- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 5 Mar 2025 19:06:21 -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.
=========================================
CSS Fonts & Fingerprinting
--------------------------
- A few folks expressed interest in helping to address issue #11775
(Index of local font issues: fingerprinting, I18n, privacy) but
had limited capacity. They will reach out to team members to see
if they can find folks with capacity to assist. Additionally,
ChrisL and astearns will work on addressing suggestions sent
privately and furthering discussion on the issue.
CSS Values
----------
- RESOLVED: Rename string keyword to raw-string (Issue #11645:
Distinction between `attr(foo type(<string>))` and `attr(
foo string)` is too subtle)
CSS Overflow
------------
- RESOLVED: Default styling for scroll markers will match default
styling for links. Default styling for scroll buttons
will match default styling for buttons (and appearance
will apply accordingly). (Issue #10935: Default UA styles
for scroll markers and scroll buttons)
CSS Display
-----------
- RESOLVED: Add a source-order value to reading-flow (Issue #11208:
reading-flow and mix of auto-flow and explicit items)
- RESOLVED: reading-flow: source-order works on block containers.
reading-order applies to block-level boxes, and not to
inline-level boxes (Issue #11208)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Mar/0001.html
Present:
Kevin Babbitt
Stephen Chenney
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Chris Harrelson
Daniel Holbert
Brian Kardell
Jonathan Kew
Ian Kilpatrick
Roman Komarov
Vladimir Levin
Chris Lilley
Alison Maher
Tess O'Connor
Noam Rosenthal
Jen Simmons
Gaurav Singh Faujdar
Alan Stearns
Miriam Suzanne
Joshua Tumath
Bramus Van Damme
Samuel Weinig
Sebastian Zartner
Regrets:
Oriol Brufau
Lea Verou
Scribe: fantasai
Scribe's scribe: kbabbitt
Administrivia
=============
astearns: Looks like we can skip item 2
bramus: US is switching to summer time, but Europe is lagging.
bramus: so next three weeks Europe will have CSSWG meetings at a
different time
bramus: since out of sync with US
astearns: Good luck everyone with figuring out international meetings
astearns: Another change is Pete Snyder was supposed to make this
meeting, but couldn't due to a conflict.
fantasai: ntim published first draft of css-forms-1, looking for
feedback
<fantasai> https://lists.w3.org/Archives/Public/www-style/2025Mar/0004.html
astearns: We have an openui meeting tomorrow
astearns: should put it on the agenda for review
fantasai: Hoping to publish FPWD soon, since the draft is fairly
complete now (even though lots of issues)
<smfr> https://drafts.csswg.org/css-forms/
Fonts & Fingerprinting
======================
Index of local font issues: fingerprinting, I18n, privacy
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11775
ChrisL: I created this meta-issue ... to organize the discussion
ChrisL: Sometimes we solve certain aspects and close an issue, so
this is why closed issues are included
ChrisL: Want to show where we are, what we've solved / not
solved, etc.
ChrisL: Some recent discussions around treating local fonts like
webfonts
ChrisL: But we need to solve this in some way, and we need to not
break the Web, and to not disadvantage users who use
languages other than English
ChrisL: For example Chinese often relies on local fonts
ChrisL: Another use case was a word processor type application, where
users expect the browser to access all the local fonts
ChrisL: Point of agenda item is to ask, who is interested in this
topic? Who plans to work on it? If we come up with solutions,
who will prototype them?
astearns: Looking for volunteers to look at the possible solutions,
try to make progress up to and including prototyping, to
see what we can do to make this a better situation across
all browsers.
noamr: I'm personally interested in it, but don't have the bandwidth
at the moment. I can try to find people in Google internally,
but that's the most I can commit to.
ChrisL: That's still helpful, thanks!
<emilio> (not with a mic r/n), but I'm interested, and there's people
at Moz that also are, but whether but whether we're the
right people to prototype depends on what solutions we're
talking about :)
astearns: As we work on solutions and get closer to something that
seems viable, it may be a little easier to convince others
to take the time to prototype things.
astearns: I will say that I got 5 private responses to my query that
was meant to prompt public reply-all of people interested
in this issue.
astearns: People expressed their opinions on what most likely
possibilities were on the issue, but just private replies
and not sure what people are comfortable with me making
public.
ChrisL: I sent a private reply. First I had increased time in CSSWG
by 10% and plh was ok with it.
ChrisL: I also commented on what I thought were the most practical
directions, but as the editor I want to be neutral.
ChrisL: so that's why private reply
astearns: I will commit more time to looking through these issues and
replying with problems that I see, or avenues that seem
promising.
astearns: I may not be quite the level of ChrisL, might be more 5%
increase. :)
astearns: [reads emilio's comment]
jfkthame: I'm in a fairly similar position to noamr, I'm interested,
but I have very little bandwidth atm
jfkthame: At the same time, if/when we coalesce around ideas worth
prototyping, I'm happy to advocate for them and try to find
resources to work on it
kbabbitt: Encourage incubating ideas
kbabbitt: Since I brought up word processing idea, I can discuss with
those stakeholders
kbabbitt: Will try to produce data necessary
astearns: So maybe we take this back to the issues and get some more
work done, unless anyone else wants to add to the
conversation?
astearns: OK, done for now. Expect these issues to return!
CSS Values
==========
Distinction between `attr(foo type(<string>))` and `attr(foo string)`
is too subtle
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11645
TabAtkins: attr() has the ability to say how to parse the attribute
TabAtkins: default behavior is to take the value and use it directly
as a string
TabAtkins: we also have the ability to parse it as CSS value
TabAtkins: In particular, can parse it as a string. This is weird,
because you would need to include the quotes.
TabAtkins: But it would also be weird to exclude that, so we're
allowing it.
TabAtkins: But it's confusing because to get the first behavior you
write 'string' and for the second behavior you write
'type(<string>)'
TabAtkins: These are super close to each other, and probably
confusing for authors.
TabAtkins: Some discussion about other keywords.
TabAtkins: unparsed-string, raw-string ...
TabAtkins: Unless anyone has other ideas, propose to rename to
raw-string
<bkardell> sgtm
TabAtkins: this is one of the keywords that do special behaviors
<TabAtkins> attr(href raw-string)
fantasai: This is equivalent to attr(href)
astearns: If it's equivalent to syntax without keyword, can we just
remove the keyword?
TabAtkins: We can't. For one thing, I prefer having explicit
keywords. But more importantly, legacy behavior requires
us to fall back to an empty string if the attribute is
missing
TabAtkins: whereas the new behavior is falling back to Invalid At
Computed Time behavior.
TabAtkins: It would be weird if you couldn't do that for the most
common case
TabAtkins: so omitting falls back to empty string, including keyword
falls back to IACT
fantasai: That is a subtle difference that is not going to be obvious
at all
fantasai: if that's actually a behavioral difference I think it would
be good to make it clearer
TabAtkins: Don't know how to bake IACVT into a keyword
fantasai: Me either
TabAtkins: Right now if you specify a type at all you get IACVT as a
fallback
TabAtkins: not tied to string vs ??, a little more for people to learn
TabAtkins: Agree it's not great but need to work around legacy
behavior
fantasai: Something for us to think about, if we can make it clearer.
astearns: So for now, proposal is to rename to raw-string
TabAtkins: Should do asap, since we're shipping already.
<bkardell> 1+
astearns: Any objections to changing string to raw-string?
RESOLVED: Rename string keyword to raw-string
CSS Overflow
============
Default UA styles for scroll markers and scroll buttons
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10935
flackr: We want to have a reasonable default styling for scroll
markers and buttons, so they're visible
flackr: Our suggestion is to make scroll buttons to render like
buttons, including handling 'appearance'.
flackr: and scroll markers would look like links
flackr: since they're interactive etc.
TabAtkins: You did bring up question of appearance?
flackr: I implemented it, think it should
TabAtkins: Agree
fantasai: The interesting question is whether the scroll markers
match the ? pseudo class
<TabAtkins> :visited/:link
fantasai: Technically they can't because :link by itself selects
elements but not pseudos
fantasai: Wondering what we want to do about that
TabAtkins: So if page author changes their :link style, wouldn't
change scroll markers?
fantasai: Right
flackr: Agree that would be nice... open to suggestions?
astearns: If we don't find a way of having link styling apply to
scroll marker, then what we're doing is requiring authors
to add the ::scroll-marker selector to their link styling
block
fantasai: Which they're not going to remember to do
<chrishtr> it seems unlikely to me that developers won't notice that
these Pseudos have the wrong colors, and then go fix it
<chrishtr> the colors being wrong will make their scroll markers look
invisible or totally wrong in prominent site ui
JoshT: Why are they being styled as links rather than buttons?
flackr: They scroll to content, just like regular links do
JoshT: In the past, authors probably would have implemented as
buttons; but I see the logic
TabAtkins: It depends what you're doing. Carousel dots, more like
buttons; but for ToC, more like a link.
JoshT: What is the aria role?
flackr: They're tabs, with scroll marker group being the tablist
astearns: Should we resolve on this, and then try to figure out link
styling? Or is this a fundamental question we need to solve?
fantasai: The goal of default styling is to make it visible... if not
visible, not a good thing?
TabAtkins: As chrishtr points out, authors will almost always tweak
them anyway
TabAtkins: so they're going to notice if looks bad on the page.
TabAtkins: same as if they put a blue background; will notice links
are invisible
TabAtkins: so probably fine
astearns: Whether or not fine, could resolve today on default styling
for scroll markers matching link styling, and scroll
buttons taking button styling
<chrishtr> +1 to this proposed resolution
astearns: anything about appearance?
TabAtkins: appearance applies to scroll buttons same as regular
buttons
PROPOSED: Default styling for scroll markers will match default
styling for links. Default styling for scroll buttons will match
default styling for buttons (and appearance will apply
accordingly).
RESOLVED: Default styling for scroll markers will match default
styling for links. Default styling for scroll buttons will
match default styling for buttons (and appearance will
apply accordingly).
flackr: I'll open a separate issue for the :link-matching
CSS Display
===========
scribe: kbabbitt
reading-flow and mix of auto-flow and explicit items
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11208
TabAtkins: last time we discussed there was a question about whether
reading order is the one that explicitly sets an element
to a particular spot
TabAtkins: rather than relying on visual stuff
TabAtkins: should work without opting into one of the other explicit
reading flow values
TabAtkins: whether it should be explicit or implicit etc
TabAtkins: authors had opinions in thread
TabAtkins: the idea of having a reading-flow value that does no
reordering by default but just gives side effects
TabAtkins: sounds perfectly reasonable
TabAtkins: we didn't do this before because just tab-index was the
side effect
TabAtkins: but with reading order in display now it makes sense to
have a reading-flow value that does no implicit reordering
TabAtkins: just reordering that author asked for
TabAtkins: we do however feel strongly that it needs to be a new
keyword
TabAtkins: rather than a default behavior that can trigger anytime an
element has reading order
TabAtkins: fantasai was suggesting that if any element has reading
order it automatically makes parent into a reading flow
container
TabAtkins: emilio disagreed on performance implications
TabAtkins: can't tell if something is a reading-flow container just
from element itself
TabAtkins: grid with a whole bunch of autoflow children can be an
expensive operation
TabAtkins: I think becoming a reading flow container has side effects
TabAtkins: having a child with reading order would implicitly apply
side effects to siblings
TabAtkins: this would happen if you have the same markup several
times on a page or across multiple pages
TabAtkins: only some have a reading order child or have a reading
order child that is hideable
TabAtkins: will change whether side effects apply to everything else
TabAtkins: seems not great, just as hard for authors to predict as
stated concern
TabAtkins: that authors would not be able to predict whether reading
flow works by default
TabAtkins: so we are pretty strongly against reading flow working by
default for these reasons
TabAtkins: should instead opt into reading order
TabAtkins: fantasai's third point in response was forward
compatibility
TabAtkins: if reading order automatically turns on reading flow
containers, that only works if everything can be a reading
order container
TabAtkins: or if we fix the set of block types that can ever be
reading order containers
TabAtkins: otherwise others could set reading order on a block which
would do nothing today
TabAtkins: we could define it in the future and it would turn on
suddenly causing side effects that they don't expect
TabAtkins: fantasai suggested we could go ahead and define
block-level reading flow right now in trivial case of no
reordering
TabAtkins: we're not super comfortable with that
TabAtkins: display:block order is going to be complicated anyway
fantasai: I don't think so, we're not proposing to add new visual
order
fantasai: just saying you can have normal flow order and also apply
reading order different from source order
fantasai: you have an order that's the source order, you don't have a
magic order, just saying reading order should apply to
source order like in a flexbox
fantasai: don't think floats etc. introduce any more complexity
fantasai: just as simple as a flexbox that doesn't have any order
properties
chrishtr: almost a no-op?
fantasai: no because if you set reading order on... e.g. I have a
section with a heading and a couple of paragraphs
fantasai: if I set reading order -1 on the heading it would pull up
the heading above the paragraphs
fantasai: no magic about floats, because that would require a new
value for reading-flow
fantasai: which would be magic block reordering something
fantasai: we're not suggesting that
TabAtkins: it does sound like a potentially doable behavior for block
but our opinion is still towards not triggering by default
TabAtkins: our ideal conclusion would be to add a no-op value that
just makes something a reading flow container
TabAtkins: and doesn't do anything else special
TabAtkins: define that it works for everything
TabAtkins: not everything because we still want tables to be
handleable in a different way
TabAtkins: so define it for blocks and call it a day
fantasai: this gets into another issue about initial value of
reading-flow
fantasai: next issue
fantasai: having initial value being smarter than sort order
fantasai: adding new value that is strict source order
fantasai: with those two, the strict source order could be the value
we use here
emilio: agree with TabAtkins
emilio: did we decide whether reading order affects a11y tree as well?
fantasai: yes
emilio: I don't know exact order of abspos and floats right now
emilio: but presumably that would get more tricky
emilio: e.g. does the float get order... in source order?
<iank> I think this property only applies to in-flow elements?
fantasai: if we apply to blocks, when floats come out of flow that's
a visual effect
fantasai: does not affect reading order
fantasai: would be there as if not floated
emilio: ok that seems fine
emilio: I would expect containing block to ? the order
fantasai: in the future maybe we want to do something fancy with
floats
astearns: in the proposal where reading order works without reading
flow, is it the case that if you set reading order on an
element that will make the nearest block-level parent a
reading flow container?
TabAtkins: yes
fantasai: yes
astearns: very limited utility with markup I'm used to working with
where things can get wrapper elements
astearns: caption goes above picture until someone decides caption
needs a wrapper element
astearns: then it stops working as intended
fantasai: don't think you can introduce a ? that hoists things out of
the tree
astearns: yes. I think this is an argument for TabAtkins' position
fantasai: don't think that would change situation in your case
fantasai: if reading order ?? it's still not going to move
fantasai: you still have to set it on the direct child that you're
trying to reorder
fantasai: if reading order is not set on the elements you want to
reorder that are siblings
fantasai: nothing is going to happen
fantasai: question is whether or not you need something on the
container, not going to make a difference here
fantasai: reason TabAtkins wants it is to make sure author is opted
into the tabindex side effects
TabAtkins: that's the big part, also if we go with your suggestion we
could never introduce a more complex behavior
TabAtkins: might be something we never need but I feel like if we
explore block cases more we might want to do something
like that
TabAtkins: uncomfortable with shutting off that possibility
fantasai: if you were going to reshuffle the tree...
fantasai: order property doesn't work like that
TabAtkins: but order property only works with flex and grid which are
explicit about container child relationship
TabAtkins: uncomfortable shutting off possibility of better block
reordering strategy
fantasai: how would that work? extract element outside container?
TabAtkins: don't know
TabAtkins: there's some meat on that bone though
TabAtkins: because as astearns said, it's common to have wrapper
elements
fantasai: if you introduce wrapper elements the reading order
property will be on outermost wrapper
fantasai: a number of properties that you want to set on outermost
wrapper, reading order is one of them
TabAtkins: discussion got mixed with next issue
fantasai: swap issues or stay on this one?
TabAtkins: we can get some resolutions on this one
TabAtkins: can resolve on a no-op container ? value, a source order
value or something
fantasai: need that for both issues
chrishtr: not to choose a name, say there is a value
TabAtkins: happy to resolve on that
astearns: Proposed resolution is to add a source order value to
reading-flow property
PROPOSED: Add a source-order value to reading-flow.
RESOLVED: Add a source-order value to reading-flow
fantasai: Proposed: reading-order applies to block-level elements,
does not apply to inline-level elements
TabAtkins: such that source-order value points to it?
fantasai: that's the third question
TabAtkins: not yet whether it applies by default or not
<fantasai> PROPOSAL: reading-order applies to block-level boxes, and
not to inline-level boxes. (Note this will work under
source-order, and not e.g. flex-*/grid-*)
<TabAtkins> reading-flow:source-order works on block containers.
reading-order works on block children of those block
containers that are opted in to reading-flow
<fantasai> PROPOSAL: reading-flow: source-order works on block
containers. reading-order applies to block-level boxes,
and not to inline-level boxes
astearns: objections?
RESOLVED: reading-flow: source-order works on block containers.
reading-order applies to block-level boxes, and not to
inline-level boxes
astearns: Anything more we can resolve on?
chrishtr: that it has to be explicit?
astearns: that is the sticking point
TabAtkins: resolution as it stands says implicit stuff doesn't work
TabAtkins: right now only explicit works
fantasai: we can take that back to the issue
chrishtr: come back to this issue next week for 3rd point
Received on Thursday, 6 March 2025 00:06:55 UTC