Re: <q> and commas

2008/10/29 Robert J Burns <rob@robburns.com>
>
> On Oct 29, 2008, at 3:19 PM, Justin James wrote:
>
>> As a result, authoring tools do actually need to be rather smart, in order
>> to determine what to do when the user types a quotation mark character and
>> then selects text and hits the "Q" button (or whatever they would do to
>> turn
>> a selection into a quote).
>>
>
> No, the authoring tools do not need to do that at all. If an author types a
> quotation mark the authoring tool can simply leave it alone. If the author
> selects some phase and selects a q element command, the UA would wrap that
> phrase in the Q element. The rendering of this would not be handled
> automatically or intelligently or magically. The rendering would be handled
> by applying the CSS style rules to the newly created Q element. Again, no
> magic and no heuristic intelligence required. It has nothing to do with the
> MS Word features we all hate.


Exactly.


>  Overall, I stand by my statement that this proposal is "fraught with
>> danger". It requires a relatively complex amount of logic, with relatively
>> little returns, especially when you consider the benefit from this
>> logic...
>> allowing people to not type quotation marks, or to update the quotation
>> marks if they change the nesting levels.
>>
>
> Except you're talking about a proposal no one else is discussing. Instead
> what I hear being discussed is:
>
> 1) continued use by authors of the q element
> 2) continuing in the HTML4 tradition of recommending quotation marks
> wrapped around the q element (perhaps also requiring some distinguishing
> presentation even if its not specifically through quotation marks).
> 3) providing a sample HTML stylesheet that includes some :before and :after
> selectors CSS generated content properties to include quotations marks where
> appropriate


I personally hope that it would be a little stronger than just a "sample"
stylesheet: I would want UA authors to feel obliged to implement it if at
all possible.

Also (and this is a minor point) if the default styles were to be specified
in CSS, the rules for quotations might need to use more than just the
:before and :after pseudo-elements; they *might* need to specify
font-style:italic, for instance. *Which* rules they would need would be
discovered by whoever is charged with drafting the default styles during the
course of their research.

4) recommending the CSS WG adds support for some missing presentational
> conventions such as:
>     a) kerning quotations over or even inside trailing punctuation
>     b) determining context language (e.g., document language) to apply
> appropriate language specific quotation styling (this is mostly for default
> UA stylesheet since authors and users will likely only add specific
> quotation marks desired as an author or user)
>     c) though not yet discussed in the current thread, I've said before
> that CSS should provide some mechanism to distinguish quotation presentation
> according to the number of words or characters within the quotation element
> (since this too reflects a common presentational idiom for quotations)


Interesting. Not sure what I think of this yet, but it feels like it might
require the sort of heuristic reasoning we want to avoid. Could you provide
a reference for where you've discussed this previously?


> 5) adding an attribute (such as marks='provided' marks='needed) to allow
> authors to select the authoring convention they prefer


This doesn't seem necessary to me: as long as the default presentation can
be overridden with styles, why introduce another (redundant) mechanism to
achieve the same effect? (To answer my own rhetorical question, it
could possibly be useful in the case of UAs that won't support @style but
would support @mark - an extreme edge case, I hope, and therefore not one
worth taking seriously.)


> 6) perhaps intelligently (only here are we talking about applying some
> heuristics) omitting duplicate quotation marks when included as generated
> content from CSS and included at the border of the q element (either inside
> the element or immediately outside the element)
>    Note: this may also be important for aural browsers where the user's
> stylesheet already distinguishes a quotation by voice (for example) so that
> hearing the utterance of "quote" and "unquote" is redundantly annoying for
> the user
>
> The last item should is the only one involving heuristics and they're
> actually some fairly simple heuristics. By clearly specifying an algorithm
> to follow to determine which quotations are duplicate, we would provide a
> way for authors using the Q element already to continue to work in legacy IE
> and all other browsers (which I imagine was much of Chris' motivation in
> initiating this thread).


I'm *not* in favour of such heuristics, and I'll explain why.

(A) In cases where the author has used constructions like <q>"(A
quote.)"</q>, the markup is invalid under HTML 4.x, so no backwards
compatibility for this case should be required. For HTML 5, I don't have
strong feelings at this point whether such markup should be invalid or not.
Yet, if HTML 5 does not deem such markup invalid, then it should be up to
the author to style the <q> elements not to render quote marks.

(B) In cases where the author has used constructions like "<q>(A
quote.)</q>" together with styling like that suggested in "Long Live The Q
Tag"[1] (i.e. styling to prevent the <q> element from displaying quotation
marks; that is, to behave as IE<8) then no heuristics are needed to prevent
the <q> element displaying quote marks, because the styling already takes
care of this.

(C) If an author wants to be able to use quotation marks AND <q>
elements (e.g. "All he said was, <q>Hi.</q>"), I think he/she should be able
to, for instance to display, without a supposedly helpful heuristic
algorithm intervening and potentially misrendering the author's intention
(e.g. displaying "All he said was, 'Hi.' instead of "All he said was,
'Hi.'").

For the reasons in (A), I conclude that constructions in which the author
places quote marks immediately inside <q> elements do *not* require
heuristic solutions.
For the reasons in (B) and (C), I conclude that constructions in which the
author places quote marks immediately outside <q> elements do *not* require
heuristic solutions.
Therefore, heuristic solutions are not required.

Best regards,

Sam

[1]http://www.alistapart.com/articles/qtag