IRC log of css on 2020-01-23
Timestamps are in UTC.
- 00:25:06 [dauwhe]
- dauwhe has joined #css
- 00:41:34 [Karen]
- Karen has joined #css
- 01:47:34 [drousso]
- drousso has joined #css
- 02:04:03 [drousso]
- drousso has joined #css
- 02:22:00 [projector]
- projector has joined #css
- 02:22:30 [Rossen]
- Rossen has joined #css
- 02:23:01 [shans]
- shans has joined #css
- 02:23:31 [sylvaing]
- sylvaing has joined #css
- 02:24:02 [leaverou]
- leaverou has joined #css
- 02:24:32 [plinss_]
- plinss_ has joined #css
- 02:32:50 [skk]
- skk has joined #css
- 02:38:01 [plh]
- plh has joined #css
- 02:51:18 [dauwhe]
- dauwhe has joined #css
- 04:01:21 [skk_]
- skk_ has joined #css
- 04:03:01 [dauwhe]
- dauwhe has joined #css
- 04:07:10 [skk]
- skk has joined #css
- 04:10:46 [skk_]
- skk_ has joined #css
- 04:14:42 [skk]
- skk has joined #css
- 04:32:50 [skk_]
- skk_ has joined #css
- 04:37:05 [dauwhe]
- dauwhe has joined #css
- 04:47:23 [dauwhe]
- dauwhe has joined #css
- 06:53:07 [skk]
- skk has joined #css
- 07:59:28 [igalia]
- igalia has joined #css
- 08:00:20 [jfkthame]
- jfkthame has joined #css
- 08:04:59 [rego]
- rego has joined #css
- 08:06:24 [skk_]
- skk_ has joined #css
- 08:49:56 [jensimmons]
- jensimmons has joined #css
- 09:01:15 [svillar]
- svillar has joined #css
- 09:03:34 [igalia]
- igalia has joined #css
- 09:03:59 [igalia]
- for people to call in https://meetings.igalia.com/cssw
- 09:04:13 [RossenF2F]
- RossenF2F has joined #css
- 09:04:21 [igalia]
- oops wrong link it seems https://meetings.igalia.com/csswg
- 09:04:45 [RossenF2F]
- Zakim, start meeting
- 09:06:15 [skk]
- skk has joined #css
- 09:07:12 [RossenF2F_]
- RossenF2F_ has joined #css
- 09:07:44 [jensimmons]
- jensimmons has joined #css
- 09:07:52 [fremy]
- fremy has joined #css
- 09:09:04 [RossenF2F__]
- RossenF2F__ has joined #css
- 09:09:22 [RossenF2F__]
- RRSAgent, start meeting
- 09:09:22 [RRSAgent]
- I'm logging. I don't understand 'start meeting', RossenF2F__. Try /msg RRSAgent help
- 09:09:49 [faceless2]
- faceless2 has joined #css
- 09:10:57 [Zakim]
- Zakim has joined #css
- 09:11:25 [astearns]
- zakim, start meeting
- 09:11:25 [Zakim]
- RRSAgent, make logs Public
- 09:11:26 [Zakim]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 09:12:15 [Rossen__]
- Rossen__ has joined #css
- 09:12:25 [jfkthame]
- jfkthame has joined #css
- 09:14:57 [bkardell_]
- bkardell_ has joined #css
- 09:14:57 [bkardell_]
- present+
- 09:15:13 [rachelandrew]
- present+
- 09:15:25 [bkardell_]
- present+
- 09:15:29 [stantonm]
- stantonm has joined #css
- 09:15:32 [cbiesinger]
- present+
- 09:15:40 [stantonm]
- present+
- 09:15:44 [skk]
- present+
- 09:16:39 [dbaron]
- Present+
- 09:16:40 [heycam]
- present+
- 09:17:01 [Rossen__]
- present+
- 09:17:05 [jensimmons]
- present+
- 09:17:05 [hober]
- present+
- 09:17:07 [fremy]
- present+
- 09:17:09 [jfkthame]
- present+
- 09:17:11 [faceless2]
- present+
- 09:17:12 [rego]
- present
- 09:17:13 [iank_]
- present+
- 09:17:13 [emilio]
- present+
- 09:17:15 [florian]
- present+
- 09:17:15 [rego]
- present+
- 09:17:33 [TabAtkins]
- present+
- 09:17:39 [TabAtkins]
- ScribeNick: TabAtkins
- 09:18:12 [oriol]
- present+
- 09:18:44 [TabAtkins]
- Topic: column-fill in unconstrained containers
- 09:18:46 [TabAtkins]
- github: https://github.com/w3c/csswg-drafts/issues/4689
- 09:19:03 [TabAtkins]
- rachelandrew: New issue, but refers back to a previous issue; trying to wrap up.
- 09:19:22 [TabAtkins]
- rachelandrew: Previous Multicol said that in continuous media, column-fill is only used if height of columns is constrained; otherwise they're balanced.
- 09:19:28 [TabAtkins]
- rachelandrew: Was commented out in 2012.
- 09:20:00 [TabAtkins]
- rachelandrew: Chrome and WK implemented column-fill as if that line was there; Firefox implemented without.
- 09:20:09 [fantasai]
- present+
- 09:20:25 [TabAtkins]
- rachelandrew: We put the line back in in #3224, to match Chrome, but in #4036 we reverted based on dbaron's issue.
- 09:20:47 [TabAtkins]
- rachelandrew: dbaron suggested we change the line to say "in continous context, and last fragment in fragmented contexts...", and I updated the table accordingly
- 09:21:00 [TabAtkins]
- rachelandrew: So we need to figur eout what to do when column-fill:auto and unconstrained height
- 09:21:15 [TabAtkins]
- rachelandrew: If we honor it, that means all the content goes into the first column.
- 09:21:29 [TabAtkins]
- rachelandrew: This is only outstanding issue in multicol.
- 09:21:44 [TabAtkins]
- florian: In addition to Firefox vs WK, there was browser vs print aspect
- 09:21:51 [TabAtkins]
- florian: Wanted consistency between multiple things.
- 09:21:59 [lajava]
- lajava has joined #css
- 09:22:02 [TabAtkins]
- florian: "browser when screen" and "browser when printing" should act the same
- 09:22:10 [TabAtkins]
- florian: Shouldn't ranodmly become different, people don't test
- 09:22:20 [TabAtkins]
- florian: And also didn't want browsers and print formatters to do different things
- 09:22:31 [TabAtkins]
- florian: It seemd to me there was only one behavior we could use that satisfies those
- 09:22:46 [TabAtkins]
- rachelandrew: We resolved to revert the change and put an issue in the spec in Fukuoka
- 09:23:18 [TabAtkins]
- florian: dbaron, do you remember what the "one harmonious approach" was?
- 09:23:36 [TabAtkins]
- dbaron: I think our conclusion was...
- 09:23:40 [TabAtkins]
- dbaron: There were two constraints.
- 09:24:08 [TabAtkins]
- dbaron: One was we dont' want the rules between continuous and fragmented contexts to be different, such that you get different results if you ahve a small multicol in a fragmented context that is small enough to not fragment.
- 09:24:25 [TabAtkins]
- dbaron: Second is making the behavior of print formatters, and browsers when printing, consistent.
- 09:24:44 [TabAtkins]
- dbaron: I think shortest path to satisfy both and be sensible is Chrome and WK changing their behavior, I think to the Gecko one.
- 09:25:07 [TabAtkins]
- dbaron: I think if we look at continouous context behavior, it woudl involve Chrome and WK matching Gecko. I don't remember about fragment context
- 09:25:20 [TabAtkins]
- timeless: Prince matches Firefox
- 09:25:44 [heycam]
- s/timeless/faceless/
- 09:25:46 [TabAtkins]
- florian: remaining open question is, are Blink and WK willing to do it?
- 09:26:16 [myles]
- myles has joined #css
- 09:26:18 [TabAtkins]
- rachelandrew: Morten says yes, but we'd have to clarify what colum-fill:auto and height:auto means
- 09:26:38 [TabAtkins]
- iank_: Morten's fine, yes. Depending on how diffiuclt, we might not get to it immediately; it might wait for our new fragmenting impl.
- 09:26:54 [TabAtkins]
- dbaron: I'm reading Fukuoka minutes, but I think we already decided to do this.
- 09:26:59 [skk_]
- skk_ has joined #css
- 09:27:09 [TabAtkins]
- dbaron: Morten was concerned about, once we make that change, there's more that needs to be defined more clearly.
- 09:27:11 [tantek]
- tantek has joined #css
- 09:27:26 [TabAtkins]
- dbaron: so I think we agreed on the behavior we wanted, but then needed to follow up with issues to make it more fully defined.
- 09:27:39 [TabAtkins]
- dbaron: Resolution was "revert #3224, and add spec issues to define this"
- 09:27:57 [TabAtkins]
- dbaron: So I think our resolution was reverting, and then there were other issues that aren't fullyd efined and need to be defined.
- 09:28:08 [TabAtkins]
- dbaron: I suspect Morten might be the best to remember what that undefined stuff was.
- 09:28:27 [TabAtkins]
- iank_: And I think Morten wanted it to all be done at once rather than a dripfeed of impl issues, so he'll want it all defined before he makes the change.
- 09:28:38 [TabAtkins]
- florian: Was the question about min-height:auto, max-height, etc.
- 09:28:52 [TabAtkins]
- dbaron: [reads Morten's comment]
- 09:28:55 [myles]
- present+ myles
- 09:29:29 [dbaron]
- was reading https://github.com/w3c/csswg-drafts/issues/4036#issuecomment-508378790
- 09:29:43 [TabAtkins]
- rachelandrew: All riht, so I'll need to talk to Morten to see what he was really wanting to be defined
- 09:30:14 [TabAtkins]
- rachelandrew: Can we have a clear resolution confirming this position?
- 09:30:26 [TabAtkins]
- iank_: Yeah, could we have fully defined behavior before we make the change?
- 09:32:06 [TabAtkins]
- RESOLVED: Confirm that we do indeed want (at least generally) Firefox's behavior, and get Morten to confirm exactly what he wants clarified in further issues.
- 09:33:31 [TabAtkins]
- Topic: multicol tests
- 09:33:38 [fantasai]
- ScribenicK: fantasai
- 09:33:45 [TabAtkins]
- ScribeNick: TabAtkins
- 09:33:58 [TabAtkins]
- rachelandrew: As part of this work I've been going thru the testsuite
- 09:34:04 [TabAtkins]
- rachelandrew: Some are quite old, going back to old Opera tests
- 09:34:13 [TabAtkins]
- rachelandrew: I've been inlining the tests as I go to see what's tested and not
- 09:34:26 [TabAtkins]
- rachelandrew: I've got a whole bunch of tests now that are Fragmentation, not Multicol, or Box Alignment.
- 09:34:32 [TabAtkins]
- rachelandrew: Dont' have anywhere for them to live.
- 09:34:40 [TabAtkins]
- rachelandrew: What's the process for moving those?
- 09:35:34 [TabAtkins]
- TabAtkins: If those tests belong to Fragmentation or Align, we can just move those in WPT, right?
- 09:35:40 [TabAtkins]
- rachelandrew: Dunno, got shrugs in #testing before
- 09:36:22 [TabAtkins]
- florian: If it still involves multicol, you can also still link in the metadata to the part of it that's relevant in Multicol. You can also include tests in <wpt> that aren't in your spec's folder, if they're relevant.
- 09:36:59 [zcorpan]
- zcorpan has joined #css
- 09:37:15 [TabAtkins]
- fantasai: Yeah I think florian summarized it. Test goes in the folder of the spec it's primarily testing; if it's testing interactions you can link those cross-spec sections; if the test is just using a feature for generic purposes (like backgrounds), you don't need to link that spec.
- 09:37:48 [TabAtkins]
- fantasai: Some tests you can go either way on whether they're tagged Multicol or not, but they're definitely fragmentation; only things like "how wide is a column, etc" are def multicol.
- 09:38:18 [TabAtkins]
- iank_: If you do move a whole bunch of tests, it's easier for us if you do them in one large ocmmit
- 09:38:27 [TabAtkins]
- iank_: We have to update test expectations, etc.
- 09:38:41 [TabAtkins]
- rachelandrew: I've already got a spreadsheet, so I can do it all at once
- 09:38:45 [TabAtkins]
- iank_: How many?
- 09:38:52 [TabAtkins]
- rachelandrew: Dunno, a fair few. Tens.
- 09:41:23 [fantasai]
- ScribeNick: fantasai
- 09:41:28 [fantasai]
- Topic: Masonry Layout
- 09:41:50 [TabAtkins]
- github: https://github.com/w3c/csswg-drafts/issues/4650
- 09:42:22 [fantasai]
- jensimmons: Mats Palmgren, layout engineer at Mozilla, over Christmas break, this is what he did for Christmas present
- 09:42:33 [fantasai]
- jensimmons: He's thought in detail about what it would take to add something to Grid to accomplish Masonry layout
- 09:42:40 [fantasai]
- jensimmons: It's lots of detailed from implementer perspective
- 09:42:46 [fantasai]
- jensimmons: So what is Masonry layout?
- 09:42:58 [fantasai]
- jensimmons: It's a popular idea of how to lay out content on the Web, e.g. on Pintrest
- 09:43:14 [fantasai]
- jensimmons: People wanted to do it with Grid, but you can't really, still have to use JS
- 09:43:29 [fantasai]
- jensimmons: works fast on Pintrest because they put a lot of money and effort into it
- 09:43:37 [fantasai]
- jensimmons: others use this library
- 09:43:44 [fantasai]
- jensimmons: Here's what the layout looks like [shows outline]
- 09:43:54 [fantasai]
- jensimmons: Why not do it with flexbox? well that would give the wrong content order
- 09:44:21 [fantasai]
- jensimmons: Don't want the early things to be below the fold with late things up at top in the later columns
- 09:44:32 [fantasai]
- jensimmons: also makes a problem with lazy loading, would rejigger layout
- 09:44:36 [fantasai]
- jensimmons: Order ppl need is going across
- 09:44:49 [fantasai]
- jensimmons: This version of Masonry, the most common one, is that as it goes to fill in the rest of the pieces of content
- 09:45:01 [fantasai]
- jensimmons: puts next item into the column that is the shortest, so always closest to the top
- 09:45:18 [fantasai]
- jensimmons: Other option is to go from 1st column to last column always
- 09:45:32 [fantasai]
- jensimmons: but skip columns that are too full to keep things roughly in order
- 09:45:38 [fantasai]
- jensimmons: Mats believes he's figured out how to do it in Grid
- 09:45:40 [fantasai]
- jensimmons: That's the issue
- 09:45:54 [fantasai]
- jensimmons: I think it would be popular and ppl would be super happy to have
- 09:46:01 [fantasai]
- TabAtkins: Yes, this has been requested for like 15 years
- 09:46:14 [fantasai]
- TabAtkins: Overall, love the proposal, think it's great, lots of detail in it
- 09:46:14 [bkardell_]
- q+
- 09:46:26 [fantasai]
- TabAtkins: Only concern, making it part of Grid instead of its own display type
- 09:46:26 [rachelandrew]
- q+
- 09:46:37 [fantasai]
- TabAtkins: Think we should make it display: masonry, copy over concepts from Grid
- 09:47:05 [heycam]
- fantasai: any examples of things you're concerned about?
- 09:47:10 [emilio]
- q+
- 09:47:13 [heycam]
- fantasai: this is somewhat similar in that subgrid is also kind of like a mode
- 09:47:20 [heycam]
- ... which creates a different way of laying out items in the grid
- 09:47:26 [heycam]
- ... masonry is a different model for doing the rows
- 09:47:37 [fantasai]
- TabAtkins: Sugrid is fundamenally a grid still
- 09:47:48 [fantasai]
- TabAtkins: but Masonry is different
- 09:48:08 [fantasai]
- TabAtkins: Example, Mats suggests an align-tracks property that only applies to masonry
- 09:48:12 [heycam]
- fantasai: what's it do?
- 09:48:27 [fantasai]
- TabAtkins: it aligns the Masonry stuff within their track
- 09:48:41 [fantasai]
- TabAtkins: So there are a few different layout concepts
- 09:48:47 [fantasai]
- TabAtkins: that don't apply to Masonry in Grid
- 09:48:52 [fantasai]
- TabAtkins: and that don't apply to Grid in Masonry
- 09:48:54 [jensimmons]
- q+
- 09:49:01 [fantasai]
- TabAtkins: So I think we should re-use as many concepts as possible
- 09:49:08 [tantek]
- Is this orientation specific? I.e. presumably masonry refers to the overlapping brick like layout. Flickr does this for displaying photo results, e.g. https://flickr.com/photos/tags/csswg
- 09:49:09 [fantasai]
- TabAtkins: but separate out as a distinct display type
- 09:49:17 [fantasai]
- TabAtkins: that has a clear signal for what applies here vs in Grid
- 09:49:36 [fantasai]
- florian: For align-tracks property, if we did have different modes, could we use an existing alignment property to do this?
- 09:49:52 [heycam]
- fantasai: if I understand correctly, you have a box, then some masonry tracks
- 09:50:08 [heycam]
- ... each individual track aligning its content to the bottom
- 09:50:17 [heycam]
- ... rather than taking the entire masonry chunk and sliding it to the bottom
- 09:50:34 [heycam]
- ... isn't this exactly what justify-content does in flexbox? why not just reuse align-content?
- 09:50:46 [heycam]
- TabAtkins: only given an hour thought to this
- 09:50:55 [heycam]
- fantasai: I think it's premature to split it out, it's its own layout model, but which should think about that
- 09:51:05 [heycam]
- ... for now leaving it as part of grid makes sense until we have a clearer idea of what doesn't fit
- 09:51:19 [tantek]
- q?
- 09:51:28 [fantasai]
- Rossen__: Fan of this proposal
- 09:51:34 [fantasai]
- Rossen__: What are we trying to get out of this discussion?
- 09:51:57 [fantasai]
- heycam: Wanted to get temperature of the room, see if there's interest
- 09:52:02 [fantasai]
- heycam: and also get thoughts on integration
- 09:52:26 [fantasai]
- bkardell_: Of course I want this
- 09:52:47 [fantasai]
- bkardell_: Want to say same thing as Grid and Flexbox, we should stop and solve the a11y problem with content reordering
- 09:52:58 [fantasai]
- bkardell_: I have concerns about that, that's all
- 09:53:07 [fantasai]
- rachelandrew: I would really like to see Masonry solved
- 09:53:19 [fantasai]
- rachelandrew: I also agree we should look at content reordering proble
- 09:53:24 [iank_]
- q+
- 09:53:26 [fantasai]
- rachelandrew: Don't think it should be part of Grid
- 09:53:32 [astearns]
- ack bkardell_
- 09:53:34 [fantasai]
- rachelandrew: Trying to teach it, it's not a grid
- 09:53:35 [TabAtkins]
- I think this doesn't introduce any new content-reordering problems; it's definitely no worse than "a pile of floats", still according with the standard "left to right, top to bottom" ordering.
- 09:53:37 [astearns]
- ack rachelandrew
- 09:53:40 [TabAtkins]
- (Unless you use 'order', of course.)
- 09:53:43 [fantasai]
- rachelandrew: would make a lot more sense to have a separate layout model
- 09:54:01 [tantek]
- Is there no attempt to do baseline alignment across masonry items in different columns?
- 09:54:09 [tantek]
- That might be one reason to consider it grid-like
- 09:54:11 [Rossen__]
- ack emilio
- 09:54:28 [fantasai]
- emilio: I don't know if should be separate model
- 09:54:45 [fantasai]
- emilio: but multicol changes layout model quite a lot, this still mostly fits within grid layout paradigm
- 09:54:49 [fantasai]
- emilio: can share a lot of code
- 09:54:53 [fantasai]
- emilio: so not quite like multicol
- 09:55:00 [Rossen__]
- ack jensimmons
- 09:55:02 [fantasai]
- jensimmons: I think these are great issues to bring up
- 09:55:11 [fantasai]
- jensimmons: taking of introducer hat
- 09:55:13 [fantasai]
- jensimmons: this is jen
- 09:55:22 [fantasai]
- jensimmons: I was also concerned about a11y order
- 09:55:23 [astearns]
- tantek: I doubt it would be feasible to to baseline alignment when there are not grid lines in the block direction
- 09:55:33 [fantasai]
- jensimmons: but aftter explaining, I think it's less of a problem than Grid
- 09:55:46 [fantasai]
- jensimmons: It does seem like ppl are tabbing through DOM order, focus rings
- 09:55:53 [fantasai]
- jensimmons: Easier because content doesn't go below the fold
- 09:55:58 [fantasai]
- jensimmons: I do feel like this belongs as grid
- 09:56:09 [fantasai]
- jensimmons: there are 2 axes, and this only works in one axis
- 09:56:21 [fantasai]
- jensimmons: do this in row directly, have all power of grid in column direction
- 09:56:34 [fantasai]
- jensimmons: Things when it comes to subgrid and nesting a grid inside a grid, might want things to interact
- 09:56:37 [tantek]
- would https://flickr.com/photos/tags/csswg be an example of doing it in the "row direction"?
- 09:56:40 [fantasai]
- jensimmons: things interact
- 09:56:52 [Rossen__]
- q?
- 09:56:53 [fantasai]
- jensimmons: Just choose how you want to treat other axis
- 09:57:16 [fantasai]
- jensimmons: ...
- 09:57:26 [fantasai]
- iank_: I'll try and channel Adam Argyle
- 09:57:36 [fantasai]
- iank_: He previously worked in industry and built lots and lots of Masonry layouts
- 09:57:39 [TabAtkins]
- Ah, I remember why *-content can't work for distributing the items in a masonry track!
- 09:57:51 [fantasai]
- iank_: he had similar reaction that might fit better as a separate layout model
- 09:57:56 [Rossen__]
- ack iank_
- 09:57:59 [Rossen__]
- ack dbaron
- 09:57:59 [Zakim]
- dbaron, you wanted to ask about which grid properties apply sensibly given the placement algorithm
- 09:58:20 [fantasai]
- dbaron: Jen was talking about, and think this might relate to Tab's comment on IRC, applying grid properties in vertical axis in masonry
- 09:58:36 [fantasai]
- dbaron: One thing I was wondering is how many interact with placement concept of Masonry
- 09:58:47 [fantasai]
- dbaron: e.g. if you have align-content in the vertical axis
- 09:59:02 [fantasai]
- dbaron: space-around, you want even gaps
- 09:59:13 [fantasai]
- dbaron: you don't know how many items until you place them
- 09:59:27 [hober]
- q+ myles
- 09:59:40 [fantasai]
- dbaron: and you can't place them until you know the number of gaps in each column above the item
- 10:00:03 [fantasai]
- TabAtkins: Mats answered it by saying you place items before applying align-content
- 10:00:07 [astearns]
- tantek: I don't think the flickr thing is masonry-row. The content order would go top to bottom in that case, and it looks to me like the first three pictures in the first row are in content order
- 10:00:43 [heycam]
- TabAtkins: align-content is a different thing, it moves the whole grid
- 10:01:02 [heycam]
- ... repeat autofill doesn't work
- 10:01:11 [fantasai]
- TabAtkins: But back to fantasai's point about align-content, in Grid it aligns the entire grid
- 10:01:35 [fantasai]
- florian: If you have a grid with sized tracks in the Block axis, and the size of the tracks is smaller than the container, then you can align
- 10:01:47 [fantasai]
- florian: but masonry tracks don't have such a size
- 10:02:09 [tantek]
- astearns, I have heard what Flickr does called "masonry" layout as well so that likely deserves some clarification
- 10:02:18 [tantek]
- in particular, the feature of resizing images to fit like that
- 10:03:05 [fantasai]
- TabAtkins: Track does have a size, it's the sum of all masonry items in it
- 10:03:52 [astearns]
- q+ to surface my side convo with tantek
- 10:03:58 [fantasai]
- myles: Want to jump on bandwagon and say it's really exciting
- 10:04:10 [fantasai]
- myles: wrt new display type, I think Mats makes a compelling argument wrt graceful degradation
- 10:04:28 [fantasai]
- fremy: you can just say `display: grid; display: masonry` which works
- 10:04:32 [Rossen__]
- ack myles
- 10:04:44 [fantasai]
- TabAtkins: Especially if we re-use grid-template-columns or whatever, it's easy fallback
- 10:04:52 [fantasai]
- astearns: Side conversation with Tantek on IRC
- 10:05:05 [fantasai]
- astearns: Has example of Flickr, wants to ask if that's also Masonry layout
- 10:05:15 [tantek]
- specifically with the resizing of items in the masonry layout
- 10:05:21 [tantek]
- yes dbaron
- 10:05:27 [fantasai]
- Rossen__: This is a multiline flex
- 10:05:58 [astearns]
- ack astearns
- 10:05:58 [Zakim]
- astearns, you wanted to surface my side convo with tantek
- 10:06:00 [fantasai]
- jensimmons: Flickr decides how many photos to put in a row
- 10:06:07 [fantasai]
- jensimmons: then makes the outer edges to match the container
- 10:06:13 [tantek]
- it's not just flex. it's about resizing the images automatically to fit them in the row
- 10:06:14 [fantasai]
- jensimmons: then changes the height of the row to match
- 10:06:22 [fantasai]
- jensimmons: it's weird and complicated and totally done in JS
- 10:06:38 [fantasai]
- dbaron: each image is sized based on other photos in the row
- 10:06:45 [tantek]
- anyway the point is due to the brick-like layout, this is *also* called masonry
- 10:06:47 [plh]
- plh has joined #css
- 10:06:55 [fantasai]
- jensimmons: If you [...] then you get basically that layout, but the images are cropped by object-fit
- 10:06:59 [fantasai]
- jensimmons: they use JS to avoid cropping the images
- 10:07:06 [fantasai]
- jensimmons: and Masonry is a whole different layout
- 10:07:09 [tantek]
- having the row heights adjust automatically is key
- 10:07:22 [tantek]
- I'm saying that web developers (some at least) know this as masonry as well
- 10:07:32 [tantek]
- so if you call something masonry, some may/will expect this to be supported
- 10:07:33 [fantasai]
- Rossen__: In summary, I'm hearing a lot of support for this proposal
- 10:07:50 [fantasai]
- Rossen__: reminds me of early days of Grid, when we proposed something
- 10:08:04 [fantasai]
- Rossen__: and 2nd model was proposed to add to it, at first seemed unlikely to fit
- 10:08:19 [fantasai]
- Rossen__: but ended up with a harmonious merge
- 10:08:27 [fantasai]
- Rossen__: Let's get something in a more spec-like proposal
- 10:08:34 [fantasai]
- Rossen__: then decide if it should fit into Grid, or should be its own thing
- 10:08:36 [jensimmons]
- The demo I was just talking about: https://labs.jensimmons.com/2016/examples/image-gallery-flexbox-1.html It only works in FIrefox because of the flexbox sizing bug of images in Chrome, Edge & Safari.
- 10:08:41 [fantasai]
- Rossen__: Are there parts that should be extensions to Grid?
- 10:08:48 [fantasai]
- Rossen__: I think it will take some time to figure out
- 10:09:21 [fantasai]
- Rossen__: but overall goal of proposal and exposure of topic is achieved in sense that there's a lot of support and demand for this, so let's continue working on this in a separate module for now to bake out the details and decide the next path forward
- 10:09:25 [fantasai]
- Rossen__: might be Grid, might be something else
- 10:09:28 [fantasai]
- Rossen__: sound good?
- 10:09:33 [fantasai]
- fantasai: +1
- 10:09:42 [tantek]
- +1
- 10:09:45 [bkardell_]
- ... and to double down on solving the general reordering issue?
- 10:09:53 [fantasai]
- Rossen__: So I propose we take a resolution to adopt Masonry layout and move from there.
- 10:10:02 [fantasai]
- fantasai: Who's editing
- 10:10:17 [fantasai]
- TabAtkins: I'll co-edit, but not primary edit
- 10:10:44 [fantasai]
- Rossen__: Mats?
- 10:10:51 [fantasai]
- dbaron: We might have to do some convincing
- 10:10:55 [fantasai]
- fantasai: I can edit.
- 10:11:21 [fantasai]
- RESOLVED: Adopt Masonry layout proposal, editors fantasai and Tab, and Mats if he's convinceable
- 10:11:40 [fantasai]
- bkardell_: Masonry isn't in content order
- 10:11:44 [dbaron]
- and Jen?
- 10:11:52 [fantasai]
- florian: yes and no, it's not a 1D thing, they're in 2D space
- 10:12:00 [fantasai]
- florian: but within that space they're in content order
- 10:12:04 [astearns]
- they are always top to bottom, not necessarily left to right
- 10:12:21 [fantasai]
- s/convinceable/convinceable, and Jen if she's allows/
- 10:12:23 [fantasai]
- ?
- 10:12:27 [bkardell_]
- for the record, not pushing back on 'this' - worried about the general space
- 10:12:56 [fantasai]
- Topic: Merging All the Shape Functions
- 10:13:10 [fantasai]
- fantasai: Do we want to wait for Amelia?
- 10:13:40 [fantasai]
- TabAtkins: I agree with Amelia, so can represent her position
- 10:13:43 [fantasai]
- [agenda-wrangling]
- 10:14:06 [fantasai]
- Topic: Why was min-content etc. to be redefined to be nothing like Block axis?
- 10:14:23 [Rossen__]
- github:https://github.com/w3c/csswg-drafts/issues/3973
- 10:14:36 [fantasai]
- cbiesinger: Seems to be disagreement between me and dbaron
- 10:14:55 [fantasai]
- cbiesinger: For a long time min-content/max-content/fit-content were defiend to work in the block axis
- 10:15:08 [fantasai]
- cbiesinger: to be the size the item would have if it weren't explicitly sized
- 10:15:12 [fantasai]
- dbaron: Size at what width?
- 10:15:18 [fantasai]
- cbiesinger: I know that's your objection to this
- 10:15:22 [fantasai]
- cbiesinger: Chrome had implemented this
- 10:15:32 [fantasai]
- cbiesinger: This is also essentially the same size that Flexbox uses for min-height: auto
- 10:15:45 [fantasai]
- cbiesinger: At one point spec was changed to say that block axis just computes to auto, and Chrome removed it
- 10:15:51 [fantasai]
- cbiesinger: However I think this is a useful thing to have
- 10:15:58 [fantasai]
- cbiesinger: Intrinsic size in the block axis at the specified width
- 10:16:01 [fantasai]
- cbiesinger: I would like to have that feature back
- 10:16:03 [fantasai]
- cbiesinger: discuss.
- 10:16:22 [fantasai]
- dbaron: You said Chrome implemented it. I'd like to see the definition of what Chrome implemented
- 10:16:36 [fantasai]
- TabAtkins: In particular our resolution was for you to tell us what you did so we can look at it :)
- 10:16:55 [TabAtkins]
- "Leaving the issue open to: hopefully get some info from @cbiesinger as he promised ^_^"
- 10:16:57 [fantasai]
- cbiesinger: Can write it up, but should I talk about it? or write it?
- 10:17:18 [fantasai]
- dbaron: I think there are a bunch of gaps in the specs, want to know how you would fill in the gaps
- 10:17:46 [heycam]
- fantasai: in the block axis, by saying it becomes auto, we're saying it becomes the max-content size
- 10:17:56 [heycam]
- ... the max content size, min content size, and auto size, are exactly the same
- 10:18:12 [heycam]
- cbiesinger: it doesn't work for min/max-height this doesnt work right now
- 10:18:21 [heycam]
- fantasai: and in that case, defining them to be teh same in the spe cdoesn't cause any problems
- 10:18:29 [heycam]
- dbaron: except the auto height of the block is a concept at layout time after you know the width
- 10:18:35 [heycam]
- ... whereas min/max content heights dont have a width to use
- 10:18:52 [heycam]
- ... and min/max content are referecned all over these other specs without saying it's at a particular width
- 10:18:58 [heycam]
- ... a particular block has a unique min content height
- 10:19:17 [heycam]
- ... if min-content and max-content are a function of width, then every spec that needs to use those concepts need to say what the width input is
- 10:19:20 [heycam]
- fantasai: I'm pretty sure grid does
- 10:19:25 [jensimmons]
- jensimmons has joined #css
- 10:19:25 [heycam]
- dbaron: pretty sure most specs don't
- 10:19:32 [heycam]
- fantasai: for block, you always have a iwdth
- 10:19:38 [heycam]
- dbaron: you have many widths. available width?
- 10:19:47 [heycam]
- ... intrinsic size of an orthogonal float...
- 10:19:53 [heycam]
- fantasai: that's defined in Wriitng Modes
- 10:20:04 [heycam]
- ... WMs says if you need the width you use viewport size plus some other calculations
- 10:20:16 [heycam]
- dbaron: does it say that for intrinsic size? i think it says to do that for layout, but these are different concepts
- 10:20:24 [heycam]
- fantasai: so you want to WMs to clarify to use it for both?
- 10:20:32 [heycam]
- cbiesinger: you could say it uses the width in the current layout mode
- 10:20:57 [heycam]
- dbaron: it's hard for me to argue this witout preparation, but the last time I went through the specs following spec links I couldn't find out how it was defined
- 10:20:59 [heycam]
- cbiesinger: I don't disagree
- 10:21:20 [heycam]
- fantasai: one thing that we are losing by defining everything ot be auto, if min/max content and auto size in block axis were always equal, it wouldn't matter
- 10:21:27 [heycam]
- ... but the problem is that in grid and flex, they have different emanings
- 10:21:35 [heycam]
- ... you get a different size, content lays out differently, in the block axis
- 10:21:47 [heycam]
- ... and being able to request those sizes and being able to use them within the context of other nested layouts is useful
- 10:22:00 [heycam]
- dbaron: but the spec right now pretends these are generic concepts across all layout systems, and not dervied from widths
- 10:22:08 [heycam]
- ... but layout systems define these all over without saying what width to use
- 10:22:15 [heycam]
- dbaron: cbiesinger and I agree that tihis is not currently defined in specs
- 10:22:25 [heycam]
- cbiesinger: are you objecting to the concept of this? or just the fact that this is currently not well defined
- 10:23:38 [heycam]
- Rossen: let's doubel down on the previous resolution
- 10:23:54 [heycam]
- dbaron: I think it's a huge arthicetctureal change for our layout code
- 10:24:00 [heycam]
- dbaron: I want it to be important and clearly defined before doing that
- 10:24:17 [heycam]
- dbaron: I think this is one of those things where you can get pretty close with a bunch of hacks, but that's not the same as following the spec
- 10:24:19 [heycam]
- ... and I still don't know what the spec is
- 10:24:37 [heycam]
- fantasai: you need to do some intrinsic sizing in the wrong axis to get grid/table to worth with orthogonal flows
- 10:24:52 [heycam]
- ... I think the architectural changes is whether you do this or not, and you already have to do it
- 10:24:58 [heycam]
- dbaron: right now in code hte functions that compute intrinsci size don't take a width argument
- 10:25:09 [heycam]
- ... and if these things are a function of width we need to work out what width to use for every caller
- 10:25:16 [heycam]
- ... some of this is complicated because intrinsic size is recursive
- 10:25:20 [heycam]
- ... it depends on all its descendants
- 10:25:37 [heycam]
- ... in some of these non-recurisve cases it could depend on layout, but we need to say what these cases are
- 10:25:59 [heycam]
- ... but I think there are cases where there are hundreds of calls to intrinsic size calculations across our code, we need to work out what to pass in
- 10:26:05 [fantasai]
- i/fantasai: in the block axis, by saying/ScribeNick: heycam/
- 10:26:08 [heycam]
- Rossen: I agree this is a large change if you are computing intrinsci size wihtout doing layout
- 10:26:20 [heycam]
- ... might be best to close this until we have details
- 10:26:37 [heycam]
- s/close this/close the discussion today/
- 10:26:45 [heycam]
- ... Christian has the action to write this up
- 10:27:45 [fantasai]
- ScribeNick: fantasai
- 10:27:56 [fantasai]
- Topic: Line grid and tests
- 10:28:16 [TabAtkins]
- ScribeNick: TabAtkins
- 10:28:20 [projector]
- projector has joined #css
- 10:28:31 [fantasai]
- github: https://github.com/w3c/csswg-drafts/issues/938#issuecomment-575499518
- 10:28:51 [Rossen]
- Rossen has joined #css
- 10:28:53 [TabAtkins]
- koji: we discussed quite a bit on issues for rhythm sizing last time two years ago
- 10:29:04 [TabAtkins]
- koji: as far as i understand, this issue was the most blocking for the feature
- 10:29:19 [TabAtkins]
- koji: Since then, Blink shipped LayoutNG. I didn't reimplement this in LayoutNG yet.
- 10:29:21 [shans]
- shans has joined #css
- 10:29:26 [TabAtkins]
- koji: Currently this test fails in all browsers.
- 10:29:35 [TabAtkins]
- koji: I don't see a way to solve this properly
- 10:29:51 [sylvaing]
- sylvaing has joined #css
- 10:30:08 [TabAtkins]
- florian: We talked about multiple solution for the double-sizing. What is the test assuming?
- 10:30:18 [TabAtkins]
- koji: We just have tests for rhythm-sizing in general.
- 10:30:22 [leaverou]
- leaverou has joined #css
- 10:30:47 [TabAtkins]
- florian: We have a spec, and tests; you fail because you don't ipmlement. That's normal, right?
- 10:30:50 [heycam]
- fantasai: what are the tests for? there's block step sizing and line step sizing
- 10:30:52 [plinss_]
- plinss_ has joined #css
- 10:30:56 [TabAtkins]
- fantasai: Were the tests for block step sizing, or line step sizing?
- 10:31:01 [TabAtkins]
- koji: line step sizing
- 10:31:23 [TabAtkins]
- koji: Question isn't about that, tho. I have to admit that I've got not great confidence on how I understand this accidental double-spacing issue.
- 10:31:26 [rego]
- are these the tests? https://wpt.fyi/results/css/css-rhythm?label=experimental&label=master&aligned
- 10:31:39 [TabAtkins]
- koji: But if I understand correctly, florian and astearns consider this a critical blocking issue.
- 10:31:53 [TabAtkins]
- koji: From my perspective, any solution can't avoid accidental double-spacing in some cases.
- 10:32:17 [astearns]
- q+
- 10:32:18 [TabAtkins]
- koji: So if we say accidental double-spacing fundamentally breaks the feature, we're basically saying CSS won't have this feature. Is that correct?
- 10:32:35 [TabAtkins]
- florian: Problem here is we want a vertical rhythm where the lines are the same size, and what to do when you can't have that.
- 10:32:55 [TabAtkins]
- florian: So either you break the rhythm and let some lines get bigger, or you double size the line to keep the rhythm.
- 10:33:08 [TabAtkins]
- florian: Can't avoid one or the other. What you can avoid is double-size when you don't need them to be.
- 10:33:28 [TabAtkins]
- florian: So if we have a mode where we double-size some of the time, making sure it doesn't happen gratuitiously, or in a brittle UA-dependent way, is the essential issue.
- 10:33:47 [TabAtkins]
- florian: So it's not "we can never have double sizing", it's "we have to be careful and make double-sizing happen consistently and predictably"
- 10:33:58 [tantek]
- rather than "that would be bad", can you state the desired fallback behavior?
- 10:34:03 [TabAtkins]
- hober: Isn't there a third option?
- 10:34:16 [TabAtkins]
- hober: Enforce the rhythm, and let the line overlap slightly.
- 10:34:22 [TabAtkins]
- florian: I think it's a bad one, but yes.
- 10:34:38 [TabAtkins]
- hober: I think some would prefer that.
- 10:34:51 [TabAtkins]
- florian: Circling back to koji's question, we ahve multiple specs addressing this problem.
- 10:35:15 [TabAtkins]
- florian: My feeling is that the most realistic part of this story is block-step-sizing; easiest and least brittle.
- 10:35:59 [fantasai]
- TabAtkins: Not going to break your layout if all your blocks are slightly larger in one browser than another
- 10:36:09 [fantasai]
- TabAtkins: but very broken if every line is double-spaced
- 10:36:29 [fantasai]
- faceless2: This only applies when line-height is normal?
- 10:36:32 [TabAtkins]
- faceless2: This only applies when line-height is normal, correct?
- 10:36:49 [TabAtkins]
- florian: Different concepts here. block-step-sizing ahs the problem without line-height.
- 10:36:54 [TabAtkins]
- florian: So they overlap to varying degrees.
- 10:37:56 [TabAtkins]
- fantasai: I think neither of these specs should be actively tested or implemented yet; I don't think we have great consensus on this as the correct solution yet.
- 10:38:14 [TabAtkins]
- fantasai: block-step-sizing doesn't have this sensitivity to inline layout or font rendering.
- 10:38:49 [TabAtkins]
- fantasai: So I think we could point to a wpt revision that had those tests, but I don't think we shoudl highlight failures before we have agreement on the concept at all.
- 10:38:52 [zcorpan]
- zcorpan has joined #css
- 10:39:10 [astearns]
- q?
- 10:39:54 [TabAtkins]
- fantasai: I think we need to handle font fallback in a more robust way. I think there's a lot of work to do to solve rhythmic sizing well, and a lot of that is solving inline layout problem generally.
- 10:40:06 [TabAtkins]
- koji: We could just set line-height and it works, tho.
- 10:40:15 [TabAtkins]
- fantasai: Right, but baseline-to-baseline spacing is still inconsistent.
- 10:40:35 [TabAtkins]
- fantasai: So because we have this discrepancy, almost all the time we trigger the double-spacing.
- 10:41:06 [TabAtkins]
- fantasai: So we want to clear this up, make the lines naturally rhythmic, so then when we need to *interrupt* the rhythm with something significantly different we can invoke rhythmic sizing.
- 10:41:17 [TabAtkins]
- koji: True for Latin, I don't think it's true for CJK.
- 10:41:39 [faceless2]
- q+
- 10:41:41 [TabAtkins]
- koji: Really just want to know if we should even be thinking about imlementing right now.
- 10:42:07 [TabAtkins]
- fantasai: I don't think so, no. If you remove those tests, drop a link to the last revision with them into the spec.
- 10:42:32 [TabAtkins]
- koji: Ok. But even block sizing has these problems too.
- 10:43:12 [TabAtkins]
- fantasai: I don't think so, no. rhythmic sizing *will* increase the size of blocks sometimes.
- 10:43:23 [TabAtkins]
- koji: We will have the same problems as text tho.
- 10:43:24 [TabAtkins]
- florian: How?
- 10:43:49 [TabAtkins]
- TabAtkins: If we have rendering differences in line heights, and the block height is based on text content, we'll have the same UA-dependent differences!
- 10:44:31 [TabAtkins]
- florian: If you size with lh unit, then...
- 10:45:05 [TabAtkins]
- florian: Really my issue is just about line-step-height. I don't think it's about block-step-height, but if you think there is, go ahead and open an issue about that.
- 10:45:52 [Rossen__]
- ack astearns
- 10:46:08 [TabAtkins]
- astearns: Elika went over a bit of my comment, but if th efeature isn't in active dev, I think it's perfectly fine to remove tests from WPT. I just approved a PR to remove all the Regions tests for this reason.
- 10:46:32 [TabAtkins]
- astearns: I'd prefer if there *was* active development - I don't think this issue is a blocker to doing work at all.
- 10:47:01 [TabAtkins]
- koji: So I hear consensus to remove the tests, and add warning to line-height-step and line-grid; block-step is fine.
- 10:47:12 [Rossen__]
- ack faceless2
- 10:47:17 [TabAtkins]
- faceless2: RealObjects have implemented this; I can't speak for how well.
- 10:47:18 [Rossen__]
- ack fantasai
- 10:47:23 [Rossen__]
- ack faceless
- 10:47:23 [TabAtkins]
- faceless2: AH have an implementation as well.
- 10:47:33 [TabAtkins]
- faceless2: We've got it too.
- 10:47:55 [TabAtkins]
- faceless2: I think this is all about the differences in what line-height:normal means between impls.
- 10:48:29 [Rossen__]
- q?
- 10:48:53 [TabAtkins]
- TabAtkins: I'll note that the ".tentative" substring in the filename is designed for this - tests that shouldn't be considered normative yet, but are in development.
- 10:49:16 [TabAtkins]
- Rossen__: So current proposal is to remove tests, add warnings to line-height-step and line-grid.
- 10:49:38 [TabAtkins]
- myles: What will the warning say?
- 10:49:45 [TabAtkins]
- florian: In line-height-step it can link to this issue.
- 10:49:57 [TabAtkins]
- florian: For line-grid, there are concerns, but no issue yet.
- 10:50:02 [TabAtkins]
- astearns: I can add the warning.
- 10:50:32 [TabAtkins]
- astearns: "We haven't figured everything out yet, but don't try to ipmlement blind assuming it's stable. Please give feedback if you're okay with working on bleeding edge."
- 10:50:59 [fantasai]
- <br>
- 11:01:59 [myles_]
- myles_ has joined #css
- 11:22:05 [RossenF2F]
- RossenF2F has joined #css
- 11:22:09 [stantonm]
- stantonm has joined #css
- 11:22:35 [jfkthame]
- jfkthame has joined #css
- 11:24:27 [jensimmons]
- jensimmons has joined #css
- 11:24:36 [dbaron]
- Topic: update on mod() function
- 11:25:01 [TabAtkins]
- https://twitter.com/tabatkins/status/1219936010961915905
- 11:25:10 [emilio]
- ScribeNick: emilio
- 11:25:11 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/2513
- 11:25:33 [emilio]
- TabAtkins: so the poll I started yesterday about mod has ended
- 11:25:54 [emilio]
- ... had some fair results, and the contradictory results I expected
- 11:26:16 [emilio]
- ... so 3/2 in favor of JS, 9/1 in favor of math, depending on how you ask
- 11:26:38 [emilio]
- ... so the conclusion is that most people just write buggy code and they think / want math semantics
- 11:26:49 [fantasai]
- /JS/JS semantics if you ask directly/
- 11:26:52 [emilio]
- ... there's also a lot of discussion in the replies about use-cases
- 11:26:54 [jensimmons]
- link to poll??
- 11:27:08 [fantasai]
- s/favor of math/favor of math if you ask them about a basic computation/
- 11:27:23 [emilio]
- ... and it seems math is a better suit to fix those use cases
- 11:27:35 [emilio]
- jfkthame: would people be better off with explicit is-odd / even functions
- 11:27:51 [fantasai]
- https://twitter.com/tabatkins/status/1219936010961915905
- 11:27:58 [fantasai]
- https://twitter.com/tabatkins/status/1219936010961915905
- 11:28:17 [emilio]
- TabAtkins: they sometimes use it as a proxy for odd / even, but it's not general of course
- 11:28:37 [TabAtkins]
- https://twitter.com/tabatkins/status/1219939184682717184
- 11:28:47 [emilio]
- TabAtkins: so no decision for now yet unless the room is convinced, but worth thinking about it and we can peek this up at a later call
- 11:29:20 [emilio]
- TabAtkins: how does the room feel? Did anyone change their mind?
- 11:30:09 [emilio]
- myles_: I guess there's a third option which is not defining what negatives does
- 11:30:17 [emilio]
- TabAtkins: that's what C++ does and that's evil
- 11:30:29 [emilio]
- myles_: I didn't mean to return unicorns but just explicitly return 0 or something
- 11:30:46 [emilio]
- TabAtkins: it seems negatives could be common, I wouldn't want that
- 11:30:54 [emilio]
- Rossen: seems not many opinions have changed so let's move on
- 11:31:18 [emilio]
- Topic: [css-transforms-1] 'view-box' definition doesn't make sense
- 11:31:35 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4662
- 11:31:44 [emilio]
- TabAtkins: the definition seems to not make sense
- 11:31:52 [emilio]
- ... the origin and size of the box are not related
- 11:32:15 [emilio]
- ... says that the origin of the coordinate space is the viewbox start
- 11:32:25 [emilio]
- ... and the size is the size of the viewbox
- 11:33:26 [emilio]
- ... so for example if you have a viewbox="20 20 100 100"
- 11:34:30 [emilio]
- ... the origin of the coordinate space is outside of the viewport, such as the origin is at (-20, -20)
- 11:34:53 [emilio]
- ... so that the viewbox is based off a rectangle outside of the svg's viewport
- 11:35:35 [emilio]
- heycam: so before CSS transforms, in svg you couldn't use percents inside transform so this was a non-issue
- 11:35:46 [emilio]
- ... I wonder if the issue is the way we're defining this rectangle
- 11:36:58 [emilio]
- ... Maybe it doesn't make sense to define that rect
- 11:37:15 [emilio]
- emilio: for percents in transforms you just need a basis so you don't need any origin right?
- 11:37:24 [RossenF2F]
- q?
- 11:37:25 [emilio]
- fantasai: yeah but other stuff references the view-box
- 11:37:37 [emilio]
- TabAtkins: and the origin matters for rotations and scales
- 11:37:41 [emilio]
- emilio: fair
- 11:38:17 [emilio]
- myles_: pretend you use transform-box: view-box and rotate by 3deg or something, what would you expect?
- 11:38:52 [emilio]
- TabAtkins: multiple acceptable answers, but the issue is that the size and the origin are not related, unlike other boxes
- 11:39:17 [emilio]
- fantasai: the issue is that this is how transforms have been defined in SVG
- 11:39:27 [emilio]
- fantasai: [reads AmeliaBR's comment in the issue]
- 11:39:42 [emilio]
- https://github.com/w3c/csswg-drafts/issues/4662#issuecomment-576496516
- 11:40:19 [emilio]
- TabAtkins: ok if it's what SVG uses by default then sure, whatever
- 11:40:29 [emilio]
- ... but I'd like it to be called out explicitly
- 11:40:53 [emilio]
- faceless2: The way we see the viewbox is just a translate transform
- 11:41:09 [emilio]
- ... I'm not sure it's as confusing as it sounds
- 11:41:31 [emilio]
- TabAtkins: my issue is that if you choose transform-origin: 100% 100% the point you get makes no sense
- 11:41:48 [emilio]
- ... but sure if it's legacy then fine, I thought it was invented recently as it was added after other changes
- 11:42:08 [emilio]
- ... so I'm ok with the behavior but I want to clarify that this is legacy svg behavior
- 11:42:29 [emilio]
- fantasai: there are other specs that reference these values somewhat inconsistently
- 11:42:43 [emilio]
- ... we copied them all out into the box model module
- 11:42:47 [TabAtkins]
- https://drafts.csswg.org/css-box/#keywords
- 11:43:23 [emilio]
- ... I want to change the definition of viewbox to account for this and then change all specs to reference those definitions
- 11:43:57 [emilio]
- ... any objections to doing that?
- 11:44:19 [emilio]
- RossenF2F: it seems something we should do, and seems we should close this with no change
- 11:44:30 [emilio]
- ... with the note added to the spec explaining why
- 11:44:42 [emilio]
- TabAtkins: I guess we'll add it to the box spec
- 11:44:45 [emilio]
- RossenF2F: sure
- 11:45:28 [emilio]
- fantasai: do we need another keyword to reference the box tab was talking about? (size of viewbox at the position of viewbox?)
- 11:45:31 [emilio]
- RossenF2F: probably not
- 11:45:40 [emilio]
- ... objections to the proposed resolution?
- 11:45:57 [emilio]
- RESOLVED: No change to the behavior, add a note to the spec
- 11:46:30 [emilio]
- RESOLVED: move the box keyword definitions on css-box and publish a new working draft
- 11:47:26 [emilio]
- RESOLVED: rebase the rest of the spec referring to these definitions to point to css-box
- 11:48:45 [emilio]
- fantasai: I propose to move the only non-css2 feature in css-box (margin-trim) to level 4 and move this to CR and co. fast so that other specs can depend on it
- 11:48:53 [emilio]
- RossenF2F: sounds reasonable, objections?
- 11:48:57 [fantasai]
- s/spe referring/specs referring/
- 11:49:06 [fantasai]
- s/spec referring/specs referring/
- 11:49:16 [emilio]
- RESOLVED: Move margin-trim to css-box-4 before republishing
- 11:49:50 [emilio]
- topic: scrollbar-gutter
- 11:50:07 [svillar]
- svillar has joined #css
- 11:50:12 [emilio]
- github: https://github.com/w3c/csswg-drafts/issues/4674
- 11:50:50 [emilio]
- cbiesinger: we're interested in implementing this: there's a lot of values for this property, and a lot of values didn't seem that useful to me
- 11:51:19 [emilio]
- ... florian came with some use cases but I'm not sure they're useful enough?
- 11:51:32 [emilio]
- iank_: we probably only want to implement stable
- 11:51:45 [emilio]
- florian: the other values were solving issues raised by google
- 11:51:58 [fantasai]
- s/and a lot/but a lot/
- 11:51:59 [emilio]
- ... we should explain them better in the spec
- 11:52:11 [emilio]
- ... but I'd be sad if we removed it
- 11:52:17 [myles_]
- q+
- 11:52:24 [emilio]
- cbiesinger: I think your explanation makes sense
- 11:52:38 [emilio]
- fantasai: seems to me this feature belongs on css-scrollbars, not css-ui
- 11:53:00 [hober]
- q+
- 11:53:04 [hober]
- q-
- 11:53:05 [emilio]
- florian: don't care, though I'm not an editor of css-scrollbars, so if you want me to keep editing it I should become an editor
- 11:53:19 [tantek]
- huh?
- 11:53:25 [emilio]
- RossenF2F: objections to move from css-ui to css-scrollbars and adding florian as an editor?
- 11:53:44 [florian]
- s/keep editing it/keep editing that feature/
- 11:53:47 [tantek]
- sorry I'm joining midconversation so I'm unaware of context
- 11:53:51 [heycam]
- from css-overflow, not css-ui
- 11:54:05 [fantasai]
- tantek, context is https://github.com/w3c/csswg-drafts/issues/4674
- 11:54:09 [TabAtkins]
- tantek, moving scrollbar-gutter to css-scrollbars
- 11:54:10 [emilio]
- RESOLVED: Move scrollbar-gutter to the scrollbars spec, add florian as an editor
- 11:54:10 [RossenF2F]
- ack myles_
- 11:54:13 [tantek]
- thanks fantasai
- 11:54:25 [emilio]
- myles_: we did a review with some people that know more about design than me
- 11:54:36 [emilio]
- ... this feature fundamentally breaks overlay scrollbars
- 11:54:49 [emilio]
- ... but we also understand that there's a real problem here
- 11:55:00 [emilio]
- ... and you don't want the scrollbar to cover things
- 11:55:25 [tantek]
- myles++ has a very good point
- 11:55:31 [emilio]
- ... there's also another issue (#4619) which proposes adding an environment variable with the width of the native scrollbars
- 11:55:39 [cbiesinger]
- q+
- 11:55:44 [emilio]
- ... it seems that'd allow authors to peek
- 11:56:15 [emilio]
- florian: I don't think the stable value changes anything with overlay scrollbars, it's the force value what's problematic for you right?
- 11:57:03 [emilio]
- myles_: any property that says "all elements should not be covered by overlay scrollbars" is problematic
- 11:57:27 [emilio]
- hober: we like the idea of moving active elements but we don't want to encourage authors to try to inset everything
- 11:57:34 [RossenF2F]
- q?
- 11:57:39 [emilio]
- cbiesinger: the env variable seems a better case for the google use case
- 11:57:42 [jensimmons]
- q?
- 11:57:45 [jensimmons]
- q+
- 11:58:13 [emilio]
- florian: I don't think it would because an env variable is for the entire page, so it doesn't depend on whether there actually are scrollbars
- 11:58:31 [emilio]
- cbiesinger: I meant the combination of the env variable with the stable value
- 11:58:51 [emilio]
- fantasai: but florian's point means that scrollbar width may change
- 11:59:11 [emilio]
- ... and you don't know the scrollbar width
- 11:59:20 [cbiesinger]
- q-
- 11:59:43 [emilio]
- myles_: the wide value is not really that wide, so probably just the wide one would be enough
- 11:59:56 [cbiesinger]
- s/4619/4691/
- 12:00:09 [tantek]
- we deliberately removed explicit numeric width from scrollbar-width. there's also no "wide" value
- 12:00:10 [tantek]
- https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width
- 12:00:11 [cbiesinger]
- https://github.com/w3c/csswg-drafts/issues/4691
- 12:00:25 [tantek]
- just: auto | thin | none
- 12:00:26 [emilio]
- myles_: I think the value should be zero for non-overlay scrollbars
- 12:01:33 [emilio]
- fantasai: we need both to align non-scrollable elements to scrollbars
- 12:01:41 [emilio]
- myles_: isn't that a problem now?
- 12:01:49 [emilio]
- florian: yes, but that's something that `scrollbar-gutter` solves
- 12:02:06 [emilio]
- ... the `always` toggle let you get the scrollbar gutter on elements that are not scrollable
- 12:02:14 [fantasai]
- The example is is a toolbar which is not scrollable over a scrollable box. The author wants the rightmost item in the toolbar to align with the rightmost item in the scrollable box.
- 12:02:17 [emilio]
- ... which lets you fix that
- 12:03:01 [tantek]
- q+ to ask if Blink also intends to implement scrollbar-color and scrollbar-width? if not, then it doesn't make sense to merge scrollbar-gutter with those properties, because they'll end up blocking each other in CR
- 12:03:06 [emilio]
- hober: in a world with that value and non-overlay scrollbars then that'd be zero
- 12:03:19 [hober]
- s/non-//
- 12:03:44 [tantek]
- there is no "thick"
- 12:03:55 [emilio]
- myles_: [[discussing with florian on the whiteboard]]
- 12:04:22 [tantek]
- scrollbar-width: auto
- 12:04:29 [tantek]
- is what I think people are trying to say?
- 12:04:55 [emilio]
- myles_: so you mean that we need two environment variables, one per scrollbar-width value?
- 12:05:03 [fantasai]
- The discussion is about how to know how thick to make the padding on the toolbar if the scroller has a 'scrollbar-width: thin' declaration - the solution currently is to say 'scrollbar-width: thin; scrollbar-gutter: always force' on the toolbar
- 12:05:12 [jensimmons]
- q-
- 12:05:14 [tantek]
- examples?
- 12:05:27 [tantek]
- agreed with myles
- 12:05:41 [emilio]
- florian: the thing that would fix this is `always`, people are already moving stuff away from the scrollbars, just guessing
- 12:05:56 [fantasai]
- s/guessing/guessing how wide they are/
- 12:05:56 [emilio]
- hober: so a variable that tells you how wide it is?
- 12:06:05 [tantek]
- good I want to hear Jensimmons's thoughts
- 12:06:19 [emilio]
- florian: as long as you can do that then I'm fine
- 12:06:29 [emilio]
- myles_: there are too many values
- 12:06:34 [florian]
- q?
- 12:06:45 [fantasai]
- ack tantek
- 12:06:45 [Zakim]
- tantek, you wanted to ask if Blink also intends to implement scrollbar-color and scrollbar-width? if not, then it doesn't make sense to merge scrollbar-gutter with those
- 12:06:47 [florian]
- q+
- 12:06:48 [Zakim]
- ... properties, because they'll end up blocking each other in CR
- 12:06:52 [tantek]
- re: https://github.com/w3c/csswg-drafts/issues/4674 "Blink is interested in implementing/shipping scrollbar-gutter"
- 12:06:54 [emilio]
- TabAtkins: some of them could be named better
- 12:07:13 [RossenF2F]
- q?
- 12:07:51 [emilio]
- tantek: I'd like to ask Google which other values besides stable is Blink interested in implementing, and is blink interested in implementing scrollbar-{width,color}?
- 12:08:15 [emilio]
- cbiesinger: def. interested in stable and the env variable, not so much in others
- 12:08:59 [TabAtkins]
- Okay, so I remember why we did "always" - "stable" means that authors still have to ensure their designs work on both widths. "always" was meant to be a "let authors safely be a little lazier" value.
- 12:09:10 [emilio]
- tantek: makes sense, and I tend to agree with myles_ that there's if there's no implementor interest and no use case maybe should be dropped
- 12:09:26 [emilio]
- cbiesinger: scrollbar-{width,color} is not on the roadmap
- 12:09:44 [emilio]
- iank_: not meaning we won't implement, but not on the roadmap
- 12:09:55 [TabAtkins]
- I feel strongly that if we do stable, we *need* force; that's the use-case Florian illustrated and it's very valuable I think.
- 12:10:00 [emilio]
- tantek: then I'd probably advocate for undoing the move to the scrollbars spec
- 12:10:15 [hober]
- hober: why not put them in different levels of the same spec?
- 12:10:17 [emilio]
- ... we'd have to do a lot of gymnastics
- 12:10:24 [TabAtkins]
- We can maybe drop "both" - it had use-cases that I think were mostly based on "always".
- 12:10:43 [emilio]
- fantasai: I think there's a benefit to have related features in the same spec
- 12:10:50 [fantasai]
- s/benefit/benefit to readers/
- 12:10:54 [TabAtkins]
- So perhaps an `auto | [ stable && force? ]` grammar reduction.
- 12:10:59 [emilio]
- ... keeping it in overflow doesn't make much sense
- 12:11:08 [emilio]
- tantek: I don't think there's any benefit of moving it
- 12:11:37 [bkardell_]
- what about what hober said?
- 12:11:47 [emilio]
- RossenF2F: I don't think we should do busywork just for the sake of doing it, but I do think that we should have scrollbar-related properties together to move them for the REC track, and for readers
- 12:11:53 [fantasai]
- hober, scrollbar-color and scrollbar-width already have one implementation
- 12:12:00 [fantasai]
- hober, scrollbar-gutter has an intent from Chrome
- 12:12:01 [emilio]
- ... this is why we have modules and levels
- 12:12:07 [fantasai]
- hober, it's not clear which is further ahead in that respect
- 12:12:12 [TabAtkins]
- q+
- 12:12:19 [fantasai]
- hober, and we're not even in CR, so there's no reason to drop anything atm
- 12:12:35 [emilio]
- RossenF2F: so we probably can still make a level of scrollbars be on the REC track with color/width
- 12:13:03 [emilio]
- tantek: given the fact that there's disagreement on what implementors are interested in I think that trumps the cosmetic use case
- 12:13:05 [bkardell_]
- "interest" and "priority" aren't the same though
- 12:13:17 [emilio]
- ... that practical divergence should override the cosmetic thing
- 12:13:21 [emilio]
- fantasai: but it's a WD
- 12:13:32 [emilio]
- tantek: right that's why I think busywork is not warranted
- 12:13:43 [TabAtkins]
- q?
- 12:14:02 [emilio]
- ... hearing from WebKit that they're interested in all three, otherwise just leave it alone?
- 12:14:27 [emilio]
- RossenF2F: let's try to avoid discussing process too much... Do you want to undo the previous resolution?
- 12:14:39 [myles_]
- q+
- 12:15:02 [emilio]
- tantek: yes, because the lack of interest from blink in scrollbar-width/color means we shouldn't do it
- 12:15:07 [emilio]
- iank_: that's a misrepresentation
- 12:15:12 [fantasai]
- I want to point out that oveflow-4 is otherwise completely experimental stuff and is not an appropriate place for a feature that is being imminently implemented
- 12:15:43 [tantek]
- fantasai then move the experimental stuff in overflow-4 to overfow-5
- 12:15:43 [RossenF2F]
- q?
- 12:15:50 [emilio]
- jensimmons: interest is not the same as saying not on the roadmap
- 12:15:53 [tantek]
- don't make extra busy work for multiple specs
- 12:15:54 [fantasai]
- tantek, it's not an overflow feature, it's a scrollbar feature
- 12:15:59 [emilio]
- iank_: It just meant not in the roadmap at the moment
- 12:16:04 [fantasai]
- tantek, it doesn't belong in that module
- 12:16:05 [emilio]
- ... that may change in the future
- 12:16:06 [tantek]
- overflow and scrolling are tightly related
- 12:16:08 [TabAtkins]
- tantek, stop objecting to other people volunteering to do work
- 12:16:18 [tantek]
- fantasai quit making an aesthetic argument
- 12:16:38 [emilio]
- cbiesinger: I'm more skeptical about the scrollbar width use case, we just don't plan to implement it soon
- 12:16:47 [fantasai]
- tantek, it's a usability argument. I want our specs to not be GCPM-style hodgepodgs
- 12:16:51 [tantek]
- I'm saying postpone until we get positive signals from implementers for all three properties
- 12:16:55 [emilio]
- RossenF2F: there are other implementors other than google :-)
- 12:17:05 [tantek]
- I'm arguing for more modularity not less
- 12:17:13 [tantek]
- anyway my objection to the previous resolution is recorded
- 12:17:15 [TabAtkins]
- tantek, one property per spec?
- 12:17:19 [emilio]
- TabAtkins: yeah we try to be extremely clear when objecting because we understand it's a powerful statement
- 12:17:22 [RossenF2F]
- q?
- 12:17:39 [tantek]
- TabAtkins: no I'm not interested in strawman like that or fantasai's "GCPM-style hodgepodgs"
- 12:17:44 [tantek]
- seriously, not good faith arguments
- 12:17:44 [RossenF2F]
- ack florian
- 12:18:21 [emilio]
- florian: I heard calls for dropping values and I'd like to push back. We designed this for years in response to use cases. I'm happy to document what the use cases were and maybe rename values so they're better names
- 12:18:29 [tantek]
- starting by removing things that lack a reason is the right thing to do
- 12:18:35 [emilio]
- ... but until that's done I don't think we should drop values
- 12:18:45 [tantek]
- hober++
- 12:18:53 [RossenF2F]
- q?
- 12:18:54 [emilio]
- hober: that's some work in order to chop things, we'd rather do that now
- 12:19:09 [tantek]
- I'm really not sympathetic to features without examples/explanations up front
- 12:19:18 [emilio]
- florian: it's just some examples, and I'm sure we won't chop it off
- 12:19:27 [hober]
- s/we'd rather do that now/i'd rather spare you the work and chop them now/
- 12:19:27 [emilio]
- dbaron: I'd say that's a reason why explainers should have explainers with what they're trying to solve
- 12:19:45 [emilio]
- myles_: I don't think that actually conflicts with the env variable proposal
- 12:19:49 [dbaron]
- s/explainers should/specs should/
- 12:20:11 [tantek]
- if you can't link to the examples / explanations, consider them non-existent
- 12:20:31 [emilio]
- florian: I recall people saying there are no use cases but they were, and I'll spend some time cleaning up this and investigate dropping these after we remember what they're for?
- 12:20:55 [tantek]
- florian: if you want to postpone dropping, then why not postpone merging also? why is that kind of tentative reasoning good for one postponement and not another?
- 12:21:07 [tantek]
- feels pretty inconsistent
- 12:21:10 [emilio]
- TabAtkins: I think we agree that stable or something that implements that is good, and that env doesn't solve it
- 12:21:23 [emilio]
- ... I think `force stable` seems reasonable too
- 12:21:51 [emilio]
- ... as that is what you can use to align
- 12:21:59 [emilio]
- ... non-scrollable things to scrollable things
- 12:22:07 [emilio]
- cbiesinger: you can use that with the env variable right?
- 12:22:17 [emilio]
- TabAtkins: yes
- 12:22:28 [emilio]
- florian: don't you need a media query for overlay scrollbars?
- 12:22:39 [emilio]
- emilio: env variable would be zero in that case
- 12:22:55 [emilio]
- TabAtkins: always is the one you were more skeptical about
- 12:23:23 [tantek]
- TabAtkins: "I could see dropping this for now"
- 12:23:39 [emilio]
- ... it's done so that you can consistently design stuff across systems
- 12:23:46 [emilio]
- ... I could see us dropping always for now
- 12:24:05 [emilio]
- ... `both` is intended for always and it seems to be a lot less valuable with stable
- 12:24:11 [emilio]
- ... and I think we can drop it for now too
- 12:24:35 [emilio]
- ... so we can probably drop them and use `stable` with the `force` keyword, or with the `env()` variable
- 12:24:37 [emilio]
- myles_: sounds reasonable
- 12:24:46 [hober]
- q+
- 12:24:53 [RossenF2F]
- ack TabAtkins
- 12:25:16 [emilio]
- fantasai++
- 12:25:40 [jensimmons]
- q?
- 12:25:42 [emilio]
- florian: my proposal is to revisit this in a week or three
- 12:25:58 [emilio]
- ... once we have the cases and alternatives clear
- 12:26:13 [fantasai]
- s/cases/cases described/
- 12:26:19 [tantek]
- if you're postponing dropping, then postpone merging
- 12:26:34 [tantek]
- why is postponing ok for one and not the other?
- 12:26:34 [TabAtkins]
- tantek, I'm not happy with you apparently misquoting me to make a point opposite what I'm supporting
- 12:26:39 [fremy]
- fremy has joined #css
- 12:26:47 [myles_]
- q-
- 12:26:54 [RossenF2F]
- ack hober
- 12:26:55 [emilio]
- hober: I wanted to reply to tab
- 12:27:17 [emilio]
- ... you said that you're ok dropping always and both, and then between stable + force, or stable + env() you're indifferent right?
- 12:27:27 [emilio]
- ... I prefer the env variable
- 12:27:36 [cbiesinger]
- q+
- 12:27:47 [emilio]
- ... I think it should be an exceptional thing done with particular descendants, and the env variable encourages this a bit more
- 12:27:49 [RossenF2F]
- Zakim, close queue
- 12:27:49 [Zakim]
- ok, RossenF2F, the speaker queue is closed
- 12:28:03 [emilio]
- TabAtkins: are you ok with adding more than two values for different widths?
- 12:28:11 [emilio]
- hober: we can get to that once it comes up
- 12:28:16 [RossenF2F]
- ack cbiesinger
- 12:28:33 [emilio]
- cbiesinger: I agree with hober though for different reasons. I think env() is more understandable for authors than `stable force`
- 12:28:43 [tantek]
- I agree with cbiesinger, so don't bother with moving a dead property into a different spec
- 12:28:53 [emilio]
- RossenF2F: so next steps florian brings the use cases for the current design
- 12:29:01 [cbiesinger]
- well the property isn't dead, just maybe some values of it
- 12:29:02 [hober]
- hober: i think we have multi-engine agreement here, which seems worth noting
- 12:29:43 [tantek]
- Thanks Rossen for clarifying purpose of scrollbars spec. You're right we should have started there
- 12:29:53 [tantek]
- Rossen++ for upleveling the conversation
- 12:29:54 [emilio]
- RossenF2F: Re. merging, scrollbar-width/color just styles controls... scrollbar-gutter is more about the box model
- 12:30:10 [emilio]
- ... so let's not move everything to scrollbars yet until we know what will remain there
- 12:30:17 [tantek]
- That sounds like I need to better document scope in the Scrollbars spec
- 12:30:31 [emilio]
- ... next call we'll see whether we stick to that resolution
- 12:30:32 [tantek]
- TabAtkins: I've grown very intolerant of time-wasting aesthetics.
- 12:31:17 [emilio]
- jensimmons: I like it when this group is able to have discussions and make space for each other instead of going back and forth
- 12:31:58 [TabAtkins]
- ScribeNick: TabAtkins
- 12:32:15 [TabAtkins]
- Topic: safe-area-insets
- 12:32:19 [RossenF2F]
- github:https://github.com/w3c/csswg-drafts/issues/4670
- 12:32:36 [TabAtkins]
- emilio: there's no explicit area in env() spec about how safe-area-inset behaves in iframes
- 12:32:48 [TabAtkins]
- emilio: ipmls disagree. We're doing some related work, would like it clarified.
- 12:33:11 [TabAtkins]
- emilio: If iframes are nested, they may not care about safe areas, etc.
- 12:34:01 [TabAtkins]
- TabAtkins: Who's responsible for this spec?
- 12:34:04 [TabAtkins]
- heycam: dino and you
- 12:34:11 [TabAtkins]
- TabAtkins: I'm there for processing model, not values. ^_^
- 12:34:13 [RossenF2F]
- Zakim, open queue
- 12:34:13 [Zakim]
- ok, RossenF2F, the speaker queue is open
- 12:34:17 [TabAtkins]
- hober: I'm happy to bug dean about this.
- 12:34:56 [TabAtkins]
- TabAtkins: Can you (emilio) tag dino into the thread?
- 12:34:59 [TabAtkins]
- emilio: Yes
- 12:35:04 [TabAtkins]
- Topic: animating ui controls
- 12:35:23 [RossenF2F]
- github:https://github.com/w3c/csswg-drafts/issues/3153
- 12:36:06 [TabAtkins]
- fantasai: I thought we resolved this topic last year. I think we should be marking these properties as discretely aniamtable? (nav-up, user-select, etc)
- 12:36:11 [TabAtkins]
- fantasai: Stuff in the UI spec.
- 12:36:36 [TabAtkins]
- dbaron: I think we've only marked things as non-animatable when there are technical problems, like animation-* or display.
- 12:36:42 [tantek]
- is that really the right default?
- 12:36:46 [tantek]
- q+
- 12:36:49 [TabAtkins]
- fantasai: That's my understanding, so I think we just close this issue?
- 12:37:15 [TabAtkins]
- florian: I agree we only make things impossible when it's technically hard, and I don't that the css-ui things are that. I think they should be switched to discrete explicitlyh.
- 12:37:55 [tantek]
- q?
- 12:37:57 [TabAtkins]
- florian: So if anything in CSS UI is still marked as non-animatable, we should fix that to say "discrete"
- 12:38:16 [RossenF2F]
- ack tantek
- 12:38:21 [TabAtkins]
- tantek: Something dbaron said about non-animatable.
- 12:38:33 [TabAtkins]
- tantek: I agree that's been our historical default, but I'm wondering if that's acutally desirable.
- 12:38:48 [TabAtkins]
- tantek: At minimum, every time we mark something animatable, that implies we need tests for that, that the animation works.
- 12:38:53 [heycam]
- q+
- 12:38:55 [florian]
- q+
- 12:39:16 [TabAtkins]
- tantek: So those are all costs. So is that rule a sufficient default? In this particular case, it feels kinda weird to animate these particular proeprties.
- 12:39:35 [TabAtkins]
- tantek: I want to know florian's opinion on this. But my intuition is that there's no use-case for these particular properties.
- 12:39:43 [emilio]
- q+
- 12:39:59 [TabAtkins]
- dbaron: As far as use-cases, peopel use animations in contexts where they animate some UI in from not being there, then "turn it on".
- 12:40:17 [TabAtkins]
- dbaron: I could imagine setting nav-up as part of turning it on. Maybe it could have been there all the time, but it seems plausible to do.
- 12:40:31 [TabAtkins]
- tantek: That's the kind of reasoning I'm happy to have on the reasoning.
- 12:40:41 [TabAtkins]
- s/the reasoning/the record/
- 12:41:17 [florian]
- q?
- 12:41:23 [TabAtkins]
- tantek: If you're animating layout, you might need to animate the nav-* props; seems weird but I've seen weirder.
- 12:41:34 [RossenF2F]
- ack heycam
- 12:41:41 [TabAtkins]
- TabAtkins: And Lea has brought up examples in the past of odd-seeming animations; I think there's probably an example for everything.
- 12:42:00 [TabAtkins]
- heycam: I think there's value in having the blanket rule of "animatable unless impossible" vs lots of use-case analysis.
- 12:42:10 [RossenF2F]
- ack florian
- 12:42:12 [TabAtkins]
- heycam: And if something's not animatable we ahve to write tests for that anyway, so same amoutn of work.
- 12:42:16 [emilio]
- q-
- 12:42:16 [TabAtkins]
- florian: Agree on testing.
- 12:42:19 [tantek]
- q?
- 12:42:33 [tantek]
- good point heycam
- 12:42:54 [TabAtkins]
- florian: And note it's also about transitions. "animate or not" tells you whether the transition happens at the middle or at the beginning (or end? don't remember). So it has to switch anyway.
- 12:43:15 [tantek]
- is there a use-case for user-select animating?
- 12:43:23 [TabAtkins]
- florian: display, animation, etc can't be switched at all for technical reasons, but everything else we're just deciding where in the animation it switches, and there's no good reason to ban it from choosing where to switch.
- 12:43:24 [tantek]
- (figured I'd just ask in IRC instead of q+ for that)
- 12:43:50 [tantek]
- what are we making user-select consistent with?
- 12:43:56 [TabAtkins]
- florian: I agree that user-select doesn't appear to ahve a use-case, but for aforestated reasons having an exception here doesn't seem to be useful; we stil have to pick one way or the other.
- 12:43:59 [heycam]
- tantek, perhaps for similar reasons as dbaron mentioned about some UI animating in. maybe you want it not to respond to user interaction until the animation is done, or at a certain point
- 12:44:03 [fantasai]
- all other properties in CSS that use keyword values
- 12:44:05 [RossenF2F]
- q?
- 12:44:15 [tantek]
- ok heycam. good enough for now.
- 12:44:42 [TabAtkins]
- tantek, more importantly to florian's point, transitioning the property makes it swap at some point regardless, its 'justa bout whether it's possible to choose where it transitions or not.
- 12:44:49 [TabAtkins]
- RossenF2F: So close as accepted? Any objections?
- 12:45:18 [TabAtkins]
- RESOLVED: Mark user-select as discretely animatable, not non-animatable.
- 12:45:22 [tantek]
- TabAtkins: ok that's the consistency I was looking for. thanks.
- 12:45:39 [TabAtkins]
- Topic: triaging specs
- 12:45:42 [tantek]
- s/TabAtkins:/TabAtkins,
- 12:47:45 [TabAtkins]
- Topic: where does constructable stylesheets live?
- 12:47:53 [TabAtkins]
- heycam: Spec is currently in wicg
- 12:47:59 [TabAtkins]
- emilio: Resolution to put it in cssom
- 12:48:12 [TabAtkins]
- emilio: Discussion about whether to put it in level 2, or a diff spec, or same document. I'd prefer it same document.
- 12:48:55 [TabAtkins]
- TabAtkins: We can ask Rakina if she wants to do the work or let you do it. I agree putting it in CSSOM1 is best.
- 12:48:58 [TabAtkins]
- RossenF2F: Any objections?
- 12:49:31 [TabAtkins]
- RESOLVED: CSS() is merged into CSSOM1 (either emilio or rakina doing so)
- 12:49:51 [TabAtkins]
- Topic: CSS() and frozenarray
- 12:49:52 [RossenF2F]
- github: https://github.com/WICG/construct-stylesheets/issues/45
- 12:50:14 [TabAtkins]
- heycam: context of me raising this is that we'd like to ship soon. there's a bunch of issues, but these four seem most worth discussing.
- 12:50:31 [TabAtkins]
- heycam: last time this was discussed, there was a hope that tc39 would define some new mechanism for array-like things.
- 12:50:46 [TabAtkins]
- heycam: Last comment in the issue was that some small aspect would be introduced, but not the whole use-case.
- 12:51:01 [TabAtkins]
- heycam: I'm not happy with FrozenArray either, and hopefully we can move to a better compat model in the future.
- 12:51:16 [TabAtkins]
- heycam: But I'd like to see if we're definitely not going to move to an explicit .add()/.remove() methods
- 12:51:22 [TabAtkins]
- hober: Speaking for Ryosuke...
- 12:51:31 [tantek]
- heycam, could you comment in https://github.com/WICG/construct-stylesheets/issues/45 accordingly? I didn't see any reference to TC39 there
- 12:51:34 [TabAtkins]
- hober: He's very opposed to FrozenArray, and wants to move back to add/remove methods
- 12:51:42 [astearns]
- q?
- 12:51:42 [hober]
- https://github.com/w3c/webcomponents/issues/759#issuecomment-521053064
- 12:51:44 [TabAtkins]
- hober: He says FrozenArray encourages racy code.
- 12:51:48 [jensimmons]
- jensimmons has joined #css
- 12:51:59 [TabAtkins]
- hober: (example above)
- 12:52:49 [TabAtkins]
- TabAtkins: Now that Domenic has left TC39, we don't have anyone really pushing for it anymore.
- 12:53:13 [TabAtkins]
- heycam: I'd be happy to change away from frozenarray, but I want to make sure that, since Chrome is shipping right now, they'd be okay with changing.
- 12:54:39 [TabAtkins]
- TabAtkins: I think we're fine with changing since it's an early change, but FrozenARray is what IDL is recommending right now, and there's advice to explicitly not add new listish collections.
- 12:55:00 [tantek]
- TabAtkins, since you attend both CSSWG TC39, and I did once, should one of us pick up liaisoning?
- 12:55:09 [hober]
- q?
- 12:55:11 [hober]
- q+
- 12:55:24 [TabAtkins]
- emilio: I don't think we need a new collection; we can add functions to document.shadowRoot, like .insertAdoptedStylesheet() and .removeAdoptedStylesheet(), and maybe just .appendAdoptedStylesheet().
- 12:55:49 [tantek]
- I just want to make sure that if we (CSSWG) want something from TC39, that we capture that in our issue, and that one of us commit to filing a respective issue in a TC39 repo (I can help with this, but also happy to defer to TabAtkins)
- 12:56:14 [TabAtkins]
- TabAtkins: Not to get too in the weeds, but how would the adopted sheets be exposed?
- 12:56:34 [TabAtkins]
- hober: Just a CSSStylesheetList, still hanging off of .adoptedStylesheets
- 12:56:43 [fantasai]
- ScribeNick: fantasai
- 12:56:47 [fantasai]
- TabAtkins: I think that's OK, sure
- 12:57:01 [RossenF2F]
- q?
- 12:57:05 [RossenF2F]
- ack hober
- 12:57:10 [fantasai]
- hober: I wanted to follow up on what emilio said seems fine
- 12:57:19 [fantasai]
- hober: Problem here, we all agree, CSSOM is not great
- 12:57:29 [fantasai]
- hober: What I like about the resolution isn't that it contnues CSSOM parts we don't like
- 12:57:55 [fantasai]
- hober: It's a feature addition to CSSOM that's compatible with CSSOM, but does not prevent us from coming back and fixing all of CSSOM
- 12:58:02 [fantasai]
- hober: Let's make all the same mistakes we've always made
- 12:58:08 [fantasai]
- hober: even though it's not a design we're not crazy about
- 12:58:11 [fantasai]
- hober: and come back and fix it all later
- 12:58:27 [fantasai]
- TabAtkins: Are we sure that CSSStyleSheetList can be upgraded to an Arraylike?
- 12:58:31 [fantasai]
- hober: idk
- 12:58:38 [fantasai]
- bkardell_: CSSOM.next context?
- 12:58:41 [fantasai]
- TabAtkins: Yes. I think we can
- 12:58:45 [fantasai]
- TabAtkins: would be nice to know for sure
- 12:58:52 [fantasai]
- heycam: Depends on particular solution
- 12:58:57 [plh]
- plh has joined #css
- 12:59:28 [fantasai]
- heycam: Emilio's suggestion is to add the mutating methods on the shadow root and not on the style sheet list object, right?
- 12:59:43 [Karen]
- Karen has joined #css
- 12:59:54 [fantasai]
- heycam: A little weird and different that the object that exposes the list of items is not the same object on which you have the mutating methods
- 13:00:10 [fantasai]
- emilio: How different from CSSGroupingRule having ?? or CSSStyleSheetRule having ???
- 13:00:15 [fantasai]
- heycam: You're right, it's already weird!
- 13:00:20 [TabAtkins]
- s/??/.insertRule()/
- 13:01:32 [fantasai]
- Proposed: Make adopted stylesheets a CSSStyleSheetList and add the appropriate add/remove methods to the document or shadowRoot interface
- 13:01:39 [tantek]
- Is there any outstanding request for TC39? Or did that get dropped?
- 13:01:45 [fantasai]
- heycam: Compared to CSSStyleSheetRule, there's no appendment?
- 13:01:48 [fantasai]
- emilio: ...
- 13:01:57 [dbaron]
- s/appendment/append method/
- 13:02:05 [TabAtkins]
- tantek, we believe we can still upgrade the CSSSTyleSheetList into an ArrayLike in the future.
- 13:02:23 [emilio]
- s/.../ but I mentioned append because I suspect that's what more people would do
- 13:02:24 [fantasai]
- hober: Tantek raises question, should we communicate our continued interest in this problem to TC39? And how?
- 13:02:31 [fantasai]
- TabAtkins: We need a champion, interest isn't enough.
- 13:02:35 [fantasai]
- TabAtkins: I'm overloaded, so I can't do it
- 13:02:43 [fantasai]
- TabAtkins: for Arraylikes
- 13:02:49 [fantasai]
- hober: We can ask our reps on the group to mention it
- 13:02:51 [tantek]
- Can we capture in an issue at least? Even without a champion?
- 13:02:58 [tantek]
- Thanks hober
- 13:03:05 [fantasai]
- ACTION hober, TabAtkins, heycam : Ask TC39 reps to advocate Arraylike
- 13:03:10 [TabAtkins]
- tantek, without a champion nothing will move
- 13:03:15 [fantasai]
- RESOLVED: Make adopted stylesheets a CSSStyleSheetList and add the appropriate add/remove methods to the document or shadowRoot interface
- 13:03:21 [fantasai]
- <br type=lunch>
- 13:03:36 [tantek]
- TabAtkins, I'm ok with filing an issue to at least capture it and maybe a champion finding that after
- 13:03:38 [TabAtkins]
- tantek, And I've clearly communicated our desire for it several times over the last several years. ^_^
- 13:03:39 [emilio]
- topic: end
- 13:03:50 [TabAtkins]
- github-bot: end topic
- 13:03:53 [tantek]
- "clearly communicated"? meaning you already filed an issue? or in-person in TC39?
- 13:04:06 [tantek]
- I don't want to duplicate your work to be clear :)
- 13:04:16 [RossenF2F]
- github-bot, end topic
- 13:04:19 [heycam]
- in person
- 13:04:21 [heycam]
- there's already an issue
- 13:38:18 [zcorpan]
- zcorpan has joined #css
- 13:41:58 [plh_]
- plh_ has joined #css
- 13:42:51 [jfkthame]
- jfkthame has joined #css
- 13:49:05 [Karen]
- Karen has joined #css
- 14:01:32 [astearns]
- Ah, github-bot didn't comment on the issue because it's a WICG one
- 14:01:53 [myles]
- myles has joined #css
- 14:04:41 [dauwhe]
- dauwhe has joined #css
- 14:05:39 [skk]
- skk has joined #css
- 14:08:15 [stantonm]
- stantonm has joined #css
- 14:09:25 [astearns]
- waiting for enough people to get back in the room to resume
- 14:12:58 [TabAtkins]
- tantek, yeah, in person. talked to a bunch of the active editors/champions about this over the years
- 14:13:31 [emilio]
- https://usercontent.irccloud-cdn.com/file/xHjVjvtb/csswg.png
- 14:13:41 [astearns]
- dbaron, can you make the bot aware of the WICG repo?
- 14:15:06 [stantonm]
- ScribeNick: stantonm
- 14:15:48 [TabAtkins]
- "the WICG repo" doesn't exist, it's a ton of repos. But yeah it would be good to be allowed to comment on repos in that user.
- 14:16:13 [tantek]
- Thanks TabAtkins, this is not a priority for me so I'll defer to your experience here. If you decide you want liaison help on this, I may have some cycles (and interest in helping TC39 / CSSWG comms)
- 14:16:22 [igalia]
- igalia has joined #css
- 14:16:50 [TabAtkins]
- whoever your tc39 manager is, just talk to them about this. i'll be talking to shu.
- 14:17:09 [tantek]
- I need a link for "this" to do that 😂
- 14:17:20 [tantek]
- Yulia is our TC39 lead
- 14:18:03 [dbaron]
- github-bot, reboot
- 14:19:52 [stantonm]
- topic: CSSStyleSheetInit dictionary may have unintended usage
- 14:20:01 [astearns]
- github: https://github.com/WICG/construct-stylesheets/issues/105
- 14:20:09 [jensimmons]
- jensimmons has joined #css
- 14:20:23 [github-bot]
- github-bot has joined #css
- 14:20:36 [RossenF2F]
- RossenF2F has joined #css
- 14:20:39 [stantonm]
- topic: CSSStyleSheetInit dictionary may have unintended usage
- 14:20:46 [stantonm]
- github: https://github.com/WICG/construct-stylesheets/issues/105
- 14:20:57 [stantonm]
- topic: CSSStyleSheetInit dictionary may have unintended usage
- 14:21:04 [stantonm]
- github: https://github.com/WICG/construct-stylesheets/issues/105
- 14:21:10 [chris]
- chris has joined #css
- 14:21:16 [chris]
- present+
- 14:21:21 [chris]
- rrsagent, here
- 14:21:21 [RRSAgent]
- See https://www.w3.org/2020/01/23-css-irc#T14-21-21
- 14:21:39 [stantonm]
- heycam: css stylesheet interface has constructor, allows to set various things on the stylesheet
- 14:21:51 [stantonm]
- ... seems like allows combinations of things that are not valid
- 14:22:04 [stantonm]
- ... specifically creating stylesheet with empty title
- 14:22:37 [stantonm]
- emilio: only use for title and alternate is compute disabled bit
- 14:22:46 [stantonm]
- emilio: don't see anything useful
- 14:22:57 [stantonm]
- TabAtkins: so your saying we should just remove it?
- 14:22:59 [stantonm]
- emilio: yes
- 14:23:29 [stantonm]
- chris: don't need it not necessary
- 14:24:21 [stantonm]
- emilio: title attribute sets preferred stylesheet list, why it doesn't apply in shadow dom
- 14:24:32 [stantonm]
- ... don't know what it means for ransom constructible stylesheet
- 14:24:40 [stantonm]
- ... just use .disabled attribute
- 14:24:48 [fremy]
- fremy has joined #css
- 14:24:54 [stantonm]
- heycam: remove constructor, and force .disabled?
- 14:25:40 [stantonm]
- emilio: title doesn't work in shadow dom
- 14:26:04 [stantonm]
- ... reason title is useful is because browsers provide UI for switching
- 14:26:22 [stantonm]
- ... .disable is still fine
- 14:26:42 [stantonm]
- christ: used to be more visible for, but some functionality moved away
- 14:27:05 [stantonm]
- RESOLVED: remove title and alternate from constructor
- 14:27:22 [stantonm]
- topic: Defined location/href of Constructed Stylesheets
- 14:27:27 [astearns]
- github: https://github.com/WICG/construct-stylesheets/issues/95
- 14:27:56 [stantonm]
- heycam: regular non-constructable style sheets have url to resolve other stylesheets
- 14:28:07 [stantonm]
- with constructable, no facility to provide url
- 14:28:15 [stantonm]
- ... regular urls are resolved against document
- 14:28:27 [stantonm]
- ... you might want to be able to specify
- 14:28:57 [stantonm]
- TabAtkins: web component wants css to also be relative to some 3rd party url?
- 14:29:20 [stantonm]
- ... can't hardcode deployment url, how do you use to it to get relative url
- 14:29:52 [stantonm]
- ... when user says background.png, want it to use 3rd party load path - currently uses first party
- 14:30:47 [stantonm]
- heycam: read issue as today there's not a good way to do this
- 14:31:15 [stantonm]
- TabAtkins: splitting parts of URL, base part still might be hard to obtain
- 14:31:55 [stantonm]
- ... url is hardcoded somewhere...just elsewhere than your stylesheet pipeline
- 14:32:15 [stantonm]
- hober: probably fine to set base and location as specified
- 14:32:49 [stantonm]
- heycam: not speficying url of sheet itself
- 14:32:59 [stantonm]
- hober: yes, sheet url is same as document url
- 14:33:46 [jensimmons]
- jensimmons has joined #css
- 14:35:26 [stantonm]
- RESOLVED: add base URL constructor argument for sole purpose of resolving relative URLs in stylesheet, and location of the stylesheet remains that of the document
- 14:36:42 [TabAtkins]
- TabAtkins: And do we need to note the security concerns that bz raised, like with file:// etc?
- 14:37:05 [TabAtkins]
- hober: Those are addressed by instead doing this as just a relative-url resolver, and keeping the stylesheet location the same.
- 14:37:07 [TabAtkins]
- TabAtkins: Cool.
- 14:37:19 [stantonm]
- topic: Should adoptedStyleSheets be ordered before other style sheets in the tree, instead of after?
- 14:37:20 [astearns]
- github: https://github.com/WICG/construct-stylesheets/issues/93
- 14:37:26 [faceless2]
- faceless2 has joined #css
- 14:37:34 [stantonm]
- github: https://github.com/WICG/construct-stylesheets/issues/93
- 14:37:46 [lajava]
- lajava has joined #css
- 14:38:21 [stantonm]
- heycam: spec says orderering of stylesheets should be ?, but actually should it be other way around?
- 14:38:48 [heycam]
- https://github.com/WICG/construct-stylesheets/issues/93#issuecomment-487772869
- 14:38:55 [bkardell_]
- q+
- 14:39:21 [stantonm]
- TabAtkins: my comment says make sense to put after
- 14:39:40 [stantonm]
- emilio: don't think there's a strong reason for one or other
- 14:39:57 [stantonm]
- hober: agree, but is there consistency arguments?
- 14:40:06 [stantonm]
- TabAtkins: maybe related to @font-face, which is after
- 14:40:23 [anssik]
- anssik has joined #css
- 14:40:47 [astearns]
- ack bkardell_
- 14:41:09 [stantonm]
- bkardell_: talking about shadow root and document styles, strangely related - some things bleed through, some blocked
- 14:41:27 [stantonm]
- ... not sure I get what ordering means
- 14:41:45 [stantonm]
- ... would like them to come before
- 14:42:01 [tantek]
- tantek has joined #css
- 14:42:04 [stantonm]
- ... different use cases, adopt styles from outside
- 14:42:38 [stantonm]
- TabAtkins: all sheets that come from markup come before adopted style sheets
- 14:43:01 [stantonm]
- bkardell_: we want to use these for UA equivilent, seems like not the right move
- 14:43:27 [stantonm]
- TabAtkins: adopted style sheets help when people put things directly in shadow dom
- 14:43:42 [stantonm]
- ... component usage will move to adopted style sheets, gives full control
- 14:43:57 [stantonm]
- ... if you use style inline, it's baked into the template
- 14:44:14 [stantonm]
- ... similar to link style sheet in head, where you override with adopted
- 14:44:32 [stantonm]
- ... both ordering can make sense, no strong argument
- 14:44:42 [stantonm]
- bkardell_: we don't know which is correct
- 14:45:06 [stantonm]
- hober: if we don't know, ask the author
- 14:45:24 [stantonm]
- ... implies two sets of adopted style sheets, seems complex
- 14:45:32 [stantonm]
- ... not sure if additional complexity is worth it
- 14:45:44 [tantek]
- present++
- 14:45:46 [tantek]
- present+
- 14:45:57 [stantonm]
- TabAtkins: don't need two sets, just move from shadow root to adopted
- 14:46:14 [stantonm]
- bkardell_: can you do adopted style sheets outside shadow dom
- 14:46:15 [stantonm]
- TabAtkins: yes
- 14:46:38 [stantonm]
- hober: summarizing = after, if they want before have to specify
- 14:46:50 [stantonm]
- RESOLUTION: constructed style sheets to always go after
- 14:46:59 [TabAtkins]
- astearns: And if we realize that authors do ahve common need to put the adopted ones first, we're free to add a knob for that.
- 14:47:49 [stantonm]
- topic: TRIAGE ALL THE SPECS
- 14:48:08 [stantonm]
- chris: color-5 is ready, it's a delta spec with color modification
- 14:48:16 [florian]
- +1
- 14:48:34 [stantonm]
- RESOLVED: publish first public working draft of color-5
- 14:49:08 [stantonm]
- hober: FPWD of transforms-2
- 14:49:23 [stantonm]
- RESOLUTION: publish FPWD of transforms-2
- 14:49:37 [stantonm]
- dbaron: no objections, maybe it makes sense to publish transforms-1 at same time
- 14:49:49 [stantonm]
- fantasai: transforms-1 is in good shape, it's in CR
- 14:50:13 [stantonm]
- fantasai: media-queries-5
- 14:50:30 [stantonm]
- RESOLVED: resolved to publish media-queries-5
- 14:50:45 [stantonm]
- dbaron: does publishing delta spec break tools?
- 14:51:04 [stantonm]
- TabAtkins: bikeshed will remove things
- 14:51:20 [stantonm]
- ... there's no quick fix
- 14:51:47 [stantonm]
- chris: color-5 is entirely new feature, it's useful to have delta
- 14:51:57 [stantonm]
- TabAtkins: un-delta for publishing
- 14:52:12 [stantonm]
- fantasai: that's hard, we need to have goal to publish more specs
- 14:52:30 [stantonm]
- dbaron: add a thing that both versions maintained in single doc
- 14:52:47 [stantonm]
- TabAtkins: not quick solution
- 14:52:53 [stantonm]
- s/not/no
- 14:53:36 [Karen]
- Karen has joined #css
- 14:53:42 [stantonm]
- fantasai: can we publish resize-observer
- 14:53:50 [rego]
- https://drafts.csswg.org/resize-observer/
- 14:54:23 [stantonm]
- dbaron: any concerns with it being in WICG
- 14:55:07 [stantonm]
- florian: double IPR for contributions
- 14:55:20 [stantonm]
- fantasai: in practice doesn't matter if they're also in CSSWG
- 14:55:39 [stantonm]
- TabAtkins: same boat, we're good
- 14:56:37 [stantonm]
- astearns: only asking to publish resize-observer yourself
- 14:56:55 [stantonm]
- chris: have to file issue saying to publish FPWD
- 14:57:02 [stantonm]
- RESOLVED: publish FPWD of resize-observer
- 14:57:16 [stantonm]
- fantasai: css-conditional level 4
- 14:57:37 [stantonm]
- RESOLVED: publish FPWD of css-conditional-4
- 14:57:53 [stantonm]
- fantasai: css-highlight-1
- 14:58:05 [stantonm]
- hober: some disagreement
- 14:58:26 [stantonm]
- ... with FPWD we want to make sure we have good idea of what were doing
- 14:58:35 [stantonm]
- ... event API is missing
- 14:58:54 [stantonm]
- ... in current would rather not publish, we should at least stub it out before publishing
- 14:59:29 [stantonm]
- florian: gives different signals to lawyers if it's incomplete
- 14:59:41 [stantonm]
- hober: I can commit to stub it out
- 15:00:04 [stantonm]
- RESOLVED: stub out events API, then publish FPWD of css-highlights-1
- 15:00:20 [stantonm]
- fantasai: any other drafts?
- 15:00:32 [zcorpan]
- zcorpan has joined #css
- 15:00:34 [tantek]
- I'll be ready to republish CSS Scrollbars soon
- 15:00:40 [tantek]
- Just one issue/edit remaining
- 15:00:44 [stantonm]
- florian: text-decoration-4
- 15:00:51 [stantonm]
- fantasai: need to check through issues first
- 15:00:54 [tantek]
- (thanks to fantasai nudging me last week)
- 15:01:04 [stantonm]
- ... any other working drafts we should publish?
- 15:01:53 [stantonm]
- astearns: do we need to request before?
- 15:02:03 [stantonm]
- fantasai: depends on time frame, not normally
- 15:02:13 [stantonm]
- heycam: maybe scroll anchoring
- 15:02:17 [jensimmons]
- jensimmons has joined #css
- 15:02:26 [stantonm]
- TabAtkins: I can own, and publish
- 15:02:44 [stantonm]
- RESOLVED: FPWD of scroll-anchoring level 1
- 15:03:05 [stantonm]
- florian: scroll bars?
- 15:03:14 [stantonm]
- fantasai: tantek has some more issues to fix
- 15:03:36 [fantasai]
- s/has/just said he has/
- 15:03:56 [tantek]
- other than that issue 3315, draft and changes section is up to date but still regenerating (re-bikeshedding?) https://drafts.csswg.org/css-scrollbars-1/#changes
- 15:08:59 [stantonm]
- topic: Add ISO 15924 script codes to unicode-range
- 15:09:04 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4573
- 15:09:34 [stantonm]
- myles: unicode-range takes bunch of code-points
- 15:09:45 [dbaron]
- the addition of those two agenda items was https://wiki.csswg.org/planning/galicia-2020?do=diff&rev2%5B0%5D=1569210305&rev2%5B1%5D=1570141384&difftype=sidebyside
- 15:09:50 [stantonm]
- ... bad for a couple reasons, lots of numbers and not clear what they mean
- 15:10:12 [stantonm]
- ... also when adding some like emoji, you can list all unicode points - but it changes over time
- 15:10:32 [stantonm]
- ... proposal to add keyword that lets the browsers define the code points
- 15:10:43 [stantonm]
- florian: what are the keywords
- 15:11:02 [stantonm]
- myles: issue says use pull keywords from ISO
- 15:11:18 [stantonm]
- hober: we shouldn't define these things, reference something in unicode
- 15:11:34 [stantonm]
- myles: different languages use some common code points
- 15:11:46 [stantonm]
- ... keywords shouldn't be a partition, there will be overlaps
- 15:11:56 [stantonm]
- ... space character will be in most of them
- 15:12:23 [stantonm]
- fantasai: two factors, script extensions list - some of these are assigned to common script
- 15:12:31 [stantonm]
- ... we should be looking up script extensions
- 15:12:40 [stantonm]
- ... other case is super common things - numbers, space, etc
- 15:12:48 [stantonm]
- ... alot of things assigned to common script
- 15:13:01 [stantonm]
- ... probably makes sense to include common by default, but have opt out
- 15:13:22 [stantonm]
- myles: we should resolve that we would like keywords, but not resolve on the actual keywords
- 15:13:29 [stantonm]
- fantasai: we should rely on iso
- 15:13:41 [stantonm]
- faceless2: rely on existing registry
- 15:13:54 [stantonm]
- astearns: should we have everything in the registry
- 15:14:07 [stantonm]
- heycam: do the names in the registry match normal css conventions?
- 15:14:15 [stantonm]
- TabAtkins: looks like no?
- 15:14:29 [stantonm]
- fantasai: should be a list of keywords 4 chars long
- 15:14:32 [faceless2]
- https://www.unicode.org/Public/12.1.0/ucd/Scripts.txt
- 15:14:32 [jensimmons]
- jensimmons has joined #css
- 15:14:37 [astearns]
- `Zsye 993: Emoji`
- 15:14:53 [stantonm]
- TabAtkins: if we're confident they are 4 letters, we can take directly
- 15:15:10 [stantonm]
- fantasai: think that should be fine, they need to maintain compat
- 15:15:13 [faceless2]
- example values : "Hebrew", "Devanagari", "Common"
- 15:15:36 [stantonm]
- myles: we may get it wrong, can we tentatively resolve to try something out first
- 15:15:55 [stantonm]
- florian: go with 4 letter name of long name? or not deciding
- 15:16:07 [stantonm]
- faceless2: where did four letter name come from?
- 15:16:59 [stantonm]
- florian: long name has hyphens, 4 letter is defined somewhere else
- 15:17:11 [stantonm]
- TabAtkins: casing shouldn't be important
- 15:17:28 [dbaron]
- The 4 letter script codes are always letters and come from ISO15924: https://tools.ietf.org/html/rfc5646#section-2.2.3
- 15:17:31 [stantonm]
- astearns: leave it to the fonts editors to define what keywords we pull, don't need to resolve on that now
- 15:17:49 [stantonm]
- myles: I'll also contact unicode
- 15:18:06 [stantonm]
- jfkthame: should there also be exclusion values?
- 15:18:24 [stantonm]
- hober: if you could exclude a range, you could exclude common range
- 15:18:26 [Karen]
- Karen has joined #css
- 15:18:36 [stantonm]
- myles: be careful we don't turn this into a full language
- 15:19:10 [stantonm]
- chris: even if you do a good job, when unicode adds new values you may unintentionally exclude things
- 15:19:19 [stantonm]
- ... shift burden of defining onto external body
- 15:19:32 [dbaron]
- also see https://unicode.org/iso15924/iso15924-codes.html
- 15:19:33 [stantonm]
- RESOLVED: we are going to create keywords for unicode ranges
- 15:19:59 [dbaron]
- "Zsye" is for Emoji, I think :-/
- 15:20:21 [dbaron]
- I think that's a little unfortunate.
- 15:20:31 [stantonm]
- topic: The Cursive = Chinese Kaiti equivalent
- 15:20:43 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4606
- 15:21:11 [stantonm]
- chris: first had these thoughts in CSS2, said cursive matched cyrillic (?)
- 15:21:46 [stantonm]
- ... how similar is kaiti to cursive
- 15:21:58 [stantonm]
- ... would like to see more comments from people who read chinese
- 15:22:05 [stantonm]
- myles: can we ask i18n
- 15:22:17 [stantonm]
- chris: we should reference clreq
- 15:22:39 [stantonm]
- fantasai: usage of kaiti is similar to how english uses italics, not really cursive
- 15:23:01 [stantonm]
- ... switching to cursive english font in middle of kaiti feels inappropriate
- 15:23:11 [stantonm]
- heycam: see kaiti in childrens books
- 15:23:21 [stantonm]
- fantasai: something like comic sans
- 15:23:29 [stantonm]
- ... not fully connected writing
- 15:23:55 [RossenF2F]
- RossenF2F has joined #css
- 15:24:00 [stantonm]
- florian: mapping english words like cursive doesn't always make sense in other language
- 15:24:04 [stantonm]
- ... inconsistent mapping
- 15:24:20 [stantonm]
- chris: we don't provide typography for free, better to use font-family name
- 15:24:39 [stantonm]
- ... if you want something specific say something specific
- 15:25:06 [stantonm]
- fantasai: high-level switching can be nice, distinguish paragraphs
- 15:25:32 [stantonm]
- fantasai: think we do need some kind of syntax
- 15:25:46 [stantonm]
- florian: should not map all keywords we have to other language
- 15:25:59 [stantonm]
- ... how far do we need to go? not sure
- 15:26:18 [stantonm]
- astearns: we should ask clreq for this issue
- 15:26:37 [stantonm]
- florian: what do we want to ask
- 15:26:53 [stantonm]
- astearns: do we need a keyword for kaiti, or can it map to existing keywords
- 15:27:19 [stantonm]
- chris: followed spec in good faith, people may need to back things out if we change
- 15:27:36 [stantonm]
- s/authors followed/followed/
- 15:27:41 [dbaron]
- q+ to comment on whether data indicating which category a font falls in exists in the font or the OS
- 15:27:54 [chris]
- s/people/browser implementers/
- 15:28:12 [stantonm]
- myles: valuable for us to have criteria on when to add new generic font keywords
- 15:28:39 [stantonm]
- astearns: open page on wiki for requirements of new keywords
- 15:29:01 [stantonm]
- dbaron: it's useful to have that in the spec, fine to have non-normative explaining why the spec is this way
- 15:29:08 [Zakim]
- dbaron, you wanted to comment on whether data indicating which category a font falls in exists in the font or the OS
- 15:29:14 [stantonm]
- hober: lets people know how to change it if they see it in spec
- 15:29:24 [stantonm]
- astearns: put in wiki as scratch space
- 15:30:01 [stantonm]
- dbaron: can we extract metadata from fonts to help derive these keywords
- 15:30:39 [stantonm]
- myles: most existing generic font families fail that test
- 15:30:54 [stantonm]
- jfkthame: in theory panose should word, but in pratice usually not there
- 15:31:00 [stantonm]
- s/word/work/
- 15:31:16 [fantasai]
- s/word/work/
- 15:31:49 [stantonm]
- myles: some criteria for naming, needs to map to more than just one font file
- 15:32:16 [stantonm]
- ... useful for installed fonts, OS's need to have installed fonts that match
- 15:32:35 [stantonm]
- ... other criteria is that at least two OS support a font for that generic
- 15:32:49 [stantonm]
- chris: not always helpful in underrepresented languages
- 15:32:59 [stantonm]
- astearns: but we already resolved to do work on that front
- 15:33:14 [stantonm]
- fantasai: so then it's with appropriate language pack installed
- 15:33:24 [fantasai]
- for some appropriate definition of language pack
- 15:33:29 [stantonm]
- myles: computers don't know, browser dev needs to manually type in list
- 15:33:36 [Zakim]
- fantasai, you wanted to say that the threshold is, are typographers regularly using a distinction in font stylistic groupings to make a semantic distinction in their publications
- 15:34:06 [stantonm]
- fantasai: threshold should be whether typographers in typical publications are using distinctions between different groups of fonts
- 15:34:15 [stantonm]
- ... example is italic vs normal vs bold in latin
- 15:34:21 [smfr]
- smfr has joined #css
- 15:34:31 [stantonm]
- ... sans-serif, serif, monospace makes a semantic distinction
- 15:34:55 [stantonm]
- dbaron: does serif/sans-serif meet that criteria
- 15:35:16 [stantonm]
- hober: good to come up with criteria, stuck with the ones we already have
- 15:35:33 [stantonm]
- ... new criteria should just work going forward, may not fit existing perfectly
- 15:35:59 [stantonm]
- fantasai: there are stylistic distinctions sometimes, but can also be semantic in many others
- 15:36:19 [stantonm]
- florian: criteria is useful for prioritizing, but hard to say yes/no
- 15:36:47 [stantonm]
- florian: if we don't meet criteria we shouldn't add, if we meet it we *may* add
- 15:36:53 [fantasai]
- it's a sufficient but not necessary criteria
- 15:37:10 [stantonm]
- s/florian/fantasai
- 15:37:48 [fantasai]
- s/if we don't meet criteria we shouldn't add, if we meet it we *may* add/if we meet the criteria, should add; if we don't, we may add/
- 15:38:55 [stantonm]
- topic: How does scrolling relate to mouseWheel event propagation?
- 15:39:23 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4680
- 15:40:35 [plh]
- plh has joined #css
- 15:40:54 [AmeliaBR]
- AmeliaBR has joined #css
- 15:41:28 [astearns]
- github: none
- 15:42:06 [stantonm]
- topic: Overlap between the definition of resolving color values and serializing <color> component values.
- 15:42:11 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/982
- 15:43:00 [stantonm]
- chris: css object model has not clear text about how to construct these color strings
- 15:43:10 [stantonm]
- ... color-4 should obsolete that part of the model
- 15:43:28 [stantonm]
- ... do people agree? or do we think it needs serialization
- 15:43:55 [stantonm]
- ... even if you have rgb with percentage, some bits get thrown away
- 15:44:12 [stantonm]
- ... should it be in color-4 or OM
- 15:44:24 [stantonm]
- emilio: as long as its well defined I don't care
- 15:44:33 [stantonm]
- TabAtkins: prefer color spec
- 15:45:22 [stantonm]
- leaverou: remove it from css OM and just point to color-4
- 15:46:04 [stantonm]
- florian: agree, color-4 now has appropriate infomation to represent that spec
- 15:46:14 [stantonm]
- RESOLVED: move serialization into color-4
- 15:46:44 [stantonm]
- fantasai: before we remove from OM should we publish it
- 15:46:51 [stantonm]
- TabAtkins: publish both after the move
- 15:47:56 [stantonm]
- topic: Serializing color() values
- 15:47:58 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/480
- 15:48:36 [stantonm]
- chris: dean raised how does the color function get serialized
- 15:48:50 [stantonm]
- ... whats a good serialization, for all the new ones they need to be floats
- 15:49:09 [stantonm]
- ... any problems with that in OM
- 15:49:29 [stantonm]
- TabAtkins: if it's not int it will serialize property, as long as data model underneath is number
- 15:49:43 [stantonm]
- chris: for color you can use 0-1, or 0-100%
- 15:49:49 [stantonm]
- ... 0-1 was simpler
- 15:50:11 [stantonm]
- emilio: consistent with alpha
- 15:50:51 [stantonm]
- RESOLVED: color() functions, if they have a choice between percentage and number, they should use number
- 15:51:16 [stantonm]
- chris: lightness is a percent, how do we handle that specific one
- 15:52:00 [stantonm]
- TabAtkins: percentage and number equilivence is defined as 0-1 equals 0-100%
- 15:52:07 [stantonm]
- ... so we can just accept number
- 15:52:13 [stantonm]
- s/can/can't/
- 15:52:54 [stantonm]
- ... in the color function, just follow the rules - which is 0-1
- 15:52:59 [stantonm]
- fantasai: agree with tab
- 15:53:45 [stantonm]
- florian: for match function we take 0-100?
- 15:53:54 [stantonm]
- christ: eventually caved to just take percent
- 15:54:21 [stantonm]
- TabAtkins: could be this one color space takes 0-400, so doesn't matter
- 15:54:55 [stantonm]
- chris: some people use equipment that gives back percent
- 15:55:11 [stantonm]
- fantasai: adding the percent sign makes sense
- 15:55:27 [chris]
- s/gives back percent/gives back L in 0 to 100 range and no percent
- 15:55:42 [stantonm]
- TabAtkins: don't do the weird thing with lab and percentages (?)
- 15:56:25 [stantonm]
- chris: did it for rgb, so we argued it might make sense for lab
- 15:56:33 [stantonm]
- ... it's longer so not being used as much
- 15:56:53 [xiaochengh]
- xiaochengh has joined #css
- 15:56:59 [AmeliaBR]
- We already have RGB functions where percentages map to 0-255 in integers. Because that's the convention for that data type. If integer 0-100 is the convention for lab.
- 15:57:12 [AmeliaBR]
- ... maybe makes sense to follow.
- 15:57:14 [fantasai]
- in the color() function?
- 15:57:43 [AmeliaBR]
- Ummm… I don't know which syntaxes are allowed there.
- 15:59:45 [TabAtkins]
- Proposed Resolution: the `color(lab ...)` function, like the rest of the color() values, are in the 0-1 (or 0% - 100%) range. And they serialize the same as other color() values (as a 0-1 number).
- 16:00:06 [nigel]
- nigel has joined #css
- 16:00:10 [stantonm]
- RESOLVED: the `color(lab ...)` function, like the rest of the color() values, are in the 0-1 (or 0% - 100%) range. And they serialize the same as other color() values (as a 0-1 number).
- 16:03:01 [astearns]
- topic:break
- 16:12:35 [dauwhe]
- dauwhe has joined #css
- 16:18:27 [TabAtkins]
- Topic: <dialog> positioning
- 16:18:29 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4645
- 16:18:29 [TabAtkins]
- github: https://github.com/w3c/csswg-drafts/issues/4645
- 16:18:33 [fantasai]
- ScribeNick: fantasai
- 16:19:05 [fantasai]
- TabAtkins: Dialog layout description, two modes
- 16:19:23 [fantasai]
- TabAtkins: 2nd one is a very long run-on sentence that's weird and not described in CSS
- 16:19:32 [fantasai]
- TabAtkins: Behavior is useful, but unfortunate not in CSS
- 16:19:35 [fantasai]
- TabAtkins: So a few things to do
- 16:19:43 [fantasai]
- TabAtkins: First question, is this worth trying to put into CSS?
- 16:19:58 [fantasai]
- TabAtkins: Next, quick description of what it is and what might be involved, to get an idea of how it would work
- 16:20:24 [AmeliaBR]
- Define in CSS please!
- 16:20:31 [fantasai]
- TabAtkins: Thoughts on whether to describe in CSS, or treat as a special one-off case in HTML
- 16:20:38 [fantasai]
- florian: In general, think it's better to do in CSS
- 16:20:47 [fantasai]
- florian: but if extremely complicated * low value, maybe not
- 16:21:02 [fantasai]
- smfr: Authors might want to use the same type of positioning for their own fake dialogs
- 16:21:07 [fantasai]
- smfr: so better to have in CSS
- 16:21:36 [AmeliaBR]
- Defining in CSS also makes it easier to modify / override with CSS (e.g., by media queries, interactions with other CSS).
- 16:21:47 [fantasai]
- TabAtkins: Aim to get a resolution to add this to CSS, does anyone object to me putting this into some spec, probably css-position?
- 16:21:59 [fantasai]
- TabAtkins: I'm taking the silence as assent
- 16:22:21 [fantasai]
- tantek: Any security considerations wrt lowering barriers to making fake dialogs?
- 16:22:29 [fantasai]
- TabAtkins: Can do in JS already
- 16:22:35 [fantasai]
- TabAtkins: So can we take a resolution to that?
- 16:22:56 [fantasai]
- RESOLVED: Define dialog positioning in CSS terms, probably in css-position, with aim of replacing HTML's one-off description
- 16:23:19 [fantasai]
- fantasai: ...
- 16:23:21 [fantasai]
- TabAtkins: ...
- 16:23:45 [fantasai]
- emilio: It's a stateful position, because you don't want to reposition the dialog when you scroll or relayout
- 16:23:49 [fantasai]
- TabAtkins: here's the basic description
- 16:23:55 [fantasai]
- TabAtkins: Ignoring stacking context aspect
- 16:23:59 [fantasai]
- TabAtkins: but for positioning bit
- 16:24:03 [fantasai]
- TabAtkins: It's basically abspos
- 16:24:12 [fantasai]
- TabAtkins: where we figure out the offset to apply when it first comes into existence
- 16:24:19 [fantasai]
- TabAtkins: such that it's safe-centered into viewport
- 16:24:27 [fantasai]
- TabAtkins: from that point on, it's just abspos -- you scroll the page, it scrolls off
- 16:24:40 [fantasai]
- TabAtkins: if you dismiss the dialog and regenerate, it will recalculate its position
- 16:24:51 [fantasai]
- TabAtkins: interesting question is when do we clock thispoint in time?
- 16:24:58 [fantasai]
- TabAtkins: Answer should be when animation starts
- 16:25:13 [fantasai]
- iank_: Another way to define is in the DOM layer
- 16:25:27 [fantasai]
- iank_: for the DIALOG element it could query what the layout is and set the top directly via CSS
- 16:25:34 [fantasai]
- TabAtkins: Essentially built-in JS
- 16:25:40 [fantasai]
- iank_: We do this for other things
- 16:25:41 [tantek]
- is it not fixedpos? huh
- 16:25:48 [fantasai]
- iank_: It's not great, but might be impler
- 16:25:52 [TabAtkins]
- nope, it scrolls if you scrol lthe page
- 16:25:54 [fantasai]
- s/imp/simp/
- 16:26:07 [fantasai]
- emilio: My objection wrt when boxes are created is that engines create boxes at different times
- 16:26:30 [fantasai]
- emilio: When you change the display value, Blink will reposition, because it destroys the box and loses the state
- 16:26:49 [tantek_]
- tantek_ has joined #css
- 16:26:53 [fantasai]
- TabAtkins: If you go from not having boxes to having boxes, you reposition. Having boxes to having boxes, you don't reposition
- 16:27:03 [fantasai]
- TabAtkins: Ian's description was also quite good, smfr what do you think?
- 16:27:49 [heycam]
- fantasai: to describe Ian's suggestion, at the point the dialog is launched, the UA sets the top/bottom/left/right to be an absolute position edges of the viewport
- 16:27:59 [heycam]
- ... and then, we use the alignment properties to center it within that area
- 16:28:04 [heycam]
- ... then you don't have to calculate the centering
- 16:28:22 [heycam]
- ... just use the inset properties to bring the abspos range to match the current viewport range when the dialog is launched
- 16:28:30 [heycam]
- smfr: sounds like you're snapshotting the layout viewport
- 16:28:50 [heycam]
- fantasai: you're assigning abspos inset properties so that you're creating a box that overlaps exactly the fixedpos containing block
- 16:28:57 [heycam]
- smfr: wondering if it should be defined in terms of the layout viewport somehow
- 16:29:10 [heycam]
- TabAtkins: the HTML spec does require recalculating the position if the viewport changes size
- 16:29:17 [heycam]
- ... guess that's still possible, it's just a ResizeObserver on the window
- 16:29:29 [heycam]
- smfr: another question is if the user zooms. same behavior as fixpos?
- 16:29:36 [heycam]
- fantasai: as abspos, if the user wants to zoom in to see the dialog they should be able to
- 16:29:51 [heycam]
- TabAtkins: don't want fixpos magic. abspos with magic setting at a particular time
- 16:30:02 [heycam]
- fantasai: I think that this works and is simpler than creating a new magic model with timing implications
- 16:30:21 [heycam]
- fantasai: question I have is, if you have a dialog that's inside one of these containing block trapping elements, how do you get this element to escape and become contained byt the containing block
- 16:30:27 [heycam]
- TabAtkins: that's answered by top-layer
- 16:30:34 [heycam]
- ... in this mode it's always kicked into that
- 16:30:39 [heycam]
- ... do need to specify top layer rendering
- 16:30:48 [jensimmons]
- jensimmons has joined #css
- 16:30:52 [heycam]
- fantasai: putting something there changes stacking context and containing block?
- 16:30:54 [heycam]
- TabAtkins: yes
- 16:30:58 [heycam]
- ... abspos containing block becomes the root
- 16:31:06 [heycam]
- fantasai: how does that interact with transforms or contain layout?
- 16:31:12 [heycam]
- TabAtkins: layout containgment should still be fine with escaping
- 16:31:18 [heycam]
- ... and transforms it changes its parent
- 16:31:23 [heycam]
- ... it's no longer transformed
- 16:31:34 [heycam]
- iank_: yes. it's weird
- 16:32:05 [heycam]
- fantasai: so it sounds like what we're doing is defining a way to put something into the top layer, out of the box tree, into this parallel box tree (list) where the containing block is the size of the entire page
- 16:32:09 [heycam]
- TabAtkins: I think that's the right thing
- 16:32:19 [heycam]
- TabAtkins: think it's the whole page
- 16:32:44 [heycam]
- heycam: interactions with full screen? they'll both be in the top layer
- 16:32:48 [heycam]
- TabAtkins: we'll need to deal with that
- 16:32:52 [heycam]
- ... separate but intersecting topics
- 16:33:03 [heycam]
- smfr: top layers will stack up
- 16:33:09 [heycam]
- ... if you have full screen and dialog
- 16:33:16 [heycam]
- fantasai: what's the stacking order?
- 16:33:20 [heycam]
- smfr: whichever's created first
- 16:33:23 [heycam]
- ... but we need to define that
- 16:33:34 [heycam]
- fantasai: it's not as much of a mess as fieldset/legend...
- 16:33:39 [heycam]
- iank_: painting wise this is more interesting
- 16:34:00 [heycam]
- smfr: part of me wonders if we need to maintain compat with dialog layout. is this sensible behavior in HTML? or should we define something different
- 16:34:04 [heycam]
- ... think only Chrome has shipped
- 16:34:12 [heycam]
- TabAtkins: I've used dialogs in personal projects and enjoyed it
- 16:34:37 [heycam]
- iank_: are we the only ones shipping it?
- 16:34:38 [heycam]
- TabAtkins: I think so
- 16:34:58 [heycam]
- iank_: I would be up for potentially investigating what compat risk there is if there's a more sane model that we think we can ship
- 16:35:03 [heycam]
- ... the compat thing will be the question
- 16:35:11 [heycam]
- ... Simon what caused you to start investigating this?
- 16:35:17 [heycam]
- smfr: I was just looking at how the implementation would work in WebKit
- 16:35:39 [heycam]
- ... and I dug into the Blink code and found a function deep down
- 16:35:43 [fantasai]
- i/fantasai: to describe Ian/scribenick: heycam
- 16:35:45 [heycam]
- ... in block rendering
- 16:35:49 [heycam]
- ... didn't want to do the same thing
- 16:36:00 [smfr]
- s/in block rendering/in block layout/
- 16:36:53 [heycam]
- RESOLVED: Define dialog in terms of top layer and a snapshotted abspos position and alignment property for centering
- 16:37:04 [heycam]
- smfr: can we also resolve on specifying top layer behavior in CSS somewhere?
- 16:37:09 [heycam]
- ... it needs to live along with paint order and z-index
- 16:37:17 [heycam]
- ... wherever CSS 2.2 Appendix E will go
- 16:37:22 [heycam]
- fantasai: probably CSS Position?
- 16:37:23 [heycam]
- smfr: or a new spec
- 16:37:37 [heycam]
- smfr: I feel like a paint order spec is probably necessary
- 16:37:47 [heycam]
- dbaron: I think we need a spec for a bunch of rendering stuff, including common terminology
- 16:37:58 [heycam]
- ... if you remember the big table of horrible test cases for stacking contexts, etc., we need a spec to cover that
- 16:38:03 [heycam]
- fantasai: so new spec for the painting order
- 16:38:03 [tantek_]
- perhaps that could include hit-testing which is directly related to stacking order etc.
- 16:38:28 [heycam]
- dbaron: CSS Rendering Model or CSS Painting Model?
- 16:38:31 [tantek_]
- more than just painting, the stacking order affects hit-testing
- 16:38:38 [fantasai]
- scribenick: fantasai
- 16:38:49 [fantasai]
- Topic: Mousewheel Event Propagation
- 16:38:50 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4680
- 16:39:33 [fantasai]
- smfr: Running into some issues with how nesting scrolling works, and differences between browsers
- 16:39:39 [fantasai]
- [display fragments into weird pieces]
- 16:39:51 [fantasai]
- smfr: I look example showing when the events are received
- 16:40:08 [tantek_]
- me more Mondrian than Picasso TBH
- 16:40:11 [bkardell_]
- https://codepen.io/smfr/pen/RwNvVPj
- 16:40:13 [bkardell_]
- ^^^
- 16:40:18 [smfr]
- https://codepen.io/smfr/full/rQZqxo
- 16:40:45 [fantasai]
- smfr: First question is, if your pointer is over the border of the element
- 16:40:52 [fantasai]
- smfr: and you initiate scrolling
- 16:40:58 [fantasai]
- smfr: do you scroll that element's overflow region?
- 16:41:02 [fantasai]
- smfr: in WebKit, yes
- 16:41:08 [fantasai]
- smfr: in Firefox, answer is yes
- 16:41:14 [fantasai]
- smfr: in Chrome, answer is no
- 16:41:23 [fantasai]
- smfr: My pointer over the border of the element, I scroll the main page in Chrome
- 16:41:25 [fantasai]
- smfr: Difference #1
- 16:41:42 [fantasai]
- smfr: Other interesting thing about Chrome, notice the element is still receiving wheel events
- 16:41:48 [fantasai]
- smfr: even though I'm not scrolling it
- 16:42:00 [fantasai]
- smfr: so disconnect between when an element receives scroll events and when it actually gets scrolled
- 16:42:10 [fantasai]
- smfr: ...
- 16:42:17 [bkardell_]
- what about :hover - does it work on the border?
- 16:42:17 [fantasai]
- smfr: Things also get interesting when you start nesting scrollers
- 16:42:24 [fantasai]
- bkardell_, yes
- 16:42:32 [fantasai]
- smfr: Now, same thing, parent scroller here
- 16:42:46 [fantasai]
- smfr: it has two descendant elements, but those elements are absolutely-positioned, and the scroller is not their containing block
- 16:42:52 [TabAtkins]
- s/.../I think it's reasonable that browsers may have assumed that users only want to scroll when the mouse is actually in the content/
- 16:43:22 [fantasai]
- smfr: when I scroll the left abspos, it's a DOM descendant of the big scroller, and the big scroller receives wheel events becaue of DOM propoagation
- 16:43:33 [fantasai]
- smfr: but when I reach the end of the little scroller, the big scroller does not scroll
- 16:43:39 [fantasai]
- smfr: in WebKit and Firefox
- 16:43:49 [fantasai]
- s/Firefox/Chrome
- 16:43:59 [astearns]
- q?
- 16:44:01 [fantasai]
- smfr: but in Firefox, the big scroller scrolls after I reach the end of the little scroller
- 16:44:10 [fantasai]
- dbaron: That seems wrong to me
- 16:44:24 [fantasai]
- dbaron: I would expect it to scroll the ancestor only if ...
- 16:44:41 [fantasai]
- dbaron: Seems that scroll propagation should follow containing block containment
- 16:44:49 [fantasai]
- s/dbaron/smfr/
- 16:44:51 [fantasai]
- dbaron: I'm not sure
- 16:45:02 [fantasai]
- dbaron: If you have somehting with overflow: scroll
- 16:45:25 [fantasai]
- dbaron: I'll invent the term "containing block child", to descrie it more as a tree for this discussion
- 16:45:55 [fantasai]
- dbaron: An element with overflow:scroll might have containing block children that move when it scrolls, and containing block children that don't move when it scrolls?
- 16:45:59 [fantasai]
- dbaron: or do they all move when it scrolls?
- 16:46:03 [fantasai]
- smfr: I think they all move when it scrolls
- 16:46:21 [heycam]
- fantasai: I think that's true since I don't know how you'd fix the element to any scroll port other than that element's
- 16:46:31 [fantasai]
- s/element/viewport/
- 16:46:36 [fantasai]
- dbaron: Concerned about sticky
- 16:46:39 [fantasai]
- dbaron: or abspos
- 16:46:50 [fantasai]
- dbaron: maybe containing-block-ness is right
- 16:47:12 [fantasai]
- dbaron: I would expect scrolling to propogate the scrolling up to the next thing that would cause the thing where your mouse is to move
- 16:47:16 [fantasai]
- smfr: I think that makes sense
- 16:47:36 [fantasai]
- dbaron: This might be something Mats has an opinion aout
- 16:47:42 [fantasai]
- s/aout/about/
- 16:48:02 [fantasai]
- emilio: Following regular box order is more similar to what the events do
- 16:48:33 [fantasai]
- smfr: Prolem with that is that it's easy to construct content where you might mask scroll ... end up scrolling something unrelated on the page just because it happens to be in the DOM parentage
- 16:48:47 [fantasai]
- dbaron: with DOM events you also have the ability to look at what the event target it
- 16:48:50 [fantasai]
- s/it/is/
- 16:49:13 [fantasai]
- fantasai: Do we want to resolve the question about borders first? Seems simper.
- 16:49:28 [fantasai]
- smfr: Which do people prefer?
- 16:49:38 [fantasai]
- dbaron: I was surprised when you showed me what Firefox does
- 16:49:57 [fantasai]
- heycam: the border should move if I'm hovering over it and try to scroll
- 16:50:07 [fantasai]
- iank_: I think that's why we have this behavior
- 16:50:23 [fantasai]
- AmeliaBR: From the DOM perspective, seems reasonable that event going to element should cause it to scroll
- 16:50:35 [fantasai]
- AmeliaBR: maybe from user perpective preferred behavior is different
- 16:50:54 [fantasai]
- AmeliaBR: but if doing it that way, maybe give script some affordances to figure out what's happening
- 16:51:07 [fantasai]
- AmeliaBR: because right now would have to evaluate the coords against layout and stuff
- 16:51:29 [fantasai]
- AmeliaBR: I think it's weird to have the default behavior that we cannot recreate with script, if you want to do something else in response to wheel events
- 16:51:45 [fantasai]
- iank_: Subtracting borders from the rectangle, lots of libraries for these types of calculations
- 16:51:57 [heycam]
- fantasai: I don't think it's that weird from a user perspective for it to scroll
- 16:52:04 [heycam]
- ... for a similar reason, if hovering over the scrollbar, it scrolled
- 16:52:13 [heycam]
- ... the scrollbar doesn't move
- 16:52:25 [heycam]
- fantasai: the thumb does but the scrollbar itself doesn't
- 16:52:50 [heycam]
- ... I'm not convinced frmo a user perspective it's that terrible for the element's contents to scroll when hovered over the border
- 16:53:02 [heycam]
- smfr: if you were interacting through touch rather than pointer would you have the same opinion
- 16:53:20 [heycam]
- ... with touch users have an expectation that the thing under the finger moves
- 16:53:29 [heycam]
- ... I think it's less obvious then that you want to scroll the content rather than everything else
- 16:53:42 [heycam]
- fantasai: it's less obvious, but unless the border was absolutely huge, I probably wouldn't be surprised or notice
- 16:54:07 [fantasai]
- astearns: Not hearing much consensus
- 16:54:16 [heycam]
- smfr: I would prefer that you only scroll when you're in the scrollable part of the content
- 16:54:19 [fantasai]
- smfr: I would prefer you only scroll over the scrollable part of the conent, withint he padding box
- 16:54:51 [fantasai]
- astearns: I think it's a little weird to scroll when your cursor is over the right border, which is outside the scrollbar itself, but top / left / bottom seems fine to me. So I'm mixed.
- 16:55:10 [fantasai]
- iank_: From our perpective, I don't have full back story, but I'm guessing that someone did this for a good reason at some point
- 16:55:14 [fantasai]
- smfr: I think you inherited it from WebKit
- 16:55:16 [stantonm]
- stantonm has joined #css
- 16:55:23 [fantasai]
- iank_: We've changed a lot of stuff in this area
- 16:55:36 [fantasai]
- astearns: thought webkit does scroll over the border area and Blink does not
- 16:55:51 [fantasai]
- iank_: Right, I expect somebody intentionally made the change
- 16:56:27 [fantasai]
- smfr: Not sure we need to resolve now, but one thing I would like maybe to resolve on is that there isn't a simple relationship between an element receiving a wheel event and scrolling happening in that element
- 16:56:36 [fantasai]
- smfr: both because of the border issue and also the containing block issue
- 16:56:56 [fantasai]
- astearns: We could resolve on that, but then without the pariculars, not sure what use that resolution is
- 16:57:08 [fantasai]
- smfr: maybe that's not something to resolve on, but something to use as basis for future discussions
- 16:57:16 [fantasai]
- iank_: Sounded like smfr you preferred our behavior?
- 16:57:26 [fantasai]
- iank_: Sounded like dbaron and heycam, you also did?
- 16:57:32 [fantasai]
- heycam: I think so. I don't feel super strongly about it
- 16:57:53 [fantasai]
- astearns: OK, then let's try to resolve that when the cursor is over the border area, mousewheel events will not scroll the content area. Anyone object?
- 16:57:53 [jensimmons]
- jensimmons has joined #css
- 16:58:14 [fantasai]
- fantasai: I don't feel strongly about it
- 16:58:25 [fantasai]
- RESOLVED: Over the border area, doesn't scroll the content area
- 16:58:29 [fantasai]
- astearns: second part
- 16:58:39 [fantasai]
- astearns: has the border case and also the content area case
- 16:58:43 [fantasai]
- iank_: ...
- 16:59:08 [fantasai]
- smfr: I've seen some odd behaviors where sometimes scrolling over the border of an abspos child causes its parent that's not in the containing block chain to scroll....
- 16:59:24 [fantasai]
- bkardell_: Should any child, if you're on the border, you're technically inside
- 16:59:31 [fantasai]
- bkardell_: you're on the border, does it scroll the parent?
- 16:59:42 [fantasai]
- iank_: I can try and rationalize what potentially happens
- 17:00:01 [fantasai]
- iank_: wheel events get delivered even when the element isn't scrolling, to the element directly under the pointer, and they bubble up
- 17:00:14 [fantasai]
- iank_: you can create applications which don't necessarily scroll, but they do intercept wheel events
- 17:00:34 [fantasai]
- iank_: following that logic, makes sense to still deliver wheel events on the border box
- 17:00:43 [fantasai]
- smfr: I think so
- 17:01:02 [fantasai]
- smfr: Nothing I've said is about propoagating wheel events. The should follow normal DOM propagation and hit-testing rules
- 17:01:13 [fantasai]
- iank_: So your concern is mainly around abspos
- 17:01:34 [fantasai]
- smfr: My concern was that when use rinteraction with mouse wheel events triggers scrolling, disassociated with DOM wheel events, and different between browsers
- 17:01:37 [fantasai]
- smfr: would like it to be more specified
- 17:01:52 [fantasai]
- smfr: User interface aspect of when /how scrolls propagate, somewhat ndependent of event propagation
- 17:02:01 [fantasai]
- iank_: so concern is hwere the actual scroll propoagates to an dwhen
- 17:02:15 [fantasai]
- smfr: I think there's nothing to change about how wheel events change, nothing to do there.
- 17:02:19 [Karen]
- Karen has joined #css
- 17:02:43 [RossenF2F]
- RossenF2F has joined #css
- 17:02:49 [fantasai]
- astearns: so proposed resolution would be that actual scrolling behavior only propagates through the DOM tree if the pointer is over the content area of the scroller, is that correct?
- 17:03:07 [fantasai]
- smfr: I think it has to be described in terms of conaining block
- 17:03:32 [fantasai]
- smfr: assuming dbaron consideres gecko behavior a bug, with ... once you reach the end of the ...
- 17:03:46 [AmeliaBR]
- astearns version makes the most sense to me. The event propagates, but the scroll container checks the mouse position before actually scrolling or propagating further.
- 17:03:58 [fantasai]
- smfr: ONe thing that does not happen, you don't do a deep hit test, and find some ancestor becuase it happens to be under the mouse cursor, but covered by something else
- 17:04:12 [fantasai]
- smfr: you find the most descendant scroller, then ancestors scroll depending on whether in the ancestor containing block chain
- 17:04:47 [fantasai]
- smfr: For example, my testcase has the righthand element, which is not scrollable
- 17:04:52 [AmeliaBR]
- But what happens if the element that gets the event *isn't* a decendent of the scroller that is behind it…
- 17:05:06 [fantasai]
- smfr: if my mouse is over this half of it, scrolling will scroll he page.
- 17:05:30 [fantasai]
- ...
- 17:05:55 [fantasai]
- smfr: webkit has bugs because some parts uses conaining block chain, and some parts uses DOM ancestry, and when they don't match you get bugs
- 17:06:07 [fantasai]
- astearns: summarize proposed resolution?
- 17:06:24 [fantasai]
- smfr: Scroll propagation between nested overflow: scroll propagates through containing block chain
- 17:06:48 [fantasai]
- iank_: potential nasties
- 17:06:54 [duga]
- duga has joined #css
- 17:06:58 [fantasai]
- iank_: scrolling the left box, and cursor for brief amount of time is over the big scroller
- 17:07:04 [fantasai]
- iank_: and we currently don't scroll that, if that makes sense
- 17:07:21 [fantasai]
- smfr: Talking about latching, decide which element is scrolling at the beginning
- 17:07:29 [fantasai]
- smfr: not scrolling other things even though mouse has moved
- 17:07:36 [fantasai]
- smfr: next gesture, choose the thing to scroll again
- 17:07:42 [fantasai]
- https://www.w3.org/TR/css-display-3/#containing-block-chain
- 17:07:47 [fantasai]
- iank_: right
- 17:08:02 [fantasai]
- smfr: So that's another thing that's completely unspecified, and maybe there should be some words in the spec about it
- 17:08:43 [fantasai]
- astearns: So proposed resolution is that scroll behavior propagates through the containing block chain
- 17:08:50 [fantasai]
- iank_: I think that's fine, I think that's what our current impl does
- 17:08:56 [fantasai]
- astearns: Concerns from other implementers?
- 17:09:10 [fantasai]
- astearns: Alright, now objections? Anyone want to object?
- 17:09:19 [fantasai]
- RESOLVED: So proposed resolution is that scroll behavior propagates through the containing block chain
- 17:09:29 [fantasai]
- ACTION smfr File open issue against latching behavior
- 17:09:42 [fantasai]
- smfr: Does this go into cssom-view or what?
- 17:09:49 [fantasai]
- heycam: Seems like most relevant spec
- 17:10:18 [heycam]
- fantasai: overflow doesn't do anything with events. cssom view has some scrolling stuff, some scroll apis
- 17:10:33 [heycam]
- ... don't know what extent it really fits in with either, but would go with CSSOM since it's talking about DOM stuff
- 17:10:36 [fantasai]
- i/fantasai/emilio: maybe css-overflow?
- 17:10:47 [fantasai]
- astearns: OK, we'll put in cssom-view. Which doesn't have an editor.
- 17:10:52 [fantasai]
- astearns: smfr can I add you as editor?
- 17:11:01 [fantasai]
- RESOLVED: Add these rules to cssom-view, add smfr as editor
- 17:11:15 [fantasai]
- heycam: Another question, which element's pointer values do we look at to decide if it's going to scroll or not?
- 17:11:27 [fantasai]
- heycam: especially wrt looking at ancestors to see what to scroll
- 17:11:30 [fantasai]
- s/pointer/pointer-events/
- 17:11:53 [fantasai]
- smfr: I think we evaluate pointer-events when we do the hit testing, so only when finding the element to scroll
- 17:11:57 [fantasai]
- smfr: unsure about abspos and stuff
- 17:12:06 [fantasai]
- astearns: Good question, maybe open an issue?
- 17:12:09 [fantasai]
- heycam nods
- 17:12:14 [fantasai]
- astearns: Anything more on scrolling today?
- 17:12:18 [fantasai]
- smfr: That's all I have
- 17:12:24 [fantasai]
- astearns: Thanks for calling in
- 17:12:34 [fantasai]
- astearns: Let's go through Motion issues, because we have Amelia on the line
- 17:12:50 [fantasai]
- Topic: Motion - Final approach for shapes
- 17:13:37 [myles]
- ScribeNick: myles
- 17:13:47 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/3468
- 17:14:11 [myles]
- AmeliaBR: for the various properties that use shape(), some only care about the outline of the shape. Others care about the actual fill area of the shape
- 17:14:42 [myles]
- AmeliaBR: So for motion-path, you only care about the outline, but for clip-path, you care about which parts are inside and outside. This is an issue when you have polygons or paths with cris-crossing lines and inside/outside isn't so clear
- 17:14:51 [myles]
- AmeliaBR: Enter fill-rule. even-odd and nonzero.
- 17:15:00 [myles]
- AmeliaBR: It was originally defined as polygon(keyword, ...)
- 17:15:13 [myles]
- AmeliaBR: path() was defined in motion-path, and didn't include the keyword
- 17:15:37 [myles]
- AmeliaBR: Things get complicated with <path> because this had 2 separate properties for the fill rule. Filling vs what's the effect when it's in a clip-path.
- 17:16:06 [myles]
- AmeliaBR: How do we deal with this conflict between having a keyword as part of the shape function vs having a separate property which doesn't make sense for <clipPath>
- 17:16:47 [myles]
- AmeliaBR: I came up with a couple options. The one that seemed to have people most support is that the keyword within the shape function includes "auto" as the default, and the default would look up the other SVG properties. But if you set the value otherwise, it would override the old SVG properties and we maybe eventually deprecate the SVG properties.
- 17:17:22 [myles]
- AmeliaBR: If you specify a fill-rule keyword in motion-path, it's ignored, but that's not a problem. The only place where it's a problem with <shape> where it gets filled. We're specifying where if you set a fill rule in the function, it overrules the fill-rule property.
- 17:17:32 [myles]
- AmeliaBR: The default behavior is defined in all other cases to match the current behavior.
- 17:17:48 [myles]
- heycam: I like that. I'm not sure we need an explicit "auto" as opposed to just its absence.
- 17:18:07 [myles]
- TabAtkins: We do, for ... some case. There is a case related to <path>
- 17:18:25 [myles]
- TabAtkins: If path() takes a keyword, where the winding rule is determined by context, you need to be able to say "go grab from the other property explicitly"
- 17:18:31 [fantasai]
- +1 to heycam
- 17:18:44 [myles]
- heycam: This is a component of one value, and it's optional, can we just use its optionality?
- 17:18:50 [myles]
- AmeliaBR: So the auto behavior is the "no keyword specified" behavior
- 17:19:11 [myles]
- TabAtkins: That would work. It just runs into my dislike of having omitted values being unwritable
- 17:19:21 [myles]
- heycam: There are a lot of properties that have optional keywords
- 17:19:24 [astearns]
- q?
- 17:19:26 [myles]
- fantasai: <lists them>
- 17:19:32 [myles]
- TabAtkins: I get touchy
- 17:19:37 [myles]
- TabAtkins: I won't fight it
- 17:19:46 [TabAtkins]
- s/touchy/tetchy/
- 17:20:07 [fantasai]
- s/I get/Most of them are booleans, but when more than one value
- 17:20:15 [myles]
- AmeliaBR: The benefit of heycam's approach is that shipping for shapes in clip-path and shape-outside, we don't need to change anything, because the change would only come in paths where the author behavior is different from the current default behavior
- 17:20:32 [myles]
- heycam: Are their other elements other than <path> where we might want to have a default value that's not "go and look at the fill-rule property"?
- 17:20:41 [myles]
- AmeliaBR: All the other cases the default value will be to just use one of the existing keywords.
- 17:20:49 [myles]
- TabAtkins: even-odd is the default
- 17:21:05 [myles]
- heycam: There's no value in adding an explicit auto keyword to say "look at the fill-rule property" for these other cases?
- 17:21:10 [myles]
- TabAtkins: Those other cases don't have a property.
- 17:21:27 [myles]
- AmeliaBR: It wouldn't make sense to have a div with both a clip-path and a shape-outside and also set a fill-rule in another property. That would be confusing
- 17:22:07 [myles]
- TabAtkins: There's only the two things that have the information defined by another property, and there isn't a use case to have arbitrary things rely on those two, it's just due to SVG's existing behavior to rely on those two
- 17:22:07 [myles]
- TabAtkins: and that's it.
- 17:22:16 [tantek]
- tantek has joined #css
- 17:22:25 [myles]
- astearns: The proposed resolution is to make this an optional keyword with just the two values, and default to even-odd or "lookup depending on context"
- 17:22:46 [myles]
- AmeliaBR: Withing the context of d= then not specifying the keyword would the the SVG legacy beahvior. Specifying the keyword behavior would mean "ignore the fill-rule and clip-rule properties"
- 17:22:54 [myles]
- astearns: Any objections?
- 17:23:06 [myles]
- RESOLVED: make an optional keyword with just the two values, and default to even-odd or "lookup depending on context"
- 17:23:39 [myles]
- Topic: Definition of containing-box for ray()
- 17:23:40 [astearns]
- github: https://github.com/w3c/fxtf-drafts/issues/369
- 17:23:43 [svillar_]
- svillar_ has joined #css
- 17:24:38 [myles]
- TabAtkins: There's not actually a definition of what containing box to use for ray(). It just says "the containing box" and that's not a term. It doesn't mean any thing. So what's the box? So we know how long the ray is. Where the 100% point is. There's a few possibilities
- 17:24:59 [myles]
- TabAtkins: We could just choose one. Maybe the containing block of the abspos. Or we can alter the grammar of the property a bit to have its containing box specified like how shape() does
- 17:25:18 [myles]
- TabAtkins: If we did so, we would be referring to the box of the parent element, not the box of the element being motion-pathed
- 17:25:23 [myles]
- chris: i prefer the second one
- 17:25:24 [myles]
- TabAtkins: me too
- 17:26:07 [myles]
- AmeliaBR: Would this also affect other ways of defining the path? So the path shape would also be repositioned to be relative to the containing block instead of relative to the initial position of the element that you're actually moving?
- 17:26:17 [myles]
- TabAtkins: Yes. That's what ewilligers is suggesting. URLs, rays, and paths also gain the ability to have an optional box
- 17:26:22 [myles]
- AmeliaBR: Is this a breaking change?
- 17:27:01 [myles]
- TabAtkins: Shapes already have this, that's part of the grammar. For paths, we can choose the default appropriately so paths don't change behavior. Whatever value that is, ray() should work the same way. IDR which value that is.
- 17:27:16 [myles]
- AmeliaBR: How does that apply to SVG if we're going up to the parent element
- 17:27:28 [myles]
- AmeliaBR: Are we going to the literal parent element like <g>? Or relative to the view box?
- 17:27:40 [myles]
- heycam: Does this come back to the previous discussion about the box keyword that we moved into a different spec?
- 17:27:48 [myles]
- TabAtkins: We've already altered this spec for using the box keyword
- 17:28:07 [myles]
- heycam: So that should define how this works for SVG
- 17:28:25 [myles]
- AmeliaBR: It might not be the most intuitive if the parent is <g> then the fill-box of that group might be a bit weird. But if we define it early before there's too much content using these properties ...
- 17:28:34 [myles]
- heycam: Was ray() added for rounded display?
- 17:28:37 [myles]
- TabAtkins: yes
- 17:28:48 [myles]
- heycam: If we have control over what box, then that satisfies that use case?
- 17:28:51 [myles]
- TabAtkins: I believe so.
- 17:29:29 [myles]
- astearns: Do we have a way forward here?
- 17:29:41 [myles]
- heycam: It feels slightly overkill having these keywords everywhere, but it's okay.
- 17:30:09 [myles]
- TabAtkins: My own objection to that is that they're all the same, shapes and paths and rays are all the same. I would like CSS to do it consistently right from the start
- 17:30:17 [myles]
- heycam: If you can specify the box in some, then it should be the default...
- 17:30:18 [fantasai]
- +1
- 17:30:19 [myles]
- TabAtkins: Yeah.
- 17:30:28 [heycam]
- s/the default/all/
- 17:30:56 [myles]
- astearns: Proposed resolution: All of the offset-path values allow a coordinate box, treated the same as today's basic shape (which I know is under-defined)
- 17:31:09 [myles]
- astearns: It is well-defined, it's just in a weird part of the spec, i will fix)
- 17:31:18 [myles]
- RESOLVED: All of the offset-path values allow a coordinate box, treated the same as today's basic shape
- 17:31:35 [myles]
- TabAtkins: shane is no longer part of CSSWG, can I replace him as an editor?
- 17:31:43 [myles]
- astearns: Will you actually be able to spend time on it?
- 17:31:50 [myles]
- TabAtkins: I'd like to fix it up. I can spend more than 0 time.
- 17:32:07 [myles]
- astearns: okay
- 17:32:23 [myles]
- RESOLVED: move shane to former editors, add TabAtkins as a current editor
- 17:34:13 [fantasai]
- ScribeNick: fantasai
- 17:34:41 [fantasai]
- Topic: font-display
- 17:35:05 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4108
- 17:36:00 [TabAtkins]
- https://github.com/w3c/csswg-drafts/issues/4108
- 17:36:02 [TabAtkins]
- github: https://github.com/w3c/csswg-drafts/issues/4108
- 17:36:33 [fantasai]
- TabAtkins: When I originally drafted the font-display values, the last one, optional, I intended to be as much as possible "make the user's experience smooth even if they don't get pretty fonts"
- 17:36:45 [fantasai]
- TabAtkins: Wasn't super clear in the spec, and implementers came up with answers that don't satisfy that goal
- 17:37:00 [fantasai]
- TabAtkins: Within first 100ms or less, still creates a layout jump
- 17:37:05 [fantasai]
- TabAtkins: Jake was running into the same problem
- 17:37:13 [fantasai]
- TabAtkins: wanted smooth page display without any layout jank, and wasn't getting it
- 17:37:25 [fantasai]
- TabAtkins: I believe the current text addresses it, perhaps with an extra comment
- 17:37:34 [fantasai]
- TabAtkins: Would like some discussion from y'all
- 17:38:06 [TabAtkins]
- https://drafts.csswg.org/css-fonts-4/#valdef-font-face-font-display-optional
- 17:38:31 [fantasai]
- TabAtkins: My text atm, if font can be loaded "immediately", can be used, otherwise ignore it
- 17:38:41 [fantasai]
- TabAtkins: can't be used for the rest of the page's lifetime. Refresh page, can try again
- 17:38:49 [fantasai]
- TabAtkins: Paried with some additional info
- 17:39:04 [fantasai]
- TabAtkins: MUSTNOT cause the layout of the page to jump
- 17:39:17 [fantasai]
- TabAtkins: allowed to delay initial rendering if needed to load the font
- 17:39:30 [fantasai]
- TabAtkins: specifically, we have some issues wrt how to do in Chrome, can put more detail in the spec
- 17:39:36 [fantasai]
- TabAtkins: Anyone have comments on details?
- 17:40:02 [fantasai]
- TabAtkins: If in memory cache for tab, use the font. Otherwise we go to disk, takes too long, skip it
- 17:40:13 [fantasai]
- TabAtkins: Once loaded, may ro may not be present for future navigation depending on cache state
- 17:40:20 [fantasai]
- TabAtkins: Cannot depend on font ever being there
- 17:40:38 [fantasai]
- TabAtkins: Want to make sure that all font pre-loads bring the font into the memcache
- 17:40:43 [fantasai]
- TabAtkins: track which fonts are there
- 17:41:05 [fantasai]
- TabAtkins: When preloaded font is optional, delay loading to give time to get off disk -- or extremely fastnetwork
- 17:41:10 [fantasai]
- TabAtkins: otherwise, don't delay
- 17:41:45 [fantasai]
- TabAtkins: If you don't do anything special on your page, just say font is optional
- 17:41:51 [fantasai]
- TabAtkins: almost guaranteed to not have font on first page load
- 17:42:09 [fantasai]
- TabAtkins: chance of available on future page loads, but not guaranteeed, e.g. if on device with small cache
- 17:42:53 [fantasai]
- TabAtkins: If it's a preloaded font, then very likely to be load on future navigations because we will delay rendering to load into memory cache
- 17:42:57 [heycam]
- q+
- 17:42:57 [fantasai]
- s/small cache/small memory/
- 17:43:10 [fantasai]
- TabAtkins: because preloading is a hin that something is important enough to kick of load asap
- 17:43:18 [fantasai]
- TabAtkins: That seems to satisfy the use cases for optional that we want to hit
- 17:43:29 [fantasai]
- TabAtkins: allowing pl to have completely jank-free font-optional experience
- 17:43:36 [fantasai]
- TabAtkins: Try your best to use it, but prioritize no jank
- 17:43:46 [myles]
- q+
- 17:43:51 [astearns]
- ack heycam
- 17:44:00 [fantasai]
- heycam: not sure how much is normative vs heuristics
- 17:44:09 [fantasai]
- heycam: but seems a bit weird to me that you have two different behaviors wrt disk cache
- 17:44:24 [fantasai]
- heycam: without preloaded fonts, disk cache is deemed too slow, but link rel=preload it's ok?
- 17:44:45 [fantasai]
- TabAtkins: Not so much it's too slow, but don't want to incur cost of delaying rendering unless indication that it's important to you
- 17:45:03 [fantasai]
- heycam: is this because checking whether the font is in the disk cache is also slow? is it the checking, not the loading?
- 17:45:49 [fantasai]
- TabAtkins: in our implementation, memcache check is fast enough to be synchronous, whereas disk cache is async, we kick off without loading
- 17:46:01 [fantasai]
- heycam: disk cache can be very fast when it's not too big
- 17:46:16 [fantasai]
- TabAtkins: definitely cool to keep things vague enough that UAs can adjust
- 17:46:24 [fantasai]
- TabAtkins: but want preload to cause delay
- 17:46:36 [fantasai]
- heycam: Other thing I was going to say is I'm not really a big fan of optional
- 17:46:40 [fremy]
- q?
- 17:46:45 [astearns]
- ack myles
- 17:46:50 [fantasai]
- myles: I have a lot to say so split into pieces
- 17:47:06 [fantasai]
- myles: Firstly, wnat to make sure it's clear that WebKit will never ever defer first load. So that has to be not a case. that's our philosophy
- 17:47:15 [fantasai]
- myles: Can you be super clear about which, you listed like 3 main pieces
- 17:47:22 [fantasai]
- myles: one is deleted number 100ms and replaced with words
- 17:47:34 [fantasai]
- myles: one is never cause layout jank
- 17:47:40 [fantasai]
- myles: last one was about preloading
- 17:47:44 [fantasai]
- myles: which are normative
- 17:47:51 [fantasai]
- TabAtkins: first two are normative, in the spec
- 17:47:58 [fantasai]
- TabAtkins: third one I would like to put in the spec
- 17:48:10 [fantasai]
- myles: The spec shouldn't use words mem cache and disk cache, those are impl details
- 17:48:17 [fantasai]
- myles: still not guaranteed to get the font even if preload
- 17:48:21 [fantasai]
- myles: there's nothing testable here
- 17:48:31 [fantasai]
- myles: So I think this should be evangelism, not in a spec
- 17:48:40 [fantasai]
- myles: "for our browser, you will get better results if you preload"
- 17:48:49 [fremy]
- q+
- 17:48:49 [fantasai]
- TabAtkins: Talking to internal customers who want no jank on initial load
- 17:49:03 [fantasai]
- TabAtkins: if they don't get it, and instead block loading page, that's a worse user experience
- 17:49:17 [fantasai]
- TabAtkins: so having some reasonable assurance of similar behavior among browsers would be worthwhile
- 17:49:31 [fantasai]
- TabAtkins: ultimately stochastic, cna't depend on it, but difference between 80% and 10%
- 17:49:47 [fantasai]
- myles: Are your internal customers only considering Chrome, or also other browsers?
- 17:49:51 [fantasai]
- [unminuted]
- 17:50:05 [fantasai]
- myles: Other piece I want to mention, dbaron brought up a super valuable point
- 17:50:14 [fantasai]
- myles: I think it supports what heycam said as is last sentence
- 17:50:44 [fantasai]
- dbaron: One of my concerns with this is that a lot of stuff around downloadable fonts is designed to deal with the possibility that you have a pretty large number of faces for various reasons
- 17:51:10 [fantasai]
- dbaron: You might have fonts egmented by character range, multiple weights 4-6 of them, a lot of the mechanisms around downloadable fonts were designed to load lazily
- 17:51:14 [fantasai]
- dbaron: define a library, fetch the ones you need
- 17:51:20 [fantasai]
- dbaron: so some of this pre-loading stuff...
- 17:51:26 [fantasai]
- dbaron: there are cases where you just use one font
- 17:51:38 [fantasai]
- dbaron: those cases probably bias towards symbol font hacks, and text that is all Latin
- 17:51:52 [fantasai]
- dbaron: and maybe things are more complicated in non-Latin languages, or things that use more weghts and stuff like that
- 17:52:02 [fantasai]
- dbaron: one of my big concerns about font-display is that it is per-face
- 17:52:13 [fantasai]
- dbaron: can have situation where your regular font cached and bold font isn't
- 17:52:36 [fantasai]
- dbaron: and using downloadable font permanently for regular weight and local font for bold might be worse than all of the other cases
- 17:52:47 [fantasai]
- TabAtkins: Those can still totally happen is the font load just doesn't occur
- 17:52:53 [fantasai]
- dbaron: if you have network failures can happen
- 17:53:00 [fantasai]
- myles: optional makes it more likely that it fails
- 17:53:05 [myles]
- q_
- 17:53:06 [myles]
- q+
- 17:53:07 [astearns]
- ack fremy
- 17:53:28 [fantasai]
- fremy: As an author, at this point, with current proposal for optional, I would be very unlikely to use it. Because more likely to not get your font than to get it
- 17:53:31 [fantasai]
- fremy: why bother?
- 17:53:41 [fantasai]
- fremy: Only if user keeps using your site regularly, not going to be in memory
- 17:53:55 [dbaron]
- s/other cases/other cases (including flashing, or fallback for all the fonts)/
- 17:53:57 [fantasai]
- fremy: not unless constantly in use
- 17:54:22 [fantasai]
- myles: no, it's valuable for web sites while you're navigating through mutiple pages on the site
- 17:54:29 [fantasai]
- TabAtkins: won't work on single-page app, don't use it in one
- 17:54:34 [AmeliaBR]
- q+
- 17:54:45 [fantasai]
- fremy: You're extremely unlikely to get the font, then why bother? You are going to download the font anyway.
- 17:54:59 [fantasai]
- TabAtkins: Your case is a single-page app that gets closed and reopneed every day
- 17:55:05 [astearns]
- zakim, close queue
- 17:55:06 [Zakim]
- ok, astearns, the speaker queue is closed
- 17:55:26 [fantasai]
- TabAtkins: preload signal intention is that, if it's still in your disk cache, it will likely get used the 2nd day and subsequent days, because giving it enough time fo rthat
- 17:55:26 [Karen]
- Karen has joined #css
- 17:55:33 [fantasai]
- fremy: Safari said they don't want to block rendering
- 17:55:48 [fantasai]
- myles: Internal clients care that usage gets up to 80%, but we're absolutely not going to block rendering
- 17:55:56 [fantasai]
- myles: That's not going to work in Safari
- 17:56:10 [fantasai]
- TabAtkins: assuming ppl aren't using optional, then comfortable with janky 2 frames and then stable layout
- 17:56:32 [fantasai]
- myles: I'm OK with you've shown the page with fallback font then never show the page with loaded fonts
- 17:56:35 [fantasai]
- TabAtkins: ...
- 17:56:48 [fantasai]
- TabAtkins: If it's likely that optional will never give them assurance to see font, then they'll use JS to delay rendering manually
- 17:56:54 [fantasai]
- TabAtkins: or will use one of the values that wll cause jank anyway
- 17:57:07 [fantasai]
- myles: This is an intractable problem. We can't never delay rendering and have the disk cache be able to serve tehse requests
- 17:57:20 [fantasai]
- myles: given that these customers will never get what they're aiming for, I don't think that the association with preloading makes sense
- 17:57:32 [fantasai]
- TabAtkins: Want to check understanding
- 17:57:54 [fantasai]
- TabAtkins: website authors using fallback, getting a couple frames in one font and then frames in other font, it's better than getting a few frames of nothing and thn getting the page?
- 17:57:59 [fremy]
- q+
- 17:57:59 [fantasai]
- s/thn/then/
- 17:58:07 [myles]
- q-
- 17:58:30 [astearns]
- ack AmeliaBR
- 17:58:39 [fantasai]
- AmeliaBR: I've heard a lot of confusion of what's the purpose of this value
- 17:58:44 [fantasai]
- AmeliaBR: Tab said the goal was to avoid jank
- 17:59:05 [fantasai]
- AmeliaBR: If that's the goal then maybe other smarter ways this can happen, like waiting until doing a major repaint anywan and then block in the font
- 17:59:10 [fantasai]
- AmeliaBR: catches the single-page app update situation
- 17:59:14 [fantasai]
- AmeliaBR: but I don't kno if that's the best
- 17:59:47 [fantasai]
- AmeliaBR: As a user, the idea of downloading fonts but then not using them unless I happen to close the page and re=-open it before it gets lost from the cache, that's not a great use of my data plan
- 18:00:22 [fantasai]
- TabAtkins: UA is allowed to skip downloading if it thinks that's reasonable in the circumstances, and metered data is definitely such a circumstance.
- 18:00:52 [fantasai]
- astearns: Done for today
- 18:00:59 [fantasai]
- Meeting closed.
- 18:13:02 [cbiesinger]
- github-bot: end topic
- 18:21:29 [skk]
- skk has joined #css
- 18:21:31 [drousso]
- drousso has joined #css
- 18:48:54 [zcorpan]
- zcorpan has joined #css
- 19:02:50 [drousso_]
- drousso_ has joined #css
- 19:17:26 [Karen]
- Karen has joined #css
- 19:42:48 [dauwhe_]
- dauwhe_ has joined #css
- 20:04:39 [Zakim]
- Zakim has left #css
- 20:07:43 [rego]
- rego has joined #css
- 20:55:09 [aja]
- aja has joined #css
- 21:01:38 [drousso]
- drousso has joined #css
- 21:06:11 [aja]
- aja has joined #css
- 21:15:58 [Karen]
- Karen has joined #css
- 21:40:44 [drousso_]
- drousso_ has joined #css
- 21:48:39 [Zakim]
- Zakim has joined #css
- 21:48:48 [astearns]
- zakim, end meeting
- 21:48:48 [Zakim]
- As of this point the attendees have been (no one)
- 21:48:49 [Zakim]
- RRSAgent, please draft minutes
- 21:48:49 [RRSAgent]
- I have made the request to generate https://www.w3.org/2020/01/23-css-minutes.html Zakim
- 21:48:53 [Zakim]
- I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye
- 21:48:57 [Zakim]
- Zakim has left #css
- 22:05:42 [jamesn]
- jamesn has left #css
- 22:33:04 [birtles]
- birtles has joined #css
- 22:40:25 [jfkthame]
- jfkthame has joined #css
- 22:48:26 [faceless2]
- faceless2 has joined #css