- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Oct 2024 19:40:26 -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.
=========================================
CSS Inline
----------
- RESOLVED: Make property text-box-edge inherited (Issue #10904: Is
`text-box-edge` inherited or not?)
- RESOLVED: 2 values are required unless the single value provided
can be doubled (Issue #10703: The behavior when one value
is specified for `text-box-edge`)
- RESOLVED: We allow mix-and-match syntax for <text-edge> keywords
(Issue #10713: Allow re-ordering of <text-edge> keywords)
- RESOLVED: Revert the previous resolution: allow all combinations
for `text-box` (Issue #10748: Disallow `auto` in
`text-box` shorthand)
- RESOLVED: text-box-trim trims inline to the text-box-edge;
otherwise use the line-fit-edge; both for sizing and for
painting (Issue #10834: Inline boxes and line-fit-edge vs
text-box-trim/edge)
CSS Anchor Positioning
----------------------
- RESOLVED: When an anchor position element is first rendered or
change fallback position, use the current scroll offset
to calculate its position area (Issue #10999: Better
handling of scroll position for fixpos elements on first
layout)
CSS Pseudo
----------
- fantasai introduced issue #11038 (Should the "first formatted line"
propagate into a different BFC?) during the last few minutes of
the call so that there can be further discussion on the issue or
in a future meeting.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Oct/0006.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Kevin Babbitt
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Matthieu Dubet
Elika Etemad
Robert Flack
Mason Freed
Daniel Holbert
Jonathan Kew
Roman Komarov
David Leininger
Romain Menke
Fernando Serboncini
Jen Simmons
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Regrets:
Lea Verou
Scribe: matthieud
CSS Inline
==========
Is `text-box-edge` inherited or not?
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10904
fantasai: This is about inheritance of text-box-edge
fantasai: We split the text-box-edge into 2 properties
fantasai: koji thinks both properties should inherited (currently one
does not the other)
fantasai: Various scenarios seem to indicate that inheritance makes
more sense for Jen
fantasai: The proposal is to make text-box-edge inherit
fantasai: When trimming, we use the value of text-box-edge on the
containing block of the line box affected
fantasai: If you set text-box-trim on an article and heading says
trim to ex, then you will trim the top of the first line to
ex, and the bottom of last line to ideographic
kizu: I have some concerns
kizu: being inherited makes it very powerful
kizu: It could break some content inside (cf STP)
kizu: We will need to provide at least some author guidance to set it
on the smallest element possible, otherwise component inside
will be trimmed
fantasai: No text-box-trim will NOT be inherited, only text-box-edge
fantasai: This change would allow the box closest to the line box
would have the priority about what edge to trim to
fantasai: if you have text with mixed writing mode, this change allow
the closest box to the text to decide the edge which is
appropriate
kizu: Makes sense
kizu: I don't see any issue if text-box-trim stays non inherited
florian: Makes sense to me
florian: particularly about block boxes
florian: because text-box-trim also applies to inline, how it works
there?
fantasai: text-box-edge previously also changes the way line
calculation is done, but it has been moved to line-box-edge
fantasai: text-box-edge has no effect on an inline of any other box,
except if this box has text-box-trim also
florian: Makes sense that it doesn't apply, but what happens when it
applies ? the inline would use the value of text-box-edge
itself, not the container?
fantasai: Yes
florian: I support the proposal
RESOLVED: Make property text-box-edge inherited
The behavior when one value is specified for `text-box-edge`
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10703
fantasai: koji got developer feedback about when only one value
specific for text-box-edge it's confusing that it defaults
to text edge for the unspecified
fantasai: The reason the default is text because it's always valid,
conservative value
fantasai: The other current keyword like alphabetic trim aggressively
fantasai: We should not change the default for this reason
fantasai: but we can require 2 keywords
<kizu> +1 to requiring both
fantasai: In any case when that keywords can't be double (like `cap
cap` is not valid)
florian: The original design makes sense but not gonna object to
change
PROPOSAL: 2 values are required unless the single value provided can
be doubled
<florian> 0
RESOLVED: 2 values are required unless the single value provided can
be doubled
Allow re-ordering of <text-edge> keywords
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10713
fantasai: A question about syntax
fantasai: Currently syntax requires the first keyword for the
top-edge and second for bottom edge
fantasai: We could change the syntax to be re-orderable
fantasai: cap and ex are always on top side
fantasai: alphabetic always on bottom
fantasai: It could be more explicit and re-orderable
fantasai: We could also change the keywords to be more explicit
fantasai: Does it makes a better syntax ?
<fantasai> "text ideographic" vs "text-top ideographic-bottom"
fantasai: example "text ideogrpahic" is less clear than "text-top
ideographic-bottom"
fantasai: Choices: no change ? switch to explicit keywords syntax ?
allow both syntax (because no ambiguity) ?
<fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/13205
kizu: I like order independence
kizu: Could we do the same for `position-area` ?
kizu: If we can disambiguate it makes sense to make them re-orderable
matthieud: It is always implied, no? Trying to summarize
fantasai: So kizu is voting for the third choice (mix and match)
matthieud: Can decide at parsing time?
fantasai: Right
RESOLVED: We allow mix-and-match syntax for <text-edge> keywords
Disallow `auto` in `text-box` shorthand
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10748
fantasai: Disallow allow in text-box shorthand because it comes for
text-box-edge property
fantasai: Because `text-box: auto` is confusing
fantasai: `text-box: trim-both` is the same and clearer
fantasai: We should revert the previous resolution and allow all
combination
fantasai: We should at least allow `auto` to be combined
<fantasai> text-box: <'text-box-trim'> || <'text-box-edge'>
RESOLVED: Revert the previous resolution: allow all combinations for
`text-box`
<fantasai> https://github.com/w3c/csswg-drafts/issues/10748#issuecomment-2339570832
fantasai: When it is appropriate to disallow a longhand value in a
shorthand?
fantasai: Would introduce ambiguity in parsing, could be blocking for
the future, how readable is it
fantasai: We should have a very clear reason when we disallow a
longhand value in shorthand
fantasai: Careful about `auto` keyword also
fserb: Would this be a principle?
fantasai: Yes
fantasai: Do we anticipate having a keyword `auto` for `text-box`
(not the one from `text-box-edge`)?
<astearns> Something to add to
https://wiki.csswg.org/spec#coordination-between-specifications?
fantasai: This would be a good reason to disallow
florian: No reason in this specific case
florian: Should we upstream that to the "tag design principals"
document?
<fantasai> https://wiki.csswg.org/ideas/principles
CSS Anchor Positioning
======================
Better handling of scroll position for fixpos elements on first layout
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10999
TabAtkins: Anytime you do something which respond to scroll state, it
is generally do on compositor thread
TabAtkins: so no layout or ok do be a frame delayed
TabAtkins: anchor-positioning is careful about being mostly doable on
compositor except some spec defined part
TabAtkins: This is about one specific section: customizable select is
not responding to scrolling as much as it could
TabAtkins: cf link comment
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/10999#issuecomment-2415284548
TabAtkins: If you scroll the viewport, and reopen the popup, you
don't get what is expected (the second image)
TabAtkins: It doesn't look very right because currently spec mandates
that the calculation is done on the initial position
TabAtkins: We generally need this restriction
TabAtkins: Some cases we should remove it though: when first creating
boxes or when doing fallback
PROPOSAL: change the rule for calculating position-area: when an
element is first rendered or switch from fallback, calculate its
position form the current scroll offset, not the initial scroll
position
TabAtkins: We need this to make customizable select correct otherwise
it's very weird (specially when they start off screen)
emilio: Same similarity with last remember size stuff
emilio: Not objecting, we need the details very well defined
flackr: One case I'm worried is if you scroll up, recomputing the
size based on current scroll, it would then fit and you don't
want it to try to resize using the original position area
TabAtkins: When you trigger fallback it might move to a new fallback
position
flackr: Reusing the first position would be bad
TabAtkins: It could be weird, we need to treat this size as tainted
flackr: We need to do something to force it to a different fallback
flackr: like not recomputing the available area
TabAtkins: Stuff about remembering fallback ???
kizu: +1
kizu: I got this issue
TabAtkins: How solved it statically or a frame delayed ?
kizu: It was dynamic, and it would be better if static
kizu: We are using a library for this: they are dynamic
kizu: static is better here
TabAtkins: Everybody is okay with this approach
RESOLVED: accept what TabAtkins said in the thread with caveat from
here. When an anchor position element is first rendered or
change fallback position, use the current scroll offset to
calculate its position area
CSS Inline Continued
====================
Inline boxes and line-fit-edge vs text-box-trim/edge
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10834
fantasai: We split 1 property into 2
fantasai: One detail we should clarify: when you paint an inline box
what edge to you use to paint the box
fantasai: When text-box-trim is on, we should use the edge to paint
the background
fantasai: What edge do we use to size the text?
fantasai: Do we use the painted edge ? or we still size it against
the line-fit-edge?
fantasai: If text-box-trim is off, and we have border/background,
what edge to we draw them? (line-fit or text edges)
fantasai: In the new line box model, we want to use the visible edges
of the box to show the contribution of the box
fantasai: To be consistent, text-box-edge should trim an inline box
according to text-box-trim. If not, the edge use for
drawing and sizing is the edge specified by line-fit-edge
fantasai: Otherwise that creates inconsistency between box used for
sizing and box used for background
PROPOSED: text-box-trim trims inline to the text-box-edge; otherwise
use the line-fit-edge; both for sizing and for painting (except
when line-fit-edge is normal and we do the weird old thing)
RESOLVED: text-box-trim trims inline to the text-box-edge; otherwise
use the line-fit-edge; both for sizing and for painting
CSS Pseudo
==========
Should the "first formatted line" propagate into a different BFC?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11038
fantasai: text-box-trim feature really on concept of first formatted
line
fantasai: also first-line and first-letter rely on this
fantasai: To what extend are the allowed to intrude into a new
formatting context like flex, grid, multicol
fantasai: We need to think about use cases
fantasai: Possible easy answer: they don't (current implementation)
fantasai: In the past, people used ??? to create a new formatting
context
dbaron: Some case makes sense, other are problematic
dbaron: The weirdest is when a new formatting context has multiple
stuff at the top
dbaron: like multi column or grid
dbaron: Whether that justifies to make it not work with all new
formatting context is another question
dbaron: But I think it's weird to apply it to the cases where there
are multiple things at the top or bottom
florian: first-line, first-letter, text-box-trim should have the same
behavior which is ???
<dbaron> (This seems different from first-line and first-letter in
this regard.)
<fantasai> dbaron, I think it might make sense to apply it to all of
the things at the top
<fantasai> dbaron, but definitely not just one of them
Received on Wednesday, 16 October 2024 23:40:58 UTC