- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Apr 2023 19:40:51 -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.
=========================================
Selectors
---------
- RESOLVED: Specify `@initial` as defined in this issue and open
another issue about the duplication problems with entry
and exit styles (Issue #8174: Add pseudo-class to
establish before-change style for css-transitions on new
elements)
- RESOLVED: Start with [the name] `@starting-style` [instead of
`initial`] (Issue #8174)
CSSOM View
----------
- RESOLVED: Close issue with no change (Issue #7795: checkVisibility
and filter:opacity(0))
CSS Images
----------
- RESOLVED: Close, no change (Issue #8259: Define optimizeSpeed as
nearest neighbor)
- RESOLVED: If there are no valid options, render as an invalid
image (Issue #8266: Define what happens when all
image-set options are invalid)
CSS Fonts
---------
- RESOLVED: Math function simplification for descriptors is as if
they were specified properties, and descriptors with
math functions use the specified-value serialization
rules (Issue #7964: Unclear serialization of calc
expressions in `@font-face` font-stretch/style/weight
descriptors)
CSS UI
------
- RESOLVED: Remove slider-horizontal, square-button, and push-button
from <compat-auto>; PaulG will open an issue about ARIA
roles and concerns about slider-vertical and push-button
(Issue #8506: Consider removing slider-horizontal from
<compat-auto>)
Scroll Anchoring
----------------
- There are questions about the relationship between overflow-anchor
and the proposed new `always` value on issue #7745 (Consider
adding an opt-in way of avoiding scroll anchoring suppressions).
Discussion will return on github to come up with a proposal.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Apr/0011.html
Present:
Tab Atkins
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Tantek Çelik
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Paul Grenier
Daniel Holbert
Brian Kardell
Jonathan Kew
Vladimir Levin
Rune Lillesveen
Peter Linss
Alison Maher
Eric Meyer
Cassondra Roberts
Jen Simmons
Alan Stearns
Miriam Suzanne
Sebastian Zartner
Regrets:
Rachel Andrew
Jennifer Strickland
Bramus Van Damme
Lea Verou
Chair: astearns
Scribe: emeyer
Administrative
==============
astearns: Agenda bashing?
fantasai: I would like to discuss F2F planning after the call with
whoever wants to stick around for a few more minutes
astearns: Should we consider the topic Lea raised or wait for her?
TabAtkins: We should probably wait for Lea
astearns: All right, we'll skip this week and get on next week's
agenda
Selectors
=========
Add pseudo-class to establish before-change style for css-transitions
on new elements
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8174
flackr: We were looking at using a pseudo-class to establish a
before-change style
flackr: We've proposed `@initial` (bikeshedding to come) that
defines a block used for before-change styles
flackr: This is implemented, working well, doesn't have weird edge
cases
flackr: Tab nicely summarized all the semantics
TabAtkins: It's `@initial` used whenever an element doesn't have a
before-change style
TabAtkins: In particular, it answers all the weird questions from
doing this as a pseudo
TabAtkins: @rules behave a lot better
TabAtkins: This also works a lot better with nesting
TabAtkins: I'm good with this
astearns: Comments or questions?
dbaron: Are there cases where you want to write both for @initial
and for something else?
TabAtkins: Possibly but only incidentally
TabAtkins: Sometimes you'll want to write so that normal style is
the same as initial styles
TabAtkins: But with a different class you'll want different stuff
TabAtkins: Doing it this way means you can't easily combine them,
you'd have to write the styles twice
dbaron: That's my concern; I had a colleague who had to repeat
styles to make the entry and exit transitions match
flackr: I think that might be the common case if you want something
to fade out when it goes away and fade in when coming back
TabAtkins: One sets opacity 0 and another doing the same, yeah
flackr: Haven't thought this deeply but we could consider… never mind
TabAtkins: Yeah, I couldn't make that make sense either
astearns: Is this a blocking concern, dbaron?
dbaron: I think it's something we should pay attention to
dbaron: The particular pattern I saw looked pretty ugly, but then
the other proposals here also had significant issues
dbaron: We could maybe change the rules around this to ameliorate in
some way
TabAtkins: If we do pursue the mixin idea, we could write styles
once in the mixin and call it from both spots
astearns: Any other discussion?
(silence)
astearns: Sounds like the proposal is to specify `@initial` as
defined in this issue and open another issue about the
duplication problems with entry and exit styles
<dbaron> sounds good to me
<masonf> +1
astearns: Objections?
RESOLVED: Specify `@initial` as defined in this issue and open
another issue about the duplication problems with entry
and exit styles
flackr: There‘s also a question on the issue about the actual name
astearns: While this isn't a keyframe, this is tied to animations
TabAtkins: Transitions, not animations
flackr: If you have an implicit `from` keyframe, it animates from
there, not the initial style
TabAtkins: `@initial-style` is fairly reasonable
TabAtkins: It's a little generic but not so generic it doesn't mean
anything
astearns: Would it be bad to make it longer for clarity?
<masonf> `@initial-state` maybe?
flackr: If we're exploring long names, `@before-change` is very
specific to what this is
flackr: That's what we call it in the spec
<masonf> `before-change` is the same length as `initial-state`
TabAtkins: Not opposed to that
TabAtkins: It's weirder to puzzle out what it does, but its
weirdness speaks to specialized nature
astearns: I like that
dbaron: One thing that bother me about before-change is that it
omits it's only for when the element appears
dbaron: Maybe replace `initial` with `start`
<fantasai> “before construction” ?
<masonf> `@starting-style`?
<fantasai> +1
TabAtkins: Maybe we should take bikeshedding back to issue; we need
more percolation
fantasai: I like mason's proposal
fantasai:`@starting-style`
<miriam> +1
astearns: Given we're coming up with multiple good options, we
should take it back to the issue
flackr: My concern is delaying too long over the name
fantasai: I think we should conclude on another call but we could
bikeshed in the issue
flackr: Sounds good
fantasai: I suggest we start with `@starting-style` for now
<flackr> +1
astearns: Are you asking for a resolution?
<TabAtkins> +1
fantasai: Yes, that we call it that until bikeshedding is concluded
<masonf> +1
astearns: Any objections?
RESOLVED: start with `@starting-style`
CSSOM View
==========
checkVisibility and filter:opacity(0)
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7795
vmpstr: We've added `check-visibility()` which considers a few
styles like opacity
vmpstr: If we're considering that, why aren't we considering
`filter` opacity 0?
vmpstr: It's hard to do this, and it was commented if we have other
filters that make things invisible
vmpstr: I propose to close with no change
TabAtkins: I concur
<fantasai> +1 to close no change
<dbaron> +1
astearns: Any concerns here?
RESOLVED: Close issue with no change
CSS Images
==========
Define optimizeSpeed as nearest neighbor
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8259
fantasai: We have SVG values that correspond to SVG keywords
fantasai: It was observed browsers might be able to use better
algorithms
fantasai: Should optimizeSpeed be the same as crispEdges?
TabAtkins: These legacy values are only around because I'm reusing
names from SVG
TabAtkins: As far as I know, no browser ever did anything with them
TabAtkins: Other renderers might, not sure
TabAtkins: For the web, it doesn't seem like it matters what we map
them to
TabAtkins: I do object to adding bespoke behavior for these values
TabAtkins: If we want to do something with nearest-neighbor, we
should do that
TabAtkins: If we do want to do that later, it would be fine to swap
mapping
TabAtkins: For now, what exact value we define isn't important
TabAtkins: I suggest we close, no change
fantasai: I think it's an okay state for now, but is risky in the
long run
fantasai: If there are people who would want nearest-neighbor, maybe
we should add a keyword specifically for that
TabAtkins: I'm happy to switch the alias over in that case, but
don't want to do anything special for it now
fantasai: Seem fine; do we need a `nearest-neighbor` keyword?
TabAtkins: That would be a different issue
astearns: Proposed resolution is close, no change for now; can
discuss separately if we need `nearest-neighbor` or any
other
astearns: At that point we could discuss whether to change the alias
for `optimizeSpeed`
astearns: Objections?
RESOLVED: Close, no change
Define what happens when all image-set options are invalid
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8266
emilio: If you specify an invalid type that the UA doesn't
understand, we don't have a good answer for what happens
emilio: Does the UA try to load and then discard?
emilio: Tab put in the spec we render an invalid image
emilio: The difference is that if the type function ends up invalid,
like say it's PNG in the CSS but then serve a JPEG, it's a
problem
emilio: I think what Tab put in the spec is fine
astearns: Proposed resolution is to accept what's been added to the
spec?
TabAtkins: More specifically, if there are no valid options, it
rendered as an invalid image
<fantasai> +1
astearns: Objections?
RESOLVED: If there are no valid options, render as an invalid image
CSS Fonts
=========
Unclear serialization of calc expressions in `@font-face`
font-stretch/style/weight descriptors
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7964
TabAtkins: Fundamental issue is that simplification rules for math
functions refer to resolution stages
TabAtkins: Those don't apply in descriptors
TabAtkins: So what are the rules for serialization, and do they
match?
TabAtkins: Apple wants serialization to be the same as CSS
properties, which makes sense
TabAtkins: Not sure if we're compat-constrained or not
dbaron: The one thought I have is that descriptors seem a lot like
specified values
TabAtkins: Agreed
emilio: Agreed
TabAtkins: I think it's reasonable to say we treat things the same
astearns: We could resolve on that and see if anyone complains
TabAtkins: proposed resolution: math function simplification for
descriptors as if they were specified properties, and
descriptors with math functions use the same
serialization rules as properties
RESOLVED: Math function simplification for descriptors is as if they
were specified properties, and descriptors with math
functions use the specified-value serialization rules
CSS UI
======
Consider removing slider-horizontal from <compat-auto>
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8506
emilio: Firefox never supported this
emilio: Recently, I found three keywords where there are problems
in WPT
emilio: Usage is pretty low
emilio: We also have no compat issues about this
masonf: We don't object to this
astearns: What are we resolving?
emilio: Drop slider-horizontal, square-button, and push-button
PaulG: slider-vertical has native semantics around orientation
PaulG: If there is usage, we should communicate that ARIA values
need to be used
emilio: Right now, the spec says it does nothing special
dbaron: I don't think there a history of appearance changing
accessibility roles, is there?
PaulG: In Chromium, [missed]
dbaron: I don't think the CSS `appearance` property affect
accessibility
PaulG: I'm looking at the demo in the issue, in Chromium, the
vertical slider renders with orientation: vertical that
nothing else set
dbaron: That's surprising to me
masonf: me too (but confirm it)
<bkardell> Is it bad? Seems good?
PaulG: Concern is if it's dropped, anyone depending on that
orientation needs to know they need to replace that with ARIA
astearns: Given that usage is very low, is this a big concern?
PaulG: This is in no way a reason to stop, but this is a concern APA
will probably voice
PaulG: I'm guessing where this is used, understanding of
accessibility is low
PaulG: I'll help smooth that over with APA, I'd just like numbers
masonf: We're speaking just about slider-horizontal, yes? Not
slider-vertical
masonf: Is it an accessibility problem for horizontal?
PaulG: No, only concerned with vertical and that semantic meanings
are conveyed in other ways
masonf: We should open an issue about vertical
masonf: I think we're okay horizontal, but need to discuss more
about vertical
<dbaron> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/accessibility/ax_slider.cc;l=47-83;drc=5a252fef36aced8857912a7eba43dad5590cb54d
astearns: So proposed resolution is to remove slider-horizontal,
square-button, and push-button
PaulG: I might need to check push-button
PaulG: Does ARIA pressed get added?
astearns: What if we resolve to do the removal, then Paul, can you
open an issue on slider-vertical and push-button on
possible ARIA concerns?
PaulG: Yes
RESOLVED: Remove slider-horizontal, square-button, and push-button
from <compat-auto>; PaulG will open an issue about ARIA
roles and concerns about slider-vertical and push-button
Scroll Anchoring
================
Consider adding an opt-in way of avoiding scroll anchoring suppressions
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7745
emilio: Scroll anchoring spec has a bunch of heuristics about when
to apply or stop applying scroll anchoring
emilio: We found some cases where pages rely on scroll anchoring to
happen, and depending on timing of style changes, page may
misbehave
emilio: When you fire scroll events
emilio: Seems to be no way for devs to say “I really really want
scroll anchoring to happen”
emilio: I think adding a way to opt into ignoring suppressions and
in this scrolling, we're going to do anchoring regardless of
other things
emilio: I think it's moderately trivial to implement, but is it a
good idea? Or reason it's a bad idea?
astearns: Any thoughts on adding a way to require scroll anchoring?
(silence)
astearns: Should we add an `always` value and see how it goes?
emilio: If there's no anchor you don't do anchoring, so maybe that
name doesn't quite make sense
flackr: What is `always` specified on?
emilio: overflow-anchor works on the scroll container, I believe
flackr: overflow-anchor I thought is applied to any element to
prevent any element within to be selected as an anchor
emilio: Right, I guess should always have an effect on non-scroll
containers
flackr: I was wondering if `always` would be a way of saying “this
is the element to which I want to anchor”
emilio: Then we'd need another way to specify that an anchor should
never lose the anchor even if there are suppressions
flackr: What do you anchor to?
emilio: Whatever you were anchoring to before
emilio: What the suppression triggers do is prevent going back
flackr: The suppression trigger prevent selecting an anchor within a
given subtree
flackr: You need to know which element should stay in the same
position after anchoring
emilio: I'm not proposing to change anchor selection
emilio: In my head, suppression triggers don't affect anchor
selection
flackr: Are we talking about overflow-anchor?
emilio: What I'm talking about it, the spec has heuristics that
don't affect anchor selection but do affect adjustments
emilio: overflow-anchor seemed an obvious property to add this
exception
flackr: I know anchor selection is a big problem and maybe
overflow-anchor: always means you must selector something
in here as the anchor
emilio: This seems like an orthogonal problem
emilio: I'm just trying to bypass the heuristics
SebastianZ: Quick note: overflow-anchor is targeting elements while
something is targeting the scroll container, or maybe it
should be another property in the end
astearns: Let's take this back to the issue and come up with a
proposed solution that can be agreed upon there
astearns: Maybe we can get this and the linked issue on a
near-future call
astearns: That's time; anyone who wants to stay to talk about a
summer FTF, please stay on
Received on Wednesday, 19 April 2023 23:41:30 UTC