A minor item for the HTML wish list

[Guest Michael Dietz]

TMG has the [WEB:] [:WEB] codes to generate a URL link. It works very well. However I would like to add the target="_blank" attribute to the encoded line. To do so I have to use a kludge, i.e., placing the quotation marks in rather awkward locations. For example:

 

[WEB:]http://ca.gov/" target="_blank;California[:WEB]

 

Note I need to place a trailing quote after the URL address but none after the _blank attribute. This will generate the desired

 

<A HREF="http://ca.gov" target="_blank">California</A>

 

with the correct placement of quote marks.

 

I would be nice to enter the target="_blank" attribute and have TMG recognize the constant and adjust the quote marks as needed. As I said it is a minor item, more in the aesthetic realm than serious.

[John Cardinal 0]

Michael,

 

I urge you to reconsider using the target="_blank" parameter. Most web designers now agree that people browsing a site should choose for themselves whether or not to break out of a framed site or open a new window or tab to view a link. (All modern, full-featured browsers include right-click options to open a link in a new window, etc.)

 

Note that the target= parameter is deprecated in HTML 4.01 (the latest official version) which means it will be removed in a future version.

 

Given the above, I don't think it's wise for TMG to add support for the target= parameter. It's very likely that most web browsers will support the target= parameter for quite some time, but that doesn't mean that well designed sites should use it.

[Michael Hannah 0]

As stated in the TMG Help files

[WEB:]www.whollygenes.com;Wholly Genes[:WEB]

is equivalent to:

[html:]Wholly Genes[:HTML]

 

I have found that if I am doing anything unusual it is better to actually use the [html:][:HTML] pair and code exactly what I want. While this does not address how to use the WEB construct and include attributes, or whether there is an error in the processing of WEB with quotes, it is a simple workaround.

 

In your case instead of using [WEB] you could directly use

 in TMG:
[html:]California[:HTML]
 
