- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Jan 2025 19:51:46 -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.
=========================================
Rechartering 2025-2027 (Issue #10671)
-------------------------------------
- ChrisL has already responded to some comments and astearns will
reply to the remaining one.
- ChrisL will draft up a proposal to address the concerns in Brave's
objection and have it for the working group to review shortly.
Selectors
---------
- RESOLVED: :has-slotted should use the flattened tree to resolve if
content is slotted or not. We could later discuss a
different pseudo-class for the other behavior (Issue
#6867: Pseudo-class to indicate when a slot has content)
CSS Rhythm
----------
- RESOLVED: Do NOT establish BFC for block-step-size with details on
when the extra space gets added to the bottom only to be
determined in future conversations (Issue #11325:
`block-step-size` should not establish an independent
formatting context)
- RESOLVED: Close no change (Issue #1902: Inherit block-step-size)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jan/0009.html
Present:
Rachel Andrew
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Oriol Brufau
Stephen Chenney
Keith Cirkel
Emilio Cobos Álvarez
Stephanie Eckles
Elika Etemad
Robert Flack
Simran Gill
Paul Grenier
Chris Harrelson
Brian Kardell
Jonathan Kew
Roman Komarov
Chris Lilley
Alison Maher
Eric Meyer
Cassondra Roberts
Jen Simmons
Alan Stearns
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Lea Verou
Sebastian Zartner
Regrets:
Gaurav Singh Faujdar
Scribe: bramus
Rechartering 2025-2027
======================
github: https://github.com/w3c/csswg-drafts/issues/10671
ChrisL: Few responses
ChrisL: 1st response saying editorial addition saying CSS is good for
a11y
ChrisL: 2nd asking extra language
ChrisL: Response is that it sounds great and doesn't sound specific
to CSS. Suggestion to suggest to other group or some wording.
no response yet.
<fantasai> Regarding the previous point, how much of what's requested
actually belongs in the charter?
ChrisL: Suggestions welcome here
ChrisL: here is a link to a doc I wrote for tpac
<ChrisL> https://www.w3.org/2024/09/font-i18n-privacy.html
ChrisL: long running issue is sometimes called a privacy issue or an
i18n issue that pulls in opposite directions
ChrisL: had good discussion at TPAC
ChrisL: now, third comment...from center for democracy and technology
ChrisL: looking forward to collaborating with css and privacy and i18n
ChrisL: not sure we can change charter to say we have more progress
on this
ChrisL: I think they are saying that we should keep going
ChrisL: would love to reply that we will do that
ChrisL: does that seem reasonable?
astearns: sounds reasonable
ChrisL: can you send that?
astearns: where to send it to?
ChrisL: somewhere public would be good
ChrisL: should be addressed to the privacy wg and i18n wg
ChrisL: all of those were comments of the form whether we are doing
things about something
ChrisL: last one is from brave and is a formal objection
<ChrisL> https://lists.w3.org/Archives/Member/w3c-css-wg/2025JanMar/0017.html
ChrisL: unfortunately they were not able to attend the meeting at
tpac back in the day
ChrisL: it's not clear whether they realize work had been done,
although they sort of quote a bit from that
ChrisL: I think they are aware but they are saying we are doing
nothing and are not addressing things
ChrisL: they will remove FO if the WG plans to remove the
fingerprinting surface
<ChrisL> Brave will happily remove our FO to the rechartering if the
group proposes
<ChrisL> a plan to address the fingerprinting surface, and to
commit to
<ChrisL> incorporating mitigations for this fingerprinting
vulnerability into the
<ChrisL> group's specs.
ChrisL: also saying that our _refusal_ to address is concerning
ChrisL: what should we do as a group?
astearns: my recollection is that we sort of had a plan, but not one
that we can push through the specs directly
astearns: we thought that there would be a way of threading the
needle between i18n and privacy
astearns: in saying that “yes browsers can limit access to user
installed fonts if they provide a UI that opt in“
ChrisL: my recollection as well, but have no resolution on that
ChrisL: I think that nick dotty was of the opinion that UAs should
do that
ChrisL: cost is that it's an opt-in, either web wide or site-specific
ChrisL: seems clear enough to propose as spec text
ChrisL: also true that there are other fingerprinting issues and
should commit to solving those
jensimmons: if there is gonna be text that mandates a UA to turn off
privacy preserving features then I need to discuss
internally
astearns: but that has been a way forward for a while
astearns: maybe apple have already been thinking about this
jensimmons: I will try to find out
ChrisL: Of course I will put proposed text into an issue, not
directly in the spec.
ChrisL: don't want to break the web
fantasai: one of the things we can do to reduce the surface is to
only allow access to user installed fonts if they give you
access to code points that is outside the range of those
served by the system
fantasai: could limit it to letters
fantasai: outside of the normal range
fantasai: but would allow a browser to unconditionally allow access
to user installed fonts, but only when necessary
ChrisL: sometimes people install a newer version of a font because
some glyphs were wrong, so doing a codepoint by codepoint
thing means they would still get the broken behavior
astearns: for the purpose of this discussion: chris you will open an
issue with a proposed text and we will discuss that on a
call very very soon and show that as the proposed plan that
brave is requiring
ChrisL: yes
fantasai: when does our charter expire?
ChrisL: have until march
<ChrisL> Charter was extended until 2025-03-12
fantasai: so can discuss at f2f
jensimmons: would love to see this fonts issue written out
separately, in 1 place
ChrisL: the whitepaper I linked to is basically that writeup
Selectors
=========
Pseudo-class to indicate when a slot has content
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6867
keithamus: last week we resolved to match when the fallback content
is not being displayed
keithamus: which means using non flat tree
keithamus: think this is a mistake
keithamus: some people form the WC community reached out
keithamus: was maybe overindexing on maybe whether the fallback
content is displayed vs the flattened slots
keithamus: would like to change the resolution to use the flattened
tree
lea: do we stay consistent with JS API or do we do a better thing?
Both are valid. Probably should follow JS approach for
consistency
lea: am wondering if we can have two pseudo classes
keithamus: JS API offer the optionality through a flattened flag
keithamus: has more to do with compat with ::slotted
keithamus: cannot do slotted-slot
keithamus: also composition
keithamus: authors of components are more likely to want to know if
the thing has been slotted.
keithamus: if that is many layers deep seems irrelevant to them
lea: agree
keithamus: proposed resolution is to use the flattened tree
keithamus: to create new selector that uses non-flat tree I have no
opinion
keithamus: polyfills: won't affect us because JS has optionality for
both
lea: I completely agree with the sentiment that we need to ship this
ASAP. really needed
keithamus: I have i2s for chrome and I believe we are working towards
one for firefox as well
keithamus: need to resolve on this
<keithamus> PROPOSED RESOLUTION: :has-slotted should use the
flattened tree to resolve if content is slotted
or not.
<lea> +1
astearns: with a future issue on adding a param or new pseudo to not
use the flat tree
astearns: that's a different, later, discussion
keithamus: sgtm
chrishtr: do we need revised resolution?
astearns: no, wanted to point out other issue is out of scope
<lea> PROPOSED RESOLUTION: :has-slotted should use the flattened tree
to resolve if content is slotted or not. We could later discuss
a different pseudo-class for the other behavior.
chrishtr: so someone should raise a new issue
keithamus: I'll try and do that tomorrow
RESOLVED: :has-slotted should use the flattened tree to resolve if
content is slotted or not. We could later discuss a
different pseudo-class for the other behavior.
keithamus: thanks everyone for your time
CSS Rhythm
==========
`block-step-size` should not establish an independent formatting
context
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11325
jensimmons: block-step-size establishes a new BFC on the box that the
prop is applied to
jensimmons: authors are gonna apply block-step to article element and
apply to every p inside, or every img in figure.
jensimmons: if we make all those have a BFC that is a lot
jensimmons: means block-step won't work on floated content
jensimmons: should not have establish an independent FC
jensimmons: there's a few comments in the issue that shows photos
jensimmons: proposed resolution to no longer require an independent
formatting context
astearns: questions?
astearns: seems reasonable
fantasai: complication here is about floats, not about sizing of
floats but content that is impacted by a float
fantasai: if you have a box that is impacted by floats and tries to
avoid them. if it gets taller it might need to get narrower
fantasai: gets complicated with shapes
fantasai: if we want to do this – which I think we do – we can try to
determine how much of an impact there and limit the number
of cycles
fantasai: issue is that it moves the box down, e.g when using margin
fantasai: creates a position vs size relationship
fantasai: in case where it moves down and causes more complications,
then we could say space goes to the end
fantasai: and in the future figure out cycle-breaking
fantasai: would cover basic cases
<dbaron> I think we have some similar sort of cycles already with BFC
placement around floats, but I'm not sure if these are
equivalent or worse.
iank: don't you already have this problem?
iank: everything that avoids floats that is block level establishes
new BFC of some variety
iank: if you set block-step-size on some parent you already have the
case where a new FW that avoids floats is adding to margins
then it goes to next layout area
fantasai: oh, I misremembered the issue, this is about wrapping
fantasai: so you have a float and a box that has text in it that
wraps to avoid the float
fantasai: if that float has a complicated shape or ends before the
end of the paragraph
fantasai: when you say to have the p have a block-step-size of 1lh
fantasai: and you want to add 1em to either side of the p
fantasai: can cause all content to move down
fantasai: which can cause calc of line boxes to change and re-wrap
fantasai: don't think we want to do that
fantasai: or not all the time
fantasai: then that is what can cause the size to...if it re-wraps
end up with extra line which changes amount of space, which
needs recalc of step size
iank: I see
iank: seems problematic
fantasai: proposal is to track to see if the impacted lines by how
much
fantasai: or if additional lines become impact
fantasai: if no change, then adjust space above and below
fantasai: but if it does impact the space the only insert at the
bottom
fantasai: that way you get the rhythm that you requested
fantasai: it goes all at the bottom where it won't change the
position of the lines
iank: doesn't that break the rhythm?
fantasai: not really. the function does not impact internal contents
that might or not be on the rhythm
fantasai: goal is that make sure that thing that is after the x, you
resume the rhythm
fantasai: to make sure the margin box is an ?? number of steps
fantasai: we can say that “floats are impacting stuff and we don't
want to end up with a cycle so we insert at the bottom“
fantasai: in the future we can choose to try more layout options
fantasai: so in cases where it's safe to ?? then you get exactly what
you wanted and if it's not the case then we do bottom only
iank: I think that's fine as long...would prefer it to be if any of
the content is affected by floats you always place at the end
because we already have root layout scenarios that trigger
things like clearance
iank: or how does that work? might be problematic as well
iank: how does this work with collapsing margins?
fantasai: current spec says that you measure the box's own specified
margin to find its margin box and make that a ?? of the
step size
fantasai: means that in some cases that margin inside that is larger
than outside margin will do the step sizing thing correctly
fantasai: I specced it like that to keep it simple
iank: ... might be problematic
iank: doing content on border box modification is fine, margin box
inside of a block layout context gets problematic because of
interaction with collapsing margins and floats and float
clearance which would break the feature
astearns: so we need separate issue for that
iank: I'll file that
iank: At the end of the day you want to shift the box's position, not
alter the margin
fantasai: In terms of changing the margin we are not changing the
computed value, only from a layout perspective
iank: so wouldn't be reflected in gCS
iank: things like margin-trim do, though
fantasai: does it?
iank: yep.
iank: it's complicated / nuanced
astearns: let's set margin collapsing aside
astearns: talk about the desire to have a single behavior for block
step size in the presence of floats
astearns: suggestion is to always place at the bottom
astearns: does that make sense?
fantasai: as a first step yes
fantasai: but later might want to do a layout check
ACTION: fantasai to clarify that block-step doesn't impact computed
sizes
<RRSAgent> records action 1
iank: Could do that, it's a little bit complex because...
iank: can potentially do that if there's no intruding floats
iank: already have complicated logic in block layout
iank: interactions is really complex
iank: if there are intruding floats and their geometry changes then
we always add to bottom
fantasai: changes or if it doesn't extend far enough
iank: don't want that logic
iank: gets complicated with clearance
jensimmons: issue 1901 is relevant here
fantasai: two things we want to resolve here is that it does not
establish new BFC and two if inserting space above would
cause complications with floats then we insert the space
below only
fantasai: and then I would like for us to dig into the complications
that might be too complicated
fantasai: and ideally reduce the types of situations that hit this
limitation
fantasai: can have the spec a little bit undefined there to allow
implementers to give feedback
oriol: reminds me of align-content that non-normal establishes new BFC
oriol: do we want to be consistent with this?
oriol: about proposal: am concerned about leaving it open because
complicatedness depends on the engine
oriol: would prefer to keep establishing BFC or something very
straightforward as proposed.
jensimmons: suggestion was not to keep it permanently vague, but to
have progress on the spec
fantasai: for the use cases where this prop is likely to be used
overlaps a lot with floated content use cases
fantasai: having the property have no effect on things that happen to
be impacted by floated content
fantasai: want to reduce the cases where that happens
fantasai: important for this to work, so makes sense to not establish
BFC
fantasai: issue with align-content is that author is explicit about
what they want
fantasai: (missed)
fantasai: and don't want to change for align-content to flip BFC on
or off depending on placement of content
fantasai: cant make it conditional
fantasai: for align-content needs BFC
fantasai: for consistency
fantasai: for this case here, seems fine to insert space the bottom
when there is a complication
oriol: concerned about leaving "a complication" vague
oriol: depends on the engine
fantasai: yes, will align on that later...let's figure it out in the
in-between
astearns: would you, oriol, be ok with resolving on that?
oriol: not a fan of open ended things
oriol: I guess I can input/verify that ??? guess it's fine to leave
for later. not a fan though/
<dbaron> The other factor is that this particular feature (step
sizing) is designed in a way that it has to work reliably in
order to be useful (having consistent rhythm).
<fantasai> it's going to "work" consistency, it's just a question of
do we insert the space above or below the item
PROPOSED RESOLUTION not establish BFC with details on when the extra
space gets added to the bottom only to be determined in future
conversations
astearns: are you ok with that ian?
iank: seems fine. hard constraint for me is no relayout.
astearns: other comments/questions/objections?
RESOLVED: Do NOT establish BFC for block-step-size with details on
when the extra space gets added to the bottom only to be
determined in future conversations
Inherit block-step-size
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/1902
jensimmons: block-step is a shorthand for 4 longhands
jensimmons: see comment for details
jensimmons: there is an idea to have 5 longhands
jensimmons: to have block-step-size not set the increment
jensimmons: so they can turn it on/off for specific situations
jensimmons: discussed with elika that it reminds me of margin
jensimmons: you don't set it in one location and then turn it on
jensimmons: suggestion to close no change
jensimmons: do not need a separate property to turn it on or off
<flackr> I feel like usually you'd use a variable to pass it down if
you wanted to do this
astearns: trying to think of the use case where you want to keep an
inherited block-step length and turn that on or off
depending on the context
astearns: are you, elika, ok with closing no change?
fantasai: no strong opinion
iank: might want to split it off if ??? child
iank: to see if the thing as a whole
fantasai: to set it on the figure and not the caption
iank: or an article
astearns: there you turn it off for the children
astearns: usecase needs to be that you set it on a parent but don't
want a descendant to use it but do want its children to use
astearns: extra footgun of setting block-step-size and having it not
happen seems more like a general case that we should be
solving for
fantasai: for comparison, now that we dropped the new BFC
requirement, we could drop the none value in
block-step-size with an initial value of 0
fantasai: when you increase you get stepping
fantasai: alt model is to be like text-box-trim where one prop sets
the setting and another that turns it on and off
fantasai: alt model where block-step-size inherits and you enable it
on the boxes that need it
fantasai: not convinced that that extra indirection is necessary
fantasai: but have done it before
fantasai: cases where we did this are cases where you set a thing on
a parent and cascade it individually
flackr: officially this seems like a use case for variables...to pass
down values that are not applied
flackr: authors can use a variable if they want access to the value
PROPOSED RESOLUTION: Close no change
RESOLVED: Close no change
Admin
=====
astearns: next week breakout session on overflow
astearns: and then regular meeting
astearns: and then more
astearns: and then f2f
astearns: see you all then
fantasai: and register for the F2F on the wiki!
<fantasai> Please register for the F2F!
https://wiki.csswg.org/planning/cupertino-2025
Received on Thursday, 16 January 2025 00:52:19 UTC