Meeting minutes
<r12a> thanks for the reminder, looking for the link...
Agenda
<florian> Html ruby extension fpwd CFC: w3c/
<gb> Issue 26 CFC: Publish HTML Ruby Markup Extensions FPWD (by LJWatson)
florian: in the HTML WG the CfC for publishing the HTML Ruby Markup Extensions spec just went out today
… link ^
[css-content] Quote character choice must depend on surrounding language, not language of the quotation
<gb> Issue 5478 [css-content] Quote character choice must depend on surrounding language, not language of the quotation (by r12a) [css-content-3] [Closed Accepted by CSSWG Resolution] [i18n-needs-resolution] [Agenda+ i18n]
fantasai: it's been edited and I haven't republished the draft yet
florian: does that include that part needs to go into the UA style sheet, or just the mechanics of it?
florian: make the initial value do the right thing, or make the UA style sheet do the right thing?
fantasai: the only way to do that automatically would be to make the value of the quote property to depend on @@
… without a separate selector I don't think it's possible to get it to do the right thing
… that brings up a question of the selectors might not be the most efficient
florian: @@1
fantasai: if what you're trying to do is as soon as you hit a q element then you lock it down you could do it on any child
<fantasai> q > * { quotes: match-parent; }
xfq: do you mean the author should specify this?
r12a: that's the thing I'm arguing against
… I don't think the author needs to remember or find out how to make the default expectation
… and it should happen by default
<fantasai> q { quote: auto-compute-me-now; } /* iherits as string value */
r12a: whether that happens because we put something in a style sheet or whether that happens because the initial value
florian: do you think browsers will be happier with @@?
fantasai: I don't know
florian: but you're probably reasonably well-positioned to ask people who would know
xfq: @@
r12a: it's not supposed to respond to changes in languages further down
fantasai: it's because if you set the initial value to a value on the root element and it computes on the root element rather than inheriting the auto
… from what I understand, you don't want either of these behaviours
florian: and I think the thing with a selector in the UA style sheet does give us the right behaviour
… it's just not the kind of thing we typically want to
xfq: what's the next step?
fantasai: we can go back to browser vendors and ask them which approach they want to take here
florian: can we agree on a UA style sheet rule that is the most performant and acceptable we can think of
… that gives us the behaviour we want and then we tell the browsers are you either willing to implement this or do you have another suggestion?
florian: you want the first q element in the hierarchy
… lock down every descendant of it
fantasai: right now we have match-parent, but instead of computing against the parent's language it computes against your own language
… which is match-self
<fantasai> <p lang=fr>Some text <q lang=en> more text <q lang=zh> inner text</q></q></p>
fantasai: so we have this, what you want here is you want French quotations all the way through
r12a: yeah
florian: the auto keyword means that you pick a quotation system based on the content language of the parent
… so exactly what we want on the first q element
fantasai: instead of saying it matches the same quotation mark system as the parent, we want a keyword that computes against the parent
… you can't do that as initial value because it breaks stuff
florian: effectively that's kind of what match-parent does
… match-parent gets that string from above, while auto doesn't and re-resolves it everywhere
fantasai: what are impls do currently is a good question
florian: they do the wrong thing
<fantasai> auto = resolve against the current element's language
<fantasai> (and inherit as 'auto', so re-resolve on each element)
<fantasai> match-parent = resolve against the parent eleent's langauge
<fantasai> (and inherit as that string, so don't re-resolve)
florian: when do you ever want to resolve against the current element's language?
fantasai: @@
florian: from my point of view, the way you have it specified now, is precisely the behaviour you want
… as far as the q element is concerned
florian: what do you want for blockquote?
florian: possibly the same, but I'm not sure
r12a: I don't think a blockquote is the same thing as a q element
… I'm just thinking off the top of my head at the moment
… a blockquote is bit of text that you indented usually
… the blockquote at the top level would take the quotes of the surrounding language
… but inside of it, it's different
florian: in that case, we're fine
… I still think we're on the right behaviour with the spec as it is plus the UA style sheet rule
fantasai: here's a fun wrinkle I think we didn't think about
… if the quote is not generated by the q element, but by ::before, which is a child of the q element
… match-parent should use the language tag of the parent to resolve to a string
florian: @@
… that's still not good enough, it's good enough to make it work, but we also need to disable that on descendant <q>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/
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
close #18
<gb> Closed issue #18
Languages / writing systems with 2 line breaking conventions in common use?
<gb> Issue 11 Languages / writing systems with 2 line breaking conventions in common use? (by frivoal)
florian: I think we conlcuded on this one last time
… and the conclusion was not the one I was hoping for, but that's a conclusion nonetheless
… some years ago Myles replied to my proposal keep-hangul
… Myles said this is probably not unique to Korean
… the i18n research into Ethiopic seems to show that it's not a one langauge problem but a two language problem already
… it's probably an N language problem
florian: are there context where you may be facing where user generated input in arbitrary languages
… might be Ethiopic/Korean/Korean so you have to have the value of the property be auto
AOB
r12a: I've been working on a FPWD for Khmer lreq
… originally I copied the stuff I have in my own site into this page
… but I'm worried about IP issues
… and it takes a long time to create the pages even though I'm just copying
… because it's quite a lot of adjustments
… and I have to matintain the same material in 2 different locations
… I've stripped out the text that is identical to the sutff in my documents
… and add a link
fantasai: I have a couple questions
… first of all, all of the work you're doing under the area of i18n research and documentation is reasonably considered part of your job, you should get paid for that
… you can ask your manager to increase the amount of time that you're alotted
r12a: I don't want to do that because I want more flexibility
fantasai: the second thing is this presents a bit of risk of what happens many years later when you and your website are not going to be around
… or github.io goes down because it's not free anymore
r12a: I want complete control of the information and no obligation to work on the information
<r12a> fuqiao, don't forget to use my mins2issue tool - the page to package the information and instructions for use should be available from the link to the repo, but of course ping me if you get stuck