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

[CSSWG] Minutes Telecon 2022-03-02 [css-cascade] [css-contain-3] [css-images-5] [css-flexbox] [css-grid-3] [cssom-view]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 3 Mar 2022 06:51:15 -0500
Message-ID: <CADhPm3tNxVZDxhAs3QQCt6w8QS3Bpo4A9Ak2CzUTpdt99A2nSw@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.

Future F2F Meetings

  - Group members are asked to fill out the anonymous survey on TPAC
      attendance that was sent to the private list

CSS Cascade

  - There was no strong preference on the call for how to handle issue
      #7083 (Should 'revert' really treat animation origin as author
      origin?). Discussion will continue on github to try and
      understand the reasons behind the original decision for the
      'revert' behavior.

CSS Contain

  - RESOLVED: Keep the current syntax (Issue #7073: Move style() to the
              feature level in the grammar)

CSS Images

  - RESOLVED: We add to Images 5 these 2 properties, object-viewbox and
              object-overflow. 1 is boolean about hidden and visible
              and the other is equivalent of SVG viewbox. We would try
              and create a mapping between SVG and new property. New
              property would take inset and xywh so there's 2 ways to
              specify size (Issue #7058: Proposal to allow replaced
              elements to paint outside of their bounds)

CSS Flexbox

  - RESOLVED: Treat items as not monolithic (Issue #6855: Multi-line
              column flexbox fragmentation)
  - RESOLVED: Update fragmentation rules to flexbox to handle
              multi-line independently (Issue #6855)

CSS Grid

  - RESOLVED: Add this functionality to grid L3 (Issue #6692:
              Conditional subgrid fallback when no parent grid is


  - RESOLVED: Add isVisible to element as defined in the issue. Work
              out the corner case in a separate issue (Issue #6850:
              Proposal: add Element.isVisible[toDocument] to detect if
              element is visible in the document)


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Mar/0000.html

  Rossen Atanassov
  Tab Atkins Bittner
  David Baron
  Oriol Brufau
  Elika Etemad
  Robert Flack
  Simon Fraser
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Vladimir Levin
  Daniel Libby
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Cameron McCormack
  Alan Stearns
  Miriam Suzanne

  Adam Argyle
  Jonathan Kew
  Florian Rivoal
  Jen Simmons

Scribe: dael

Future F2F Meetings

  Rossen: It's 2 minutes past so let's get going
  Rossen: Before we get going, I want to call for any additional items
          or changes
  Rossen: Also want to use a minute and ask for you to go ahead and
          provide the anonymous signal as to if you're interested in
          joining TPAC in person, virtual, or not at all
  Rossen: Reason is we want an idea about how many folks are willing to
          do in person F2F in general. On the back we can start
          figuring out if we can start doing hybrid F2F.
  Rossen: We have one coming with TAG where it's split between 2
          different geographies and we'll find a way to sync
  Rossen: There are ways to think about how to meet in person. But want
          a pulse about if most people want to do it or not
  Rossen: Link is in the private email
  Rossen: Any extra agenda items or changes?

CSS Cascade

Should 'revert' really treat animation origin as author origin?
  github: https://github.com/w3c/csswg-drafts/issues/7083

  oriol: I can explain unless fantasai wants to explain
  fantasai: Go ahead
  oriol: The thing is that according to spec when you have revert in
         keyframes rule, that's animation origin, and revert rolls
         back. Spec says animation origin is author origin and we roll
         back to user. Only happens for revert but not revert-layer
  oriol: Having this special behavior for revert surprised me when impl
         this in webkit where revert didn't work in keyframes
  oriol: Seemed strange
  oriol: Also has performance cost. By time resolving keyframe styles
         you have base styles of the element. At least WK not tracking
         which styles are from which declarations. If there's revert I
         have to recollect all the declarations in order to have proper
  oriol: revert-layer it's just a matter of using base style so no perf
  oriol: Not just WK, check in Blink. Mentioned impl this required
         disabling and optimization.
  oriol: Wondering if could change
  oriol: Anders mentioned blink would still disable optimization due to
         em units
  oriol: No strong opinion. It surprised me and maybe more consistent
         to align. But 2 behaviors can give more flexibility to authors
  Rossen: Other opinions?

  fantasai: The main thing to think about is if you use revert in
            animation do you want it to revert to user style sheet? Or
            revert the rules for the keyframe down to just the authors
            regular rules
  fantasai: From user point of view that's the question
  fantasai: No strong opinion
  fantasai: I think original thought is revert in author stylesheet
            removes what author has done. Since animations more likely
            to be used by author having revert roll back to no author
            styling made sense at time. I think dbaron proposal for that
  Rossen: Looking to see if dbaron is here
  <dbaron> not here
  oriol: About which one can be more useful, I guess what's spec for
         revert may be a bit more useful since revert-layer...in most
         cases you can just remove the declaration. Exception is a
         fallback in a value
  Rossen: What would you prefer here? Prefer to try and resolve now?
  Rossen: Which way would you prefer to take the resolution, oriol? If
          we need to wait for dbaron I'm sure he can get back to us if
          her doesn't agree or we wait for dbaron
  oriol: I don't have much of an opinion. Opened for discussion and to
         know background. I don't have a hurry to resolve
  oriol: Maybe we can wait for dbaron
  Rossen: If there's no urgency let's continue in GH. I see dbaron so
          I'm hoping he'll engage on GH

CSS Contain

Move style() to the feature level in the grammar
  github: https://github.com/w3c/csswg-drafts/issues/7073

  miriam: When we defined both size and style functions for the
          @container rule we made them so they could wrap larger chunks
          of syntax so can have multiple style/size queries in style
  miriam: Seemed useful as syntax sugar. Since then removed size and
          left only with style and possibility of future functions
  miriam: What we're looking at is do we still want style and any
          future functions to have that sugar of allowing multiple
          queries or statements inside the function? Or restrict to
          each function is a query?
  miriam: Provided 2 examples, don't look terribly different. Lean
          slightly toward keeping flexibility but very slight. Anders
          argued to remove it

  fantasai: My thought is that it's annoying to type something over and
            over again. If you have a complex style query it would be
            annoying to type style again and again. Selectors has built
            in logic to handle multiple boolean logic. I think for
            author friendliness it's better to allow

  Rossen: If Anders is not here; anyone in favor of dropping?
  miriam: I haven't heard from anyone else in that direction
  Rossen: I'm fine with taking a resolution and revisiting in case
          Anders has a strong position and reason. From listening to WG
          seems we're leaning more to keep it
  Rossen: Other opinions?
  Rossen: Objections to keep the current behavior?

  RESOLVED: Keep the current syntax

CSS Images

Proposal to allow replaced elements to paint outside of their bounds
  github: https://github.com/w3c/csswg-drafts/issues/7058

  TabAtkins: While discussing the shared element transitions proposal a
             couple weeks ago there was some obvious need to control
             how the image snapshot sized better
  TabAtkins: The image snapshot can be sized to elements but larger to
             capture outlines or shadows. Awkward interaction with
             normal image sizing. When looking at Jake's proposal I
             realized this would be useful in general and addresses a
             gap in Paint API
  TabAtkins: General proposal is add 2 properties to object family;
             object-viewbox and object-overflow. Apply a viewbox to
             replaced content and allow it to overflow context box
  TabAtkins: Viewbox is same grammar as SVG and has same effect. Let's
             you say x/y boundary is the image boundary.
  TabAtkins: [gives example]
  TabAtkins: The natural size of image adjusts to spec width and
             height. For sizing it assumes the element transition
             snapshot is the size of element border box. If part
             outside is displayed somehow due to something like
             object-overflow you can see the rest like the shadows
  TabAtkins: Generalizing the use case, one of the use cases we wanted
             to handle in Houdini Paint API is doing custom shadows.
             Groups like Google material design did optics based
             shadowing. Because couldn't paint outside the bounds you
             had to do weird tricks to do it
  TabAtkins: This would allow you to do that exact thing as well when
             paired with object-overflow. 2 properties, hidden and
             visible. Hidden is like today
  TabAtkins: With these 2 properties would help a lot with shared
             element transitions but useful general property
  TabAtkins: fantasai provided feedback might be good to have it just
             be viewport and we upgrade the SVG to a property and do
  TabAtkins: I'm fine with that if people believe it's a good way to go
  TabAtkins: Last I checked no other feedback. Any questions or
             concerns I'd love to hear it.
  TabAtkins: Else could add to images

  smfr: Sounds reasonable. Not a huge fan of new ways to do ink
        overflow, but I see the use case
  smfr: If you do object overflow and then object-fit:cover you'll have
        bits outside that don't respond to hit testing. Might encourage
        people to make weird content for hit testing
  TabAtkins: That is true. I don't know how to address it, though. It's
             part of core functionality since shadows shouldn't hit,
             but you could also do cover. Not sure if we can solve that
             or put a note saying don't do
  smfr: Note is probably fine
  smfr: Other thought is how it interacts with aspect-ratio
  TabAtkins: Should be straight-forward. Changes element natural size
             to spec width and height and that implies aspect-ratio.
             I'm not sure if we allow width and height without
             aspect-ratio. Should have same effect. 2:1 and set square
             viewbox it's 1:1 for all other purposes
  smfr: Alright

  plinss: I thought I heard there would be viewbox property that takes
          same as SVG viewbox?
  plinss: Little concerned because SVG will look a bit like standard
          rect and it's not. Might be confusing. Maybe have it be a
          shape function?
  TabAtkins: Would that imply we want to allow other shape or is this
             just special for the property?
  plinss: Restrict to small set of shapes. rect and inset might make
  plinss: Just confusing about a bare property that takes 4 values but
          it's not the same
  <fantasai> +1 to plinss's suggestion of both rect() and inset()
  TabAtkins: I get you. And having rect and inset would be pretty
             worthwhile. If you use viewbox you have to get width and
             height but inset lets you set 20px. I think that sounds
             pretty good
  plinss: I'm not opposed to having another one to take SVG syntax for
          people who know it but we should call out
  TabAtkins: Doesn't rect take svg?
  plinss: I think it's trbl
  plinss: I don't want to rat hole, but calling out
  TabAtkins: We don't have rect, we have inset. So add a rec or some
             other name that takes xy stuff
  <fantasai> xywh()
  plinss: There is rect on clip unfortunately
  TabAtkins: Okay

  dholbert: One other concern with SVG viewbox is it's a list of 4
            numbers and doesn't allow units or %. Might make it we'd
            have to extend a fair bit. Might be worth abandoning it for
            that purpose
  TabAtkins: I would have presumed we upgrade to css units. But point

  vmpstr: I wanted to confirm how scaling works. If we scale images
          such that we squish. Squish the viewbox and overflow squishes
  TabAtkins: Right. If you scale image of SVG element using viewbox the
             whole thing squishes including the outside

  fantasai: For rect function media uses xywh. Makes it clear what each
            argument would be.
  fantasai: For SVG correspondence we've tried to create mappings. We
            should look more because if we can make them map it solves
            viewbox which has not had a mapping
  TabAtkins: I don't think there is a big problem...speaking from
             ignorance but suspect not a big problem with making this
             property override viewbox of inline SVG. Probably okay.
  TabAtkins: Should put in as an issue without effecting rest of design
  fantasai: If you put it in from an embedded SVG it should have same
  TabAtkins: Not sure about that. That would mean that applying the
             style to an image element could have distinct effects
             based on source type
  fantasai: True for width and height. If you apply sizing to root SVG
            for embedded vs inline get different
  TabAtkins: Talking embedded SVG vs png
  fantasai: No, if you have it inside the SVG file
  TabAtkins: Yes, yes. If it applies to svg-in-html it would apply to
             raw SVG as well

  fantasai: Sounds like proposal is we have these 2 properties,
            object-viewbox and object-overflow. 1 is bool about hidden
            and visible and the other is equivalent of SVG viewbox. We
            would try and create a mapping between SVG and new
            property. New property would take inset and xywh so there's
            2 ways to spec size
  fantasai: And that's in images 5
  TabAtkins: Correct
  Rossen: Other opinions?
  Rossen: Objections?

  RESOLVED: We add to Images 5 these 2 properties, object-viewbox and
            object-overflow. 1 is boolean about hidden and visible and
            the other is equivalent of SVG viewbox. We would try and
            create a mapping between SVG and new property. New property
            would take inset and xywh so there's 2 ways to specify size

CSS Flexbox

Multi-line column flexbox fragmentation
  github: https://github.com/w3c/csswg-drafts/issues/6855

  alisonmaher: This issue is how to handle fragmentation for multi-line
               column. A couple questions
  alisonmaher: First is around the spec recommendation to treat items
               as monolithic. Curious reason and if we should remove
               because otherwise items in a single line could frag
               differently than a 1 line multi-line
  alisonmaher: Also, each element has it's own stack. Implies
               multi-line column flex has it's own context except items
               are monolithic. Doesn't make sense. If we fragment
               independently the result would be closer to
               unfragmented. Firefox doesn't match for either of these
  alisonmaher: Proposal is update spec to match FF for frag multi-line
  alisonmaher: May have to reconsider break-before and -after
  alisonmaher: Curious about reasons to keep spec text as is

  TabAtkins: First, alisonmaher, this entire chapter was a best guess
             set up and we're happy to change to match impl or good
  TabAtkins: What you're saying makes sense. Pending more detailed
             review as I write this seems plausible
  fantasai: What TabAtkins said, chapter was a best guess. Multi-line
            column flexbox was the weirdest. Written the way it was
            because not sure what you're suggesting is possible. If it
            is possible to shuffle across page break, it makes more
  fantasai: As to if we should make any changes to this, we should try
            and match both good behavior and implementations. I think
            these changes make sense

  Rossen: Other opinions? fwiw I remember some reasoning behind
          monolithic items it was because simpler and we were waiting
          for an implementation and here we are
  Rossen: alisonmaher can you summarize the proposal?

  alisonmaher: Update flexbox spec to fragment multi-line columns
               independently and make items not monolithic
  Rossen: Objections to not monolithic?

  RESOLVED: Treat items as not monolithic

  Rossen: Objections to update fragmentation rules to flexbox to handle
          multi-line independent

  RESOLVED: Update fragmentation rules to flexbox to handle multi-line

CSS Grid 2

Conditional subgrid fallback when no parent grid is available
  github: https://github.com/w3c/csswg-drafts/issues/6692

  Rossen: Opened by Morton. TabAtkins can you take?
  TabAtkins: Morton is asking for...right now the rule is if you say a
             grid is subgrid in 1 axis and it doesn't have a parent it
             reverts to being an ordinary grid with no declaration on
             that axis
  TabAtkins: Can rely a bit on grid template areas but it's hacky. We
             consider this to be an error case. If you say it's a
             subgrid and not inside a grid you messed up
  TabAtkins: However, if you're writing an independent component
             reasonable to allow for that. If subgrid works in the
             parent and if not has own tracks
  TabAtkins: Upon review fantasai and I decided grammar handles this.
             You can already spec the names without sizes. If we allow
             a full track list seems reasonable for grammar and we
             ignore sizes if you're subgrid
  TabAtkins: Small wrinkle from oriol is make sure not to put
             auto-repetition is. We have a grammar term that does that
             and allows non-auto-repeat
  TabAtkins: We wouldn't put in grid 2, but reasonable for grid 3 with
             other new features. Thoughts? Objections? Okay to explore
             in grid 3?
  <miriam> +1 I would use this
  <dlibby> +1 for grid 3
  Rossen: Following your explanation it seems reasonable. Curios about
          other opinions. See IRC support
  Rossen: Sounds like something we can add to L3 of grid. Objections?

  RESOLVED: Add this functionality to grid L3

  Rossen: Means you need to make Grid 3 TabAtkins
  fantasai: It's on the to do list
  TabAtkins: Long list of features we've deferred
  fantasai: Wrapping up L1 & 2 first


Proposal: add Element.isVisible[toDocument] to detect if element is
    visible in the document
  github: https://github.com/w3c/csswg-drafts/issues/6850

  chrishtr: Brought this up a couple weeks ago. 2 use cases to add. 1)
            know if an element is visible via testing framework. Some
            links for that in the issue. 2) if content under
            content-visibility:hidden is skipped. Checking without
            forcing render
  chrishtr: Previously talked a bit about name and about mapping this
            back to use cases and prior art. Discussion about how to
            make this extensible to different definitions of visible
  chrishtr: I went back and looked at jquery visible function and
            looked at a11y tech. a11y tech looks at internal UA APIs so
            this seems not applicable.
  chrishtr: Proposal: add isVisible function with 2 default behaviors.
            Having a layer box and not being in
            content-visibility:hidden subtree. Dictionary argument to
            allow you to opt into other types that are both convenient
            and not convenient to query now in order to allow devs to

  Rossen: Looking at some of the discussions around a11y and how such a
          feature could be used. I think you're right most AT go
          through something like UI automation and not this. But what
          they go after is they look at APIs available to authors and
          then negotiate with platforms about if it makes sense for
          them to have
  Rossen: My motivation there was to see if having a property like
          isVisible won't trigger additional interpretations. Having
          had discussions with one of the ATs it doesn't look like
          they'd be too interested. I can't speak to more then them
  Rossen: Based on that I'm fine. if more requests come our way we can
          consider if we should discuss this as part of css-aam to have
          further mappings
  chrishtr: Okay. I had a similar discussion with Chrome a11y team and
            they reached same conclusion
  Rossen: Okay. Back to functionality merit, any other opinions or
          reason we want to change anything?

  chrishtr: Proposal: Add isVisible function to the element object that
            has behavior: has a box and is not skipped by
            content-visibility:hidden ancestors. Dictionary of options
            for additional types of visibility; tracksVisibilityName
            which is a bool attribute
  <heycam> "track" sounds like some checking that is ongoing
  chrishtr: Return value is also a dictionary indicating if it's a box,
            if it's skipped, and would tell you other information based
            on what's defined
  chrishtr: Most important is isVisible and we can work on dictionary
            in ED
  Rossen: Objections to accepting this?
  heycam: I think the word tracks sounds like doing something ongoing.
          Probably a better word to be found
  fantasai: Check?
  chrishtr: Check is a good word
  chrishtr: Change proposal to check. That makes sense

  flackr: Skimming proposal. If you requested a bunch of checks and
          element was skipped do we clean the style to see if other
          checks are true or false?
  chrishtr: Hm. Hadn't considered. If it doesn't have box or box is
            skipped...I guess if you spec those perhaps it should force.
  flackr: Not sure right behavior
  chrishtr: Either could ignore you or return false. Weird to say
            you're visible but not
  vmpstr: Will their return a bool of all params?
  chrishtr: Returns a dictionary.
  chrishtr: Another option would be return the first 2 and then it's
  Rossen: Would it be better to, instead of think on our feet, let's
          resolve on the bigger capability and then you can work out
          this case in a separate issue. Unless you're looking for a
          concrete resolution
  <vmpstr> +1
  <flackr> +1
  chrishtr: Makes sense to resolve on the big thing

  Rossen: Proposal Add isVisible to element as defined in the issue.
          Work out the corner case in a separate issue

  RESOLVED: Add isVisible to element as defined in the issue. Work out
            the corner case in a separate issue

  Rossen: That brings us to the top of the hour
  Rossen: Thanks for calling. Please answer the quick survey about
          showing up in person for a F2F
Received on Thursday, 3 March 2022 11:51:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:20 UTC