Discuss: Long Live the Q Tag

by Stacey Cordoni

41

I’ll try to answer most of what’s been questioned or debated.

Chris Botman: Thank you for noting that relevant information. Jim Dalton touches on this in comment #28. Like Jim says, this fix encourages web authors to start using quotation mark entities with use of the Q element. Since including the quotation marks will most likely be expected by the author in XHTML 2, this fix works well in that direction.

Brent Royal-Gordon: A server-side solution can definitely be implemented. One like you mention, however, being as it removes the Q tags entirely from IE, will cause unsemantic markup. Likewise, since JAWS is designed for use in IE, it will also pose an accessibility issue. Once the page is processed and the Q tags are replaced with quotation marks, JAWS will no longer recognize that as a quote.

Paul: How ironic I didn’t find that article on my many scavenges for articles related to the Q element. I did write my first draft on July 15th though, and I see that one was published in August, so that’s why. Originally I came up with this idea on the DevShed Forums and I know that an avid poster, Gary Turner, posted an article of my findings on his web page soon thereafter and then it seems the idea started popping up here and there before my publication date on ALA.

Like Chris Ovenden mentions in comment #11, and as I mentioned in the article, IE7 most likely won’t support the Q element either. Not to mention, I would beg to differ that IE6 is a soon-to-be-obsolete browser, even when IE7 is released.

Mark: Yes, double quotation marks do appear in text-only browsers, browsers with CSS turned off, or if the CSS is overridden. Personally, I accept the double quotation marks in text-only browsers if it means my IE users get to see quotation marks (with still adhering to semantic markup and accessibility.) Not to mention, the number of people using IE versus text-only browsers is hugely significant.

Jack: It seems the Q element will be a never ending dispute by many, but I’m hoping to shed some insight on a simple solution – although not perfect, I believe it’s definitely worth using and I’m glad you agree.

Chris Ovenden: The Q element is neccessary for semantically correct markup and is also neccessary for screen readers. Screen readers do react differently to an open Q tag than to a left quotation mark. Also, quotation marks have many uses, they are not just used for quotations. Like Adrian D mentions in comment #16, quotation marks can be used for slang words, technical terms, book titles, song titles, etc.

How does this CSS hack not solve the problem? This fix does work – with a minor fall back of double quotation marks in text-only browsers, browsers with CSS turned off, or if the CSS is overridden.

Paul Armstrong: I must say I’m a bit confused with your comment. If you read the article correctly (and completely), you will have known that this fix works with screen readers as well as with JavaScript disabled browsers.

Al Lemieux: The Q element is neccessary for semantically correct markup and for screen readers.

Chris Hunt: My solution is to surround the Q tags with quotation mark entities and include a short CSS hack to remove the quotation marks set by the users browser. In my article, example number 5 does not mention anything about the CSS hack – so no, it is not one of the solutions I suggested not to use.

Mike Cherim: Thank you. Actually, if IE ever supports the :before/:after pseudo elements before providing support for the Q element, the fix still works. IE will act as the other browsers act now. However, you are right, if the Q element is supported before the :before/:after pseudo elements, double quotation marks will appear. According to the IEBlog, neither are yet on the agenda for being supported in IE7.

Steven Paulo: Yes, you are correct. No one knows when or which will be supported first, and I didn’t want to hold this article back until then because it’s quite useful now (and will be for some time since neither the Q element or :before/:after pseudo elements are currently on the agenda to be supported by IE7).

Brian LePore: Good Point.

Benjamin Hawkes-Lewis: First off, Thank you. You make some very valid points. Some of what was mentioned comes down to personal preference though. Every web author has different priorities and as written in the article, this fix works best for me and my priorities (and probably a bunch of other persons). I do not believe this technique is “chaotic” as you put it, nor do I believe including the quotation mark entities should be defined as polluting the semantics of the Q tag. A lot of what you list people to do is advocate for support of the element and other such things. Once supported, that’s all fine and dandy, but people still browsing with older browsers will have the same issue as we have now. Even when IE decides to support the Q element, this fix will still work and should be used until the older browsers are obsolete.

Josh Peters: I never said you couldn’t. As I mentioned in my article, I suggest a JavaScript fix to be a great secondary solution.

posted at 09:33 am on September 27, 2006 by Stacey Cordoni

42 Think of the screen reader developers

Stacey Cordoni observes:

Likewise, since JAWS is designed for use in IE, it will also pose an accessibility issue. Once the page is processed and the Q tags are replaced with quotation marks, JAWS will no longer recognize that as a quote.

Jaws 7.10 supports Firefox 1.5 too. But other than the “lang” attribute, how did you coax Jaws into announcing Q or using a different voice for Q? Like I say, I’ve failed miserably at that.

Screen readers do react differently to an open Q tag than to a left quotation mark.

Which other screen readers, and in what configuration, are you talking about here?

people still browsing with older browsers will have the same issue as we have now

If people serve XHTML 1.x, they should use application/xhtml+xml (see Ian Hickson’s arguments and W3C’s note ); if people use XHTML 2.0, they (probably) will be required to use application/xhtml+xml. Most browsers that can render application/xhtml+xml, and all browsers that make that support explicit in their default Accept header, have a partial implementation of Q that will serve as a usable fallback.

The XHTML 2.0 draft currently says that quotation punctuation should be added in the text or the stylesheet, and some punctuation cannot be added without CSS. If people start serving application/xhtml+xml, older browsers will need to be served HTML for the same resources. If we develop the algorithms to add quotation punctuation to Q now, we will be able to serve styled Q to XHTML browsers and serve in-text quotation punctuation around SPAN to HTML browsers. (Indeed we could be doing that already, but XHTML currently adds little advantage over HTML 4.01 unless you’re using SVG or MathML.)

