Open r12a opened 3 years ago
A few key comments from that other issue:
It would be easy to say that auto
resolves based on the parent content language rather than the element's own, and I think we should definitely at least do that.
The next consideration is whether we want to get the q { quotes: inherit; }
behavior required to get consistent quoting conventions through multiple levels of quotation. Given that auto
inherits as itself, it would require some other keyword (like the match-parent
keyword we have added to text-align
) to resolve the computed value to a specific quoting convention.
The CSS Working Group just discussed [css-content] Quote character choice must depend on surrounding language, not language of the quotation
, and agreed to the following:
RESOLVED: auto value of quote to be based on parent language
RESOLVED: Add match-parent keyword
Just wondering about the status of this. It doesn't seem that any edits have yet been made, afaict. It seems to me that something along these lines may be useful.
[1]
A typographically appropriate used value for quotes is automatically chosen by the UA based on the content language of the element and/or its parent.
Replace with something like:
A typographically appropriate value for quotes is automatically chosen by the UA based on the content language of the q element's parent. Nested q elements use the same content language for values as the first element.
[2]
Note: If a quotation is in a different language than the surrounding text, it is customary to quote the text with the quote marks of the language of the surrounding text, not the language of the quotation itself.
-->
Note: If a quotation is in a different language than the surrounding text, it is customary to quote the text with the quote marks of the language of the surrounding text, not the language of the quotation itself. Nested quotations continue to use quote marks for the same language as the top-most quotation.
[3]
Il disait: « Il faut mettre l’action en ‹ fast forward ›. »
The quote marks around fast forward seem a little ambiguous to me wrt whether they surround a quotation (as opposed to a foreign term). But it also misses the chance to show French quotes on the outside, too. Maybe you have a reason for choosing that example, or maybe it's better to use the following (or both?).
Mais Lucy répondit: «Give George my love and tell him, ‹Muddle›».
OK, I pushed some edits for this. There's actually two approaches we can take for match-parent
:
auto
, but for this language", and inherit as such. Like alternatively you could implement as "look up the tree until we find a non-match-parent
value and grab the content language from that element", but it's probably easier to just inherit it as a package deal. Idk if I should note that trick in the spec or not...Anyway, I took the second option (resolve at used-value time only) because it's more consistent with how auto
works. But would appreciate WG review. https://github.com/w3c/csswg-drafts/commit/8b2623c9568a69939e7fc854c1148a263ac17b0a
@r12a Currently auto
resolves on each element it's used, it's just now changed to look at the parent instead of the element itself. To get the behavior you have in the last example (Mais Lucy répondit: «Give George my love and tell him, ‹Muddle›».) you'd need to spec q q { quotes: match-parent; }
. Do you think we should do this by default or is e.g. (Mais Lucy répondit: «Give George my love and tell him, “Muddle”».) a reasonable default?
Currently auto resolves on each element it's used, it's just now changed to look at the parent instead of the element itself. To get the behavior you have in the last example (Mais Lucy répondit: «Give George my love and tell him, ‹Muddle›».) you'd need to spec q q { quotes: match-parent; }. Do you think we should do this by default or is e.g. (Mais Lucy répondit: «Give George my love and tell him, “Muddle”».) a reasonable default?
No, no. Keeping the same style of quote marks for embedded quotes is what i'm asking for in many of my previous comments in this thread, and as the default. Everything i've seen indicates that the internal quotes should be consistent with the external quotes. I therefore don't see “Muddle” as a reasonable default. It should be ‹Muddle›. hth
Also, what happens if you have more than one set of embedded quotes – rare, i grant you, but probably not something to ignore.
I also find myself wondering why auto should be the default setting, since match-parent (where parent means the context outside the outermost quotes) is really what we need by default. It seems to me that the auto setting should produce that most of the time anyway – i hope it will not turn into something that allows browsers to continue doing the wrong thing as they have been doing so far.
@r12a match-parent
won't do the right thing as an initial value because it maps the element's language to a quotation mark system and then inherit with that choice locked--which by default means it'll take the language from the root element (which is the outermost element), map it to a quotation mark system, and trace that system that through the whole document tree. That won't do the right thing in a lot of cases.
you'd need to spec
q q { quotes: match-parent; }
I think we'd need q * { quotes: match-parent; }
in the UA stylesheet to get the behavior @r12a wants, and I cannot think (at least not yet) of another way to achieve the same result. Should we do that?
I think i had misread the meaning of auto
. Tell me if i'm right in thinking that if the default situation is
q { quotes: auto; }
q * { quotes: match-parent; }
then Mais Lucy répondit: «Give George my love and tell him, ‹Muddle›». would come out as expected, even if there was a third or fourth embedded level, and even if the languages of each embedded level change. That is, the quotes for the top level are set by the language outside the top level (auto), but the quote marks for any embedded levels simply match the quotes used in the top level, regardless of language. (And of course the actual quote characters can vary according to the level, eg. single or double guillemets, but they always match the quotes one would use in the language of the text outside the top level.)
If that's so, then this may be a useful approach for dealing with the q
element, but content authors will need to know/remember to use the two lines of CSS for any non-q elements if they hack it themselves. That's a bit of a concern.
Tell me if i'm right […]
By my understanding, yes, that is correct.
So, as discussed on a recent i18n call, the above discussion is wrong, because content: open-quote
(resp. content: close-quote
) is not used on the q
element, but on ::before
(resp. ::after
), which are children of the q
element.
So what we would need to get the desired behavior is:
quotes: match-parent
or quotes: parent
or parent-language
or quotes: context
(to be bikesheded) value which computes to (and therefore inherits as) a set of strings describing the appropriate type of quotes based on the content language of the parent elementq { quotes: parent-language; }
q q { quotes: inherit; }
With that in place, the pre-existing ua stylesheet rules
q::before { content: open-quote; }
q::after { content: close-quote; }
would do what i18n expects.
quotes: auto
could go back to computing to a set of strings describing the appropriate type of quotes based on the content language of the current element. This would not be used by q
, but could be useful in other contexts, such as blockquote
elements, which authors could opt into styling either with auto
or parent-language
. Alternatively, if resolving based on the current element's language that's considered useless in all contexts, auto
can be the name we use for the parent-language
This issue was discussed in a meeting.
Some text more text
inner text
s
florian: I thought we had the solution, but I forgot the ::before in the child
r12a: I find it very difficult to follow all the stuff you're talking about because I don't know the technical details
florian: I think we really understand the use case that you want to achieve, but it's surprisingly tricky to get there
<fantasai> q { quotes: match-parent; } q q { quotes: inherit; }
<r12a> fuqiao, here's a link: r12a/mins2issue
fantasai: this is not as bad as an universal selector because q is not very often used
… even if you have to walk up the parent up to the route every time you hit a queue, you're not gonna hit a q very often
… so it won't regress most pages probably
florian: we now have a definition that probably works and a selector that's less problematic
… still not amazing, but probably works
… maybe we should update the spec
… and talk with the browser vendors
fantasai: that seems reasonable
… back to blockquote
florian: maybe it's just parent, not match-parent
fantasai: auto-parent or something like that
florian: we should write it down
fantasai: and ask the browser vendors
florian: I'm curious how often is this something people run into and complained about
xfq: I've seen some real examples in paper books
r12a: I've seen real web pages too
… I use the q element myself
… it's really useful for things like translation
… you don't have to go through all the hard coded quote marks and change them
… you just change the CSS
data:text/html,<div lang="zh"><q lang="fr">Quote <q>embedded</q></q> <q>Quote</q>
The CSS Working Group just discussed [css-content] Quote character choice must depend on surrounding language, not language of the quotation
, and agreed to the following:
RESOLVED: adopt a quotes value that, if the parent's quotes computed value is auto, computes the correct quotes for the parent's language, and if the parent's quotes computed value is not auto, inherits that value
RESOLVED: drop existing match-parent value
See also follow up discussion in https://github.com/w3c/csswg-drafts/issues/10436
[This and the following comments were moved to https://github.com/w3c/csswg-drafts/issues/10468]
I was just reviewing an article i wrote in 2018 but haven't yet published, pending the resolution of this discussion. Some parts, esp. related to how to write CSS, need to be rewritten after the dust settles. The following section may be useful to describe the problem we are attempting to solve: https://w3c.github.io/i18n-drafts/questions/qa-the-q-element.en#how
However, the section Problems with scope describes an issue that i'm not sure we have yet discussed: If you apply a font change to a quotation in another language marked up with the q element, the font change also affects the quote marks, but the quote marks should be treated as part of the surrounding text, and remain in the same font as the stuff around the quote.
Should we discuss that here, or raise a separate issue?
If you apply a font change to a quotation in another language marked up with the q element, the font change also affects the quote marks, but the quote marks should be treated as part of the surrounding text, and remain in the same font as the stuff around the quote.
Probably worth discussing in a separate issue. Logically, I agree that the quote marks "belong" to the context of the quoted text, but if the quote is styled quite distinctively, I suspect it could look quite jarring to surround it with quote marks that don't match its style.
(I'm sure I've seen typographic guidelines that insist punctuation marks should use the style of the adjacent word, and haven't said anything about an exception for quote marks.)
2.4.1. Specifying quotes with the quotes property https://drafts.csswg.org/css-content/#quotes-property
The i18n WG raised an issue related to the Rendering section of the HTML spec because current implementations choose quote marks based on the language of the quotation, rather than the language of the surrounding text. This is wrong, and needs to be fixed.
It is noticeable when the language of the quotation is different from that of the surrounding text. See these tests:
Since the HTML spec is now to have that section removed (due to introduction of the
auto
value for thequotes
property), we need this requirement to be made clear in the CSS spec.[Note, btw, that contrary to the request at the start of the HTML thread mentioned above (https://github.com/whatwg/html/issues/3636), it is important to base the choice of quotes on the language of the immediately surrounding text, not the language of the html tag (as is made clearer further down the discussion thread).]
It would also help to include a note showing how content authors can make their styling produce the correct results (since it's far from straightforward, and it will no longer be possible to point to examples in the HTML spec).