W3C home > Mailing lists > Public > public-html@w3.org > October 2008

Re: <q>

From: Sam Kuper <sam.kuper@uclmail.net>
Date: Sun, 26 Oct 2008 00:41:30 +0100
Message-ID: <4126b3450810251641r10b123a6q35a15c1049a88fc2@mail.gmail.com>
To: "HTML WG" <public-html@w3.org>
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.


Received on Saturday, 25 October 2008 23:42:08 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:38 UTC