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

[CSSWG] Minutes TPAC F2F 2020-10-20 Part I: Masonry Layout, CSS Contain [css-grid] [css-contain]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 29 Oct 2020 19:37:44 -0400
Message-ID: <CADhPm3tB_r3NRVo-orYeGVOEgKkAWvk_BT2ZGzFiW+=u0-x3LQ@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.

Masonry Layout

  - RESOLVED: Adopt Mats's draft as ED (Draft spec:
              (Issue #4650: Masonry layout)
  - Masonry will be a part of Grid 3 for now and as the definitions
      are refined the group will revisit if it should stay in Grid or
      become its own spec.

CSS Contain

  - When reviewing the proposal for content-visibility:
      hidden-matchable (Issue #5595) here were concerns about the
      behavior to stop firing a beforematch event when there's no
      response. Scoping this as an improvement on display:none made
      sense, but more discussion of the error handling is necessary
      before the group could resolve on this property.
  - RESOLVED: contain:size suppresses intrinsic aspect ratio (Issue
              #5585: contain:size needs to mention its effect on
  - RESOLVED: 'contain' keywords representing a combination of other
              keywords are defined to compute to those keywords so
              that they serialize under shortest-serialization
              principle (Issue #5511: Computed value of shortcuts)
  - RESOLVED: Close no change (Issue #5506: Combination of shorthand
              and longhand values)
  - RESOLVED: Change term "containing box" to "containment box" (Issue
              #5590: Terminology Question for css-contain)
  - RESOLVED: Add an example, but no change to normative prose (Issue
              #5550: Clarify on specifying aspect-ratio and
              contain:size on replaced elements)


Agenda: https://wiki.csswg.org/planning/tpac-2020#agenda-schedule

  Rossen Atanassov, Microsoft
  Tab Atkins-Bittner, Google
  Christian Biesinger, Google
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Elika Etemad, Invited Expert
  Brandon Ferrua, Salesforce
  Simon Fraser, Apple
  Megan Gardner, Apple
  Chris Harrelson, Google
  Daniel Hobert, Mozilla
  Brian Kardell, Igalia
  Vladimir Levin, Google
  Daniel Libby, Microsoft
  Chris Lilley, W3C
  Ting-Yu Lin, Mozilla
  Peter Linss, Invited Expert
  Myles C. Maxfield, Apple Inc.
  Alison Maher, Microsoft
  Cameron McCormack, Mozilla
  Manuel Rego, Igalia
  François REMY, Invited Expert
  Morgan Reschenberg, Mozilla
  Melanie Richards, Microsoft
  Florian Rivoal, Invited Expert
  Devin Rousso, Apple, Inc.
  Jen Simmons, Apple, Inc.
  Alan Stearns, Adobe
  Miriam Suzanne, Invited Expert
  Greg Whitworth, Salesforce

Scribe: fantasai
Scribe's scribe: TabAtkins

Masonry Layout
  github: https://github.com/w3c/csswg-drafts/issues/4650
  draft spec: https://raw.githack.com/mozilla/gecko-dev/master/layout/docs/css-grid-3/Overview.html

  Mats: I wrote the Masonry spec
  Mats: That's what we'll discuss today. I didn't prepare any
        presentation of it, but happy to answer any technical
        questions you might have
  heycam: Last time I presented the explainer based on Mats's gh issue
  heycam: Mats turned that into spec text
  heycam: Main thing we want today is, ask to put this into a draft
  heycam: and secondly, which spec does that go into
  heycam: is it Grid 3 or something else

  Rossen: Last time discussed in F2F, was at Igalia
  Rossen: Have there been any major changes since then?
  Rossen: Some of the early conversation was should it be part of grid
          or own display value.
  Rossen: Did we resolve on this? Current proposal uses grid
  * fantasai is in favor of using grid
  heycam: That hasn't changed in the spec
  heycam: Initial proposal was tied into grid and not a separate
          layout model
  heycam: Not sure if that's captured as an issue in the spec itself

  heycam: Mats, could you talk about open issues listed in the spec?
  Mats: A few issues in the spec, but mostly resolving edge cases
  Rossen: We should make the issue clear
  Rossen: Do we want to adopt this module?
  heycam: Maybe easier to resolve on that first, then file specific
          issues in GH

  iank: Unsure if there was much follow-up discussion about in grid vs
        separate display type

  TabAtkins: First, I was looking for where the proposal was and had
             trouble finding it. Have URL now
  TabAtkins: Looking in the thread, back in January we already agreed
             to adopt this proposal
  TabAtkins: editors: me, Mats, fantasai, jensimmons
  TabAtkins: We haven't done anything with it, but it seems like we
             already agreed to adopt it
  TabAtkins: so should dive into structural questions like is it grid
             or not

  jensimmons: So not even sure what we're debating, but have comments
              on whether should be part of grid display type or own
              display type
  jensimmons: Seems we haven't resolved that
  jensimmons: I think it should be part of the grid display type
  jensimmons: I really like how this proposal works. Read it again
  jensimmons: I've been thinking about it the last few months, but
              re-reading again
  jensimmons: think it would be awful lot of work to figure out making
              it not grid, in the other dimension etc.
  jensimmons: and would perhaps settle on something simplistic
  jensimmons: By making part of Grid, get an incredible body of work,
              resolved on gaps, alignment, repetition of tracks, etc.
  jensimmons: using minmax, etc.
  jensimmons: Don't know why we would want to give authors a separate
              set of tools
  jensimmons: Don't want to give authors two sets of things to learn
  jensimmons: Argument from before, word "grid" means everything lines
              up in 2D but masonry is packing
  jensimmons: but I think that's a pedantic argument
  <TabAtkins> If we did it as a separate thing, we would explicitly
              just do "exactly what Grid does" in everything that
  <TabAtkins> It would just let us get a slightly more optimized
              syntax for declaring the masonry, basically.
  jensimmons: I don't think "grid" can't encompass this
  jensimmons: I think it should be part of grid, and I really like the
              direction this is going so far

  chrishtr: I'm wondering if, related to point already made about
            relation to grid, do you have data to show about how hard
            to implement or how much it re-uses the concept of grid?
  Mats: It was pretty easy to fit into existing CSS grid code that we
  Mats: CSS grid, all the algorithms, are pretty standalone per axis
  Mats: so our code at least, just run the code for one axis
  Mats: ...
  Mats: It shouldn't be hard
  Mats: to implement for an existing CSS Grid implementation
  Mats: get a lot of free structural [?]

  iank: I think my concerns from last time still hold
  iank: Unless I'm wrong, a few things in the grid model that not in
        the masonry model
  iank: e.g. grid-area
  iank: right?
  iank: If I have grid-area: 1/2 it will ignore one of the axes
  Mats: yes
  iank: That concerns me
  iank: Also, want to do things like splitting content over two grid
  iank: can re-use concepts
  iank: but I'd be hesitant to jump the gate

  <TabAtkins> I strongly suspect we'd just literally build Masonry
              stuff into the Grid Layout Algo, even if we did Masonry
              as a separate spec.

  florian: I agree more with Jen than Ian
  florian: Almost all the tools that work in Grid also should work here
  florian: So theoretically we could have 'display: masonry' that
           either uses all the grid properties or has duplicate
           properties, but do we really need that?
  florian: Having a few properties not apply some of the time is
           really OK.
  florian: Other question, If you're trying to fall back from masonry,
           what happens?
  florian: If separate display type, you fall back to block. Grid is
           probably a better naive fallback.
  florian: But I'm leaning towards keeping it a grid variation rather
           than a separate thing
  florian: and not too concerned about Ian's concern

  fantasai: I also think it makes sense to integrate it with grid, for
            all the reasons mentioned
  fantasai: In terms of various things not applying, if we want them
            to apply I think we could combine masonry layout and grid
            layout if we wanted to
  fantasai: So if you assign it to row 1 it's in a masonry layout in
            row 1, then if you put it in row 2 it's in a separate
            masonry layout
  fantasai: Would be happy to adopt as an ED and possibly as a FPWD

  TabAtkins: Looking over the set of grid properties and whether or
             not they apply
  TabAtkins: It is absolutely the case that Masonry should be built on
             Grid algorithm
  TabAtkins: but as for property set
  TabAtkins: Most of them will have weirdness that only one of the
             pair works in masonry layout
  TabAtkins: grid-auto-rows vs grid-auto-columns
  TabAtkins: We have different flow values for masonry that do
             something similar but distinct
  TabAtkins: similar to placement properties
  TabAtkins: and then I guess row gap vs column gap work similarly
  TabAtkins: I think we should make a new display value with its own
  TabAtkins: but have a single layout algorithm
  TabAtkins: but I think we have a good opportunity to have a better
             developer-facing API instead of trying to re-use and
             half-ignore the grid properties.
  TabAtkins: But happy to be wrong, but I want to play around with
             making a new set of things just in case

  fremy: I think I agree with Tab on this mostly
  fremy: but also, want to accept as WD

  fremy: I took a look, there's like one new property,
  fremy: but no definition of what the values do
  fremy: Hesitant to accept when there's no definition
  fremy: I feel like it's not working great
  fremy: So leaning towards saying, let's make this something
         different and if in the end we find we re-use most of the
  fremy: but first let's define standalone and then later on if we
         find convergence, I think it would be more logical
  *fantasai agrees with the lack of definition for the values, wanted
            to point that out also :)

  myles: Understand idea that some grid properties won't apply to
         masonry. And in the future, some masonry properties won't
         apply to grid either
  myles: And understand argument that even if different specs, even if
         properties with different names in different specs, can share
  myles: The strongest differentiator between the two solutions is
         what the fallback is
  myles: is it better to have masonry fall back to block, or to have
         some properties that apply just to grid
  myles: If masonry layout falls back to block, much worse than
         falling back to grid with some properties ignored
  fremy: You can also fall back using @supports
  fremy: There's no good reason to limit yourself because of fallback
  <iank> ```display: grid; display: masonry;``` is what a lot of folks
         will do for this case.
  fremy: Even if the properties work similarly, not quite the same
  myles: The argument there is about what authors get by default
  myles: of course you can do anything, but what about authors who
         don't think about these cases

  TabAtkins: This is the same argument that led to multicol being
             built on block and not being a separate display type
  TabAtkins: Multicol is different of block, and having one be variant
             of other is weird
  TabAtkins: The fact that it's a "block container" is awkward, and
             I'm afraid we'll run into the same problem again
  TabAtkins: But because going to be slightly different
  TabAtkins: I suspect we'll end up writing ourselves into awkward
             corners if one different from other

  heycam: I think the comparison to multicol is interesting in another
          way because we have this precedent of having the gap
          properties, which apply to flex and grid etc.
  heycam: we gave them one name to apply across multiple layout models
  heycam: Here we have grid-specific properties, but if we considered
          masonry separate from grid
  heycam: Names of some grid properties could be changed so that the
          commonalities are more obvious

  Rossen: Want to make the discussion more action-oriented. Repeating
          previous discussions
  Rossen: Want to make sure we arrive at an actual resolution of what
          we're doing with the current spec
  Rossen: Keep separating the leading sort of differences on the table
  Rossen: Implementers and what they prefer vs. fallback mechanism vs.
          users and authors and how they will perceive from an
          ergonomic point of view

  jensimmons: The way I see it, alignment was created to go with
              flexbox and then folks realized it would be great to do
              in grid
  jensimmons: and rather than come up with new set of keywords and
              values, because they do work slightly differently
  jensimmons: but the argument that authors, it'll be too hard to say
              'grid-template-rows: masonry' and then 'grid-auto-rows:
              ??' to set the default
  jensimmons: but 'grid-auto-rows' doesn't apply
  jensimmons: I don't think authors will be confused
  jensimmons: to me it's very similar to alignment
  jensimmons: For alignment, making a separate set of syntax would
              have been much much more confusing
  jensimmons: I'm really glad they share syntax
  jensimmons: and that's my thoughts on this
  jensimmons: It doesn't seem like a completely different layout model
  jensimmons: It's an option in something bigger
  jensimmons: and that is something that looks a lot like grid
  jensimmons: Don't want duplication, new set of names and properties,
  jensimmons: Not just doing the simplest things possible in
              masonry.js, but much more powerful because built on Grid

  fantasai: My proposal is that we adopt this as an ED, and I don't
            really care if we temporarily name it css-masonry or
  fantasai: and think we should fill out the missing dfns, etc
  fantasai: and come back to this topic and decide if we want to take
            it as FPWD as either name, and let Tab try his attempt at
            different names, let Jen survey authors, and come back to
            it in a month or two
  fantasai: but adopt it for now as an official ED
  fantasai: It'll be a diff spec built on top of grid anyway, at least
            at first
  fantasai: and publish FPWD when we think we're ready to show
            something to the world
  <florian> +1
  Rossen: Internally uses grid, but also is masonry layout
  Rossen: suggest adopt as-is and then decide upon FPWD
  myles: We support progress on Masonry, and agree with fantasai,
         let's take the step we can take immediately
  Rossen: and might have other things to add to css-grid-3 also
  fantasai: We have a list of stuff that's going into Grid 3 already,
            already resolved, just needs edits ...

  RESOLVED: Adopt Mats's draft as ED

  Rossen: Mats, before you transition over, do you want to add the
          rest of the editors to this spec?
  Rossen: Jen, are you up to it?
  jensimmons: yes, I would love to! yay new company that let's me do
  heycam: Firefox has recently gained a new experiments stage in the
  heycam: can turn it on and play with it
  heycam: Settings options preferences
  heycam: I think you have to be using Nightly

  fremy: Now that we adopted the ED, that sounds cool, but would like
         to discuss content of the draft
  fremy: I'm not sure I understand the reason why we have all the
         keywords in 'masonry-auto-flow'
  fremy: But reading the algorithms section, I'm not sure what's the
  fremy: I think it would be a good idea to clarify a bit
  Rossen: We'll have the ED in the csswg repo pretty soon, hopefully
          by the end of the week
  Rossen: Once this is the case, you can go ahead and file as many
          issues as you want
  Rossen: First issue might be display type
  Rossen: as well as everything else that is currently unclear, but at
          this point spent a lot of time and other agenda items
  Rossen: so please open issues
  fremy: Sure

CSS Contain
Scribe: TabAtkins

content-visibility: hidden-matchable

  jarhar: Hi, I'm Joey. I'm working on content-visibility:
  jarhar: in parallel with HTML feature called beforematch
  jarhar: A lot of websites have sections, like wikipedia
  jarhar: and find-in-page doesn't work because it's 'display: none'
  jarhar: When searching for these things, want these things to be
  jarhar: so you would send 'content-visibility: hidden-matchable'
          which is same as 'content-visibility: hidden'
  jarhar: That'll find the element and fire the beforematch event
  jarhar: and page has ability to change the style to reveal the
  jarhar: and after one RequestAnimationFrame
  jarhar: Browser will scroll to it
  jarhar: and that's pretty much the idea
  <fremy> this is a wonderful proposal

  fantasai: I'm curious, in a lot of cases, it seems it should just
  fantasai: in the case of a details element, it should just pop open
  fantasai: I'm a little confused as to why we wouldn't want this to
            happen as well
  jarhar: Agree supporting content in details element
  jarhar: but separate from CSS property
  jarhar: For DETAILS could just say browser can change the state of
          DETAILS automatically
  jarhar: but other case don't use DETAILS element, those use
          display: none
  jarhar: so providing a different way
  jarhar: Also CSS state is maintained by page, page has opportunity
          to change itself
  jarhar: 2nd question?
  fantasai: Why wouldn't this be the default behavior for
            'content-visibility: hidden'
  jarhar: Could maybe, but some concern around privacy mitigations
  jarhar: if we fired on hidden content
  jarhar: Page, after it gets an event, the page is required to reveal
          the content or else we lock the page out of using beforematch
  jarhar: We want to prevent the page from trying to figure out what
          the user is searching for
  jarhar: and hidden-beforematch is what we're using to determine state
  jarhar: A lot of pages using 'content-visibility: hidden' already,
          and would create lockout, so not great
  jarhar: so that's why
  <bkardell> actually I will just say most of the time that is
             probably not actually what you want and if you need me to
             clarify why I can re-add to the queue

  emilio: Find-in-page already changes the selection of the document,
          and that's observable now
  emilio: so how useful is this mitigation
  jarhar: There are other ways to observe find-in-page
  jarhar: e.g. by listening to scroll events
  jarhar: in Firefox as you type it fires selection events
  jarhar: makes it easy to detect
  jarhar: in Chromium not the same
  jarhar: The selection is only fired when user dismisses find-in-page
  jarhar: so from Firefox point of view, makes sense not to have extra
          mitigation, but from our side it's needed
  <TabAtkins> So the answer to "why not give 'hidden' this behavior,
              and then add another value that has the current
              unmatchable behavior" is "there's already some legacy
              content that we'd prefer not to break if not necessary"

  emilio: Other question is, this makes find-in-page effectively
          asynchronous, which is not something that happens
  emilio: How does window.find() work and similar things?
  emilio: And why does this have to be a CSS property at all?
  emilio: I think if you find text in a 'display: none' subtree, and
          if page reacts to it
  emilio: find again or something
  emilio: idk
  jarhar: For async part, it's true, the whole flow is async
  jarhar: First we find the match, then wait for next animation frame,
          then ?, then wait for next frame, then see if it was revealed
  jarhar: That was seen to be necessary ...
  jarhar: based on page, which wasn't handling the style change
  jarhar: but for normal find-in-page use case, when not
  jarhar: still keeping it synchronous
  jarhar: Not really sure if we'll fire beforematch or window.find
  jarhar: at this point
  jarhar: Only motivation for me is to make easier to test across
          platform, but not aware of any use cases for window.find
          where you need to search hidden content

  smfr: From what I remember about content-visibility
  smfr: you select into it
  smfr: and then you have to realize all the content
  smfr: Seems like what you're proposing would bring in content during
        find, incremental improvement
  smfr: but wouldn't select content
  smfr: previously if user did select-all on the document
  smfr: because of selection, would realize content for invisible
        stuff, would be slow (?)
  smfr: but find would work in a reasonable way
  smfr: with this new thing
  smfr: But why is find special?
  smfr: What about scroll to text?
  smfr: What about search for addresses, metadata
  smfr: #target
  smfr: ...
  smfr: Why only find?
  jarhar: started with find, could expand to other use cases
  vmpstr: I think auto already supports all these things
  vmpstr: This is adjustment to 'hidden', which is not available to

  TabAtkins: You mentioned how a page doesn't respond to the format
             event by revealing something, we'll remove their ability
             to do it
  TabAtkins: Does that mean we automatically turn the thing visible,
             or what?
  jarhar: We stop firing the beforematch event
  jarhar: It's invisible
  TabAtkins: So the whole page is broken, not just one aspect of use
  jarhar: Usually there's some other way to reveal content in the
          page, just find-in-page would be broken
  TabAtkins: Before you'd walk up and try to find something auto that
             could fail open rather than failing closed
  myles: So if you catch an event and do nothing, different from not
         catching the event??
  florian: I don't think anyone said that
  florian: Question is if you don't respond to event, do you stay
           hidden or get auto-revealed
  TabAtkins: Default being to reveal
  TabAtkins: if you're responding on your own, would do
  jarhar: There's no way to possibly have the browser build the content
  jarhar: page is in control of the style, same as 'hidden'
  jarhar: CSS property says this is hidden, and until the page
          reveals, it should stay hidden
  jarhar: There's internal state in the thing, and when you search for
          it, it would unlock similar to 'auto'
  jarhar: but direction we're going, page maintains state, and it has
          to remove the CSS property
  TabAtkins: I would like to have more discussion about that
  TabAtkins: feels backwards for bad pages
  TabAtkins: broken JS

  vmpstr: Use cases we're targeting here are things like wikipedia
          collapsed sections
  vmpstr: where there are already handlers that expand the content
  vmpstr: This would add that find-in-page can expand the content
  vmpstr: if there's an error
  vmpstr: It prevents pages from figuring out what character is typed
          by incrementally constructing a DOM but never revealing that
  vmpstr: Somewhat possible now with scroll offsets, but they're
          visible always
  vmpstr: Content you're searching is visible
  vmpstr: would allow you to search content, and remains visible
  TabAtkins: Framing of strict improvement over 'display:none' makes
             me a little happier
  TabAtkins: but think there should be some discussion about whether
             that's the right way to go

  astearns: Hearing some concerns around what happens when events break
  astearns: ..
  astearns: Wonder if we should take this back to the issue and get
            more of the proposal fleshed out, and answer questions,
            then bring back on a regular call
  astearns: Any other discussion?
  fantasai: Just +1 to TabAtkins and smfr's questions and concerns

contain:size needs to mention its effect on aspect-ratio
  github: https://github.com/w3c/csswg-drafts/issues/5585

  florian: I think this was oversight in the original specification
  florian: contain:size suppresses intrinsic size, mentions width/
           height, but forgot to state that it also suppresses
           intrinsic aspect ratio
  florian: So should say so
  florian: Note this is not about the explicit 'aspect-ratio' property
  florian: but about the intrinsic one
  <fremy> lgtm
  <fantasai> lgtm
  TabAtkins: seems obvious, but this is a REC so need WG approval
  astearns: Proposed that contain:size suppresses intrinsic aspect

  dlibby: Would it be possible that 0/0 gives us the right behavior
          for this aspect ratio?
  TabAtkins: What do you mean by both zero?
  <astearns> 0/0 makes a very small box, as I recall
  fantasai: Having an aspect ratio vs having an infinite aspect ratio
            is different
  <cbiesinger> wait, I thought we decided 0/0 was infinity
  florian: We're not doing 0/0, we're doing "no aspect ratio"
  cbiesinger: What if we have 'auto' in the aspect ratio in the
  TabAtkins: You wouldn't ignore auto, but you would look up intrinsic
             aspect ratio and see that you have none

  RESOLVED: contain:size suppresses intrinsic aspect ratio

  fantasai: We get to the be the guinea pigs for modifying a Rec
  fantasai: Do we want to resolve publishing an updated Rec that
            contains a candidate change?
  chris: Doesn't it have to be published under a particular state
         to be able to modify it?
  fantasai: Only if you're adding new features, not fixing errors
  florian: There is another change we're likely to do to the same
           level of this spec
  florian: *after that*, sure, but let's resolve just once
  TabAtkins: So no publication yet, but soon. Happy to guinea pig
  florian: Another change in terminology is proposed
  florian: and another one about the definition of contain:size being
           phrased sufficiently vaguely that Mats didn't disagree with
           what we were trying to do, but wasn't sure what we were
           trying to do
  florian: and we found some potential things we might want to change
           about how it affects grid tracks
  florian: Not on agenda today, but can discuss later
  <florian> the other remaining contain issue that isn't on the agenda
            for today is

Computed value of shortcuts
  github: https://github.com/w3c/csswg-drafts/issues/5511

  TabAtkins: Not clear how serialization should work in certain cases
  TabAtkins: The 'content' value is equivalent to 'layout paint'
  TabAtkins: Should it serialize as 'content' or 'layout paint'?
  TabAtkins: Some differences between browsers
  TabAtkins: If we specify shortest serialization principle to use
             shorthand when possible
  TabAtkins: that assumes we'll always have a strict hierarchy of
             shorthand variables
  TabAtkins: if partial overlap, might have multiple shortest-possible
  TabAtkins: I think we can spec our way out of that if needed
  TabAtkins: Right now, means that the exact value is used
  TabAtkins: essentially make ...
  TabAtkins: and then go through and use shortest serialization
  TabAtkins: So I propose that we serialize the 'contain' property
             using shortest serialization
  TabAtkins: and use shorter values rather than how written

  fantasai: Worth distinguishing between specified and computed values
  fantasai: If talking about computed values, then just say that
            'content' computes to 'layout paint' and it'll serialize
            appropriately per rules
  fantasai: If talking about specified values, need to be explicit
  oriol: Generally, specified values keep keyword as specified, just
         normalize the order
  florian: Doesn't that fall out?
  TabAtkins: Then it sorts in a particular order
  fantasai: Canonical ordering in our propdef tables
  fantasai: It'll look at how you've defined the grammar, and
            serialize based on that order
  fantasai: unless you define differently
  TabAtkins: I think we need more detail in CSSOM to be clear
  TabAtkins: about computed value, sounds like we can just resolve on
             doing the normal thing and then write tests
  florian: Don't we need to say that the "compute to" each other?
  florian: Otherwise they're similar but different values

  emilio: Behavior in Firefox is because we only partially implement
          some of contain
  emilio: but generally, we should serialize the same, the computed
          and specified values
  emilio: I don't see why they should be different. Most properties
          behave like that if there's no conversion

  TabAtkins: I would prefer avoiding specified value conversion here
  TabAtkins: so let's leave that off to the side, leave it for
             computed value serialization
  TabAtkins: So I'm fine to say that shorthand values compute to
             appropriate longhands and that falls out
  astearns: So proposed resolution is that values are ...?
  fantasai: You say the shorthand computes to the longhand, and it'll
            serialize as the short one

  RESOLVED: contain keywords representing a combination of other
            keywords are defined to compute to those keywords so that
            they serialize under shortest-serialization principle

Combination of shorthand and longhand values
  github: https://github.com/w3c/csswg-drafts/issues/5506

  TabAtkins: I wrote in an example in the spec 'contain: strict style'
  TabAtkins: because strict doesn't include style
  TabAtkins: Turns out that this is not grammatical
  TabAtkins: You can't mix the shorthands with additional longhands
  TabAtkins: Question is... should it be?
  TabAtkins: Especially if the shorthand computes to longhand,
             shouldn't we allow combining them
  TabAtkins: If we do that, then how strict do we want to be about the
             combinations, do we allow 'strict paint' even though
             'paint' is already included in 'strict'
  TabAtkins: Weakly prefer allowing more combos, but browsers only
             accept the stricter syntax

  florian: My weak preference goes the other way around because it's
  florian: If from scratch, would allow the non-redundant
           combinations, but minor enough not worth fixing

  myles: Similar to what Florian just said.
  myles: Also, as far as you know, are you the only person who has
         this desire?
  TabAtkins: No idea
  myles: So probably, no change
  astearns: Until browsers get bugs from people other than Tab :)
  astearns: proposed no change
  <fantasai> +1
  astearns: Any objections?

  RESOLVED: Close no change

Terminology Question for css-contain
  github: https://github.com/w3c/csswg-drafts/issues/5590

  florian: Spun out from bigger discussion, and Mats pointed out we
           used the term 'containing box' to talk about the principal
           box of element to which containment is being applied
  florian: 'containing box' sounds a lot like 'containing block'
  florian: He proposes 'containers box', I don't love that either
  florian: but 'containment box' maybe helps?
  florian: Help avoid confusion with 'containing block'
  florian: Purely editorial
  <fantasai> +1 to changing
  florian: Used half a dozen times in this spec, not really in other
           specs (yet)
  <heycam> +1 to "containment box"

  TabAtkins: +1 to changing
  TabAtkins: "containing" is used too much across CSS
  TabAtkins: "containment box" sounds great, directly ties into
             concept, and slightly more distinct

  RESOLVED: Change term "containing box" to "containment box"

aspect-ratio and contain:size on replaced elements
Scribe: fantasai
  github: https://github.com/w3c/csswg-drafts/issues/5550

  TYLin: Issue is replaced elements with intrinsic aspect ratio
  TYLin: Specify contain:size and aspect-ratio, what size should it be?
  TYLin: Discussion in the issue, should use explicit 'aspect-ratio'
         and otherwise none
  florian: My impression is that spec was confusing because we didn't
           say anything at all, but if we clarify as we did in the
           earlier issue, do we need to say anything else to make this
  TabAtkins: It does fall out, but might be worth an example
  fantasai: I think it falls out
  TYLin: added testcase
  astearns: So proposal is to add an example
  astearns: Any objections?

  RESOLVED: Add an example, but no change to normative prose

  <br end=':15'>
Received on Thursday, 29 October 2020 23:38:43 UTC

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