2008/10/26 Lachlan Hunt <lachlan.hunt@lachy.id.au> > The better solution is simply to give up on the <q> element, which doesn't > seem to have any significant use cases beyond automatic quoting, and just > require the author to type the appropriate quotation marks. > A use case I've experienced is when an editorial decision is made to change all quotes on a site from being single quotes on the first level of nesting to double quotes on the next level, etc, to the other way around - double on the outside, single on the next level in, etc. This is a royal PITA to change without the <q> element. I think that if the <q> element is implemented properly, it will allow authors who want to use it (e.g. me) to separate presentation from content in a manner that would otherwise be an ugly kludge (e.g. using <span> elements instead, and overriding their presentation with CSS rules or Javascript to make them behave like <q> elements - hardly an accessibility-friendly solution). > This is what authors already do today given the limited support for <q> in > some browsers, > That doesn't mean it's good! If browser support was there, some developers would certainly make use of it. Look around various forums & mailing lists, and you'll see people asking, "How do I make the <q> element work properly?" - and it's not their fault it doesn't: it's the fault of the UAs' broken implementations of it. > and there doesn't really seem to be any problems worth solving for which > <q> is an appropriate solution. > See my example above. Regards, SamReceived on Saturday, 25 October 2008 23:42:08 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:32:42 GMT