Re: <q>

On Oct 29, 2008, at 5:20 PM, Philip TAYLOR (Ret'd) wrote:
> Thomas Broyer wrote:
>> (while, however, in lights of Ben Millard's message, I'd probably
>> rather go with <p>"<q>I'm tired of this</q>," he said.</p>)
> Would you ?  Surely the comma should /follow/ the second
> (closing) quotation mark, unless you are writing American
> English and following the Chicago Manual of Style's rather
> idiosyncratic ruling on this topic.

This again underscores the presentation nature of the quotation marks  
and why we should be adhering to the separation of concerns design  
principle here. In adhering to the separation of concerns, an author  
should simply not need to know anything about style manuals as the  
author composes the HTML document. HTML5 should be seeking to codify  
that separation of concerns approach (even if we provide authors  
mechanisms to opt out of that approach and provide their own quotation  

In the long and tedious list of references, Ben MIllard cited there  
was one gem[1] from Benjamin Hawkes-Lewis who always provides high- 
grade ore in his messages. There he outlines 4 separate presentational  
issues with quotations. All of those issues could be addressed by CSS  
properties or @ rules. While these might only be finally able to  
authors in a decade or so, from then on, this debate would finally be  
closed. It would be up to users and authors how to style their  
quotations, but in a fully abstracted manner separating that  
presentation in CSS from the semantics in the HTML Q element.

Again, all of the issues Hawkes-Lewis raises in that message could be  
addressed by CSS. Dedicated quotation @ rules could shape how the  
quotation is presented.

a) kerning of trailing ::after quotation marks over trailing punctuation
b) omission of terminating quotation marks (e.g., French and Russian)
c) line marker quotation marks (e.g., French) which may already be  
handled by proposed CSS line markers
d) block presentation of lengthy inline quotations

Again these are all issues for CSS to deal with. For HTML we should  
simply provide the marks attribute (taking values of 'needed or  
'provided') to give authors the option of following the HTML4 and  
future convention ('needed' as the default value) or the IE <8 imposed  
convention or for those waiting for the new CSS properties and @ rules  
for Russian, French and other conventions requiring those CSS  
enhancements ('provided'). Chris Wilson's additional proposal to  
intelligently avoid the duplication of quotation marks with ::before  
and ::after might also be worth pursing unless others can conceive of  
serious problems generated by that approach (for instance authors  
testing on browsers supporting duplication correction and not  
realizing other UAs fail to void the duplication).

Take care,

[1]: <>

relates to Issue 48 (Issue-48)

Received on Wednesday, 29 October 2008 22:47:01 UTC