Re: <q>

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,

Sam