W3C home > Mailing lists > Public > public-digipub-ig@w3.org > April 2016

Re: The HTML q element can sometimes be useful. Discuss.

From: Nick Barreto <nick@canelo.co>
Date: Wed, 27 Apr 2016 08:14:27 +0100
Message-ID: <CAMsQQ_xo8vmrkyd6NA=DP2kQeJZBOBa5XQHm-+Rrie5XmjOO1g@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: ishida@w3.org, W3C Digital Publishing IG <public-digipub-ig@w3.org>, www International <www-international@w3.org>
> Unlike sentence ending periods, quotation marks do change based on the
> styling of the document (more so for blockquote than for q, but still).

How semantically different are <q> and <blockquote>, apart from <q> clearly
being inline? Or have I just described the entire difference?

Nick Barreto

*Co-founder & Technology Director**CANELO *| www.canelo.co
@canelo_co <https://twitter.com/canelo_co> | @nickbarreto

On 27 April 2016 at 02:28, Florian Rivoal <florian@rivoal.net> wrote:

> > On Apr 27, 2016, at 01:20, ishida@w3.org wrote:
> >
> > I figured it would be good to start a thread where we can address the
> wider questions that kept popping up on the other thread that was focused
> on the styling in the HTML5 rendering section.
> >
> > Here we get to put pros and cons for the existence of the q element,
> suggestions for improving it, advice about when to not use it, ideas about
> what's needed above and beyond it, etc.  I think CSS styling of quotes is
> probably in scope too, since it's hard to talk about the markup without the
> styling support.
> >
> > It may help to limit the scope, however, just to *actual quotations*,
> rather than all the other things people stick 'quote marks' around, just in
> order to prevent a situation of herding cats.
> >
> > So please reply to this. It's likely to be a long thread with diverse
> opinions. That's ok, but please try not to make unsubstantiated
> assertions.  Please use examples where you can, to help people get your
> point. And please be kind to other thread participants.
> >
> > I'll contribute some ideas later when i can carve out some time. I do
> have some concerns.  At some point, i'll try to summarise the pros, cons
> and suggestions.
> Needing to style something is not necessarily a proof that some semantic
> element is needed, but it is at least strong evidence.
> Quotes are often italicized or made to stand out in one way or another. If
> rendered to a speech medium this is a good place to change voice, or to do
> something like "@media speech { q::before { content: "quote" } }". If we
> didn't have a q element, we'd often see <span class=quote> in markup.
> This makes it different from a hypothetical sentence element. Just like
> quotes, sentence are semantically meaningful pieces of content. However,
> even though we don't have a sentence element, and we hardly ever see <span
> class=sentence> in markup.
> In addition to styling, this is also reinforced by the fact that switching
> language for a quote isn't that rare, while switching language for a
> sentence that isn't a quote or in a separate paragraph or some other
> containing element doesn't happen all that much.
> So since we're mostly going to mark up quotes anyway, we might as well
> have a standard element for it rather than everybody using their span soup.
> And going through a document programmatically to extract quotes is also not
> a crazy thing to do, so here as well, dedicated markup helps.
> The question of punctuation is more tricky.
> Like quotes, one could imagine generating the punctuation for a
> hypothetical sentence element.
>   sentence::after {content: ". "}
>   sentence:lang(ja)::after {content: "。"}
> But nobody does this. Maybe generating the punctuation for quote is just
> as silly, and we don't see it because we're all too used to the q element.
> However, I don't think so. Unlike sentence ending periods, quotation marks
> do change based on the styling of the document (more so for blockquote than
> for q, but still).
> All in all it is pretty clear to me that there should be an element for
> quotes, and that it should be possible to change what the quotation marks
> with css. I think this leaves basically two possibilities:
> (1) What we have today:
>   Markup:
>     <q>something someone said</q>
>   UA stylysheet:
>     q::before {content: open-quote}
>     q::after {content: close-quote}
> (2) Some other elements where quotes are in the markup, but identified so
> that you can replace them.
>   Markup:
>     <quote><oq>“</oq>something someone said<cq>”</cq></quote>
>   UA stylesheet: nothing
> In both cases, you can in css remove the quotation marks or replace them.
> I think the meaningful differences are:
> (a) Is it important to have quotation marks if the markup is rendered
> without any styling at all? If yes, and if we assume that such a
> css-incapable UA would know enough about HTML to tell apart block level
> elements from inline elements (otherwise the whole thing is mostly
> unusable), but not enough to know that the q element needs quotation marks,
> (2) is the way to go.
> (b) If it is not practical to write css rules that will generate the right
> type of quotation marks most of the time, authors will need to turn off
> (q::before, q::after {content:none} ) the automatic quotation mark
> generation and write the punctuation in the markup instead, in which case
> they might as well use (2).
> If (a) and (b) aren't issues, (1) is as capable as (2), and much less
> verbose.
> I am somewhat sympathetical to (a), but not to (b), as I believe it is
> perfectly practical to write in the UA stylesheet rules that will generate
> appropriate quotation marks in most situations (see the other thread for
> what these rules should be).
> We could provide some backward compatible hybrid solution that lets
> authors mix and match as they feel is appropriate:
> Markup:
>     <quote><oq>“</oq><q>something someone said</q><cq>”</cq></quote>
>     <q>something someone said</q>
> UA stylesheet:
>   q::before {content: open-quote}
>   q::after {content: close-quote}
>   quote > q::before, quote > q::after { content: none }
> However, I doubt many people care about (a) in practice, or that many
> people have issues with the quotes provided by the browser on the q
> element, so I suspect this markup pattern would not see much usage. I could
> be wrong though.
>  - Florian
Received on Wednesday, 27 April 2016 07:15:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:42 UTC