- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 23 Jan 2025 19:28:42 -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.
=========================================
Upcoming F2Fs
-------------
- The spring F2F will be April 15 to 17
- There is a poll for dates for the summer F2F. Group members are
asked to fill in their availability.
CSS Environment Variables
-------------------------
- RESOLVED: Adopt safe-area-max-inset-* values (Issue #11019: Maximum
safe area inset values to allow sliding bottom bar)
CSSOM View
----------
- RESOLVED: enum ScrollIntoViewContainer { "all", "nearest" },
defaulting to `all`, expanding to element in the future
if needed (Issue #9452: Option for scrollIntoView that
doesn't propagate to ancestors)
Selectors
---------
- RESOLVED: UAs MUST preserve user privacy (Issue #11151: Proposal:
Update :visited language to state UAs must preserve user
privacy)
CSS Text
--------
- There wasn't a strong preference between the two options for issue
#9724 (What does the `white-space-collapse` apply to when
white-space trimming/positioning) will be written up in advance
of the F2F. This will allow the authors to gain feedback on ease
of implementation before selecting one option.
Anchor Position
---------------
- RESOLVED: Close no change (Issue #10831: `anchor()` Fallback type
inconsistency vs WPT)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jan/0013.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanazzov
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Andreu Botella
Oriol Brufau
Stephen Chenney
Keith Cirkel
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
Daniel Holbert
Brian Kardell
Jonathan Kew
Roman Komarov
Alison Maher
Florian Rivoal
Gaurav Singh Faujdar
Alan Stearns
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Regrets:
Lea Verou
Scribe: joshtumath
F2F Scheduling
==============
Spring F2F
----------
alisonmaher: Converging on dates April 15th to 17th
<astearns> +1 to confirming those dates
tabatkins: In April I'm only available first week
<alisonmaher> https://app.rallly.co/invite/VFdy8sxOY2WU
tabatkins: April 15th is week with most yeses. The no is me
tabatkins: vacation for 3 weeks in April
Florian: second week clashes with AC meeting
astearns: main difference is that we loose either tabatkins or Lea
astearns: we'll lose someone important either way
Rossen: we're going to lose both Chris and Lea. So let's do tentative
15th to 17th
Rossen: alisonmaher, when is confirmation of space?
alisonmaher: I can email everyone this week depending on what works
out with the booking
Summer F2F
----------
astearns: TabAtkins had a question
<TabAtkins> * Jun 23-27
<TabAtkins> * Aug 18-22
<TabAtkins> * Aug 25-29
TabAtkins: Summer? I have not looked into bookings. Does anyone have
problems with these weeks.
Rossen: The weeks and times are in IRC. Please take a look if you
have any hard blocks during those weeks.
Rossen: Please reach out to TabAtkins and discuss.
<fantasai> -> https://app.rallly.co/poll/j2QtO5IYmIOI
TabAtkins: Will be somewhere in continental Europe.
<astearns> thanks for working on this, Tab
Rossen: So, again, call to action is look at poll posted or
timeframes in the minutes. Reach out to TabAtkins or fill out
poll directly.
schenney: If you do sign in, you can change your vote later.
Rossen: Let's proceed with rest of the agenda.
CSS Environment Variables
=========================
Maximum safe area inset values to allow sliding bottom bar
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11019
flackr: The safe-area-inset allows authors to know what portion of
their content might overlap content they're not in control of
flackr: e.g. the camera
flackr: Lets authors know when it goes over the safe area, but this
changes dynamically
flackr: this requires re-layout. I would like to add a maximum safe
inset area
flackr: to allow it to slide in from the side of the screen to cover
the inset space
flackr: In particular, this is giving you the safe area you would
have at large viewport sizes
flackr: when viewport is small, less of your content is reaching the
edge of the screen so it's less likely to go under native
controls and things
flackr: when the viewport grows to the large size, it will go under
the camera
<TabAtkins> +1, this sounds reasonable to me.
emilio: It looks reasonable
emilio: I was trying it out in Chrome for Android and don't get the
safe area jump you are trying to fix
flackr: This is behind a bunch of different feature flags
flackr: as your controls slide away, the viewport would grow also
underneath the switcher bar
<bramus> Chrome flags:
https://gist.github.com/bramus/6ad1bfe96e9b93885c0858e5816acccb
emilio: Recomputing environment variables can be expensive.
emilio: Keeping track of what uses each variable. but yeah this might
be a reasonable way of fixing it.
flackr: We can use the approach suggested in the issue to optimize it
flackr: treat it like a position: sticky type effect
emilio: But you still need to update the style of elements. you could
implement smarter tracking
smfr: With Apple we're fine with this
smfr: Something I thought of is that when they change there will be a
resize event. But will there be an event for this to know it's
changed?
flackr: It's already dynamic but I'm proposing adding a static value
bramus: I took it for a spin and I think it will work out nicely,
solve author problems
Rossen: OK, the summary of the proposal is to adopt the
max-safe-area-inset values
flackr: wasn't sure if it should be safe-area-max
<bramus> safe-area-max-inset?
Rossen: safe-area-max?
RESOLVED: adopt safe-area-max-inset-* values
CSSOM View
==========
Option for scrollIntoView that doesn't propagate to ancestors
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9452
flackr: scrollIntoView is a useful API
flackr: Does the right thing for common use cases. but propagates all
the way up chain to scroll root
flackr: So the proposal is to add a container property to the dict
added to scrollIntoView
flackr: It would use Tab's proposal here for the common ancestor
about what to scroll into view
flackr: The main reason was to make it easy to refer to your own
scrolling ancestor.
flackr: So you'd say container.target and it would refer to nearest
ancestor
flackr: I'm also fine with it just using the container. but then we
have to answer what happens if the container is not actually
an ancestor
flackr: You could just do nothing because that's what you've asked for
flackr: TabAtkins' suggestion is simple to use, but container is not
quite the right name
Rossen: the top scrolling ancestor of the container?
<TabAtkins> X.scrollIntoView(container:Y), finds the nearest common
scrollable ancestor of X and Y
emilio: I think I was going to drop a similar question. Ancestor in
the DOM sense or layout tree sense?
emilio: or maybe we need to... we have a switch to not scroll
emilio: I think what you want is to scroll to the first scrollable
thing
emilio: let's say you have a fixedpos element
emilio: it does not scroll with the rest of the content
flackr: It would follow the scroll parent chain?
emilio: A layout ancestor.
emilio: so let's say if you scroll it on a popover.
emilio: that seems reasonable, but container is a misnomer. maybe
scroll-parent?
emilio: but we have the scroll parent API
flackr: we have a separate issue to add scroll parent to the element
API
<bramus> https://github.com/w3c/csswg-drafts/issues/1522 is that issue
flackr: we have offset parent, which is close
emilio: Should we add something to skip over overflow: hidden stuff,
but I can see you want both
bramus: They should use overflow: clip in that case
smfr: I agree with emilio. Should shadow roots be a boundary as well?
smfr: and at least in WebKit, scrolling goes across iframe boundaries
smfr: it surprises me because ???
flackr: I thought chrome changed that to not propagate across iframe
boundaries.
argyle: On codepen, the reproduce ability is available
argyle: you'll see the iframe scroll into view and you'll know it's
the child iframe. it's kind of the issue
smfr: I have a feeling that's cross origin. maybe I'm thinking of
jsbin
bramus: Yes I think so
<smfr> if Chrome did change the cross-origin iframe behavior, I'd
like that to be raised in a CSS issue and specified
Rossen: But the point is righteous. allowing to escape iframes or
cross-origin iframes, sounds like reasonably in scope
flackr: I think it's a different issue
flackr: the issue of smfr is iframes, it's scrolling and hijacking
frames that are unrelated.
<bramus> +1 on it being a different issue
<argyle> +1, two great different issues we should fix
Rossen: but should be tackled in a separate issue. very related
emilio: So we could still at least agree that this doesn't work when
the container you pass in comes from a separate document
emilio: smfr had a question about shadow root
emilio: they don't have boxes so they don't apply here?
emilio: depending on how we do this, scroll parent API has to
retarget stuff from inside to outside shadow trees
emilio: the scroll only on the first ancestor would get you ???
emilio: so I wonder if we should do more research for that situation
emilio: the closest scroller, if it's in the shadow tree, do you want
the container inside your tree
emilio: I don't think you want to get it without conversions, to get
an element from a shadow tree
flackr: I guess in a way, you can scroll up to the ????
emilio: You need a way of avoiding scroll parent in the shadow root
emilio: that may be an issue with shadow parent rather than this issue
flackr: We should have an API for that that expands to specifying a
container in the future
<emilio> maybe we have an enum Container { "all", "first" }, then
optionally make it `(Container or Element) container;` in
the future
<flackr> I would say nearest instead of first
argyle: 100+ on this. it makes scrollIntoView unusable because of the
side effects
argyle: maybe tag the containers with CSS. we indicate a scroll into
view mechanism
argyle: then you declare on any container that you know of.
flackr: I disagree because that would change things like scrolling to
an anchor link
flackr: could spec it not to but maybe it would be weird, affect some
APIs not others
flackr: agree with emilio's suggestion changing first to nearest
emilio: sounds good
bramus: Could have default value being document root element
bramus: As smfr said in IRC, could continue this at F2F
flackr: That could be breaking. we could change what all does
Rossen: I want to see if we can resolve
Rossen: instead of deferring to F2F
Rossen: We can agree to adopt it as currently specified
<flackr> Proposed resolution: Add container: 'all' | 'nearest' with
default value 'all'
<emilio> PROPOSED: enum ScrollIntoViewContainer { "all", "nearest" },
defaulting to `all`, expanding to element in the future if
needed
flackr: Scroll parent ancestry
emilio: Not if the block is not scrollable
smfr: Does it work in the popover case?
emilio: It would scroll the viewport, but that would be outside of
the scroller
emilio: we should define this so that it works properly in that case.
smfr: OK
Rossen: Sounds like it's resolved
RESOLVED: enum ScrollIntoViewContainer { "all", "nearest" },
defaulting to `all`, expanding to element in the future
if needed
<emilio> We should probably follow-up with issues for iframe and
overflow-hidden tweaks
Selectors
=========
scribe: emilio
Proposal: Update :visited language to state UAs must preserve
user privacy
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11151
TabAtkins: Won't go over background of visited privacy leaks
TabAtkins: Last year Kyra Seevers started to take up the project to
close that loophole
TabAtkins: since them we've been happy with the experiment
TabAtkins: Now we have a useful privacy-preserving visited
TabAtkins: we'd want to expand that language
TabAtkins: to make it more strict, from "may" to "must" help preserve
privacy
TabAtkins: That might be not matching :visited at all, or might be
doing something clever
TabAtkins: Idea is to add an appendix with our approach too
<astearns> +1 to must
emilio: +1
Rossen: Objections?
RESOLVED: UAs MUST preserve user privacy
<fantasai> sgtm
ChrisL: Any impact on WPTs?
TabAtkins: It must be a visual test to come up in WPT
iank: Not many, must be reftests
emilio: and reftests might not be reliable (assume sync queries of
visitedness)
CSS Text
========
What does the `white-space-collapse` apply to when white-space
trimming/positioning
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9724
andreubotella: We have hanging and conditionally-hanging glyphs
andreubotella: you can only hang at the end of a line
andreubotella: and you can have unconditional hanging spaces before
hanging spaces
andreubotella: in which case if you grow the size of the line box
there'd be a point where you reach the end of the
conditionally hanging spaces and then all the spaces
hang
andreubotella: I have a demo in the issue
andreubotella: [screenshares
https://github.com/w3c/csswg-drafts/issues/9724#issuecomment-1867809865]
andreubotella: question is are we fine with that behavior?
florian: This can happen with different white-space-collapse at the
end of the line
florian: can't think of when this would happen in real content
florian: another alternative would be that unconditionally-hanging
followed by conditionally-hanging spaces all behave as
conditionally-hanging
florian: I don't think this matters in practice
florian: the demo makes it the more obvious interpretation of the spec
florian: I think we could do that
<astearns> I think I prefer the proposal to propagating conditionality
andreubotella: The reason this would be rare in practice is that in
order to have unconditional hanging spaces _before_
conditional you need to have combination of these
values and characters such as ideographic spaces
florian: Right, just a mix of ideographic and regular spaces won't
cause this, you also need different white-space-collapse
values
emilio: Unless this really matters for some use-case, I think this
is fine
emilio: I'd be a bit skeptical of introducing this kind of "how you
hang depends on how things after you hang" that Florian
mentioned
emilio: so unless that behavior is really important for some
realistic use-case, I think what you suggest is fine
fantasai: I feel the second definition florian gave seemed simpler?
fantasai: so I lean towards that
fantasai: but I agree it doesn't really matter in practice, so
whatever is more straight-forward
andreubotella: Yeah I guess whether you hang at all depends on what's
after or how you hang seems fine
florian: What's harder to implement
andreubotella: Don't know off the top of my head
fantasai: Can ask internally
fantasai: agree to whatever is simpler
astearns: So we can resolve either with whatever is simpler or with
no change
fantasai: Can we put option a and option b together and just ask for
impl feedback?
florian: Last comment in the issue does contain that but can clarify
fantasai: Let's get those options together and poll at the end of
the F2F
CSS Anchor Position
===================
`anchor()` Fallback type inconsistency vs WPT
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10831
TabAtkins: In this issue it was raised that there's an inconsistency
with the spec that says `<length-percentage>` on the
fallback
TabAtkins: anchor and anchor-size are both `<length>`s
TabAtkins: so type wise they should be valid fallback
TabAtkins: so afaict there's no inconsistency
RESOLVED: Close no change
Received on Friday, 24 January 2025 00:29:14 UTC