Re: <q>

2008/10/29 Justin James <j_james@mindspring.com>

> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of Sam Kuper
> 2008/10/29 Justin James <j_james@mindspring.com>
> >> 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.
> >
> > I do *not* agree. Again, please do not put words in my mouth.
>
> You have indeed stated that you want this to be defined as a CSS item.


Assuming that "this" means, "a W3C specification document (or fragment
thereof) defining how the <q> element in HTML 5 ought to be treated by UAs",
and that "a CSS item" means, "a task for the CSS WG", then, no, I haven't.


> So if I understand [you] correctly [*snip*], what you *really* want is:
>
> * <q> to be defined in HTML as simply, "denotes a quotation" or something
> similarly simple (I agree with this, by the way)


Not quite. I want <q> to be defined, under authoring requirements, as
denoting a quote, and defined for UA purposes as requiring a default
rendering that matches a set of defined rules (where the UA is technically
capable of implementing those rules) and approximates them in a useful
fashion otherwise (for UAs with strictly limited character sets like, say,
starburst LED displays[1]).


> * The creation of a default CSS styling sheet, in which <q> will be styled
> with quotes before and after


Again, not quite. I want the creation of a set of default styling rules
(preferably but not necessarily in a stylesheet format and preferably but
not necessarily in CSS). *If* this set of rules is expressed in CSS, then it
*may* use the :before and :after pseudo-elements, but I certainly wouldn't
propose *a priori* that it must use them (and certainly not for all
languages). Otherwise any languages (and there may be some) that express
quotes by, for instance, italicisation rather than with quote marks, could
end up being poorly served.


> * This default CSS sheet is to be defined and controlled by the people
> working on HTML, not CSS


Not necessarily. See my points above about CSS. As for who should do the
work, well, regardless of who does it I think the HTML WG would have to be
certain it met their requirements. Beyond that, I wouldn't mind who did it
as long as it got done on time and well.


> >> * Redefine <q> to remove this idea of magic quotes
> >
> > By "magic quotes", I believe you mean quotation marks generated by UAs
> upon encountering
> > <q> elements.* If so, then I do *not* agree <q> should be redefined to
> "remove the idea"
> > of them. I have stated my reasons for this in previous posts.
>
> Again, I think that your reasons are a real edge case. I just have not
> heard any clamor for quotation marks to appear by themselves, anywhere.


Ask yourself why HTML 4 specified that browsers were supposed to render
quotation marks at <q> tags: people *did* want this behaviour. Some people
still want it.

Look, my proposal means that:

   - the people who do want it get it, and
   - the people who don't want it can avoid it (either by not using <q> at
   all, or by overriding the default presentation with one line of CSS), and
   - the people who just want backwards compatibility and don't care beyond
   that get it, but implemented far better than was previously the case.

I really do think that's the fairest compromise.


> > <p><q>I'm tired of this,</q> he said.</p>
> >
> > is a far more elegant solution, for the reasons expressed in my previous
> emails in this
> > thread.
>
> This is *only* "elegant" for someone not accustomed to typing quotation
> marks.


Well, writing </p><p> might seem inelegant to someone accustomed to hitting
the return key a couple of times to get a new paragraph, but it's how
SGML/XML-style markup works: "you want the document marked up, you gotta put
in the tags." Sometimes, you can or should put those tags in place of the
things you would enter if you were just writing a plain text document or a
word processor document.


> It is trivial for an authoring tool to swap quotation marks with &quot;
> entities.


It certainly isn't appropriate for all quotation marks in HTML content to be
replaced with &quot; entities, so I hope you're not proposing that as a
serious alternative to my suggestions!


> It is not trivial for an authoring tool to figure out where it would be
> appropriate to replace quotation marks with <q>.


As the current spec says (section 2.2):

"Authoring tools are expected to come in two broad varieties: tools that
work from structure or semantic data, and tools that work on a
What-You-See-Is-What-You-Get media-specific editing basis (WYSIWYG).
The former is the preferred mechanism for tools that author HTML, since the
structure in the source information can be used to make informed choices
regarding which HTML elements and attributes are most appropriate.
However, WYSIWYG tools are legitimate. WYSIWYG tools should use elements
they know are appropriate, and should not use elements that they do not know
to be appropriate. This might in certain extreme cases mean limiting the use
of flow elements to just a few elements, like div, b, i, and span and making
liberal use of the style attribute."


For the first class of authoring tool, it would be easy in many cases to
figure out where <q> elements should be used. The second class probably
shouldn't use <q> unless the user explicitly informs the authoring tool that
some part(s) of the document being edited are quotes. (For a user interface
to perform the latter task in MS Word, I refer you to my earlier email on
the topic, in this thread.)


> >> * Ping the CSS folks and ask them to take up this issue
> >
> > If rules for the recommended default presentation of <q> elements end up
> being codified
> > in a codex that is referenced by the HTML 5 spec, rather than being
> incorporated into it
> > (either option is acceptable to me), then there is the question of which
> group(s) should
> > collect and maintain those rules. I certainly have *not* suggested that
> this task fall on
> > the shoulders of the CSS WG. The only role in this I feel CSS must have
> is in providing a
> > language in which to encode those rules.
>
> As I have stated before, it is quite clear that what you want (a default
> CSS styling) is not on the horizon for HTML 5 or this group.Very few places
> in the HTML spec define presentation, except where absolutely necessary, as
> far as I know. This proposal very much so "breaks" the intent of HTML.


I haven't insisted on a default *CSS* styling. As for the other point,
section 9 is, as I mentioned earlier, apparently incomplete; regardless of
which, I don't - respectfully - think this is your call.

Sam

[1]http://en.wikipedia.org/wiki/Starburst_display