Meeting minutes
<addison> trackbot, prepare teleconference
https://
Agenda
(discussion of agenda)
Meeting recurrence
addison: r12a is having technical difficulties, so maybe a bit tricky to discuss all topics
addison: What should be our meeting timing / cadence?
florian: This time doesn't always work on Tuesdays, but it works fine for today
fantasai: 2am is workable once a month
florian: My standing conflict is 2nd Tuesday of the month; any other is fine
addison: Likely target for next month would be the 19th
florian, fantasai: wfm
addison: 3 topics on our backlog
addison: r12a published his article about generic font families
addison: hesitate to discuss without r12a
florian: Meta-comment about the issue, wrt how to proceed
… I think there's 3 subtopics
… If we're planning to add a lot of these, how do we manage them?
… is this a spec, a registry, who is managing the list?
… Another question is, technically, how do we add new generics? Do they have fallbacks? Are they defined over all of Unicode, or certain areas? What syntax do we use?
… Lastly which [missed]
florian: fantasai made a statement about this, a good criteria for the minimum we should do
… not necessarily the limit, but a good place to start
florian: wrt fallbacks, syntax, maybe primarily discuss in CSSWG
<addison> ack
addison: Where we started from, from our conversation with fantasai previously
… first question was, are there any cases that would meet the bar for a generic
… our understanding was that a generic needed to be something where the appearance was physically different for a reason beyond stylistic preferences
… needed to convey a semantic difference
… so I think that's what r12a's article was about, showing different cases where they might rise to the level of meeting that bar
… If we agree that's true and we agree what the bar is, then we could try to fool around with how would we do this
… what would these generics mean, and how would we tell browser vendors
… if other criteria aren't true, then it would be a waste of time to codify
… so first question is, whether those are the right critera and are we identifying items that fit them
xfq: I agree that Florian's points are for discussion
xfq: One thing I'm not sure about is Unicode
… from what I understand this has more to do with fonts
… doesn't have much to do with Unicode stuff
… if people want to restrict a font for a specific range of characters, they can use existing mechanisms like unicode-range descriptor for @font-face
florian: So for the moment, serif/sans-serif apply to all of Unicode
… e.g. serif is Mincho, not Gothic, in Japanese
… If we want to define this for all generics, then we need to know not just what Nastaliq means in Arabic
… but also what it means in Greek
… Or otherwise, we need to define some generic fonts that don't fall back
… I think we have a resolution that they will fall back, and I don't think it's reasonable to discuss what nastaliq means in Greek
xfq: As long as a suitable font found on the system
addison: but a Nastaliq font would likely cover Arabic and basic Latin, but not Greek or Cyrillic or Han ideographs
addison: it doesn't have any meaning there, but it might imply serif, say
<atsushi> +1 for covering latin-1 etc., similar request raised in JLreq also
florian: we might want to define that
… for the new type, it falls back to serif or it falls back to sans-serif, or you have to say yourself
florian: The other thing I wanted to say wrt meeting the bar, I have not read r12a's article (still need to)
… the bar set by fantasai is where we "really ought to do something"
… I believe that set is not empty
… and not doing something for that set would be a disservice to the Web
… Might be useful to go further, but at least do that
fantasai: for the fallback behavior, the current font generics fall back to @@, for the new ones they define what happens, whether they're transparent, the behavior over Unicode
… I think for this we're gonna have a type of generics, not for the full range of Unicode, might have a functional notation for generics
… just an idea
florian: we already have fallback
fantasai: we do already have fallback
florian: it's not incredibly useful to put the fallback into the parens
… we could define for new generics which of the three it falls back to (serif, sans-serif, maybe monospace)
fantasai: But what do you get for Greek of the last font in the list is nastaliq?
florian: unsure, maybe we need to define for each type what it falls back to
florian: Also worth noting that functional notation would make the property invalid
… this was suggested as a way of namespacing the generics so that they don't conflict with named fonts
… name conflicts are increasingly likely as we add more generics
… so we need some kind of syntax to distinguish
ACTION: Florian to read r12a's article on generic font families
<trackbot> Created ACTION-1221 - Read r12a's article on generic font families [on Florian Rivoal - due 2022-11-29].
fantasai: For some of the fonts, seems like need for generic is definite; some are fuzzy; some are language-specific, this should be handled by treating generics differently depending on lang tag
addison: r12a's goal was to write down what we know
addison: Consider nastaliq, is it tied to language or is it a font style?
… affects legibility
florian: Might not meet the bar. Meets the bar of it's important
… but it's not clear that you have documents that contain both nastaliq and something else, and if you lose the distinction you lose information
addison: unclear you'd have document where they're validly mixed
… maybe if you have Arabic document talking about Urdu
florian: it's very relevant, but not very relvant contrast
… that's kind of thing that doesn't meet fantasai's bar
… however, might also be nice to have, because it's a thing people want
… but if the browser is smart enough, which it should be, if you say it's Urdu it should make it nastaliq without you telling it to
… because that's how Urdu should be rendered
… for Persian, less clear, could have either
addison: or kufi, but ...
florian: That's second bucket: culturally important, but not essential in the same way
addison: My suggestion is have a read through the document
… maybe some meet the bar and some don't
… assuming there are some -- and some feel pretty clear -- then can go forward with what to do and how to do it
florian: what's best way to provide feedback?
addison: probably written feedback, if you have time
… because then we can do some offline work, and think about it
… and then maybe when we come together, be ready to make decisions
fantasai: in the CSSWG we need to be clear whether the semantic distinction is required
… we might also want to add generics for other purposes
addison: So read the article, list which ones meet the bar, and if list is zero discuss why
… and if some meet the bar, then we have a concrete example and we can go, ok, how do we do this
florian: Maybe fantasai and I can take a joint action item
… and as we do this, maybe we find subcategories for the rest
ACTION: fantasai: with florian triage richard's article into a list of potential generics
<trackbot> Created ACTION-1222 - With florian triage richard's article into a list of potential generics [on Elika Etemad - due 2022-11-29].
+1
Flow-relative syntax for margin-like shorthands
https://
fantasai: I think we have a good set of minutes ^
… we had a debate on the syntax
… notation about whether that property is logical by default, physical by default, or not applicable
… the triage needs to be in the definition table
… we didn't have much agreement on the syntax options
… I don't think people are object to this idea
… if you write logical-first, it's quite natural to have things like margin to be logical
… but for box-shadow etc. it might make sense for it to stay physical
… so it doesn't end up becoming a 'flow everything'
… the action on us is to do a triage on all properties of css
… the action on i18n is which should stay physical
addison: I understand David's assertion on direction of shadow, it's not really about bidi
… but I don't know we're going to jump out of the box: 'this should be logical'
florian: we do have a an index of properties
… @@1
<florian> https://
addison: if you have a list of items you propose not to mirror, it would be easy for us to have a look at that list, like 'oh that's fine'
florian: this is a list of everything, not a triaged list
fantasai: we might want to have a categorized list, like these are the box properties
florian: maybe authors can deal with that manually
florian: maybe we need an allowlist, block list and a sensible default
fantasai: or maybe we need modes like mostly-logical, mostly-physical, etc.
fantasai: if we get the metadata and declaration-level syntax sorted out, I imagine authors come up with tooling in preprocessors
addison: how to make it happen relatively organic and relatively early?
fantasai: I don't know. there's definitely some people who would do that
… some people working on translations have to think about these things
florian: in terms of CSSWG we have enough people who understand this but we have limited people who use it on a daily basis
florian: the challenge of adding metadata and triage is that css is a moving target
… it has to be maintained
fantasai: we could add it to the property definition table
… the triage could be a PR against the entire repo
… the property definition table don't shift that much
florian: I'm not saying we shouldn't do this, but we should consider the timing, we should not do the triage, change it, and re-do the triage
… fantasai and I should probably do this together
ACTION: florian: triage all CSS properties to determine which are logical, physical, or NA by default
<trackbot> Created ACTION-1223 - Triage all css properties to determine which are logical, physical, or na by default [on Florian Rivoal - due 2022-11-29].
https://
<addison> https://
[css-syntax] custom property names too permissive, require namespacing rules
https://
florian: why do we need to something about it?
https://
fantasai: I think the CSSWG has a resolution on it already ^
addison: why don't we queue that and put it on the next meeting?
florian: thank you and good night elika!