[whatwg] several messages about quotations

[Ian Hickson]

Summary: I've made the spec require that any punctuation for <q> be 
included inside the element; I've added examples for <q>.

On Wed, 10 Nov 2004, Thomas Scholz wrote:
> Ian Hickson schrieb:
> >
> > I sometimes want to take quotes and put them into floats with huge 
> > oversized quotemarks under the text at the top right and bottom left 
> > (it's quite a common effect in glossy magazines). This can't be done 
> > unless you can address the quotes directly somehow.
> 
> What about an element <quote>?

Well, we have an element (<q>), the problem is what to do with the 
quotation marks.


On Wed, 10 Nov 2004, Henri Sivonen wrote:
> On Nov 10, 2004, at 03:34, Ian Hickson wrote:
> > > 
> > > I agree with Henri, this is an authoring problem, not a styling a 
> > > problem.
> > 
> > But Henri agreed with me, saying that using markup for this was a bad 
> > idea.
> 
> What I agreed to was that using markup for smartening ASCII quotes was a 
> bad idea. I wouldn't mind using spans for the special case of floating 
> the quotation marks.
> 
> How would you define CSS pseudo-elements for open and close quotes in 
> such a way that they would be implementable and would not match 
> apostrophes and would correctly differentiate between open and close 
> quotes in languages that use the same character for opening and closing 
> and in languages that invert the direction of guillemets compared to 
> French?

I would introduce two pseudo-elements, ::quote-start and ::quote-end, 
which match one or more characters with the Quotation_Mark property (as 
per Unicode PropList) found at the start or end of an element, if such 
text is a direct child of the element (skipping White_Space characters).

I've started this idea down the path of the CSS working group.


On Wed, 10 Nov 2004, Max Romantschuk wrote:
> 
> I thought the issue on the table was the fact that the spec defines the 
> following: "Visual user agents must ensure that the content of the Q 
> element is rendered with delimiting quotation marks."
> 
> The problem arises with UAs which don't understand <q>, and leaves out 
> the quotation marks. This results in the loss of the information that 
> the element content was a quote.

On Wed, 10 Nov 2004, Thomas Scholz wrote:
> 
> No, some UAs insert quotes, some don't. A new defined element <quote> 
> shouldn't require automagic quotes and leave this up to the author.

On Wed, 10 Nov 2004, Max Romantschuk wrote:
> 
> OK. I see your point. Even though this would esentially solve the 
> problem I would be hesitant to support such a solution. If two elements 
> mean the same thing on a semantic level and only differ in presentation 
> we're essentially returning to the HTML3 model of mixing content and 
> presentation.
> 
> I'm not claiming I have a better solution, but I feel we strive to 
> separate content from presentation and keep the semantic model as 
> unambiguous as possible.

I agree that introducing a new element just to solve the problem isn't 
really a good solution.


On Sat, 16 Apr 2005, fantasai wrote:
> John Lewis wrote:
> > I strongly believe quotation marks (for songs, etc.) should be written 
> > by the author in the document, not added with CSS. <q> is messy and 
> > hard to use.
> 
> I agree that <q> has problems, particularly with en-US style 
> punctuation. However, if the italics is going to be in the CSS, I think 
> the quotation marks should also be there.
> 
> I'd like to note also that citations in languages other than English -- 
> in Chinese, for example -- are probably done differently. (This is why 
> either all citation formatting should be the responsibility of the 
> author or none of it should be.)

I agree that the CSS should be able to override quotation punctuation.


On Wed, 13 Jul 2005, Bjoern Hoehrmann wrote:
> 
> What is proposed for XHTML 2.0 does not really work, I've discussed this 
> in <http://lists.w3.org/Archives/Public/www-html/2004Aug/0011>.

Would it work if we required all punctuation to be included in the source 
(inside the <q> element), and provided the above-suggested pseudo-elements 
to deal with styling?

Did you ever receive a reply to that e-mail?


On Tue, 3 Apr 2007, Asbjørn Ulsberg wrote:
> On Mon, 02 Apr 2007 23:52:48 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > > 
> > > Instead of enhancing the Q element, we should deprecate it and 
> > > replace it.
> > 
> > Replace it with what?
> 
> A new element, <quote> for example.
>
> > What should we do with the existing content that uses <q>?
> 
> It will still be supported, but deprecated in favour of <quote>.
> 
> > This has been an open issue in the WHATWG for a while but nobody has 
> > come up with a particularily compelling solution -- either the 
> > solutions drop compatibility with existing content, or existing UAs, 
> > or require complex CSS features. (My own proposal falls in the latter 
> > camp; it makes <q> require quote marks around <q> elements 
> > (author-provided), then provides complex CSS that can select those 
> > quotes for replacement -- for legacy unquoted content you get the 
> > quotes added by CSS, for everything else you get the author-provided 
> > quotes.)
> 
> Instead of shoe-horning this into <q>, isn't it better for future 
> content authors to have a <quote> element that has this functionality 
> out of the box?

Well, other than some minor growing pains with <q> for a few years, what's 
the problem with reusing <q>? It's shorter and people already know about 
it. Somewhat. (It's hardly ever used, really. Less than <blink> and 
<ilayer> according to my studies.)


> as well as being able to replace <blockquote>?

Why would we do that?


On Wed, 25 Apr 2007, Yahia Chlyeh wrote:
> 
> I have remarked that the current draft does not require UAs to add 
> quotation marks enclosing the text inside the <q/> element (nor does it 
> prohibit that).
>
> Not requiring it is good, but disallowing it would be great for the sake 
> of saving the <q/> element for the future from ambiguities resulting in 
> its non use.

That seems reasonable. I'll make the rendering section require that in due 
course.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'