I do not believe this technique is “chaotic�? as you put it

I should probably have explained that in addition to its failure to achieve its stated objectives (IMHO), it makes the task of parsing and representing web documents (even more) hopeless, since you do not declare whether you are using the Q element the way the specification says you must, or the way you would prefer. If people start using this technique, how are screen readers supposed to react to Q and quotation punctuation? If they announce Q and read punctuation, that will work great for people who have used Q as per the specification; but users will have to listen to both on pages using your technique. But if they do not read punctuation then users will not know what is a quotation on most web pages, which do not use Q at all. So your technique actually reduces the already small incentive screen reader developers have to support Q. The very existence of this article, let alone the use of the technique, contributes to the wholesale confusion about Q (e.g. on MSDN) that I for one have been trying to combat. This is why I think it adds to the chaos that is already out there.

nor do I believe including the quotation mark entities should be defined as polluting the semantics of the Q tag.

Just to clarify a little, my line about pollution was not referring to your technique, but to people placing content or punctuation inside the Q element that was not in the source material. (The example currently serving for the XHTML 2 draft is another example of such pollution. I hope to get that changed.)

But I would argue that your technique corrupts your markup. What do you think quotation punctuation means? What do you think the Q element means? Now what do you think it means when you put them together? I think it means (if anything) a quotation in a quotation, or maybe a quotation in an article title.

If you do not wish to use HTML as per the specification, perhaps you should define a custom DTD, explain how user agents should treat documents of that type, and employ that for your documents instead. That way user agents and automated agents can know for certain how to interpret Q. Such practice is supported under the umbrella of RFC 2854 . If you balk at that, perhaps you can come up with a metadata profile or something for HTML that will at least signal that you’re using Q incorrectly.

posted at 11:54 am on September 27, 2006 by Benjamin Hawkes-Lewis

43 Untitled

Firstly I’d like to congratulate Benjamin Hawkes-Lewis for his well-written and intellectual posts. Secondly, in response to Stacey Cordoni’s comment “…quotation marks can be used for slang words, technical terms, book titles, song titles, etc.” isn’t the CITE tag meant for titles, and the DEF tag meant for technical terms? Let’s not forget the VAR tag too when dealing with code. Otherwise a SPAN is the best bet.

posted at 12:39 pm on September 27, 2006 by Chris Hester

44 Correction

Oops, I meant the DFN tag there.

posted at 12:40 pm on September 27, 2006 by Chris Hester

45 no-open-quote

Firefox sometimes miscalculates the width needed for a <q>quoted text</q> when you use

q:before, q:after { content: “”;
}

So I have seen italic quoted text with a length of two lines or longer to overflow its container. The fix is:

/* fallback for Safari 2.0 */
q:before, q:after { content: “”;
}

/* for browsers with better CSS 2 support */
q:before {
content: no-open-quote;
}
q:after {
content: no-close-quote;
}

posted at 12:44 pm on September 27, 2006 by Martin Kliehm

46 Re: no-open-quote

Oops, Textile ate my CSS comments…

// fallback for Safari 2.0

q:before, q:after { content: �?�?; }

// for browsers with better CSS 2 support

q:before { content: no-open-quote; }

q:after { content: no-close-quote; }

posted at 12:49 pm on September 27, 2006 by Martin Kliehm

47 Conditional comments

What is the advantage of this solution compared to placing conditional comments around the q element? If you use the following code, all problems are solved without css and polluting markup, right?

If future IE versions still don’t support the q element you will have to ajust all conditional comments, but that is the only disadvantage I can think of.

posted at 03:25 pm on September 27, 2006 by Niels Sijm

48 Untitled

I’m very uneasy about using generated content to add punctuation to a document. Punctuation is part of the text, giving it structure and meaning. So I don’t like the idea of adding it via CSS, which is meant for decoration and styling. Imagine, for example, if you removed all of the capital letters and full stops from this article, then added them via CSS. You would have removed a large part of the meaning from the text.

If you leave the quotation in your document, and use typographically correct punctuation, is there any need to use <q>? Surely, as others have pointed out, the semantic structure of the text is conveyed by the punctuation on its own. Punctuation is semantic markup!

There was a discussion of this recently on Accessify forum which might be useful.

Joe Clark’s book has a useful section on quotations too.

posted at 03:56 pm on September 27, 2006 by Jim O'Donnell

49 Safari and a question on JAWS/conditional comments

If people serve XHTML 1.x, they should use application/xhtml+xml (see Ian Hickson’s arguments and W3C’s note ); if people use XHTML 2.0, they (probably) will be required to use application/xhtml+xml. Most browsers that can render application/xhtml+xml, and all browsers that make that support explicit in their default Accept header, have a partial implementation of Q that will serve as a usable fallback.

For the record, it was my understanding that Safari does support application/xhtml+xml, but from my testing I have not seen it sent with the Accept header. Regardless, can someone please give their experience working with the q element in Safari?

When JAWS uses IE as its rendering engine shouldn’t it inherit IE’s conditional comments? If so, shouldn’t a behaviour to add quotes around a q element still be applied? I’ve read the comments here and understand that screen readers react different when the q element is there, but I am still confused as to what exactly that distinction is and how that is not a suitable replacement (beyond the requirement of JavaScript being enabled and semantic arguments about the placement of quotes in relation to the q element aside). Does this result in double quotes?

posted at 04:24 pm on September 27, 2006 by Brian LePore

50 Untitled

Readers may also be interested in reading Gez Lemon’s solution:
Fixing Quotes in Internet Explorer

Hopefully this will at least get quotes marked up in a useful way for the more recent browser/screen reader combinations. Of course, the downside is that it requires JavaScript.

posted at 05:16 pm on September 27, 2006 by Jon Gibbins