– DRAFT –
I18N ⇔ CSS

Upstreaming small Kana to Kana mapping to Unicode

<fantasai> github: w3c/csswg-drafts#8442

fantasai: we have a mapping table, but annevk said it should be upstreamed to Unicode
… that seems reasonable

florian: I agree

fantasai: can the i18n WG pass that on to Unicode?
… in the mean time we can keep the table up to date

xfq: Yes, I can bring that to i18nWg
… it's useful outside of CSS

florian: who is the i18nWG liaison to Unicode?

xfq: I think it's Richard, but usually addison contacts them as the i18nWG chair

florian: sounds good, and on our side we'll do what crissov suggested

Counter Styles

florian: short version of my comments is, I think registry is the wrong track if required in browsers
… registries are not meant for normative requirements
… they're for e.g. mappings
… to make normatively required for browsers, need to put it in the spec
… and registries are not specs

florian: registries would be fit for purpose for what we did before...
… could be one as a Note
… registries would put some restrictions on how it's maintained
… e.g. can you remove names, what kind of review is necessary, maybe there's different criteria for stable / exploring lists
… this works, useful for what we do so far
… but for something more heavyweight
… Here for every thing there's a separate spec, that provides normative requirements
… but one-liner specs are still specs

[discussion about process]

fantasai: I think if we just make it non-normative, with non-normative suggestion to implement, it'll be fine.

florian: good to have some back-compat requrements in the registry rules

fantasai: More interesting question is whether to actually implement and ship these
… and if so, if all of them or some of them

florian: as long as it's opt-in on author's style, it's maybe a convenience
… there's some risk of shifting, but most of the shifts are not dramatic
… making them auto-apply is a problem

fantasai: yes, an auto-translating thing would be problematic

florian: Tab mentioned auto-translate to Japanese lettering, and nobody wants that

florian: another problem is shifting variations of numbering...

fantasai: I think we'll need i18nWG position / education to the CSSWG on these questions
… e.g. named counter styles probably OK to ship and update over time, the shifts are unlikely to break things particularly much
… but auto-translating could be a problem

r12a joins

florian: Everyone seemed enthusiastic about i18n, but we (i18nWG members) were the most skeptical

florian: For shipping the various list numbering systems, shipping them is probably fine
… most likely point of breakage would be if you are referencing individual list items
… if the numbering changes, but that's pretty rare

florian: on the other hand, really needs to be opt-in
… don't want to get the wrong or inappropriate numbering style
… translating from roman numerals to japanese traditional style is maybe not wanted/expected

florian: Other topic is if we really want a registry
… upside is can define restrictions on how it gets updated
… compared to a Note
… also lighter weight to update vs REC
… on the other hand, registries aren't supposed to contain normative statements
… if the goal is to say "you must implement all that" , can't really
… can maybe suggest that it could be implemented, but can't be RFC2119 MUST

fantasai: we don't have to make this a requirement

florian: if there's a strong suggestion that it's a good idea, probably it will get implemente

r12a: I think they wanted to establish a registry in order to keep everyone in sync

r12a: I don't believe that will happen, but I'm concerned about process
… who will create / maintain?
… We don't have it in our charter to do REC track stuff

florian: Registries aren't REC
… I think the process would be have CSSWG create it, and appoint i18nWG as one of the custodians
… so CSSWG would be in charge of maintaining the rules of the registry
… but updating the content of it can be done by i18nWG, and there's no overhead (other than what we put in the rules)

r12a: is this likely to happen?

florian: seems likely, the CSSWG resolved to do it, just pending
… if i18nWG says it's bad idea, can stop it
… but otherwise assumption is that we'll do it

fantasai: CSSWG resolved that it's a good idea (from their perspective)
… and so will do it unless i18nWG pushes back

r12a: Some issues, e.g. WebKit ships somali that should be somali-ethiopic or something
… we're not clear on the names
… we name latin-script ones after language, and others after writign system, and there are earlier styles that break the rules
… so we'd have to establish some clearer rules about how to name things
… a lot of the time, that will be the main issue
… e.g. there are some styles that are identical to each other
… only difference is the name
… and that's because... e.g. maybe some Indian language
… you name it after the language, even though shared among languages

florian: Do you have these rules/guidelines written, or just shared knowledge

r12a: neither written no shared, because only I maintain the document

florian: It would be good to write these own
… and identify where there are problems
… and point that out to CSSWG

florian: also in process of writing, might identify what are *constraints* vs what are stylistic preferences
… preferences shouldn't be registry rules, but things that should stay constant shoudl be

r12a: Do we put stuff in the registry before or after adoption by browsers?

fantasai: before

r12a: then there's no clarity on which browsers support which styles

florian: Regardless of how displayed, a registry is a table with columns
… one column can be implementation status
… and could, e.g. allow browsers to tick box of "I shipped this"

r12a: The problem is finding someone, might not be us, who would track everything
… every time there's a new release, check the new counter style
… creating tests
… gathering results every time
… and changing docs

florian: if we require tests for every counter, can just use WPT infrastructure to test if it passes now
… and tick boxes when it does

