- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jan 2020 15:20:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Add ISO 15924 script codes to unicode-range`, and agreed to the following: * `RESOLVED: we are going to create keywords for unicode ranges` <details><summary>The full IRC log of that discussion</summary> <stantonm> topic: Add ISO 15924 script codes to unicode-range<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4573<br> <stantonm> myles: unicode-range takes bunch of code-points<br> <dbaron> the addition of those two agenda items was https://wiki.csswg.org/planning/galicia-2020?do=diff&rev2%5B0%5D=1569210305&rev2%5B1%5D=1570141384&difftype=sidebyside<br> <stantonm> ... bad for a couple reasons, lots of numbers and not clear what they mean<br> <stantonm> ... also when adding some like emoji, you can list all unicode points - but it changes over time<br> <stantonm> ... proposal to add keyword that lets the browsers define the code points<br> <stantonm> florian: what are the keywords<br> <stantonm> myles: issue says use pull keywords from ISO<br> <stantonm> hober: we shouldn't define these things, reference something in unicode<br> <stantonm> myles: different languages use some common code points<br> <stantonm> ... keywords shouldn't be a partition, there will be overlaps<br> <stantonm> ... space character will be in most of them<br> <stantonm> fantasai: two factors, script extensions list - some of these are assigned to common script<br> <stantonm> ... we should be looking up script extensions<br> <stantonm> ... other case is super common things - numbers, space, etc<br> <stantonm> ... alot of things assigned to common script<br> <stantonm> ... probably makes sense to include common by default, but have opt out<br> <stantonm> myles: we should resolve that we would like keywords, but not resolve on the actual keywords<br> <stantonm> fantasai: we should rely on iso<br> <stantonm> faceless2: rely on existing registry<br> <stantonm> astearns: should we have everything in the registry<br> <stantonm> heycam: do the names in the registry match normal css conventions?<br> <stantonm> TabAtkins: looks like no?<br> <stantonm> fantasai: should be a list of keywords 4 chars long<br> <faceless2> https://www.unicode.org/Public/12.1.0/ucd/Scripts.txt<br> <astearns> `Zsye 993: Emoji`<br> <stantonm> TabAtkins: if we're confident they are 4 letters, we can take directly<br> <stantonm> fantasai: think that should be fine, they need to maintain compat<br> <faceless2> example values : "Hebrew", "Devanagari", "Common"<br> <stantonm> myles: we may get it wrong, can we tentatively resolve to try something out first<br> <stantonm> florian: go with 4 letter name of long name? or not deciding<br> <stantonm> faceless2: where did four letter name come from?<br> <stantonm> florian: long name has hyphens, 4 letter is defined somewhere else<br> <stantonm> TabAtkins: casing shouldn't be important<br> <dbaron> The 4 letter script codes are always letters and come from ISO15924: https://tools.ietf.org/html/rfc5646#section-2.2.3<br> <stantonm> astearns: leave it to the fonts editors to define what keywords we pull, don't need to resolve on that now<br> <stantonm> myles: I'll also contact unicode<br> <stantonm> jfkthame: should there also be exclusion values?<br> <stantonm> hober: if you could exclude a range, you could exclude common range<br> <stantonm> myles: be careful we don't turn this into a full language<br> <stantonm> chris: even if you do a good job, when unicode adds new values you may unintentionally exclude things<br> <stantonm> ... shift burden of defining onto external body<br> <dbaron> also see https://unicode.org/iso15924/iso15924-codes.html<br> <stantonm> RESOLVED: we are going to create keywords for unicode ranges<br> <dbaron> "Zsye" is for Emoji, I think :-/<br> <dbaron> I think that's a little unfortunate.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4573#issuecomment-577727767 using your GitHub account
Received on Thursday, 23 January 2020 15:20:40 UTC