Which should I use? The <q> element or double quotes when I'm writing a story with dialogue? The reason I thought of using <q> is so that I can "style" it for audio browsers and screen readers.<br />
<br />
BTW, the reason I used parentheses is because I can't use "<" in the title.<!--content-->This accessify forum thread (<!-- m --><a class="postlink" href="http://www.accessifyforum.com/viewtopic.php?t=269&highlight=quotation">http://www.accessifyforum.com/viewtopic ... =quotation</a><!-- m -->) offers some guidance. I have some sympathy with brothercake's viewpoint - <q> is semantically correct. OTOH, I am concerned about the lack of support by IE (I wonder if IE7 still suffers). For that reason, bearing in mind the gez post about JAWS 4.51, I would probably use "<br />
<br />
I'll be interested to see what others think, though.<!--content-->I think I'll be using <q>" "</q> for semantic reasons. If IE7 can deal with :before and :after pseudo-elements, the possibility for fun will increase. As it is, I can use this rule:<br />
<br />
q:before, q:after{<br />
content:"";<br />
}<br />
<br />
Which is basically empty content.<!--content-->That's the one construction that you don't want to use. The only real way out of this hole that MSIE has dug for us is a server side sniff. Give MSIE it's own Q element free version.<!--content-->I've just checked (should have done so before I posted above) IE7 still does not support <q>.<!--content-->IE7 still does not support <q>.Why am I not surprised?<br />
<br />
And is it worth even bothering to check if they bothered to support ABBR?<!--content-->That's the one construction that you don't want to use.Are you saying there is something horribly wrong with this?<q style="quotes: none;">"hello"</q>If so, what?<br />
<br />
Oh, and IE7 does support <q> in that it recognises it and doesn't go into quirks mode when it sees it. It just fails to do anything about it. Same with IE6.<!--content-->Are you saying there is something horribly wrong with this?<q style="quotes: none;">"hello"</q>If so, what?I'm certain that I remember reading something about it in the W3C documents. I tried a quick search, though, and came up empty. But we really don't want to see those ""funny doubled double quotes"".Oh, and IE7 does support <q> in that it recognizes it and doesn't go into quirks mode when it sees it. It just fails to do anything about it. Same with IE6.That's not what I call "support".<!--content-->I'm certain that I remember reading something about it in the W3C documents. I tried a quick search, though, and came up empty. But we really don't want to see those ""funny doubled double quotes""."Funny doubled double quotes" aren't great, although assuming that the other browsers are supporting the CSS you use properly then that shouldn't be too much of an issue and Browser Sniffing Isn't Great Either (<!-- m --><a class="postlink" href="http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages#Browser_identification_approach_.28aka_.22browser_sniffing.22">http://developer.mozilla.org/en/docs/Us ... niffing.22</a><!-- m -->. 29:_not_best.2C_not_reliable_approach), maybe its a case of striking a balance and identifying the lesser of to evils.That's not what I call "support".Me neither, but really, what IE is not supporting is the quotes or content styles. You can still apply other styles to a Q element, if you wanted your quotes highlighted and in bold for some reason, for instance.<!--content-->Why am I not surprised?<br />
<br />
And is it worth even bothering to check if they bothered to support ABBR?<br />
<br />
IE7 does support <abbr><br />
<br />
eg<br />
<abbr title="United Nations">UN</abbr><br />
results in the tooltip "United Nations" when the mouse pointer is hovered over "UN".<!--content-->In other words, it's back to a mirrored site? One for IE, one for browsers?<br />
<br />
BTW, when I use that rule, it does work. content:""; means "don't show anything in the specified place". IE doesn't support this rule, but it doesn't support <q> either, so it all works out.<br />
<br />
Here's to Bill Gates' Intestinal Sculpture for the Internet.<!--content-->so it all works outNot exactly:From the WCAG 1.0<br />
6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.<br />
<!-- m --><a class="postlink" href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-order-style-sheets">http://www.w3.org/TR/WAI-WEBCONTENT/wai ... yle-sheets</a><!-- m --><!--content-->Hm. Point. I guess I shouldn't use <q> after all...<br />
<br />
Is <q> phased out in XHTML 2.0?<!--content-->For that reason, bearing in mind the gez post about JAWS 4.51, I would probably use "<br />
Does anyone know how a screen reader will deal with that?<!--content-->Does anyone know how a screen reader will deal with that?If it's following the rules then there is absolutely no reason why it would treat it any differently from a ".<!--content-->If it's following the rules then there is absolutely no reason why it would treat it any differently from a ".<br />
Heh, I suppose I should clarify that I don't know how it would treat a " either. What I mean is, if a screen reader encounters " (or "), what does it do? Does it announce "quote"?<!--content-->Heh, I suppose I should clarify that I don't know how it would treat a " either. What I mean is, if a screen reader encounters " (or "), what does it do? Does it announce "quote"?<br />
Referring back to that accessify forum thread I mentioned earlier, according to gez (<!-- m --><a class="postlink" href="http://www.accessifyforum.com/viewtopic.php?p=1527#1527">http://www.accessifyforum.com/viewtopic.php?p=1527#1527</a><!-- m -->) a user may hear "quote" or not - depending on which screen reader is being used.<!--content-->Okay, Charles, I shall rely on your excellent advice for the final answer. <q> or "?<!--content-->Server side sniff for that foul air that wafts from Redmond, WA.<!--content-->To make page coding easier, I'd like to go with one or the other. It's a BIG story I'm writing.<!--content-->I've given up on the Q element for now, but if I hadn't then I would do the whole thing in XHTML marked up just the way it's supposed to be. Then I would use some XSLT stylesheets to transform to the two HTML versions. And I would toss into the mix a nice, printer friendly, PDF version.<!--content-->I'm using HTML 4.01. As for PDF... *Glares, bares claws.* SMILE when you say that! *Detests online PDFs*<!--content-->UPDATE:<br />
<br />
I've stopped using <q> altogether in my story, as I would have had something like this in my CSS:<br />
<br />
<br />
q:before{<br />
content:""";<br />
}<br />
q:after{<br />
content:""";<br />
}<br />
q:before.thought{<br />
content:".o0(";<br />
}<br />
q:after.thought{<br />
content:")";<br />
}<br />
q:before.Smilodon{<br />
content:"[";<br />
}<br />
q:after.Smilodon{<br />
content:"]";<br />
}<br />
<br />
<br />
And in my story, I'd be using stuff like<br />
<br />
<q>Yapyapyap</q><br />
<q class="thought">Lost in thought</q><br />
<q class="Smilodon">Growlsnarl</q><br />
<br />
In short, a lot of extra typing.<!--content-->
<br />
BTW, the reason I used parentheses is because I can't use "<" in the title.<!--content-->This accessify forum thread (<!-- m --><a class="postlink" href="http://www.accessifyforum.com/viewtopic.php?t=269&highlight=quotation">http://www.accessifyforum.com/viewtopic ... =quotation</a><!-- m -->) offers some guidance. I have some sympathy with brothercake's viewpoint - <q> is semantically correct. OTOH, I am concerned about the lack of support by IE (I wonder if IE7 still suffers). For that reason, bearing in mind the gez post about JAWS 4.51, I would probably use "<br />
<br />
I'll be interested to see what others think, though.<!--content-->I think I'll be using <q>" "</q> for semantic reasons. If IE7 can deal with :before and :after pseudo-elements, the possibility for fun will increase. As it is, I can use this rule:<br />
<br />
q:before, q:after{<br />
content:"";<br />
}<br />
<br />
Which is basically empty content.<!--content-->That's the one construction that you don't want to use. The only real way out of this hole that MSIE has dug for us is a server side sniff. Give MSIE it's own Q element free version.<!--content-->I've just checked (should have done so before I posted above) IE7 still does not support <q>.<!--content-->IE7 still does not support <q>.Why am I not surprised?<br />
<br />
And is it worth even bothering to check if they bothered to support ABBR?<!--content-->That's the one construction that you don't want to use.Are you saying there is something horribly wrong with this?<q style="quotes: none;">"hello"</q>If so, what?<br />
<br />
Oh, and IE7 does support <q> in that it recognises it and doesn't go into quirks mode when it sees it. It just fails to do anything about it. Same with IE6.<!--content-->Are you saying there is something horribly wrong with this?<q style="quotes: none;">"hello"</q>If so, what?I'm certain that I remember reading something about it in the W3C documents. I tried a quick search, though, and came up empty. But we really don't want to see those ""funny doubled double quotes"".Oh, and IE7 does support <q> in that it recognizes it and doesn't go into quirks mode when it sees it. It just fails to do anything about it. Same with IE6.That's not what I call "support".<!--content-->I'm certain that I remember reading something about it in the W3C documents. I tried a quick search, though, and came up empty. But we really don't want to see those ""funny doubled double quotes""."Funny doubled double quotes" aren't great, although assuming that the other browsers are supporting the CSS you use properly then that shouldn't be too much of an issue and Browser Sniffing Isn't Great Either (<!-- m --><a class="postlink" href="http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages#Browser_identification_approach_.28aka_.22browser_sniffing.22">http://developer.mozilla.org/en/docs/Us ... niffing.22</a><!-- m -->. 29:_not_best.2C_not_reliable_approach), maybe its a case of striking a balance and identifying the lesser of to evils.That's not what I call "support".Me neither, but really, what IE is not supporting is the quotes or content styles. You can still apply other styles to a Q element, if you wanted your quotes highlighted and in bold for some reason, for instance.<!--content-->Why am I not surprised?<br />
<br />
And is it worth even bothering to check if they bothered to support ABBR?<br />
<br />
IE7 does support <abbr><br />
<br />
eg<br />
<abbr title="United Nations">UN</abbr><br />
results in the tooltip "United Nations" when the mouse pointer is hovered over "UN".<!--content-->In other words, it's back to a mirrored site? One for IE, one for browsers?<br />
<br />
BTW, when I use that rule, it does work. content:""; means "don't show anything in the specified place". IE doesn't support this rule, but it doesn't support <q> either, so it all works out.<br />
<br />
Here's to Bill Gates' Intestinal Sculpture for the Internet.<!--content-->so it all works outNot exactly:From the WCAG 1.0<br />
6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.<br />
<!-- m --><a class="postlink" href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-order-style-sheets">http://www.w3.org/TR/WAI-WEBCONTENT/wai ... yle-sheets</a><!-- m --><!--content-->Hm. Point. I guess I shouldn't use <q> after all...<br />
<br />
Is <q> phased out in XHTML 2.0?<!--content-->For that reason, bearing in mind the gez post about JAWS 4.51, I would probably use "<br />
Does anyone know how a screen reader will deal with that?<!--content-->Does anyone know how a screen reader will deal with that?If it's following the rules then there is absolutely no reason why it would treat it any differently from a ".<!--content-->If it's following the rules then there is absolutely no reason why it would treat it any differently from a ".<br />
Heh, I suppose I should clarify that I don't know how it would treat a " either. What I mean is, if a screen reader encounters " (or "), what does it do? Does it announce "quote"?<!--content-->Heh, I suppose I should clarify that I don't know how it would treat a " either. What I mean is, if a screen reader encounters " (or "), what does it do? Does it announce "quote"?<br />
Referring back to that accessify forum thread I mentioned earlier, according to gez (<!-- m --><a class="postlink" href="http://www.accessifyforum.com/viewtopic.php?p=1527#1527">http://www.accessifyforum.com/viewtopic.php?p=1527#1527</a><!-- m -->) a user may hear "quote" or not - depending on which screen reader is being used.<!--content-->Okay, Charles, I shall rely on your excellent advice for the final answer. <q> or "?<!--content-->Server side sniff for that foul air that wafts from Redmond, WA.<!--content-->To make page coding easier, I'd like to go with one or the other. It's a BIG story I'm writing.<!--content-->I've given up on the Q element for now, but if I hadn't then I would do the whole thing in XHTML marked up just the way it's supposed to be. Then I would use some XSLT stylesheets to transform to the two HTML versions. And I would toss into the mix a nice, printer friendly, PDF version.<!--content-->I'm using HTML 4.01. As for PDF... *Glares, bares claws.* SMILE when you say that! *Detests online PDFs*<!--content-->UPDATE:<br />
<br />
I've stopped using <q> altogether in my story, as I would have had something like this in my CSS:<br />
<br />
<br />
q:before{<br />
content:""";<br />
}<br />
q:after{<br />
content:""";<br />
}<br />
q:before.thought{<br />
content:".o0(";<br />
}<br />
q:after.thought{<br />
content:")";<br />
}<br />
q:before.Smilodon{<br />
content:"[";<br />
}<br />
q:after.Smilodon{<br />
content:"]";<br />
}<br />
<br />
<br />
And in my story, I'd be using stuff like<br />
<br />
<q>Yapyapyap</q><br />
<q class="thought">Lost in thought</q><br />
<q class="Smilodon">Growlsnarl</q><br />
<br />
In short, a lot of extra typing.<!--content-->