[CSSWG] Minutes Telecon 2024-07-31 [css-grid][css-values][cssom][css-nesting][css-shapes]

=========================================
  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 Grid & Values
-----------------

  - RESOLVED: Remove grid-template properties from the list of
              properties that calc-size is valid for and that
              interpolate-size works on (Issue #10618: should
              calc-size() and interpolate-size apply to
              grid-template-rows and grid-template-columns?)

CSSOM & Nesting
---------------

  - RESOLVED: Throw on insertRule only when there are no valid
              declarations. Do not throw otherwise (Issue #10520: Error
              behavior for insertRule with declaration blocks)

CSS Grid
--------

  - RESOLVED: Allowing mixed track sizing, as long as the algorithm
              does not allow position-dependent effects (Issue #10053:
              Intrinsic track sizing algorithm for masonry can go
              exponential in complexity)
  - RESOLVED: Add a note about the grouping optimization and baseline
              handling (Issue #10053)

CSS Shapes
----------

  - RESOLVED: Shapes Level 1 is modified to say that shape-outside
              takes all <basic-shape> (Issue #9728: Clarify which
              `<basic-shape>` are valid in `shape-*`)
  - RESOLVED: Publish a new CRD of Shapes 1 with this [above] change
              (and whatever else is already in since last publication)
  - RESOLVED: Accept Noam's PR (switch to `using`, allow reordering
              grammar) (Issue #5841: Minor comments on shape())

===== FULL MEETING MINUTES ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jul/0015.html

Present:
  Rachel Andrew
  Tab Atkins-Bittner
  Kevin Babbitt
  Oriol Brufau
  Stephen Chenney
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Matthieu Dubet
  Elika Etemad
  Robert Flack
  Simon Fraser
  Mason Freed
  Paul Grenier
  Chris Harrelson
  Jonathan Kew
  Ian Kilpatrick
  Roman Komarov
  Alison Maher
  Eric Meyer
  Florian Rivoal
  Cassondra Roberts
  Noam Rosenthal
  Brandon Stewart
  Alan Stearns

Regrets:
  Daniel Holbert
  Chris Lilley
  Lea Verou
  Sebastian Zartner

Chair: astearns

Scribe: noamr

CSS Grid & Values
=================

should calc-size() and interpolate-size apply to grid-template-rows
    and grid-template-columns?
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/10618

  dbaron: Hoping this would be quick. Earlier in calc-size I've given a
          list of props it should work on
  dbaron: width/height/flex-sizes/grid-template-rows/
          template-columns/... and equivalents. see in issue for full
          list
  dbaron: Proposing to remove the grid ones for a few reasons. I
          thought it would be more doable than Ian
  dbaron: Thought I was getting it done, but the approach doesn't work
          at all for division of length and unit algebra, both highly
          requested, speced but perhaps not implemented
  dbaron: Basic conclusion after trying, there is no reasonable way to
          mix calc-size/interpolate-size with distribution over grid
          tracks, algebra over length
  dbaron: Conclusion: not try to do it for grid properties, save
          initial version for the other properties and not the others
  dbaron: This might mean that if we figure this out in the future we
          might need to add a new opt-in value. We might not, but
          that's the down side
  dbaron: Main reason to remove the grid props is that I don't see how
          to do it

  astearns: questions or concerns?
  <TabAtkins> If dbaron can't figure it out, I doubt I could either, +1
  <emilio> Sounds fair :)

  fantasai: How would this affect the syntax of the interpolate-size if
            we want to extend in the future?
  dbaron: We'd have to add a keyword like "also allow grid"
  fantasai: Remind me of current values?
  dbaron: numeric only, allow-keywords
  <TabAtkins> allow-keywords allow-grid-template
  <TabAtkins> something like that
  fantasai: So we'll have "allow-grid" or something
  dbaron: Something like that
  fantasai: Sounds reasonable

  astearns: Can this affect other props in the future. Anything left
            off the list dbaron?
  dbaron: Only one possible candidate, something with column
          (column-width)?
  iank: Yes, it's column-width and the length properties
  astearns: It's possible we'd have some future extensions with more
            keywords
  astearns: Seems reasonable if that ever happens
  dbaron: Double hypothetical. Need to do that if we found a way to do
          it and that by doing it would be a compat issue. For columns
          that's unlikely a compat issue

  astearns: Any other questions or comments?
  astearns: proposed resolution: remove grid-template properties from
            the list of properties that calc-size is valid for and that
            interpolate-size works on
  astearns: objections to removing grid-template-* properties from this
            feature?

  RESOLVED: remove grid-template properties from the list of properties
            that calc-size is valid for and that interpolate-size works
            on

