- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 1 Aug 2024 14:23:45 -0400
- To: www-style@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.
=========================================
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