- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Oct 2021 19:29:25 -0400
- To: www-style@w3.org
- Cc: www-international@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Joint meeting with Internationalization Working Group
=====================================================
CSS Logical
-----------
- There were several points to cover in the proposal to make
switching to logical keywords easy for issue #1282 (Flow-relative
Shorthands) and the group didn't have time to reach resolution on
the issue.
- There was broad agreement that the group wants to encourage
authors to use logical whenever available.
- Of the outlined roadmap steps, they did agree to forgo the
proposed @rule.
- There was originally opposition to the !keyword syntax, but
during discussion it became clear that it might be the best
option.
- Discussion will continue in future meetings to unblock
development.
CSS Fonts/Meta
--------------
- Issue #4910 (Criteria for generic font families) was raised as a
meta issue around the criteria a generic font family must meet
but it lead to discussion and requests to have user created
generic font families. There's interest in exploring user created
generic font families so a separate issue will be raised.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/24
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Oriol Brufau
Elika Etemad
Daniel Holbert
Robert Flack
Simon Fraser
Brian Kardell
Jonathan Kew
Chris Lilley
Ting-Yu Lin
Peter Linss
Alison Maher
Myles Maxfield
Eric Meyer
Addison Phillips
Florian Rivoal
Dominik Röttsches
Alan Stearns
Miriam Suzanne
Lea Verou
Fuqiao Xue
Scribe: drott
CSS Logical
===========
Flow-relative Shorthands
------------------------
github: https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-952428897
r12a: My thoughts: i18n WG probably agrees with those: - font
fingerprinting and user-installed fonts
astearns: Let's discuss flow-rel syntax for...
r12a: internationalizers and localizers would profit from those values
r12a: A few value shorthands not supported yet
r12a: Hard to convince users to switch to logical property values
r12a: github issue converging on solution
r12a: - one approach, defining modes for use of logical properties
r12a: a solution for that approach still a long way off
r12a: Currently proposed solution seem to fit long term goals
r12a: suggest to focus on the last bit of short term solution
<fantasai> Note that "short term solution" here is also part of the
long-term solution.
<fantasai> We're not intending to have a stopgap
astearns: miriam, you had a summary on most recent solution?
miriam: Starting with shared understanding of the goal
miriam: We don't want to only make shorthands available
miriam: we want to make logical properties as a long term usage
available
miriam: Is there a way to make flow-relative syntax first, rather
than sprinkling it in on top of physical syntax
miriam: We can't just append -logical on everything
miriam: you might have cases of mixed use
miriam: We imagine an end state where you can use an universal toggle
miriam: Change existing shorthands
miriam: which coordinate space they're in
miriam: We'd need a lexical mode switch
miriam: that would toggle it just for stylesheet
miriam: Scoping a section of your code, with an @ rule, which mode
you're in
miriam: allows you to do parts of the stylesheet in a mode
miriam: Several years process of
miriam: describing each part in each syntax
miriam: how we could get to a toggle to switch
astearns: Would it be possible to have a mode switch, affects all
properties, even those props would not have a way of
expressing one mode of values
miriam: wouldn't that be backwards incompat
fantasai: We have a couple of properties of position-based values
fantasai: We have to go through of all of CSS - is there a physical
or logical variant?
fantasai: If we skip one, and have a mode switch...
astearns: We could go through: these are props affected by mode switch
astearns: without having the ability to say in each property's value
def
astearns: Eventually, we could have a syntax to allow you to do it at
the property level
fantasai: We need to get to the point where we look at all property
fantasai: We might as well do it a the property-level
fantasai: in cases in layout you'd want to relative
fantasai: Use cases in layout where you'd want to go per property
florian: We just ran into a use case in vertical layout
florain: Add an entry to each property def
florian: Go property by property, define what the default behavior
is, then what happens if you do switch
r12a: Once a switch is defined, and once a set of properties is
defined to respond to that
r12a: Hard to change later: properties that should now respond to the
switch
fantasai: Yes, that's why we have to do all at the start
miriam: We might also have functions, as well as properties
miriam: with logical vs. physical behavior
florian: Might apply to gradients - where there's an angle
r12a: Running into this problem, like to have a clean slate of
logical properties
r12a: Four value properties, Most of the properties already have
flow-relative versions, such as margin-block-start etc., but we
don't have it for the shorthands. Can we solve the shorthand
issue while solving it for all the properties?
astearns: Two ways: 1) extend logical scheme we have been using
astearns: get last things done in the interim
astearns: 2) figure out which other values... (missed)
miriam: How to proceed?
miriam: either -... or !...
miriam: Need to decide which to use
miriam: People are confused by the word logical
<Rossen> !logical is hard to read from afar... my preference would
be -logical
miriam: flow-relative sounds more reasonable to me
lea: Two things: ! keywords work for every property
lea: @rule switch is a good direction
lea: It should be possible to override it for smaller parts of the
stylesheet, i.e. a specific rule
fantasai: that's why the @rule should have a block syntax
astearns: advocating for only the @rule having the switch?
<Rossen> I also agree that "logical" is a very implementation
specific term.
lea: It would be nice to have different names for one-off cases
lea: Problem with an @rule that's a block
lea: follows a need to indent the whole stylesheet
miriam: Our proposal: could be at the top or as a block
<fantasai> https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-952428897
florian: For props that have a direction in their name, like
padding-left & padding-inline-start, but we don't have
margin-physical / margin-logical etc.
florian: We have a version of the name with a logical keyword rather
than a physical one, but we don't have a generic *-logical
syntax yet
florian: find !syntax much more appealing
florian: Do think we need to review all props, except those that have
direction in their name
florian: If we have project where we change something outside of each
properties - that's difficult and not gonna happen
florian: If we don't proceed property by property, with
"micro-switch" we're not getting to the goal
florian: even though it wouldn't be quite as global
argyle: Fan of logical properties
argyle: Counter to florian's proposal - I find it natural to start
writing padding-logical, margin-logical
argyle: It's a shift in my mentality - small shift to
padding-logical, margin-logical
argyle: Regarding @rule mode
argyle: Worry that people add that at the top, then have imports ->
side effect
TabAtkins: They're not propagating to the imports
argyle: (missed)
lea: Re miriam: having these two modes
lea: Would be confusing to learn different forms of the same @rule
lea: We could change scoping to be the nearest block/scope (?(
lea: Re florian: !keyword
lea: Concerned to have two global concepts to do the same thing
lea: it's okay to have to type an extra word
lea: It could be a separate keyword, doesn't have be !keyword
lea: I'm against having !keyword at the end of property value
<lea> takes as long to type as a keyword in the property value, but
!keyword is seen as a global syntactic construct whereas this
only applies to certain properties
Scribe: TabAtkins
fantasai: I'm very strongly against separate keyword
fantasai: As seen in this comment we posted, it complicates parsing
significantly already - some props have complex grammars
that this interferes with
fantasai: We need to keep it out of the value space so we can add it
to literally any property without messing with grammars.
<lea> fair point. I'd vote for property names then
Rossen: It sounds like there's still a lot of design to do here
before we have the final syntax
Rossen: When we started this a number of years ago the term "logical"
was kind of impl-motivated; it stuck in the spec.
Rossen: We've been referring to it as logical in the CSSWG and
convinced ourselves it sounds good, but not sure it's the
best word for authors. Perhaps rethink this.
Rossen: But regardless, need to consider if we're getting into a
property explosion by adding -keyword to everything, or the
keywords/bang-keywords
Rossen: One way or the other we should unblock Richard and commit, be
explicit about what would allow us to do width/height and
other box model properties
Rossen: Or be explicit that we're not doing this
miriam: In that spirit, I think we can punt on the at-rule and how it
works
miriam: because it's clear the first thing to solve is
property-by-property, with global toggle later
miriam: What convinced me about florian's argument is I think it's
very confusing to imagine how the cascade works with multiple
margin shorthands with different names
miriam: But with a single margin shorthand that's flagged, that's
easy to understand. Setting 'margin' and 'margin-logical' a
little confusing, while setting 'margin: ... !logical', the
last one wins as normal
<lea> Another thing against !keyword: I find it confusing that
margin-left: 3px !logical; would still do margin-left.
<fantasai> lea, that would be invalid
<lea> fantasai, so !logical would be invalid at parse time on most
properties?
<fantasai> lea, yes
<lea> fantasai: hmm. Then maybe it's not so bad.
jensimmons: In some comments I heard "it doesn't seem too hard to
write 'logical' everywhere"...
jensimmons: I want to articulate a vision where front-end devs don't
have to remember to write all these things to do things
logically, especially since there will be bad unintended
consequences if they forget some of them
jensimmons: But mostly, most websites don't think about i18n but
browsers are increasingly translating content *for*
users - push a button and you have swapped text
jensimmons: So I want to get into a place where by default the web is
logical, and physical is a non-default option
jensimmons: So everything we're talking about with individual things
makes it harder to think logically
astearns: So it seems we have consensus to punt on the at-rule for now
astearns: In favor of working on individual properties right now
astearns: Need to figure out what the switch will look like.
astearns: Think it'll be clearer if there are examples of what the
options would look like.
<lea> fantasai: how does it work with variables? --foo: 5px !logical;
margin-left: var(--foo); IACVT?
<TabAtkins> lea, yes
<TabAtkins> lea, well, hm, i'd ahve to think about it
<fantasai> lea, iirc !rules in variables don't flow through to the use
florian: Lea seems to be walking back on opposition to bang-keywords
in chat, does that need to be discussed?
lea: It doesn't seem so bad now
fantasai: It has to make things invalid, otherwise if e.g. we define
logical margin now and logical padding next year,
padding: ... !logical; will change meaning next year and
that's bad
florian: Also you can use it in @supports to check
<TabAtkins> fantasai, we only have one example of a !keyword so far
and it applies to cascade rather than parsing, so can't
necessarily generalize
CSS Fonts
=========
Criteria for generic font families
----------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/4910
<r12a> Writing systems around the world use a wide variety of
alternative writing styles. These writing styles may support
functional differences between text, or may have cultural
relevance, in addition to aesthetic concerns.
<r12a> The inability to control what style of font is delivered
during fallback can be problematic to international users. A
Thai user may not want text to fall back to a looped style if
an alternative non-looped font is available. A Kashmiri or
Urdu user will certainly want content to fall back to a
nastaliq font, if one is available, rather than one of the
naskh fonts they are likely to have on their system. And so on.
<r12a> The current set of categories for generic font fallbacks are
modelled on a Western world-view, and don't map onto the needs
of international users. Trying to stuff the needs of other
writing systems into the current Western categories is not
really feasible, not to mention that it potentially creates
confusion for would-be users.
<r12a> Browsers should allow users to define their own generic
fallback fonts for writing-system relevant categories. An
attempt may be may to enumerate those categories in a
registry, or users may be allowed to define them for
themselves. However, apart from some defaults, the browser
shouldn't attempt to restrict which fonts apply to which
category – users should be able to match fonts to categories.
The mechanism involved could be very similar to, or perhaps
even just an extension of, existing mechanisms for defining
font preferences in browsers for proportional, serif,
sans-serif, and monospaced fonts.
myles: I hadn't seen this before, interesting
myles: You mentioned a user-created generic font family
myles: Are you describing that a user could make a font-family named
"myles" and a website could use it?
myles: Or that the generic families are still defined in CSS, but
users control what fonts map to the family
r12a: Yes, one of those. More details need to be worked thru.
r12a: Discussion about English-specific details of the existing
generic fonts
r12a: But having a registry could be slower, but would give us
control over what's available
r12a: There's lots of different styles for non-latin scripts
r12a: But the main thing is I want a mechanism where a user can
control which fonts belong to which category
chris: So there's two ways we can do it with generics
chris: One way is, we had five originally, two are stupid we can drop
them, and we don't add more. If you want fonts use a webfont.
Workable, but not everyone will have fonts.
chris: The other way is to have a whole bunch of categories which
don't map to anything for many scripts
chris: So the issue is a clash with existing terms - if we add a
"myles" generic, need to figure out how that interacts with
webfonts named "myles"
chris: I think the "thousand flowers" approach is where to go, we
just need to be clear about it
astearns: I'm a little concerned about this user-definitions scheme,
that we'll put a lot of burden on users of a particular
language
astearns: Yes, perhaps there's a registry entry for nastaliq, but if
it's user-defined then every user has to fiddle with
settings to create a nastaliq entry and associate a font
astearns: I think if we do a registry there should be a way to
graduate it to "official" where it's supported by default
in browsers
Peter: Having the user have the ability to create a generic family
doesn't seem that useful - how does the author know what the
users are exposing?
<myles> +1 to what Peter is saying
Peter: Having the user be able to associate fonts with a generic
family does help with another issue on the list
Peter: Relatively small communities get a preferred font on their
system
Peter: And if it's something the browser uses but doesn't expose tot
he content, that addresses the privacy/fingerprinting concerns
Peter: If we have a thousand generic families, that seems like a mess
Peter: Even in western-centric families, they quickly fail
Peter: Type doesn't fit nicely into categories
Peter: So you have an issue - what does the author consider a
'fantasy' font vs the end-user, and are they agreeing?
<chris> fantasy should be deprecated honestly
<astearns> namespace problems could be solved by using functional
notation: generic-font(myles)
Peter: If the user goes to a site do they expect their font to be
used on a given author's site?
r12a: I think content authors could choose a font, and the problem is
what if it's not available on the user's system
r12a: Like for nastaliq, Urdu speakers really don't want a naskh
font, they always want nastaliq
r12a: So I think those users need a way to define what happens when a
particular writing style is used
<chris> yes, I like the idea of a generic() function
florian: I think a few of the problems aren't that bad
florian: If the list is populated by users it would be confusing -
extensions could potentially expand for them
florian: If we have a bunch of UA information - a browser on Mac
knows what fonts the system ships with, they can pre-populate
florian: But for the registry, we can graduate to official only if at
least one browser wants to ship with a default assignment
florian: So then authors have a list of known groups, and users/UAs
can add more
florian: So yes, there are many, but only supported ones hit the
registry
florian: For the name clash, we can just namespace into a function if
we need to
myles: This is a meta-issue that's been going on for over a year,
lots of comments and participants
myles: Often when CSSWG discusses meta-issues there are opinions but
not much issues
myles: Maybe we want to say "no policy, but we'll discuss individual
requests as they come" and close the issue?
r12a: That's sort of avoiding the problem
r12a: We think users need a solution
myles: I'm not saying we wouldn't have new changes, I'm saying we
could discuss those for specific proposals rather than having
an overarching principle
astearns: This issue is about the principle, and was started in part
to *shut down* discussion of new generics
astearns: Think it makes sense to have an issue about how to have new
generics
fantasai: I don't think it's a good idea to have user-defined
generics, makes more sense to have them in the spec
fantasai: Need to be more open to having generics because there are a
lot more necessary
fantasai: Richard brought up a point about users wanting a certain
style of font over another
<astearns> I think the idea of having user tweaking of UA-defined
generics is really interesting
fantasai: That should be handled in user settings by setting the
generics to the appropriate style
fantasai: That doesn't need a new generic
fantasai: When it is needed is when a variant conveys meaning
fantasai: Like in English using italics for emphasis. Those are
shifts in the family but it's not really a different shape.
fantasai: [missed]
fantasai: Those kinds of things describe a shift
fantasai: When those aren't bold or italics but rather a style of
font we need to make sure the fonts have that style
fantasai: So we need generics for those cases at a minimum
fantasai: Maybe for more reasons, like our recent 'rounded', which
can be done case-by-case
fantasai: But we need to be more open to generics that only have
meaning for some scripts
<r12a> international users use specific font categories of font to
change the font style where we might use bold or italic in
English
fantasai: While trying to have them be as broad of a range as possible
astearns: Out of time, but I think it would be good to have a new
separate issue about how to introduce new generic fonts
families syntactically
<chris> I volunteer to raise the new issue on adding generics
astearns: Not this meta issue about whether to do it at all
astearns: We didn't get to the user-installed fonts issues
astearns: But we have a longer-form meeting scheduled next week
<chris> yay!
astearns: We could invite you at a scheduled time block
astearns: I'll contact you about that
Received on Wednesday, 27 October 2021 23:31:08 UTC