Meeting minutes
present_
Administrivia
astearns: If you're attending TPAC, in-person or remote, please sign up on the wiki
https://
astearns: If dialing in for an issue, letting me know which issues and when you're available would be helpful
Scroll Animations
fantasai: Scroll Animations, most edits are in, looking for FPWD next week
Administrative (revisted)
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
CSS Contain
[css-contain-3] .conditionText and name vs query
github: https://
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 concatenated thing?
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
+1 from 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 the PR
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
<heycam> fantasai: the syntax is like for MQs
<heycam> fantasai: so there are potentially a redundant set of parens around the entire expression, but in lots of cases you'll have ( expr ) or ( expr )...
<heycam> fantasai: any parens there should appear there
<heycam> 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
RESOLUTION: Add .containerName and .containerQuery
[css-sizing] Define precise timing for setting last remembered size?
github: https://
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 rememberd 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 interal 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 impelemtn 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?
RESOLUTION: Accept Oriol's proposal to record last remembered size first before ResizeObserver callbacks
[css-sizing] Last remembered size for non-atomic inlines?
github: [css-sizing] Last remembered size for non-atomic inlines?
<astearns> github: https://
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 resonable 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?
RESOLUTION: display:inline doesn't record a size
[css-sizing] Last remembered size when fragmented?
github:
<astearns> github: https://
github: [css-sizing] Last remembered size when fragmented?
github: [css-sizing] Last remembered size when fragmented?
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
<heycam> fantasai: monolithic elements can be split across multiple cols/pages
<heycam> ... not convinced using the first fragment makes any sense
<heycam> ... probably want to use the total size of the element, not just the first piece of it that prints on the first page
<heycam> astearns: when a monolithic element gets spliced, does it have multiple fragments? or one fragment that's been sliced into pieces
<heycam> florian: pieces and fragments are the same thing?
<heycam> fantasai: it does have multiple pieces
<heycam> ... not sure if we clarified we call them fragments or not
<heycam> ... two effects of being monolithic. we try to avoid breaking them across breaks
<heycam> ... other is that we don't fragment the content inside them, just graphically slice it
<heycam> ... still get a bunch of pieces of the element. I'd call them fragments
<heycam> ... I think you want the total height of all of those pieces, and not just the height of the first piece
<heycam> oriol: if you have multiple fragments, in strange cases, each fragment might have different width/height?
<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.
<heycam> 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 wont' have different widths on different pages
<heycam> florian: could have different widths, if expressed as a percent?
<heycam> fantasai: at that point you're doing something more sophisticated than just graphically slicing
<heycam> ... so going with the first one is perfectly fine
<heycam> 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
<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. “
<heycam> oriol: doing something different seems tricky for an implementation
<heycam> fantasai: I'm good with it, but it's not ideal, didn't we agree on fixing ResizeObserver like 6 years ago?
<heycam> astearns: probably, but work isn't done
<heycam> fantasai: would've hoped the second implementation would've fixed things instead of copying the broken stuff
<heycam> florian: especially since I believe we said that dealing with fragmentation properly was a precondition for going FPWD
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 cotent-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
<heycam> fantasai: brings up the question of whether we want to do something better later?
<heycam> ... generally, people say we have to decide right now
<heycam> ... what's the point of the note if we've decided not to change anything?
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
<heycam> 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
<heycam> ... if we're open for change int he future? that's one thing
<heycam> 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
<heycam> 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
<heycam> ... the poitn of last remembered size is that it's the size of hte element. if you size the element to that size, it'll give a reasonabel result
<heycam> ... if you take the size of the first fragment, it won't make any sense
<heycam> ... if you set the first fragment size as the height, you'll get a very different result
<heycam> ... a ResizeObserver is trying to do something a bit different, we're changing stuff and we want to know
<heycam> ... but the point of ResizeObserver is to observer it, not to set the size back again to the element
<heycam> ... but last remembered size is about setting the size back again
<heycam> ... but if you chop off some percentage of it, due to fragments, it's not really preserving its remembered size
<bradk> +1
<heycam> astearns: that convinces me
<heycam> florian: me too
<TabAtkins> I'm just not happy about this diverging from ResizeObserver
<TabAtkins> They should do the same thing imo
They're not trying to solve the same problem
<heycam> 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
<Rossen-phone> a+
<Rossen-phone> a+
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-phone: 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-phone: 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
<florian> +1
oriol: that's fine
astearns: so not resolving today
[css-contain-1] contain:size shouldn't fragment as monolithic
https://
github: https://
<astearns> github: https://
<heycam> florian: CSS Contain has several types of containment
<heycam> ... all these are establishing changes to how CSS normally behaves, to reason about inside/outside the element, breaking dependencies
<heycam> ... what's going on inside an element doesn't affect the outside
<heycam> ... we have size containment, the goal being when the inside changes, the size of the element doesn't
<heycam> ... and in particular within that, we want to deal with size changes in the case the element is fragmenting
<heycam> ... for that we have a double goal. 1. regardless fo how the element fragments, its total size shouldn't change. but nore than that, the size of the fragments shouldn't change either
<heycam> ... the spec says applying size containment causes the element to be monolithic
<heycam> ... fantasai opened an issue to say it doesn't need to be
<heycam> ... she correctly poitns out size containment causes the element to be fixed size
<heycam> ... so the total size of the element won't vary, regarldess of the breaking point
<heycam> ... but making it fixed size does not guarantee the fragment sizes won't change
<heycam> ... so I think we need something more than merely making the element fixed size
<heycam> ... 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 fragmnets won't change, but it also means the content of the element will not be fragmented and will be sliced
<heycam> ... which isn't actually necessary in this case
<heycam> ... as long as we guarnatee fragment sizes to not change, we can still allow fragmentation
<heycam> ... fixed size fragments but content fragments is not a thing we have currently
<heycam> ... 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
<heycam> ... in some later level possibly relax this to not be monolithic as long as you fulfil these specific constraints
<heycam> ... could do that without trouble, any implementation compliant today would be compliant in the future
<heycam> ... but this is the last open issue on css-contain-1
<heycam> ... not sure it's so interesting to change the spec to allow behavior nobody has at this point
<florian> http://
<heycam> fantasai: that seems very weird to me
<heycam> ... don't think it's supposed to do that
<heycam> florian: it's interoperable
<heycam> fantasai: it should be drawing the box all the way to the bottom of the page, and not leaving a gap when it fragments
<heycam> florian: the total size does stay fixed, btu the size of the fragments doesn't
<heycam> 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
<heycam> iank_: all of the fragmentation engines for most cases, when you fragment, you'll typically consume the remaining fragmentainer space
<heycam> fantasai: that's what I was epxecting to happen
<heycam> florian: Safari, Chrome, and Firefox all do this
<heycam> ... 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
<heycam> ... whether that's the case or not depends on the content of the element
<heycam> ... 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
<heycam> 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?
<heycam> fantasai: I could undersatnd if engines were like "oh for web compat reasons we can't conusme the extra space", but even when it's auto, it's not consuming down to the fragmentainer
<heycam> florian: because here we're not in a monolithic case, it doesn't want to have one full line of content [...]
<heycam> fantasai: the fact it's not working for auto is disturbing
<heycam> florian: that's the current behavior, and doesn't work for contain:size
<heycam> ... I propose sticking with monolithic for level 1, then maybe relaxing in a later level
<heycam> fantasai: rather defer the issue
<heycam> florian: would you object to the monolithic beahvior being allowed?
<heycam> fantasai: no, I think it's fine to allow that
<heycam> 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?
<heycam> fantasai: I said I don't mind deferring
RESOLUTION: Not make any changes to css-contain-1, possibly relax the monolithic requirement in later levels