W3C home > Mailing lists > Public > www-style@w3.org > October 2022

[CSSWG] Minutes Telecon 2022-09-07 [css-sizing] [css-contain]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 1 Oct 2022 22:52:24 -0400
Message-ID: <9f1e6833-4ba6-4971-c0fb-5c42d0f86bfa@inkedblade.net>
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

    - RESOLVED: Size contained boxes are monolithing
                in L1 (no change to spec), consider relaxing
                requirement to allow fragmenting content in
                later levels

CSS Sizing

    - RESOLVED: Accept Oriol's proposal to record last remembered size
                first before ResizeObserver callbacks
    - RESOLVED: display:inline doesn't record a size
    - Oriol to investigate summing the heights of fragments
         when recording last remembered size of fragmented boxes


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Sep/0004.html
Chair: Alan Stearns

   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


   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
   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
   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?
   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
   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
   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
   oriol: At the time we record the size, the element might not be
   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
   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
   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
   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
   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
   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
   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
   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

   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
   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
   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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC