- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 1 Oct 2022 22:52:24 -0400
- To: W3C style mailing list <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 Contain
-----------
- RESOLVED: Add .containerName and .containerQuery
to container query rule API
https://github.com/w3c/csswg-drafts/issues/7190
- RESOLVED: Size contained boxes are monolithing
in L1 (no change to spec), consider relaxing
requirement to allow fragmenting content in
later levels
https://github.com/w3c/csswg-drafts/issues/5648
CSS Sizing
----------
- RESOLVED: Accept Oriol's proposal to record last remembered size
first before ResizeObserver callbacks
https://github.com/w3c/csswg-drafts/issues/7659
- RESOLVED: display:inline doesn't record a size
https://github.com/w3c/csswg-drafts/issues/7606
- Oriol to investigate summing the heights of fragments
when recording last remembered size of fragmented boxes
https://github.com/w3c/csswg-drafts/issues/7598
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Sep/0004.html
Chair: Alan Stearns
Present:
Alan Stearns
Brad Kemper
Cameron McCormack
Daniel Holbert
Daniel Libby
David Grogan
Elika J. Etemad
Ian Kirkpatrick
Miriam Suzanne
Oriol Brufau
Robert Flack
Rossen Atanassov
Tab Atkins
<RRSAgent> logging to https://www.w3.org/2022/09/07-css-irc
<RRSAgent> https://www.w3.org/2022/09/07-css-minutes.html
Scribe: fantasai
Administrivia
=============
astearns: If you're attending TPAC, in-person or remote, please sign up on
the wiki
<fantasai> https://wiki.csswg.org/planning/tpac-2022
astearns: If dialing in for an issue, letting me know which issues and when
you're available would be helpful
dholbert: What's the schedule exactly?
dholbert: joint meeting, is CSSWG the rest of the day?
astearns: yes, joint meeting is just as listed
astearns: and CSSWG the rest of Thu/Fri
astearns: [describes various timeslots etc]
astearns: When in session / when on break, is on TPAC events page
dholbert: you mean the wiki?
astearns: No, the calendar invite page
astearns: I'll update wiki with links to all the things
dholbert: thanks
Scroll Animations
=================
fantasai: Scroll Animations, most edits are in, looking for FPWD next week
<fantasai> https://drafts.csswg.org/scroll-animations-1/
<fantasai> https://github.com/w3c/csswg-drafts/pull/7710
CSS Contain
===========
.conditionText and name vs query
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7190
miriam: Currently we have .conditionText which is a single string
miriam: but includes 2 parts, a name for name of container and a
query for the conditions to match against that container
miriam: so proposal is to keep .conditionText as the entire query
miriam: but add .containerName and .containerQuery so you can get
the parts yourself
astearns: if we have the parts, why do we need the concatenation?
TabAtkins: to match the other conditional rules
heycam: it inherits from ConditionalRule, so need to say what that
property returns
astearns: Anyone with opinions?
<TabAtkins> +1
<fantasai>
heycam: makes sense to me
<TabAtkins> (and emilio already implemented it, apparently)
heycam: just question, the one that returns the expression
heycam: that doesn't include the parentheses?
miriam: that would include potentially multiple expressions
heycam: was asking about outermost parens
miriam: they're not required
miriam: no need to include them there
heycam: ah, so parens are part of the expression, not extra syntax
miriam: right
astearns: objections?
miriam: @andruud already posted a PR, so we could resolve to merge
* fantasai proposes we resolve and leave the edits to the editors
astearns: Not seeing anything about parens
miriam: if they are included, not part of the .containerQuery?
astearns: need to know whether to expect the parens
miriam: could merge the PR and add that as well
fantasai: the syntax is like for MQs
fantasai: so there are potentially a redundant set of parens around
the entire expression, but in lots of cases you'll have
something like: ( expr ) or ( expr ) ...
fantasai: any parens there should appear there
fantasai: if we want to simplify, we should do it all the way through
heycam: I guess I wasn't suggesting simplification
heycam: wasn't sure if outermost parens were part of @container rule
syntax
heycam: but sounds like it's part of the expression
astearns: so it's just as specified, with whatever parens
miriam: yes
astearns: then we can resolve to accept this PR and add these attributes
RESOLVED: Add .containerName and .containerQuery
CSS Sizing
==========
Define precise timing for setting last remembered size?
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7659
oriol: Spec says that when element needs to record last remembered
size, occurs when ?? events occur
oriol: but may be multiple observers that need to be notified
oriol: what happens if callbacks are involved?
oriol: [missed]
oriol: Implementations for the last remembered size are using an
internal ResizeObserver
oriol: it will be sorted somewhere in this list of observers
oriol: other callback observers can observe whether the last
remembered size was recorded
oriol: so webpage can notice that current impl in Blink and Firefox,
they are creating this internal ResizeObserver the first time
an element needs to update its size
oriol: then this internal ResizeObserver is preserved for other
elements that may need to update their last remembered size
oriol: even if nothing needs to be updated, the ResizeObserver is
not removed
oriol: it continues to exist
oriol: We are exposing these implementation details to web pages
oriol: My question is, are we fine with that?
oriol: This is the simplest way to implement it, but shouldn't be
hard to say that the last remembered size should be recorded
before other ResizeObserver callbacks are involved
oriol: this would be consistent with creating such observers at the
very beginning of the creation of the document
oriol: What do people think? Should we keep exposing these? Should
we define a specific order?
TabAtkins: I don't think exposing these impl details is good, and
your suggestion of timing is good
TabAtkins: would be happy to write that into the spec
iank: Just to clarify, this would be internal ResizeObserver would be
effectively inserted as first in the list of ResizeObservers or
something similar to that?
oriol: Yes, that would be the proposal
oriol: Other ResizeObservers can be created and appended, so best to
say it's first, before other ResizeObservers are involved
astearns: Only change to authors would be less info about...
oriol: Effect would be if they create their own ResizeObserver, by
the time their callback is called the last remembered size
will have been recorded
oriol: otherwise it might not be recorded yet, and might fall back
to fallback of contain-intrinsic-size
astearns: Any objections to setting this precise timing?
RESOLVED: Accept Oriol's proposal to record last remembered size
first before ResizeObserver callbacks
Last remembered size for non-atomic inlines?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7606
oriol: Spec doesn't clarify the details of what size we are recording
as the last remembered size
oriol: for non-atomic inline elements, it's hard to determine a size
oriol: ? has a size of 0x0
oriol: when recording a size, we have two reasonable ways
oriol: one is to store 0x0 as usual
oriol: this is what implementations are currently doing
oriol: might be a bit surprising since not the real size, just an
arbitrary decision
oriol: another possibility would be doing the same that we do for
display:none or when not generating a box
oriol: we are not storing the last remembered size
oriol: and we allow the element to keep a previously-set last
remembered size
oriol: I don't have a strong opinion
oriol: bit of an edge case, since inline elements do not support
size containment
oriol: so this will only matter if you are dynamically changing the
display from 'inline' to other things
oriol: but would like to clarify expected behavior
astearns: when you say Chrome and FF are treating inlines as 0x0
astearns: WebKit result is different? or don't know?
oriol: I think WK has not implemented this feature
TabAtkins: I have no attachment to either solution
TabAtkins: in absence of a reason for a change, would stick with
existing behavior
dholbert: Seems weird to have different behaviors for transiently
display:none vs display:inline
dholbert: without a good reason for 0x0 it feels arbitrary to
have those differ
dholbert: what happens if you 'display: contents' or other value?
dholbert: would be best to have a consistent answer to
"no sensible size"
TabAtkins: that's fair
astearns: other opinions?
[silence]
astearns: Proposed resolution is to not accept current behavior
in impls, but go with option 2 of not recording the size
astearns: any objections?
RESOLVED: display:inline doesn't record a size
Last remembered size when fragmented?
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7598
oriol: This is about what we do when we are in multicol or printing
oriol: elements can get fragmented
oriol: in that case, what the ResizeObserver does
oriol: is it only provides the size of the first fragment
oriol: ResizeObserver spec has plans to add sizes of more fragments
oriol: but for now implementations are only storing the first fragment
oriol: I think this is reasonable, because we cannot try to keep the
same number of fragments and size for each
oriol: because only used when size containment, and it is monolithic
in that case
oriol: so using size of first fragment seems reasonable and easiest
solution
fantasai: monolithic elements can be split across multiple cols/pages
fantasai: not convinced using the first fragment makes any sense
fantasai: probably want to use the total size of the element, not
just the first piece of it that prints on the first page
astearns: when a monolithic element gets spiced, does it have
multiple fragments? or one fragment that's been sliced
into pieces
florian: pieces and fragments are the same thing?
fantasai: it does have multiple pieces
fantasai: not sure if we clarified we call them fragments or not
fantasai: two effects of being monolithic:
fantasai: 1. we try to avoid breaking them across breaks
fantasai: 2. other is that we don't fragment the content inside them,
just graphically slice it
fantasai: still get a bunch of pieces of the element. I'd call them
fragments
fantasai: I think you want the total height of all of those pieces,
and not just the height of the first piece
oriol: if you have multiple fragments, in strange cases, each
fragment might have different width/height?
fantasai: for the height, you add them. for the width, you can just
take the width of the first one, because for a monolithic
element you won't have different widths on different pages
florian: could have different widths, if expressed as a percent?
fantasai: at that point you're doing something more sophisticated
than just graphically slicing
fantasai: so going with the first one is perfectly fine
<bradk> “Finally, if there are no possible break points below the
top of the fragmentainer, and not all the content fits,
the UA may break anywhere in order to avoid losing content
off the edge of the fragmentainer. In such cases, the UA
may also *fragment* the contents of monolithic elements
by slicing the element’s graphical representation.”
<TabAtkins> Specifically, my "strong agree" is to "do whatever
ResizeObserver currently does"; I have no opinions on
what that behavior actually *is* and *strongly* feel
we shouldn't be litigating that topic here in this issue.
astearns: might agree with Tab, that we agree ResizeObserver is not
fragment aware. that current state, taking the first
fragment might be fine for this edge case
oriol: doing something different seems tricky for an implementation
fantasai: It's not ideal, didn't we agree on fixing ResizeObserver
like 6 years ago?
astearns: probably, but work isn't done
fantasai: would've hoped the second implementation would've fixed
things instead of copying the broken stuff
florian: especially since I believe we said that dealing with
fragmentation properly was a precondition for going FPWD
* fantasai is annoyed that we don't put effort into getting
fragmentation handled
astearns: 2 ways forward
astearns: 1st option is to just have the size of the first fragment
be recorded, to match everything else
astearns: and maybe put issue in the spec that when ResizeObserver
gets fixed, we should do better here
astearns: Or we can define how we construct a size out of the
entire height and width of a sliced monolithic element
astearns: I'm lazily inclined towards the first
astearns: Oriol, you mentioned that's what Blink does atm
oriol: Yes, they take the size of the first fragment since that's
the information that ResizeObserver is providing
astearns: If we decide to go with the entire height and width of
monolithic element, is there going to be a mismatch
between last remembered size and what is available in
ResizeObserver?
oriol: At the time we record the size, the element might not be
monolithic
oriol: it might be monolithic when using
oriol: having a mismatch, it's not a big deal
oriol: the deal is having to compute the size in a new way
oriol: it could be that only ResizeObserver in the page is the
internal one
oriol: we'd have to calculate different sizes for this and for
ResizeObserver
oriol: so a bit more work, and maybe trickier
oriol: but like you said about the mismatch, it's not like the
other ResizeObservers are getting the last remembered size
oriol: they can use content-visibility to see it
oriol: but I don't think they are affected by the added complexity
in the implementation
astearns: so, can people live with doing the easy thing for now
and putting a note in that we should do better later?
<TabAtkins> +1
fantasai: brings up the question of whether we can to do something
better later?
fantasai: generally, implementers say we have to decide right now
and can't change later
fantasai: what's the point of the note if we've already decided
not to change anything in the future?
astearns: Last time we put significant effort into fragmentation
was when Bloomberg was interested
astearns: might require a non-browser team to care to improve
fantasai: if the premise is we can't change behavior, then it
doesn't matter if Bloomberg decides to fund fixing
things 2 years from now
astearns: not sure that's the case for this API. can definitely
see a path forward to not change current behavior,
but add a fragment aware portion that gives you the
same information in a fragment aware form
fantasai: we agreed to do that when we discussed it, to be fixed
for FPWD. but that's different for what we do for last
remembered size
fantasai: the point of last remembered size is that it's the size
of the element. if you size the element to that last
remembered size, it'll give a reasonable result
fantasai: if you take only the size of the first fragment, it
won't make any sense
fantasai: if you set the first fragment’s size as the height,
you'll get a very different result
fantasai: a ResizeObserver is trying to do something a bit
different, we're changing stuff and we want to know
fantasai: the point of ResizeObserver is to observe that there's
a change, not to set the size back again to the element
fantasai: but last remembered size is about setting the size back
again
fantasai: but if you chop off some large percentage of the box,
due to fragmentation, it's not really preserving its
remembered size
<bradk> +1
astearns: that convinces me
florian: me too
<TabAtkins> I'm just not happy about this diverging from ResizeObserver
<TabAtkins> They should do the same thing imo
<fantasai> They're not trying to solve the same problem
oriol: I can try to take a look at the best way to implement this,
see what different approaches there are
TabAtkins: okay with investigating, not with resolving on something
problematic
astearns: [explains]
astearns: I would like to hear what the problems of mismatching
what problem will that cause?
TabAtkins: the use case is just as valid when done manually with
ResizeObserver
TabAtkins: if we can do one way, should do it the other way
florian: I think that means we fix both this and ResizeObserver
TabAtkins: I'm fine with that, if implementable
astearns: I suggest we resolve that last remembered size, when
fragmented, returns the entire size of the unfragmented
element
astearns: and get some implementation feedback
astearns: and come back to this if the implementation feedback
raises problems
dholbert: is this specifically for monolithic elements? or anything
fragmented
oriol: anything, since last remembered size can be recorded if
element is not monolithic
dholbert: I'm concerned that the unfragmented size is not something
we generally have or would generally be useful
dholbert: if you have line height extremely tall lands on the
fragmentation point
dholbert: might have two pieces that aren't summing to the original
total
dholbert: ...
astearns: that's only the case for non-monolithic elements
dholbert: Yes, for monolithic sum of parts should equal sum of pieces
florian: similar problem figuring out the height of a thing with
getComputedStyle()
Rossen: What I wanted to ask here, does this discussion apply to
variable-size fragments or to fragmentainers that are of
regular fragment size or ???
astearns: discussed earlier, but didn't come to conclusion on the
monolithic width
Rossen: I think answer varies based on that
astearns: So if ppl have concerns we leave issue open and have Oriol
investigate what can be implemented in at least one
implementation
astearns: and see whether what he comes up with is an acceptable
path forward
oriol: that's fine
astearns: so not resolving today
contain:size shouldn't fragment as monolithic
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5648
florian: CSS Contain has several types of containment
florian: all these are establishing changes to how CSS normally
behaves, to reason about inside/outside the element,
breaking dependencies
florian: what's going on inside an element doesn't affect the outside
florian: we have size containment, the goal being when the inside
changes, the size of the element doesn't
florian: and in particular within that, we want to deal with size
changes in the case the element is fragmenting
florian: for that we have a double goal. First, regardless of how
the element fragments, its total size shouldn't change.
But more than that, the size of the fragments shouldn't
change either
florian: the spec says applying size containment causes the element
to be monolithic
florian: fantasai opened an issue to say it doesn't need to be
florian: she correctly points out size containment causes the
element to be fixed size
florian: so the total size of the element won't vary, regardless of
the breaking point
florian: but making it fixed size does not guarantee the fragment
sizes won't change
florian: so I think we need something more than merely making the
element fixed size
florian: I agree making the element monolithic is slightly overkill,
in the sense that it will guarantee that not only the total
size of the box and all fragments won't change, but it also
means the content of the element will not be fragmented and
will be sliced
florian: which isn't actually necessary in this case
florian: as long as we guarantee fragment sizes to not change, we can
still allow fragmentation of its contents
florian: fixed size fragments but content fragmenting is not a thing
we have currently
florian: preference is to stick with the existing spec requirement
that all size contained elements become monolithic, because
it fulfills the requirement and is what is implemented
florian: in some later level possibly relax this to not be monolithic
as long as you fulfil these specific constraints
florian: could do that without trouble, any implementation compliant
today would be compliant in the future
florian: but this is the last open issue on css-contain-1
florian: not sure it's so interesting to change the spec to allow
behavior nobody has at this point
<florian> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10671
fantasai: that seems very weird to me, don't think it's supposed to
do that
florian: it's interoperable
fantasai: it should be drawing the box all the way to the bottom of
the page, and not leaving a gap when it fragments
florian: the total size does stay fixed, but the size of the
fragments doesn't
fantasai: drawing the box sides all the way down to the end of the
page or column, rather than ending at the fragmentation
point, then the size of the fragments would not change
based on the fragmentation position
iank: all of the fragmentation engines for most cases, when you
fragment, you'll typically consume the remaining fragmentainer space
fantasai: that's what I was expecting to happen
florian: Safari, Chrome, and Firefox all do this
florian: three line element fragment, just tall enough to contain
the three lines, but the fragmentainer containing the
element is 2.5 lines high. So the first fragment will be
2 lines, the third fragment will be 1 line.
So there's a 0.5 line gap at the end of the first one
florian: whether that's the case or not depends on the content of
the element
florian: maybe this is an interoperable spec violation, but I'm not
convinced it's a spec violation
<astearns> The fragment heights stay the same in blink, but adjust
in gecko
fantasai: that's super weird. I wonder what's causing this to happen
<bradk> Wouldn’t box-decoration-break: clone cause the fragments to grow?
fantasai: I could understand if engines were like "oh for web compat
reasons we can't consume the extra space when fragmenting
fixed-size boxes", but even when it's auto, it's not
consuming down to the break
florian: because here we're not in a monolithic case, it doesn't want
to have one full line of content [...]
fantasai: the fact it's not working for auto is disturbing
florian: that's the current behavior, and doesn't work for contain:size
florian: I propose sticking with monolithic for level 1, then maybe
relaxing in a later level
fantasai: rather defer the issue
florian: would you object to the monolithic beahvior being allowed?
fantasai: no, I think it's fine to allow that
florian: all implementations behave this way, and you're agreeing it
should be allowed. is it worth blocking the spec to make a
change that's not testable and not invalidate any
implementation?
fantasai: I said I don't mind deferring!
RESOLVED: Not make any changes to css-contain-1, possibly relax the
monolithic requirement in later levels
Received on Sunday, 2 October 2022 02:52:42 UTC