Special Blog Post:
The Coding Hack's Corner, Issue #1
Although you'll find little here in the way of intensively technical details—this series is more of a 'try this' offering—you'll have to suffer through a little bit background information from time to time. That's not because it's good for your soul to know esoterica; instead, it's because the background knowledge will help in formulating a better understanding of the coding trick involved and the consequences of using it.
As a general point of reference in writing code for Web pages, the ancient "language" that Web browsers expect to see and translate into Web pages for end users is called "Hyper-text Mark-up Language" (HTML), a specialized version of a broader language called "Standard General Mark-up" (SGML). Mark-up languages for computers are actually modern descendants of the old annotational language of publishers and editors, going clear back to the very early years of printing. During the production of a book, the manuscript would be set to print, and a copy would be printed out, often on one or several long sheets of paper. This so-called "galley proof" would go to an editor, who would go through it not just to make final corrections in spelling, grammar, and perhaps layout, but also to tell the printer where to change words from regular type to bold, italics, or something else. (And yes, this story is somewhat simplified, but the point is accurate.) The editor would make these notations with "marks" on the galley proof where the changes were to be made. For example, a galley proof might have the following run of text:
Now, the editor would like to add some emphasis to this otherwise bland story, so he must indicate to the printer that the word "left" should be italicized to enhance the building plot. He would do so with some mark-up around the target word:
The printer would know what the mark-up meant. In just about the same way, a browser knows what that mark-up means, too, and will render the text as follows:
Simple mark-up for browsers comprises nothing more than a set a open and close tags that browsers know how to render. The most common ones are <b> and </b>; <i> and </i>; <center> and </center>; <u> and </u>; <s> and </s>; and <a> and </a>, with this last tag pair having some extras that can be thrown in the opening one. This is the one upon which we'll focus for the first tip.
Hyperlinks Plain and Hyperlinks with Style: The TITLE Command
Most Web page writers are familiar with the <a> tag as it is used to create "hyperlinks," which are words or phrases that, when an end user clicks on them, cause the browser to go to another Website whose URL ("Web address") is embedded in the tag. For example, a Web page writer might want to offer the following suggestion to readers:
An end-user's browser would interpret that code as follows:
Now, let's sophisticate this code just a little bit. Later, we'll throw it into high gear with a neat trick; but for now, let us add a modest enhancement called a "tool tip," which is a little ingot window of information that appears when the end-user mouses over the hyperlink. It works like this: instead of putting in only the code
put in this:
Your result in the full sentence will look like this:
Mouseover the link, and you'll see the tool-tip appear.
As a couple of quick asides in closing on the tool-tip trick, it's better to use lower-case letters to write the command portion of HTML tags these days; and notice that it's a good idea to have a space and then a forward slash (/) before the closing > character. This is especially true if, at the very top of your template, you see some mystical code lines that have "XHTML" somewhere in them.
Hyperlinks Plain and Hyperlinks with Jumps: The TARGET Command
Now that we have the tool tip in the link, let's talk about not losing visitors to your site, which is going to happen if they click on your links. It would be nice if clicking on a link in your blog opened the link in a new window instead of using the existing browser window. If the existing window does the move, you've lost your visitor, who might or might not hit the BACK button to return.
Two ways exist to do this trick. The first is a case-by-case method; the second makes it the default way that links open. The second way is a little more complicated than the first, but you do it once, and you never have to worry about it again. We'll take the easier route first, though. Recall above that we had created a hyperlink with a tooltip that looked like this:
Look at the following enhancement, which causes the link to open in a new window:
That's all there is to it: put in the target="_blank" string, and when someone clicks on the link, the Webpage will open in a new window. Here's an example of the code in use:
And here's the result the end-user will see. Click on the link, and you'll get a new window opening up:
Mouseover the link, and you'll see the tool-tip appear. Click on the link, and you'll see the linked Website open in a new window. (And close it quickly, for God's sake: the last thing I need is a federal prosecutor seeing that he's getting referrals from this blog and thereby noting my existence.)
Anyway, pretty cool, yes? No more losing your readers when they click on a link you've put in a post.
The only problem with this trick is that you have to remember to do it with every link you write. It's not much to do, but after a while, it can get pretty old, so it would be nice if there were a code that you could put in your template to make this target="_blank" statement the default way every link was handled; then, when you coded your hyperlinks, all you would need to worry about is the URL part and the tool tip part.
Preparing for Disaster
To pull this trick, we need to go to the blog template. That means we're going to mess with something that will ruin the blog if we make a mistake. To avoid catastophe, we're going to make a back-up of the template, and we're going to do it the old-fashioned way.
Open the ancient program Notepad. If you're unfamiliar with how to do this, here's the way: START → ACCESSORIES → NOTEPAD and double-click. A Notepad window will open for you. Minimize it; we'll use it in a minute.
Now, go to the screen that shows your template. Put your mouse cursor anywhere in that screen, and right-click. The menu that appears will have as its last item SELECT ALL. Click on it. The entire template will highlight. Right-click again, and on the menu, click COPY.
Now, maximize that Notepad screen you opened a minute ago. Anywhere in the screen, right-click. On the menu that opens up, click PASTE. Make sure that WORDWRAP (in the FORMAT menu) is OFF (and make sure it's always set to OFF when you're dealing with back-ups).
The entire code of your blog is now in there. Save the file. A good way to name it is to write , for example, INDEX10-27-05.txt or something similar that indicates the date of the back-up. This way, over time, you can make occasional back-ups of your template, and you'll know very easily at what date each one was done. Those of you who are role-playing-game buffs might be familiar with this as a gaming strategy: you save multiple copies as you go along so that, if you get killed, you can try opening up earlier versions to find where you were before you got yourself into the situation that led to your demise.
Once you've made this back-up, if you ever do something catastrophic on the active template for your blog, it's easy to go back to one you've saved. Here's how to make the back-up become the active template, once again. Open the file that has your back-up. It should open in Notepad unless you've reset plain text files to open in some higher word processor. If that's the case, open Notepad and then open the INDEX file from inside Notepad. Once the back-up is on screen, right-click your mouse anywhere in the screen and SELECT ALL. The whole thing should highlight. Now, right-click again and click COPY. Next, go to your template screen where the template you want to replace is showing. In that screen, right-click, then choose SELECT ALL. Now, right-click again and then click PASTE. The contents of your back-up has now replaced your active template.
Now for the Surgery
What we're going to use is the BASE tag. If we put this into the template as <base target="_blank"> , all hyperlinks after that tag will open in a new window. The tag <base target="_parent"> causes all hyperlinks to open by the default method, which means hyperlinks will use the existing browser window to open the new URL. We use these two tags together to trap parts of the template where we want hyperlinks to open in new windows. You might be wondering why, once we've done the <base target="_blank">, we'd want to go back to the old default method. One reason is that some commenting systems already have code in their programs (usually, javascripts) to pop open a window for comments. Leaving the <base target="_blank"> setting in that part of the template might confuse a poorly written javascript program running the commenting system. Also, certain templates have a method by which clicking on the big title at the top can bring back the main blog. You wouldn't want the main blog to open in a new window while some sub-component of the blog was still open.
Again, we're going to use the BASE tag pair to trap certain portions—called "frames"—of the template. (The best way, although not quite right, to identify a frame is by where you see a <div> and </div> pair trapping some code.) The most important frame, of course, is the part of the template that calls up your posts. Another important place to trap with the BASE tag pair is where you have links to advertisers, other blogs, or outside resources. The only place where setting the BASE tag pair is a bit tricky is in the part of your template where your actual posts are called in, and that's because the little javascript program that calls up your comments window is right near the bottom of that frame. We're going to set this trap very tightly around the point where the posts are pulled in.
Open the BASE tag pair right before the statement that calls up the posts. In Blogger, look for this statement:
<$BlogItemBody$>
You put the opening BASE tag, <base target="_blank"> right before this, and you set the BASE back to the default with the <base target="_parent"> right after this. So, when you're finished, you should see this little structure in your template:
<base target="_blank">
<$BlogItemBody$>
<base target="_parent">
instead of just the <$BlogItemBody$> statement.
That's it. Now, any hyperlink you put in a post will open in a new window when a reader clicks on it. You don't need to put that TARGET declaration in the A HREF statements anymore. In fact, sometimes, you'll be given hyperlink code to put in your blog somewhere; and if it's an advertisement, you can almost be sure that the hyperlink code you're given will have the declaration target="_top" in it. If you've put the BASE statements in that frame, just get rid of the advertiser's TARGET declaration. It won't hurt a thing.
And to finish this topic, look through your template for frames. As I noted above parenthetically, they're usually trapped by a <div> and </div> pair. To get links within those frames to open in a new window, put the <base target="_blank"> right after the <div>, and put the <base target="_parent"> right before the </div>. So, after you've done the enhancement, you should see this:
<div>
<base target="_blank">
•
•
•
[hyperlinks and other code]
•
•
•
<base target="_parent">
</div>
And that is that.
One More Tip for the Night
As I promised, this article would provide something for non-bloggers as well as bloggers. The following trick shows you how to use special characters not on your keyboard in posts and in comments. Special characters are rendered by way of "entity codes," which all browsers read as the same specific characters. Every entity code begins with the & sign and ends with a semi-colon. For example, to create an "em-dash" (a long "hyphenation" sign), you would type the code — where you wanted the em-dash to appear. To create the acutely accented "e" in text, you would type é to create it. The capitalized version is created by typing É. Some entity codes use pound signs followed by numbers; others use a word related to the letter. As a general—if somewhat arcane—rule, if there is a number entity code and a word entity code, use the number entity code; however, it doesn't hurt to use the word entity code in most situations. The Web has many resource tables of entity codes. In the sidebar of this blog, I have a link to a special page called HTML for Bloggers, where I provide a few tips. In that article, you'll find a nice little list of the more popular characters that can be created with entity codes.
The End of the Road
This concludes the first installment of "The Code Hack's Corner." Use what I've given you here at your own risk. Remember that your host and author is a hack, an occasional conspiracy theorist, and a blogger drifting all too quickly into the happy place of slightly fuzzy thinking that is the hallmark and reward of old age. That having been said, these tricks should work if implemented properly. If you try them and they really do succeed, by all means put a comment on the thread associated with this post. It will please me to know that something I've suggested actually had some practical use.
The Dark Wraith will provide further advice on coding in future installments of this series.
Published 10/27/2005 11:01:00 PM
<< 15 Comments Total
Good morning, Dark Wraith.
*Clap* *Clap* *Clap* *Clap* *Clap*
Wonderful article! I used the first part over at my blog on 2 items close to the top of the left hand side. It worked a treat .. and just in time for Halloween! I know I'll have to come back to read the rest of the article closer. It's very helpful!
Good morning, Old White Lady. Thank you for letting me know that you've already tried one of the tricks. Tool tips are important for a couple of reasons: first, they provide a greater density of content in articles without taking up space in the end-users' view; and second, those tool tips are read by search engine bots just like visible content. Sometimes there's something you want to say that just doesn't have a place in the main body of a post because it's too much of a "side comment" kind of thing, but the tool tip gives you the opportunity to include it without breaking up the flow of the main narrative of your article. The tool tip is also great for explaining what a link is all about.
Now, by the way, I need to mention that you got me going on the idea of running this series. You probably recall that, some time back, I gave you the instructions for inserting the BASE tags, and you successfully implemented them after only a relatively small amount of aggravation. (At least, I think it was "relatively small," but I could be wrong about that.) One way or the other, you got it working, and now you don't have to worry about the targeting command anymore.
I'll be interested to see how many bloggers give this a whirl; and I'll also be interested to see how often commenters on various blogs start using special characters.
The Dark Wraith now needs to wander back to the rant he's writing for the blog today.
That was very well done Dark Wraith, I admit I have gotten lazy now that I've gone from webpaging to blogging as far as incorporation of some good coding.
Excellent advice on saving your blog template. Many people forget to do that before attempting change. Especially for those of us using blogspot as it has a tendency to not want to cooperate with template changes at times.
:-)
Good evening, Lisa Renee.
Don't get me started on Blogger... otherwise known as Clogger, Blooger, Flogger, and a whole bunch of names a gentleman shouldn't print where young folks could see them.
Doing back-ups isn't just a good idea; it's a way to keep from losing your sanity when your template gets obliterated by Blogger, which happens from time to time through no fault of the host of the Web page. Blogger actually "loses" the code of the blog once in a great while during a publishing upload. One of the techs at a Web hosting service told me that these losses usually mean that anywhere from 25% to 40% of the code for the blog simply vanishes! If you don't have a back-up to put that code back in and republish, that's the end. I had it happen to me three times during intensive upgrades here at The Dark Wraith Forums.
So, yeah, I always was a bit overly zealous when it came to back-ups; but Blogger convinced me that my obsessive/compulsive personality sometimes pays off big time.
The Dark Wraith hopes some other people take my advice on that back-up routine.
Good evening, Dark Wraith.
Yes, I do remember that lesson. It was a terrific addition to the blog. If I recall correctly, there was not much aggravation because you explained, in depth, each step I needed to take. It was a very satisfying enhancement which I continue to appreciate.
I think this series is going to be very helpful. Thank you!
Thank you. Bookmarked. Copied. Will be studied and implemented.
Good afternoon, coturnix.
I just went over to your blog, Science and Politics, and you've already implemented the TITLE and TARGET options perfectly!
The Dark Wraith appreciates the use of his recommendations.
Thank you! I'll try to spread the gospel some more!
Also, I use WordPad instead of NOtepad as it has less formatting options to worry about. Actually, I have a Wordpad file called A HREF which contains a column of about 100 copies of the basic Link html. That file is the first one I open when I want to post something. I write my post in there, paste it into Blogger and once I see that it published correctly I close the Wordpad file but NOT saving changes. Sometimes when I know I will use only a few links, I copy a few lines from that file and copy them into a fresh blank file.
Also, direct posting from MSWord into Blogger helps with a lot of formatting stuff (e.g., superscript, funny fonts including Cyrillic alphabet, Greek letters, etc.). One has to be careful, though, as some fonts deform HTML.
Another option is to go into your "posting" page in Blogger and paste a few copies of the Link html into the appropriate box there. Then, whenever you want to create a post, you go to "view html" instead of the regular Wysiwig and there they are, ready to be filled with URLs and titles.
Now I have made another WordPad file called Super A HREF that contains about a hundred copies of the code as you have provided above with hover-over titles and "open in new window" command.
instead of putting in only the code
<a href="http://dark-wraith.com/bbs/">The Dark Wraith Forums Message Board</a>,
put in this:
<a href="http://dark-wraith.com/bbs/" title="Go to The Dark Wraith Forums Message Board and enjoy some good blogging" />
[...]
notice that it's a good idea to have a space and then a forward slash (/) before the closing > character.This is especially true if, at the very top of your template, you see some mystical code lines that have "XHTML" somewhere in them.
Unless I'm misunderstanding your intention, the second link above appears to be incorrect. How does a tag of the form <a href="..." title="..." /> create a link? There's no link text. It's an empty tag – nothing will be visible.
Recall above that we had created a hyperlink with a tooltip that looked like this:
<a href="http://dark-wraith.com/bbs/" title="Go to the Dark Wraith Forums Message Board and enjoy some good blogging" />The Dark Wraith Forums Message Board</a>
Strangely, this actually does work (in Firefox anyway) even though it technically seems to be incorrect XML. AFAIK, this should be treated as an empty tag followed by text and a dangling close tag, not aregular open and close tag pair surrounding text.
Everything I know about XML says that including slashes at the end of open tags as you do here should land you in trouble (and thus should also be a problem in XHTML). I realize there are all sorts of strange coding standards for web documents to deal with legacy browsers and such, but why would such a standard actually violate XML formatting? Am I just missing something?
For example, to create an "em-dash" (a long "hyphenation" sign), you would type the code — where you wanted the em-dash to appear
For those who don't want to remember the numerical code, an em-dash can be produced by the code — (and an en-dash by –).
Good morning, plover.
On your first point, I was being lazy by merely noting the tag portion that would be changed and not the entire structure. I should probably repair that lest anyone think the other portion isn't necessary with the little enhancement.
Now, about your second point. First, I think you're refering to "XHTML" rather than "XML," even though they're all part of the same big movement out of the simple word of straight HTML. The point of suggesting the forward slash is that it prepares a document for Strict 1.0, even though, in and of itself, it's not technically correct. It seems to me that a W3C standard (which is nothing more than a standard for FireFox and related implementations even though it's a good idea to abide its strictures to the extent possible) applied to a document headed by any XHTML statement at the top will be a whole lot happier with those forward slashes. I am mindful that this is, broadly speaking, not the best coding discipline, and I plan to get really down into the dust and hammer out some more technically precise issues about XHTML later on.
I do appreciate your input, though. You are sophisticated in your understanding of the world of code. If you spend some time reading my posts over the coming weeks, you'll see that my style is to start simple, with loose application, then tighten up the definitional framework as I build the arc of a series. It generally works for me as a teacher, even though I can drive more technically sophisticated sorts batty sometimes.
The Dark Wraith will probably one day get his backside kicked for being that way.
I think you're refering to "XHTML" rather than "XML,"
I made my points the way I did because I (more or less) trust my understanding of the XML framework, but don't necessarily know what wrinkles might be added in the context of XHTML, especially ones that result from the vagaries of browsers rather than the standard itself.
The point of suggesting the forward slash is that it prepares a document for Strict 1.0, even though, in and of itself, it's not technically correct. It seems to me that a W3C standard [...] applied to a document headed by any XHTML statement at the top will be a whole lot happier with those forward slashes.
Yes, strict XHTML requires forward slashes for places where one wants an empty tag (<br/> etc.), but I would think that precisely for strict XHTML (which, in theory anyway, requires that a document conform to XML syntax, right?) that a slash at the end of a tag intended as an open tag would be an error and produce undesired results. I'm surprised it works even in non-strict XHTML, but then what I'm surprised about doesn't necessarily have any bearing on how browsers actually work... :)
my style is to start simple, with loose application, then tighten up the definitional framework as I build the arc of a series. It generally works for me as a teacher, even though I can drive more technically sophisticated sorts batty sometimes.
So, in other words, the details I'm questioning are just the result of pedagogical choices? I figured there had to be something going on (especially given that the source code for the article itself didn't include weird, extraneous slashes). However, my impression is that the approach you've taken in this instance will be confusing to anyone who understands what an XHTML empty tag is, whether they are particularly sophisticated coders or not. Obviously, this is just my two cents – you're the one who understands the audience you're writing for. It just seemed worth noting.
Quibbling aside, it seems like a useful series. Thanks for doing this. I'll keep an eye out for future installments.
Good Morning Dark Wraith,
Have implemented the default target trick. THANKS!! very cool. Am waiting with bated breath for more.
Tried the special char trick, couldn't make it work on first go-round, but didn't have the time to fool around with it (at work).
Something I've seen while blogging, and have wondered about: some comment engines take out all your extra spaces and carraige returns. You therefore cannot make a readable comment, because the whole thing is all mashed together. Some people, however, must know the trick of inserting hard-spaces and hard-carraige returns, because their comments are readable.
Oh, blogger envy! Almost as pitiful as smiley envy.
Good morning, SB_Gypsy.
First things first. To create a hard space, type the following string:
You can put as many of these together as you like, but don't go way overboard: you could end up with a "thread-ripper" that is too wide for the frame in which the comments are being made.
Now, I've seen a number of comment engines that take out extra carriage returns. If I'm not mistaken, Drupal is known for this, and I think Typepad's native comment engine is, too. Sadly, they also have a bad habit of ignoring HTML code that tries to overcome their little game. Here's the best you can do: A hard carriage return will occur in normal HTML with the <br> tag. Alternately, you can get a paragraph break with the <p> tag.
These do not work after the last line of a comment, but in some systems they work within the body of a comment.
Give them a try and see what happens.
The Dark Wraith awaits the results.
YIKES, that string got picked up as an actual hard space instead of the representational string for one. Let's try that again, SB Gypsy.
To create a hard space, type the following string:
The Dark Wraith won't even try to explain how tricky it is to write codes here without the codes being picked up as actual tags.