- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Dec 2023 20:06:43 -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.
=========================================
Upcoming Meetings
-----------------
- Next week there will be an extra hour of meeting to cover
additional topics.
- The next F2F will be Feb 12-14 in Mountain View CA. Group members
are asked to add to the wiki if they will be attending.
CSS Values
----------
- RESOLVED: Percents that are resolved against numbers do that at
parse time (Issue #9395: Resolve `<percentage>`
representing `<number>` or `<angle>` at parse time)
- RESOLVED: Drop mix() from Values 4 (Issue #9343: Abandon mix()?)
- RESOLVED: We will never use mix to represent a single interpolated
value but may have something like it for expressing the
whole interpolation (Issue #9343)
Scroll Snap
-----------
- RESOLVED: Specify option 7 [Join with preceding ranges if there are
later overlapping ranges and the gap is short] as
normative behavior (Issue #9187: Improve or clarify
nested snap behaviors)
- RESOLVED: Specify the whole list in this order as normative
behavior (Issue #9622: Standardize snap point selection
with multiple aligned boxes)
CSS Lists
---------
- RESOLVED: Revert the previous resolution and the associated edits
(Issue #5477: CSS counter scope/inheritance is
incompatible with HTML ordinals)
- RESOLVED: The working group is interested in defining an opt-in
narrow scope for counter resets. Exact syntax tbd (Issue
#5477)
Scroll Animations
-----------------
- The group wants to make sure that if we make changes in issue #8915
(Blocking effects of timeline-scope) it wouldn't lead to problems
that would make containment less impactful. Discussion will
return to the issue for more investigation.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Dec/0000.html
Present:
Tab Atkins-Bittner
Elika Etemad
Robert Flack
Daniel Holbert
Dael Jackson
Vladimir Levin
Peter Linss
Florian Rivoal
Alan Stearns
Miriam Suzanne
Regrets:
Rachel Andrew
Oriol Brufau
Chris Harrelson
Jonathan Kew
Bramus Van Damme
Sebastian Zartner
Chair: astearns
Scribe: dael
Upcoming Meetings
=================
astearns: I think we can get through a few things today
astearns: Housekeeping- I posted the possible agenda for an extra
hour of meeting that I'm planning to announce for next week
astearns: It's the hour before the regular meeting. I'll get that
posted today and ask if there's anything else to add
<@astearns> https://wiki.csswg.org/planning/mountain-view-2024
astearns: Second, TabAtkins announced to private list we have a
meeting for Feb 12-14. There is a wiki page up. Please add
at least your name so we know who is coming
astearns: I think that's it for my housekeeping. Anything else?
fantasai: We should try and plan F2F after that at some point
astearns: Yep. On my list to poke Tess about the Apple hosted-meeting
fantasai: I think we're still on for that. Main thing to figure out
is dates
astearns: I'll get that going too
CSS Values
==========
Resolve `<percentage>` representing `<number>` or `<angle>` at
parse time
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9395
TabAtkins: Pointed out that while the spec says we simplify trees at
computed and used time, there's significant browser
interop at resolving percents of numbers at parse time.
Calc(50%) in opacity and you read back immediately you
get .5
TabAtkins: I don't have much of an opinion. I'm fine leaving spec
as-is or with modifying spec to say % resolved against
numbers are resolved at parse time. Either is okay with
me, so question of what do browsers want to do
fantasai: Another relevant question is would authors have an opinion
on it
TabAtkins: I've never heard anyone have an opinion. I haven't looked
deeply, but haven't spotted it
fantasai: I think tend to keep specified values as specified. Example
a lot of color stuff could be at parse time, but we don't.
Same with bg position stuff
astearns: If we decide we want that behavior is it likely that all
the browsers will change their current code to adapt?
TabAtkins: Given I'm not seeing anyone say anything, I suggest we
resolve to match browser behavior
florian: Only thought against that direction is the more you preserve
the easier it is for browser tools that work off OM. But not
sure if we've followed that enough for it to be practical
TabAtkins: Agree. And if you want high quality you have to do it like
dev tools
astearns: And there is now a dev tools API
TabAtkins: It is very important to get access to the invalid stuff
and you cannot get it from the OM. I'm not super
sympathetic to needing values for an editor concern.
Author surprise would be different, but I don't see that.
fantasai: Situation is we're kind of inconsistent where some things
can resolve and some can't?
astearns: For things that do resolve against a number, only exception
is filter argument.
florian: Anyway, I think Tab's suggestion is reasonable
TabAtkins: Can drop some tests and highlight that filter effect needs
a change
fantasai: Just put a warning where you write the thing that it's not
always going to resolve like line-height
astearns: An example of something that looks like it would work but
doesn't would be reasonable to put in spec
TabAtkins: I think line-height is most reasonable thing. Good idea
astearns: Proposal: Percents that are resolved against numbers do
that at parse time
astearns: And we'll have an example of something that doesn't quite
fit the pattern and we'll add wpt for this
astearns: Objections?
RESOLVED: Percents that are resolved against numbers do that at parse
time
Abandon mix()?
--------------
github: https://github.com/w3c/csswg-drafts/issues/9343
TabAtkins: First off, to clarify. Since issue was filled mix() gained
a new syntax. We're not talking about that. This is about
dropping original feature for mix(). It was intended to
let us represent values that couldn't be written as
computed but do interpolate
TabAtkins: Since then we added sufficient specialized functions to
values 5 to handle all cases we know where this happens.
Only a handful of cases that needed the generic
interpolation.
TabAtkins: So, I believe we can drop the generic interpolator and
stick with the specific ones that handle each thing that
needs special behavior
florian: And it did not represent things that are not interpolable?
TabAtkins: Correct, it was invalid syntax
fantasai: Two reasons mix was added. One was for these interpolations
that you can't show intermediary value. Other was create
syntax to allow authors to represent an interpolation of a
value between two breakpoints in a MQ. It's not that the
intermediary can't be represented but it's because you want
a range depending on another calc
fantasai: That's what mix was originally for. Since then, TabAtkins
and I decided it should be kicked from level 4. But the
other function of mix where you can take a whole property
value and interpolate between it and another value based on
how far you are in a 800px window
florian: And you could represented it but not well?
fantasai: You could, but now that there's calc-mix you can represent.
But if you have something like discrete keywords you can't
unless there's an existing mix value
miriam: You've basically answered my question.
TabAtkins: They cover the case for the types they're meant for.
There's a bunch of types like keywords that don't have a
mix function
miriam: That use case feels useful to me
fantasai: I think there are reasons to want something like mix. I
don't think we want to impl as is. Reasonable to resolve
not in L4 but seems reasonable to explore
TabAtkins: Also resolve that we're not intending mix to represent
intermediate values would be good. But intent that it's
useful for authors to say somewhere on this path is good.
Good to resolve that we're not keeping mix to rep
intermediate values
astearns: Proposal: We will drop mix from L4. Specifically, we don't
want to use it for the generic representation of
interpolated values but we may in a future level come up
with something like mix to express the interpolation itself
fantasai: 2 resolutions. Drop mix from Values L4. Second is: Keep
exploring mix for interpolation use cases but not for
representing a single interpolated value
<TabAtkins> proposed: we're not keeping mix() *for the purpose of
representing intermediate values*. keeping it for
*authors wanting to interpolate arbitrary things* is
still on the table
astearns: First part, drop mix from Values 4. Objections?
RESOLVED: Drop mix() from Values 4
astearns: Second is we will never use mix to represent a single
interpolated value but may have something like it for
expressing the whole interpolation
fantasai: It shouldn't be the only way to represent the value
RESOLVED: We will never use mix to represent a single interpolated
value but may have something like it for expressing the
whole interpolation
Scroll Snap
===========
Improve or clarify nested snap behaviors
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9187
flackr: Previously discussed this. Use case is when you have nested
snap points want to respect inner ones as discrete stops that
are separate.
flackr: Previously suggest avoiding inner, but that mad tiny gaps.
fantasai had alternate that joined inner with outer that
follows. Had some concerns about asymmetrical
flackr: Compromise is when the gap between the inner snap areas is
larger than viewport it's a discrete area you can snap to.
When it's smaller it joins with previous inner snap area
flackr: Already have a condition for length between snap areas. And I
think it satisfies both use cases. Made a demo page with all
the various proposals. Adam tried it out and voted his support
flackr: Hoping we can go with this.
<TabAtkins> I haven't been able to experiment with this myself, but
Adam has and likes flackr's suggestion, and it does sound
pretty reasonable.
<TabAtkins> So +1
fantasai: Compare to scrollport or snapport?
flackr: Snapport
fantasai: Sounds like a good direction. Not sure how final we'll be
until there's a prototype, but happy to go in this
direction. Wondering if we want to spec it out now or spec
as you could do this but it's technically undefined
flackr: I'm in favor of spec out and pushing for this to be the
direction. We already have browser differences. It feels like
spec will bring more attention
<astearns> +1 to specifying behavior
fantasai: Yeah, I think we put algorithm in spec. Just if we should
require or if it's an example
florian: This will be fiddly, so we should we write it with intent
that it's normative so we get same behavior
fantasai: Okay
flackr: +1
astearns: I didn't read all the options
flackr: I did make prototype so we can play with it
astearns: Is it option 7 or option 7 plus other things?
flackr: Just option 7
florian: I wouldn't be surprised if we have to revisit once people
play with it, but until then this is a reasonable place to
start
astearns: Proposal: Specify option 7 as normative behavior
astearns: Objections?
RESOLVED: Specify option 7 as normative behavior
astearns: Thanks flackr for doing the demo and going through options
Standardize snap point selection with multiple aligned boxes
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9622
flackr: The spec says that when there's multiple boxes that are
currently in a valid snap position, other than preferring
targetted the browser can pick any box. I feel this makes
spec things like snap events harder and I'd like to
normatively define in these cases
<TabAtkins> +1 to this proposal, and specifically the exact proposed
list. I think flackr's example for keeping 5 and 6 in the
current order makes sense
flackr: Proposed a specific algo here that preserves the intern for
focused elements but then items that are aligned in both
axis, inner elements.
flackr: Basically, trying to provide a standard answer for what is
the snapped item.
<@fantasai> TabAtkins, flackr's example isn't about the ordering,
just about whether 5 makes sense as a rule
<TabAtkins> disagree, I think it's a good example of why you *should*
eliminate the large element from being the snap target
before you discover there's an overlap in the axises
florian: Here too I think good to have specific behavior encoded.
Proposal here, are the rules because they make sense or is
it having observed people in these cases this works better
flackr: Constructed rules to what I think makes sense
florian: Okay. Doesn't mean I object. But because we're not spec we
may have browser differences so it gives us room to pick a
good one. I'm not sure if it's easy to find use cases that
depend on this, but would be good
flackr: If it helps, Chrome is semi-random because depends on
construction order
florian: How would we go about finding live use cases that fall into
this
flackr: Only way you can observe which item is snapped is by which
item is snapped when you change layout. Only way authors
could do this today is scroll changes but relying on multiple
aligned items
florian: I guess you won't break much if you change
flackr: It's a bit of an edge case
astearns: There's talk in IRC about order of step 5 and 6
fantasai: Step 5 is inner vs outer and 6 is about if you happen to
have snap positions in two axis that come from same element
you want that element rather than snap in one axis
flackr: Yes, if you have a 2d you want something that aligns in box
axis.
fantasai: If you have a 9 grid you care about the one in the middle.
Okay
flackr: As I mentioned, 5 might not be necessary. If you have inner
area aligned it could make snap not valid for the outer area
flackr: No strong feelings about which one goes first
<TabAtkins> I have medium-strong feelings that the current order is
best.
flackr: Sorry, I do. I posted an example. You have an inner item
aligned. Technically both boxes in my diagram are snap for
inner and outer. You probably want the aligned
fantasai: But if they're aligned in both axis you skip set 6
TabAtkins: If you take same case but more inner one inside a bit, it
does argue better behavior is block axis to take the inner
so you don't want it eliminated by match checking
florian: I agree
flackr: Agree with that
fantasai: Okay
astearns: Consensus on ordering. How much of this do we make
normative?
astearns: With my chair hat off, I'm in favor of spec the whole
thing. Otherwise we may not find issues if people don't
impl whole list
flackr: My preference as well. And impact is subtle. Only observable
today is what is aligned after layout change
florian: I don't think there's complexity to give variance to
browsers. Have a precise behavior seems good for complex
demos
fantasai: Where are snapping events defined?
flackr: Scroll snap 2
fantasai: They're not published so should do something about that.
This becomes more critical for level 2
astearns: fantasai are you okay spec the whole list as normative?
fantasai: Okay with that. Could mark as at risk for L1, but should
write it all out
astearns: Proposal: Specify the whole list in this order as normative
behavior
flackr: I think it's not too hard to test. I'll help
astearns: Objections?
RESOLVED: Specify the whole list in this order as normative behavior
fantasai: What should we do about scroll snap L2 draft? It's just
an ED
astearns: Is it ready for FPWD?
fantasai: Don't know
flackr: Have a PR in progress to add detail about event timing. This
issue is in support of changing the targets of snap events to
be a single element in each axis
flackr: I guess that's to say I don't know
florian: Land the PR and then publish?
flackr: I think finishing the inflight PR would make sense
astearns: fantasai, how about you open an issue saying we should have
a FPWD for L2 and people can comment and get focus
CSS Lists
=========
CSS counter scope/inheritance is incompatible with HTML ordinals
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5477
TabAtkins: A little while ago...several years...we talked about what
changes to make to the counter scoping algo to make it
workable as a mechanism to explain html lists
TabAtkins: html lists have weird behaviors for legacy reasons. I
tried to write a fix that fixed what's in the thread but
there's close behavior it did not solve. A related change
that would fix both is define a counter has an associated
scope, wide or narrow. Default is wide where it's visible
to children and following siblings until scope of same
name is declared. Narrow is only visible to children
TabAtkins: That matched how counters. You have an ol and outside of
that you have an li, today because wide scoping the li
sees the counter scope from the ol and will increment that.
TabAtkins: There's some reasonable cases that are less intuitive due
to wide.
TabAtkins: Ability to declare scope to be narrow fixes this properly.
It will be somewhat magic same way list item counter is.
Will be slightly more reasonable for authors where they
intent it to number a list among children
TabAtkins: Concept also carried to when thinking about toggles.
Having wide and narrow was necessary there. I think it's
proved out that is useful.
TabAtkins: Precise mechanics I have not figured out. Happy to take a
resolution to figure out
florian: Wide is default and narrow is opt-in to match html?
TabAtkins: Correct
astearns: Other questions or opinions?
astearns: First thing would be revert previous?
astearns: Proposal: Revert the previous resolution and the associated
edits
astearns: Objections?
RESOLVED: Revert the previous resolution and the associated edits
<TabAtkins> valid markup that gets weird currently is in
https://github.com/w3c/csswg-drafts/issues/9076
astearns: Proposal: The working group is interested in defining an
opt-in narrow scope for counter resets. Exact syntax tbd
TabAtkins: I expect it'll work same as reverse counter specs, but I
haven't dug in enough to be certain
astearns: Objections?
florian: Question- you mentioned html has weird edge case. Narrow
scope seems too clean to cover. Do we end up matching html
or is there a bajillion corner cases where we're different?
TabAtkins: I think this brings us all the way or very very close
enough that browsers could call it good. I know wide
behavior is web breaking if applied to html counters
florian: We'll discover it soon enough. We create narrow and if it
doesn't work people will tell us
TabAtkins: I think remaining weird was list item counter and we
resolved how to handle that. Where if you don't declare on
an ol it happens. I'm not completely loaded on this and
it's complex
RESOLVED: The working group is interested in defining an opt-in
narrow scope for counter resets. Exact syntax tbd
TabAtkins: Issue #9076 was also covered in this discussion as well.
It was the same case
Scroll Animations
=================
Blocking effects of timeline-scope
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8915
astearns: On the agenda to confirm we do want style containers to
block timeline names from escaping. Is it container queries
or style queries?
florian: Container query on which style is based?
astearns: Anyone have a better handle on this?
florian: Superficially this seems fine to me
astearns: We had already resolved we'd not allow timelines to escape
a container of some kind
miriam: Containment for container queries includes style. If you set
up an inline size container you are implicitly adding style
containment. That's scope the timeline name
flackr: And that seemed unnecessary restriction and might want to
scope the layout that has containment
astearns: From my recollection we have other names that don't leak. I
think just doing this to be consistent?
florian: I think...I think it would be appropriate to spend more time
on this. Containment is not just useful behavior, but
guarantee that certain constraints are matched. Just because
we can't immediately find a case where there's a problem
doesn't mean there isn't one.
florian: If we build this and the web depends on it but it doesn't
work that breaks container queries. We don't want to defeat
containment by doing this.
vmpstr: I think this is an observation that lets us skip work in
subtree. If these names escape the work becomes necessary
flackr: Agree. If we want to leak better to say size containment
doesn't require strict style containment
flackr: Issue came about because using a container query
florian: Types of containment don't have dependency, but container
queries use both
flackr: I think that's what we're getting at, the core. You should be
able to leak names even if have container
florian: So style is strict but not invoked
miriam: Have to do part because counters escaping
flackr: Need to think through
florian: That means breaking style containment into two things. One
is invoked by container and the other is not but is by
content visibility.
florian: I suspect explicit values are better if we go there
astearns: We're not going to get to a resolution today. Let's take it
back to the issue and try and work this through
astearns: Thanks everyone for calling. There will be an extra hour at
the start of next week's meeting.
astearns: Please put your availability on the Feb wiki
Received on Friday, 8 December 2023 01:07:16 UTC