[CSSWG] Minutes Telecon 2024-03-06 [css-values][css-pseudo][css-contain][css-writing-modes]

  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 Values

  - RESOLVED: Make semicolons an optional upgrade to commas in CSS
              functions (Issue #9539: Better handling of arguments with
  - RESOLVED: No change, keep with the existing resolution [existing
              (Issue #6026: Use of 100vw is causing pointless
              horizontal scrollbars on some websites)

CSS Pseudo

  - RESOLVED: Custom properties don't apply to the highlight pseudos.
              On highlight pseudos, the var() function takes from the
              originating element (Issue #9909: Revisit CSS Custom
              Properties in highlight pseudos)

CSS Contain

  - RESOLVED: If a content-visibility:auto element is skipping its
              contents but has not yet determined its visibility, don't
              fire the contentvisibilityautostatechange event until you
              do know the visibility (Issue #9803: Should the first
              `contentvisibilityautostatechange` event be fired without
              knowing if the element is close to the viewport)

CSS Writing Modes

  - RESOLVED: All of the text spacing properties don't apply to the
              squished-together character of text-combine-upright;
              text-spacing-trim is treated as trim-all (Issue #9423:
              Spacing within text-combine-upright)


Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0005.html

  Rossen Atanassov
  Tab Atkins
  Kevin Babbitt
  Oriol Brufau
  Stephen Chenney
  Daniel Clark
  Elika Etemad
  Robert Flack
  Chris Harrelson
  Daniel Holbert
  Ian Kilpatrick
  Vladimir Levin
  Alison Maher
  Florian Rivoal
  Alan Stearns
  Miriam Suzanne

  Rachel Andrew
  Yehonatan Daniv
  Jonathan Kew
  Chris Lilley
  Romain Menke
  Noam Rosenthal
  Bramus Van Damme
  Lea Verou
  Sebastian Zartner

Chair: Rossen

Scribe TabAtkins
Scribe's scribe: fantasai

CSS Values

Better handling of arguments with commas
  github: https://github.com/w3c/csswg-drafts/issues/9539

  <fantasai> ->
  TabAtkins: General problem is, we have several function in-flight
             which can take argument values that are the full set of
             CSS value syntax including comma-separated lists.
  TabAtkins: example might be var(), which isn't a problem because we
             intentionally put fallback as the last part, so you can
             know whether the commas are top-level or part of the
  TabAtkins: but for several other new things, that's not possible
  TabAtkins: Right now the proposals for these, when your function
             could contain commas, we switch to using semicolons to
             separate arguments in those functions.
  TabAtkins: but it does mean that during design phase of a function,
             we have to decide whether to use commas or semicolons
  TabAtkins: It's also a bit weird to have two distinct syntaxes,
             especially when most uses of these functions won't need
             semicolons -- most of the time will not contain commas as
             part of the argument, just a keyword or whatever
  TabAtkins: So using semicolon for these when 99.9% of cases don't
             need it is odd

  TabAtkins: We came up with several options
  TabAtkins: 1. Don't use semicolons. Instead, allow functions to have
             some way to wrap arguments e.g. function, brackets, etc.
  TabAtkins: For example, 'item()' which just wraps its contents and
             means its contents.
  TabAtkins: we could use brackets, like Grid already does
  TabAtkins: or curly braces, which aren't allowed top-level but can
             use inside a function
  TabAtkins: Alternatively, could make the semicolons an optional
  TabAtkins: That is, you start parsing assuming comma separation
  TabAtkins: but if you hit a semicolon, reparse the function as
             requiring semicolons between arguments and treating commas
             as part of the arguments
  TabAtkins: I am mildly inclined to go with option 2, where semicolons
             are an optional upgrade
  TabAtkins: can be done across all of CSS, so don't have to think
             about which functions
  TabAtkins: Doesn't require extra level of nesting which we try to
  TabAtkins: that said, I'm OK with any of these options
  TabAtkins: Opinions?

  astearns: Lea has asked a few times, instead of generic function, why
            not bare parentheses?
  TabAtkins: I responded -- previously purposely avoided bare
             parentheses. We used them originally e.g. for grid names,
             but switched away, because that would mess up SASS.
  TabAtkins: those arguments still apply
  astearns: I have a slight preference for option 1 with short function
  astearns: I also think square brackets would be fine
  <florian> [removed myself from the queue because I wanted to ask and
            say the same thing as astearns]

  oriol: Personally I'm fine with current situation of just using
  oriol: It's true that we need to think about it at the beginning of
         the function design, but it's ok to me
  oriol: I'm also OK with option 2
  oriol: among the others, they seem strange
  oriol: I would be OK with parens, but the others seem a bit strange
         to me
  oriol: Also argument about SASS, I wonder if there would be a
         possibility for them to wrap... This is a 3rd party tool, we
         shouldn't constrain CSS development to match outside tooling.

  fantasai: Like Oriol, I'm fine with current situation of designing it
            form the beginning. also fine with option 2. I could live
            with braces, but I think the function option reads as if
            it's part of CSS rather than an escaping mechanism.
  fantasai: so I'd prefer avoiding using a function.
  fantasai: For brackets, we already use that in other parts of CSS
            (Grid) so it's potentially confusing there.
  fantasai: But we'd *never* use braces in that same way, so we won't
            have the same problem
  fantasai: So mild pref for semicolon; their identity is a stronger
            comma and it's fitting we use it for that purpose

  Rossen: Other opinions?
  TabAtkins: Straw poll?
  <TabAtkins> 1. No change (design functions to use ; when it's needed)
  <TabAtkins> 2: use [] wrapper.
  <TabAtkins> 3: use {} wrapper.
  <TabAtkins> 4. use function wrapper (item() or similar)
  <TabAtkins> 5. Upgradeable semicolon (comma in general, but authors
                 can choose to use ; instead when necessary)

  <TabAtkins> 5, 3
  <astearns> 4, 2
  <vmpstr> 4, 2/3
  <fantasai> 1, 5, 3
  <oriol> 1, 5
  <schenney> 2,4,1
  <miriam> 5,3,1
  <flackr> 5, 4
  <florian> 3,5
  <kbabbitt> 2/3, 4, 1
  <iank> 5, 1 maybe
  <Rossen> 4,3
  <dholbert> (abstain)

  astearns: Tab, you had a worry that {} might break parsing, is that
            still a concern?
  TabAtkins: For naive (regex) parsing yeah, but all good tools should
             have a real parser
  fantasai: If you can't do bracket matching your tool is already gonna
            break everywhere, so minimum you need to bea ble to bracket
  <schenney> 5 is also most popular 2nd option, I think
  <fantasai> Total counts: 5.5 for 1, 2 for 2, 7 for 3, 6 for 4, 7 for 5
  Rossen: More first-place votes for option 5

  flackr: Is there a problem with nesting the functions?
  TabAtkins: That's fine, because the function itself will be the

  Rossen: Let's resolve on 5.
  <florian> WFM
  <florian> +1
  TabAtkins: Was close, but 5 ekes out, and if any strong objections
             can re-discuss
  Rossen: Any objections to #5?

  RESOLVED: Make semicolons an optional upgrade to commas in CSS

Use of 100vw is causing pointless horizontal scrollbars on some
  github: https://github.com/w3c/csswg-drafts/issues/6026

  iank: I think now, with Bramus's data, this is likely fine
  iank: Bramus did a lot of analysis on it. still a little concerned,
        but someone can take the risk and see what happens
  <fantasai> Bramus wins MVP of the issue! \^_^/

  TabAtkins: When overflow is set on the root element (specifically;
             not body), we will take the scrollbars into account when
             calculating viewport unit sizes
  iank: Yes, specifying overflow:scroll on the root is sufficiently
        rare that people shouldn't run into this
  iank: Probably won't solve the general case on existing sites, but
        people can fix it moving forward
  iank: One caveat is that enterprise is always hidden in this type of
        analysis, so if someone rolls it out there might be a hidden
        part that changes our resolution
  TabAtkins: +1
  fantasai: Why didn't we want to do it for body propagation? Too
  iank: Yes, I think it would break way too many sites

  fantasai: Other thing in the thread is having the dv* units respond
            to scrollbar
  fantasai: So I guess it would make sense to say that dv* would
            respond to scrollbar...
  TabAtkins: dv* units are always between small and large units, right
             now; we should be careful about losing that

  <astearns> previous resolution:
  astearns: I linked to the existing resolution that already covers
            this, this discussion is about us not undoing that
  Rossen: So keep no change?
  Rossen: Objections?

  RESOLVED: No change, keep with the existing resolution

  Rossen: Do we need something for the dv units?
  fantasai: No, we should do that in a separate issue
  miriam: Do we also need, in the new issue, to mention CQ units?
  fantasai: Would need to be a more separate issue

CSS Pseudo

Revisit CSS Custom Properties in highlight pseudos
  github: https://github.com/w3c/csswg-drafts/issues/9909

  schenney: I filed this based on two things
  schenney: First, one of the comments on the bug report when we tried
            to enable the highlight inheritance chain
  schenney: Someone in a tool was setting a custom property on
            ::selection on every element, expected it to use the custom
            prop from the element
  schenney: Second, when I looked at SO about the ::selection pseudo,
            there was at least one answer that ended up saying "just
            use custom props for your selection pseudo"
  schenney: so this appears to already be a big behavior, custom
            properties driving selection behavior
  schenney: Previous browser behavior, this *was* the correct way to do
            it - customs would inherit through the originating element

  schenney: So I propose we change the spec to also inherit custom
            props from originating elements
  schenney: This may be great for devs, but it poses problems for impl
            and spec
  schenney: First, at minimum it's a memory hog, you have to copy
            custom props onto all your selection pseudos.
  schenney: every time the property set changes you have to reallocate
            a new custom property set for the element
  schenney: Second, what do you do when a custom prop is defined in
            both the highlight inheritance chain *and* the originating
  schenney: "correct" answer depends on context, hard to spec a
            reasonable behavior
  schenney: So in hindsight I think we shouldn't make the change. But a
            lot of webdevs have come in and said we *should* make it.
  schenney: So, is there anything sensible to do about when there's
            clashing declarations?

  fantasai: I think one thing suggested in the thread which is fairly
            simple is to have "normal" properties inherit through
            highlight chain, but take custom properties from the
            originating element
  fantasai: and *only* the originating element
  fantasai: So you can't set custom props on an article::selection and
            have that visible to a span::selection
  fantasai: but you can set it on `article` and inherit to the span,
            and then it'll be visible in span::selection
  fantasai: I don't like an interleaved where it's inherited from two
            places at once, but I think in this limited case it's okay.
            The entire set of normal and the entire set of custom each
            have a single place to inherit from
  schenney: I think that's equivalent to saying custom prop defined on
            highlights are ignored?
  fantasai: No. We *could* define it that way and it probably wouldn't
            break much. But we could also still allow highlights set on
            you to win, and just inherit from the element.
  fantasai: but maybe that causes more problems
  schenney: Right, you'd have to say they apply to the element it's set
            on but not inherited... that causes issues. Simpler to just
            not allow it
  fantasai: Yeah
  schenney: I think this is probably fine.

  schenney: So do we do this for just ::selection or all the highlight
  fantasai: All, I think
  schenney: Yeah, for consistency
  fantasai: And the same arguments apply for the other highlights too
  schenney: I think there's not enough usage to really draw conclusions
            from on the other types yet
  fantasai: Lea mentioned wanting to do syntax highlighting with
            highlight pseudos
  fantasai: being able to use variables with them would be useful
  schenney: Syntax highlighting does seem to be the primary usecase for
            highlights, especially for perf, agreement

  schenney: So proposed resolution: custom properties are disallowed in
            highlight pseudo-elements. They inherit from the
            originating element.
  fantasai: Would that work for Lea's use case?
  TabAtkins: Yes, because she sets the theme colors on the originating
  schenney: I think the only difference practically is if you change
            the custom prop on the originating element chain, in a way
            that's out-of-sync with how you change the highlight
            "pseudo-classes" on the chain
  schenney: That's the only way to get into trouble

  dandclark: I was thrown off by Lea's example, it seems you can make
             it work with either proposal
  dandclark: I think our main concern was not breaking old code relying
             on the current browser behavior
  schenney: I think that's right
  schenney: My primary motivation is that people currently do a lot of
            custom properties on the elements and expect it to be
            visible to the selection. allowing that really increases
            the likelihood we can actually ship
  dandclark: We are changing long-standing behavior by changing the
             selection behavior at all, what's the bar for us to know
             if it's shippable?
  dandclark: When we switched to inherit custom props from root we got
             some reports of real breakage, like form github
  dandclark: It sounds like what I'm hearing is that it's not too bad
             to just inherit the custom props, performance-wise
  schenney: From a perf perspective, as long as we don't allow custom
            props to actually be set on the highlight itself, then from
            a code complexity perspective it works fine
  schenney: In trying to launch highlights in chromium, we've run into
            this issue, and people relying on the fact that they could
            change the selection for just one type of element and
            explicitly not have it inherited
  schenney: But that second one has been fixed in the most important
            sites affected by it, so I think with this change we'll
            have a good chance of shipping the fixes

  fantasai: So the proposal is custom props don't apply to highlight
            pseudos. The var() function takes from the originating
  vmpstr: Clarify on var() - that "takes from originating" is just for
          the highlight pseudos, not in general, right?
  TabAtkins: Yes

  RESOLVED: Custom properties don't apply to the highlight pseudos. On
            highlight pseudos, the var() function takes from the
            originating element.

CSS Contain

Should the first `contentvisibilityautostatechange` event be fired
    without knowing if the element is close to the viewport
  github: https://github.com/w3c/csswg-drafts/issues/9803

  vmpstr: We have an event that fires when content-visibility:auto
          state changes (form skipped to not skipped, or vice versa)
  vmpstr: Question, what to do if we haven't determined visibility for
          the element yet
  vmpstr: Can happen if we add the content-visibility:auto then force
  vmpstr: Visibility is done at IO timing, so not done yet
  vmpstr: Naively we'd fire an event that says "it's skipped" then at
          IO time we fire another saying "it's visible", two events in
          rapid succession
  vmpstr: Filer of the issue suggests we just don't fire the event
          until we've actually had a chance to determine the visibility
  <TabAtkins> +1, makes sense to me

  vmpstr: One extra - "unless there's something else making the element
          relevant to the user", then we already know it's relevant and
          fire it immediately
  vmpstr: so if the element is skipping its contents but we haven't
          determined its visibility yet, don't fire the event
  <chrishtr> +1 to the resolution

  RESOLVED: if a c-v:auto element is skipping its contents but has not
            yet determined its visibility, don't fire the
            contentvisibilityautostatechange event until you do know
            the visibility

CSS Writing Modes

Spacing within text-combine-upright
  github: https://github.com/w3c/csswg-drafts/issues/9423

  fantasai: There's a feature text-combing-upright which causes glyphs
            in upright vertical text to combine into a single combined
  <TabAtkins> like if you want "23" it'll smush into one block
  fantasai: We specify that letter-spacing doesn't apply inside the
            smushed box, we treat it like a single character
  fantasai: We didn't specify the other spacing properties, like
  fantasai: Proposal is we ignore all of them
  fantasai: and for text-spacing-trim we treat it as trim-all
  fantasai: Generally you won't run into these situations anyway, but
            if you do you probably don't want extra space making it
            even more squished
  florian: I initially thought we wanted some options here, but on
           further thought I think we don't, and that fantasai is right
  <TabAtkins> +1
  Rossen: objections?
  <fantasai> illustration ->

  RESOLVED: All of the text spacing properties don't apply to the
            squished-together character of text-combine-upright;
            text-spacing-trim is treated as trim-all

Received on Friday, 8 March 2024 14:56:40 UTC