[whatwg] several messages about quotations
Ian Hickson
ian at hixie.ch
Fri Apr 11 17:57:41 PDT 2008
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list