IRC log of css on 2020-01-23

Timestamps are in UTC.

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