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

>
> 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
<http://www.twitter.com/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
>