[CSSWG] Minutes Joint CSS-Internationalization Telecon 2021-10-27 [css-logical] [css-fonts]

  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
      - Discussion will continue in future meetings to unblock

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.


Agenda: https://github.com/w3c/csswg-drafts/projects/24

  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
  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
  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
  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
  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
  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
  <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
  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
  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
  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

  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
  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:06 UTC