[CSSWG] Minutes Telecon 2023-10-04 [css-syntax] [css-text] [css-ui] [css-grid] [css-masking]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Syntax

  - RESOLVED: At top level, if you see a rule that looks like a custom
              property, we consume as a rule and throw it away as
              invalid (Issue #9336: Dashed-ident rules and error
  - TabAtkins will look into using a more generic term than 'nested'
      for the flag for mixed declaration+rule contexts

CSS Text

  - RESOLVED: Straw poll for naming between -wrap and -allow. Values
              are wrap|nowrap (Issue #9102: Move "balance | stable |
              pretty" out of text-wrap)


  - RESOLVED: Values will be fixed | content (Issue #7542: Allow
              <textarea> to be sized by contents)
  - The group will run a poll on form-sizing vs field-sizing, with
      values content and fixed

CSS Grid

  - RESOLVED: Drop align-tracks, justify-tracks from Masonry spec
              (Issue #8207: Masonry - align-tracks / justify-tracks
              potentially not desirable for accessibility)

CSS Masking

  - RESOLVED: mask-border properties will match border-image wrt
              animatability (FXTF issue #529: Interpolation of
              mask-border properties)
  - RESOLVED: mask-type is not a longhand of mask (FXTF issue #528: Is
              mask-type a longhand of mask?)


  - The group will update “Animatable” lines to “Animation type” in all
      propdef tables (FXTF issue #521).


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Oct/0000.html

  Tab Atkins
  Stephen Chenney
  Elika Etemad
  Robert Flack
  Chris Harrelson
  Ian Kilpatrick
  Vladimir Levin
  Alison Maher
  ChangSeok Oh
  Florian Rivoal
  Alan Stearns
  Miriam Suzanne
  Lea Verou

  Yehonatan Daniv
  Jonathan Kew
  Khushal Sagar
  Bramus Van Damme
  Sebastian Zartner

Chair: astearns

Scribe: fantasai
Scribe's scribe: TabAtkins

CSS Syntax

Dashed-ident rules and error recovery
  github: https://github.com/w3c/csswg-drafts/issues/9336

  TabAtkins: We resolved the fundamental grammar ambiguity between
             properties and declarations in nesting by deciding we
             would start by parsing as a declaration, and if it was
             invalid, go back and parse as a rule
  TabAtkins: recently tweaked to make more efficient
  TabAtkins: works pretty fine, but a wrinkle about custom properties
  TabAtkins: custom properties are very hard to make invalid
  TabAtkins: anything you write in a custom property will always be
  TabAtkins: so if you write --foo: [anything] that's a valid custom
  TabAtkins: in order to avoid a behavior change for authors
  TabAtkins: if it looks like custom property, we treat it as a custom
             property during rule parsing
  TabAtkins: if you have 'display:hover', can quickly tell it's not a
             valid display
  TabAtkins: issue is that I didn't condition that check on being in a
             nested context
  TabAtkins: so as written, if you have a top-level style rule starting
             with --foo:whatever, it will try to consume a custom
             property declaration
  TabAtkins: it will eat everything up to the next top-level semicolon
  TabAtkins: lose the rest of the stylesheet from that point forward
  TabAtkins: I didn't think about this case, so proposal is to
             condition that check for "does this look like a custom
             property" to check whether in a nested context or not
  TabAtkins: if not nested context, we let it parse as a rule
  TabAtkins: but will do rule-parsing and end at next curly brace
  TabAtkins: this means that behavior-wise, this brings us back to how
             this case would have acted before my recent change to
             allow nesting to work
  TabAtkins: i.e. if you write a style rule --foo:whatever, it will
             only eat one style rule
  TabAtkins: I've checked this with Emilio during TPAC

  fantasai: So what this means is that parsing behavior for style rules
            with a custom ident is different in top level vs nested
  fantasai: So if we have custom idents at beginning of selector, will
            we be in trouble?
  TabAtkins: In both cases, if you try to write a rule with
             --foo:something, you would end up with something invalid
  TabAtkins: if it wasn't a valid custom property, you won't get a rule
  TabAtkins: The difference in parsing behavior is, if it's nested
             it'll consume as a declaration
  TabAtkins: whereas at top level it'll consume as a rule
  TabAtkins: in both cases, can't be a rule
  TabAtkins: we took as an implicit restriction on ourselves that if
             you have a style rule that wants to start with a dashed
             type selector, you have to spell it differently e.g. wrap
             in :is()
  TabAtkins: considered that to be fine because that's not a valid
             custom element name in HTML or XML (I think?)
  TabAtkins: very difficult to have a type selector that looks like
             that, can work around
  TabAtkins: error recovery is different in both cases, but either way
             the rule is invalid and won't work
  TabAtkins: and I think that's enough consistency
  <fantasai> ok, sgtm

  astearns: My question is, defining it as working normally in nested
            context vs defining it as doing different thing in top-level
  astearns: would that be exactly the same? I'm worried nested context
            are about CSS nesting, not a regular declaration block...
  TabAtkins: The switch used in Syntax is "is it mixed with
  astearns: Ok, and nested context is that type of context
  TabAtkins: Yeah
  TabAtkins: Flag is called "nested" but in practice used for mixed
  astearns: Might want a different term
  TabAtkins: I'll look into it

  ACTION: TabAtkins to look into using a more generic term than
          'nested' for the flag for mixed declaration+rule contexts
  <RRSAgent> records action 1

  TabAtkins: Proposal is, at top level, if you see a rule that looks
             like a custom property, we consume as a rule and throw it
             away as invalid

  RESOLVED: At top level, if you see a rule that looks like a custom
            property, we consume as a rule and throw it away as invalid

CSS Text

Move "balance | stable | pretty" out of text-wrap
  github: https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1735801461

  fantasai: A bunch of ideas were thrown around
  fantasai: I think the two main contenders are text-wrap-mode and
  fantasai: A bunch of other options but none seem to get traction
  <fantasai> https://front-end.social/@jensimmons/111138016628140950
  fantasai: Jen Simmons posted on mastadon to guess what -mode would do
  fantasai: And generally people guessed correctly
  fantasai: But we didn't run text-wrap-allow test
  fantasai: So that's where we're at. I think either should work, don't
            have a strong opinion
  fantasai: Should we think about it more or straw poll? comments?
  <vmpstr> what are the text-wrap-allow values?
  astearns: I'm slightly more happy with -allow than -mode, but could
            live with either

  florian: No strong pref, neither's great nor terrible
  florian: prefer wrap and nowrap, not auto and nowrap
  florian: one is consistency with flex.
  florian: Other is we can't rename text-wrap property, too long and
  florian: if that's true we probably need to do the same with the
           values themselves
  <miriam> +1 slight vote for allow
  <TabAtkins> also slight pref for -allow

  astearns: Anyone have concerns with -allow being a boolean
            essentially? Tim's concern
  astearns: Right now it's a bool but we might have more modes in the
  astearns: I think it's ok that -allow doesn't as strongly imply on/off
  florian: Even beyond boolean we'll have grades of how much to allow
  fantasai: My one concern with -allow is we got some feedback on -mode
            and not on -allow
  fantasai: so just don't know if it's intuitive or not
  fantasai: Not that it's bad, just not as much info on it

  fantasai: I'm interested in getting a straw poll to see what the WG
            feels like
  lea: I'd be fine with a straw poll
  lea: I suggested a process for async polls, was wondering about
       trying it for the first time in this specific issue if people
  <lea> https://github.com/w3c/csswg-drafts/issues/9438
  lea: Me or someone else could try to post a poll like this and see
       where people stand
  florian: I'm not against trying a new process, but I'd rather not do
           it on something fairly urgent that people want to unblock
           shipping on
  lea: Sure, but because this is APAC and lots of regrets, might not
       have sync quorum anyway, so might speed things up
  fantasai: I think CSSWG could be better at this than the Advisory
  astearns: I'm happy with the async straw poll and coming back next
  astearns: You think a week is sufficient?
  lea: Yeah, maybe even less
  astearns: Nice to have a weekly call to discuss and ratify though.
  astearns: So how about we do that. I'm happy to set up the poll, or
            Lea can?
  lea: I can post it and even add votes that have been expressed
  TabAtkins: I think as long as it's clear someone had a preference
             it's okay to write in their vote
  fantasai: I think it needs to be clear *between these two options*,
            not necessarily just a pref for one of the existing ones

  fantasai: Also we should make it clear that wrap/nowrap is the value
  lea: I think we can't decide on values before name
  florian: You might have missed the earlier discussion; we can't
           change the shorthand for compat. If we're stuck with the
           shorthand value naming, we should probably keep the keywords
           in the longhand
  fantasai: I think it's unlikely that people are using a lot of
            text-wrap:wrap, most like just text-wrap:balance, so might
            be changeable, but for consistency with rest of CSS that
            uses this concept, using wrap/nowrap as the pair is
  florian: yeah
  astearns: If we had a time machine we'd do no-wrap but we don't
  lea: The thing is, not all values work with every name
  florian: We're not trying any name, just -mode and -allow. And wrap/
           nowrap works with those
  lea: Wait are we only doing those two names?
  astearns: Yes, convo narrowed to those two
  fantasai: I didn't see people advocating for more than those
  fantasai: You had a white-space-wrap suggestion but it wasn't really
            about white space in several writing systems
  lea: Yeah that ship might have sailed. I'm fine with not doing
       white-space-wrap if nobody else wants it
  astearns: So action Lea to make the async poll for text-wrap-mode and
  astearns: Can either wait on values or just resolve to say the values
            are wrap/nowrap
  <lea> +1 for wrap | nowrap
  <TabAtkins> +1 to wrap/nowrap
  astearns: Objections to resolving?
  <TabAtkins> [none]

  RESOLVED: Straw poll for naming between -wrap and -allow. Values are

  <lea> Straw poll posted in


Allow <textarea> to be sized by contents
  github: https://github.com/w3c/csswg-drafts/issues/7542

  iank: Put on agenda again because some discussion about current name
        and values and suggestions for other ones
  iank: so agenda to bikeshed these
  iank: I've seen a few variations. A lot keep 'form-sizing' but use
        'content' instead of 'auto'
  iank: another suggestion was normal | auto?
  TabAtkins: Don't think we should go with generic keywords, later
             suggestion is better
  <TabAtkins> content | fixed
  iank: So 'form-sizing: content' and also 'field-sizing: content'
  TabAtkins: Based on the suggestions in the thread, I suggest
             'content' and 'fixed'
  TabAtkins: Weak pref, but sound reasonable
  TabAtkins: and even if the precise definition is wonky, it's easy to
             guess what the behavior is
  TabAtkins: unlike auto / normal / default / legacy
  <astearns> +1 to -sizing & content

  lea: How does this interact with width/height?
  iank: This changes how you resolve the intrinsic values
  iank: If you specify 'width: 100%', during intrinsic sizing might
        behave as min-content/max-content
  iank: If you specify 'width: 100px', won't get a behavior change
  TabAtkins: This makes form contents use the content-based sizing
             rules that normal non-replaced elements do
  TabAtkins: form controls by default have weird intrinsic sizing due
             to legacy
  iank: This also disables the compressibility quirk
  iank: This quirk gets around the fact that form control elements have
        a fixed intrinsic size
  iank: if you set e.g. width: 100%, the min-content size will be zero
  iank: this will opt you out of that behavior
  iank: It existed because there wasn't a good intrinsic size before
  lea: Does it have other effects? e.g. Chrome doesn't allow visible
  iank: This only affects intrinsic sizing
  <TabAtkins> compressibility thing:

  miriam: I'm liking 'content', but curious how it interacts with the
          sizing *-content keywords
  miriam: They're doing slightly different things in different places,
          will it be confusing?
  iank: I don't think so, we suspect people already using min-content/
        max-content on these form controls already
  iank: If you use this, set 'form-sizing: content', then this'll
        change how *-content behave, make them follow the content
  florian: This is actually a good relationship, because it ties the
           *-keywords to be based on the contents
  iank: Any preferences on form sizing vs field sizing
  astearns: Slight preference for field, because form means other
            things too
  miriam: Same
  lea: Also form-sizing feels like it affects <form>
  <lea> control-sizing?
  iank: We got similar feedback on Twitter
  <TabAtkins> huh. I wouldn't have thought about field-sizing. Like
              input fields?
  <TabAtkins> I guess, sure.
  fantasai: We don't use "field" in a lot of other places
  fantasai: What about input-sizing?
  fantasai: This is all about input elements
  iank: Also affects textareas, select, etc.
  <TabAtkins> iank: That might be a little confusing since it also
              affects textarea and select
  iank: So input might not be great
  <lea> fixed reminded me, what about something-layout to match
        table-layout as a precedent ?
  iank: Talking about these elements on MDN, "field" appears a lot, so
        I think it would match ppl's expectations
  miriam: We also do have <fieldset> which refers to same idea
  <TabAtkins> I wouldn't have thought of "field", but I suppose it
              makes sense, and we don't have any other concepts using
              that term in CSS so I think it's clear to use
  <TabAtkins> (I do prefer form-sizing tho)
  <lea> nah, I think -layout would be a bad idea here. auto | fixed
        might be good for the values though (same as table-layout)

  <iank> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
         ("field appears 29 times")
  <iank> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
         ("control" appears ~70 times)

  florian: I think I like form better here, but just to be complete, we
           have a term for elements that can have native appearance,
           and we call them "widget".
  florian: I don't think it would be very helpful here, so my
           preference still goes to "form"
  fantasai: Seems like fixed|content for values. Any alternatives for
            fixed? Seems like we're happy for content
  <lea> input-sizing
  florian: Someone suggested legacy?
  astearns: Should we resolve on 'fixed' and 'content'?
  lea: There were many arguments in the thread about legacy being bad
  lea: another would be 'auto' and 'fixed', which would match
  iank: pretty strong to keep 'content'
  astearns: Proposed 'content' and 'fixed' as values for this property,
            any objections?

  RESOLVED: Values will be fixed | content

  fantasai: Should we run a poll for these names too?
  <TabAtkins> +1 to another poll
  <lea> TabAtkins: sync or async?
  <TabAtkins> async again
  florian: not a fan of input-sizing because <input>
  <chrishtr> form-sizing?

  POLL: 1. form-sizing 2. field-sizing 3. input-sizing
  <florian> 1
  <miriam> 2
  <TabAtkins> 1,2
  <astearns> 2
  <fantasai> no strong opinion
  <lea> abstain, I think
  <vmpstr> (abstain)
  <iank> 2,1
  <chrishtr> 2,1
  <iank> (no strong opinion however)
  <schenney> (abstain)
  <changseok> 1
  <flackr> 2
  [discussion of poll results]
  <TabAtkins> Since there's no active disagreement I'm fine with a
              straight majority, fwiw
  <TabAtkins> We don't need a strong consensus when it's not
              controversial for the group
  <dholbert> 2

  fantasai: I think it would be useful to poll authors on the two
            names, to see if there's a strong drift one way or another
  lea: if we're pressed for time...
  TabAtkins: We're not that pressed that a week is critical
  astearns: fFster to resolve on the call, after getting poll results
  [discussing poll mechanics]
  [proposed to have a poll using Lea's mechanism, but add in an emoji
  [also discussing running polls over twitter / mastodon]
  astearns: So we will run a poll on form-sizing vs field-sizing, with
            values content and fixed.
  astearns: We'll be able to also evaluate Lea's proposed async poll

  <lea> 2nd Straw poll posted!

CSS Grid

Masonry - align-tracks / justify-tracks potentially not desirable
    for accessibility
  github: https://github.com/w3c/csswg-drafts/issues/8207

  iank: Mats's spec for Masonry had a feature align-tracks/
        justify-tracks which allowed you to align individual tracks
  iank: Personally I haven't seen developers ask for this
  iank: and it leads to some accessibility problems
  iank: If you look at the examples and try to count from 1 - 33,
        you're jumping all over
  iank: also a bunch of issues wrt spanning items
  iank: so the proposal is to drop this sub-feature
  fantasai: We're OK with dropping. If it seems that we need to do
            something like this in the future, we can explore it then
  dholbert: Seems fine to me, too
  astearns: Proposal is to drop align-tracks/justify-tracks from
            Masonry spec
  astearns: Objections?

  RESOLVED: Drop align-tracks, justify-tracks from Masonry spec

CSS Masking

Interpolation of mask-border properties
  github: https://github.com/w3c/fxtf-drafts/issues/529

  ntim: The properties are marked as discretely animatable, but that's
        inconsistent with border-image which is animatable by computed
  ntim: I know mask-border was based off border-image, so I was
        wondering why the inconsistency?
  <TabAtkins> +1 to matching border-image
  fantasai: I suspect (haven't checked) is that animatable lines
            weren't added in the source, and Bikeshed defaults them to
  fantasai: But yes it makes sense to make them consistent
  <TabAtkins> (I could just make it an error at this point; that didn't
              make sense before.)
  <fantasai> TabAtkins, yes please
  astearns: Proposed to change mask border properties to match

  RESOLVED: mask-border properties will match border-image wrt

Is mask-type a longhand of mask?
  github: https://github.com/w3c/fxtf-drafts/issues/528

  ntim: I noticed that mask-type has a prefix mask-
  ntim: It looks like a longhand of mask, but idk if it should be or not
  fantasai: Looking at the dfn now I think it shouldn't be
  fantasai: The property is set on a mask *element* and says whether
            the mask is based on luminance or alpha
  fantasai: I think that's not an appropriate longhand for the mask
  ntim: I wonder if the name is appropriate, then?
  fantasai: It is - we don't always have the situation where the prefix
            indicates a shorthand.
  fantasai: I can't think of a different name
  fantasai: Also this is an SVG property so unsure we can even change
            it at this point

  miriam: I agree on intuition, mask- feels like a longhand of mask,
          but there are several mask- properties that are not part of
          the shorthand
  miriam: so it's not a lone standout
  ntim: Even mask-border is part of mask
  fantasai: Yeah all the rest are on the element using the mask. This
            is the only one that's not that.
  fantasai: It defines the mask, not applies it
  ntim: Would prefer to rename if it's compatible, but seems maybe it's
  astearns: Seems resolution is no, mask-type is not a longhand of mask
  <fantasai> https://developer.mozilla.org/en-US/docs/Web/CSS/mask-type#browser_compatibility
  fantasai: I think mask-type is shipping in all browsers
  astearns: Could leave it open if people want to look into renaming,
            but doesn't seem likely

  RESOLVED: mask-type is not a longhand of mask


Update “Animatable” lines to “Animation type” in all propdef tables
  github: https://github.com/w3c/fxtf-drafts/issues/521

  fantasai: A lot of these don't have active editors, is it ok for us
            to do a drive-by edit to fix this?
  astearns: Yes, I decree it
  fantasai: And at some point we need to figure out republishing
  fantasai: but that's for another day

  astearns: [summarizes upcoming discussions]
  lea: aren't we also talking about CSS4 CG soon?
  astearns: End of the month

  Meeting closed.

Received on Thursday, 5 October 2023 22:54:39 UTC