Re: <q>

2008/10/25 Ben Boyle <benjamins.boyle@gmail.com>

> I prefer a more rigid application of the separation of concerns
> principle: start with grammatically correct (including punctuation)
> content, then apply the markup language.


It is *very* important that web authors should be able to mark up content
that is NOT grammatically correct. Otherwise tons of material could not be
put on the web (including many important historical documents, for
instance).


> The content should be correct
> with the markup removed. If it is dependent upon the markup for proper
> punctuation, this separation has not been achieved.


This is a seductive notion, and it would be convenient if it held true
generally. But it does not. Tabular content, for instance, doesn't make much
sense unless marked up as such, and neither does block-quoted content. What
is more, using the <q> element gives *greater* separation of concerns than
simply inserting a quotation mark, because it allows a web designer to
implement a global change in presentational style (e.g. using single quotes
by default and double quotes for nested quotes) simply by changing a CSS
rule or two.


Let me explain why I don't find q useful (why I think it could be
> deprecated).
>
> I could author this:
> <q lang="en">Hello world</q>
>
> And I could change the language:
> <q lang="fr">Hello world</q>
>

This is a very poor use case to pick. Changing the language of an element to
the incorrect language is not something authors should be doing: it's
mistaken practice. Alternatively, suppose you had had <q
lang="en">Bonjour</q> and needed to change that to <q lang="fr">Bonjour</q>,
that would still be a poor use case to pick, because it's not really an
HTML-authoring use case: it's a "fixing your badly marked up HTML" use case.
In other words, the responsibility for the difficulties faced in these two
use cases rests not with the spec but with the author who has been using the
wrong language for the content or vice versa.


> Thankfully, the q element is completely optional so there's nothing
> stopping me continuing to avoid using it. ;)


Yep, and inline styling is still possible too, so you can style every
element individually if that's how you want to spend your time!

Sam