Meeting minutes
<fantasai> https://
<fantasai> https://
<fantasai> https://
fantasai: I think the most exciting thing I have is that the CSSWG is working on an anchor positioning proposal
… which has been getting a lot of discussion lately
… draft ^
… slide deck ^
… the thing interesting for i18n is the way that different proposals handle writing mode relative positioning and styling
… that's an ongoing discussion
… one of the interesting things about the newer proposal is that it opens up the possibility to choose physical/logical side
<fantasai> https://
fantasai: also about backgrounds, also ongoing
… the other thing that's interesting about writing mode relativity is which writing mode are we using
<fantasai> https://
fantasai: when you have an element and you're using the logical property, because of the limitations and how we calculate the cascade, we can only use the writing mode of the element itself
… but a lot of times when you're doing layout with writing mode you want the writing mode of the container
… it might be interesting from an i18n point of view to know which writing mode you want to resolve start vs end relative to
<fantasai> w3c/
Upstream small Kana to Kana mapping to Unicode
<fantasai> ->
<fantasai> w3c/
fantasai: Not sure if we asked yet for i18n to upstream the small kana to kana mapping to Unicode
… I don't remember if we actually did it or not
<fantasai> https://
r12a: I don't think we did that
<fantasai> w3c/
fantasai: on the topic of escalating things to Unicode, do we need to do anything?
Incorrect text-transform capitalize behavior for Catalan geminate Ls
r12a: I looked at UAX #29, didn't see any problem
<gb> Issue 29 dog food the character template in specdev and update TR (by aphillips) [task] [BLOCKED!!]
fantasai: there just needs to be a test and we can close the issue
TPAC
fantasai: is there anything we should put on the schedule for discussion at TPAC?
xfq: I think we can go through our i18n tracker needs resolution issues and see if there's anything we should discuss
xfq: Still open actions for font generics and for logical properties
xfq: other than that don't have anything for now
xfq: but we do have a lot of tracker issues against CSSWG drafts repo
xfq: might want to take a look and see what we can add to TPAC agenda
xfq: 2 things we want to discuss today: quote character issue, and other thing from Addison
[audio cut]
xfq: Unicode code-point styling issue
fantasai: why using Arial specifically?
r12a: compact and clear, good fallback
Add .uname and .codepoint to style characters inline
r12a: and another reason, I forgot
fantasai: remind me why are we using Arial specifically?
r12a: I don't remember
… there was a reason
fantasai: and you went back to not having a space between the char and the code point
… I think that's a bad idea
… I think there should logically be a space there and we should allow it to stay there
… I think it's more important to have spaces where space is belong to than have spaces be exactly the width you want
… the next question I have is do we need the class=uname?
r12a: yes
… we actually use that outside of the code point markup sometimes
fantasai: for uses outside of the code point, is that documented in the readme as well or is that a secret feature?
r12a: it's one of the things that we use, but whether we decided that would be for general I don't know
fantasai: I think it would make sense to just use code
r12a: it provides the semantics because code is not really the semantics for the Unicode character name
.uname, .codepoint code { ... }
r12a: if you don't have uname, you could end up just like normal code, which is not what we want
… I'm hoping that we don't need to type all of that stuff and respec and bikeshed will generate the markup
fantasai: that seems quite reasonable for them to do
[[U+3000]] ?
fantasai: we'll probably want to help them identify what's a good shorthand
fantasai: is that something we can pull from a database?
r12a: there's a Unicode data file, the main one
… and you can distill the information from it
fantasai: from a person like spec editor, I think the easiest thing generally to have something expand out to just identify the code point by number
… I kind of am not sure listing the character is as necessary
r12a: it depends
… using the number is one of the possibilities
… in the case of RLI or no break space @@2
fantasai: it should be in bdi
fantasai: the bdi element, I think in one of the stylings I had put a background on it so you could actually set it apart from the rest the text
… for example if you have a full width character vs a half width char, it makes it much easier to see what's actually the difference
r12a: it didn't look good and not useful for the majority of cases
… andif you use an image you don't need that anyway
fantasai: I'll take a look again at the latest version
… major thing I think is there should be a space
Encourage CSS to make some edits
<r12a> w3c/
r12a: as far as I can tell, this is just a question of some editing
… which I didn't think was problematic
… I don't think this should take very long
… it will make things a lot easier
ACTION: fantasai to make the edits of CSS #5478
<gb> Created action #35
w3c/
close #27
<gb> Closed action #27
https://
<atsushi> https://