- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 22 Aug 2024 18:59:13 -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.
=========================================
Media Queries
-------------
- On the call there was no clear sense of if the best way to handle
issue #10249 (Effect of <meta name=color-scheme> on the
(prefers-color-scheme) MQ) was to allow a meta to set
prefers-color-scheme or if it's better to have a style query.
Discussion will return to the issue.
CSS Cascade
-----------
- RESOLVED: We publish current draft, and we open an issue for the
multiple nested scopes (Issue #10370: Publish an updated
WD)
CSS UI
------
- It wasn't clear that setting inert was the right solution for issue
#10711 (Support setting offscreen content inert), though the
problem space was clear. Discussion will return to the issue to
further determine if inert is the right path forward given
concerns about accessibility.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Aug/0013.html
Present:
Rachel Andrew
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Oriol Brufau
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Matthieu Dubet
Elika Etemad
Robert Flack
Paul Grenier
Daniel Holbert
Brain Kardell
Jonathan Kew
Roman Komarov
David Leininger
Vladimir Levin
Alison Maher
Noam Rosenthal
Khushal Sagar
Alan Stearns
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Sebastian Zartner
Regrets:
Chris Lilley
Florian Rivoal
Lea Verou
Chair: astearns
Scribe: matthieud
Scribe's scribe: TabAtkins
Media Queries
=============
Effect of <meta name=color-scheme> on the (prefers-color-scheme) MQ
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10249
TabAtkins: Dark mode and spec is weird: when the meta makes the page
dark, it is not reflected in the value of the media query
TabAtkins: Proposition we allow the meta name color-scheme to define
the value of the prefers-color-scheme MQ
TabAtkins: Uniflow information from page to the CSS; it's similar to
how the viewport meta affect the size MQ on the page
emilio: It makes sense. If someone does the opposite (set the meta
from the value of the MQ?) no reason to do that though
TabAtkins: No reason to do that (set meta from MQ)
joshtumath: How this work with color-scheme property?
TabAtkins: It still has no effect of the result of the
prefer-color-scheme MQ
fantasai: Currently the color-scheme meta is just setting the
color-scheme property. But now it would have a new behavior
(affecting the MQ)
TabAtkins: It makes more sense than having MQ giving the result of
the OS
fantasai: But setting color-scheme property on the root doesn't
affect the MQ
TabAtkins: Nobody expects properties to affect MQ, but it's more
reasonable for the HTML (like meta) to affect the MQ
TabAtkins: If I set color-scheme, I get dark controls, but
prefers-color-scheme doesn't reflect, so that's confusing
fantasai: But if you set color-scheme property on the root, you also
get dark controls, and prefers-color-scheme doesn't reflect
there either
emilio: Do we have data on the usage of this?
TabAtkins: Anecdotal I got bit by this behavior already
joshtumath: As author, I'm often confused between using the meta tag
vs the css property
joshtumath: Are they equivalent? Now they would not be equivalent
anymore
joshtumath: And also weird when using the property on the root
TabAtkins: They are the same right now
emilio: Not really, the meta changes the value of "normal"
miriam: We've discussed similar stuff with the Preferences API
(changing the result of MQ)
miriam: As author, I'm sometimes interested to know what the user
(the OS) setting is even if I overwrite with the property
<fantasai> +1 miriam
miriam: I would like to be able to query the normal setting on the
page (so no overwrite of the MQ); but I'm also interested
into overwriting it
emilio: You can already modify the preferences (with iframe or svg?)
<fantasai> [prefers-color-scheme on embedded content takes the value
from the embedding element's color-scheme]
TabAtkins: Assuming you are on a page width has set the meta to dark.
What is the goal of knowing the original user value?
miriam: Not sure, interesting to know if my author default is
different from the user default. Like for example providing a
toggle if they don't match
TabAtkins: That would use javascript
miriam: Yes but it would be more robust with html
TabAtkins: But it doesn't work today. If meta is dark, and you use
the MQ to set style, you will have inconsistent result
ntim: meta tag values are the same as the property, but MQ only
supports a subset of them
TabAtkins: The proposal is that the prefers MQ takes into account the
meta tag; so it just match only the used value of the
color-scheme property (so no issue)
joshtumath: Maybe we need a new MQ
TabAtkins: If we introduce a new MQ which take into account the meta,
there would not be any use for the original one which only
reflect the OS value
TabAtkins: It could be a JS API if we really want to have the default
value without the meta
<miriam> curious if that's true...
kizu: +1 for this as a style query
TabAtkins: Style query is nice to do non color styling, but it is
useful for the MQ to differ from the style query?
TabAtkins: Do we want both mechanisms?
astearns: In your solution the MQ and the style query would differ
when you set value on the root
TabAtkins: Yes
<TabAtkins> <meta name=color-scheme content=dark>, then
`color-scheme: light dark`
kizu: If html meta dark with only 1 value, but author css
color-scheme root both light and dark. What do we do? Author
might want to override this
TabAtkins: Preference for this should affect how the color-scheme
property resolves
fantasai: The style query makes more sense
fantasai: We want to used value and not the computed value here
fantasai: If you change the color-scheme in the middle of the page,
but other part you want the user preference "normal", Tab's
solution doesn't work
fantasai: Only works with a style query
fantasai: It would avoid the confusion between color-scheme meta and
color-scheme MQ
fantasai: And you can do a container query on the root to get the
value of the meta tag
TabAtkins: Elika solution is nice, let's go back to the issue
<emilio> +1 to TabAtkins, not sure they need to be exclusive
TabAtkins: My solution is still valid
<fantasai> It would need to be a color-scheme() function
<fantasai> since the computed value wouldn't work for this purpose
<fantasai> we need the used color-scheme
CSS Cascade
===========
Publish an updated WD
---------------------
github: https://github.com/w3c/csswg-drafts/issues/10370
miriam: We want to publish an updated for cascade-6 with @scope
miriam: We are not tracking multiple scope proximity, we only look at
the proximity of the single closest one
miriam: Do we need to resolved that first or we can publish and
keeping this opened?
matthieud: I think this is about taking into account nested scope,
and instead of just looking at the closest one to do
disambiguation...
matthieud: If the closest is equal in scope, you'd go up one level,
etc
miriam: Right. Though there's also an issue about if there's a
different number of scopes.
matthieud: Yeah, I see no reason why it should only be the first one.
matthieud: Don't have giant use-cases for the nested ones, but still
seems weird we completely forget about the outer scopes.
PROPOSED RESOLUTION: we publish current draft, and we open an issue
for the multiple nested scopes
<fantasai> sgtm
RESOLVED: We publish current draft, and we open an issue for the
multiple nested scopes
<bramus> 🎉
CSS UI
======
Support setting offscreen content inert
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10711
flackr: Many website designs when creating paginated stuff or when
the site provide an alternative to a long scrolling document,
the recommended practice is that content outside of the
viewport is inert
flackr: You don't have the content in your accessibility tree
flackr: It can be done with display:none but not very good
flackr: You can do aria:hidden as html attribute so need a script as
you progress animation
flackr: New simple way to say "content out of view is inert"
flackr: We could either assign this on the scroller (overflow) or on
the element itself?
astearns: The default value for overflow-interactivity is auto in
option 2
emilio: Is overflow the only place we want to support this use-case?
emilio: Author might want this for stuff in the screen
flackr: Similar usecases to animate to/from content not the
accessibility. Option 1 would allow that because its not
tight to overflow
flackr: Option 1 has added complexity but you can't select offscreen
content with a simple selector today, so for the scrolling
usecase you would have to animate the interactivity property
with a view timeline or something
kizu: Option 2 is nice. Option 1 is powerful but limited
kizu: Always risk to break accessibility with all options: if we
apply this to an element but cant reach it without scrolling,
accessibility will be broken
kizu: Because it's inert you would only be able to scroll to it,
can't reach it in any other way
kizu: Option 2 is safer because tied to scrollable container
PaulG: Like kizu, in a listbox with item overflowed. Does the engine
will give the correct number of items to the accessibility
tree when some of them are inert?
flackr: Nice question. Maybe inert is not the property we want to
use then
PaulG: Maybe inert is fine but not for this scenario. We need to
clarify the exact use cases
flackr: We don't want to use this when user want to interact with
this content
flackr: It doesn't make sense to use this for overflowing tabs in a
tab list for example
flackr: so maybe inert is not what we want
<TabAtkins> I'm feeling like this is indeed a "well don't do that"
situation
ntim: Controlling inert from CSS was originally objected against
ntim: Inert is not only about presentation but also about content
ntim: because it applies aria-hidden
flackr: Display already does stuff on aria tree even if it is a css
property
emilio: For Firefox tab bar, we want tab hidden but still remain in
the accessibility tree. So we don't really want inert
does this only apply to scroller? or also to clip-path or clip?
kizu: For clip it should not work
kizu: For hidden not sure
flackr: For hidden many time people make it scrollable with other
mechanism
emilio: We are not sure if we want actual inertness here
flackr: We can take it back to the issue
astearns: Please comment on the issue
Received on Thursday, 22 August 2024 22:59:45 UTC