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

[CSSWG] Minutes New York F2F 2022-08-02 Part I: Shared Element Transitions; Sizing [css-sizing]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 30 Aug 2022 19:32:13 -0400
Message-ID: <CADhPm3v_XckO=1h_VTget=yCmmL8VLo6doWGoA1eLTuSR86ycA@mail.gmail.com>
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.

Shared Element Transitions

  - RESOLVED: Add Shared Element Transitions as ED, with JakeA, khush,
              and TabAtkins as editors (Issue #6464: Shared Element


  - RESOLVED: 0x0 is not special with regards to ResizeObserver or
              contain-intrinsic-size (Issue #7539: How does 0x0 size
              affect last remembered size?)
  - RESOLVED: Replace ResizeObserver editors with Oriol and Emilio
  - RESOLVED: At ResizeObserver time, forget an element's last
              remembered size if it is currently out of the document
              (Issue #7532: Should last remembered size be removed if
              the element is removed from the document?)
  - RESOLVED: "last remembered size" is tracked for the two axises
              independently (in case of containment in one axis), and
              can be invoked independently (with
              contain-intrinsic-size:auto in one axis) (Issue #7529: Is
              the last remembered size recorded if there is size
              containment in a single axis?)
  - RESOLVED: Clarify that setting contain-intrinsic-size to a size
              overrides the content size, even if there is other sizing
              info such as grid column widths (Issue #7520: Clarify
              contain-intrinsic-size with multicolumn/grid)
  - RESOLVED: contain-intrinsic-size size is used as the natural sizes
              of replaced elements (but does not set the aspect ratio)
              (Issue #7519: Clarify how contain-intrinsic-size affects
              size containment algorithm)
      - TabAtkins will also add some examples to the spec
  - RESOLVED: If, when an element goes from not generating a principal
              box to generating one, it does not have
              contain-intrinsic-size:auto, forget any last remembered
              size (Issue #7527: What happens with the last remembered
              size if there is no principal box?)
  - RESOLVED: If an element doesn't have a principal box, we do not
              record a last remembered size (Issue #7527)


Agenda: https://github.com/w3c/csswg-drafts/projects/30

  Rachel Andrew, Google
  Jake Archibald, Google
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  David Baron, Google
  Oriol Brufau, Igalia
  Emilio Cobos Álvarez, Mozilla
  Yehonatan Daniv, Wix.com
  Elika J Etemad aka fantasai, Invited Expert
  Robert Flack, Google
  Simon Fraser, Apple
  Daniel Holbert, Mozilla
  Brian Kardell, Igalia
  Jonathan Kew, Mozilla
  Ian Kilpatrick, Google
  Una Kravets, Google
  Rune Lillesveen, Google
  Chris Lilley, W3C
  Vladimir Levin, Google
  Francois REMY, Invited Expert
  Florian Rivoal, Invited Expert
  Cassondra Roberts, Adobe
  Khushal Sagar, Google
  Alan Stearns, Adobe
  Miriam Suzanne, Invited Expert
  Bramus Van Damme, Google
  Lea Verou, Invited Expert

Scribe: fantasai

  Rossen: welcome to Day 2

Shared Element Transitions
  github: https://github.com/w3c/csswg-drafts/issues/6464

  vmpstr: About Shared Element Transitions, a new set of APIs we're
          working on for animations and transitions between pages
  vmpstr: single page and hopefully multipage as well
  vmpstr: Was presented in breakout session
  vmpstr: since then worked on spec text and prototype in Chromium as
  <vmpstr> https://tabatkins.github.io/specs/css-shared-element-transitions/
  vmpstr: I sent this spec draft to the list awhile back
  vmpstr: hoping that people interested would have read through the
  vmpstr: Ultimate goal for us is adopting this into the CSSWG
  vmpstr: so we wanted to use this opportunity to surface issues people
          may have
  vmpstr: and of course we're happy to answer any questions
  khush: Other goal that I'm hoping is, there are a few open issues in
         the spec and things came up while prototyping
  khush: and wanted to go over those as well
  khush: hoping we can file issues within CSSWG and go from there

  Rossen: We've had the overview in the past, there's also an open
          aggregate for this feature, which we haven't gotten to
  Rossen: Questions or comments or feedback to vlad and khushal?
  Rossen: What do they need to move forward and adopt this as part of
          the CSS charter?
  Rossen: Do we need any additional overview, refresher of the APIs?
  TabAtkins: Happy to discuss any concerns, but also if OK with making
             ED can discuss later as well

  fremy: I like the idea, just note that there is no images or diagram
         or anything in the draft
  fremy: so maybe in a future version, have a diagram of the different
         pseudo elements
  fremy: and what order they're in the page
  fremy: It's in Ch4, but a diagram would be nice
  fremy: not a blocking thing
  <Rossen> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
  Rossen: I posted also a link to the explainer, a bunch of really
          well-illustrated examples there
  fremy: Exactly what I was hoping for
  Rossen: Anything else, fremy ?
  fremy: Nope

  <JakeA> Updated developer-facing article
  JakeA: I posted a link to the developer-facing content for this,
         which includes a lot of videos and examples
  JakeA: can put it in the spec if wanted
  JakeA: I've never seen a video in a spec before!
  TabAtkins: Of all this specs, this is probably the one that would
             most benefit!

  Rossen: Any objections to adopting this work?
  fantasai: Are we adopting an ED, or are we also publishing FPWD
  TabAtkins: Still have some tweaks to make, so happy to wait until we
             get those down and then doing FPWD
  fantasai: If you have planned edits, let's do ED now and FPWD later

  RESOLVED: Add Shared Element Transitions as ED, with JakeA, khush,
            and TabAtkins as editors

  Rossen: anything else on this topic?
  <bramus> Nice!
  <vmpstr> \o/

  Scribe: emilio
  Scribe's scribe: fantasai

How does 0x0 size affect last remembered size?
  github: https://github.com/w3c/csswg-drafts/issues/7539

  oriol: Not sure if I should do a quick intro about
         contain-intrinsic-size: auto
  oriol: which is a feature that remembers the last size of an element
  oriol: and then uses that instead of collapsing the contribution of
         the contents
  oriol: when you have size containment
  oriol: This specific issue is about 0x0 size. The spec seems to
         assume that using ResizeObserver is the way to track this size
  oriol: since it mentions that the size is updated at ResizeObserver
  oriol: when implementing this I found a problem when the size is 0x0
  oriol: If you start observing an element with ResizeObserver and the
         element doesn't have a 0x0 size then you get an observation
         with the current size
  oriol: but you don't get it without it
  oriol: so the question is should we still store this size as the last
         remembered size?
  oriol: Seems like Chromium wasn't doing it
  oriol: so I don't see a reason about why special-casing it
  <dbaron> This sounds like a spec bug, and the spec should handle 0x0
           sizes just like other sizes.

  emilio: Now that you've explained this, this is only observable in
          some cases, right?
  emilio: if there's not stored size, you use 0x0
  emilio: e.g. in one axis
  oriol: when you have contain-intrinsic-size: auto you need to provide
         a fallback value
  oriol: so if you get the fallback you can detect it's not stored

  TabAtkins: This appears to be a corner case falling from the
             implementation details
  TabAtkins: so I don't mind either way

  dbaron: I think this is just a spec bug that was copied to the spec
          because it was written based on impl
  dbaron: I think 0x0 should be handled like any other size
  TabAtkins: the spec doesn't special-case this
  TabAtkins: so it's an impl bug
  oriol: yeah, this is because the ResizeObserver inits its size to 0x0
  TabAtkins: we only reuse the RO timing
  dbaron: it might be a bug in ResizeObserver

  flackr: Should we remember 0x0 only if the element was visible? This
          is intended for content-visibility
  oriol: There are some issues with storing the size
  oriol: You need to be size-contained at the time, which
         content-visibility provides in some cases
  oriol: so if you lay out the content normally without
         size-containment etc it gets saved
  flackr: If the element has never been on screen we shouldn't be
          remembering 0x0 for its size
  flackr: we'd lay out 0x0 with content-visibility: hidden
  oriol: If it has content-visibility from the beginning you don't
         store the size
  flackr: But content-visibility: auto changes dynamically when you
  oriol: If you have content-visibility: auto initially outside of the
         screen we won't store the last remembered size because it has
         size containment, we'll store it once you enter the screen
  flackr: So we won't save the size if it has size containment, so my
          concern is addressed
  flackr: ResizeObserver will still fire
  oriol: Yeah, but you won't store the last remembered size

  scribe: fantasai
  scribe's scribe: emilio

  emilio: I think I agree with dbaron, but it feels like a bug in
  emilio: IntersectionObserver does fire an observation immediately,
          regardless of whether on the screen
  emilio: so it feels to me like a bug that ResizeObserver doesn't fire
          on zero
  <flackr> +1
  emilio: and that would fix this by extension
  emilio: so I suspect we just move this to the ResizeObserver spec
  emilio: idk who's the editor of that?
  emilio: but given the precedent of IntersectionObserver always firing
          as well, it doesn't seem to me that this would be
  emilio: It seems the editors are no longer working on CSS specs
  emilio: so we need new editors for this spec?
  Rossen: Let's figure out what we want to fix and then figure out who
          is going to do it

  oriol: Proposed resolution would be that 0x0 size is not special, is
         just like any other size
  emilio: That's the current spec behavior
  Rossen: That doesn't require any change to the spec, simply requires
          implementations to fix their bugs
  emilio: But then we need to file a ResizeObserver bug
  Rossen: Yeah, but we're here to fix specs
  Rossen: Seems we don't need a spec change, if the bugs are not filed,
          please go and file them
  Rossen: Anything else on this topic?
  Rossen: Objections to resolving on 0x0 is not a special size?

  RESOLVED: 0x0 is not special with regards to ResizeObserver or

  emilio: This means we need ResizeObserver spec changes
  [discussion of possible editors]
  <fantasai> +1 to oriol

  RESOLVED: Replace ResizeObserver editors with Oriol and Emilio

Last remembered size when element is removed from the document
  github: https://github.com/w3c/csswg-drafts/issues/7532

  oriol: Spec says that when we store last remembered size, this
         survives box destruction, e.g. if you add 'display: none', the
         element will keep storing this last remembered size
  oriol: My question here is if the element is removed from the tree
  oriol: and then later re-inserted
  oriol: will it still have its last remembered size from the previous
         position in the tree?
  oriol: Should we remove the last remembered size?
  TabAtkins: I suggest whatever is easiest to implement
  TabAtkins: Rossen made the point that moving the element is done by
             removing the item ...
  TabAtkins: but if you're e.g. re-ordering a list, you might want to
             keep that info
  <iank> yeah there are lots of cases for moving things around, and it
         should keep the same last size.
  TabAtkins: The common case for removing from document and
             re-inserting is moving it around
  TabAtkins: and the common case of that is re-ordering within a list
             of similar items
  TabAtkins: so my suggestion is to keep the last remembered size until
             normal things remove it

  <ydaniv> Is removing from layout tree much different from being
           removed completely from the DOM?

  emilio: You can move things around, given how specced right now
  emilio: that means that if you move it, by the time you ??, it will
          already have a box
  emilio: When we fire ResizeObserver callback, if you move an element,
          it will have a new box and a new position in the tree
  emilio: Do we want to clear it if it's not in the document or doesn't
          have a box, i.e. when you fire the ResizeObserver event
  emilio: [missed]
  emilio: Deciding at the time of ResizeObserver doesn't prevent the
          moving case from working
  TabAtkins: If you remove it from the tree, hold onto it a bit,
             ResizeObserver fires, and then you don't have a remembered
             size at that point
  TabAtkins: when the ResizeObserver timing happens (well-defined), if
             the element is outside the document, we clear the last
             remember size
  TabAtkins: because we forget the size in some cases at ResizeObserver
  Rossen: What do we do for animations?
  TabAtkins: They're tied to the box
  TabAtkins: but these are tied specifically to the element itself
  TabAtkins: Is there an implementation concern?
  emilio: No
  TabAtkins: I could lean either way

  Rossen: Oriol, do you have an opinion
  oriol: No strong opinion, just wondering about it
  oriol: I suppose we can leave it to not do anything special
  oriol: Styles might change if you move it, or the old size might be
         strange in the new position
  oriol: but can also be fine
  oriol: so no strong opinion
  iank: The reason not to tie it to the box is that we have a lot of
        features that will switch out of the box
  iank: e.g. like when using CQ, it will be very common fro an element
        to have potentially different boxes associated

  ydaniv: contain-intrinsic-size is only interesting if you have
          content-visibility and still out of view, right?
  ydaniv: so by the time that the element is in view, it doesn't really
          play any part, right?
  oriol: It can play a part if you first lay out the element normally
         and it can store its size, and then you add
         content-visibility: hidden, then it can be in the screen and
         keep its contents, and it will use its last remembered size
  oriol: We resolved this last week
  TabAtkins: That's the exact weirdo case this is designed for

  Rossen: Ok, regardless if it's weird or not, we need to make it more
  Rossen: If we specify that it fires, the previous size
  Rossen: would there be any objections?
  TabAtkins: I think I lean very slightly towards it forgetting its size
  TabAtkins: if you're stashing away, not just doing a move
  TabAtkins: it's much less clear that the new context you're putting
             it into would be similar
  TabAtkins: so I lean towards forgetting if it's out of document

  Rossen: When you last checked this, did you check what
          implementations did?
  oriol: Chromium never seems to remove last remembered size
  oriol: and in Gecko haven't landed implementation
  flackr: For virtual scroller recycling element, I think we'd see this
          happen, and you'd want to forget the size, because you're
          changing the content before re-inserting
  Rossen: So then the proposed resolution is that the element will
          forget its last size
  TabAtkins: at normal ResizeObserver timing
  vmpstr: Then if removed and then re-added, then it's keeps its size
          if it happened before the resize observer timing
  TabAtkins: At ResizeObserver time, you also check if it is in the
  TabAtkins: if not, forget the size

  RESOLVED: At ResizeObserver time, forget an element's last remembered
            size if it is currently out of the document

Recording last remembered size recorded given single-axis containment
  github: https://github.com/w3c/csswg-drafts/issues/7529

  oriol: We are only storing last remembered size if there's not size
  oriol: However, in newer specs of css-contain, we may have size
         containment in a single axis
  oriol: what happens?
  oriol: Are we still storing both width and height of last remembered
  oriol: Do we not update last remembered size in the uncontained axis?
  oriol: Should we check at least one of the axes has size containment
         and then store both?
  oriol: How should this work exactly?
  TabAtkins: This is a very good question

  Rossen: do you have a proposal, Oriol?
  oriol: Maybe would feel more natural to me to do independently rather
         than together
  oriol: Right now Chromium stores together
  oriol: I don't have a strong opinion

  TabAtkins: I think I lean toward tracking them together, just because
             say you have a set width and you have a contained block
  TabAtkins: whatever height you want to remember, that depends on
             your width
  TabAtkins: if you end up with a different width, your height is not
             going to be very meaningful
  TabAtkins: It's weird to expect a different width also
  TabAtkins: but I feel either record both or record neither
  TabAtkins: and you need to have containment to get sizing to trigger

  flackr: I was going to suggest the opposite
  flackr: reason being that the only way that you have containment in
          one axis by it being an explicit style, whereas containment
          in both axes is because of content-visibility and being
  flackr: If the developer, while on screen, has containment in one axis
  flackr: then it should store the last remembered size when it goes
          off screen
  Rossen: That's a compelling argument
  TabAtkins: That seems reasonable
  Rossen: Sounds like we're approaching a resolution
  Rossen: Proposed resolution is that we'll keep them separate, and
          store them separate
  Rossen: Any objections?

  RESOLVED: "last remembered size" is tracked for the two axises
            independently (in case of containment in one axis), and can
            be invoked independently (with contain-intrinsic-size:auto
            in one axis)

<br end=??:20>

Clarify contain-intrinsic-size with multicolumn/grid
  github: https://github.com/w3c/csswg-drafts/issues/7520

  oriol: Spec defines contain-intrinsic-size as setting the intrinsic
         inner size
  oriol: then it says that this causes the box to size as if its
         in-flow contents ...
  oriol: but what exactly are its in-flow contents?
  oriol: multicol container or grid container
  oriol: In a multicol container, the size, it sets the width of the box
  oriol: but if you have columns or tracks, the total width of the
         column/container will be bigger than that
  oriol: in grid it's the opposite,
  oriol: but here, contain-intrinsic-size, was setting the content size
         of the grid
  oriol: ...
  oriol: I don't think it's completely clear, and I want to have a
         resolution on this

  <iank> our multi-col intrinsic sizing isn't particularly good in this
  TabAtkins: The Grid behavior is correct. Multicol is wrong
  TabAtkins: We didn't think about multicol when writing this, but
             thought about grid, and ignoring the grid stuff is the
             intended behavior
  TabAtkins: multicol should be fixed, and get a clarification in the
             spec to make extra clear
  oriol: If you specify contain-intrinsic-size: none and then in grid
         it may become greater than zero
  oriol: if you have e.g. fixed tracks
  oriol: but if you specify contain-intrinsic-size: zero
  oriol: then it will override grid template properties?
  TabAtkins: Correct
  TabAtkins: If not setting the size, you pretend no children, but grid
             is still there
  TabAtkins: but if set a size, you get that size

  fantasai: What's the behavior with multicol?
  TabAtkins: If you set contain-intrinsic-size to a length, you get
             that size, not size of columns
  fantasai: multicol columns are usually less fixed-size than fixed-size
            grid columns anyway

  Rossen: Is that the only clarification we need?
  TabAtkins: This isn't a clarification for multicol specification,
             just make clear that things such as multicol or grid don't
             do anything special, size just gets overridden
  Rossen: What's the proposed resolution?
  TabAtkins: Clarify spec that layout systems that can have sizing
             effects even with empty children don't matter,
             contain-intrinsic-size overrides all of that and sets a
             particular content size

  RESOLVED: Clarify that setting contain-intrinsic-size to a size
            overrides the content size, even if there is other sizing
            info such as grid column widths

Clarify how contain-intrinsic-size affects size containment algorithm
  github: https://github.com/w3c/csswg-drafts/issues/7519

  oriol: There's a bunch of sentences in the spec, mostly editorial,
         but the interaction of how the algo in containment spec is
         altered to take contain-intrinsic-size into account
  oriol: Mostly editorial, might not worth it to discuss now, just one
         thing I wanted to discuss is
  oriol: What about replaced elements?
  oriol: The contain spec says that when you have a replaced element
         with size containment, it behaves as if it had no natural
         aspect ratio
  oriol: and the natural size was zero
  oriol: what happens if you have contain-intrinsic-size?
  oriol: What Chromium does is that the replaced element still doesn't
         have a natural aspect ratio
  oriol: but the natural width and height are the ones specified in
  oriol: Does this make sense, or do we want some other behavior?
  TabAtkins: Having used natural width/height take from
             contain-intrinsic-size makes sense

  TabAtkins: You asked, why do first layout if going to relayout
  TabAtkins: Answer is, we want to make sure that under normal
             circumstances, width calculates before height
  TabAtkins: depending on contents, can have different effects
  TabAtkins: once have width, then calculate height
  oriol: So can we have an example of these cases in the spec?
  ACTION: TabAtkins add an example

  Rossen: Does that mean we don't need to change anything?
  TabAtkins: Oriol's second example, needs fixing in the spec
  fantasai: We want to clarify that it doesn't set the aspect-ratio
  Proposed: contain-intrinsic-size size is used as the natural sizes of
      replaced elements (but does not set the aspect ratio)
  <iank> some SVGs have this behaviour.
  TabAtkins: Yeah
  fantasai: I wanna suggest that if the aspect-ratio...
  TabAtkins: We wanna say that it doesn't have an intrinsic
             aspect-ratio, the property can affect
  fantasai: Wonder if there's utility in being able to set the
            aspect-ratio from those sizes
  fantasai: guess it has to be opt-in, we don't know if the element is
            supposed to have an aspect-ratio
  fantasai: we might want to have that ability
  <iank> if you want to opt-in to an aspect-ratio you can just set the
         aspect-ratio as well?
  fantasai: Yeah, you can do that explicitly, but it'd be easier to
            have it computed from contain-intrinsic-size
  fantasai: That's something to think about but can be addressed later
  Rossen: Objections?

  RESOLVED: contain-intrinsic-size size is used as the natural sizes of
            replaced elements (but does not set the aspect ratio)

Last remembered size if there is no principal box
  github: https://github.com/w3c/csswg-drafts/issues/7527

  oriol: In a note, when the element gets display:none, then the last
         remembered size is supposed to be preserved
  oriol: If the element doesn't have 0x0, and the box is destroyed when
         you apply 'display:none', then the last remember size will be
  oriol: if contain-intrinsic-size is auto, then need to remember this
         last size
  oriol: so we override the last size with 0x0
  oriol: and then I guess we should add the condition that the element
         at that point is not generating a principal box, shouldn't
         record the size
  TabAtkins: Correct, if it doesn't have a principal box shouldn't
             record the size
  TabAtkins: agree we should fix that
  oriol: If there's no box, shouldn't we be able to remove this last
         remembered size?
  oriol: we resolved that if it's removed from the tree, we clear the
  oriol: I guess if it doesn't have a box, the size doesn't change, but
         my understanding is even if the size doesn't change, if you
         remove contain-intrinsic-size: auto you remove last remembered
  TabAtkins: Lacking a principal box shouldn't remove the remembered
  TabAtkins: as long as you still have contain-intrinsic-size: auto

  oriol: Consider a case where we have a box, but let's say that we
         have contain-intrinsic-size: auto and we remember the size
  oriol: and then we remove contain-intrinsic-size: auto
  oriol: but box size doesn't change
  oriol: Should we remove the last remembered size?
  TabAtkins: Yes
  TabAtkins: This is not tied to ResizeObserver, it's tied to
             ResizeObserver timing
  oriol: If you lose contain-intrinsic-size: auto, but this doesn't
         trigger a size change, then we still remove the last
         remembered size
  fantasai: Okay
  oriol: In this case, we wouldn't get an observation because the size
         didn't change
  oriol: but if we can remove the size when contain-intrinsic-size:
         auto is lost, what if we first add display:none
  oriol: and then remove contain-intrinsic-size: auto
  oriol: by consistency, we need to remove the last remembered size as
  oriol: but most browsers don't recompute style during 'display: none'
  TabAtkins: So that's an implementation difficulty with matching the

  fantasai: Suppose if it's display: none you can flip things on and off
  fantasai: and when you remove 'display: none', you check if
            contain-intrinsic-size:auto is there and either clear the
            last remembered size or not?
  emilio: But you need to do that not at ResizeObserver time, but as
          soon as you get a box that is not contain-intrinsic-size:auto
  emilio: so you go display:none, at ResizeObserver time we don't know
          what to do because don't have a box
  emilio: if when you come back, you need to check
  TabAtkins: that seems fine to me
  emilio: It's weird to update this in different places
  TabAtkins: I also think it's weird to do that, but it's apparently
             problematic to do it while display is none
  TabAtkins: So we check for contain-intrinsic-size:auto when the
             element begins generating a principal box again
  TabAtkins: if it doesn't have contain-intrinsic-size:auto at that
             point, forget its last remembered size
  emilio: yeah, ok
  TabAtkins: If you're doing anything weird switching
             contain-intrinsic-size while you're display:none it's your

  emilio: Consider Container Queries, might flip things depending on
  emilio: if you're already compute Container Queries, you may need to
          create a box for a size that isn't your final one
  emilio: you may clear the remembered size,
  emilio: ...
  TabAtkins: Why would you clear it at that point
  emilio: Imagine without CQ matching, you don't have
  emilio: and once you know that you have a container of a given size,
          the box gets contain-intrinsic-size:auto
  TabAtkins: Easiest solution is to put contain-intrinsic-size:auto
             less conditionally
  emilio: Yes, I agree, but its a sketchy case
  emilio: because it depends on how precisely you implement queries
  TabAtkins: I think it's okay
  TabAtkins: It seems ok for it to be less certain
  TabAtkins: There's an easy solution: don't make it conditional in
             your styles

  TabAtkins: So proposed resolution is that we add new condition to
             forget last remembered size
  TabAtkins: which is if an element goes from not generating a
             principal box to generating one, we check cis and if it's
             not auto we forget the size
  oriol: and for storing the size the element should have a box
  Rossen: any objections to first one?

  RESOLVED: If, when an element goes from not generating a principal
            box to generating one, it does not have
            contain-intrinsic-size:auto, forget any last remembered size

  TabAtkins: If an element doesn't have a principal box, we do not
             record a principal size

  RESOLVED: If an element doesn't have a principal box, we do not
            record a last remembered size

  Rossen: Anything else on this issue?
  oriol: Nope
Received on Tuesday, 30 August 2022 23:32:55 UTC

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