Meeting minutes
<addison> gb, find actions with label CSS
<addison> gb, help repo
<gb> addison, the command "repo: xxx/yyy" or "repo: yyy" adds repository
<gb> … xxx/yyy to my list of known repositories and makes it the
<gb> … default. If you create issues and action items, they will be
<gb> … created in this repository. If you omit xxx, it will be the copied
<gb> … from the next repository in my list, or "w3c" if there is none.
<gb> … You can give more than one repository. Use commas or
<gb> … spaces to separate them. Aliases: repo, repos, repository,
<gb> … repositories. See also "gb, help use".
<gb> … Example: "repo: w3c/rdf-star".
<addison> gb repo: w3c/i18n-actions
<addison> gb, list actions with label CSS
<addison> gb, list actions
<addison> gb, list open actions
<addison> gb, status
<gb> addison, the delay is 15, issues are on, names are on; and no repositories are specified.
Repository: w3c/i18n-actions
<addison> gb, list open actions with label CSS
<gb> Found actions in w3c/i18n-actions: none
<addison> gb, list open actions with label css
<gb> Found actions in w3c/i18n-actions: none
<addison> gb, list open actions
<gb> Found actions in w3c/i18n-actions: #25, #24, #23, #22, #19, #18, #16, #15, #13, #12, #11, #10, #9, #8, #7, #6, #5, #4
<addison> gb, list open actions with label css+i18n
<gb> Found actions in w3c/i18n-actions: none
<addison> gb, list open actions with label DONE
<gb> Found actions in w3c/i18n-actions: #25, #24, #22
<addison> gb, list open actions with label css
<gb> Found actions in w3c/i18n-actions: #18, #13, #11, #10
https://
<atsushi> https://
ACTION: addison to ask about status of html because of ruby
ACTION: addison to ask about status of html because of ruby
<gb> Created action #26
Action Items
<addison> gb, list open actions with label css
<gb> Found actions in w3c/i18n-actions: #18, #13, #11, #10
<addison> #18?
<gb> Action 18 Have informal explanation sessions about counter style translations with csswg members (on frivoal, fantasai)
<addison> #13?
<gb> Action 13 Make sure generics are comfortable to read in the content language (on frivoal)
florian: just had f2f, need to get the group work on #18
<addison> #11?
<gb> Action 11 Triage all css properties to determine which are logical, physical, or na by default (on frivoal)
<addison> #10?
<gb> Action 10 With florian triage richard's article into a list of potential generics (on fantasai)
florian: hope to have plenty of time in August
Line-breaking in SEAsian languages
florian: from a Unicode line breaking spec point of view, Latin in SEAsian languages do not have wrapping opportunities around them
… that's not helpful for the langauge
addison: you mean Thai etc.
florian: Thai, Lao, Khmer etc.
… when your UA doesn't know about the languages they're supposed to break anywhere
… like Javanese
… Thai script used to write the Thai language
… but also other languages
… and dialetcs
addison: I know r12a raised specific issues in the sealreq issues
… Thai dictionary is only for the Thai language
florian: so far how this work or doesn't is magic in CSS
… you can do it manually if it's not supported by your browser
… if you wrap a language using the Thai script but not the Thai language
… you might put wbr elements in your text indicating the breaks are expected
… but it's not Thai
addison: it might break in the middle of a word
florian: in CSS there is no way to dectect SEAsian languages
… I want to hear your opinion
… you can break anywhere
… if you add markup and say break anywhere
… then it's not 'nowrap'
… ideally you just leave it to the browser but if you want to do it yourself
… if you know auto doesn't work reliably can you turn it off?
<addison> https://
<addison> https://
florian: if there's no dictionary the preferred approach is to break anywhere instead of let it overflow, right?
<addison> https://
r12a: there are different kind of line breaking behavior in SEAsian languages
florian: I understand that in Javanese etc. the cluster is more complex than Thai
<addison> https://
xfq: In Javanese, the initial consonant of a word may be added to the last consonant of the previous word
… so line breaking do not necessarily break text at word boundaries
florian: my hypothesis is 1) browsers should do it automatically, including taking the language tag into account 2) when you want to do it manually, what authors would want to to manually insert wbr or zwsp, and turn off dictionaary based linebreaks
r12a: I'm searching for an issue that I'm sure I wrote which talks about all of this
Is it w3c/
florian: if the user only has the Thai dictionary, are they ok with using the dictionary even if it's not great, or are they completely different?
r12a: I think it's a bit of both
<r12a> https://
r12a: the author should be able to control
florian: if it's not accurate but similar to the Thai dictionary then we should probably apply it, if not, then it would be good not to apply the dictionary
florian: is there a grouping for the Javanese-like languages and the Thai-like languages in Unicode?
r12a: no
… grapheme clusters may be going to change to mean orthographic syllables in Unicode
… base char + combinging char
… sometimes called a combining char sequence
… in practise the combining char sequence is equivalent to orthographic syllables
florian: in the future Unicode might make grapheme clusters mean orthographic syllables?
r12a: for some languages
… for Devanagari it might not be the case
r12a: current grapheme clusters is just base char + combining chars
<r12a> https://
r12a: you may want to see this page
… it's update significantly
… Javanese, Lisu, Tibetan
<r12a> see also https://
Ruby
florian: I'll come back to this group
… I was told by Tess from Apple that the HTML WG might be disbanded so we need to figure out where we put the ruby markup document
r12a: Myles has some threads and I've been trying to read those
Other issues
florian: word boundary line breaking?
r12a: I came up with another problem yesterday
<r12a> w3c/
<r12a> w3c/
r12a: in N'ko, Hebrew, Arabic some text should be slanted to the left
… in N'ko it's the default
… in Hebrew it's author's choice
… Chris said you can use things like -13deg
… but if there's an existing italic font in the system then the italic font will be used
<r12a> w3c/
fantasai: css doesn't know the left leaning nature about italics
… that only works with variable fonts
… if you want to create an oblique font that leans to the left but you don't want to create a variable font
r12a: if you see the image they're not variable fonts
fantasai: if the font wants to provide both left- and right- leaning fonts
… it needs to be a variable font
r12a: you need to have different font faces
fantasai: you said the font designer choose left-leaning or right-leaning, what if the font designer decided to choose both?
r12a: italics is extremely differnt from oblique fonts
… see the Ukrainian image
… I think if you specify a `font-style: oblique -14deg;`
… is there an italic font for this , if so then use it, if not then apply the oblique
florian: I'm not sure that's right
<r12a> https://
r12a: that seems to be the browsers are doing according to my test
florian: if people ask for oblique it should never fall back from italic to oblique
<addison> > The font matching routine will select a font to use which is closest to the requested angle
florian: font-synthesis is kind of strange, if you're asking for oblique it's less useful because it's a lot easier to synthesize than italic
addison: in some cases extra oblique is needed since the glyph is already slanted
… if you just allow the closest but the closest might be in the wrong direction
florian: if you want italic say italic, if you want oblique say oblique
r12a: the oblique value comes with an angle, it seems to aim at synthesize it, not to choose an oblique font
florian: if you ask for 14deg and there's a 15deg one it's probably fine, if you ask for 14deg and there's a 37deg one then maybe not
r12a: maybe the content author is happy with the approximate number but maybe the content author wants the exact number
fantasai: I think leaning vs upright is a more important distinction than leaning in different directions
… I probably care less about what exactly the angle is
addison: are people talking about italic, and oblique is a side effect, or is it strictly about oblique?
florian: if it's not a variable font I don't believe the UA knows if a font is left-leaning
… should we add a descriptor in @font-face?
<gb> @font-face
fantasai: probably
florian: descriptor in @font-face say whether a non-variable font is left-leaning or not
fantasai: this is an under investigated corner of the spec
… I think we need to look into this
… if we need to OT to provide this metadata
florian: for variable fonts the UA would know
r12a: this has to work for non VFs
florian: maybe one of you could look into an N'ko font including the Latin glyphs and see if the Latin glyphs lean to the left or right
r12a: if the Latin leans to left and the Hebrew leans to the right then the result doesn't look great
florian: 2 problems
… 1. fix existing selection of oblique text
… 2. we have no way to say if you want to italicize leftwards
<fantasai> Open
<fantasai> Open
<r12a> w3c/
ACTION: florian to write comments about oblique and italic options on css 8914
<gb> Cannot create action. Validation failed. Maybe florian is not a valid user for w3c/i18n-actions?
ACTION: frivoal to write comments about oblique and italic options on css 8914
<gb> Created action #27
<addison> gb, florian = frivoal
fantasai: we should start to assemble an agenda for TPAC
… in the CSSWG repo we have the labels 'Agenda+ i18n' and 'Agenda+ TPAC'
… we should flag both of those labels
<addison> @Bert, gb doesn't like labels with + in their names, eg. css+i18n or probably "Agenda+"
<gb> @Bert