CSSOM & Nesting
===============

Error behavior for insertRule with declaration blocks
-----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/10520

  emilio: We resolved to be able to call insertRule for various
          declarations, but we didn't resolve on error handling
  emilio: 2 options: (1) do nothing, effectively making this API not
          throw at all, right now we throw. (2) throw, but only when we
          get empty declaration blocks
  emilio: 2 is a bit weird if you only specify invalid declarations,
          but would be consistent with how it's parsing. Seems like
          there's a variety of opinions on the thread or other options

  astearns: Other people who have commented?
  matthieud: We thought that maybe we'd add another function,
             insertDeclaration, to avoid this issue.
  matthieud: This was one of the options we resolved on last time,
             still option for the discussion.
  emilio: I thought we wanted insertRule work and would do the right
          thing
  TabAtkins: The resolution was to prefer insertRule, but fall back if
             necessary due to web compat
  emilio: Were you against throwing on declaration blocks?
  TabAtkins: I want to be consistent. Need to look at existing
             implementation. If we throw now we should keep throwing
  emilio: insertRule currently throws
  TabAtkins: Then insertRule should throw if the declaration is
             consisting only of invalid rules
  emilio: That's the current spec
  matthieud: The spec says to throw syntax errors in multiple places
  astearns: matthieud are you ok with matching the throwing behavior
            here, or prefer a separate method?
  matthieud: Current is OK, it's a bit weird and surprising when mixing
             valid/invalid declarations, but that's fine

  fantasai: Throwing on "only invalid rules" vs throwing on "mixed" is
            weird and inconsistent. We should throw on "some invalid
            stuff"
  TabAtkins: We can't throw on "some invalid" because of forward
             compatibility, as people won't be able to use it for
             multiple browsers in the future as it would always throw
  fantasai: It would be weird if something was throwing for not having
            any valid declarations and then suddenly not throw when one
            valid declaration added
  <TabAtkins> we currently throw on "one invalid at-rule", I'm not sure
              that throwing on "one invalid decl" is inconsistent
  emilio: That's exactly the CSS parser behavior
  matthieud: The CSS parser and the CSSOM have different behavior "on
             purpose": the CSS parser happily skip invalid rules/
             at-rules/declarations - but the CSSOM throws on invalid
             rule
  emilio: It's not that bad, because that's how the CSS parser behavior
          works
  emilio: I don't recall the behavior when there are multiple rules
  Matthieud: You can't insert multiple rules with insertRule

  florian: From my POV if we throw on everything that's invalid or
           empty and don't throw on mix valid/invalid, than that's
           consistent
  florian: you need at least 1 valid declaration to be valid
  fantasai: If we care about the idea of forward compat, if we use 3
            new syntax and one old syntax, and then you remove the old
            one it starts throwing, it doesn't make sense
  fantasai: If we want to throw invalid declarations we should always
            do that
  florian: It works the same as with inserting an empty string

  emilio: I don't disagree with fantasai but I don't think it's
          possible because it would make the API never throw with any
          input
  emilio: that's a pretty significant breaking change
  emilio: the current spec is perhaps the most sensible solution
  <TabAtkins> `insertRule("@invalid {...}")` throws - this is perhaps a
              bad idea for forwards compat *as well*, but it's the
              current long-standing behavior
  florian: I argue that it makes conceptual sense, not necessarily that
           it's convenient for devs

  fantasai: I agree we shouldn't change the behavior for @ rules,
            that's fine since it's one rule at a time
  fantasai: I'm arguing for consistency on invalid declarations only,
            or a mix of valid and invalid declarations
  fantasai: and I think we should be consistent about whether we throw
            on all-invalid and empty string
  fantasai: We need to either throw or not throw on all-invalid/
           some-invalid/empty-string
  fantasai: the 3 of them should behave in the same way
  emilio: not-throwing on all invalid is not feasible, because you
          don't know if you were given invalid declarations or an
          invalid at rule. it gets weird
  Matthieud: Right, it means changing the existing situation where we
             throw on invalid rule
  emilio: Then we should other do what's on the spec, or throw on some
          invalid, but it's a bit odd how the rest of CSS works
  MatthieuD: This would be a breaking API change
  <TabAtkins> At the moment there's no way, given the parsing algos, to
              tell the difference between "empty string" and "all
              invalid decls"; invalid decls are dropped during parsing.
  <TabAtkins> If we try to just split on "empty string" vs "not empty",
              then a string containing just an invalid rule will pass
              (whereas currently it throws).
  <TabAtkins> We'd had to instead do some heuristic on the stuff in the
              string to see if it *might* look like there's a decl in
              there.
  <fantasai> Could check for initial "@" for "invalid at-rule".
             Probably that's what most people would rely on.
  <TabAtkins> Can't look for just an @; style rules are allowed too
  <fantasai> TabAtkins, ahh right
  <matthieud> I don't think trying to find an heuristic like looking
              for an @ is a good idea (and it already doesnt work for
              nested style rule)

  florian: Maybe I'm failing to understand something, but the way I see
           it, you want to throw as a reaction to anything invalid
           being passed, while I think we should throw on the absence
           of something valid
  florian: Throwing is not a signal of "something was wrong" but rather
           "there was not a single thing that was right"
  florian: At least it's useful in some cases where you insert some
           valid rules and some invalid
  fantasai: It's ok conceptually, do we want to be resilient on wrong
            declarations, if we don't throw on most implementations and
            silently handle invalid declarations, and then some
            implementation arbitrarily succeeds
  florian: Isn't that useful, when you want to get told when "one thing
           works" vs "nothing works"
  fantasai: Why do I care if I dropped 2/3 vs 3/3?
  florian: It depends why you inserted more than one
  florian: maybe you added a prefixed and a non-prefixed, it depends on
           why you use the API
  florian: This works for fallback properties, where you want "at least
           one of these to work"
  florian: You called insertRule, if it succeeded you probably meant it
           because you have enough fallbacks, but if nothing goes
           through something went wrong
  fantasai: This might not be more or less wrong

  emilio: It consistent with how the API behaves right now. If the rule
          list grows by 1 it doesn't throw, otherwise it throws
  emilio: It's weird because it's inserting something that's not a rule
          into a rule list
  astearns: A lot of comments on IRC, not entirely sure we're ready for
            a resolution. Take back to the issue?
  fantasai: I'm not going to object, people will be confused, but I
            don't know if there is a better option
  fantasai: given the restrictions, I don't see a better solution
  astearns: Concerns about "only throwing when there is nothing valid?"
  proposed resolution: throw for insertRule if there are no valid
      declarations, not throw otherwise

  RESOLVED: Throw on insertRule only when there are no valid
            declarations. Do not throw otherwise

