Terry Hickman's Light Bulb Alley: Punctuation
Ellipses and em-dashes haunting your nights? You're not the only one, it appears.The following exchange occurred on Speculations Rumor Mill, my favorite Web hangout for genre fiction writers. The participants have kindly given me permission to post it on Light Bulb Alley for the benefit of writers everywhere. This particular discussion concerns this knotty grammatical problem that plagues almost every writer I know, including me. If you're still confused after reading this, head for your reference shelf and study up. That's what I have to do, too.
==========================================================================================Message 99 was left by Karen R. on 2002-01-05 05:52:00.
Re: em dashes. I've wondered about these rules a lot. I'm reading the 3rd Harry Potter now (always a little behind) and on the same page I see two quotes from Prof. Trelawney:
"My poor dear boy . . . my poor, dear boy . . . no . . . it is kinder" etc.
"My dear boy, it is an omen -- the worst omen -- of death!"
In a later quote from Oliver Wood I see FIVE em dashes.
Sounds like the trailing off vs. interruption rule for dialogue is fine. I guess the number of allowable em dashes is just a matter of personal preference.
Message 100 was left by Timprov on 2002-01-05 06:13:00.
The em-dash example isn't interruption, it's insertion, i.e. "the worst omen" is a subordinate-clause clarification of "My dear boy, it is an omen of death."
Filling sizable pauses with anything other than description is cheating your readers, IMO. When people pause like in the ellipsis example above, it's generally either because of or accompanied by an action. So the ellipsis is used to avoid indicating the pause through description of those actions, and thereby characterization.
Message 101 was left by Jaws on 2002-01-05 09:36:00.
I have to disagree with the second paragraph of msg 100 almost entirely. It's sure as hell not cheating your readers for two characters to be involved in an argument, and many arguments—at least, the ones that occur in real life—involve not constant interruption, but occasional pauses while a party tries to formulate an appropriate response. Negotiations over child custody in front of a judge are notorious for this, because there's so much emotion involved that blurting out complete thoughts leads to contempt citations. The "action" is rumination, not something that should ordinarily be considered "bad." Making that rumination explicit by getting inside of a character's head during an argument is at least as much "cheating the reader" if done for that purpose as giving no explanation, and letting the reader infer what's happening. If character development is consistent, that inference should not be much of a stretch.
All that the punctuation really means is that a character failed to complete a thought or sentence aloud. How (and whether) to state or imply the reason(s) is entirely up to the author, and entirely a matter of style, in a different sense than I think Jed used it above. Some editors may not like certain styles and usages, and may even reject works on that basis. That, however, is a matter of personal taste, not of "cheating your readers."
Message 102 was left by Timprov on 2002-01-05 10:11:00.
Oh, I don't suggest putting in the reasons, necessarily. But during any pause, things happen, particularly in a public setting. In a courtroom, people might shuffle papers, or cough, or whisper among themselves, or drop things, etc. etc. Using the description of such an event makes your pause much more vivid and powerful than an ellipsis does. It's cheating because you're including a large pause without the pacing of the story reflecting it.
Message 103 was left by Terry Hickman on 2002-01-05 11:59:00.
This is a *great* discussion, and one I sorely need. I have never "codified" how I use ellipses and/or em-dashes (I never even knew what to *call* the latter!) so I do need to dig into Strunk & White, Chicago, and whatever else help I can find. You've given me the inspiration to do that!
For the time being, though, may I ask a really dumb question? What's the *typing* drill for em-dashes?
1. SpokenWord[space]--"
2. SpokenWord--[space]"
3. NarrativeWord1--NarrativeWord2
4. NarrativeWord1[space]--NarrativeWord2
5. NarrativeWord1--[space]NarrativeWord2
6. NarrativeWord1[space]--[space]NarrativeWord2It makes a difference to me, because my WordPerfect seems to delight in cutting double-dashes in two at the end of a line, or putting the ending " at the beginning of a line all by itself. I haven't figured out how to make it stop doing that, so sometimes I end up putting extra spaces in, anything to make it come out right. Any advice on that point would be appreciated, also.
Message 105 was left by Timprov on 2002-01-05 12:22:00.
There's probably a "correct" typing drill, but I don't think people stick to it at all. The most common usages are 3 and 6. End-of-sentences come in your #1 and without any space. One thing that irritates me no end is the double-dash form, because while some fonts have a special character for it, most don't, and '--' looks really ugly. (That's more an issue in web publishing than print publishing.) Personally, as you can see in my posts, I use a single dash surrounded by spaces, which is non-typical but clear (and also the way I publish them). I imagine em-dash usage is probably one of the most common house stylesheet changes copyeditors have to deal with, so generally you're pretty safe with whatever the heck you feel like, and they'll change it to what they think is appropriate.
Message 106 was left by Willis Couvillier on 2002-01-05 13:37:00.
Humm, well, remind me to proofread anything I might submit to Speculon. I use the [space]--[space] more than I probably should; Word converts it automatically to -. I had to turn off the autoformat for that, when I started to eSubmit.
Will.
Message 107 was left by A. Freed on 2002-01-05 19:31:00.
Heh. Whereas I learned to use em-dashes as double-dashes, no space (like--this.) This from William Shunn's article on proper manuscript format.
Message 108 was left by Toiya K. Finley on 2002-01-05 19:53:00.
Re: 107: I think "--" is ugly too, but the reason Shunn's article called it proper manuscript format is because the "--" is easier to find in a ms than "—". "—" is easy to gloss over and may look like an en-dash (single dash) when copyeditors/layout editors are combing the ms. Same deal as underlining instead of italicizinig. I've seen #3, and #6, as well as [space]-[space], as Timprov mentioned, and they all work. Whatever form you choose, make sure that it's obvious to whomever's doing the layout that you intend for an em-dash to be there.
A quick keystroke for the em-dash "—" in place of "--" is [NumLck] + [Alt] + 0151.
Message 109 was left by Timprov on 2002-01-06 01:44:00.
Will (and anybody else), it's probably best just to submit it as you had it. The copyediting thing applies to me as well; double-dashes annoy me in copyediting (because I always miss one or six on the first pass), but they don't have any bearing on ms. consideration.
Message 110 was left by Timprov on 2002-01-06 01:56:00.
As for them being ugly; I really don't care about them being ugly in ms. form. And in layout for print publishing, they're converted into a long-dash character, so they're not ugly when they're actually published. We web publishers don't really have that luxury (because people can override our font choices, some font makers decided that em-dashes weren't important, and "—" and "-" aren't nearly as distinguishable in most standard web fonts as they are in print) so we have to find some other way around it. A lot of web publishers have just gone to using "--", which is what annoys the heck out of me.
In print, I like to have spaces around the em-dash character; but that's a whole 'nother argument.
Message 112 was left by Terry Hickman on 2002-01-06 10:58:00.
Thanks for all your input, Timprov & TKF. So I guess I just pick on e*I* like and use it consistently in my own work, and let editors mess with it as they like. OK!
Message 116 was left by Jed Hartman on 2002-01-07 01:32:00.
Here's the scoop on em dashes and typography: An em dash in typeset material should not, traditionally, have a space on either side of it. (Some publishers do put spaces around em dashes, but most don't. I consider both to be valid choices, but I prefer no spaces except in certain typefaces.) But until recently, typeset material was set from typewritten manuscripts, and typewriters used monospace typefaces, so there was no clear way to distinguish an em dash from a hyphen by looking at it (a capital M is the same width as a lowercase i in a monospace font). So it became customary to use two hyphens to represent an em dash in a typewritten manuscript; typesetters would then replace the hyphens with an em dash.
For reasons that I'm unclear on, in typewritten manuscripts a double hyphen is traditionally surrounded by spaces, except when it comes at the end of an interrupted line (as of dialogue):
NarrativeWord[space]--[space]NarrativeWord
...DialogueWord--"
With the advent of desktop publishing in the mid-'80s, everything got confused. People knew the traditional conventions for typewritten material, but didn't know that those were originally intended as ways to represent typeset material using a typewriter. (Much like trying to use ASCII to represent various things that ASCII doesn't include, like _underscores_ to represent underlining in a typewritten manuscript, which in turn represents italics in a typeset document.) Books like The Mac Is Not a Typewriter were written to help people create desktop-published documents that looked typeset.
And that was all fine and dandy until, as Timprov noted, the Web came along. Until fairly recently, there was no way to represent an em dash in an HTML document that you could be sure would be viewed properly in all browsers.
There was a fancy trick using a single-pixel GIF and alt text that David Siegel recommended; I used that for years in my online words-and-wordplay column, now sadly defunct due to lack of time. At SH, we use the typewriter approach ("[space]--[space]" in most cases). In my own Web pages, I use the HTML entity — (ampersandpound151semicolon), which now shows up properly in all modern browsers that I've tried (including Lynx, which was previously the last holdout), but we haven't yet switched over to using that at SH. An article at alistapart (I think it's not that article but another one linked from it) claims that #151 is not a valid HTML entity, and recommended using #8212 instead; that too has worked in every browser I've tried. (Unfortunately, the HTML symbolic entity named mdash is not widely supported.) With such em-dash characters, you don't put spaces on either side, just like with traditional typeset material. (Unless, of course, you're a publisher who likes having spaces on either side of an em dash.)
As for avoiding breaking lines in a word processor when typing a double hyphen, some word processors allow you to enter a "nonbreaking hyphen" character; if your word processor provides such a character, you should definitely use it in all your double hyphens. I also recommend using a nonbreaking space before the double hyphen to avoid starting a line of text (or a page) with a double hyphen (or with an em dash if you put spaces around your em dashes).
All of that said, though, I suspect Timprov's right that editors aren't likely to care much about what exact format you use. Traditional-minded editors may expect you to use traditional manuscript format (the double-hyphen approach discussed above), and I suspect it's easier on the typesetter (if you're submitting to someone who still sets type from hardcopy) if you use a double hyphen to make clear that what you want is an em dash, but I suspect most editors will figure out what you mean in most cases.
The one thing I'd strongly recommend avoiding is using a single hyphen with no spaces around it-like this-as an em dash.
Message 117 was left by Jed Hartman on 2002-01-07 01:34:00.
...Of course, the remaining drawback to using an HTML numeric entity for an em dash is that if you're using a monospace font, as is generally used to display the tt tag that the Rumor Mill puts around postings, you'll get a monospace "em dash" that looks like a hyphen... But most people aren't reading most of the Web in monospace fonts.
Message 118 was left by Timprov on 2002-01-07 05:55:00.
Unfortunately, while current versions of Lynx may support em-dashes, older versions don't (and don't substitute anything, they simply don't display the character), and Lynx users don't have the upgrade pressure IE and Netscape users do. Also, Lynx has, at least to the point of the version I have access to, always used a monospace font.
Message 119 was left by John Savage on 2002-01-07 10:43:00.
I just checked the W3C definitions, and — is indeed a correct HTML entity for an em-dash. It is not correct, however, in Unicode, which defines all characters with four Arabic numerals (hence —).
As an aside, here are two other seriously annoying typography issues for e-publishers. I've made a couple of determinations for my use, but there is simply no standard.
(1) Quotation marks (whether single or double). Typographically, an opening quotation mark is distinct from a closing quotation mark. Most word processors that use "smart quotes" (the default, for example, in Word97 and later) will automatically make this change, and pretty accurately too. HTML, however, will not. The " entity does not substitute typographical quotation marks; instead, one must choose Unicode characters. Unfortunately, many typefaces do not have the proper Unicode characters, so we end up with Courier-style ichor. As far as writers are concerned, it really makes no difference whatsoever whether mss have "smart" or "dumb" quotation marks, unless the editor is in the habit of publishing the ms as is!
(2) Representing ellipsis is an unfortunately insoluble problem, largely due to stupid font design. First of all, writers, it is not proper to put spaces between the periods in an ellipsis; it should look like ..., not . . .. Second, learn the difference between a three- and a four-dot ellipsis, and when the ellipsis is brought up to the preceding or trailing end of a phrase (or, in some cases, neither!)—your typesetter will thank you.
The real problem with ellipsis, though, is whether to use three periods (which risks breaking an ellipsis over a line break) or a single-character entity… like … at the end of the preceding phrase. All modern word processors support the latter, and it's also supported in Unicode and extended ASCII. However, that support is (to use the technical term) butt-ugly: it's invariably too narrow in commonly used typefaces. One solution is a "virtual entity," such as . . ., but this causes problems with some browsers (especially for those not using a US-ASCII default). Here's a plea for web-font designers to expand the three-dot ellipsis to a reasonable width, probably two ems (and at least 1.5 ems).
Message 123 was left by Jed Hartman on 2002-01-08 01:31:00.
Re Lynx: the older versions of Lynx that I'd seen display #151; as a hyphen, while the newer ones display it as a double hyphen (which I thought was awfully clever of the newer versions). I'm certainly in favor of being accessible to Lynx users where possible (especially 'cause doing so is generally good practice for other accessibility issues), but I think for my own pages I draw the line at trying to support old versions of Lynx; agreed that there isn't the pressure to upgrade, but I think the percentages still get small enough for me to be willing to give them a less-than-ideal experience. (But that's not an SH policy; we're still using double hyphens there.)
Thanks for the explanation re Unicode, John; I hadn't caught that distinction (or maybe just hadn't remembered it), but now that you mention it, it makes sense.
Good point re "smart" quotes, too. Our text-to-HTML conversion script converts all known curly-quote characters to straight quotes, but it sure would be cool if there was enough browser support for curly quotation marks to be able to use them easily. Most recent browsers do support the numeric entities (both Unicode and HTML) for curly quotes, but they're a pain to use nicely when creating HTML, and there's always the legacy-browser-support issue.
As for dot-dot-dot: Chicago says to use three-to-em spaces between the dots, so we at SH have actually been using the . . . format you mentioned. I'm sorry to hear that it doesn't work well in some browsers, though; can you tell me more about how it looks in non-US-ASCII? (Feel free to send it to me in email if you like; I feel a bit like I'm hijacking this topic into technical details of Web publishing, which I find fascinating but may not really be relevant to the editing topic.)
Well, okay, since I'm on the subject anyway, I'll mention one other thing about Web formatting: Jim Kelly noted in an early "On the Web" column that he finds block paragraphs with blank lines between them very hard to read. He wants indented paragraphs in Web browsers. I tried some mockups, and they looked terrible, but A List Apart (http://www.alistapart.com/stories/typography/) has a style sheet that makes them look (to me) very attractive in browsers that support CSS, and reverts to regular block paragraphs for browsers that don't. I like that approach a whole heck of a lot, but I don't know enough CSS yet to be able to replicate it (or even understand their stylesheet). But at some point I think it'd be cool to switch to that approach.
==========================================================================================
Want to go back to my Home page? Click here.Send me some email. I promise to answer! Ellipses and em-dashes haunting your nights? You're not the only one, it appears.
The following exchange occurred on Speculations Rumor Mill, my favorite Web hangout for genre fiction writers. The participants have kindly given me permission to post it on Light Bulb Alley for the benefit of writers everywhere. This particular discussion concerns this knotty grammatical problem that plagues almost every writer I know, including me. If you're still confused after reading this, head for your reference shelf and study up. That's what I have to do, too.
==========================================================================================Message 99 was left by Karen R. on 2002-01-05 05:52:00.
Re: em dashes. I've wondered about these rules a lot. I'm reading the 3rd Harry Potter now (always a little behind) and on the same page I see two quotes from Prof. Trelawney:
"My poor dear boy . . . my poor, dear boy . . . no . . . it is kinder" etc.
"My dear boy, it is an omen -- the worst omen -- of death!"
In a later quote from Oliver Wood I see FIVE em dashes.
Sounds like the trailing off vs. interruption rule for dialogue is fine. I guess the number of allowable em dashes is just a matter of personal preference.
Message 100 was left by Timprov on 2002-01-05 06:13:00.
The em-dash example isn't interruption, it's insertion, i.e. "the worst omen" is a subordinate-clause clarification of "My dear boy, it is an omen of death."
Filling sizable pauses with anything other than description is cheating your readers, IMO. When people pause like in the ellipsis example above, it's generally either because of or accompanied by an action. So the ellipsis is used to avoid indicating the pause through description of those actions, and thereby characterization.
Message 101 was left by Jaws on 2002-01-05 09:36:00.
I have to disagree with the second paragraph of msg 100 almost entirely. It's sure as hell not cheating your readers for two characters to be involved in an argument, and many arguments—at least, the ones that occur in real life—involve not constant interruption, but occasional pauses while a party tries to formulate an appropriate response. Negotiations over child custody in front of a judge are notorious for this, because there's so much emotion involved that blurting out complete thoughts leads to contempt citations. The "action" is rumination, not something that should ordinarily be considered "bad." Making that rumination explicit by getting inside of a character's head during an argument is at least as much "cheating the reader" if done for that purpose as giving no explanation, and letting the reader infer what's happening. If character development is consistent, that inference should not be much of a stretch.
All that the punctuation really means is that a character failed to complete a thought or sentence aloud. How (and whether) to state or imply the reason(s) is entirely up to the author, and entirely a matter of style, in a different sense than I think Jed used it above. Some editors may not like certain styles and usages, and may even reject works on that basis. That, however, is a matter of personal taste, not of "cheating your readers."
Message 102 was left by Timprov on 2002-01-05 10:11:00.
Oh, I don't suggest putting in the reasons, necessarily. But during any pause, things happen, particularly in a public setting. In a courtroom, people might shuffle papers, or cough, or whisper among themselves, or drop things, etc. etc. Using the description of such an event makes your pause much more vivid and powerful than an ellipsis does. It's cheating because you're including a large pause without the pacing of the story reflecting it.
Message 103 was left by Terry Hickman on 2002-01-05 11:59:00.
This is a *great* discussion, and one I sorely need. I have never "codified" how I use ellipses and/or em-dashes (I never even knew what to *call* the latter!) so I do need to dig into Strunk & White, Chicago, and whatever else help I can find. You've given me the inspiration to do that!
For the time being, though, may I ask a really dumb question? What's the *typing* drill for em-dashes?
1. SpokenWord[space]--"
2. SpokenWord--[space]"
3. NarrativeWord1--NarrativeWord2
4. NarrativeWord1[space]--NarrativeWord2
5. NarrativeWord1--[space]NarrativeWord2
6. NarrativeWord1[space]--[space]NarrativeWord2It makes a difference to me, because my WordPerfect seems to delight in cutting double-dashes in two at the end of a line, or putting the ending " at the beginning of a line all by itself. I haven't figured out how to make it stop doing that, so sometimes I end up putting extra spaces in, anything to make it come out right. Any advice on that point would be appreciated, also.
Message 105 was left by Timprov on 2002-01-05 12:22:00.
There's probably a "correct" typing drill, but I don't think people stick to it at all. The most common usages are 3 and 6. End-of-sentences come in your #1 and without any space. One thing that irritates me no end is the double-dash form, because while some fonts have a special character for it, most don't, and '--' looks really ugly. (That's more an issue in web publishing than print publishing.) Personally, as you can see in my posts, I use a single dash surrounded by spaces, which is non-typical but clear (and also the way I publish them). I imagine em-dash usage is probably one of the most common house stylesheet changes copyeditors have to deal with, so generally you're pretty safe with whatever the heck you feel like, and they'll change it to what they think is appropriate.
Message 106 was left by Willis Couvillier on 2002-01-05 13:37:00.
Humm, well, remind me to proofread anything I might submit to Speculon. I use the [space]--[space] more than I probably should; Word converts it automatically to -. I had to turn off the autoformat for that, when I started to eSubmit.
Will.
Message 107 was left by A. Freed on 2002-01-05 19:31:00.
Heh. Whereas I learned to use em-dashes as double-dashes, no space (like--this.) This from William Shunn's article on proper manuscript format.
Message 108 was left by Toiya K. Finley on 2002-01-05 19:53:00.
Re: 107: I think "--" is ugly too, but the reason Shunn's article called it proper manuscript format is because the "--" is easier to find in a ms than "—". "—" is easy to gloss over and may look like an en-dash (single dash) when copyeditors/layout editors are combing the ms. Same deal as underlining instead of italicizinig. I've seen #3, and #6, as well as [space]-[space], as Timprov mentioned, and they all work. Whatever form you choose, make sure that it's obvious to whomever's doing the layout that you intend for an em-dash to be there.
A quick keystroke for the em-dash "—" in place of "--" is [NumLck] + [Alt] + 0151.
Message 109 was left by Timprov on 2002-01-06 01:44:00.
Will (and anybody else), it's probably best just to submit it as you had it. The copyediting thing applies to me as well; double-dashes annoy me in copyediting (because I always miss one or six on the first pass), but they don't have any bearing on ms. consideration.
Message 110 was left by Timprov on 2002-01-06 01:56:00.
As for them being ugly; I really don't care about them being ugly in ms. form. And in layout for print publishing, they're converted into a long-dash character, so they're not ugly when they're actually published. We web publishers don't really have that luxury (because people can override our font choices, some font makers decided that em-dashes weren't important, and "—" and "-" aren't nearly as distinguishable in most standard web fonts as they are in print) so we have to find some other way around it. A lot of web publishers have just gone to using "--", which is what annoys the heck out of me.
In print, I like to have spaces around the em-dash character; but that's a whole 'nother argument.
Message 112 was left by Terry Hickman on 2002-01-06 10:58:00.
Thanks for all your input, Timprov & TKF. So I guess I just pick on e*I* like and use it consistently in my own work, and let editors mess with it as they like. OK!
Message 116 was left by Jed Hartman on 2002-01-07 01:32:00.
Here's the scoop on em dashes and typography: An em dash in typeset material should not, traditionally, have a space on either side of it. (Some publishers do put spaces around em dashes, but most don't. I consider both to be valid choices, but I prefer no spaces except in certain typefaces.) But until recently, typeset material was set from typewritten manuscripts, and typewriters used monospace typefaces, so there was no clear way to distinguish an em dash from a hyphen by looking at it (a capital M is the same width as a lowercase i in a monospace font). So it became customary to use two hyphens to represent an em dash in a typewritten manuscript; typesetters would then replace the hyphens with an em dash.
For reasons that I'm unclear on, in typewritten manuscripts a double hyphen is traditionally surrounded by spaces, except when it comes at the end of an interrupted line (as of dialogue):
NarrativeWord[space]--[space]NarrativeWord
...DialogueWord--"
With the advent of desktop publishing in the mid-'80s, everything got confused. People knew the traditional conventions for typewritten material, but didn't know that those were originally intended as ways to represent typeset material using a typewriter. (Much like trying to use ASCII to represent various things that ASCII doesn't include, like _underscores_ to represent underlining in a typewritten manuscript, which in turn represents italics in a typeset document.) Books like The Mac Is Not a Typewriter were written to help people create desktop-published documents that looked typeset.
And that was all fine and dandy until, as Timprov noted, the Web came along. Until fairly recently, there was no way to represent an em dash in an HTML document that you could be sure would be viewed properly in all browsers.
There was a fancy trick using a single-pixel GIF and alt text that David Siegel recommended; I used that for years in my online words-and-wordplay column, now sadly defunct due to lack of time. At SH, we use the typewriter approach ("[space]--[space]" in most cases). In my own Web pages, I use the HTML entity — (ampersandpound151semicolon), which now shows up properly in all modern browsers that I've tried (including Lynx, which was previously the last holdout), but we haven't yet switched over to using that at SH. An article at alistapart (I think it's not that article but another one linked from it) claims that #151 is not a valid HTML entity, and recommended using #8212 instead; that too has worked in every browser I've tried. (Unfortunately, the HTML symbolic entity named mdash is not widely supported.) With such em-dash characters, you don't put spaces on either side, just like with traditional typeset material. (Unless, of course, you're a publisher who likes having spaces on either side of an em dash.)
As for avoiding breaking lines in a word processor when typing a double hyphen, some word processors allow you to enter a "nonbreaking hyphen" character; if your word processor provides such a character, you should definitely use it in all your double hyphens. I also recommend using a nonbreaking space before the double hyphen to avoid starting a line of text (or a page) with a double hyphen (or with an em dash if you put spaces around your em dashes).
All of that said, though, I suspect Timprov's right that editors aren't likely to care much about what exact format you use. Traditional-minded editors may expect you to use traditional manuscript format (the double-hyphen approach discussed above), and I suspect it's easier on the typesetter (if you're submitting to someone who still sets type from hardcopy) if you use a double hyphen to make clear that what you want is an em dash, but I suspect most editors will figure out what you mean in most cases.
The one thing I'd strongly recommend avoiding is using a single hyphen with no spaces around it-like this-as an em dash.
Message 117 was left by Jed Hartman on 2002-01-07 01:34:00.
...Of course, the remaining drawback to using an HTML numeric entity for an em dash is that if you're using a monospace font, as is generally used to display the tt tag that the Rumor Mill puts around postings, you'll get a monospace "em dash" that looks like a hyphen... But most people aren't reading most of the Web in monospace fonts.
Message 118 was left by Timprov on 2002-01-07 05:55:00.
Unfortunately, while current versions of Lynx may support em-dashes, older versions don't (and don't substitute anything, they simply don't display the character), and Lynx users don't have the upgrade pressure IE and Netscape users do. Also, Lynx has, at least to the point of the version I have access to, always used a monospace font.
Message 119 was left by John Savage on 2002-01-07 10:43:00.
I just checked the W3C definitions, and — is indeed a correct HTML entity for an em-dash. It is not correct, however, in Unicode, which defines all characters with four Arabic numerals (hence —).
As an aside, here are two other seriously annoying typography issues for e-publishers. I've made a couple of determinations for my use, but there is simply no standard.
(1) Quotation marks (whether single or double). Typographically, an opening quotation mark is distinct from a closing quotation mark. Most word processors that use "smart quotes" (the default, for example, in Word97 and later) will automatically make this change, and pretty accurately too. HTML, however, will not. The " entity does not substitute typographical quotation marks; instead, one must choose Unicode characters. Unfortunately, many typefaces do not have the proper Unicode characters, so we end up with Courier-style ichor. As far as writers are concerned, it really makes no difference whatsoever whether mss have "smart" or "dumb" quotation marks, unless the editor is in the habit of publishing the ms as is!
(2) Representing ellipsis is an unfortunately insoluble problem, largely due to stupid font design. First of all, writers, it is not proper to put spaces between the periods in an ellipsis; it should look like ..., not . . .. Second, learn the difference between a three- and a four-dot ellipsis, and when the ellipsis is brought up to the preceding or trailing end of a phrase (or, in some cases, neither!)—your typesetter will thank you.
The real problem with ellipsis, though, is whether to use three periods (which risks breaking an ellipsis over a line break) or a single-character entity… like … at the end of the preceding phrase. All modern word processors support the latter, and it's also supported in Unicode and extended ASCII. However, that support is (to use the technical term) butt-ugly: it's invariably too narrow in commonly used typefaces. One solution is a "virtual entity," such as . . ., but this causes problems with some browsers (especially for those not using a US-ASCII default). Here's a plea for web-font designers to expand the three-dot ellipsis to a reasonable width, probably two ems (and at least 1.5 ems).
Message 123 was left by Jed Hartman on 2002-01-08 01:31:00.
Re Lynx: the older versions of Lynx that I'd seen display #151; as a hyphen, while the newer ones display it as a double hyphen (which I thought was awfully clever of the newer versions). I'm certainly in favor of being accessible to Lynx users where possible (especially 'cause doing so is generally good practice for other accessibility issues), but I think for my own pages I draw the line at trying to support old versions of Lynx; agreed that there isn't the pressure to upgrade, but I think the percentages still get small enough for me to be willing to give them a less-than-ideal experience. (But that's not an SH policy; we're still using double hyphens there.)
Thanks for the explanation re Unicode, John; I hadn't caught that distinction (or maybe just hadn't remembered it), but now that you mention it, it makes sense.
Good point re "smart" quotes, too. Our text-to-HTML conversion script converts all known curly-quote characters to straight quotes, but it sure would be cool if there was enough browser support for curly quotation marks to be able to use them easily. Most recent browsers do support the numeric entities (both Unicode and HTML) for curly quotes, but they're a pain to use nicely when creating HTML, and there's always the legacy-browser-support issue.
As for dot-dot-dot: Chicago says to use three-to-em spaces between the dots, so we at SH have actually been using the . . . format you mentioned. I'm sorry to hear that it doesn't work well in some browsers, though; can you tell me more about how it looks in non-US-ASCII? (Feel free to send it to me in email if you like; I feel a bit like I'm hijacking this topic into technical details of Web publishing, which I find fascinating but may not really be relevant to the editing topic.)
Well, okay, since I'm on the subject anyway, I'll mention one other thing about Web formatting: Jim Kelly noted in an early "On the Web" column that he finds block paragraphs with blank lines between them very hard to read. He wants indented paragraphs in Web browsers. I tried some mockups, and they looked terrible, but A List Apart (http://www.alistapart.com/stories/typography/) has a style sheet that makes them look (to me) very attractive in browsers that support CSS, and reverts to regular block paragraphs for browsers that don't. I like that approach a whole heck of a lot, but I don't know enough CSS yet to be able to replicate it (or even understand their stylesheet). But at some point I think it'd be cool to switch to that approach.
==========================================================================================