RE: <q>

From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Sam Kuper
Sent: Wednesday, October 29, 2008 9:15 AM
To: Justin James
Cc: Ivan Enderlin; Olivier GENDRIN; Ben Boyle; Chris Wilson; HTML WG
Subject: Re: <q>

> 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.

It's a matter of simply, "how do you write defaults that make sense on all platforms?" You *can't*. What's appropriate for my desktop PC and its 24" wide aspect monitor is not appropriate for a cell phone, which is not appropriate for a printer, which is not appropriate for a voice browser.
 
>> 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.

Yes, it is generalization of what you said. Is it an inaccurate generalization?

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

Yes, and HTML also is fairly consistent, and moving more so towards consistency. I think to have one special inline element suddenly generating quotation marks is not something that belongs in the HTML spec. It is certainly inconsistent!
 
>> 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?

Well, it wants to try to figure out whether or not it should add quotes, based upon whether or not the author has done so. What about unbalanced quotes? What if they are on purpose, and not an accident (for example, a quote such as "'bout time you killed that gator!")?
 
>> No one has adequately addressed the error handling issues.
>
> What error handling issues?

The ones where someone authors HTML and/or content that triggers this behavior when it should not be triggered, such as the unbalanced quotes above. Or what about:

   Jim said, "I think that the depth is 48"."

Heck, I can't even figure out where the period in that sentence belongs!
 
>> And the use case is an edge case to begin with.
>
> Which use case is an edge case?

The use case where people have nesting quotes, and then change the level of nesting. That is the only use case where I think that the re-quoting functionality is really useful. The rest of the time, people are so used to typing in quotation marks or the &quot; entity for hand-authors (much more so that selecting text and then clicking a button or a key combination or inserting HTML to mark it as a quote) that I think it will still be a highly unused element.
 
> 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.

This behavior is only "potentially beneficial" to people, with the exception of the re-nesting use case. It is more work to mark text with <q> than it is to type quotes in, for any authoring tool that I can think of offhand.
 
>> 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.

OK, let's get a "repeater" element too, to save people the trouble of typing repetitious things, which is a very common waste of time. In fact, I think that <table> could do with an Excel-like "auto fill" function.
 
>> 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.

This is why I don't write parsers for date values for fun. :)

> 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.

Strictly speaking, yes. But at the same time, when you make a spec too gold plated, it becomes rather useless. There are specs out there which are simply so complex that very few people actually use them, or worse, people use them and use them incorrectly (HTML 4 is a great example of this; vagueness is a form of complexity). To make the presentation of <q> this complex, for relatively little benefit to a small group of people does not make sense. Someone who may be considering using <q> would take one look at it and run in horror.

J.Ja

Received on Wednesday, 29 October 2008 18:29:55 UTC