CSS Grid
========

Intrinsic track sizing algorithm for masonry can go exponential in
    complexity
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/10053#issuecomment-2243928137

  fantasai: TabAtkins, Iank and I discussed this on Monday, and decided
            that we think this is doable, want to resolve that we allow
            mixed track sizing on masonry and investigate
  fantasai: It is currently a point of contention
  <fantasai> Proposed resolution? Allow mixed track sizing in masonry;
             investigate applying limitations on the size contributions
             of subgrid/submasonry child items to avoid pathological
             performance characteristics.
  IanK: It would be good to explicitly spec how you're supposed to
        group things and then apply the sizing algorithm, otherwise it
        would get lost and implementers won't do it correctly
  IanK: We need to list out how you're supposed to do this, and also
        mention the positional independence thing
  IanK: To get the perf characteristics, you have to group everything
        by how it's sized, and then apply the track sizing algorithm
  IanK: It's different from today where all the items are having
        applied the track sizing algorithm together
  fantasai: It's an optimization of the currently spec'ed algorithm, we
            can add it as a note for a possible optimization
  fantasai: I want to keep the algorithm easy to read
  IanK: For an implementor, if they have to dig notes to find important
        optimizations it's difficult
  fantasai: There are further optimizations, this is not the only
            possible optimizations
  fantasai: It's ok to outline this, but it's not our jobs in specs to
            detail exactly how to optimize stuff. We might not come to
            the right solution. This problem exists in all spec
  fantasai: Translating spec directly into code is a bad habit
  <TabAtkins> It is useful to give guidance when something should be
              done in a particular way, fwiw.
  <fantasai> Yeah, I'm fine with giving guidance
  <TabAtkins> If there *is* a behavioral difference, though, then it
              does matter and needs to be in the algo, obvs.
  <fantasai> obvs
  IanK: I don't want to lose the positional independence stuff as it
        requires for the algorithm to work
  IanK: Positional independence is key to get this opt to work
  IanK: Otherwise we're back to CSS2.1 where there are no algorithm
        specified
  IanK: We can write the basic constraints and build the other
        constraints on top of that

  astearns: Hearing a few things to resolve. Is this merely an
            optimization?
  fantasai: Yes
  IanK: As long as we have positional independence
  IanK: The current algorithm does have positional dependence
  astearns: Is the first resolution that we allow mixed track size,
            with a normative bit on positional independence
  proposed resolution: allow mixed track sizing on masonry, as long as
      the algorithm does not allow position-dependent effects

  RESOLVED: allowing mixed track sizing, as long as the algorithm does
            not allow position-dependent effects

  astearns: proposed resolution, add a note about the grouping
            optimization and baseline handling

  RESOLVED: add a note about the grouping optimization and baseline
            handling

  fantasai: Investigate limitations on subgrid contribution of subgrid
            items to avoid perf issues
  fantasai: We need to dig more
  astearns: Any other resolutions needed on this one?

