- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 Sep 2024 19:15:33 -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.
=========================================
Anchor Positioning
------------------
- RESOLVED: New WD for anchor positioning
- RESOLVED: Undo the previous resolution and not add position-anchor
and position-type to the position shorthand for now
(Issue #10321: `position-anchor` should be defined as a
longhand of `position`)
CSS Inline
----------
- The proposed behavior for issue #5335 (text-box-trim vs
fragmentation) appeared to be what authors wanted, but there were
concerns with implementability. There will be some discussion
offline by the implementors before the issue is brought back for
resolution.
CSS Box
-------
- Issue #10761 (Applying `margin-trim` to fragmentation containers)
had the same concern about implementability and will be included
in the offline conversations about issue #5335.
CSS Overflow
------------
- RESOLVED: No change to spec, add a note (Issue #10448: display:
-webkit-box and line-clamp without -webkit-box-orient:
vertical)
CSS Easing
----------
- RESOLVED: Allow linear() to have a single stop (Issue #10580:
Linear easing function requires at least two points?)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Sep/0004.html
Present:
Tab Atkins-Bittner
Kevin Babbitt
Andreu Botella
Stephen Chenney
Elika Etemad
Chris Harrelson
Daniel Holbert
Ethan Jimenez Vargas
Ian Kilpatrick
Alison Maher
Florian Rivoal
Alan Stearns
Miriam Suzanne
Scribe: andreubotella
Anchor Positioning
==================
Publication
-----------
github: https://github.com/w3c/csswg-drafts/issues/6900
astearns: Tab asked for a new WD for anchor positioning. If all of
the edits have resolutions, we don't need a resolution for
publishing a new version, but we might as well
TabAtkins: Not 100% sure everything has a resolution. I might have
made small edits that didn't have a proper resolution. We
also have a lot of renamings that need to be reflected on
the WD
fantasai: Will review the changelog before publishing
<florian> +1
RESOLVED: New WD for anchor positioning
CSS Inline
==========
text-box-trim vs fragmentation
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5335
fantasai: I was chatting with Jen Simmons about how text-box-trim
interacts with fragmentation. We have a discussion about
setting text-box-trim in a box in the flow that gets
fragment, but not on the multicol element. There's a lot of
column boxes inside it, should it apply to any of them?
fantasai: Probably makes sense to apply to the first and last line
box in each column
fantasai: assuming there's no intervening padding or borders
<chrishtr> +1
<miriam> +1
frivoal: Makes sense to me
astearns: I know of a use case where we'd want to trim all of the top
and bottom (?) of a column except for the very first and
last. But we can handle that with the :column element
frivoal: I'm aware of that for trimming margins, but this issue is
about trimming the top and bottom of lines. Is that correct
as well?
astearns: You might be right that it might apply only to margins.
There might also be a usefulness for lines. But yes, it
should apply only to the top and bottom if it applies to
multicolumn
bfgeek: My concern is that if applied to the end, it might shorten
the column box, which might change the fragmentation point
fantasai: When fragmenting, you'd have to be aware of whether the
line box to add to a page is trimmed or not
bfgeek: It's more complex, because of interactions with collapsing
margins at the end
bfgeek: I don't know if this is implementable for end trimming
frivoal: In this issue we're talking about trimming leading in lines,
does that also affect?
astearns: We might need some make-forward-progress algorithm where
you decide where the fragmentation break is, then apply the
trimming, and not reconsider the break
fantasai: It's similar to when trying to see if something fits, you
truncate the margins. If there are borders or padding, you
already cannot trim. It's different between line boxes and
at the end of the element, so when you evaluate whether you
fit, you trim the line box
fantasai: if additional content fits, then you move forwards
frivoal: It's clear it's desirable, but not clear how doable. Can we
edit it later if it's too hard?
fantasai: I think that's reasonable. Because margins are invisible,
it doesn't matter whether you consider the box trim or not.
It's only when placing the content and checking whether it
fits before the end of the page is when you need to
consider trimming
bfgeek: What is the behavior with empty elements that are after this?
bfgeek: If there's a subsequent empty element. That's not considered
(?) if there's an empty element afterwards
bfgeek: That's complex because we don't want to arbitrarily look
forwards to see if this is the last
fantasai: If the bottom edge of my box is 1em from the bottom of the
page, but it has a bottom-margin of 2em
fantasai: we truncate the margin to the extent necessary to make
it fit
dholbert: When fantasai was talking about how it works in practice,
discounting the text-box-trim for the purposes of seeing if
the element fits, should it also make the element draw a
smaller border box if it happens to fit when this is taken
into account?
dholbert: Should the background extend to the bottom of the column?
fantasai: Do you mean a block background or an inline background?
dholbert: If the line of text has a background, I'm thinking of a
span that has a background
...
fantasai: As an author, you don't want to combine text-box-trim with
a block background
fantasai: in the long term, we might want to have a control for this,
similar to margin-break for margins, but this would be the
default
astearns: Should we specify the behavior as florian suggested, and
reopen the issue if there are implementability concerns? or
do we take it back to the issue for now?
fantasai: I think this is what people would want if they set
text-box-trim on multicolumn. The alternative is it doesn't
apply at all
frivoal: If it applies only to the first column, it's worse because
you have unbalanced columns
astearns: Any objections, dholbert and bfgeek?
bfgeek: There's some complexity because, the way it works we'd need
to backtrack. For example, you place a line box, there's 10px
of space remaining. You need to lay out the next line box,
because it might only be 8px
bfgeek: But if it's 12px high, you need to backtrack and go to the
previous line box, and then trim it, which is a bit scary
bfgeek: you don't know if it's the last line box until you lay out
the next line
frivoal: Having it only apply to the first column and not the others
will be ugly. In general, for the problem, if we only trim
at the first column it's bad
frivoal: Same for printing and pagination, if you have a multi-page
document, you want the top and bottom to match
bfgeek: At the minimum we'd want trim-top. I'll talk to Morten to see
how feasible is trimming the bottom if we have to backtrack
fantasai: Once you've decided that the line box fits, you can forget
about whether you trimmed it. It only matters if you drew a
background, and if you do, you have the question of where
it ends
fantasai: You have to make sure the background doesn't go beyond the
fragmentainer edge
bfgeek: It affects more things than that
astearns: We should table the discussion of how it should work for
now. bfgeek, are you okay having the conversation with
Morten before resolving?
bfgeek: Yeah
frivoal: Can we resolve to do it on the start side and leave the end
side open?
astearns: We'll discuss that next time
CSS Box
=======
Applying `margin-trim` to fragmentation containers
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10761
fantasai: Jen and I think it makes sense if an author applies
margin-trim to a multicolumn container, that it should
apply to both the top and bottom
<fantasai> of the column box
bfgeek: For grid and flex I don't think it's a problem. For block
layout, we have the same problem as before: start is fine,
end is even more complex than text-box-trim
bfgeek: When you're processing an element, you fundamentally don't
know the end margin of it
andreubotella: For line-clamp: auto I'm keeping track of the bottom
margins in order to subtract relevant sizes when
computing block size
andreubotella: That's currently implemented in Blink, but only when
you have line-clamp
andreubotella: idk if it could be useful for this
florian: In terms of use cases, this is important to consider,
because trimming the margins at the start of all columns is
something authors may want
florian: This exists in AntennaHouse, which means there's demand
for it
<fantasai> https://www.w3.org/TR/css-break-4/#break-margins
fantasai: We have that spec'd on the margin-break property. If it
says keep, you keep it regardless of margin-trim
bfgeek: I'm oscillating between "it's actually easier" and "it's
harder". I'd like to talk to Morten about it
bfgeek: we could resolve that it only applies to block layout
bfgeek: that might be something to make forward progress
PROPOSED: margin-trim only applies to a multicolumn container by
trimming block-level margins at the top and bottom of each
column box
florian: Is this only multicolumn? Pages printed side-by-side have
the same demands
fantasai: What are you setting it on then?
florian: The root?
fantasai: They're both kind of similar, I'd like to resolve on this
one sooner than later
bfgeek: I'll meet with Morten next week and chat with him about this
astearns: If we have not come back to this by TPAC, I'll make sure
it's on the agenda then
Anchor Positioning Con't
========================
`position-anchor` should be defined as a longhand of `position`
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10321
TabAtkins: A while back, we resolved to make position a shorthand for
position-type (setting the absolute, fixed... keywords)
and position-anchor
TabAtkins: We've experimented since then, and the Chrome team would
like to reverse this resolution
TabAtkins: Compat reason: we'd thought there would be a stronger
compat reason to not shorthand position or other
properties, but upon further review, while there's still
risk, it's not that bad
TabAtkins: so we should consider shorthanding these older property
TabAtkins: we don't want to do it without a good reason because it's
risky though
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/10321#issuecomment-2136102979
TabAtkins: Also, after some thought, we don't agree with shorthand
position being part of the position shorthand
TabAtkins: while we have a pretty strong tradition of prefix name
shorthands being shorthands for properties with the same
prefix, but it's not as strong as thought
TabAtkins: there's a list in that thread
TabAtkins: The argument from language design is weaker than we
thought, and that strengthens the argument for not
making it
TabAtkins: to make a reasonable shorthand out of this, you need more
complex grammar, which makes it harder to use
TabAtkins: This is in the category of properties that are adjacent to
other properties but shouldn't be reset together
TabAtkins: Shouldn't reset, especially if you're switching from
static to fixed
TabAtkins: so we object to making position a shorthand right now, and
in particular with making position anchor a part of that
shorthand
astearns: Is the complexity of the shorthand across all the value
spaces, or does it only get complex when trying to set
anchor positioning values?
TabAtkins: Both. The first, because anchor positioning only applies
to static or fixed, ...
fantasai: That's not true, if you set to sticky it would ignore all
of the anchor positioning stuff
TabAtkins: I think none is one of the few obvious counterexamples,
but more complex distinctions we don't do too often
TabAtkins: the second bit of complexity: ... and ... are custom
idents, so we'd need to make them distinguishable
<TabAtkins> like, `position: absolute --foo / --bar`
TabAtkins: explicitly setting position: absolute, maybe with
container in there, and then ... gives a more readable CSS
in our opinion
fantasai: We are interested in trying to address Chrome's concerns.
We're happy with the spec as it is now until those concerns
are solved, but not happy with reverting before
florian: I agree with TabAtkins about the language not being
consistent with the prefix not always being the shorthand.
About position resetting all of the longhands, how important
is it?
fantasai: It depends on whether we want a shorthand that sets it
together
fantasai: We'd have to design that and put it out to the whole
working group
florian: Even if the shorthand doesn't set it together, for the
things that are set by position, would you have interference
from the other things set by it if they don't get reset?
florian: If we're reverting and leaving the issue open for now, I'm
good with it
TabAtkins: ... and insets and position-area being set together ...
fantasai: That's a problem with the UA stylesheet
RESOLVED: Undo the previous resolution and not add position-anchor
and position-type to the position shorthand for now
CSS Overflow
============
scribe: fantasai
display: -webkit-box and line-clamp without
-webkit-box-orient: vertical
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10448
andreubotella: We had agreed to a compat workaround for line-clamp
andreubotella: If you have -webkit-box and -webkit-box-orient:
vertical
andreubotella: then either line-clamp or -webkit-line-clamp would
make it not a flex, and make it a block
andreubotella: and -webkit-line-clamp would apply
andreubotella: Issue is if you have line-clamp on block containers
andreubotella: Should display: -webkit-box + line-clamp without
box-orient, should it also trigger the behavior of
making it a block container?
andreubotella: I agree with Florian that -webkit-line-clamp only
applies with -webkit-box and
-webkit-box-orient:vertical
andreubotella: but if you have [missed]
andreubotella: if you have -webkit-box and line-clamp, is -box-orient
also required?
florian: This problem is more difficult to describe than to solve
florian: we have a weird compat hack that is required when you have
-webkit-line-clamp
florian: and is allowed for line-clamp
florian: I don't think we need to generalize
florian: we need to support the set for -webkit-line-clamp to work
florian: It needs to not work when the whole set is not there,
because the Web depends on it not triggering if any piece is
missing
florian: if you don't have the full thing, then don't blockify the
flexbox
florian: The non-hacky version doesn't apply to flexboxes
florian: not helpful, and not needed for compat, so keep it simple
florian: Already resolved that the new line-clamp works if you have
the full set of weird stuff
florian: but if you only have one of them, then we don't trigger the
magic condition, and shouldn't
florian: so proposal is no change, just clarify with a note
astearns: Proposed no change to spec, add a note mentioning the new
version doesn't interact with only part of the old hack
RESOLVED: no change to spec, add a note
CSS Easing
==========
Linear easing function requires at least two points?
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10580
TabAtkins: Reviewing the easing spec, I realized the algorithm for
parsing the list of points in linear() didn't match up
with how we do lists of points elsewhere, e.g.
radial-gradient()
TabAtkins: where we allow single points
TabAtkins: or one value with two positions
TabAtkins: I'm hoping for resolution that we change the linear()
parsing to be similar to gradient parsing
TabAtkins: Allow a single value, whether 2 positions or 1 position
TabAtkins: and do the obvious thing with that
* fantasai doesn't understand what's obvious
<TabAtkins> the "obvious" behavior is that it's a flat line at the
given value
astearns: Proposed to allow linear() easing function to have a single
stop
RESOLVED: Allow linear() to have a single stop
astearns: OpenUI meeting tomorrow. Come talk about form controls!
Received on Tuesday, 24 September 2024 23:16:05 UTC