r12a: these things are easy to do, it's finding someone to do it that's the issue
… because these can change any time; e.g. I just added 30
… and didn't add tests yet
… takes a long time to make the tests

florian: We've been on the receiving end of "don't make normative changes without tests", and that's quite a bottleneck

r12a: wouldn't help authors
… right now, the way it's set up, you can set it up yourself
… unless you're wikipedia or something like that, you only need to define a few of them
… and it'll work across all browsers
… not a lot of work for a browser to add to their stylesheet

florian: a key reason for this exercise is that it would help with visibility of list... but will it?
… depends on how devtools exposes it, but supporting syntax doesn't tell anyone it's there

<r12a> https://w3c.github.io/predefined-counter-styles/test.html

r12a: Btw, I rewrote the document over the last few days
… going to discuss on Thursday
… a number of changes, one is single-click copy icon
… and then there are examples in use
… that helps identify errors in the document

florian: is there an existing policy about re-using names when the counter style changes?
… or creating a new one
… I guess if copy-pasting not as big of an issue

r12a: I don't think I've considered how much change, if any change at all needs a new name
… e.g. murati vs devanagari there's one letter change

florian: No I mean, if going through a period of reform

r12a: yes, exactly

fantasai: I think if it goes through a reform, need a new counter style
… but if correcting an error, it doesn't

r12a: consider Malayalam, updated in 1900s
… we have counter styles for those now, and just call it malayalam
… if orthography changes again, which might kashmiri
… do you change it for everyone, or mint a new one?
… might have cross-references, might break things

fantasai: if there's a change, it needs a new name
… so that authors get the numbering they expected when they wrote it
… if there's an error in how we defined it, then we fix in place

florian: should expose these questions

florian: current system doesn't have these worries, because author just defines themselves

r12a: Yes, that's why it's a great system
… yes, you have to copy the definition
… but then it just works

r12a: How's a registry different from what we have?

florian: Conceptually it's a table, but you don't have to lay it out as a table
… it's a bunch of entry, with a standard set of components

florian: the thing we'd get in addition to what you have is a set of rules to follow for the editor
… e.g. you must not add an entry unless X, or you must not change an entry, or you may change an entry in X ways
… structure of the document wouldn't otherwise need to change

r12a: we were assuming it woudln't be this document

florian: it could be

r12a: we haven't decided to give up ownership of this document :)

florian: could transfer, or could create a new document that sources from yours

r12a: I think that's a better moel, because there are ppl who prefer to use as we've set it up as we have it

florian: the registry can serve both purposes
… authors can still copy-paste from the registry, even if it's shipping in some browsers

florian: only reason to have different document would be if we want two different lists (e.g. one more complete, one with more vetting)
… alternatively maintain two lists in the registry

r12a: There are a bunch of built in styles in webkit
… that are not in this document

<r12a> amharic

<r12a> amharic-abegede

<r12a> ethiopic-abegede

<r12a> ethiopic-abegede-am-et

r12a: because I couldn't easily reverse-engineer them

<r12a> ethiopic-abegede-gez

<r12a> ethiopic-abegede-ti-er

<r12a> ethiopic-abegede-ti-et

<r12a> ethiopic-halehame-aa-er

<r12a> ethiopic-halehame-aa-et

<r12a> ethiopic-halehame-om-et

<r12a> ethiopic-halehame-sid-et

<r12a> ethiopic-halehame-so-et

<r12a> ethiopic-halehame-tig

<r12a> ethiopic-numeric

<r12a> cjk-ideographic

<r12a> lower-latin

<r12a> somali

<r12a> tigrinya-er

<r12a> tigrinya-er-abegede

<r12a> tigrinya-et

<r12a> tigrinya-et-abegede

<r12a> upper-latin

<r12a> upper-norwegian

<r12a> urdu

r12a: If you look at document in IRC, in addition to single-click copy
… and examples
… there's a downward-pointing arrow, pointing to MDN
… which should tell you which browsers support which styles
… but that table has errors
… this highlights the difficulty we'll have maintaining info about what's implemented vs not

fantasai: I think we can let MDN maintain the implementation state

r12a: also that document doesn't link to our document, should do

<r12a> https://developer.mozilla.org/en-US/docs/Web/CSS/@counter-style

r12a: filed an issue

r12a: would be good to find other places where authors go to look for counter styles

florian: maybe better than shipping in UA stylesheet would be building into devtools autocomplete

fantasai: an advantage of shipping is that we can fix errors over time, and it gets fixed for everyone

[florian gives an example]

r12a: you could fix it with ready-made counter styles

fantasai: you can do that whether we ship them or not

r12a: there also needs a rule, if you've fixed it, or if you prefer a different flavor and used the same name as built in

florian: yours wins
… if that wasn't true, I'd be against this

r12a: the thing most likely to change for a given counter style is the suffix or prefix or both
… and there are a number of those called out in the document we have, could be more
… so you might have (counter) or counter) or some other symbol altogether
… might stay with dot
… you may use different approaches within same document, depending on level of nesting or context or aesthetics
… so question is how do we deal with that in the registry