- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Aug 2023 19:27:49 -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.
=========================================
View Transitions
----------------
- RESOLVED: We ask for CR transition for view-transitions L1 (Issue
#8878: Move CSS View Transitions Level 1 to CR)
CSS Anchor
----------
- RESOLVED: Add the anchor-center value (Issue #8979: Add the
“centering” behavior which is now defined as an example
in the specs as something built-in)
Alignment & Positioning
-----------------------
- RESOLVED: Define this new auto behavior for anchor-center. Bring
this issue back with examples for the rest (Issue #9124:
Better interaction of auto insets and self-alignment
properties?)
CSS Text
--------
- RESOLVED: Name it [the word-break value] 'auto-phrase' (Issue
#7193: Don't provide a language parameter for
word-boundary-detection)
- RESOLVED: If your phrase is too long you should break at a normal
word boundary rather than overflow (Issue #7193)
CSS Contain
-----------
- RESOLVED: Add these four container font relative units and their
functional versions to target specific containers (Issue
#8855: Add container-font relative units)
CSS Shapes
----------
- RESOLVED: We fix the example and tests based on it (Issue #8695:
Optional values shouldn't be serialized)
- RESOLVED: Remove the part about serializing calc expressions from
Shapes spec (Issue #8695)
Media Queries
-------------
- RESOLVED: Restrict comparison syntax to the mf-numeric-value
production, not the mf-value production (Issue #8998:
Parsing strategy for range syntax)
Selectors
---------
- RESOLVED: Change from -- to state (Issue #4805: Custom state
pseudo class proposal)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Aug/0000.html
Present:
Joey Arhar
Tab Atkins
Elika Etemad
Chris Harrelson
Daniel Holbert
Ian Kilpatrick
Una Kravets
ChangSeok Oh
Florian Rivoal
Khushal Sagar
Alan Stearns
Miriam Suzanne
Regrets:
Jonathan Kew
David Leininger
Bramus Van Damme
Sebastian Zartner
Chair: astearns
Scribe: dael
astearns: This is good attendance so we should get going. We'll
shuffle to item 1, 3, 2, 10 and then get to the rest
astearns: Any other changes?
View Transitions
================
Move CSS View Transitions Level 1 to CR
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8878
khush: Got a lot of excellent feedback last time. I mentioned
changes since last discussion. Horizontal reviews are done.
khush: No response to security.
khush: No inline issues in spec. Covered a good chunk at F2F.
fantasai did a full review of spec, thanks for that
khush: Any remaining issues are editorial
<khush> https://drafts.csswg.org/css-view-transitions-1/#viewtransition-process-old-state-captured
khush: One spot where I could use a suggestion is ^
khush: When doing the ED for L2 spec with the cross-doc API it was
unclear how to hook into the L1 code. During course of
navigation we capture an object and then want to resume.
khush: L2 sets up object, creates and object that's opaque. L2 then
resumes. [missed]. Other than that I don't think there's
anything remaining to push to CR
astearns: Reason to put that into L1 algo is what?
khush: L2 describes steps specific to cross-doc navigation elements.
A bit intertwined with L1 sets that create view transition
object and capture everything and in same doc allow render.
In cross doc you take, cache, and render to other doc. Unless
it's all in same spec it's hard to capture all of this. We
did the opaque step to capture it.
khush: In HTML it's one spec so you just add, but wasn't sure better
how to do it here
chrishtr: Is this blocking the spec?
khush: No
chrishtr: So it's a no op in l1?
khush: Yes, it's a no op
chrishtr: Sounds like good feedback, but orthogonal
astearns: Seems odd to have in module level when the thing isn't in
the module level. I think it's fine to have it or not
have it
khush: When we're far into the L2 we can figure out best way to
structure
astearns: Second question, I'm assuming changes are all up to date?
fantasai: I did a line by line review in June and filed issues then
which we discussed a couple weeks ago. Haven't
specifically reviewed changelogs
<khush> https://drafts.csswg.org/css-view-transitions-1/#changes
khush: End of spec has an appendix with all the changes
astearns: Any other questions or opinions on going to CR with view
transitions L1
astearns: Not an issue for going to CR, how is the test suite?
astearns: Do we have the start of a test suite?
khush: There's lots of WPTs for this
fantasai: One thing I would say is process old state capture thing
probably could be better explained. That's editorial and
doesn't need to block CR. I'd say fine to go to CR. It
will take a few days to get all the things through and in
the meantime we can look at editorial issues
astearns: Proposal: We ask for CR transition for view-transitions L1
astearns: Objections?
RESOLVED: We ask for CR transition for view-transitions L1
khush: Thanks everyone for the feedback
fantasai: We should also publish a WD today so state of draft is
updated
astearns: Yes, that'll make publication easier
khush: One PR yet to land so publish after that?
fantasai: Yes, and editorial changes don't need CR approval
CSS Anchor
==========
Add the “centering” behavior which is now defined as an example in the
specs as something built-in
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8979
TabAtkins: The very first example in the spec shows a common use
case. Center positioned element over anchor with a bit of
safety
TabAtkins: If centering would overflow CB we shift you a little off
center.
TabAtkins: Cool you can express this, but it's a bit complicated. We
had an issue to make it easier
TabAtkins: Luckily in grid-based proposal there was an alternative.
A new self-alignment value 'anchor-center'
TabAtkins: If you're using anchor positioning and are abspos it will
attempt to center you over the element in the axis you
spec. If strict center causes overflow we'll shift a bit
TabAtkins: I have a PR with spec text.
TabAtkins: To decide on: should this live in anchor positioning or
alignment? I put in anchor positioning
TabAtkins: A few more detailed questions on exact mechanics if no
general concerns
TabAtkins: Opening the floor for questions
astearns: Seeing +1 in issue. Other opinions
<fantasai> +1 to adding it, but I haven't had time to review the
spec text
<miriam> +1
<una> +1
dholbert: Took a quick look and it makes sense to me. Nice to have
easy syntax to do the thing people will want
<chrishtr> +1
<florian> +1 to the idea, didn't review the PR yet.
<changseok> +1
astearns: I do think makes sense to leave in anchor positioning for
now since defined based on anchor properties
astearns: Lots of +1s
astearns: Objections to adding the anchor-center value
RESOLVED: Add the anchor-center value
astearns: You said there were details. Would it make sense to get PR
in and raise separate issues?
TabAtkins: That would be good.
Alignment & Positioning
=======================
Better interaction of auto insets and self-alignment properties?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9124
TabAtkins: This is a generalization of one detail on anchor-center.
When defining it, I realized if we didn't change anything
about auto insets it wouldn't work very well. To make
anchor-center work you need to set left and right to 0.
TabAtkins: This is because current behavior is designed around
certain assumptions and lacks of functionality CSS 2 had
but we've since filled in. If you have a single auto it
tightly wraps you element to align in the obvious way.
This type of behavior made sense in CSS 2.
TabAtkins: We now have better. The behaviors with rough
approximations no longer make sense. anchor-center spec
that double auto insets resolves one to 0 and the other
to the same distance in other direction so you get
largest possible non-overflow
TabAtkins: In the other case, makes sense to do something similar
and set auto insets to 0. If there's not 0 then alignment
doesn't do something useful. Right now double auto makes
you'd align staticpos not abspos.
TabAtkins: In the presence of an affirmative signal you want
alignment, meaning you set an alignment to non-initial,
we probably want to change
TabAtkins: Pro: for any non-initial value for self alignment
properties we resolve auto to 0. We keep current for
default, can't change that. But if you say something like
start-align it makes sense to give them an inset CB you
can position into
TabAtkins: For abspos elements if self-alignment property is
non-default we resolve auto to 0. I want to leave
possibility to do more subtle things. For example
anchor-center is a little smarter, but similar in spirit
TabAtkins: I don't believe anybody implements yet. We are about to
in Chrome. If anyone does, hopefully reasonable change.
TabAtkins: Thoughts?
fantasai: I'm not 100% sure that's compat with flexbox and grid
which are spec to honor alignment properties for staticpos
<fantasai> https://www.w3.org/TR/css-position-3/#abspos-insets
fantasai: There is behavior in positioning spec for these values
where alignment is with respect to staticpos. I disagree
nothing useful to be done without setting to 0
TabAtkins: Compat isn't an issue because chrome at least doesn't
support there. It's a change in spec, but not a change in
actual behavior. Not sure on other browsers
iank: Small change for us, but I don't think it would be web compat
issue
TabAtkins: I also believe for single non-auto case it's pretty
straight forwardly bad if you're indicating you want to
align
fantasai: In grid or flexbox you're aligning to the container that's
your parent
TabAtkins: Single auto, not double
TabAtkins: Single I think this is clearly right
fantasai: Oooh, okay.
<iank> +1 that its a better behaviour for the general case.
TabAtkins: In the double case, the new behavior aligns you in abspos
CB. I believe that's better. anchor-center definitely
wants it and I suspect better in the general case. Often
it's similar.
TabAtkins: The staticpos rect doesn't seem the most useful
fantasai: In flexbox align-self to does and effect when you're
staticpos. Same for grid.
fantasai: Also you're losing functionality by doing that because
then you can't align in staticpos which in grid/flexbox is
your parent and in block it's left/right which has some
uses. You want to be in static but align to end for example
fantasai: I don't mind changing for single auto where other end is
anchor because you're not doing static at that point. So
saying treat the other side as 0 doesn't seem
unreasonable. I don't think we should change spec
<fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22display%3A%20grid%3B%20border%3A%20solid%3B%20width%3A%20100px%3B%20height%3A%20100px%22%3E%0A%20%20%3Cdiv%20style%3D%22position%3A%20absolute%3B%20border%3A%20solid%20orange%3B%20align-self%3A%20end%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E%0A
TabAtkins: Main counter is all staticpos behavior is a weak approx
of what you can do with anchor pos. Anything you can do
with static you can do better with anchor. So preserving
isn't that relevant
astearns: iank has been on the queue for a bit
iank: Generally, I don't think people rely on staticpos often.
iank: With self alignment I don't think we'll have compat issue
iank: When I played with it seemed like an upgrade for authors
iank: Getting to compat, staticpos was already weird because
align-self would impact both axes. I think this is an upgrade
for double-auto. We're prepared to take web compat hit to see
if this is compat
chrishtr: iank question on flexbox/grid. Are there use cases there?
iank: Not particularly. You have the case where your CB is the
parent. When the abspos they make the parent relpos. When
mostly using abspos no behavior change. I agree with TabAtkins
anything needing staticpos can be done better with anchor
dholbert: Better to separate replaced and non-replaced elements.
Replaced elements have intrinsic width. Actively giving it
left:0 right:0 will stretch and I don't think that's the
intent
iank: Intent would be we don't stretch when we resolve to 0. We keep
shrink to fit. We're changing used not computed value. So you
look at computed when determining to stretch
TabAtkins: We're not changing initial value behavior. Only if you
set the self alignment property to specific
dholbert: Default doesn't have something, you set align-self:center
and then it stretched
TabAtkins: Center doesn't trigger stretch
dholbert: Even if it's top/bottom set to 0
TabAtkins: I think so. It would be a spec bug if it does, I think
chrishtr: My understanding is this substantially simplifies engine.
Correct?
dholbert: I think so from when I tried to implement the grid change.
Simpler not to have to compute the auto offset if you
don't have to
iank: It's a straight up simplification and matches what devs expect
astearns: I wonder if we could resolve to define this for
anchor-center for now and keep this open and have fantasai
look at flex/grid use cases and come up with here is what
we'll lose with examples?
TabAtkins: We've already significantly chopped down staticpos
behavior for flex and grid. If fantasai wants to spend
time, happy to keep open
iank: Presence of anchor being there is an important caveat
fantasai: Yeah, I think that you don't lose as much with anchor
positioning. I think the areas I'm more concerned is block
layout
TabAtkins: Haven't thought about block yet so happy to discuss there.
iank: I don't think you lose anything with block because if you need
to you make the static parent an anchor and target the edges
you're interested in
fantasai: How would you do that automatically?
TabAtkins: I think we should go into the details in issue
astearns: Proposal: add this new behavior for anchor-center and
leave the issue open for if this is extended to the rest
of the non-initial values
fantasai: I think for anchor-center this does make sense
<una> so will there be a new issue open for that?
astearns: [reads una] I think we leave this one open since it's not
an anchor-position specific issue
dholbert: And anchor-center is a bit more magical than this proposal
astearns: Is that okay una?
una: Sounds good
<dholbert> This is the testcase that I was looking at for "what are
the effects of the used value being auto vs 0", fwiw:
https://jsfiddle.net/dholbert/15y3dqu2/
iank: Can we try and get back within the month?
astearns: Proposal: Define this new auto behavior for anchor-center.
Bring this issue back with examples for the rest
astearns: Objections?
RESOLVED: Define this new auto behavior for anchor-center. Bring
this issue back with examples for the rest
CSS Text
========
Don't provide a language parameter for word-boundary-detection
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7193#issuecomment-1656188302
chrishtr: My understanding is we're all in agreement but need a name
chrishtr: Three suggested are what I mentioned
<TabAtkins> I'm weakly towards "phrase" just to suggest what it's
actually doing.
<TabAtkins> and that keyword sounds reasonable from a complexity
standpoint
chrishtr: Reason to choose 'auto-phrase' is because it could
fallback if there isn't platform support
florian: I think 'auto' alone would not be good
florian: I think auto alone would be a bad value because it already
has a normal. 'auto-phrase' is reasonable. I think
'keep-phrase' would also be okay. I could go either way
between those
fantasai: Interacts a bit with property name for the
whitespace-text-transform-something which automatically
inserts spaces at these points. A keyword that can be in
both makes sense which 'auto-phrase' does that. 'auto' is
too generic and 'keep-phrase' doesn't work for word
boundary
florian: Agree
astearns: Arguments for anything else?
astearns: Objections to naming it auto-phrase
RESOLVED: Name it auto-phrase
fantasai: As people implement this, one consideration we need to
make sure is when you turn this on you don't end up
triggering overflow because the phrases. We'll want to
avoid that, particularly if it's long or it's foreign and
you can't understand. Normal should be to wrap at a
boundary not overflow
chrishtr: Makes sense
astearns: Anything to resolve here?
fantasai: Proposal: If your phrase is too long you should break at a
normal word boundary rather than overflow
astearns: Comfortable with that?
florian: Yes
astearns: Proposal: add a principle saying you should break within
the phrase instead of overflowing
astearns: Objections?
RESOLVED: If your phrase is too long you should break at a normal
word boundary rather than overflow
CSS Contain
===========
Add container-font relative units
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8855
miriam: We added cq units that are similar to viewport. cqi, cqv
etc. several use cases for getting something like rems but
relative to container. cqch, cqex, cqem and cqlh. cqem and
cqlh are clearest
<fantasai> sgtm
miriam: Other question is this came from an issue we resolved by
adding functions for cq units so you could access the unit
on a specific container. We can consider that here.
miriam: Question is do we want these 4 cq relative units
TabAtkins: I think this is reasonable. We also should put this into
functional syntax. If you can access some aspects of an
arbitrary container, getting to the font bits makes sense
TabAtkins: +1 to the full proposal
<una> +1 this proposal makes sense!
astearns: Proposal: Add these four container font relative units and
their functional versions to target specific containers
astearns: Objections?
RESOLVED: Add these four container font relative units and their
functional versions to target specific containers
CSS Shapes
==========
Optional values shouldn't be serialized
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8695
fantasai: The CSS shapes spec tries to spec serialization but does a
couple of things that don't make sense. In an example it
says omitting components shows some default values don't
show in serialization.
fantasai: You can omit @position so that doesn't make sense. We have
interop that we always serialize, but since you can omit
you should allow to omit. Shortest serialization principle.
fantasai: Second is some guidance about avoiding calc and calc
transforms, but that conflicts with rules about
serializing position in calc.
fantasai: In this case, should defer to rules in values 4
<TabAtkins> strong +1 to making these consistent now
astearns: This was written before the rules. Intent was always to be
superseded by calc. Happy to defer to existing text now
astearns: First bit needs to stay in shapes because talks about
specific shapes values, right?
fantasai: I think we just need to correct the example and remove/fix
the tests
astearns: Any concerns about anybody relying on this? I don't think
I have any
astearns: Proposal: We fix the example and tests based on it
astearns: Objections?
RESOLVED: We fix the example and tests based on it
astearns: Proposal: Remove the part about serializing calc
expressions from Shapes spec
astearns: Objections?
RESOLVED: Remove the part about serializing calc expressions from
Shapes spec
astearns: Did you happen to look at the tests for serializing calc
in Shapes? There may be some that need updates
fantasai: I think there are tests, but I don't remember where
they are
astearns: Anything else on this one?
Media Queries
=============
Parsing strategy for range syntax
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8998
TabAtkins: It was pointed out that the mathematical syntax for MQs,
specifically equals, <, >, etc. didn't restrict the value
very well. You could say resolution = infinite. You need
to know too much information to know what's the MQ,
what's the keyword
TabAtkins: I think it's an oversight
TabAtkins: Proposal is when you use comparison syntax we restrict
value to numbers, dimensions, ratios. If you want a
keyword you use colon syntax
astearns: Opinions?
TabAtkins: I think this is just an oversight. It's a mature spec so
we need a resolution
astearns: Proposal?
<fantasai> makes sense to me
TabAtkins: Restrict compare syntax to the mf-numeric production
astearns: Objections?
<TabAtkins> restrict comparison syntax to the mf-numeric-value
production, not the mf-value production
RESOLVED: Restrict comparison syntax to the mf-numeric-value
production, not the mf-value production
Selectors
=========
Custom state pseudo class proposal
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1344721034
jarhar: I was working on getting this spec. Has :-- custom name
syntax. Suggestion was :state instead of :-- for custom
name. Turns out there was discussion in 2020
jarhar: I don't have a strong opinion. I wish [missed] was here to
state his case.
<jarhar> https://lists.w3.org/Archives/Public/www-style/2020May/0017.html
jarhar: Previous resolution minutes ^
astearns: Whatwg issue sounds like the idea is that it's more
consistent with :part
fantasai: oriol posted a comment that :--was discussed for another
kind of custom selector?
<fantasai> https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1662763534
TabAtkins: Yeah. For like saying :--heading that was equivalent of
h1, h2 etc. Having the clash isn't ideal, though doable
astearns: Always favor a name over ascii gibberish to make it easier
to see what you're trying to do. Not a strong opinion
TabAtkins: Looking at the discussion where we decided, looks like
everybody was unenthusiastic. If we decide to revert to
:state I think that's fine
TabAtkins: Counter argument was from plinss who wanted it not to be
too distinct. The --makes it look like a normal pseudo
class. I don't have a big opinion
astearns: We could resolve to change to :state which makes it easier
to get through whatwg. plinss can raise a new issue if he
chooses
fantasai: I think it makes more sense. We use --names when
declaring, but not when pulling information from another
system. Makes sense to not use -- for this case from what
I understand it to be
<florian> +1
astearns: Anyone want to wait on a resolution to make sure plinss is
on board?
astearns: Objections to changing from -- to state
RESOLVED: Change from -- to state
astearns: That's time. Thanks everybody for joining us on zoom.
astearns: I'll set up the calendar invite for the rest of the month
soon. Talk to you all next week
Received on Thursday, 3 August 2023 23:28:24 UTC