W3C home > Mailing lists > Public > www-style@w3.org > November 2021

[CSSWG] Minutes Virtual TPAC Meeting 2021-11-03 Part II [css-contain] [css-transforms] [css-cascade] [highlight-api] [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 7 Nov 2021 17:08:28 -0500
Message-ID: <CADhPm3vZun494DdeTKin3AzOmVLY=zbGyJ7AvX7BAcHJsRrRjQ@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.

CSS Contain

  - RESOLVED: Elements with ancestors of content-visibility:hidden will
              have no boxes while in top layer. If removed from top
              layer they get their box back (Issue #6728: Top layer
              interactions with content-visibility: hidden)
  - RESOLVED: If the subtree of an element contains a top-layer element
              it is relevant to the user (Issue #6727: Consider top
              layer elements 'relevant to the user' for
              content-visibility: auto)
  - There is agreement that issue #4598 (Static ranges and css-contain) is
      a problem that should be solved and the solution should be as
      limited in scope as possible. The result would need to be
      observable to the author so they can respond and the current
      proposal doesn't have that observability. The discussion will
      continue on github to develop a solution.
  - RESOLVED: Accept iank's proposal (
              to guarantee full layout algorithm is always forward
              moving (Issue #6426: Ancestor Layout Loops with
              Single-Axis Containment)
  - Once the edits for issue #6426 are in the spec, a request will be
      made for FPWD of Contain 3.

CSS Transforms

  - RESOLVED: Publish WD for Transforms L2
  - RESOLVED: Add dbaron as co-editor of Transforms L1

CSS Cascade

  - RESOLVED: Add the cssom rules as .name and .namelist (Issue #6576:
              Cascade Layers need CSSOM support)
  - RESOLVED: It [revert-layer] would revert the style attribute and
              nothing else (Issue #6743: revert-layer keyword in style
  - RESOLVED: revert-layer reverts animation origin and nothing else
              (Issue #6749: revert-layer keyword in keyframes)

CSS Highlight API

  - RESOLVED: Republish Highlight API

CSS Values

  - RESOLVED: Punt attr() and toggle() to Level 5 (Issue #6753: Punt
              attr() and toggle() to Level 5)


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

Scribe: dael

CSS Contain

Top layer interactions with content-visibility: hidden
  github: https://github.com/w3c/csswg-drafts/issues/6728

  vmpstr: Content-visibility: hidden skip their contents meaning they
          don't paint. When element is in top layer changes topology of
          the tree so element is hoisted to root level
  vmpstr: Proposal is we should say it doesn't paint or generate layout
  vmpstr: Could ensure it does generate and paint, but precludes a lot
          of the optimization
  vmpstr: Another is we refuse to allow in top layer, but also seems

  smfr: The top layer spec says that top layer elements, containing
        block is initial contain block. Hoisted out of anything they're
        inside of. Why is content-visibility different?
  vmpstr: It's hoisted out of all containment. There's no way to
          optimize performance of this because then have to always keep
          rendering up to date. Not sure how common case is. I was
          hoping this could have the same rule as display:none
  smfr: That means we need a new concept in css that not containing
        block or z-order
  TabAtkins: Just say descendants don't generate boxes liked
  smfr: How does that impact rest of the dialog?
  TabAtkins: You can't focus something that doesn't have a box. That
             gets skipped
  smfr: I guess same as calling show dialog on display:none
  TabAtkins: yes

  TabAtkins: I put a comment in the issue. Except explicit difference
             in spec, anything that diverges from display:none should
             be looked at with suspicion. If there's no reason for
             difference should be same as display:none
  chrishtr: I agree with that outcomequeue
  chrishtr: Wanted to clarify tricky situation is you have an element
            skipped by virtue of having and ancestor. You have a
            skipped thing with an unskipped ancestor which is bad.
            That's why Vlad said we'd lose optimizations. If you treat
            like display:none where it has a box but if in top layer it
            becomes like display:none
  chrishtr: Consistent and simple. I don't think there's a concept to
            hoist something to the top of tree and make it visible

  Rossen: Validating an assumption, none of the content elements are
          a11y, right?
  vmpstr: Correct. Can be targets of aria label, but not exposed
  Rossen: Cool
  Rossen: Sounds like a good approach. Other thoughts?

  smfr: content-visibility: auto implications?
  vmpstr: That's the next issue
  Rossen: What is resolution?
  Rossen: Option 1?
  vmpstr: Yes

  chrishtr: If there is a content-visibility ancestor there is no box.
            It's in the top layer, but has no box
  Rossen: Prop: Elements with ancestors of content-visibility:hidden
          will have no boxes while in top layer. If removed from top
          layer they get their box back
  Rossen: Objections?
  <smfr> is the “it’s in the top layer” observable?
  Rossen: smfr does the irc question you have need to be covered?
  smfr: chrishtr said in the top layer, is that observable? If so,
        through dom?
  chrishtr: Discussed if it was observable, but not sure
  vmpstr: Right, I don't know the answer to this
  chrishtr: Might be if you try...don't know
  smfr: If it has a backdrop is that display:none too?
  vmpstr: yeah, it would be same
  chrishtr: Backdrop pseudo spec has an immediately proceeding box. And
            there's not box. Might need to clarify text but should be
  Rossen: Objections?

  RESOLVED: Elements with ancestors of content-visibility:hidden will
            have no boxes while in top layer. If removed from top layer
            they get their box back

Consider top layer elements 'relevant to the user' for
    content-visibility: auto
  github: https://github.com/w3c/csswg-drafts/issues/6727

  vmpstr: Text says we skip the contents if the element is not relevant
          to user. Defines relevant as things that have focus or
  vmpstr: Proposal is add if content-visibility:auto descendant is in
          top level it is relevant and not skipped
  chrishtr: Unskips content?
  vmpstr: Yeah, if you have offscreen content-visibility:auto it would
          appear in the top layer and the subtree would be rendered
  chrishtr: Entire tree including offscreen is relevant and not skipped
  vmpstr: Can't optimize out because have to display in top layer.
          Can't use same detection for visibility because escapes paint
  vmpstr: If it escapes top layer assume it will be visible
  chrishtr: If you have description of content-visibility:auto and you
            full screen the entire subtree will be made visible
  vmpstr: Correct
  chrishtr: Including recursive ancestors. Okay. I think it's fine
  Rossen: Any other comments?

  Rossen: What's the proposed text?
  vmpstr: If the subtree of an element contains a top-layer element it
          is relevant to the user
  Rossen: Objections?

  RESOLVED: If the subtree of an element contains a top-layer element
            it is relevant to the user

Static ranges and css-contain
  github: https://github.com/w3c/csswg-drafts/issues/4598

  dandclark: The problem that this issue is trying to address is if I
             have a highlight with a static range that crosses a
             contain boundary, if I remove a node holding one boundary
             point it causes entire highlight to not paint because it's
             not valid
  dandclark: Proposed solution is not to paint highlights that cross
             contain boundaries. Assumption is it's not a thing authors
  dandclark: My understanding is some agreement from editors. Would
             like to confirm. Also suggestion from sanket this perhaps
             have same behavior for range to make it consistent to
             prevent dev confusion
  dandclark: Proposal would be highlights backed by rangers or static
             ranges should not be painted if cross a boundary

  florian: Good summary. Initial was just static but going for
           consistency why not. This could be paint containment only,
           but given no use cases we can make it all for simplicity
  fantasai: Wanted to ask what we'd do about when highlight is similar
            to selection which frequently crosses the tree
  fantasai: Contain is used for a lot of things and not clear to me we
            want to disallow selection type highlights. Something to
  florian: Good point. Need to look into in practice where is contain
           used. It's component-y. Probably not sprinkled through
           textual elements. But you're right selections cross
  fantasai: I think you should not restrain for simplicity. I think you
            should if it's necessary for impl reasons to restrict
  <fantasai> minimal necessary restriction

  Rossen: dandclark to confirm, are you saying if I construct the range
          as you described in which case it will not be painted. From a
          dev PoV the range is observable; I can inspect it. But
          visually that is not going to paint based on circumstances
          range falls into
  Rossen: Sounds to me pretty unstable approach. To fantasai's point I
          can imagine flickering if I move the ranges. Would be great
          if there's a CSSOM or other eventing that interacts or
          rejects ranges. Strong rejection than avoid paint
  Rossen: That was it could be handled by author. It will be within the
          hands of developers
  <fantasai> +1 to Rossen's point, if we are rejecting a range it needs
             to be made obvious to the author
  <fantasai> not just a failure to paint
  Rossen: From user PoV agree with fantasai that selection today is
          doing this quite a bit
  florian: Two things we could do. 1: go back to having minimal which
           is static range only on paint containment only is invalid
  florian: On top of that we might want to add an event or observer
           that lets you discover something has happened. Hard to
           design that on the fly
  Rossen: Shouldn't. I think the feedback here is enough to go back and
          design stronger.
  florian: I think we could resolve on the type of range and
           containment, but not the whole story
  dandclark: I think we're coming to resolve on minimal restriction.
             For highlight backed by static ranges that cross a paint
             containment boundary are not painted

  Rossen: Opinions?
  florian: Support and then I think there's more to look into
  Rossen: I wouldn't object, but unsatisfying because opening a problem
          that makes the discovery of these ranges less obvious to
  florian: There is an inherit contradiction between range and
           container. Not a problem in both direction, but range that's
           outside to inside a containment boundary and then you make
           the range not meaningful you want to stop painting. There is
           a contradiction somewhere
  Rossen: Yeah. A little unsatisfying. Consider you're the dev on this
          editing app with ranges and users are complaining they don't
          see highlight. How do you chase that? If not observable it
          will be hard to fix. Even if it's legitimate.
  fantasai: Author will be able to reproduce the error if they select
            the same range because would refuse to paint. But on the
            fly can't tell via JS
  florian: Another approach, though heavy, is if an author tries to
           create a range crossing an boundary or restyles to create
           boundary we forcibly split the range to outer and inner
  Rossen: It's a little better
  Rossen: But then again not sure a misspelled word is good if you
          highlight half of it
  florian: You wouldn't highlight half, but do both with separate
           ranges. Selection use case is more likely for this. Range
           for outer part of selection and range or inner part. If you
           change inner part to no longer make sense you would no
           longer highlight inner
  Rossen: I'm with you. Feels like we're designing on the fly. Authors
          will have all kinds of collections and if you create ranges
          under you need discoverability. I think there's work to be
          done here
  Rossen: Fine with the problem and recognizing we don't want to have
          these ranges. But if we resolve on something that's strictly
          worse perhaps we should work more
  florian: I want to preserve containment invariance. But how we do it
           needs more thinking
  Rossen: What if we put it back onto GH and when you work it out,
          sounds like you're starting to come up with solutions, work
          it out and then come back
  Rossen: Sound reasonable?
  florian: Think so

  dandclark: Want a gauge on dom observably vs UA trying to be helpful
             with console warnings. Are we feeling have to be dom
  florian: I think it's not inherently wrong to want static ranges.
           Highlight can be anywhere. We should do something that lets
           author react when it happens
  Rossen: And being observable through script is key so they can take
          an action
  Rossen: Let's end here. I think there's good next steps.

  <br type=until 22 minutes after the hour>

Ancestor Layout Loops with Single-Axis Containment
  github: https://github.com/w3c/csswg-drafts/issues/6426

  miriam: It turns out this is hard. We knew that
  miriam: I tried to document 4 known instances where content changing
          size on 1 axis, generally block, has impact on available size
          for inline. So if we try and contain inline only get a loop
  miriam: Generally have a pattern where outer ancestor, element
          contained on inline axis, inside of that contents responding
          to container query
  miriam: With those three nested bits, a few of the issues are
          orthogonal writing modes. 2 other cases that are common.
          Ancestor is overflow scroll and the contents can trigger
          scrollbar on ancestor which changes inline space available
  miriam: Another is floats as they get taller or shorter how they
          stack might change
  miriam: In my first document I wrote out the brute force solutions.
          They're not ideal for users. iank's idea is better

  iank: I need to study one of these a bit more but they all fall into
        effectively we layout a child once with given space, read child
        height, and based on that give it a new available space.
  iank: Fundamentally need to make sure we never walk backwards. This
        is true today
  <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9775
  iank: I pasted in irc an example ^
  iank: Orange box and inside it has a child with an aspect-ratio.
        Consider width first, get height where we can't fix. Then
        consider second of 50px. All engines walk forwards like that.
  iank: We don't try and say now that I'm this height maybe I could fit
        back here after all

  florian: Do you mean this is the end of the line principle we don't
           need the pieces miriam highlighted or that it solves them
  iank: I think we state it and it solves them all. Orthogonal. We
        layout with one set of constraints, layout, adjust. We move
  florian: I'm a bit concerned this is different than float. We should
           avoid making css accidentally stateful
  florian: Float, ancestors are not effected by float in the same way
  florian: Roughly I feel the way miriam proposed is annoyingly
           specific but need to do it to avoid vague or stateful
  iank: I don't think it's stateful. We have a bug on orthogonal, but
        with that case to compute intrinsic size for the orthogonal
        child we need to lay it out with some available size.
  iank: We layout with that size. May effect size of the parent. Now
        when we do layout pass we give orthogonal child different
        constraints and it lays out differently
  florian: That sounds true
  iank: If you can come up with a case you think is stateful happy to
  iank: Orthogonal is hard because engines have a lot of bugs. miriam's
        example shows a bug
  florian: For scrollbar and padding do you think we can get away
           without hatchet miriam proposed?
  iank: I think so. Aspect-ratio is fine, floats is fine, I think
        classic scrollbars is fine as long as you add them in a
        particular way. We'll slowly add scrollbars to get to a state.
        I think it should be okay
  florian: I thought if you didn't have miriam's approach you would get
           a different result if you start on a 800 px window different
           result then if you start bigger and shrink
  iank: No, shouldn't be an issue. That's a browser issue and should be
  iank: If there is an ambiguous set of steps where we need more
        specific order we should do that
  iank: When forming a new context in relation to floats we had a
        specific order on how people should walk through. Pretty much
        everything else falls into that
  florian: If we go that way we can have a spec that's less magic but
           we need to be very precise so it's stable and interop
  iank: yes

  florian: Can someone implementing list the steps? Undefined would be
  iank: Depends what you mean by define
  iank: We don't have a spec for block layout but we have resolved how
        floats behave.
  iank: I can describe how this works for orthogonal children, I think
        that's well defined
  florian: My ask would be for the 4 cases miriam highlighted which I
           think are specific enough, could you either point to the
           spec language that make them non-problematic or propose
           sufficient spec text?
  iank: I can work with miriam on that

  Rossen: Sounds like we're forming consensus around going forward with
          reasoning captured in the issue by iank. Additional exercise
          to figure out where changes have to land
  Rossen: Anything else to add here? I see people on this issue chimed
  florian: Great if we can go there. The things proposed are cludges we
           thought unavoidable. If they're avoidable, great
  Rossen: In terms of solution anything else to add here?
  dholbert: I think your example with aspect-ratio is a good case for
            something that behaves like this without needing container
            queries. Good extension of that
  iank: I think I can create examples as well with time
  Rossen: We call them test cases; please add them :)

  Rossen: Let's resolve on path forward. And it'll be iank for you to
          figure out where edits should go
  Rossen: Proposal: Accept iank's proposal to guarantee full layout
          algorithm is always forward moving
  florian: Sort of important to get to this in a timely manner. This
           discussion has been going on for years in GH. If there is a
           solution, great, but I'm worried we will force other
           browsers to reverse engineer Chrome or do something else if
           we don't write it
  chrishtr: Resolution to go with iank proposal?
  iank: Write it down at least for the examples. Part of the problem is
        large parts of some algorithms are undefined. Can spec how
        things should walk forward
  chrishtr: So parts of algo that intersect need to be written
  iank: Part of issue is float not well defined. List of side effects.
        Most recent for float layout is in a GH issue but not in spec.
        Pointing to the various places we've resolved
  iank: For intrinsic size we have it written
  florian: I don't think iank proposal is not self contained enough.
           It's an approach we need to look into more details.
  Rossen: Yes. We don't have specifics
  florian: We agree to try and solve that way. And we go that way and
           we come back to resolve on details
  Rossen: Have proposed path forward. Don't have details about
          specifics, but approach makes sense. You've made your point
          and people agree.
  fantasai: We had previously declined to publish fpwd because of this
            issue. If we get to a point we're okay with the issue we
            should publish fpwd

  previous proposal: Accept iank's proposal to guarantee full layout
      algorithm is always forward moving
  Rossen: That's the proposed resolution. Objections?

  RESOLVED: Accept iank's proposal to guarantee full layout algorithm
            is always forward moving

FPWD for contain 3

  florian: We haven't done it yet, though
  iank: We've done it in that this is what chrome impl does today
  florian: Which is what I'm a bit uncomfortable with. Spec says do it,
           people have to guess
  Rossen: Let's not publish fpwd yet
  chrishtr: Once there's text in the spec that encodes the proposal in
            an algorithm is that sufficient?
  fantasai: I think we should put what iank described in contain 3. I
            think if dbaron signs off we can likely all be happy. I
            propose iank drafts text with florian help and have dbaron
  florian: Agree. Even if we state as high level principles let's do

CSS Transforms

Republish transforms
  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2021OctDec/0037.html

  dbaron: I sent a long message to group list pointing to changes and
          calling out 2 aspects
  dbaron: One was that one of the edits is only half done and I'd like
          to publish anyway because other half is complicated
  dbaron: Other is the set of changes that don't have WG resolution. I
          listed and described them.
  dbaron: Given those things in my email wanted to know if group was
          comfortable resolving to agree on the things there without
          resolutions and to publish a new WD
  <florian> looked good to me
  <astearns> +1 to publishing
  <smfr> i am fine with it
  Rossen: See a bunch of +1 to publishing
  Rossen: Objections?
  <fantasai> +1 to publishing, given smfr's approval

  RESOLVED: Publish WD for Transforms L2

  <chrishtr> congratulations!
  dbaron: Second thing is to ask to be coeditor of transforms L1. I am
          not currently
  Rossen: Ask and you shall receive

  RESOLVED: Add dbaron as co-editor of transforms L1

CSS Cascade

Cascade Layers need CSSOM support
  github: https://github.com/w3c/csswg-drafts/issues/6576
  <fantasai> https://github.com/w3c/csswg-drafts/issues/6576#issuecomment-943858864

  miriam: My understanding is we wanted 2 interfaces, one for statement
          and one for block rules
  miriam: block rule has read only attribute of the name of the layer.
          statement would have read only frozen array of strings
  miriam: Does that cover it?

  fantasai: Question was what to call them: .name or .nametext vs
  TabAtkins: .names
  fantasai: .name and .names seems tricky
  TabAtkins: yeah
  fantasai: .namelist regardless of the other being .name or .nametext
  Rossen: .name is shorter
  fantasai: Great. resolve on that
  Rossen: Objections or suggestions?

  RESOLVED: Add the cssom rules as .name and .namelist

revert-layer keyword in style attribute
  github: https://github.com/w3c/csswg-drafts/issues/6743

  miriam: Similar. Question is what does it do in context where layer
          is not clear. In this case in style attribute. What happens?
  fantasai: Had recently switched style attribute to be its own origin.
            Natural fallout is it would revert the style attribute and
            nothing else.
  Rossen: Sounds reasonable
  chrishtr: Is that option 1?
  TabAtkins: Yes
  Rossen: Other ideas or objections?

  RESOLVED: It would revert the style attribute and nothing else

  <TabAtkins> basically same as doing 'revert-layer' in unlayered
              author styles

revert-layer keyword in keyframes
  github: https://github.com/w3c/csswg-drafts/issues/6749

  fantasai: Same question. Animations are their own origin
  fantasai: We have a special rule for revert keyword that causes
            animation origin to be part of author origin. For
            revert-layer makes sense to say it reverts animation origin
            and nothing else
  Rossen: opinions? objections?
  chrishtr: This is the recommendation from xiaochengh?
  chrishtr: Seems like?
  Rossen: He said he doesn't have strong opinion
  chrishtr: Okay
  Rossen: Not hearing objections

  RESOLVED: revert-layer reverts animation origin and nothing else

CSS Highlight API


  <fantasai> https://www.w3.org/TR/css-highlight-api-1/
  fantasai: We should publish since haven't since last year. Good to
            get it published
  <fantasai> last publication December 2020
  Rossen: Sounds great
  astearns: Needs changes?
  florian: I think we had a resolution and I didn't follow up. Okay to
           double resolve

  RESOLVED: Republish highlight API

CSS Values

Punt attr() and toggle() to Level 5
  github: https://github.com/w3c/csswg-drafts/issues/6753

  fantasai: We think we should drop from L4. attr() and toggle() not
            quite solid. A bunch of the rest of the spec has been impl
  fantasai: Narrowing spec to prepare for CR
  Rossen: Objection?
  oriol: Question on this. I wonder if mix() should also be deferred.
         Added recently and issues about syntax
  fantasai: I think problem with mix() is need it to serialize
            interpolation of certain transforms. I think we should keep
            it and work out the issues
  oriol: Okay
  Rossen: Hearing no objections

  RESOLVED: Punt attr() and toggle() to Level 5
Received on Sunday, 7 November 2021 22:09:11 UTC

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