- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Jul 2024 19:27:03 -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
-------------
- RESOLVED: Put this proposal (
https://github.com/w3c/csswg-drafts/issues/6517#issuecomment-2032688406
)
into css-mediaqueries-5 (Issue #6517: Script control of
(prefers-*) queries)
- RESOLVED: Add lwarlow as an editor for mediaqueries-5
Anchor Position
---------------
- RESOLVED: Change inset-area back to position-area (Issue #10209:
Bikeshed name of `inset-area`)
CSS Grid/Masonry
----------------
- RESOLVED: Drop the next value of masonry auto flow (Issue #10232:
Drop next value of masonry-auto-flow)
- RESOLVED: Drop masonry-auto-flow (Issue #10231: merge
masonry-auto-flow into grid-auto-flow?)
CSS Lists
---------
- RESOLVED: Cursor property applies to ::marker pseudo (Issue #6203:
The `cursor` property should apply to `::marker`s)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jul/0002.html
Present:
Rachel Andrew
Kevin Babbitt
David Baron
Andreu Botella
Stephen Chenney
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Brian Kardell
Brad Kemper
Jonathan Kew
Roman Komarov
David Leininger
Vladimir Levin
Chris Lilley
Alison Maher
Romain Menke
Khushal Sagar
Jen Simmons
Alan Stearns
Brandon Stewart
Miriam Suzanne
Lea Verou
Luke Warlow
Jason Williams
Regrets:
Oriol Brufau
Eric Meyer
Bramus Van Damme
Chairs: astearns & Rossen
Scribe: flackr
astearns: Any changes to the agenda?
ChrisL: item 8 was closed and can be removed
Media Queries
=============
Script control of (prefers-*) queries
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6517#issuecomment-2032688406
TabAtkins: We've discussed this before. For a quick recap, there are
many cases for e.g. light mode or dark mode on an
individual site that can be distinct from OS preference
TabAtkins: Right now, you have to manually store some bit in a
cookie, doing styling based on that info with JS, possibly
flashing the wrong style of content before that JS runs,
in general it's relatively awkward to have something
possibly depend on a media query or script info
<JaseW> Example: https://expressjs.com/ does this (Flash of unstyled
content/theme while it figures out what you want)
TabAtkins: This proposal is to allow a site to override what the OS /
browser says the value of a MQ is, and a persistence
mechanism to keep it until the site data is cleared or
removed
TabAtkins: The author can always ignore the MQ and do what they want,
it just allows them to rely on the MQ and optionally
override it without separate code paths
TabAtkins: This seems to have overall support. Would we like to adopt
this into a csswg deliverable?
TabAtkins: Possibly css, possibly webapps. Given the tight connection
to MQ likely css.
TabAtkins: It would likely go in css-media-queries-5
florian: Based on how you described it, I'm supportive. In the issue
some comments seem contradictory. E.g. "this API is to
override the underlying preference affecting all the things"
florian: Does this affect the underlying thing as well as the MQ's?
This seems confusing
lwarlow: As spec'd, the preference applies to the MQ, is used as calc
for used color-scheme, used to override the user preference
MQ client hints, that's the 3 main things. It is largely the
MQ.
lwarlow: The used color-scheme seems reasonable as part of that
florian: Is this different from what TabAtkins said?
lwarlow: Yes, slightly different. It is only affecting the MQ and not
changing anything you can't ignore already
TabAtkins: Right, keeps things consistent across these APIs
khush: 2 questions. Are you thinking of exposing this for all MQ's,
or an allowlist that is expected to be overridden? E.g. maybe
prefers-reduce-motion doesn't make sense?
khush: Are there cases for closed shadow roots or UA shadow dom where
authors can now override things they couldn't before?
lwarlow: The list of MQ's supported are the 5 pref ones,
color-scheme, contrast, reduce-motion, reduce-transparency
and reduce-data
lwarlow: I've done some research to sites in the wild. Reduce motion
comes up often, so for the same reasons as color-scheme I
think this makes sense
lwarlow: To the second point, yes currently there could be user-agent
styles using MQ's that would be affected. Off the top of my
head I'm not aware of any though.
lwarlow: I think this fits into the premise of the API but it is a
slightly new capability
TabAtkins: I think it's entirely a good thing that this works, to
keep things consistent to having the MQ pref set in the
browser
TabAtkins: Right now, script controlled functionality doesn't do this
resulting in inconsistent behavior
TabAtkins: This makes everything behave as expected
khush: Sounds reasonable
JaseW: A question for implementers, how would you feel if a site
requests an override for color-scheme or reduce-motion? Would
you expect this to trigger a permission prompt? We've already
mentioned web devs can ignore, so how do we feel about this?
JaseW: Do you expect some UI alongside this? e.g. allowing users to
change the value through the browser
TabAtkins: This has been discussed. Because it's no additional
functionality, it doesn't need a permission prompt
TabAtkins: For resetting something, this should be tied to site data.
So you can clear site data and clear these prefs
TabAtkins: UA's could offer more granular controls but it would at
least be recommended to reset with site data
ntim: I'm concerned that this is persistent. Let's say the site
changes owner, the override stays on that domain. This seems
wrong. Whereas persisted by cookies the new site wouldn't use
the cookie
ntim: The user doesn't have an obvious way to reset this
TabAtkins: Worst case a user can reset site data, but otherwise
hopefully the web dev would clear this
lwarlow: You can already design your site to ignore the user
preference
lwarlow: The idea is you'd probably have a way in the UA to clear
these independent of clearing cookies but on the spec side
wouldn't be required to have
lwarlow: The fact that it's persistent is a powerful part of this
API, to avoid a flash of incorrectly styled content, JS at
every load to restore, etc
lwarlow: I see the issue, but given good browser UI and existing
problem, it doesn't seem too concerning
JaseW: Is there not already a concept of per-site settings based on
the origin rather than cookies?
JaseW: Seems like this could be part of that
ntim: Does that mean the API will need to be async? If the browser
can provide UI to disable / override it
lwarlow: The API is designed so the request override is an async
function
lwarlow: I don't think requesting the override generally requires
intervention but it could be
astearns: Are there many open issues on the repo to be addressed?
lwarlow: There's one or two, how this interfaces with third party
iframes. I think the answers already exist in various specs
and just need to relay that information
lwarlow: Mainly ensuring this doesn't introduce a new communication
channel
lwarlow: Also does it make sense to have all of these supported?
based on research it seems the answer is yes
flackr: I think it would be good if the UA was allowed to set as well
as clear them
flackr: UA could decide it wants a darkmode per-site toggle, could be
useful to do
lwarlow: I agree, this is the intent that it could be set by the UA
khush: Was going to say the same thing as flackr, it seems better if
this were browser UI, then we don't have to force each website
to implement a pattern of adding a button
khush: If this were to exist would we still want this?
lwarlow: If that existed, it'd be great, but I still think at least
color-scheme and possibly others you still have a use case
where you want to sync values across accounts (e.g. log in
on a diff browser), and even aside from this there are
enough sites in the wild that have existing dark mode
toggles that would be nice to integrate
lwarlow: With just the browser UI, some sites would probably still
have their own setting
flackr: I agree
miriam: I also support this view. It would be amazing to have browser
UI for this, but sites will still want it as part of their
interface
keithamus: Light and dark are fine, but for artistic styles there's
no way to enumerate these to the UA other than inferred
from the stylesheets
keithamus: There's an idea to add a custom-ident, would the API allow
overriding this?
lwarlow: In its current form no, but it could be extended to set this
lwarlow: You'd basically be able to build github's preferences, high
contrast, dark mode, etc
<khush> that's a good point.
ntim: I'd have a concern about custom idents if the site doesn't have
a way to enumerate them
ntim: If we were to show browser UI, we should be able to enumerate
what's supported vs what's not
ntim: I think this should be limited to a certain set of MQs. I don't
think the site should be able to override forced colors for
example, or other AX related queries
TabAtkins: Right, only the prefers ones rather than ones that are
ignorable / preference
ydaniv: Speaking for a design tool, it'd be good to have the API so
that you could check how your site looks with different
schemes / MQ values
astearns: I'm hearing concerns for particular bits of this API, which
MQs it should apply to what values it supports, this can be
hashed out in our draft but it sounds like we have rough
consensus to add it to MQ 5
astearns: Any objections to putting this in MQ5?
RESOLVED: Put this proposal into css-mediaqueries-5
TabAtkins: Can we add lwarlow as an editor?
lwarlow: I'm happy to
RESOLVED: Add lwarlow as an editor for mediaqueries-5
astearns: Can you migrate issues over as needed?
lwarlow: Yes, will do
astearns: Please open issues about custom idents, what MQs this
applies to and the issues raised here
astearns: Anything more on this?
Anchor Position
===============
Bikeshed name of `inset-area`
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/10209
ntim: Right now anchor positioning has a property called inset-area.
It's confusing as it suggests by its prefix that you can't use
this and inset at the same time but they're independent
properties that can work together
ntim: In some ways this is a property to pick the containing block,
these usually have a position prefix. So I'd suggest
position-area
<kizu> +1 to position-area, not a strong one, but convinced by the
arguments in the issue
fantasai: When we first proposed it, it was called position-area. It
was renamed to inset-area because it didn't use to contain
the containing block, just the interpretation of auto on
the properties so it was more closely tied to other inset
properties
fantasai: Since then we've switched it back to it changing the
containing block, so I agree it would make sense to
rename back
TabAtkins: I'm neutral on the name either way. I do still like
inset-area as it's named because it occupies the same
mental area as insets. Most of the time you won't use both
because inset-area does most of what you need so having
them in the same syntactic space seems nice
TabAtkins: More broadly, because it's a value neutral rename, it's
late enough in the spec lifecycle I'm happy to pushback on
renames that don't have a clear value. I was happy to
rename fallbacks but there are impls / tutorials that use
the existing name. If there's no problem with the existing
name would prefer not to change it
astearns: Prefer but not object?
TabAtkins: Lightly objecting, not formally
TabAtkins: We've changed a lot of things where there was a good
argument for it
astearns: In terms of the timing, this was put on in May. The
lateness was in part because we didn't get to it in a
timely fashion
TabAtkins: This was originally filed a few days after I2S after years
of discussing the spec
<fantasai> Note, it wasn't years after discussing the spec -- the
proposal for position-area (and inset-area) wasn't
presented until about a year ago.
kizu: I am more inclined for position-area. Thinking as an author it
works as an inset, but many authors don't use insets for
positioning things so there's no disconnection. Thinking about
positioning something position-area is a good name and removes
the connection to insets
kizu: I was convinced by the arguments for position-area in the issue
astearns: With chair hat off, I also am convinced to change back to
position-area
jensimmons: I think what matters most is developer ergonomics when
someone is writing things so that they don't have to look
things up
jensimmons: inset-area feels like an oddball compared to the other
position properties
<TabAtkins> position-container + position-area both also seem to do
very similar things (and they kinda do); the slight
difference that the changed prefix brings might be a good
thing.
TabAtkins: I was saying the association with inset seems good to me,
but seems fairly neutral either way
TabAtkins: I'm merely pushing back on the grounds that it has been
out for a while
astearns: It sounds like others believe the reasons are strong enough
to make the change
TabAtkins: I will say there are many here who feel against making the
change
ntim: The chrome team did say they would be okay making breaking
changes even after shipping. This rename has developer
experience benefit as jensimmons said and better describes what
the property does, also implying inset can be used alongside it
ntim: so I think this is a general improvement for dev experience
TabAtkins: Point of order, we promised we would be happy to make
reasonable changes even if they are breaking, not any and
all changes. We will still push back on changes that don't
have a strong argument for them
<dbaron> Here's a list of breaking changes that are implemented or in
progress in Chrome:
https://groups.google.com/a/chromium.org/g/blink-dev/c/jGTYNuidPRs/m/4oY6JFVyBAAJ
fantasai: 2 more spec things about the rename. 1. we should consider
this in conjunction with position-try fallbacks. This takes
inset-area directly into it. Sharing a common prefix helps
associate them.
<fantasai> position-area: top left; position-try: bottom left,
bottom, etc.
fantasai: If that's inset area it's harder to associate that those
represent the same idea
fantasai: 2nd, if we do figure out shorthanding, having it prefixed
with position sets us up better for this relationship
<ntim> +1 to what fantasai said :)
miriam: I'm unconvinced by some of the arguments, e.g. having inset
as a prefix doesn't imply it can't be used with inset. But I
find fantasai's argument convincing. It sounds worthwhile
for this
jensimmons: For process, is it too late to change the name if the
name change isn't a certain amount of benefit? This was
originally proposed as position-area. The name was
changed when it was written into the spec but we didn't
have a CSSWG resolution for the name change. Apple has
repeatedly felt like we were being obnoxious about
bikeshedding names to wait for things to mature, now
we're circling back to say we still believe this is better
<ChrisL> fair point about no resolution on the earlier name change
astearns: Any other comments?
ntim: fantasai also reminded me why inset-area was chosen, because it
was defined differently before, to change the computed value of
insets. Now it doesn't so it's complementary to insets, not
replacing them
<TabAtkins> I don't understand this argument - we have complementary
properties both with and without common prefixes all the
time.
astearns: I think I'm hearing we should resolve on changing it back
to position-area
<ChrisL> +1
astearns: TabAtkins okay with resolving on this?
TabAtkins: okay
RESOLVED: Change inset-area back to position-area
CSS Grid/Masonry
================
Drop next value of masonry-auto-flow
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10232
fantasai: We have this value for masonry auto flow, instead of
finding the shortest column it keeps wrapping around
regardless of the heights of the columns. If you have
different height columns they can be placed very far apart
because it doesn't consider their size
fantasai: It seems weird when you have slight variations in column
height to jump columns (e.g. jumping to shorter column) so
we had this idea for a threshold property to say if you're
within some slack of other columns assume they're all the
same
fantasai: Since we have that functionality which needs more precise
spec, this solves the same problems that next was trying to
solve but better
fantasai: e.g. with a 100vh gap you probably don't want to do this
next column behavior
fantasai: Proposal is to drop the next value from masonry auto flow
fantasai: You can easily configure with a threshold
<TabAtkins> +1 to all that
<TabAtkins> (I do think an "infinite" keyword would be *useful* in
masonry-threshold, but it's fine either way)
<TabAtkins> `masonry-threshold: calc(infinity)` isn't terrible to
write anyway
astearns: IIRC, you can do it with masonry-threshold but you have to
do it with a hacky calc?
fantasai: We could add a keyword that's infinity, but I can't think
of a good use case for this. Would like to see a use case
for why you'd need this
astearns: Any other comments?
<fantasai> I can't think of a reason why you'd need anything greater
than 100vmax
<TabAtkins> I do have a use-case for actual infinity, but we don't
need to talk about it here; it's a side-discussion from
this issue.
astearns: oriol mentioned he's opposed to dropping it without a
keyword but it seems like it could be a separate issue
miriam: That could be a separate issue, oriol did add an example to
the thread. The use case is if you want stability, e.g. to
not have disclosure widget move columns
miriam: Is that an issue if you can't choose some stable value?
fantasai: We need to solve the stability issue somehow. You wouldn't
want giant gaps in masonry regardless. You wouldn't want
weird column heights / stuff jumping around. I think
stability is a different issue
miriam: makes sense
Proposed resolution: Drop the next value of masonry auto flow
RESOLVED: Drop the next value of masonry auto flow
merge masonry-auto-flow into grid-auto-flow?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10231
fantasai: Now that we've dropped the definite value and the next
value, there's nothing for masonry-auto-flow to do, so
propose dropping property altogether
astearns: Any concerns about dropping masonry-auto-flow?
astearns: Objections?
RESOLVED: Drop masonry-auto-flow
CSS Lists
=========
The `cursor` property should apply to `::marker`s
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6203
fantasai: Proposal is to allow cursor to ::marker. Technically this
exposes the geometry of ::marker which we avoided in the
past because we haven't defined the layout of it
fantasai: Changing the cursor a few pixels either way seems unlikely
to break anything significant so it seems like it should be
safe to apply even though we don't know where it is
astearns: comments or questions?
<TabAtkins> +1
<TabAtkins> (we should solve this issue more generally, but this is
good as a particular change)
<kizu> +1
<ChrisL> +1 to allowing cursor in ::marker but note the list of other
properties to add at the end of that issue
<florian> +1 to allowing it
TabAtkins: We should figure out how to make marker have the same
power as before and after in the future
TabAtkins: We'd like to make it a real element that's just not in
the tree
ChrisL: I think it's good to add it, the last comment in the issue
has a bunch of other properties which should probably be
added so let's not close it off without migrating it
astearns: Links to other issues though
Proposed resolution: cursor property applies to ::marker pseudo
RESOLVED: Cursor property applies to ::marker pseudo
Received on Wednesday, 10 July 2024 23:27:36 UTC