- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 28 Feb 2024 19:53:27 -0500
- 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.
=========================================
Update to Contributing.md
-------------------------
- There is a proposed update to the contribution guide which
clarifies when to land a PR (PR:
https://github.com/w3c/csswg-drafts/pull/9928 ).
Group members are encouraged to review and make changes/give
feedback.
CSS Cascade & Nesting
---------------------
- Though the group is still waiting on use counters for issue #8738
(Figure out whether we're fine with "shifting up" bare
declarations after rules), they agreed to start work on a design
for if the use counters come back saying a change is possible.
CSS Values
----------
- RESOLVED: Allow the modulus parameter to be optional in the case of
rounding numbers and default to 1 (Issue #9668: Let B
default to 1 in `round(<strategy>?, A, B)`)
- RESOLVED: -0% serializes to a normalized form (Issue #9750:
Clarifying serialization of negative zero and expression
simplification)
CSS Borders
-----------
- RESOLVED: Not going to use the pixel unit for the pixel value in
border-image-slice (Issue #6739: Accept "px" for pixel
values in `border-image-slice`)
CSS Contain
-----------
- RESOLVED: Close the issue in favor of consistency and reopen #5984
(Issue #7947: Should not cq units be interpreted in the
flatDom context?)
View Transitions
----------------
- RESOLVED: Change CSSViewTransitionRule .type to .typeList (Issue
#9905: `CSSViewTransitionRule.type` overrides deprecated
`CSSRule.type`)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Feb/0010.html
Present:
Rachel Andrew
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Oriol Brufau
Keith Cirkel
Stephen Chenney
Emilio Cobos Álvarez
Yehonatan Daniv
Matthieu Dubet
Robert Flack
Paul Grenier
Daniel Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
Roman Komarov
Chris Lilley
Alison Maher
Miriam Suzanne
Alan Stearns
Bramus Van Damme
Lea Verou
Sebastian Zartner
Chair: astearns
Scribe: Frances
Update to Contributing.md
=========================
github PR: https://github.com/w3c/csswg-drafts/pull/9928
astearns: First item on agenda is writing down a convention to not
land prs until there is a minuted resolution with normative
changes
astearns: If anyone would like to make changes, feel free to improve
it.
Bramus: Request for the filed pr should originate from it's own fork.
<florian> +1 to bramus' complementary PR
CSS Cascade & Nesting
=====================
Figure out whether we're fine with "shifting up" bare declarations
after rules
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8738
TabAtkins: The use counters for checking have not gone into Chrome
yet.
TabAtkins: Suggest to wait a little longer for use counters
lea: Use counters trade off in waiting, we might not be able to make
the change. CSS nesting is established, how could people use it,
have anecdotal data. To continue having shifting data, would
like to fix it.
TabAtkins: Need to see if it is possible to fix it, will not change
unless we can see that it is compatible, in favor.
lea: Don't need to wait for the use counters to decide whether it's
worth doing, only to determine whether it *can* be done.
astearns: Consensus that it is the right thing if possible.
astearns: Would it be possible to make the change, what else do we
have to do to see if it will work correctly. Is there a
separate issue for SSN?
TabAtkins: A naked ampersand style rule could be possible.
<TabAtkins> The proposal in the issue is to reintroduce @nest without
any arguments, which just represents the same elements as
the parent. This also avoids problems that would come
from a naked `& {...}` rule. Details are in the issue.
matthieud: Would like if we could find the solution in parallel.
lea: The author intent is clear, would not like to have another
nesting syntax, bad from ui perspective.
<TabAtkins> (We already do this "hack" in MQs/etc, fwiw.)
TabAtkins: CSSOM would reflect declarations after the first rule
showed up as @nest rules. Otherwise they would get grouped
up and lose their ordering.
astearns: It could be useful to continue to work and separate CSSOM
into a separate issue.
<lea> +1 The design component of this does not need use counters and
I'm not sure we have consensus on the design we want
TabAtkins: We could create a separate CSSOM issue.
astearns: We can work through it as soon as we get compat data back.
<oriol> Tab's proposal was on another issue,
https://github.com/w3c/csswg-drafts/issues/9492#issuecomment-1779739434
astearns: Moving onto the next issue, we are limited by compat
concerns.
CSS Values
==========
Let B default to 1 in `round(<strategy>?, A, B)`
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9668
TabAtkins: Round function takes a rounding strategy, we require the
modulus to be rounded. We could omit the modulus.
Emilio: It feels weird to make lengths invalid and not make it
optional, such as rounding a pixel value. Default for the
length would be nice.
TabAtkins: Rounding to one pixel as a default is not obvious, people
might not care about subpixels, but rather the unit they
are using.
<bramus> +1 on what tab just said.
lea: Should not have to specify 1, whereas dimensions such as length,
would make more sense on what you are rounding by, pixels might
not be used too much today. Would like default for lengths,
possibly not pixels.
Emilio: In length there is a single unit that other lengths end up
computing to.
lea: Sensible defaults are great when centered around user needs or
could be confusing.
astearns: It is reasonable to have numbers default to 1, but not
reasonable for numbers to default to invalid for another
type.
lea: Which invalid results?
astearns: Once taking the pattern of omitting the argument and
applying it, it could create invalid creations.
lea: When rounding numbers will be clear, when rounding lengths will
not be clear.
astearns: There could be a reasonable default, omit the parameter in
some implications but not others.
Florian: Figuring out more syntax is necessary, you need to express
something. Figuring out which syntax is implied. For
rounding things, separate digits after the comma. Does 10
mean 10 digits after the period or before the period? For
lengths, have to think about this stuff in what you mean.
<oriol> +1 to Florian
<lea> +1 to florian, that's exactly what I was saying too (but always
good to have multiple framings)
Bramus: If the default only cares for one of the cases, then it's not
a good default?
astearns: It could make it difficult for an author to reason whether
to use the parameter or not.
lea: If it's the concern, round could possibly not have a default. It
takes a parameter to round by.
astearns: We can likely resolve on making the change.
PROPOSAL: Allow the modulus parameter to be optional in the case of
rounding numbers and default to 1
astearns: Objections? No objections.
RESOLVED: Allow the modulus parameter to be optional in the case of
rounding numbers and default to 1
Clarifying serialization of negative zero and expression
simplification
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9750
TabAtkins: Track positive 0 and negative 0 separately, could result
in different infinities in separate cases. We mostly
separate this away. Could become an unsigned 0.
TabAtkins: One case where it isn't true if the 0 is a percentage so
could be positive or negative in +0% and -0%. How
important is this? We could just stick with the spec to
imply need to verify if clear, and care about percentages
and simplify.
<TabAtkins> max(0%, -0%) (or min(), or clamp())
astearns: Can we see if the spec is clear, does the spec talk enough
about positive and negative percentages?
TabAtkins: Would have to keep the max function with both arguments,
carefully threading a few arguments.
dbaron: If the goal is serialization round tripping, we don't parse
negative 0 into a negative 0.
<TabAtkins> min(1% / -infinity, 0%)
TabAtkins: If writing a solution similar to it, would still have to
parse in the current semantics.
TabAtkins: Currently it should require both arguments to be preserved.
Emilio: Preserving the original syntax, we need to serialize it to
something else. Infinity basically normalized the
serialization, we don't preserve the actual author
documentation.
TabAtkins: Not a problem to simplify more aggressively in the use
case in it does not matter.
astearns: Write tests for the spec based on the test production.
Emilio: Could become a complicated code path, serializing -0%, and
draw a calc tree.
<TabAtkins> happy to figure out how to normalize such an expression,
at minimum
astearns: Any other concerns?
dbaron: Not really an implementor as far as this code is concerned,
but I like the idea of trying to keep it simple for something
without much of a use case.
TabAtkins: We can resolve to at minimum serialize in case of a
complex tree.
PROPOSAL: -0% serializes to a normalized form
RESOLVED: -0% serializes to a normalized form
CSS Borders
===========
Accept "px" for pixel values in `border-image-slice`
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6739
SebastianZ: Suggested to allow pixel unit for border-image-slice. For
authors it is easier to express in pixel values.
SebastianZ: Pixel unit is meant for CSS pixels, from an authors
perspective it looks weird to have a unitless number for
slicing. Would like to possibly introduce a pixel unit.
Emilio: Is there a use case for a non pixel length?
SebastianZ: Would just be pixels.
Emilio: Either come up with a different unit and use calc() with it,
or treat pixels as arbitrary lengths.
Emilio: Slightly against
Emilio: it'd be unfortunate if e.g. the zoom property affected this
TabAtkins: Also slightly against. Pixels to allowed but not others,
can put px at the end of a number but nothing else, could
end up being confusing.
kizu: For non pixels in any length is if using css gradient and slice
using the same thing for the stop of the gradient.
kizu: Might not be worth introducing a change.
SebastianZ: Are there other use cases other than border-image-slice?
If other use cases for a new pixel unit, could introduce
in border-image-slice, until then, we can resolve not to
add the px unit.
astearns: Let's resolve
<lea> As Roman said, I do think `border-image` is rotten at the core
and needs a complete re-architecting, but no cycles to work on
that right now. I would weakly support this change, but it
doesn't make much of a difference
PROPOSAL: Not going to use the pixel unit for the pixel value in
border-image-slice
RESOLVED: Not going to use the pixel unit for the pixel value in
border-image-slice
astearns: If we find other use cases for it, we could consider adding
it to border-image-slice. Work on a replacement for
border-images.
CSS Contain
===========
Should not cq units be interpreted in the flatDom context?
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7947
TabAtkins: cqw units should be interpreted instead in the like tree
rather than the flat tree. cqw units have to be consistent
with other container queries in the flatDOM instead of in
the normalDOM
Emilio: Do queries differentiate?
TabAtkins: Yes, they do.
Emilio: Might not be what you want.
TabAtkins: Could reopen issue.
Miriam: I think this use-case is a strong argument to reopen. It is
more like inheritance. Would like to reopen it.
astearns: Close the issue saying that we want consistency.
<TabAtkins> +1 to closing this issue for consistency
PROPOSAL: Close the issue in favor of consistency and reopen #5984.
RESOLVED: Close the issue in favor of consistency and reopen #5984
CSS View Transitions
====================
`CSSViewTransitionRule.type` overrides deprecated `CSSRule.type`
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9905
TabAtkins: CSSViewTransitionRule as a .type is deprecated, it needs
renaming such as typeList instead.
<bramus> SGTM
<TabAtkins> .type is already used in CSSRule (it's deprecated)
PROPOSAL: Change CSSViewTransitionRule .type to .typeList
RESOLVED: Change CSSViewTransitionRule .type to .typeList
Received on Thursday, 29 February 2024 00:53:59 UTC