- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Feb 2022 18:54:24 -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.
=========================================
Scroll Snap
-----------
- RESOLVED: Start Scroll Snap 2 ED, with :snapped and snapping event
model, with Adam Argyle as additional editor (Issue
#6985: Proposing `:snapped`: exposing private snapped
item browser state for developers and designers)
CSS Tables
----------
- RESOLVED: Accept current Tables 3 spec text regarding calculation
of shared borders in collapsed-border mode between table
and cells (Issue #6230: Collapsed table first row width
quirk)
CSS Text
--------
- The group will check for other compat concerns and look further
into if Firefox would consider instead making NULL U+0000 visible
and then resolve based on that discovery (Pull Request #6983: The
web de-facto requires NULL U+0000 to not be visible)
CSS Contain
-----------
- RESOLVED: Close no change (Issue #6376: Bikeshed the container
property & at-rule names to avoid confusion with other
usage of contain/container)
- RESOLVED: Restrict container-name to just idents (Issue #6405:
container-name string vs ident)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Feb/0010.html
Present:
Adam Argyle
Rossen Atanassov
David Baron
Tab Atkins Bittner
Oriol Brufau
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Chris Harrelson
Daniel Holbert
Dean Jackson
Jonathan Kew
Una Kravets
Vladimir Levin
Daniel Libby
Rune Lillesveen
Ting-Yu Lin
Peter Linss
Alison Maher
Eric Meyer
François Remy
Morgan Reschenberg
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Rachel Andrew
Chris Lilley
Lea Verou
Scribe: TabAtkins
Scribe's scribe: fantasai
Scroll Snap
===========
Proposing `:snapped`: exposing private snapped item browser state for
developers and designers
---------------------------------------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/6985
argyle: Explainer in the issue
argyle: Hacks and intense work with IntersectionObserver to figure
out what element is snapped to.
argyle: Especially with snapping being a 2-d thing, where it can be
snapped to two elements
argyle: And multiple elements could overlap, any of which could be
the snappee
argyle: This proposal attempts to deal with layout-dependency issues
argyle: And lets the user know if there is a snapped element
argyle: Biggest gotcha is that if you have a scroller that's shrink
wrapped so items don't have padding, not every item might be
snappable
argyle: So this isn't necessarily useful for selection
argyle: Example, header tabs in a scroller, and whichever is snapped
to determines the contents of the tab
argyle: Right now people go to JS that does synthetic scrolling and
snapping to do things like this
argyle: So this brings the functionality into CSS.
argyle: The explainer addresses the previous issue; using
scroll-padding can enable all elements to be snapped
argyle: Second biggest issue is avoiding the :hover issue, where
something can "jiggle" matching
argyle: CSS has "loose" and "tight" loops, whether it goes out to
user interaction or cycles within the style engine
argyle: The explainer defines how to have :snapped be a loose loop
like :hover, once per frame
argyle: And it would only be able to infinite-loop during user
interaction; it wouldn't be able to jiggle on its own while
the page is at rest
argyle: So devs *could* apply styles to make something snap/unsnap
rapidly while the user is interacting, but that's it, and it
should hopefully be very obvious
argyle: So our hope is that we can take the good success of :hover
and apply it over to :snapped, letting users do snapping
control without JS.
argyle: Maybe flackr or TabAtkins can talk about the loop prevention.
florian: I'm convinced there's a giant use-case. Not too worried
about the first problem, about things not being reachable by
snapping.
florian: Am bothered by the second situation. In proximity it's fine,
but in mandatory I'm a little concerned...
florian: I've not yet convinced myself you can apply the :hover
workaround while maintaining the invariant of mandatory
snapping.
florian: That is, that while restyling you must resnap.
florian: You can probably limit it to once per frame, but you'd have
jiggling at rest, or you'd violate the mandatory requirement
and not be snapped at some times.
florian: So my question is if we *need* to solve the problem this
way? Would it be simpler to have snapping events that fire
when snapping to something?
florian: You'd still have loops if your JS did silly things, but
that's much wider.
<fantasai> +1 to JS events
<argyle> https://github.com/argyleink/ScrollSnapExplainers
argyle: Some JS events talked about in the explainer; those are part
of the proposal. snapChanged, snapChanging events, and
snapTo() function
argyle: So yeah, JS definitely important.
<fantasai> That issue's been open for awhile and needs help
https://github.com/w3c/csswg-drafts/issues/156
argyle: "changing" triggered when you've passed a threshold to start
switching to a new snap target
florian: My question is if it's *sufficient* to have events, rather
than just the pseudo?
argyle: There's a lot of cases where the CSS visual feedback is just
as important to JS knowing the snapped items.
argyle: I've got an example that adds a huge gap for one frame to
detect the snappee... the timing isn't right. We're trying to
give CSS visibility into the inner state.
argyle: I don't think we could use just a JS solution. But I do think
there's a competitive proposal in Style Queries.
argyle: So style queries might be able to pacify this use-case.
<TabAtkins> (I don't think they could; snapping isn't exposed in CSS
state except via side-channels of properties being
applied.)
flackr: I think we have similar problems with :hover, and :hover
state doesn't update until you move your cursor, we could do
a similar thing for :snapped, so even if snap changes we
wouldn't update the :snapped until user input occurs
flackr: We think in most cases devs wouldn't create these cycles,
because they usually don't with :hover
flackr: We'll have to make sure we have the same snapped element,
that does get tricky.
flackr: I think there are some cases that - say you have snapping in
both directions, you probably want the element snapped in
both directions to get the pseudo rather than first in dom
order, there's some tricky cases we'll need to make sure of
smfr: Your primary reasons to want sounded like something appropriate
for script - knowing what element was selected.
smfr: Wonder if you considered exposing on the scroller itself a list
of snapped elements.
smfr: Like .scrollLeft, etc, could have .snappedElements
smfr: Would change on scroll events
argyle: Like that idea, kinda goes with the scrollTo() options for
snapping
argyle: JS should be able to get the list of snappable children.
Sounds like a good idea
florian: There is indeed a similar to :hover when we talk about
proximity.
florian: But there is not in proximity a strong expectation you're
always snapped to something. If we break a loop, that's
fine.
florian: With mandatory you're required to always be snapped to
something. Always - authors can depend on this.
florian: There's never an unsnapped state.
florian: Not just scrolling can trigger this, restyling or animation
can change the position of the snapped element.
florian: If we have a clean way to make this continue being true,
great
florian: But I don't see a sufficient explanation in the explainer to
be clear on this.
florian: If it's impossible, oh well, we'll figure it out. Worry is
that it's possible, just very hard to do and maybe
non-interoperable so the invariant is broken in different
ways
<argyle> looks like as part of the event data on the js events
snapChanged and snapChanging, I've added snappedList and
snappedTargetsList which provide arrays of snap children on
axes
https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-snapChanged#:~:text=SnapEvent.snappedList
I do still think there's room for a generic api into this
tho!
flackr: I think the first proposal I presented does let you maintain
mandatory snapping
flackr: Your snapped state changes the style, which might cause you
to snap to another target, but your :snapped won't reflect
that until the next frame
TabAtkins: Underneath the covers, mandatory snapping invariant is
maintained, but not seen on every frame
<fantasai> https://github.com/w3c/csswg-drafts/issues/156
fantasai: Wanted to point people to discussion about event model,
been open for a long time
fantasai: I think this pseudo-class would be great, and event model
should be available at the same time or before the pseudo.
astearns: Agree, not against the pseudo, but think the events are the
more important thing
astearns: Could even wait on the pseudo until we notice the events
are often being used to add a class
<argyle> event `snapChanging`
https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-snapChanging
<argyle> event `snapChanged`
https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-snapChanged
fantasai: I'd also like to see the situation with mandatory snapping
and overlarge elements fixed first; it makes content
inaccessible if done wrong.
astearns: Any other comments? Concerns?
astearns: So it sounds like you have a lot of feedback.
argyle: The events should be well-defined, but I haven't taken up WG
time yet. Are they appropriate here?
fantasai: Yes, they'll be specced in this group.
fantasai: Probably in Scroll Snap 2.
TabAtkins: Sounded like people interested in adding to Scroll Snap 2,
should we resolve to start that spec with this in it?
astearns: Any objections?
fantasai: We should resolve to start an ED and include both :snapped
and the events
florian: If there's a different event model drafted in an issue,
should probably decide
fantasai: Can put both in for now and figure it out
astearns: So proposal is to have Scroll Snap 2 ED with pseudo-class
and event models, with Adam as editor?
florian: Think we should have both so it doesn't get frozen in
without discussion
argyle: I'll be checking soon how the two proposals compare
astearns: Objections? Anyone need more time?
RESOLVED: Start Scroll Snap 2 ED, with :snapped and snapping event
model, with Adam Argyle as additional editor
CSS Tables
==========
Collapsed table first row width quirk
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6230
fremy: While reimplementing tables in chrome, the dev found a lot of
bugs that weren't bugs per spec, but were unexpected by
authors
fremy: We realized the new version of the spec was causing the issues
fremy: But behavior that is currently implemented was mentioned in an
old version of the spec
fremy: So chrome dev decided to implement the old behavior, since we
didn't have resolution for the spec change, but they'd like to
change to the new behavior because the old didn't make much
sense
fremy: They feared there would be some breakage with new behavior, so
they added a UseCounter and studied websites
fremy: Found that on all websites, the changes to layout would be
very small, if any, and often slightly better. Found one case
where it was slightly worse, but in no case was it worse than
about 3px.
<bradk> 3px narrower or 3px wider?
fremy: So they want to update their impl to the new spec, if the WG
approves it
<iank> https://www.w3.org/TR/CSS2/tables.html#:~:text=17.6.2-,The%20collapsing%20border%20model,-In%20the%20collapsing
<astearns> https://www.w3.org/TR/CSS2/tables.html#collapsing-borders
is a more interoperable version of iank's URL
fremy: So that's context. Here's the behavior.
fremy: When you have a table in collapsed border mode
fremy: Two cells next to each other, the border needs to be
"harmonized" - pick one of the two borders and draw.
fremy: Must also harmonize border between cells and the table itself.
fremy: In the new spec you harmonize all the cells on the table edge,
take the biggest one. Do that for each edge.
fremy: The older spec for some reason only harmonized the first cell
of the first row.
fremy: If you have a table you don't draw borders around the header
row, but you use borders for the rest,
fremy: According to the old spec, the borders will then be drawn
outside the table
fremy: so it often just causes an overflow of like 1px, not
noticeable
fremy: But scrollbars can pop
fremy: And devs can't figure out why it's happening
<bradk> That answers my question
fremy: Bug is marked as Doesn't Reproduce in Firefox, technically
true, because they do something differently but still wrong,
it's based on rounding.
fremy: So proposal is to accept the new spec text: when you decide
the border of a table, you look at *all* the cells against
each border edge, not just the first
fremy: Should be more in line with dev expectations, but it's
currently a breaking change so we wanted a resolution.
iank: Ironically this is one of the better specified areas in 2.1
regarding tables, which is why everyone has the same (bad)
behavior.
fantasai: I worked on this issue in 2.1. I was really unhappy with
the old resolution.
fantasai: Happy to move away from that.
fantasai: There was a proposal to have the borders not belonging to
the table overflow; another was to count them as part of
the border with. I think there was a third to allow it to
overlap with the margin, but take up space if there wasn't
enough margin.
fantasai: Say you have a table with narrow borders, and you used a
thick border to highlight an interesting cell.
fantasai: If you want the table to stay centered when the highlighted
cell happens to be on the edge, we can't include the
difference in the border width, it'll shift the table
slightly
fantasai: But that is a more complicated behavior, but I want to put
it out for consideration.
fantasai: That effect is why, I suspect, why we had not taken the max
border width, so those borders could overlap into the
margin.
iank: I don't believe we've found anyone using it that way. Might
exist, but broadly the usage fell into a few buckets.
iank: Primary is calendar widgets - craigslist was the big one. Had
some dead code to add a transparent border to fix the behavior.
astearns: So the current spec describes what you prefer?
iank: I think the max-border behavior is defined in Tables 3.
iank: caveat-ed on us not breaking too much
iank: Use counter is high-ish but layout changes are very minor.
fremy: Current Tables spec does have symmetrical behavior
astearns: fremy, do you have opinions on the behavior fantasai
described?
fremy: I see it's useful behavior
fremy: But think you should probably be using outline to add this
kind of call-out border
fremy: So I think the simple behavior is fine. Wouldn't be mad either
way.
fantasai: Think it's probably fine.
<fantasai> The thing I *wish* we could fix in table borders model is
to invert the priority so that table wins over rowgroup
over row over cell.
<fantasai> The current version is just so impossible to deal with if
you want different colored but same-thickness borders for
rows vs rowgroups, etc.
astearns: So proposed resolution is no change to the Tables spec,
just confirming that the current spec is intended.
iank: Think the spec fixes some unintuitive behavior for webdevs.
Will report if there's problems.
RESOLVED: Accept current Tables 3 spec text regarding calculation of
shared borders in collapsed-border mode between table and
cells.
CSS Text
========
The web de-facto requires NULL U+0000 to not be visible
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/6983
florian: It's simple. Currently specs require every control character
to be made visible. It turns out it's not web-compatible to
make NULL visible. He requests we add this to the list of
characters that can be invisible.
florian: Chrome and Firefox currently do that anyway.
<PeterC> What's the spec text that this proposal would impact?
florian: So to the extent that's true, I'd agree.
* fantasai thinks it needs to also clarify that this character would
therefore be invisible, but that can be a follow-up edit
jfkthame: I'd like to see content that was affected; there doesn't
appear to be examples in the webkit bug
smfr: Looks like it affected iCloud Notes
smfr: Not sure why a null character got in there
jfkthame: It's not something we've discussed in Firefox, but I'd
personally entertain making it visible in FF.
jfkthame: Wonder if apply can't just fix iCloud if there's a problem
there
jfkthame: stray control characters in content are generally a bad
thing; even worse if people can't tell they're there
astearns: That's why we had the resolution to make things visible
astearns: Has FF tried to make the other control characters visible?
jfkthame: My recollection is we do at least on pre-release channels;
unsure if we've turned it on in release. Think we've had
trouble getting other browsers to line up.
astearns: Anyone from Blink have comments?
iank: Will have to check with koji.
florian: I think there was a point in Blink where they were visible
if there was a visible glyph in the font for them, but as
that's generally not the case, they were still invisible.
Not sure if that got fixed.
astearns: I suggest we loop in koji or whoever else in Blink;
jfkthame please check the state of the visible-chars code
in Firefox; we'll see if there are any other compat
concerns besides iCloud notes.
astearns: And we'll come back to this on a later call.
CSS Contain
===========
Bikeshed the container property & at-rule names to avoid confusion
with other usage of contain/container
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6376
astearns: Sounds like you'd like to change this issue no-change?
miriam: Yes, I'd love that.
astearns: This feature has gone thru lots of people. Haven't heard
complaints about the current names.
astearns: Anyone object to closing this no change?
<jensimmons> +1 to closing
<fantasai> +1
astearns: Or has anyone heard complaints?
RESOLVED: Close no change
container-name string vs ident
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6405
miriam: In the current spec we allow container names to be either a
string or an ident.
miriam: Advantage of string is you can use attr() to take from the
element and use it for a container name.
miriam: That could also be possible if browsers implement the
extensions to attr() that let you specify the type, attr(foo
ident)
miriam: Florian suggested just accepting ident would be easier
miriam: Don't have a strong opinion here. Like the flexibility, but
would like browsers to implement attr() stuff
fantasai: Currently attr() is not only restricted to strings, but
also just to the content property, so it'll require
extensions regardless.
fantasai: So I think we can keep it ident-only, and when we extend
attr() we can make sure it allows for idents as well.
<bkardell> kinda +1 to that
astearns: Not sure it follows we'd get attr() in this property and
with 'ident' behavior at same time, but I suppose we'd have
to either change attr() or change this property to allow
strings.
bkardell: +1 to fantasai about starting with ident.
bkardell: I think attr() is a need in lots of use-cases way beyond
this, feels bad to make an exception to solve one case as a
first option. It might be a thing we need to do, but it
feels bad to start assuming that.
TabAtkins: I think I'm the main defender of keeping string, but
fantasai makes a good point that attr() isn't allowed
anywhere at this point, so we'll fix it when we fix it,
and I'm fine with ident for now
astearns: So hearing strong arguments for restricting to ident.
Anyone wanna argue for strings?
astearns: Proposed resolution is to restrict to idents. We'll see if
we need to add strings later, or if attr() is sufficient.
RESOLVED: Restrict container-name to just idents
Received on Wednesday, 23 February 2022 23:56:05 UTC