CSS Shapes
==========
  scribe: TabAtkins

Clarify which `<basic-shape>` are valid in `shape-*`
----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/9728

  smfr: In Shapes 1 the spec says shape-outside accepts only a small
        list of functions
  smfr: We have new shape functions now - xywh()/etc, shape(), path(),
        etc.
  smfr: Convenient would be to say that <basic-shape> is all such shape
        functions
  smfr: I think in imp we avoided path() in <basic-shape> at first
        because it was hard to do the geometry to figure out where a
        line of text hit the boundary
  smfr: But I think we just need to figure it out and make shapes work
        everywhere
  astearns: Does this need to be in Level 1, or can it go to Level 2?
  smfr: Would be a little weird for Level 2 to modify shape-outside
        here, but it could I guess?
  astearns: No strong opinion either way for me
  astearns: makes sense to me
  <TabAtkins> +1 from me
  astearns: proposed resolution: Shapes Level 1 is modified to say that
            shape-outside takes all <basic-shape>s

  RESOLVED: Shapes Level 1 is modified to say that shape-outside takes
            all <basic-shape>

Publication
-----------

  smfr: Could I also ask for a new WD?
  smfr: The ED changes the values accepted by circle()/ellipse()
        grammars too
  astearns: I think this'll be a CRD at this point
  astearns: Which is why I was thinking of putting it in L2, to be lazy
  fantasai: It's not harder to publish a CRD than a WD
  astearns: Do you want a resolution to publish now, or wait for the
            next issue?
  smfr: Next issue is definitely a L2 issue, let's do now
  astearns: so proposed is: Publish a new CRD of Shapes 1 with this
            change (and whatever else is already in since last
            publication)

  RESOLVED: Publish a new CRD of Shapes 1 with this change (and
            whatever else is already in since last publication)

Minor comments on shape()
-------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5841#issuecomment-2254583993

  noamr: A few years ago there were some comments about shape() syntax,
         wanted to resolve them
  noamr: One is we use keyword `via` to describe intermediate points in
         beziers
  noamr: Proposal is `using` instead, which makes sense - you don't go
         via the points, you just use them to create the curve
  noamr: Other was to allow reordering the arguments, since they're
         distinguished by keyword
  noamr: Third is to also allow <position> rather than just <coord-pair>
  noamr: Currently we use `by` and `to` - `by` is relative segment,
         `to` is absolute. So idea is if you use `to` you can use
         <position>, like `to top left`
  noamr: These all make sense to me
  noamr: There's also an animation question, I think we can defer that

  smfr: I agree with all of these
  smfr: One thing, if you say `to` or `by` the end and control points
        are either all relative or all absolute
  smfr: It makes sense to me to be able to specify control points
        relative to the end point
  smfr: That would complicate the syntax, and needs something for
        quadratics
  smfr: But in general it makes sense to allow moving beziers and leave
        control points alone because they're relative to the endpoints
  noamr: I think we can address that in a separate issue
  smfr: Right, just want to make sure we're not stopping my thing from
        working in the future
  noamr: Yeah, it won't

  astearns: I suggest we move the <position> issue to the new issue
            about smfr's issue
  astearns: And for now just resolve on what's in the PR - reordering
            grammar, and using instead of via
  fantasai: I think we try to use prepositions, and this is a verb, so
            I'm not super into `using`
  <fantasai> I don't particularly love 'using', we usually use
             prepositions not verbs
  smfr: Nobody ships this yet, we can change things. It might change
        with the relative-control-points thing.
  fantasai: I'm fine with the PR for now.

  RESOLVED: Accept Noam's PR (switch to `using`, allow reordering
            grammar)

Received on Thursday, 1 August 2024 18:24:18 UTC