- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 29 Oct 2020 19:37:44 -0400
- 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:
https://raw.githack.com/mozilla/gecko-dev/master/layout/docs/css-grid-3/Overview.html
)
(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
aspect-ratio)
- 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)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2020#agenda-schedule
Present:
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
today.
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
overlaps.
<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
have
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
areas
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
properties
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,
masonry-auto-flow
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
things
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
algorithm
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,
etc.
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
css-grid-3
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
things
heycam: Firefox has recently gained a new experiments stage in the
preferences
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
goal
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
------------------------------------
https://github.com/w3c/csswg-drafts/issues/5595
jarhar: Hi, I'm Joey. I'm working on content-visibility:
hidden-matchable
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
findable
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
content
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
work
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
dialog
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
synchronously
jarhar: but for normal find-in-page use case, when not
'hidden-matchable'
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
find-in-page
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
preventDefault()
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
content
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
ratio
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
property?
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
https://github.com/w3c/csswg-drafts/issues/4931#issuecomment-704676915
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
serializations
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
stable.
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
work?
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