- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Apr 2025 19:42:08 -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.
=========================================
FPWD for CSS Custom Functions
-----------------------------
- RESOLVED: Publish FPWD of CSS Custom Functions
CSS Easing
----------
- RESOLVED: Copy linear gradients timing details into the linear
function (Issue #11211: Resolving curves not available at
parse time)
CSSOM View
----------
- RESOLVED: Remove the event (Issue #7693: No event to track window
position)
- RESOLVED: Add scrollParent to the spec (Issue #1522: Consider
adding Element.scrollParent)
CSSOM & Transforms
------------------
- RESOLVED: All CSS-defined functions serialize to lowercase (unless
otherwise defined), just like CSS-defined identifiers
(Issue #11556: Serializing of functions)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Apr/0011.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
Daniel Holbert
Jonathan Kew
Roman Komarov
Rune Lillesveen
Alison Maher
Josh Tumath
Alan Stearns
Sam Weinig
Sebastian Zartner
Regrets:
David Baron
Miriam Suzanne
Lea Verou
Scribe: JoshT
FPWD for CSS Custom Functions
=============================
github: https://github.com/w3c/csswg-drafts/issues/6900
spec: https://www.w3.org/TR/css-mixins-1/
Rossen: We need FPWD so people can ship
<TabAtkins> https://drafts.csswg.org/css-mixins-1/
TabAtkins: We've been talking about mixins spec for a while.
Discussed in F2F.
TabAtkins: believe spec is ready for FPWD
<fantasai> We are *overdue* for FPWD...
TabAtkins: close to ready for CR
TabAtkins: at least FPWD. Let's resolve to do it.
Rossen: Any issues with that?
<astearns> +1 to FPWD
<lea> +1 to FPWD (and to fantasai's comment)
<florian> sure, go ahead. If it's nearly ready for CR, it really
ought to get on TR at all
RESOLVED: Publish FPWD of CSS Custom Functions
TabAtkins: I'll get publication started.
fantasai: I wanted to find out plan for review of draft.
TabAtkins: As in when we ping other groups?
fantasai: Yes and blog and trying to get people to look at it
TabAtkins: We've had shakeup of staff so may be difficult, but I will
take care of those.
TabAtkins: I don't think this needs wider review from a11y or i18n?
fantasai: I still think we need to ping them all because requirement
for CR
fantasai: so publish blog post, ping groups
<astearns> ping everyone and let them say “no comment”
<PaulG> (from APA) it's low-level so probably not an issue but will
depend on whether patterns of use emerge during socialization
that alarm APA
jensimmons: It's worth taking the time to get dev and browser team
feedback
jensimmons: I know it takes time, but we are at our best as WG when
things have baked well before shipping
TabAtkins: Early feedback has been positive. YouTube personalities
seem to like it.
TabAtkins: but as spec author, I would say that ;)
CSS Easing
==========
Resolving curves not available at parse time
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11211
TabAtkins: Spec text for linear easing function has canonicalization
TabAtkins: steps for filling in steps that have empty inputs like
gradients
TabAtkins: but it lacks the timing details that linear gradients put
in for values that can't be resolved until computed value
time
TabAtkins: spec bug? I recommend we copy details from linear
gradients because it's close to a color stop list
weinig: Can we abstract it into something more general?
TabAtkins: My policy is to wait for a third thing? but I'll see if it
makes sense
<TabAtkins> WET code - write everything thrice
weinig: When I implemented this in WebKit, did at computed value
time, but I don't expect this to be a compat issue
TabAtkins: Proposed resolution is to copy linear gradients into the
??? function
RESOLVED: Copy linear gradients timing details into the linear
function
CSSOM View
==========
No event to track window position
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7693
fantasai: Our team has reviewed this and is opposed to new APIs
relying on window position. privacy problems
fantasai: we don't want to add to API surface
florian: This doesn't expose anything new. Just adds a convenience,
so you don't need to actively pull it.
florian: If you don't expose anything, it doesn't affect you. But for
people using it, they can be more efficient.
florian: There are projects to see about doing it declaratively,
which would be better, but this has been talked about for a
while.
florian: there is an opt-out so I don't understand concerns
TabAtkins: I agree generally. This is no new surface, a small easy
change that makes a known use case from Bloomberg more
efficient.
TabAtkins: I agree we shouldn't go to large expense supporting, but
in this case synchronizing API wise with event for
window.size, this does not seem worth objecting to
TabAtkins: I support keeping the resolution as it is
emilio: Did we define what happens with iframes? They do change
screenX, screenY as well
emilio: but they could have cross-origin behaviour
florian: There are some cases where it is not useful. To make it
useful, you are in breach of privacy
TabAtkins: I saw comment on issue that it should be OK to make it not
work for iframes
emilio: I'm curious about particular use case. popups?
florian: Yes I think it was primarily for popups. And moving windows
that are side-by-side together to remain together.
emilio: Implications for popups are trickier. Let's say you don't
move the window but user adds a toolbar or menu bar
emilio: that moves the page down and you should get... screenX
exposes the top window, so is it useful?
florian: If we had a declarative API to make the browser deal with
it, that would be great. But we don't have that.
florian: we have an non-great API that could be made more convenient.
Not a huge win to do this, but it's a small improvement.
emilio: If it's easier to make something work on windows but macOS
and linux get screwed...?
florian: But how?
emilio: It makes something that's not platform independent easier
to use
emilio: can we make--
PaulG: I work for a competitor to Bloomberg. we break up the app into
a PWA and you could have the app tile maybe up to five
monitors. get things to respond to size, shape and placement.
PaulG: simulates a console app environment
PaulG: PWA speeds up development, so I can see how this would be
helpful
emilio: But how will screenX on monitor a be compatible with monitor
b particularly if they have different devicePixelRatio?
emilio: I'm not sure if we expose stuff like the size of the window
borders?
emilio: But the details of these APIs are not a great fit for the use
case. Only works if there's no sidebar, for example.
emilio: I'm concerned about making it easier to use
<TabAtkins> Remember: this information already exists and is actively
used by these tools. Any complexities or issues are
things they're already dealing with. This whole API
suggestion was solely to let them stop using *polling*
and start using an async event instead, so it's a little
more efficient.
florian: We have exposed the info everywhere but we want to make it
easier to pull
emilio: The common case of a full width window is easy to handle, but
if you add stuff on top. the Firefox UI has complex
calculations to see where the windows go, and I've seen many
bugs
emilio: can people see all the edge cases?
Rossen: I think your point is well understood about making the ease
of it increasing the badness of it
smfr: This also requires leaking the origin of the screen. very
fingerprintable
smfr: we want to actually lie about this to reduce fingerprinting
smfr: we want to discourage new use of these values
<TabAtkins> Again, this information is already "leaked", and to
whatever extent you censor or reduce it, it'll apply to
this as well.
schenney: If they want a popup window outside of the browser chrome,
and it contains info relative to the main window, and they
want to move with the main window, then the multi-screen
thing is still a concern?
flackr: I want to respond to smfr. Why not just lie with 0?
smfr: It might be 0, but they may not be accurate
jensimmons: If you say 0 to everyone, it may not be an ideal solution
<TabAtkins> randomly fluctuating position would be just as noticeable
as constant-0, fwiw.
emilio: 0 seems non-fingerprintable to me. But sites depend on these,
so do you increase the web compat impact on this?
flackr: If you do moves consistent with the lie then it should be fine
florian: the spec does already call out you can lie about this
florian: if you do want to lie with randomization and jumping around,
then that may be a problem
florian: I understand why browsers would not want to ship this, but
the web platform is used as a runtime for a bunch of things
florian: If you can detect you are on one environment, it is useful
to achieve these things
emilio: With web compat, let's say we do get them to react to screen
pos values, on some platforms, we do lie because we can't do
anything better
emilio: on Wayland, screenX is always 0
emilio: if you ???? then sites will break
TabAtkins: But this is not a commentary on the existing screenX and Y
things
TabAtkins: the polling is easy but it's not efficient for users
computers
emilio: But maybe instead of the polling, I just don't use them
because polling is inefficient
<fantasai> +1 emilio
IanK: But you do have a lot of large websites doing the polling, so I
don't think it discourages anyone
Rossen: What if we did a poll here (pun, haha) and see what the group
thinks. Is it half and half about whether to add it?
TabAtkins: We already have a resolution to do it
florian: We need to change both HTML and CSS specs to do it and HTML
won't merge if one browser objects
florian: Safari objects
<smfr> Anne points to
https://w3ctag.github.io/design-principles/#leave-the-web-better
"The existence of a defect in one part of the platform must
not be used to excuse an addition or extension to the defect"
Rossen: So the question here is: do we remove it or not?
Rossen: emilio and WebKit folks say we should remove it. Chrome folks
mostly saying keep it.
Rossen: The poll will show the same thing, so we could try to force
resolution in a different way
schenney: Bloomberg are not so interested in this any more.
schenney: So between those two points, I would say we should remove it
Rossen: I could poll or call for a resolution right now
Rossen: Let's call for a resolution for objections without poll
Rossen: Does anyone object on removing this event?
florian: Unfortunate but I don't object
RESOLVED: Remove the event
Rossen: As editor, you will have to remove it. I am sorry.
florian: It's not a huge thing
Consider adding Element.scrollParent
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1522
flackr: We've had a bunch of other APIs to expose the parent and
offset parent, but devs have to do a lot of querying to find
nearest scroll container
flackr: Resolution proposed is to expose it. scrollParent. the
nearest container that's a scroll container
emilio: Just to confirm, we're talking about the scroll container you
scroll relative to
emilio: for stuff like fixpos, it should return null
emilio: I'm assuming for the root scroller, we return the
scrollingElement (in quirks mode that's the body) there are
some complexities there. we could return
document.scrollingElement?
<TabAtkins> yes, .scrollingElement I think is right
emilio: I guess modulo details it sounds good
TabAtkins: bramus suggested in the thread calling it scrollingParent
TabAtkins: I'm not sure if we have other scroll APIs that suggest we
should stick with 'scroll'
<TabAtkins> to be consistent with .scrollingElement
iank: Just to check, flackr, this will walk up the containing block
chain?
iank: so if abspos skips, it can skip a scroller and make sure it
returns the next one
kizu: I wanted to mention how we handle elements with ??? auto,
scroll, where there an element not overflowing
kizu: and cases where it clips something, so it is inside content but
not scrollable by usual means
kizu: this is what we currently on our app do. we go up the chain,
looking for scrollable containers (compared to offsetHeight
with actual height) and go further if it's not currently
scrollable
kizu: so if it will not work as expected, we will need to mention
this and propose what it should do in this case
flackr: I disagree we should make it work this way. e.g. stickypos is
offset to the nearest scroll container.
flackr: I think it should follow the spec definition of a scroll
container
flackr: if a dev wants to find the thing that actually scrolls, they
will still need additional logic
<TabAtkins> +1 to flackr's point
<iank> +1
<oriol> +1. overflow:hidden can scroll by script, no scrollbar needed
<emilio> +1
astearns: You were saying the spec needs an example of how to do it
this way?
kizu: Authors will want to be able to do this. There is also a
precedent for us to have state queries to ask if an element is
scrollable right now
kizu: this is what authors want now. not theoretical scrollability
kizu: it will be already accessible, but maybe we could make it better
<iank> It depends a lot on the usecase for what you want to do.
flackr: This at least makes it easier to get what you're asking for
flackr: but changing the size of your window could cause a different
scroll parent
emilio: If we wanted to do something like that, it might be worth
turning this into a function with options
emilio: but checking if it's scrollable is a matter of checking if
scroll height is less than client height
emilio: Modulo sub pixels get tricky but that's a separate issue.
emilio: If we need filters and whatnot, we need a different property
for 'does it have scroll overflow'
emilio: I do agree that pages tend to ask for it and get it wrong.
emilio: It is trickier to tell if something is truly scrollable
emilio: but this API should just tell you if it's a scroll container
<TabAtkins> *using* this API, it's pretty easy to walk the
scrollParent chain to find one *with* a scrollbar. still
a strict improvement over today, where if you just walk
the *parent* chain you might catch something not in the
element's CB chain
<TabAtkins> and enough things *will* want the spec's notion of
"scroll container" that we should expose that; can't
really get scroll container from an API that returns
"nearest thing with a scrollbar" as it might overshoot
<ydaniv> +1 to not skip hidden etc. Otherwise will behave different
from ViewTimelines as well
kizu: Sounds good. We will need to think about how to fix it but not
in this issue
fantasai: I agree with flackr and emilio
fantasai: if we want to make it easier for authors to filter, we
could do it based on container queries and filter by x or y
fantasai: that is a separate issue. this proposal makes sense
emilio: For the root scroller case, should we return an element at
all?
<flackr> +1 to emilio's suggestion of an IDL attribute to easily
check if something is currently scrollable
astearns: I'm not hearing objections
astearns: does anyone have a pref for scrollParent or scrollingParent?
<TabAtkins> happy to leave name decision to flackr
<iank> "scroll" matches "scrollWidth" etc.
<kizu> +1 to `scrollParent`
astearns: proposed to add scrollParent to the spec
RESOLVED: Add scrollParent to the spec
fantasai: Who will make edits in which spec?
flackr: I can make edits
CSSOM & Transforms
==================
Serializing of functions
------------------------
github: https://github.com/w3c/csswg-drafts/issues/11556
TabAtkins: Anne brought up that the CSSOM spec doesn't go into detail
about serializing functions with casing
TabAtkins: the only place where this matters right now are transform
functions
TabAtkins: all others are in lower case
TabAtkins: do we serialize transform functions in lowercase
TabAtkins: or canonical form?
TabAtkins: NaN serializes with the capital N
TabAtkins: I suggest we do what Anne says and serialize in lowercase
TabAtkins: but if compat goes the other way, I'm happy with that
emilio: You just addressed my comment. I think Firefox serializes
with the uppercase, but I might be wrong
emilio: Do we know what browsers do?
emilio: Agree lowercase seems preferable
astearns: There are platform tests testing for uppercase, Anne says
keithamus: Webkit would prefer lowercase
emilio: Is their preference current behaviour
<TabAtkins> Chrome definitely serializes to uppercase currently,
regardless of what you specified
<emilio> Same for Firefox
weinig: WebKit does capitalize
weinig: I also think we should lowercase. I don't think there is a
compat issue
weinig: it parses fine and I don't think people will rely on
capitalization
weinig: seems like a weird case
TabAtkins: on the unlikely compat issues, you will only see the
casing of one of these functions if they query the
specified style
TabAtkins: In matrix functions, both of these are lower case. people
can't depend on casing in any case
emilio: That makes me more comfortable
emilio: I guess not objecting to change this
<TabAtkins> In the computed style you always see matrix() (or maybe
matrix3d())
astearns: Not hearing objections
astearns: does anyone want to argue why we'd want to muck with things
when we already have tests?
<TabAtkins> we are making a change *away* from current impls tho
weinig: It's undefined behaviour currently. We need to make some
decision
astearns: But this is opposite of currently implemented behaviour and
tests
astearns: so proposed resolution is that all serialized functions
serialize to lowercase
RESOLVED: All CSS functions serialize to lowercase
Received on Wednesday, 30 April 2025 23:42:40 UTC