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

For the <q> element, I rather think you can. All of the technologies you've
listed are capable of printing quotation marks at the very least, with the
exception of the voice browser, which is capable of saying, "Open quote" or
suchlike.

So I don't think this objection holds.


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


Yes, it's inaccurate. It would be like me learning that your name is Justin
and generalizing that all men are called Justin.


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


My desire is that HTML elements consistently do what I want them to (for
instance, displaying quotation marks consistently across different graphical
browsers). My desire is *not* that they consistently act like each other
where it is inappropriate for them to do so. My proposals have taken this
into account.


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


No, it doesn't want to, at least not in any of the suggestions I've made. It
should figure out whether or not it should add some kind of quotation
indicator (e.g. quotation marks) based upon the language of the quotation
and the rules specified for default quoting styles in that language,
regardless of whether or not the author has put any quotation marks adjacent
to the <q> or </q> tags.


> 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!")?


I'd mark that up as, <q>'bout time you killed that gator!</q> . I don't see
any unbalanced quotes in that example (though there is an apostrophe).

I agree unbalanced quotes are an important use case, however. I spend a fair
bit of time marking up historical correspondence, and people writing letters
in the 19th Century certainly didn't always close quotations that they had
opened (or vice versa). Here's how, using XHTML1 Strict for the demo as I'm
not entirely comfortable with HTML 5 yet, I'd handle the problem of a
quotation with no quotation mark at the end (assuming that by default, the
UA uses :before and :after to supply quotation marks upon rendering):

<!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Test</title>
        <style type="text/css">
            q {font-weight:bold;}
            q.no_closing_quote_mark:after {
            content: ""
            }</style>
    </head>
    <body>
        <p><q>I love being able to style my quotes' quote marks,</q> said
S.</p>
        <p>J didn't want the browser to insert them. <q
class="no_closing_quote_mark">Quote this apparently unterminated
quotation!</q> quoth he.</p>
    </body>
</html>

This renders as expected in Firefox 2.0.0.17. The quotes are in bold (which
was a moderately popular typographical convention in English children's
books around the turn of the 20th Century, IIRC), which serves to show how
far they extend within the run of text.


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


<p>Jim said, <q>I think that the depth is 48".</q></p>


> Heck, I can't even figure out where the period in that sentence belongs!


You put it in the right place.


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


Several use cases have been presented in this thread, and that wasn't one of
them. At least, I didn't spot it. But it's a fair use case.


> That is the only use case where I think that the re-quoting functionality
> is really useful.


Be more imaginative! :) Or refer back to the other use cases already
presented in the thread.


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


Under my proposals, people will still be able to type in quotation marks or
the &quot; entity. Those people won't get the benefits of using <q>, but
they'll be no worse of than they already are.

Authors who do use <q> would, on the other hand, reap the benefits I've
outlined. (Compare HTML 4.x, where for many years a combination of a poor
definition and inconsistent browser support made <q> an element whose
correct use was punished more than it was rewarded.)



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


False. As you yourself have pointed out, it's nice to have the semantics <q>
brings. Want to analyse quotation patterns in the texts you've marked up?
<q> makes it easy. Want to re-style your quotes? <q> makes it easy. Want to
build a translation tool that can turn an HTML document in English into an
HTML document in (e.g. machine-translated) French, which is sophisticated
enough to format quotation marks correctly? <q> makes it easy. Want to cite
a URL source for your quotation? <q> makes it easy.


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


It requires a few more keystrokes per quote when you're marking up. That's
hardly a deal-breaker, especially if it's not compulsory. For people who do
want the benefits I've suggested, it's actually remarkably little effort for
substantial results.


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


If you *really* want it, start a new thread for it. If not, please don't
suggest it.


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


Right, and fortunately you don't have to now, because Hixie's done the work
to put it in the spec.

I can't say I'd really like to codify an internationalisation-aware set of
coding rules just for the heck of it, but if it were to be published up in a
spec document and end up saving hundreds or thousands of people (myself
included) at least as much time as it took me to write it, I'd feel it was
worthwhile.


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


I'm striving to avoid vagueness. Also, using <q>A quote.</q> is *less*
complex than using <q>"A quote."</q> or "<q>A quote.</q>"

As for the complexity of default quote style rules, if they're written in
CSS, then graphical UA authors won't even have to worry about the
complexity; they just have to incorporate them in their default style
sheets. (Authors of UAs capable of rendering limited character sets would
probably just choose to implement a simpler set of rules restricted to, say,
quotation markers present in ASCII or whatever other limited character set
their UA supports.)

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.


No, they'd write something like <q>Quoting in HTML 5 is easy!</q>, and it
would just work, in much the way that <ul><li>HTML 4
has&hellip;</li><li>lists that&hellip;</li><li>just work.</li></ul>

Regards,

Sam

Received on Wednesday, 29 October 2008 20:59:30 UTC