RE: <q>

I've consolidated responses to Robert Burns in this message...

> > I could not agree more. Simply put, quotation marks are either
> > content or they are presentation; the original <q> proposal seeks to
> > use a semantic element to control presentation in order to
> > compensate with a conundrum with people's content.
> 
> I cannot see how you're thinking of the q element here. The q element
> semantically demotes a quotation regardless of how it gets presented.
> That is the proper separation of concerns. The fact that quotations
> are often presented (and distinguished from non-quotations) by
> surrounding them with quotation marks is only one possible
> presentation of a quotation. Another presentation of a quotation is to
> mark is with a horizontal bar and change the color of the text (as my
> email client presents the quotations above). Another way is to set off
> quotations as indented blocks. These are the various ways to present
> quotations, but that doesn't make the quotations or the q element
> presentational.

The <q> element as presented a few days ago is, apparently, supposed to
generate "magic quotes" around its contents. Therefore, that makes it an
element which is both semantic (by indicating a quote) and presentational in
a truly unique way (by invisibly inserting HTML entities into the
presentation).

> So the quotation element is an important and I think indispensable
> part of HTML. With the latest release of IE, the necessary CSS is in
> place to support stylesheet based presentation of q element (now in
> all major browsers). However, Chris also proposed a great solution to
> the incompatibility problems we've been plagued with here that also
> provides a way forward for IE and other browsers. By advising UAs to
> intelligently NOT insert quotation marks even when the specifies it it:
> 
> 1) the q element is already surrounding by quotations marks or
> (ignoring adjacent whitespace)
> 2) the quotations marks already begin the q element (ignoring adjacent
> whitespace)
> 
> I think this solution is brilliant (though should probably be
> something for CSS to incorporate more so than HTML5, perhaps even with
> new before:: after:: contingent properties).

This feels like a trainwreck to me. It may be brilliant in some senses, but
it certainly increases complexity around the <q> tag significantly. It goes
from being a few lines of code to parse it and note its contents as a
quotation, to a few dozen lines of code (just a guess) to 100% handle all of
the various edges, error handling, etc. That's a LOT of additional
complexity. Yes, it (hopefully) compensates for sloppy authoring. I would
love to hear from someone on, say, the Microsoft Word team and ask them how
many SLOC it took to write Word's "smart quotes" feature, and how long it
took to write it and troubleshoot it and design it.

> In addition I think we should provide authors the ability to
> explicitly distinguish the semantics of their quotation elements as I
> earlier proposed[1][2][3]. By adding a 'marks' attribute taking the
> values 'provided' or 'needed', authors can indicate that the quotation
> marks should not be added by stylesheets. By treating the default
> value of this attribute as "needed" it provides authors the most
> compact syntax to markup quotations (leaving off the attribute and the
> quotations marks). It also makes HTML5 a compatible superset of
> HTML4.01 with respect to this issue. Supplementing this with Chris's
> suggestion to intelligently omit stylesheet rule quotations marks (if
> redundant) would round out he issue very nicely.

This is even more complexity. I agree that if we want <q> to provide magic
quotes, that this is needed.

> >  Again, if <q> adds punctuation, so should <p> and any other element
> > which represents grammar.
> 
> You keep repeating this analogy, without recognizing that it goes
> completely against what you're saying. The p element DOES add
> punctuation in the same way that the q elements adds punctuation. The
> following HTML:
> 
> <p>here is a paragraph.</p><p>And that paragraph is followed by
> another paragraph.</p>
> 
> will be rendered
> 
> here is a paragraph.
> 
> And that paragraph is followed by another paragraph.

Incorrect. You are talking about what *happens to be the default
presentation of every Web browser*. You are not talking about what the HTML
specification says. My argument against <q> automatically inserting
quotation marks is a direct reaction to what people are asking that the HTML
specification say, and what it actually says in 4.X. That is a world of
difference.

The major difference between <p> and <q>, which is why I use the example, is
that HTML 5 does *not* specify that <p> have the line breaks. As you say,
the line breaks are presentational only, to assist the human reader to
understand that there are paragraphs. If someone were to tell me that the
HTML spec specifically stated a particular presentation for <p>, I would
tell them that it needs to go as well.

> In both cases - paragraph (P) and quotation (Q) - the author is
> responsible for inserting the genuine semantic and non-presentational
> punctuation (commas, periods, sentence capitalization, etc.).

Maybe it is the part of me that never "got" the concept of a gerund or a
past participle, but I think that this discussion is getting a bit too
involved with some extremely minute concepts around the grammar of the
English language, and ignoring the big picture.

Why should <q> generate punctuation marks when no other HTML tag (to the
best of my knowledge) does so? OK, so there is some small benefit to people
who have multiple levels of nested quotes. So what?

The real problem that we are facing here, is that HTML 4 did a really poor
job at defining <q>. It overreached and tried to cobble together this idea
of magical punctuation generation, which was then not implemented by all
major browsers. As a result, what should have been a useful semantic tag
became mired in confusion. Now, we're dealing with the aftermath.

Personally, if someone wants to define <q> to work in this "generate
quotation marks" manner, fine. They can do it in CSS. Some people in this
conversation have suggested that this be in the "default CSS definition"
(which doesn't exist, and that is my phrase, not their phrase). That's not
going to happen, because it's already been made clear that HTML does not,
and will not, have a "default CSS definition".

So in reality, where is the discussion here? There is nothing to discuss. I
think that we all (you, me, Sam) agree that HTML specification should not
define this behavior, that it is better left to the CSS folks. Fine by me.
:) At that point, it means that what we do is:

* Keep <q> in HTML
* Redefine <q> to remove this idea of magic quotes
* Ping the CSS folks and ask them to take up this issue

Make sense?

J.Ja

Received on Wednesday, 29 October 2008 16:54:46 UTC