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