[CSSWG] Minutes Telecon 2023-03-29 [css-cascade-6] [css-text-4] [css-view-transitions] [css-selectors]

  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 Cascade

  - RESOLVED: Accept the CSSScopeRule design, with the three changes
              noted in the thread (Issue #8626: What is the desired
              shape of CSSScopeRule?)

CSS Text

  - RESOLVED: Add break-spaces to white-space-collapse (Issue #3794:
              white-space:break-spaces is in level 3 but not level 4)
  - RESOLVED: Accept the proposed addition to the 'white-space'
              grammar [addition is <'white-space-collapse'> ||
              <'text-wrap'> || <'white-space-trim'> as values for
              white-space shorthand] (Issue #5382: Multi‑value
              `white‑space` syntax proposal)

View Transitions

  - RESOLVED: Snapshot raster is theoretically infinite. Snapshot has
              a "natural view box" of the snapshot element's border
              box (giving the natural size). Object-view-box can
              change this view box (Issue #8597: Exposing ink overflow
              rect bounds to script)
  - RESOLVED: Closed invalid, fixed by the #8597 resolution (Issue
              #8606: Clarify the size of snapshot when there are
              nested transitioning elements)

CSS Selectors

  - RESOLVED: Add :popover-open pseudoclass, undefined popoverness
              from :open (Issue #8637: Introduce `:popover` pseudo


Agenda:  https://lists.w3.org/Archives/Public/www-style/2023Mar/0013.html

  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins
  David Baron
  Oriol Brufau
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Paul Grenier
  Chris Harrelson
  Daniel Holbert
  Jonathan Kew
  Peter Linss
  Alison Maher
  Myles Maxfield
  Eric Meyer
  François Remy
  Jen Simmons
  Miriam Suzanne
  Bramus Van Damme
  Lea Verou

Chair: Rossen

Scribe: TabAtkins
Scribe's scribe: fantasai


  Rossen: Planning a separate Nesting breakout next week
  Rossen: so pushing out the Nesting issues
  Rossen: Any other changes to the agenda?
  chrishtr: Can we take issue 8637?
  <chrishtr> https://github.com/w3c/csswg-drafts/issues/8637
  <fantasai> Drop item 8?

CSS Cascade

What is the desired shape of CSSScopeRule?
  github: https://github.com/w3c/csswg-drafts/issues/8626

  miriam: Anders pushed a definition for the CSSSCopeRule, in the ED
  miriam: We didn't have a resolution on the details though, so wanted
          to clarify it's defined properly
  miriam: Main questions in the thread are terms used for the start
          and end of the scope (sometimes called "root" and "lower
          boundary"/"scoping limit")
  miriam: In thread we decided start/end were clearest terms,
          especially if we do sibling scopes - they keep making sense,
          while upper/lower don't
  miriam: Another question is what to return if one of the values
          isn't specified, we suggest null
  miriam: Final question, should the value contain the parens around
          the selectors? Propose no.
  miriam: So proposal is accept the CSSScopeRule, with the three
          conclusions outlined above.
  <fantasai> +1
  <bramus> +1
  Rossen: Looks like agreement in the thread, anyone have objections?

  RESOLVED: Accept the CSSScopeRule design, with the three changes
            noted in the thread.

CSS Text

white-space:break-spaces is in level 3 but not level 4
  github: https://github.com/w3c/csswg-drafts/issues/3794

  fantasai: Part of merging level 3 into 4 is making sure we
            integrated all the level 3 changes
  fantasai: level 4 split white-space into two longhands
  fantasai: We didn't have a place to host the break-spaces value
  fantasai: So currently we put it as a value on white-space-collapse
  <fantasai> https://drafts.csswg.org/css-text-4/#white-space-collapsing

  florian: Two positives, one negative
  florian: In terms of behavior I think this is the right longhand.
  florian: In naming, having same keyword in shorthand and longhand is
  florian: But in the context of this longhand, the name isn't
  florian: We could rename, but then it would be different keyword
           between shorthand and longhand
  florian: So I think the current spec is the right compromise, but it
           is a compromise
  <fantasai> white-space-collapse: collapse | preserve |
             preserve-breaks | preserve-spaces | break-spaces
  fantasai: Agree it's a little awkward in naming, since we only break
            spaces if we *are* wrapping, which is controlled by
            another property. It's more like
            "preserve-breakable-spaces", but that gets longer.

  Rossen: Is there anything preventing us from resolving?
  Rossen: Objections?
  fantasai: Proposed resolution is to add break-spaces to

  RESOLVED: Add break-spaces to white-space-collapse

Multi‑value `white‑space` syntax proposal
  github: https://github.com/w3c/csswg-drafts/issues/5382

  <fantasai> https://drafts.csswg.org/css-text-4/#white-space-property
  fantasai: As part of making white-space a shorthand, usually we
            allow shorthand to express all the longhands
  fantasai: Currently shorthand for three props
  fantasai: This proposal lets us use all the values of any of those
            props. Old stuff still allowed, just an extension. Luckily
            no keywords conflict.
  fantasai: It's more or less what's in the table in the issue, except
            break-spaces maps to a break-spaces value for
  fantasai: So is it okay to do this inlining?
  fantasai: Second question, for the longhands, are these the keywords
            we want? They're a little different from the keywords we
            had in white-space before, but they're clearer in what
            they mean.

  florian: As part of this rename there was the suggestion that nowrap
           doesn't have a hyphen, suggestion to fix that by having the
           longhand use 'no-wrap'.
  florian: I'd advise not to do it - having nowrap in the shorthand
           but no-wrap in the longhand would be confusing
  <lea> +1 to florian, benefits here too marginal to be worth the
  TabAtkins: I still think it would be worthwhile to have 'no-wrap' as
             an alias across all properties
  TabAtkins: but also fine not to do that
  Rossen: We can start conservative, this would be an added behavior.

  <fantasai> PROPOSAL: Adopt <'white-space-collapse'> || <'text-wrap'>
             || <'white-space-trim'> as values for white-space
  Rossen: Any objections to this white-space shorthand?

  RESOLVED: Accept the proposed addition to the 'white-space' grammar.

View Transitions

Exposing ink overflow rect bounds to script
  github: https://github.com/w3c/csswg-drafts/issues/8597

  khush: We touched on defining the bounds of the element you capture
         at the f2f
  khush: One aspect is the natural size of the image is the ink
         overflow rectangle.
  khush: This can be larger than the border box, so you use
         object-view-box to size it
  khush: This means the ink overflow rectangle is exposed to authors
  khush: But this is currently undefined, what to do?
  khush: Two options. One questions whether we expose this at all.
  khush: We can censor it in getComputedStyle() and make it !important
         in UA styles here.
  khush: This can be bad if authors want to customize the size
  khush: I haven't seen good use-cases for customizing it tho.
  khush: Suggestion from fantasai is to use the scrollable overflow
         rect instead
  khush: So the natural size authors see is scrollable overflow, but
         the browser can actually draw a larger ink overflow
  khush: I'm fine with either option from impl.
  khush: If scrollable overflow makes more sense as an author-exposed
         concept, that's fine
  khush: But if ink overflow would be useful we shouldn't shy away
         from using it

  fantasai: One, I don't think authors want to control layout of stuff
            using ink overflow rect. Kinda unpredictable.
  fantasai: And not what they're actually measuring. It's excess
            stuff, you don't really notice it's there. Serifs on font,
            blur on box-shadow, etc
  fantasai: So I don't think this is something authors will want to
  fantasai: I think we either want the scrollable overflow or the box
            fragments, and allow image to overflow the rect in some way
  fantasai: Even if we expose ink overflow in IntersectionObserve for
            security reasons, I don't think it's something people want
            to measure against
  <TabAtkins> +1 to fantasai's points

  florian: Might be confused, but thought in the general case the ink
           overflow was not only under-specified, it wasn't
           necessarily finite.
  florian: With blurs it can technically be infinite.
  fantasai: You're right, though there was a proposal to define the
            bounds that it clips. Technically what impls do today

  flackr: I think hiding the ink overflow rect is one of my proposals
  flackr: But my proposal was more that if authors set an ink
          overflow, we'd combine it with intrinsic ink overflow from
          the image, and they'd always work wrt the border box of the
  fantasai: Not sure I'm following, more concrete example?
  flackr: Say you have 100x100 box, there's 50px of shadow around it
  flackr: The thing presented to the dev is no ink overflow.
  flackr: But when we calculate the ink overflow, we'd add the 50px to
          whatever we got from the author's ink overflow rect
  Rossen: What do you mean by "presented to the dev"
  flackr: The value of object-overflow won't expose that shadow size.
  khush: I'm also having trouble understanding this - is this similar
         to what fantasai is suggesting, where you see the scrollable
         overflow as the exposed size?
  flackr: Basically the same, probably just an impl detail about how
          it works.

  fantasai: I wasn't sure if the box we should use is scrollable
            overflow or the border box, just pretty sure it shouldn't
            be the ink overflow rect
  fantasai: If we have the property controlling the clipping, we could
            have an "auto" value that computes to itself and works
            from the ink overflow

  chrishtr: I think what fantasai and flackr are saying makes sense
  chrishtr: But khushal, is there any case you've seen where authors
            need to know the ink overflow to position correctly?
  khush: No, it is handled automatically.
  khush: But if authors can set the object-view-box, they get
         information about the natural size.
  khush: Like if you say "none", then measure the box, you'll get the
         size out.
  khush: So I'm fine with saying the natural size is the border box or
         scrollable overflow, and what authors see is based on that

  khush: From what I've heard so far, I think I like the proposal of
         scrollable overflow. If we decide not to expose it and
         there's a use-case later, it'll be hard to change.
  khush: So inclined to exposing it, using the scrollable overflow.
  <TabAtkins> +1

  fantasai: So we have a replaced element. It contains an image which
            is snapshot.
  fantasai: The size of that replaced element is the size of the
            snapshot element's border box.
  fantasai: But like an SVG image, that extends past its viewbox.
  fantasai: and we're setting a property that cause the stuff outside
            its nominal size to actually paint
  khush: Yes, using object-view-box to make the sizing align, and then
         anything outside paints as ink overflow, is clipped based on
  fantasai: So on an SVG currently, say I draw a bunch of circles then
            set viewbox to 50x50
  fantasai: I'll get a 50x50 image, stuff can get drawn outside of
            that. If I put this in an <img> they'll get clipped by
  fantasai: But they're still there - if I use object-position we're
            moving that 50x50 square.
  fantasai: object-view-box refers to that viewbox declaration - I
            could change it and it would change what portion of the
            SVG is "the displayed image"
  fantasai: So we're creating a snapshot whose viewbox is the border
            box of the snapshot element
  fantasai: I think we can conceptually say the top left corner of the
            border box is the 0 coord for the image, for the purpose
            of object-view-box?
  fantasai: Then I think we have an analogous situation
  <flackr> +1 that is how I was thinking object-view-box modifications
           should work
  fantasai: I think this gets us a mental model and an API consistent
            with SVG
  khush: So you're right about the viewbox descriptions.
  khush: But the origin is based on the natural size
  khush: object-view-box says to inset from those natural bounds
  khush: We have an option to say what amount of overflow is exposed
         to authors

  flackr: I agree with fantasai's thinking about how this should work,
          that matches what I'm imagining
  flackr: the ink overflow isn't dev-exposed, just part of the object
          we've captured
  flackr: so 0,0 is at the border box corner
  flackr: Do we capture scrollable overflow even if the source element
          clipped it?
  flackr: Is it only for overflow:visible we capture?
  fantasai: No, we capture what you actually see.

  fantasai: I want to change what I'm proposing from what was in the
  fantasai: The natural image should be the full size of stuff we see.
  fantasai: But the origin of the image should be the border box
  fantasai: Similar to SVG with its viewport
  fantasai: In SVG you can draw into negative coords
  fantasai: So I'm proposing the origin of the image is the border box
            corner. Anything that overflows that is captured for the
            snapshot still gets captured.
  <flackr> +1
  fantasai: So we create a raster image whose origin is not the
            top-left corner of the image
  fantasai: So that lets us say the natural size is the border box. If
            they want to change that, they can do that (so long as
            it's captured)
  fantasai: and if they extend past what's captured they get
            transparent pixels
  fantasai: so we don't need to define the boundary of the raster,
            just that it captures at least the visible scrollable
  fantasai: everything outside is on an infinite transparent canvas
  fantasai: I think that gets us a model where author can do whatever
            they want to do

  khush: +1 fantasai's suggestion
  khush: It's funny we added object-viewbox because what is proposed
         now is what we thought about implementing internally, so we
         thought a CSS property is a better way to do it
  khush: So it sounds now we conceptually do what object-view-box is
         doing but expose it to the author
  khush: So +1

  TabAtkins: Basically what khush said
  TabAtkins: Original purpose of object-viewbox was to have natural
             size image and cutout the border box part
  TabAtkins: but if we're dealing with ink ...
  TabAtkins: So default case doesn't need 'object-view-box' at all,
             its natural viewbox matches border-box, sounds find to me
  TabAtkins: Requires minor spec edits, but good change overall
  TabAtkins: and if you want the image to look larger, then you would
             use negative coords
  TabAtkins: rather than smaller positive coords
  TabAtkins: So sounds fine, good overall

  Rossen: Can you summarize resolution?
  fantasai: proposed resolution is snapshot rasterization is
            theoretically infinite. Origin corresponds to top-left of
            border box of snapshotted element, natural size is
            width+height of border box. Author can use object-view-box
            to shift this "natural view box"
  <flackr> +1
  <ydaniv> +1
  Rossen: Comments or objections?

  RESOLVED: Snapshot raster is theoretically infinite. Snapshot has a
            "natural view box" of the snapshot element's border box
            (giving the natural size). Object-view-box can change this
            view box.

CSS Selectors

Introduce `:popover` pseudo class
  github: https://github.com/w3c/csswg-drafts/issues/8637

  chrishtr: We previous resolved to add :open/:closed to apply when
            popover is opened or closed.
  chrishtr: <details> has an open/closed concept independent of in the
            top layer, but it can also be a popover.
  chrishtr: So we need two axises...
  chrishtr: Proposal is we scope :open/:closed to an element's own
            notion of being open or closed. New pseudo :popover that's
            whether it's in the top layer or not.

  plinss: Nit: whether it's "popped over", not necessarily "in the top
  chrishtr: aAgreed

  lea: What does the popover pseudo match, exactly?
  ???: Matches popovers in the open state
  lea: So what would :popover:closed ever match?
  chrishtr: A closed <details> element that's popover
  dbaron: Idea is that it matches popovers who are currently "popover
  dbaron: Open and close are reserved for elements that have their own
  <fantasai> :pop-open / :pop-closed ?
  lea: I think open/closed is fine, but :popover sounds like it
       matches any popover element, aka with a popover attribute
       regardless of whether it's popping or not

  Rossen: So :popover-open sounds like a refinement?
  chrishtr: Yes, I think :popover-open is descriptive, a little longer
            but useful
  lea: I think we had some issues about defining top layer with CSS,
       want to make sure this doesn't become an obstacle for that
  plinss: Yes, this just reflects the popover state, not what layer
          it's in.
  <flackr> +1
  <chrishtr> +1
  Rossen: Seeing +1s in the chat. Can we resolve to add, with the
          changed name :popover-open?

  plinss: Slight hesitancy due to name getting kinda long.
  plinss: Maybe worth bikeshedding the whole feature name? "popover"
          is a little weird.
  fantasai: Suggestion :pop-open
  dbaron: popover is a weird name because calling it popup turned out
          to not be web-compatible
  Rossen: So :popover-open is proposed resolution

  RESOLVED: Add :popover-open pseudoclass, undefined popoverness from

View Transitions Continued

Clarify the size of snapshot when there are nested transitioning
  github: https://github.com/w3c/csswg-drafts/issues/8606

  khush: Previous resolution makes this much easier
  khush: Currently saying snapshot is ink overflow makes nested
         transitions hard
  khush: What if the nested element is animating itself, you don't
         want it in the snapshot.
  khush: Given previous reoslution, I think this issue is solved.
  <flackr> +1
  <TabAtkins> +1
  Rossen: Other opinions or objections to calling this fixed by 8597?

  RESOLVED: Closed invalid, fixed by the #8597 resolution.


  Rossen: Gonna end the call a few minutes early, nothing in the list
          can be addressed in this remaining minutes
  Rossen: We want to have a summer f2f
  Rossen: Expect a poll coming up today
  Rossen: Want to know who can attend physically and/or virtually and
          figure out if it's reasonable
  Rossen: Have some concrete proposals that seem doable, but need to
          know schedule and intent to attend first.

Received on Wednesday, 29 March 2023 23:52:04 UTC