RE: Is <q> useful? [was Expected behaviour of quotation marks]

Richard, thanks. I should have been more explicit. I recognize the value in being able to identify quoted content and to stylize it (eg italicizing it) and to tweak the rendering of the quote marks (spacing, kerning, etc), as we do with other content types.

However, and recognizing that quoting styles vary with culture, I still find the value of using q elements to select the quote characters based on the current language to be minimal.

I would position it more exactly this way. When the q element is being used to earmark quotations, then of course we need the CSS capability to specify quotation characters, and this is language dependent.
However, when quotations are not otherwise semantically being identified,  the emphasis that is often given during presentations on CSS internationalization capabilities (I am not referring to yours in particular Richard) recommending if not driving people to replace quotes with q elements is in fact counterproductive and caused more problems than it solved. 

At least with respect to browser support, that has improved in the past few years. But even with that, the transition from literals to q elements and trying to maintain the proper quotes according to the appropriate language in multilingual environments has been problematic.

I recognize you are trying to improve the situation. Maybe the discussion will lead to a better architecture for accessing language identifiers within css, which will help elements and properties beyond just q.

tex



-----Original Message-----
From: ishida@w3.org [mailto:ishida@w3.org] 
Sent: Friday, April 08, 2016 4:29 AM
To: Tex Texin; 'John Cowan'
Cc: 'Dave Cramer'; 'W3C Digital Publishing IG'; 'www International'
Subject: Is <q> useful? [was Expected behaviour of quotation marks]

[since this is branching out into a different topic, i'm retitling it]


On 07/04/2016 19:45, Tex Texin wrote:
> I share John's disdain for the q element, although rather than saying it is broken, I think it is impractical. Perhaps others can share some use cases where it makes sense to use it.
>
> If I have a quote embedded in text, then I generally know the language 
> of the surrounding text and may as well use a literal quote in that 
> text. (Assuming you believe the outside quotes follow the surrounding 
> language.)
>
> For example, if I have a database of sayings which I use to populate a page. Something like: <author> said <saying>. Eg. Newton said "All objects resist changes in their state of motion."
> Since I know the word "said" is in English, I could supply the literal English quote characters as well. A resource string might look like-     saying: %1 said "%2"
> Using the q element instead of the literal would only complicate the programming and likely introduce errors.
> I have trouble finding simple and useful cases where it makes sense to use the q element.
>
> The case of a quote embedded in a quote surprisingly makes more sense, if you follow the model that the inner quote should follow the language of the outermost language. This case introduces the need to know the variable and unknown-until-the-time-of-rendering outermost language identifier. As is pointed out though, accessing the outermost language identifier is problematic.
>
> Where are the cases where the q element is a solution to a problem? Ie Where the first level quote characters are for some reason independent of the surrounding text and so need to be programmatic, or where the second or third level quotes need to follow the language of the first level quotes, and are able to do so, given the language identifier is replaced by the intermediate language identifier?

I'm not saying that there aren't any cases where you'd want to use Unicode characters for quotation marks, but here, as i see it, are some ways in which the q tag can be quite useful.


[1] Suppose i take your page containing a list of quotations, and i decide i want to extract just the quotations themselves, without the 'Newton said', etc.

if the quotes had been semantically identified using q elements, it would be trivial to do so.  I'd know how to locate the quotes, how to avoid extracting the subquotes (although i could if i wanted), and how to avoid extracting things that happened to have quotes around them, but weren't actually quotations (such as column headings described in the explanation about how to use the page).

doing that by searching for quotation mark characters is more complicated and may restrict the options in terms of how it would be done. In fact, if you used the British tradition to start quotes with single quote marks and those were delimited by U+0027 APOSTROPHE, you would also avoid having to figure out which punctuation marks bounded the quotation and which were used in words like it's, etc.

in fact, a general method would need to take into account the language of the source page and make some assumptions about what quote characters were used to bound the quotes in order to identify where the quote are.

none of that extra calibration or care is needed if you just extract the stuff marked up by q elements.

so that's one use case where i think q can be useful, ie. semantically marking up the elements in the text allows you to straighforwardly find stuff based on semantics, rather than having to figure it out.


[2] now, suppose that i take the quotes i extracted from your page and slipped them one by one into various other pages which were in various different languages, and i didn't use the q tag.  While inserting the quote into the page i'd have to first determine the language of that page so that i could figure out what Unicode characters to use to surround the quote, as well as which to use for secondary quote marks.

if, instead, i just inserted the quotation inside a q element, i should be able to rely on the browser to apply some sensible default punctuation characters, or even to pick up on any particular styling that the author of that page had put in place for quotations.

and btw that q element would provide a perfect hook for lang attributes and dir attributes, as well as for cite attributes, etc.


[3] use of q markup provides greater typographic control over the 
placement of quotation marks. For example, in French the guillemet tends 
to come with some extra blank space besides it. You could achieve this 
very simply by styling the q element.  In other cases, you may want to 
make the quote marks bigger, kern them or move them in one direction or 
another relative to the base, even colour them, etc.  All this is easily 
controlled by CSS if you use the q element, but not easy at all if you 
just use the Unicode characters.

[4] if you want to translate a page with quotations from, say, English 
to German, no need to search and replace the Unicode characters.  Just 
use a different style rule in the CSS to change the quote marks as needed.

[6] in fact, you may want to change the quote marks sometimes even 
without translation – perhaps to change a text from en-US to en-GB, or 
perhaps just because you prefer a different approach within a single 
locale when there are multiple possibilities (such as »Blume« vs „Blume“ 
in German), or perhaps because you want to use a script to put one 
quotation at random into a larger blockquote on the page, in which case 
you don't need the quote marks.

[5] you are going to be sure that you didn't miss out or misplace 
punctuation if your markup is well-formed.

i sometimes if fiddly to get punctuation marks right in small font 
sizes, such as in:
Lucy sagte, “Tell him „Muddle“”
(i actually just made a mistake while trying to create that example!)
whereas if i'm using Dreamweaver, marking that up is a doddle, and it's 
easy to tell that i got it correct.

Also, if i'm unable to access left and right quotation marks on my 
keyboard or in my application, it's not a problem if i'm supplying them 
via styling.

well, maybe i should stop there.

ri

Received on Friday, 8 April 2016 18:41:10 UTC