Re: <q> vs <p>

2008/10/31 Philip TAYLOR (Ret'd) <>

> Are we not, once again, beating ourselves over the
> head with a problem that would not even exist if
> HTML 5 were not required to be backwards-compatible ?

No we are not: regardless of whether the <q> element is
backwards-compatible, there is still the question of what to do with it.
Unless, that is, you're suggesting a much greater lack of backwards
compatibility than I, for one, would find acceptable.

> If browsers (user agents, if you prefer) were to have
> an HTML 5 mode of operation and a legacy mode of
> operation, this and many many analogous problems
> would immediately disappear.

But lots of new and arguably nastier problems would appear; this has been
discussed elsewhere.

> HTML 5 could, for
> example, mandate that <q> ... </q> will insert
> "appropriate" quotation marks, thereby making
> both
>        "<q> ... </q>"
>                and
>        <q>" ... "</q>
> deprecated,

Well, the second option there was never conformant, so it doesn't make sense
to mark it as deprecated. The first option wasn't advised or, really,
mentioned at all in HTML 4.x, so it doesn't make sense to mark that
deprecated either (there's nothing to mark).

> or equally it could mandate that <q>
> ... <q> will do no such thing, thereby freeing
> authors to punctuate their quotations as they wish.

Authors are already free to punctuate their quotations as they wish, and
they still would be under the proposals I've outlined in other current
threads on the topic of <q>. Please could you read those proposals?

> One could even add a <quote> element which provided
> the opposite behaviour, and authors could then
> elect which to use based in their own peronal
> preferences regarding explicit v. implicit
> quotation marks.
> The situation with legacy documents would then become
> a very simple one : a statistical analysis would
> indicate whether there is already a marked bias in
> such documents towards explicit or implicit
> punctuation,

Seriously? No automated statistical analysis I know of is capable of doing
that reliably, so unless you're willing to employ a *really* huge, i8n-aware
team of well-trained workers to oversee this and ensure reliability, I don't
think it's a practical suggestion.

> and the legacy mode of operation then
> defined to produce optimal results for whichever
> group predominates.

Leaving the rest to render wrongly, presumably.

I sure wouldn't be happy to have a "legacy" mode implemented in browsers
which would potentially apply an inappropriate rendering algorithm to 49% of
the existing Web.


Received on Friday, 31 October 2008 14:05:54 UTC