Meeting minutes
<smfr> i am trying to make sense of this text in cssom-view-1: “Elements and viewports have an associated scrolling box if the element or viewport has a scrolling mechanism or it overflows its content area and the used value of the overflow-x or overflow-y property is hidden. [CSS3-BOX]”
<smfr> is *not* hidden?
<liam> yeah, i think so too, for what it's worth
<smfr> and it should be “not hidden or clip” now
what's "it"?
The viewport overflows its content area?
what???
what about if it overflows the content area but not the padding box?
why would that make any difference
<liam> this shuld be two or three separate sentences
<smfr> yeah there are some missing words
<Guest60> I'm waiting to allowed in
<dlibby> we missed the last MQ discussion yesterday, can we start there?
<smfr> present_
<Rossen_> Rossen Atanassov, Microsoft
<Morgan> Morgan Reschenberg, Mozilla
<astearns> Alan Stearns, Adobe
<myles> Myles C. Maxfield, Apple Inc.
<smfr> Simon Fraser, Apple
<rego> Manuel Rego, Igalia
<cbiesinger> Christian Biesinger, Google
<plinss> Peter Linss, Invited Expert
<bkardell_> Brian Kardell, Igalia
<vmpstr> Vladimir Levin, Google
<oriol> Oriol Brufau, Igalia
<TabAtkins> Tab Atkins-Bittner, Google
<florian> Florian Rivoal, Invited Expert
<alisonmaher> Alison Maher, Microsoft
<GameMaker> Megan Gardner, Apple
<brandonferrua> Brandon Ferrua, Salesforce
<miriam> Miriam Suzanne, Invited Expert
<TYLin> Ting-Yu Lin, Mozilla
<heycam> Cameron McCormack, Mozilla
<jensimmons> Jen Simmons, Apple, Inc.
Elika Etemad aka fantasai, Invited Expert
Masonry Layout
<chrishtr> Chris Harrelson, Google
mats_: I wrote the Masonry spec
https://raw.githack.com/mozilla/gecko-dev/master/layout/docs/css-grid-3/Overview.html
mats_: That's what we'll discuss today. I didn't prepare any presentatin 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_: [garbled]
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 tpe
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.
<TabAtkins> If we did it as a separate thing, we would explicitly just do "exactly what Grid does" in everything that overlaps.
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> 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
<fremy> q!
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 implementatin
<fremy> fantasai: what's the keyword for moving yourself at the bacvk of the queue again?
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
<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.
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
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
florian: but do we really need this?
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
<TabAtkins> fantasai: I also think it makes sense to integrate it with grid, for all the reasons mentioned
<TabAtkins> fantasai: in terms of various things not applying, if we wantt hem to apply i think we could have a masonry layout and grid layout if we wanted to
<TabAtkins> 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
<TabAtkins> fantasai: Woudl 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
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 tpe
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
<heycam> github: https://github.com/w3c/csswg-drafts/issues/4650
jensimmons: but the argument that authors, it'll be too hard to say 'grid-template-rows: masonry' and then 'grid-auto-rows: before match' to set the default
jensimmons: but 'grid-auto-rows' doesn't aply
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 thought son 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
<TabAtkins> fantasai: my proposal is that we adopt this as an ED, and i dont' reallyc are if we temporarily name it css-masonry or css-grid-3
<TabAtkins> fantasai: and think we should fill out the missing dfns, etc
<TabAtkins> 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
<TabAtkins> fantasai: but adopt it for now as an official ed
<TabAtkins> fantasai: It'll be a diff spec built on top of grid anyway, at least at first
<florian> +1
fantasai: and publish FPWD when we think we're ready to show something to the world
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 ...
Resolution: 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 boss 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
What Topic
Rossen_: MQ issue didn't take up yesterday, any others we missed?
media queries for foldable and dual-screen devices
Foladable screens
Foldable screens
<astearns> github: https://github.com/w3c/csswg-drafts/issues/5621
dlibby_: This is an updated proposal for primitives we'd like to introduce for dual-screen and foldable devices
dlibby_: This one is a new media feature that describes the number of logical display regions a viewport is spanning across
dlibby_: Not th edevice itself, the relationship of the viewport to the device regions
dlibby_: The syntax is in two axises to allow for future form factors to use the same feature
dlibby_: goes hand-in-hand with the environment vars we discussed yesterday
dlibby_: Looking for opinions on this and if it's okay to add to mq5
heycam: my initial thoughts about this is whether these features are, don't wanna say complex bc the syntax isn't complex, but wondering if really there will be that many arrangements of displays that we need a feature shaped like this, as opposed to something simpler
dlibby_: in our original proposal we wer emore scoped, but that came with the baggage that as new form factors appeared, what is the syntax you would use for them?
dlibby_: So we feel this gives a more futur-eproof model, while allowing author to target today's devices
myles: Sof or width queries, for example, if you say (display-span-x: 3), is that *at least* three screens, or exactly 3?
dlibby_: Exactly, if you use the : or =. If you use < or > it gives less or more
myles: This also suggests authors might have different layouts for each arrangement - a different for 2x1 vs 1x2 vs 2x2, etc. That's the intent?
dlibby_: Yes.
<Zakim> fantasai, you wanted to react to myles
fantasai: The mq would give you an exact number, but becuse it's an integer ti can take min/max prefixes as well, so you can just opt into "2 or more displays"
<myles> fantasai: display-span-x: min(2)?
fantasai: To respond to heycam, the reason I didn't want to do simpler syntax, if someone has a 3-fold device we'd need a new MQ
(myles, no, (min-display-span-x: 2))
fantasai: The syntax for this simple case isn't any harder ot use than a more "specialized" one, but it lets us extend to a grid easily
fantasai: it doesn't let us extend to a non-grid, tho
fantasai: but i think most of the cases we'll need to worry about will be a grid or simplification of a grid
<myles> (TabAtkins: oh! are all number-taking media queries supposed to automatically get min- and max- prefixes?)
fantasai: So didn't want to box us into a corner
(yes)
florian: i think this works nicely
florian: as discussed yesterday, desktops can b emore complex arrangements
florian: but this isn't just windows that can be slightly offset from each other, it's a special display mode
florian: And I think a grid is really the only realistic mode to deal with
florian: [shows off an example]
florian: So i think we're good
smfr: Does the asnwer to these mqs depend on which screen the browser is on?
smfr: From samsung demos, browser can be on left, right, ro spanning both
smfr: So will these change?
dlibby_: Yes, if you're only on a single screen, your display-span will be 1
smfr: So not about the physical device, about the current configuration
fantasai: On that note, think we need some bikeshedding on this - we use "display" to refer to the physical device
fantasai: so like display-width vs width
fantasai: and we want consisten wording between env() and MQ
TabAtkins: note the MQ word is 'device-', not 'display-'
fantasai: Oh yeah. But the env() is using viewport, so we should be consistent between them
Rossen_: So any preferences or opinions?
TabAtkins: No strong opinion on word, but strong opinion towards naming consistency like elika said
<astearns> device-arrangement
florian: 'viewport' isn't great, it's how your viewport spans
heycam: perhaps something about presentation
fantasai: if you ahve a normal display it'll ahve a value of 1
<fantasai> TabAtkins: If your window spans a folded device, is that span 2 or span 1?
heycam: so i think like 'display-span-x' will sound like it should match if your single window spans across both segments even if it's just acting like a normal window
florian: if you're on a device with a seam between screens, then eys absolutely
florian: But on a device with a seamless pane separation, up to the UA to decide which way it goes
dlibby_: valid point, goes down to what cam was mentioning - if you're in more of a tiled mode that the device is informing the UA about
dlibby_: So possibility of a seamless device not presenting itself as multipane if you're not doing something
smfr: some implication of spanning the whole utility area
smfr: if you span both screens, but half of one screen is filled with a different app, your browser is 1.5 screens wide
smfr: So without information about what size each pane is...
TabAtkins: That's what the env() is for, reporting those pane sizes
Rossen_: So yeah in your example, the shared pane will just have a smaller viewport for the browser in that pane
florian: so my suggestion is to resolve to adopt it, bikeshed naming in github
florian: But i think we're agreeing to the proposal overall, maybe need a few details to be clearer
florian: But not hearing real pushback
<Zakim> fantasai, you wanted to comment on querying the gap
fantasai: agree with florian
fantasai: also might be useful to query info about the gap, how big it is and if there's content missing in the gap - if it doesn't paint or if it just jumps across
dlibby_: The env variables are designed let you avoid the gap, but perhaps there's a query to make it clearer up front
myles: are the env() indexed?
dlibby_: discussed that a bit yesterday, yes they are
dlibby_: based on discussion, should match the 2d grid indexing
<fantasai> The question of whether working on the "explode" model or the "window" model is probably relevant - http://fantasai.inkedblade.net/style/discuss/table-backgrounds/
Rossen_: So any objections to adopting them into MQ5?
Resolution: Adopt the multiscreen MQs into MQ5.
<br until=":15">
end
<fantasai> [side conversations about mixing environment variables and media features in comparisons as media queries]
<fantasai> [side conversation about breakout rooms]
<fantasai> [and trying to replicate hallway conversations virtually]
Contain
content-visibility: hidden-matchable
<fantasai> https://github.com/w3c/csswg-drafts/issues/5595
<fantasai> jarhar: Hi I'm Joey. I'm working on content-visibility: hiddne-matchable
<fantasai> jarhar: in parallel with HTML feature called beforematch
<fantasai> jarhar: A lot of websites have sections, like wikipedia
<fantasai> jarhar: and find-in-page doesn't work because it's 'display: none'
<fantasai> jarhar: When searching for these things, want these things to be findable
<fantasai> jarhar: so you would send 'content-visiblity: hidden-matchable' which is same as 'content-visibility: hidden'
<fantasai> jarhar: that'll find the element and fire the beforematch event
<fantasai> jarhar: and page has ability to change the style to reveal the content
<fantasai> jarhar: and after one RequestAnimationFrame
<fantasai> jarhar: browser will scroll to it
<fantasai> jarhar: and that's pretty much the idea
<fremy> this is a wonderful proposal
<florian> fantasai: I'm curious, in a lot of cases, it seems it should just work
<florian> fantasai: in the case of a details element, it should just pop open
<florian> fantasai: I'm a little confused as to why we wouldn't want this to happen as well
<fantasai> jarhar: Agree supporting content in details element
<fantasai> jarhar: but separate from CSS property
<fantasai> jarhar: for DETAILS could just say browser can change the state of DETAILS automatically
<fantasai> jarhar: but other case don't use DETAILS element, those use display: none
<fantasai> jarhar: so providing a different way
<fantasai> jarhar: also CSS state is maintained by page, page has opportunity to change itself
<fantasai> jarhar: 2nd question?
<fantasai> fantasai: why wouldn't this be the default behavior for 'content-visbility: hidden'
<fantasai> jarhar: could maybe, but some concern around privacy mitigations
<fantasai> jarhar: if we fired on hidden content
<fantasai> 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
<fantasai> jarhar: we want to prevent the page from trying to figure out what the user is searching for
<fantasai> jarhar: and hidden-beforematch is what we're using to determine state
<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 readd to the queue
<fantasai> jarhar: a lot of pages using 'content-visilibity: hidden' already, and would create lockout, so not great
<fantasai> jarhar: so that's why
<fantasai> emilio: Find-in-page already changes the selection of the document, and that's observable now
<fantasai> emilio: so how useful is this mitigation
<fantasai> jarhar: There are other ways to observe find-in-page
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"
<fantasai> jarhar: e.g. by listening to scroll events
<fantasai> jarhar: in Firefox as you type it fires selection events
<fantasai> jarhar: makes it easy to detec
<fantasai> jarhar: in Chromium not the same
<fantasai> jarhar: the selection is only fired when user dismisses find-in-page dialog
<fantasai> jarhar: so from Firefox point of view, makes sense not to have extra mitigation, but from our side it's needed
<fantasai> emilio: Other question is, this makes find-in-page effectively asynchronous, which is not something that happens
<fantasai> emilio: how does window.find() work and similar things?
<fantasai> emilio: and why does this have to be a CSS property at all?
<fantasai> emilio: I think if you find text in a 'display: none' subtree, and if page reacts to it
<fantasai> emilio: find again or something
<fantasai> emilio: idk
<fantasai> jarhar: for async part, it's true, the whole flow is async
<fantasai> jarhar: first we find the match, then wait for next animation frame, then ?, then wait for next frame, then see if it was revealed
<fantasai> jarhar: that was seen to be necessary ...j
<fantasai> jarhar: based on page, which wasn't handling the style change synchronously
<fantasai> jarhar: but for normal find-in-page use case, whene not 'hidden-matchable'
<fantasai> jarhar: still keeping it synchronous
<fantasai> jarhar: not really sure if we'll fire beforematch or window.find
<fantasai> jarhar: at this point
<fantasai> 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
<fantasai> smfr: from what I remember about content-visibility
<fantasai> smfr: you select into it
<fantasai> smfr: and then you have to realize all the content
<fantasai> smfr: seems like what you're proposing would bring in content during find, incremental improvement
<fantasai> smfr: but wouldn't select content
<fantasai> smfr: previously if user did select-all on the document
<fantasai> smfr: because of selection, would realize content for invisible stuff, woudl be slow (?)
<fantasai> smfr: but find would work in a reasonable way
<fantasai> smfr: with this new thing
<fantasai> smfr: but why is find special?
<fantasai> smfr: what about scroll to text?
<fantasai> smfr: what about seach for addresses, metadata
<fantasai> smfr: #target
<fantasai> smfr: ...
<fantasai> smfr: Why only find?
<fantasai> jarhar: started with find, could expand to other use cases
<fantasai> levin: I think auto already supports all these things
<fantasai> levin: this is adjustment to 'hidden', which is not available to find-in-page
<fantasai> TabAtkins: You mentioned how a page doesn't respond to the format event by revealing something, we'll remove their ability to do it
<fantasai> TabAtkins: does that mean we automatically turn the thing visible, or what?
<fantasai> jarhar: We stop firing the beforematch event
<fantasai> jarhar: it's invisible
<fantasai> TabAtkins: so the whole page is broken, not just one aspect of the use
<fantasai> jarhar: Usually there's some other way to reveal content in the page, just find-in-page would be broken
<fantasai> TabAtkins: Before you'd walk up and try to find something auto that could fail open rather than failing closed
<fantasai> myles: So if you catch an event and do nothing, different from not catching the event??
<fantasai> florian: I don't think anyone said that
<fantasai> florian: question is if you don't respond to event, do you stay hidden or get auto-revealed
<fantasai> TabAtkins: Default being to reveal
<fantasai> TabAtkins: if you're responding on your own, would do preventDefault()
<fantasai> jarhar: There's no way to possibly have the browser build the content
<fantasai> jarhar: page is in control of the style, same as 'hidden'
<fantasai> jarhar: CSS property says this is hidden, and until the page reveals, it should stay hidden
<fantasai> jarhar: There's internal state in the thing, and when you search for it, it would unlock similar to 'auto'
<fantasai> jarhar: but direction we're going, page maintains state, and it has to remove the CSS property
<fantasai> TabAtkins: I would like to have more discussion about that
<fantasai> TabAtkins: feels backwards for bad pages
<fantasai> TabAtkins: broken JS
<fantasai> levin: Use cases we're targetting here are things like wikipedia collapsed sections
<fantasai> levin: where there are already handlers that expand the content
<fantasai> levin: this would add that find-in-page can expand the content
<fantasai> levin: if there's an error
<fantasai> levin: It prevents pages from figuring out what character is type by incrementally constructing a DOM but never revealing that content
<fantasai> levin: somewhat possible now with scroll offsets, but they're visible always
<fantasai> levin: Content you're searching is visible
<fantasai> levin: would allow you to search content, and remains visible
<vmpstr> S/levin/vmpstr/
<fantasai> TabAtkins: Framing of strict improvement over 'display:none' makes me a little happier
<fantasai> TabAtkins: but think there should be some discussion about whether that's the right way to go
<fantasai> +1 to Tab's concern
<fantasai> and to smfr's
<fantasai> astearns: Hearing some concerns around what happens when events break
<fantasai> astearns: ..
<fantasai> 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
<fantasai> astearns: Any other discussion?
<fantasai> fantasai: Just +1 to TabAtkins and smfr's questions and conerns
contain: size and aspect-ratio
github: https://github.com/w3c/csswg-drafts/issues/5585
<fantasai> florian: I think this was oversight in the original specification
<fantasai> florian: contain:size suppresses intrinsic size, mentions width/height, but forgot to state that it also suppresses intrinsic aspect ratio
<fantasai> florian: So should say so
<fantasai> florian: Note this is not about the explicit 'aspect-ratio' property
<fantasai> florian: but about the intrinsic one
<fremy> lgtm
<fantasai> lgtm
<fantasai> TabAtkins: seems obvious, but this is a REC so need WG approval
<fantasai> astearns: proposed that contain:size suppresses intrinsic aspect ratio
<fantasai> dlibby_: Would it be possible that 0/0 gives us the right behavior for this aspect ratio?
<fantasai> TabAtkins: what do you mean by both zero?
<fantasai> fantasai: having an aspect ratio vs having an infinite aspect ratio is different
<fantasai> florian: We're not doing 0/0, we're doing "no aspect ratio"
<fantasai> cbiesinger: what if we have 'auto' in the aspect ratio in the property?
<fantasai> TabAtkins: you wouldn't ignore auto, but you would look up intrinsic aspect ratio and see that you have none
Resolution: contain:size suppresses intrinsic aspect ratio
fantasai: We get to the be the guinia pigs for modifying a Rec
fantasai: Do we want to reoslve publishing an updated Rec that contains a candidate change?
chris: Doesn't it have to be published under a particular license?
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
<fantasai> TabAtkins: so no publication yet, but soon. happy to guinea pig
<fantasai> florian: another change in terminology is proposed
<fantasai> 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
<fantasai> florian: and we found some potential things we might want to change about how it affects grid tracks
<fantasai> florian: not on agenda today, but can discuss later
computed value of shortcuts
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/5511
<fantasai> TabAtkins: not clear how serialization should work in certain cases
<fantasai> TabAtkins: the 'content' value is equivalent to 'layout paint'
<fantasai> TabAtkins: should it serialize as 'content' or 'layout paint'?
<fantasai> TabAtkins: some differences between browsers
<fantasai> TabAtkins: if we specify shortest serialization principle to use shorthand when possible
<fantasai> TabAtkins: that assumes we'll always have a strict hierarchy of shorthand variables
<fantasai> TabAtkins: if partial overlap, might have multiple shortest-possible serializations
<fantasai> TabAtkins: I think we can spec our way out of that if needed
<fantasai> TabAtkins: Right now, means that the exact value is used
<fantasai> TabAtkins: essentially make ..
<fantasai> TabAtkins: and then go through and use shortest serialization
<fantasai> TabAtkins: so I propose that we serialize the 'contain' property using shortest serialization
<fantasai> TabAtkins: and use shorter values rather than how written
<heycam> fantasai: worth distinguishing between specified and computed values
<fantasai> fantasai: if talking about computed values, then just say that 'content' computes to 'layout paint' and it'll serialize appropriately per rules
<fantasai> fantasai: if talking about specified values, need to be explicit
<fantasai> oriol: Generally, specified values keep keyword as specified, just normalize the order
<fantasai> florian: Doesn't that fall out?
<fantasai> TabAtkins: Then it sorts in a particular order
<heycam> fantasai: canonical ordering in our propdef tables
<heycam> fantasai: it'll look at how you've defined the grammar, and serialize based on that order
<fantasai> fantasai: unless you define differently
<fantasai> TabAtkins: I think we need more detail in CSSOM to be clear
<fantasai> TabAtkins: about computed value, sounds like we can just resolve on doing the normal thing and then write tests
<fantasai> florian: don't we need to say that the "compute to" each other?
<fantasai> florian: otherwise they're similar but different values
<fantasai> emilio: behavior in Firefox is because we only partially implement some of contain
<fantasai> emilio: but generally, we should serialize the same, the computed and specified values
<fantasai> emilio: I don't see why they should be different. Most properties behave like that if there's no conversion
<fantasai> TabAtkins: I would prefer avoiding specified value conversion here
<fantasai> TabAtkins: so let's leave that off to the side, leave it for computed value serialization
<fantasai> TabAtkins: so I'm find to say that shorthand values compute to appropriate longhands and that falls out
<fantasai> astearns: So proposed resolution is that values are ...?
<fantasai> fantasai: You say the shorthand computes to the longhand, and it'll serialize as the short one
Resolution: contain keywords representing a combination of other keywords are defined to compute to those keywords so that they serialize under shortest-serialization princple
combination of shorthand and longhand values
github: https://github.com/w3c/csswg-drafts/issues/5506
<fantasai> TabAtkins: I wrote in an example in the spec 'contain: strict style'
<fantasai> TabAtkins: because strict doesn't include style
<fantasai> TabAtkins: turns out that this is not grammatical
<fantasai> TabAtkins: you can't mix the shorthands with additional longhands
<fantasai> TabAtkins: question is... should it be?
<fantasai> TabAtkins: especially if the shorthand computes to longhand, shouldn't we allow combining them
<fantasai> 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'
<fantasai> TabAtkins: Weakly prefer allowing more combos, but browsers only accept the stricter syntax
<fantasai> florian: Weak preference
<fantasai> florian: my weak preference goes the other way around because it's stable.
<fantasai> florian: If from scratch, would allow the non-redundant combinations, but minor enough not worth fixing
<fantasai> myles: Similar to what Florian just said.
<fantasai> myles: Also, as far as you know, are you the only person who has this desire?
<fantasai> TabAtkins: No idea
<fantasai> myles: So probably, no change
<fantasai> astearns: until browsers get bugs from ppl other than Tab :)
<fantasai> astearns: proposed no change
<fantasai> +1
<fantasai> astearns: any objections?
Resolution: close no change
Terminology Question for css-contain
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/5590
<fantasai> 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
<fantasai> florian: 'containign box' sounds a lot like 'containing block'
<fantasai> florian: he proposes 'containers box', I don't love that either
<fantasai> florian: but 'contaiment box' maybe helps?
<fantasai> florian: help avoid confusion with 'containing block'
<fantasai> florian: purely editorial
<fantasai> +1 to changing
<fantasai> florian: Used half a dozen times in this spec, not really in other specs (yet)
<heycam> +1 to "containment box"
<fantasai> TabAtkins: +1 to changing
<fantasai> TabAtkins: "containing" is used too much across CSS
<fantasai> TabAtkins: "containment box" sounds great, directly ties into concept, and slightly more distinct
Resolution: Change term "containing box" to "containment box"
Sizing 4
Break
contain:size and 'aspect-ratio'
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/5550
<fantasai> TYLin: Issue is replaced elements with intrinsic aspect ratio
<fantasai> TYLin: Specify contain:size and aspect-ratio, what size should it be?
<fantasai> TYLin: Discussion in the issue, should use expliti 'aspect-ratio' and otherwise none
<fantasai> 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?
<fantasai> TabAtkins: It does fall out, but might be worth an example
<fantasai> fantasai: I think it falls out
<fantasai> TYLin: added testcase
<fantasai> astearns: so proposal is to add an example
<fantasai> astearns: any objections?
Resolution: Add an example, but no change to normative prose
Break
<fantasai> <br end=':15'>
Resolution: Add dlibby as editor to MQ5
<fantasai> dlibby_, https://lists.w3.org/Archives/Public/spec-prod/2018OctDec/0011.html
<gregwhitworth> https://w3cmemes.tumblr.com/image/144115766537
<florian> https://w3cmemes.tumblr.com/post/178519961772
astearns: we added Daniel as an editor to MQ spec
… more editor positions are available on specs as well!
… if you've been opening issues on specs, and have some suggested solutions, we can use the help.
… let astearns know on IRC or email if you'd like to take him up on the offer
<chris> florian looks frozen tbh
Issue: 4585
Sizing
<Rossen_> github:https://github.com/w3c/csswg-drafts/issues/4585
<fantasai> https://github.com/w3c/csswg-drafts/issues/4585#issuecomment-701595999
Rossen_: who wants to summarize?
fantasai: we created this issue to collect use-cases for the control over use-cases over intrinsic sizes of boxes
… we have 3 maybe 4
… one is webkit like behavior
min-content contribution another is zeroing out the ... of scrolling containers
… another one is zeroing out the min content contribution when there is a zero size or max size in that axis
… someone wanted to have a box that had the same behavior as a replaced element
… they were able to replicate a lot with our aspect ratio stuff
… but this is a quirk of how replaced elements behave that's unrelated to aspect ratios
fantasai: q to wg, do we want to design a property to switch between these different values?
… q2 to wg, are there are other cases we should add to this
Rossen_: opinions?
(awkward silence)
Rossen_: do we care enough about this? or we can also move on if there is not enough interest here
… there was interest here. in terms of behavior what do we want?
… dbaron also dumped a bunch of mozilla bugs that were a good indicator that we need to look into solving this
… i don't see anyone on the queue or engaging
… shall we close the issue with no change?
cbiesinger: i would really like to have this property
… the second part was requested by me because I know some people who want to use this on their websites
… to set the min content to zero to act like replaced elements
… seems like useful behavior to get the regular size normally but when you shrink the window you can shrink the element with it
… that's my case for it
fantasai: proposed resolution: define a property to switch between these behaviors and hope someone comes up with sensible keywords
Rossen_: better than the ones currently in the issue
jensimmons: I also think this is a really good idea
… I can see... it's sort of an advanced feature ... authors need to wrap their heads around sizing period. it requires understanding how layout works first.
… to me the big use-case is you have multiple grid items in a grid track, and the track itself is going to be based on something in the track, and you can say don't base it on the headline, base it on something else
… you set its intrinsic size to 0 or 100px
… that could be very powerful
… the columns will be the size of the content in it, except not this content or this content
Rossen_: thank you. other opinions or objections to adopting such a property. name and value names tbd
… i see some nodding of heads
… no objections
Resolution: Adopt a property to solve the requested property and values from issue 4585
Why was min-content, etc. redefined to do nothing in the block axis
<fantasai> A first terrible attempt: intrinsic-size: auto | min-zero-scrollable || min-zero-percentage
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/3973
Rossen_: cbiesinger you opened this one
… and you also added it to agenda+
cbiesinger: I did?
Rossen_: on Jan 22
cbiesinger: oh that was a while ago lol
cbiesinger: why are we discussing today, wasn't it addressed by a recent edit?
TabAtkins: yes it was
… making sure others are ok with the edit
cbiesinger: I can summarize
… in the block axis the ..xx.. and fit-content take the same value as auto
Rossen_: sounds reasonable
cbiesinger: it lets you get the min height auto behavior from flexbox and grid
… and ... ratio in other contexts
<fantasai> at one poin the spec defined min-content/max-content/fit-content to behave the same as 'auto' in the block axis
Rossen_: any other opinions?
<fantasai> the edits changed that to say that the min-content and max-content sizes in the block axis are as defined by the layout model, defaulting to max-content behavior
Rossen_: or objections to accepting the edits
<fantasai> more or less
Resolution: accept edits made
Cyclic percentage concept should not exist
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/3010
Rossen_: fantasai you added this one
fantasai: this was less of a change in behavior, and more of a change in how it was explained
… determining whether a % is cyclic is itself a bit confusing
… but not all %s are cyclic
<fantasai> https://github.com/w3c/csswg-drafts/issues/3010#issuecomment-672335319
fantasai: we tried to draft a clarification ^
… we wanted to know if that would make the spec acceptable
… we're trying to get this spec to CR soonish
Rossen_: ok
… special resolution is defined after this paragraph?
… this clarification is pretty good actually
… any other opinions or feedback?
(silence)
dbaron: the new text looks good to me
fantasai: yay!
Rossen_: hearing no objections
Resolution: accept proposed edits in https://github.com/w3c/csswg-drafts/issues/3010#issuecomment-672335319
Distinguish intrinsic size's two definitions with two terms
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/4961
fantasai: we've been using intrinsic size to refer to two different concepts
… one is the size of a replacement element
… the other concept is referring to the min-content and max-content sizes, which always exists for any box, they are determined in some manner
… we need two different terms for this
… the HTML spec uses the term natural width and natural height
… we were thinking to replace the use of intrinsic size as it applies to the inherit size of a replaced element with natural size
… and keep intrinsic size to mean the other
<heycam> +1 for aligning terms across specs
florian: with the new dfn, the intrinsic size of a replacement it would be the natural size and 0 otherwise?
fantasai: no it can lack an intrinsic size
florian: I don't understand
fantasai: you have to distinguish between whether you are taking about a min-content and a max-content size
fantasai: when the natural size of something does not exist, there are rules for determining
<Zakim> myles, you wanted to ask if this is a behavior change
myles: is this purely a rename or behavior change?
fantasai: purely terminology in the spec
cbiesinger: this is only for replaced elements but, don't you need a terminology for non-replaced elements with an aspect ratio because the regular min and max content size will be affected by the aspect ratio, but you also need a way to refer to the original min and max content size because you need that for min-size auto
fantasai: I see what you're talking about, havent' thought about that yet
heycam: we should check what the HTML spec says
… and I did, and they return 0
<cbiesinger> tantek: yep!
heycam: I just want to make sure we don't have any confusion by using the same terms
fantasai: I think the DOM APIs can return 0 when there is no natural size
TabAtkins: do the DOM APIs refer to it any other way other than the camelcased form?
heycam: no it refers to JS properties
florian: this is confusing / not good
fantasai: Their spec is using 'intrinsic size' because that's what our spec uses.
fantasai: when we update our specs, we'll make sure HTML updates their terms to match als
Rossen_: Hearing mostly support for having this clear distinction
Rossen_: Are we leaning towards also accepting the proposed names here, "natural size"?
<heycam> s/and the return 0/and they return 0 for images that have no natural size/
<florian> +1
fantasai: 2 votes in favor from rachelandrew and SimonSapin
<bkardell_> +1
Rossen_: I don't see anyone not liking it. Any objections?
<bkardell_> actually this confused me quite a bit last year
<bkardell_> I remember having exactly this converation with tab in toronto trying to figure it out
Resolution: Rename term "intrinsic size" of image with "natural size"
Rossen_: Seems like everything on Sizing 3
Rossen_: Alan has an editorial issue to talk about
Rossen_: With everything we resolved, do we need to republish
fantasai: yes, and
fantasai: That closes all the major issues on this spec, so we'd like to issue a last call for comments and start preparing for CR
astearns: so resolution to publish after all these edits are in?
Resolution: Republish WD of css-sizing-3
and start CR process after that
astearns: emilio just volunteered taking on cssom-view at least on the issues he raised
Resolution: Add emilio as editor of cssom-view
<smfr> thank you emilio!
<myles> emilio is the best
Break
<myles> 💯
astearns: Note that emilio also has editorship of cssom, and probably needs help
Clarify on specifying aspect-ratio and contain:size on replaced elements
Rossen_: that's everything for sizing then
CSS Logical Properties
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/3030
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/3030
fremy: main issue is that in CSS spec it defines how to serialize properties, contains a lot of tricks to merge declarations
… e.g. if you set all four border properties, the rules merge it to a single declaration
… when I looked at the logical properties, this is not as easy
… even if you have all four, you cannot always merge them into a single property
… it means you have to detect this case (e.g. inline-start) and do something smart
… logical and physical properties
… proposing a couple of rules to the serialization steps
… to only merge all four if they are of the same type
… while we were looking at this, a few more updates
… e.g. dbaron proposed if you set the margin property on the style attribute
… there is no reason to keep the margin-inline properties
… the logical ones
<fantasai> (because they have all now been overridden)
fremy: proposal: make sure that the grouping would work
… making sure when you set things you override properly
emilio: Gecko has the concept of logical property groups
… we added it to the spec
… this concept already exists
… e.g. border-inline-start:10px; border-start:20px;
… Gecko will do the right thing
… the concept is already in the spec. this is an obvious bugfix
fremy: emilio's link https://drafts.csswg.org/css-logical-1/#logical-property-group sounds like exactly what I'm proposing that seems fine
<Rossen_> See the refs for https://drafts.csswg.org/css-logical-1/#logical-property-group
fantasai: we should make sure ... interleaved ... then that can be folded into a shorthand
<emilio> https://drafts.csswg.org/cssom/#set-a-css-declaration is already using this concept
<emilio> We should use it from serialization
fantasai: the other part of your proposal, if a shorthand is set, then you can drop any previous declarations that set any property in that logical property group
fremy: that sounds correct to me
Rossen_: do we not have this currently specified? the part you just added fantasai ? in terms of the behavior?
fantasai: I think in terms of how everything is supposed to behave like cascade, etc. is defined. this is about CSSOM interaction
Rossen_: so this is going into CSSOM then? mostly?
fantasai: I guess so. emilio and I will work it out
Rossen_: any other opinions?
emilio: I need to look a bit more closely at the replace all the physical longhands
… because there are more complex cases
… e.g. shorthands that only override two properties
… like the serialization stuff when stuff is interleaved, that's good
… the replace of the existing physical properties, that may or may not be confusing
fantasai: I think they are two separate proposals that happen to be in the same issue
Rossen_: can you separate them for resolutions?
<fantasai> First proposal from fremy: During parsing of a css declaration block, shorthands (like margin and all) expands only to the set of longhand (grouped by mapping logic: so either logical or physical) required to describe their value, and by default resort to use physical properties if both sets are possible. Note that they can only expand if they do not contain var() substitutions.
<fantasai> Second proposal from fremy: During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.
Rossen_: please read the first one, which is about the behavior specifying, and how declaration blocks behave between shorthands and longhands and logical properties
fantasai: looks like I'm finding more pieces of it
fremy: the first one I assume every browser already does that
… it's not clear from the spec, but I assume that should work regardless
<fantasai> Third piece from fremy: When removing a shorthand property, all the longhand associated with that shorthand should be removed, regardless of their mapping kind.
<TabAtkins> +1, all sound good
<fantasai> Fourth piece from dbaron: appending a shorthand property could set all of its constituent shorthands of one mapping logic and also remove all of the constituent shorthands of the other.
Rossen_: any objections to accepting this first proposal
emilio: q, we are talking about shorthands that map to both physical and logical properties? but those do not exist in browser today
fremy: it's possible, back them we had proposal for margin, I don't know if we still have that
fantasai: we never figured out a syntax that was appropriate
fremy: that was mostly to make sure that case worked
… I don't think it's wrong to add this even if we don't have the mechanism
emilio: not saying it's wrong, just possibly confusing
how would you test it?
Resolution: proposal from fremy: During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.
fremy: mostly the loop needs to be modified
Rossen_: wanting make sure everyone is comfortable with accepting this change
<emilio> yeah, +1 for the serialization change, that's unobjectionable imo
<fremy> https://www.w3.org/TR/cssom-1/#serialize-a-css-declaration-block
Rossen_: without delaying people too much, any objections or wait til Thu morning?
fremy: for me both is fine
Resolution: proposal from fremy:During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.