(added comment after seeing John's reply)
As for this particular HTML attribute, it is just my opinion but I completely agree with John.  Having worked with HTML for well more than a decade (yep, since its very beginning), I strongly recommend using the simplest HTML code possible in TMG data.  Relying on some special attribute is very risky as I have seen all too many such attributes deprecated and dropped as HTML changes over time.  I would find this especially an issue for user-entered TMG data as one would like to believe that your genealogy data will exist far longer than particular HTML attributes are likely to exist.  Let updated releases of programs like John's wonderful SecondSite change and modify the HTML codes they automatically generate as the HTML specifications change.  Don't hard-code specific HTML attributes in your own TMG data.

Edited September 30, 2008 by Michael Hannah

[Guest Michael Dietz]

Michael, I know that I can use the HTML coding directly, it is just a bit more convenient to use the [WEB:] construct. Plus it is a bit shorter in line length.

 

John. I know the target = is deprecated. However I would like to join a web ring on Ohio genealogy and the ring master insists on having any external links open a new window. I agree that it is a bit of overkill but she says she does not want the original window to disappear. She wants to be able to navigate from my site (or the external site) to the next site on the ring. The only way I know of to do that is to open the external site, such as the Bethesda Methodist Cemetery web site, in a new window.

 

I had one devil of a time getting the target= to work in sources. I had to put the following type of sentence in the COMMENTS window for the source:

 

online at: [WEB:]http://usgwarchives.net/md/montgomery/tsimages/bethesda/bethmeth1.html" target="_blank;Bethesda Methodist Cemetery[:WEB]

 

I tried it in a variable but to no avail. SS cut the URL at the first quote mark give either an invalid URL or one which opened in the same window as my web site.

 

Any suggestions on how to accomplish this would be appreciated.

 

Thank you both for the replies.

 

Mike

[John Cardinal 0]

Michael,

 

I am not sure what to tell you about using the [WEB:][:WEB] construct in source elements. Second Site auto-detects URLs in sources and that may be interfering with the use of the [WEB:][:WEB] codes. If I read your reply correctly, you were able to use the WEB code in the COMMENTS field but not in the other source element fields? Let me know if I got that right so I can do some tests here.

 

Your ringmaster is not up to date with respect to web standards, and that's a shame. The issue is not that target="_blank" is overkill; the issue is that using target="_blank" takes control away from the person browsing the site. When target="_blank" is used, the person browsing the site has no choice; they click the link and it opens in a new window (or possibly a new tab if the browser is configred that way). They may not want another window or tab, but they can't do anything about it. On the other hand, if target="_blank" is not used, the user can choose to open the link in the same window, a new tab, or a new window... whatever he or she prefers. That's the important point.

 

It sounds like you don't agree with her, so I won't berate you further! Perhaps I gave you some ammunition to convince her to reconsider.

 

Anyway, please clarify how you used the WEB codes in source elements and I'll try to figure out a workaround.

[Guest Michael Dietz]

Thank you John for the kind words. You are right, I do not agree with the ring master but when I complained to the chief honcho of the webs I was told she was the best they had and she was the ring master for several dozen rings. So that was a brick wall. I am now thinking of abandoning the idea of being in the ring completely. After all, who looks at rings, especially genealogy ones, other than the other members of the ring?

 

I will say I do sort of think the idea of opening the external link in a different window is appealing. My reasoning for that is these links are either to the source or to a description of the locality. So if I am looking at the data for an individual I can look at the 'original' source data at the same time if both windows are open. In the case of a location I have two or three links so I can scan information on the location on several windows if I am looking for a particular piece of data. Anyway this could be a topic for a discussion of pros and cons.

 

In the case of the Master Place List I put the URL data in the Comment field of the Edit Place window. For instance:

 

Transcriptions and photographs are available at:

[WEB:]http://usgwarchives.net/md/montgomery/tsimages/bethesda/bethmeth1.html"'>http://usgwarchives.net/md/montgomery/tsimages/bethesda/bethmeth1.html" target="_blank;Bethesda Methodist Cemetery[:WEB]

 

This then ends up on the page for that location in SS with no problem as part of any comment I have for the place.

 

The sources are a different story. I have a custom source type but I will use the standard Electronic Database (Family File) since it is simpler. If I put [WEB:]http://usgwarchives.net/md/montgomery/tsimages/bethesda/bethmeth1.htm;Bethesda Methodist Cemetery[:WEB] in the URL variable I get the link to the cemetery which opens in the current window. If I place the target= attribute in the URL I get the URL which will open but also have target="_blank hanging in the source description in SS. Apparently SS cuts the line at the end of the URL, ignoring the target= attribute because it is deprecated as you have said.

 

What I did is put the line:

 

online at: [WEB:]http://usgwarchives.net/md/montgomery/tsimages/bethesda/bethmeth1.html" target="_blank;Bethesda Methodist Cemetery[:WEB] in the COMMENTS field, removed the URL variable from the Source Type and added the COMMENTS field to the end of the type. So using the example of the Electronic Database (Family File) I ended up with a custom type similar to

 

[COMPILER], [AUTHOR] ([LOCATION])<, downloaded [DATE]><, [COMMENTS]><, [CD]>.

 

This then gives me the source with the URL listed as Bethesda Methodist Cemetery which opens in a new window.

 

I hope this explains the situation.

 

Thank you for your time. Remember only three weeks to go.

 

Mike

[Guest Michael Dietz]

ps John.

I just happened to think. I never tried a custom element for the URL. I would imagine SS recognizes the standard element of URL as a URL but I wonder what would happen with a custom element containing the attributed URL?

 

I am going to give it a try and see.

 

Mike

[Michael Hannah 0]

While you are running tests, you might also check whether using the

 codes instead of the [WEB] codes works better.  Since TMG must parse and process the [WEB] codes, but completely leaves the [html] code alone, [WEB] might be the source of the issues you are seeing.

[Guest Michael Dietz]

It doesn't matter which I use, the WEB or the HTML option in an element field in the source.

 

I think what happens with the WEB option is TMG parses it into the HTML format. Then SS tries to parse the HTML format into the URL and cannot do it. If the url is simply placed in the element field TMG passes it along as a constant and SS handles it just fine, displaying the complete URL address (http:.....) as the bold, undelined link.

 

My situation is I need to have the target attribute as part of the address. So I should use either the HTML or the WEB format in order to have the complete URL address and instruction to open in another window. If the WEB or HTML format with the slight modification I started this thread with is placed into the COMMENTS field as a 'comment' line TMG recognizes it and parses it into the correctly formatted html line. SS then accepts that as a correct URL and displays the given name for the link in bold and underlined.

 

So it is a bit ofincompatibility between TMG and SS I think.

[John Cardinal 0]

Michael,

 

First, it shouldn't matter which source element is used for the URL. SS processes all of them the same, at least with respect to URL handling.

 

I think the issue has something to do with the Second Site's automatic detection of URLs in sources. Now that I understand how and where you are using the WEB codes with the target= parameter, I'll do some testing here to figure it out.

[John Cardinal 0]

I think what happens with the WEB option is TMG parses it into the HTML format. Then SS tries to parse the HTML format into the URL and cannot do it. If the url is simply placed in the element field TMG passes it along as a constant and SS handles it just fine, displaying the complete URL address (http:.....) as the bold, underlined link.

Michael,

 

I meant to reply to this part of your message in my last response, but I forgot.

 

When SS is creating a site, TMG is not involved and doesn't do any parsing. Second Site reads the TMG database directly. So, your guess that "TMG parses it into the HTML format. Then SS tries to parse the HTML format" is not correct. Actually, SS sees the exact text that you provide, including the WEB codes, and SS interprets the web codes. In this case, you didn't follow the rules; the WEB code calls for an HREF, not an HREF and a TARGET. It's OK to break the rules, but sometimes you get caught! In this case, the way TMG implements the WEB feature, your approach works. SS is honoring the rules, but is implemented a little differently than TMG, and that's partly why there's an issue...

[Guest Michael Dietz]

Thank you John. After going back to the help on the WEB and HTML options I see where the TMG sample does not have the target attribute in it. So I admit that I tried to do something which was breaking the rules. As my dear old dad would say "If all else fails, read the instructions." and "If it ain't broke, don't fix it.".

 

I have decided to decline the ring membership so it is now a moot point other than I still would like to be able to open the source and location links in a different window for convenience in looking at my data and the original data at the same time.

 

Thank you so much for looking into this for me.

Mike

[John Cardinal 0]

Michael,

 

OK, I found the issue. The quotes in the HREF value are interfering with the processing of the WEB codes. The problem is a combination of some logic that SS applies to source elements combined with the rules of the WEB code.

 

I don't have a workaround for you now... Sorry!

[Guest Michael Dietz]

No problem. Thank you again John and I will see you on the ship.

 

Mike

[Michael Hannah 0]

The quotes in the HREF value are interfering with the processing of the WEB codes. The problem is a combination of some logic that SS applies to source elements combined with the rules of the WEB code.

Do quotes in the HREF value also interfere with the processing of the HTML codes, i.e. would HTML codes work where WEB codes don't?

[John Cardinal 0]

Michael,

 

You can try to use your own HTML, but I don't think it will work. Source elements are not supposed to contain HTML, and there are conventions that get in the way. For example, the convention of citing URLs like this:

 

<http://www.example.com>

SS has to convert the so they are not interpreted as HTML. I think that processing alone will defeat your attempt to use HTML there, and I don't think using TMG's [html:] and [:HTML] codes will get around it.

 

HTML and the various codes work in the COMMENT element of the source because that field is treated as a memo field, similar to the way event memos are treated.

[Michael Hannah 0]

Ahhh.... I see! The problem occurs in using them in Source Element fields, as opposed to in memo or sentence fields. Of course [html:][:HTML] codes are not defined as available/legal for Source Element fields, nor are [WEB:][{:WEB] codes. That would explain it. I had missed that subtlety.