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

Re: <q>

From: Sam Kuper <sam.kuper@uclmail.net>
Date: Wed, 29 Oct 2008 13:14:56 +0000
Message-ID: <4126b3450810290614g595ccacdt8775a46abca6e1bb@mail.gmail.com>
To: "Justin James" <j_james@mindspring.com>
Cc: "Ivan Enderlin" <w3c@hoa-project.net>, "Olivier GENDRIN" <olivier.gendrin@gmail.com>, "Ben Boyle" <benjamins.boyle@gmail.com>, "Chris Wilson" <Chris.Wilson@microsoft.com>, "HTML WG" <public-html@w3.org>
2008/10/29 Justin James <j_james@mindspring.com>

> From: sampablokuper@googlemail.com [mailto:sampablokuper@googlemail.com]
> On Behalf Of Sam Kuper
>
> 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/28 Justin James <j_james@mindspring.com>
> >> HTML doesn't define a default style for many elements at all. Why are
> you insisting that
> >> one be defined for <q>?
> >
> > Partly because I'm used to it from HTML 4.01; partly because section 9 of
> HTML 5 is
> > obviously incomplete, leading me to think that HTML 5 may yet recommend
> default
> > presentation for many elements.
>
> It won't. I asked about this a few months ago, and the feedback from the
> group was EXTREMELY clear on this topic. Due to the wide variety of devices
> and UAs that can consume HTML, defining default styles is, (to use my
> phrase), "fraught with danger". I saw the light. :)


Maybe I haven't "seen the light" yet, but I think this is Hixie's call.
Besides, as I've mentioned, I'd be quite happy for the defaults to be
codified in a document other than the HTML 5 spec.


> >> OK, then for the sake of consistency, I insist that you insist that <p>
> require proper
> >> capitalization and punctuation.
> >
> > I don't see how that would be consistent, given that I have been making
> suggestions about
> > <q> and not about <p>. In other words, the scope of my suggestions has
> been the <q>
> > element, not all HTML 5 elements, nor even all HTML 5 elements containing
> phrasing
> > content.
>
> Simple... you are saying that an element which represents a grammatical
> concept (a quotation) should have a mechanism for automatically choosing the
> correct punctuation based on language for that piece of text.


No, I'm not. That's a general statement, or at best a vague one. Please
don't put words in my mouth.

My comments in this thread referred to the <q> element specifically, and
(except where stated) the <q> element alone.


Thus, <p> should add punctuation too, in a consistent world. HTML puts a
> heavy premium on consistency. Again, if <q> adds punctuation, so should <p>
> and any other element which represents grammar.


Trying to make apples consistent with oranges is not something HTML does (or
should) put a premium on. A paragraph and a quotation are not the same
thing, even if they do both contain phrasing content.


> > I said, "decently marked-up", I didn't say, "marked up with <q>". So
> what's the problem?
>
> Because so little content is decently marked up! Even when people TRY to
> mark things up correctly, they typically are not marked up correctly.


I still don't see how this is a specific objection to having <q> behave the
way I've suggested.


> One major assumption of HTML is that it will needed to error correct. I do
> not think that this proposal error corrects very well.


That's potentially an interesting objection. Please could you explain why
not?


> > In fact, among forum software, [quote] is probably one of the most used
> elements. It
> > would, I think, be easier for phpBB et al to become HTML5 compliant wrt.
> the <q> element
> > based on my proposals (and all equivalent proposals made by others) than
> otherwise.
>
> One class of software, yes. And you know what? It uses <blockquote>, not
> <q>, last I checked, and it is not meant for inline quoting.


Conceded.


> No one has adequately addressed the error handling issues.
>

What error handling issues?


> And the use case is an edge case to begin with.
>

Which use case is an edge case?


> I do not think that it is worth attempting to figure out some sort of
> tricky logic around these things, attempt to enunciate it within the spec,
> and then hope that HTML consumers implement that tricky logic, all to save a
> small handful of HTML authors (the intersection of the sets of authors who
> use <q>, and the set of documents with a lot of inline quotes, and the set
> of documents with a lot of nested quotes) a little bit of effort.
>

I'm not asking you to figure out the logic. Given that you could potentially
benefit from it without having to expend any further effort whatsoever,
perhaps you ought not to object on this ground.


> Let's get honest, how many documents contain so many nested quotes that
> this proposal actually saves those authors much effort? And how often does
> the level of nesting change?
>

Enough, in both cases, to make this worthwhile, given that the future of
HTML is potentially very long indeed.


> This is a unneeded, complex solution in search of a true use case.
>

It isn't terribly complex, and use cases have been presented. The algorithm
would be longer, but probably not significantly more complex, than that
presented in, say, 2.4.4.2.

None of HTML 5- is needed, strictly speaking, so I don't think
"unneeded-ness" is a valid objection. HTML 5 should enable resources which
it is already possible to hack together (from existing technologies and
newly-developed efforts) to be created more easily and in a more unified
manner, and I believe my proposals about <q> fit that theme.

Regards,

Sam
Received on Wednesday, 29 October 2008 13:15:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:24 GMT