Yahia <cyahia@gmail.com> wrote:
>> q:before{content:""}
>> q:after{content:""}
>>
>> which gets rid of the generated quotes in Opera and Mozilla, and then
>> maintain the quotes as part of the content proper.
>>
>
>OK, but what about the case when documents are viewed with CSS turned off.
>What about when the document is viewed on Lynx which adds quotations marks
>around <q/> and doesn't support CSS?
>Although it might be the only solution, I think it isn't a very elegant
>one.
As practical hacks go I personally wouldn't consider 2 quote characters
in Lynx as an issue to be concerned about. I do consider 2 quote
characters with CSS disabled in Opera or Mozilla as a drawback with
practical significance. How Konqueror and Safari handle the construct
should also be considered.
>(The ultimate would be to not use <q/> at all, which is in practice.)
Given the points you pointed out that might be the best practical choice
given that I cannot construct a use case where <q> markup serves a
practical purpose. A quick test with 2 AT UAs suggests that
Window Eyes + IE6 or FF2 ignores <q> markup and also quotes that are
part of the content proper, Jaws + IE6 ignores <q> markup but it reads
out quotes that are part of the content proper (both ascii and "real"
quotes).
>I agree with you on the fact that the conception of <q/> in the HTML spec
>is ill-designed, but waiting for XHTML2 to be finished, and wait for it to
>be implemented, is not what we are actually looking for.
IMO XHTML2 will never see implementation in a web browser. A quick
glance at the Web Application 1.0 spec suggests that the HTML4
requirement that a UA must generate quote characters around content
marked up with the <q> element has been dropped. IMO WA1 stands a good
chance of being implemented, although if it is, WA1 doesn't require
implementers /not/ to generate quote characters around <q> content.
--
Spartanicus