Friday, February 05, 2010
Let's Get Out While We Can
Blog Entry #170
(1-2) \' and \", towards the end of respectively placing single-quote/apostrophe and double-quote characters in dialog box messages and in document.write( ) strings; and
(3-4) \r and \t, towards the end of respectively inserting line breaks and tabs in dialog box messages.
window.alert("Hello \World");will simply display Hello World on the alert( ) box.
(1) \141 (using its octal ASCII code position),
(2) \x61 (using its hexadecimal ASCII code position), and
(3) \u0061 (using its Unicode code position);
however, such formulations are not discussed in "Escape Characters".
Quote formatting, revisited
document.write('We\'re going to \"need\" to know where you\'re going tonight, young man!');
To review, it is necessary to
(a) escape single-quote/apostrophe characters in a string delimited by single quotes and
(b) escape double-quote characters in a string delimited by double quotes, but
(c) double-quote characters can appear literally ("unescaped") in a string delimited by single quotes and
(d) single-quote/apostrophe characters can appear literally in a string delimited by double quotes.
This all holds regardless of the extent of quote nesting:
document.write('Alice said, "Bob said, \'Carol said, "Dave said, \'...\' " \' " ');
It follows that, whereas the apostrophes in Joe's write( ) string, which he chose to delimit with single quotes, must indeed be escaped, there's no need whatsoever to escape the double quotes surrounding the word need, and the command can be written as:
document.write('We\'re going to "need" to know where you\'re going tonight, young man!');
Had Joe delimited the write( ) string with double quotes, the apostrophes could have appeared literally but then the double quotes around need would need to be escaped or referenced as described above.
Break my lines
Joe rolls out prompt( ) and alert( ) box examples in which the \r escape sequence is used to induce line breaks in the messages on the boxes. Here's his prompt( ) box code:
var name = prompt("Please write your \'name\' in the box\rWrite it with \"quotes\" like this.","");
// Again, the single quotes surrounding the word name do not need to be escaped.
The \r sequence signifies a carriage return, which does not correspond to a
All of the other OS X GUI browsers on my computer - Camino, Chrome, MSIE, Opera, and Safari - force a line break after the word box in the prompt( ) text. (Firefox automatically wraps the prompt( ) text after the nested "quotes" string; Joe does not force a line break at this point in the text.) Another commenter points out that the correct escape sequence for a newline is \n, and replacing \r with \n does indeed give the expected effect with Firefox:
Unlike the window dialog methods, which are at least for now purely scriptic methods, document.write( ) has long had one foot in the HTML world (as implied above), and neither \r nor \n in a document.write( ) string will normally force a line break because, per the W3C's recommendation, Web browsers generally render carriage returns and newlines as ASCII spaces, i.e., space characters as generated by the space bar at the bottom of the keyboard. (This is also the reason why the document.writeln( ) method does not normally induce line breaks.) There is an important exception to this: wrapping a write( ) string in a pre element will enable you to force line breaks with \r or \n sequences, e.g.,
document.write("<pre>The backslash\ris the key.</pre>"
But as Joe notes in the tutorial's "document.write Example" section, document.write( ) line breaks are more straightforwardly effected via the br element.
The backslash is the key.
Keeping tabs on tabs
Finally, Joe offers the following code for an alert( ) box whose message comprises nine text lines and contains a three-line section formatted with \t tabs:
alert('OK Then!\r\rYou want a neat box like \"this\" one?\r\rWell!\r\rYou\'ll need:\rBrains\tBeauty\t\tTalent\rMoney\tDog food\t\tLuck\rA Cat\tEye of Newt\tA Shrubbery!\r\rAnd the ability to \'read\' this tutorial.\r\rOK?');
// The tabbed section is in purple.
Most of the OS X browsers on my computer (including Lynx!) render a tab as eight ASCII spaces in a monospace font. To the extent that this is a 'normal' rendering, here's what Joe's alert( ) box should look like:
On the other hand, dialog box text is generally rendered in a sans-serif font - this is why it is necessary to put two tabs between Dog food, which contains eight characters but does not quite reach the second tab stop, and Luck in order to get Luck to line up with Talent and A Shrubbery! in the third column of the tabbed section of the alert( ) box.
Brains Beauty Talent Money Dog food Luck A Cat Eye of Newt A Shrubbery! 12345678123456781234567812345678Browser notes
• For Firefox, change each \r to a \n and the alert( ) box will look as it should.
• Camino cuts off the OK? at the bottom of the box although the rest of the box looks OK.
• MSIE 5.2.3 won't render tabs at all. :-(
As for a \r carriage return and a \n newline, a \t tab in a document.write( ) string will translate to an ASCII space unless the write( ) string is wrapped in a pre element, speaking of which...
Tabs - HTML Goodies
Moreover, in "Tabs - HTML Goodies" Joe notes,
Others told me they created a tabbed layout*, copied and pasted it into their HTML document and then surround[ed] it with the <pre> or <xmp> tags,which IMO is a better approach to HTML tabbing than the document.write( ) and \t approach, notwithstanding Joe's later, somewhat-at-variance comment that
I know I said earlier in the tutorial that using the pre or xmp tag didn't work [in a non-script HTML context] because the tabs often didn't transfer correctly - especially if you're using a non-block font.(I'm not quite sure what Joe means by "non-block [sans-serif?] font", as "block" is not one of the W3C's generic font families.)
*Perhaps the most reliable way to generate tabs in HTML is to hard-code them with 	 character references (which will still need to appear in a pre element) - it was necessary for me to do this for my Dog food-to-Luck graphic above because, even as pre element content, my keyboard-tab-key-generated tabs are converted to ASCII spaces in the Blogger post textarea field.
Pre element text is typically rendered in a monospace font, and if you were to override this - with, say, a font-family:Arial,sans-serif; CSS declaration - then I can see how it might cause problems with your tabbing. If you're serious about using tabs, keep everything in a monospace font and you should be able to work it out.