13:58:04 RRSAgent has joined #css 13:58:04 logging to https://www.w3.org/2021/09/29-css-irc 13:58:06 RRSAgent, make logs Public 13:58:07 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 13:58:35 dholbert has joined #css 13:59:42 jfkthame has joined #css 14:00:57 flackr has joined #css 14:01:24 oriol has joined #css 14:02:22 present+ 14:02:35 dgrogan has joined #css 14:02:40 present+ 14:02:52 present+ 14:02:53 present+ 14:02:54 present+ 14:02:59 present+ 14:03:03 xfq_ has joined #css 14:03:11 present+ 14:03:15 present+ 14:03:17 present+ 14:03:26 present+ 14:03:30 present+ 14:04:59 present+ 14:05:16 present+ 14:05:18 fremy has joined #css 14:05:34 present+ 14:05:53 present+ 14:06:11 present+ 14:06:48 present+ 14:07:07 https://github.com/w3c/csswg-drafts/issues/499#issuecomment-926122734 14:07:18 topic: Decorative grid-cell pseudo-elements 14:07:29 github: https://github.com/w3c/csswg-drafts/issues/499#issuecomment-926122734 14:07:37 eeeps has joined #css 14:08:14 eugene has joined #css 14:08:26 @fantasai This is largely prompting from @jensimmons going over use-cases for this 14:08:45 @fantasai There was a syntax in the original context that was grid-area pseudo element as the grid area shorthand 14:08:57 @fantasai so we asked what are the questions we need to answer in the spec to have somethign that works 14:09:07 s/@fantasai/fantasai:/ 14:09:08 +1 14:09:53 fantasai: (summarized comment) 14:09:55 [ fantasai summarizes comment https://github.com/w3c/csswg-drafts/issues/499#issuecomment-926122734 ] 14:10:25 fantasai: would not accept the grid-placement properties 14:12:26 fantasai : ...a whole pile of details that we think makes this into something we can possibly spec up 14:12:32 :) 14:12:38 q+ 14:12:45 q+ 14:12:54 chris has joined #css 14:12:54 jensimmons : the goal here is to create a pseudo element without having to place empty divs in a cell; 14:12:57 q+ 14:13:01 present+ 14:13:03 q+ 14:13:09 rrsagent, here 14:13:09 See https://www.w3.org/2021/09/29-css-irc#T14-13-09 14:13:14 jensimmons : this really is about creating a way to target a track an area or a cell directly and not need empty divs 14:13:35 jensimmons : this felt like the simplest approach without having all the craziness 14:14:19 Rossen_ : we'll go through the queue, circle back to the specifics and knock out some of the bullets 14:14:31 ack emilio 14:14:55 emilio : are they tree-abiding pseudo elements? 14:14:58 fantasai : yes 14:15:14 dholbert_ has joined #css 14:15:25 emilio : seems a bit weird, imagine you have a bunch of conditions ... 14:15:32 (sorry missed some parts) 14:15:45 emilio : need to go through all the grid area selectors independent of all the 14:15:48 emilio: concerned about creating multiple boxes per selector 14:16:10 emilio : it can possibly work, it's just weird to do that 14:16:30 emilio : you can have a first-line style, if the page doesn't use them at all, just skip this mess 14:16:38 emilio : I need to work out all the details 14:16:43 i/emilio : it can/fantasai: Not sure, but are you referring to how you need to do placement before deciding which/how many boxes you have? 14:17:04 emilio : multiple of these selectors can match ; the fact that this happens before box construction 14:17:16 iank_ this would invalidate layout potentially right? 14:17:25 fantasai : placement first but then layout second 14:17:35 fantasai just impacts box-tree and auto-placement 14:17:46 s/match/match, and their declarations need to cascade/ 14:18:17 s/fantasai/fantasai:/ 14:18:19 @emilio: you mean like table backgrounds and borders ^_^ 14:18:22 jensimmons there are use-cases where it could be helpful to do more than borders and backgrounds 14:18:39 q 14:18:49 jensimmons if there's a hard limit, that would make things too many paints, too many cycles; then bring it in. I'd like to see if we can not limit it right out of the gate 14:18:56 q+ 14:19:01 s/jensimmons/jensimmons:/ 14:20:19 Rossen_ : feedback is creating grid cells starts off with this very simple and seemingly very easy expectation that oh we'll just put a background 14:20:51 Rossen_ : then as soon as you go down the rabbit hole, you're talking about having user expectations that are matching that of focus-handling, all kinds of eventing and capabilities 14:21:16 Rossen_ : for example focus and app development management that make sense, especially in the grid layout which can vary vastly 14:21:34 q? 14:21:41 Rossen_ : as we approach this kind of solution, it is in a way that we are not ignoring everything coming down the line in expectations 14:21:43 ack Rossen 14:21:59 Rossen_ : multi-column columns where people want to be able to target and style individual columns 14:22:03 bkardell_ has joined #css 14:22:09 ntim has joined #css 14:22:11 Rossen_ : the difference there is that multi-column is a scoped use-case to grid 14:22:16 smfr has joined #css 14:22:43 Rossen_ : if we start going down the path again, if we don't have great answers from the get-go for the use-cases I enumerated, then all we are doing here is solving the easy use-case of "let's put a little bit of background" 14:23:05 Rossen_ : I'm concerned about trying to fit functionality and user expectations of elements into pseudo-elements 14:23:05 q? 14:24:10 q? 14:24:22 rachelandrew : I like the idea of being able to do this; my concern if we don't solve the borders on grid-cells issues first 14:24:30 rachelandrew : authors will use this to style the gaps 14:24:36 Rossen's concerns all sound like separate issues to raise on spec text that we need to write - yes, this will be complicated, we shouldn’t minimize the effort. But it will be worth the work 14:24:50 ack rachelandrew 14:25:08 rachelandrew : I kind of like this idea, I understand where Rossen_ is coming from 14:25:27 rachelandrew : We add all these pseduo-elements and authors use it to add borders because authors want to use them to style the gaps 14:25:42 rachelandrew : that comes up for me far more often than trying to s tyle the grid 14:25:53 I agree with rachelandrew 's point — let's make sure we spec styling gaps before finishing this... and encourage implementors to ship gap styling before or with cell styling. 14:25:56 rachelandrew : if people can do this grid, why can't we do this with multi-column? 14:26:15 rachelandrew : it's the same in their minds; is this not something we'll need to do in multi-column too? 14:26:21 rachelandrew : for authors, it could reduce mental load 14:26:31 ack fantasai 14:26:31 fantasai, you wanted to react to rachelandrew to respond to the concern about gaps 14:26:35 fantasai : +1 to rachelandrew 14:26:41 fantasai : gaps issue is coming 14:26:52 fantasai: I agree with the prioritization of shipping order 14:27:06 chrishtr : it sounds like this is a feature that allows you to do something you can already do in a more convenient way 14:27:24 q+ 14:27:29 chrishtr : it sounds like it would be quite - in addition to the issues Rossen_ mentioned, could be quite complicated - could slow down interactions on implementation in the browser 14:27:35 chrishtr : does this use-case justify complexity 14:27:36 ack chrishtr 14:27:48 jensimmons : I think there are quite a few use-cases that this could solve for 14:27:57 I'm not sure what would slow things down more than adding those elements as real HTML 14:28:02 Rossen_ : you can do that if you add elements there 14:28:16 chrishtr : you can do all this with adding the elements 14:28:25 ack iank_ 14:28:27 jensimmons : there's a big difference between having the space and targeting the space with CSS 14:28:36 iank_ : I want to bring up how this interacts with a11y 14:28:47 @TabAtkins: you have to add them during layout, and their order in the "DOM" depends on the grid placement which can change depending on container queries etc... 14:28:52 s/having the space/having elements in the tree/ 14:28:58 iank_ : currently we have before and after markup, depending on the context 14:29:10 iank_ : I'd be concerned that people would use the content property 14:29:15 q? 14:29:18 iank_ : to add more content in CSS 14:29:21 Don't pseudo-elements affect layout and take up space? 14:29:37 ack florian 14:29:38 yeah, that's my understanding 14:29:47 florian : from an author standpoint, this syntax seems spot-on 14:29:55 florian : this makes it extremely learnable 14:30:15 s/spot-on/spot-on, once I've seen it can't think of anything else/ 14:30:19 florian : when you start thinking about pointer events, etc. - on the one hand yes, on the other, we're overdue on discussing these issues 14:30:50 florian : I'd like to hear from jensimmons about use-cases that go beyond border and background 14:30:58 florian : without needing a subtree or a pseduo-element 14:31:01 q? 14:31:34 jensimmons : 14:31:57 jensimmons : I feel unprepared to answer this question 14:32:31 jensimmons : it would be great to allow an element to tilt without an nth-child 14:32:39 q+ 14:32:43 q+ 14:32:43 jensimmons : there's this idea that content can flow automatically, especially with responsive design 14:33:04 q? 14:33:25 jensimmons : not wanting to write a bunch of breakpoints; need a way to separate particular areas on the grid without manipulating the way content is flowing 14:33:36 jensimmons : this is not about creating more content, this is about styling 14:33:49 GameMaker has joined #css 14:34:26 ack emilio 14:34:45 emilio : the example shared jensimmons, I thought the idea was creating boxes / grid-items and being able to style them 14:35:02 emilio : what you showed was that these items would exist inside the grid 14:35:17 fantasai : I don't think we can do that example in the proposal that we have 14:35:31 fantasai : we could possibly do that if you didn't want the content to rotate 14:35:42 fantasai : you could do that with the pseudo-items and have the grid-item on top of that 14:35:51 emilio : if I understand, then you can do this with regular elements 14:36:03 fantasai : the problem is that with a regular element, you would have to inject a bunch of empty divs 14:36:10 https://github.com/w3c/csswg-drafts/issues/1943 is more like that first use case 14:36:11 emilio : i agree, I just wanted to wrap my head around it 14:36:25 emilio : a syntax to inject a bunch of elements onto the grid in a particular order to style them 14:36:40 fantasai : if we could select things by their placement in the grid, that would also be awesome 14:36:59 q- 14:37:01 fantasai : that has a problem of the selection being dependent on a layout 14:37:09 tantek has joined #css 14:37:12 fantasai : change as the size of the page changes 14:37:18 present+ 14:37:37 fantasai : part of what this is trying to solve is a handful of cases that don't involve styling the element itself 14:38:08 iank_ : variable content types, want content on a diagonal, how does this work for that case? It seems like you want to insert pseudo-elements based on the size of the grid 14:38:28 present+ 14:38:31 fantasai : block out the cells you want to block out by making them 14:38:42 iank_ : wouldn't that expand out the grid 14:38:55 fantasai : yes, you wouldn't use that when you only have a few items 14:39:24 fantasai : a lot of these are cases where the author knows the minimum and maybe the maximum but doesn't know the number of columns because that depends on how wide the screen is 14:39:42 iank_ : I'm a little suspicious of the "knows how many items". For that use-case where you want to skip grid areas 14:39:54 iank_ : It seems like it's actually easier to inject DOM 14:40:04 iank_ : Or a grid property that says, skip this grid area 14:40:32 iank_ : dynamic size of content didn't mesh in my mind 14:40:51 fantasai : I agree in that use-case it would be better to inject DOM 14:41:06 s/inject DOM/specify skipped cells in a property/ 14:41:07 s/inject DOM/specify skipped cells in a property/ 14:41:27 astearns : Next steps to draw out use-cases and corner-cases so we can talk through code examples 14:41:43 astearns : it doesn't sound like we're ready to say yes let's put this in a working draft 14:41:45 q+ 14:42:04 iank_ : I don't think we need an editor's draft, just writing down the examples in the issue 14:42:17 astearns : I think this is getting too complicated for an issue 14:42:34 astearns : spec text would be helpful; we wouldn't have to adopt the draft if we weren't happy with it 14:42:59 jensimmons : if folks are willing to explore this area, this seems like something we want to solve 14:43:20 jensimmons : yes, an editor's draft with real-world use-cases 14:43:30 PeterCon has joined #css 14:43:34 jensimmons : then we can point at items and identify what n eeds to be better 14:43:34 ack florian 14:43:47 florian : I support this for those who feel this is a bit early 14:44:02 florian : I came in really liking it and wondering if it's an uncanny valley of too much and not enough 14:44:18 florian : Want to see more examples to see if this comes close enough 14:44:44 iank_ : use-cases written down clearly would be really useful; there might be multiple avenues we can explore 14:45:01 iank_ : we've talked about styling columns and gaps, that could be a different selector 14:45:07 iank_ : multiple avenues we could go down 14:45:11 s/those who feel this is a bit early/those who feel this is a bit early, think of that early spec as an explainer/ 14:45:16 s/that could/the rotated item case, that/ 14:45:28 astearns : makes sense 14:45:49 jensimmons I will help make use-cases 14:45:54 jensimmons I can't help write the spec 14:46:00 rachelandrew happy to help with this 14:46:03 s/jensimmons/jensimmons:/ 14:46:04 s/jensimmons/jensimmons:/ 14:46:10 s/rachelandrew/rachelandrew:/ 14:46:40 astearns : task jensimmons and rachelandrew to work through examples and syntax 14:46:54 astearns: Resolved 14:48:17 RESOLVED: jensimmons and rachelandrew to write up use cases, examples, and syntax for this proposal 14:54:28 vmpstr has joined #css 14:57:39 ScribeNick: TabAtkins 14:58:31 Topic: effect of inert on hit testing 14:58:34 github: https://github.com/w3c/csswg-drafts/issues/6685 14:58:59 smfr: There has been a history of impls of `inert` that haven't matched 14:59:15 smfr: Chrome and Gecko already mismatch, now WebKit is implementing and want a spec that is clear 14:59:26 smfr: Historically, Chrome's was mor ein terms of DOM propagation 14:59:37 smfr: If an event hit an inert node it woudl skip up to an ancestor 14:59:41 present+ 14:59:55 smfr: Gecko was in terms of pointer-events; it woudl ignore the inert element so clicks could go to underneath it 15:00:14 present+ 15:00:16 smfr: On a call a few weeks ago chrishtr said he'd talk to Google folks and see if they're okay with doing Gecko's behavior 15:00:26 smfr: Also questions about whether inert effects APIs like elementFromPoint() 15:00:31 smfr: And some keyboard interactions 15:01:01 chrishtr: I did not unfortunatley get to talk to a11y team in Chrome, but I did review the discussions again. 15:01:25 chrishtr: I think there are pros and cons to both; I think we could just discuss Tim's proposal point-by-point and see if it's okay to everyone 15:01:42 chrishtr: Also no browsers publicly ship the attribute yet, so all browsers are still changeable right now 15:01:54 q+ 15:02:08 smfr: Dialog and Fullscreen specs refer to inert and say it should be applied to the document, with the dialog/fullscreen excepted from the effect 15:02:20 smfr: So even if the attribute ahsn't shipped, there are implications on those features 15:02:31 chrishtr: I didn't look at the code for dialog/fullscreen, did anyone else 15:02:54 chrishtr: I assume it ignores hit-test events in the dialog 15:03:46 chrishtr: So I think we can discuss this holistically and probably dialog impl coudl be changed in Chromium, unless someone knows about compat problems 15:04:08 emilio: I doubt the set order issue is going to be a problem for fullscreen/dialog, because they're on the top layer and thus always on top of everything else 15:04:43 emilio: In terms of impl, Gecko's has an internal CSS property called 'inert', and we apply it to everything and reset it on the dialog, that has effects on pointer-events and such 15:04:51 ack bkardell_ 15:05:19 bkardell_: Interesting bc dialog was defined with the terms of top-layer and inertness, but didn't expose them or refer to them elsewhere. They're two separate but related problems, and depending on what you do with the top layer it helps answer the other questions 15:05:52 bkardell_: The way libraries today make dialogs is to create a pseudo-top-layer that's a top-level child of body, so they can make everything else inert 15:06:10 bkardell_: When we define that, and Alice did the initial impl and we did the polyfill, some of the things around top layer are a little wonky maybe 15:06:33 bkardell_: There ahs been an incredible amount of discussion on this topic. Before Alice left on sabbatical, she agreed there were things in Chrome to work on. 15:06:46 bkardell_: So I think it's worth talking about top-layer first to set up the questions about inert, imo 15:06:48 q+ 15:07:06 chrishtr: I see now that Tim did put some comments on Chrome's behavior and quirks 15:07:16 ack smfr 15:07:42 smfr: One fo the fundamental difficulties is the inert spec says you can't make a descendant of an inert node non-inert, and yet the dialog spec says the document is inert and then the dialog (a child of the document) is non-inert... 15:08:02 smfr: And if the impl is pointer-events based, youa re allowed to make a descendant of a pointer-events:none node pointer-events:normal 15:08:45 ntim: WebKit recently implemented a pointer-events-based approach, similar to Firefox 15:09:13 astearns: So bkardell_ suggested starting with top layer 15:09:24 bkardell_: So let's discuss how it's defined and how it works 15:09:46 bkardell_: If it works something like existing impls in libraries, so it's effectively projected to a sibling of the document, we can think about it one way 15:09:51 q+ 15:10:02 bkardell_: If talking about the tree itself and where it lives normally in the tree, things get a lot more complicated 15:10:07 q+ 15:10:21 ack smfr 15:10:32 smfr: I think we're happy with the way top-layer is specified; it renders z-ordered above the rest of the doc 15:10:36 q+ 15:10:41 smfr: I think Chrome/WEbKit do that now 15:10:51 smfr: If there are implications for event propagation, maybe they're not clear enough 15:11:00 scribe+ 15:11:11 ack TabAtkins 15:11:15 TabAtkins: IIRC, the way we've described top layer is that it get reparented in the layer tree sense 15:11:24 TabAtkins: being a direct child of the top-level document/canvas/thing 15:11:33 TabAtkins: That way nothing can interfere with its positioning 15:11:44 TabAtkins: That's how we specced it, are we doing something different now? 15:11:50 chrishtr: No, that's what spc and impl do 15:12:02 chrishtr: reparent into new stacking context that is z-indexed above everything else 15:12:06 chrishtr: It's well-specified, afaict 15:12:15 TabAtkins: Shouldn't have any effect on events, that works normally 15:12:23 smfr: https://fullscreen.spec.whatwg.org/#rendering 15:12:26 chrishtr: My guess is chromium, hit testing happens on the layout box tree 15:12:39 chrishtr: so the impl probably sees the dialog element and then fails to look up the tree to see the inert attribute above it 15:12:49 chrishtr: If you see an inert node, stop at that node, but don't check ancestors 15:13:01 chrishtr: I think that's how impl, and not consistent with spec 15:13:23 chrishtr: Maybe we should discuss directly, should the impl just be exactly what Firefox and WebKit have already implemented? 15:13:38 chrishtr: Seems the difference is "?? cannot be iner, except when ... dialog" 15:13:42 emilio: That's a Gecko bug 15:13:49 emilio: Dialog is inert, we use the same mechanism 15:13:55 emilio: should be fixable 15:14:07 emilio: Rest of document is inert so can't do anything 15:14:11 emilio: but that seems like Gecko bug 15:14:18 emilio: other is, does this affect computed value of pointer-events? 15:14:21 emilio: In Gecko it does 15:14:28 futhark has joined #css 15:14:35 emilio: The alternative was to have an internal property and check that everywhere you check pointer-events: none 15:14:46 emilio: This way clearer for implementers and authors 15:14:50 present+ 15:15:03 emilio: And less likely to accidentally cause divergence in the future 15:15:16 s/authors/more useful to authors/ 15:15:20 chrishtr: UA style sheet? 15:15:23 emilio: A bit more magic than that 15:15:44 emilio: It's like an inherited property, which causes a bunch of other properties to compute differently 15:15:52 emilio: It's conceptually same as UA rule 15:16:13 emilio: In practice, we made an internal property to handle the inheritance. 15:16:35 emilio: Anything in subtree will have pointer-events: none forever, unless inert value is changed on descendant 15:17:17 [discussion of the implementation detail and how it's not visible to authors] 15:17:26 bkardell_: ??? 15:17:29 emilio: ???? 15:17:32 chrishtr: What about dialog? 15:17:33 https://searchfox.org/mozilla-central/source/layout/style/res/ua.css#171 15:17:38 https://searchfox.org/mozilla-central/source/layout/style/res/html.css#836 15:17:39 emilio: Sets the internal bit on the document element 15:17:53 emilio: and then dialog has a UA rule that applies this inert property to the default when modal 15:18:00 s/???/does that also affect the accessibility bits?// ans: yes 15:18:02 chrishtr: So special exception not accessible to developers 15:18:04 emilio: right 15:18:21 emilio: There's no way, spec-wise, for devs to override that 15:18:28 emilio: we could add that capability, unsure how it would look 15:18:38 emilio: Spec says anything under inert subtree is inert, and no way to un-inert a node 15:18:51 flackr: I think it'd get complicated for anything other than top-layer to override 15:18:57 bkardell_: That's why top layer is important here 15:19:04 bkardell_: if you are in top layer, can reason about things 15:19:14 bkardell_: some details that are observable that we need to agree on and document 15:19:41 bkardell_: I believe that back in April, Alice suggested that she might want to take a look at revamping some of Chrome's internals to use a pointer-events-like behavior 15:19:53 bkardell_: There was some hesitance to say the magic *was* pointer-events 15:19:59 bkardell_: because seemed architecturally unfortunate 15:20:01 emilio: why? 15:20:13 emilio: pointer-events shouldn't really be a CSS property, but we're way past that point now 15:20:28 emilio: So given that, I'm happy to say that inert is managed via pointer-events 15:20:36 chrishtr: In the Intent to Ship that didn't complete for this feature 15:20:43 chrishtr: Alice tried it and didn't like it 15:21:00 chrishtr: Didn't like that not targettable from getElementsFromPoint 15:21:09 bkardell_: makes inspector break 15:21:17 emilio: yeah, but that's an issue with inspector 15:21:19 q+ 15:21:29 chrishtr: It doesn't make sense to have pointer-events: none; and then ... 15:21:34 chrishtr: UA can special-case inspector 15:21:43 bkardell_: we have problem with top layer already, can't inspect stuff underneath 15:21:52 ack chrishtr 15:21:55 ack smfr 15:22:01 smfr: We could always add an options dictionary to getElementsFromPoint 15:22:29 smfr: To let it include pointer-events:none or inert if we wanted to 15:22:57 bkardell_: And then devtools would use that by defualt 15:23:12 chrishtr: and we could do that as a feature enhancement and devtools can just use magic 15:23:24 chrishtr: asking tim/simon, is what Emilio said consistent with what WebKit does? 15:23:41 chrishtr: You do some magic thing that makes descendants of inert p-e:none and the dialog is exempted? 15:23:55 ntim: It's mostly the same yeah, we just don't hcange the computed styles for pointer-events 15:24:24 emilio: I slightly prefer actually changing the computed style, for the reasons i described before, but don't feel super strongly. 15:24:39 emilio: Would just be a little unfortunate and easy to make mistakes in the future for authors 15:25:04 ntim: Not changing computed styles gives us flexibility to change inert in the future or not be fully consistent with the p-e:none value, but don't feel strongly either 15:25:19 bkardell_: I have a slight pref for Apple's because it makes the impl detail visible 15:25:51 emilio: We do specify some things in terms of UA style, and other things in terms of "behaves as", so I don't have a strong opinion, it's just a slight pref toward reflecting it in the computed style 15:25:59 s/makes the impl detail visible/ff's makes the implementation details observable 15:26:16 chrishtr: So it sounds like what's already in WK/Gecko is fine, and Chrome can change and the WG can agree on that in spec 15:26:23 chrishtr: So next is whether pointer-events:none is okay 15:26:39 astearns: Do we want to resolve on that first? 15:26:45 chrishtr: Talk about the next first 15:27:20 chrishtr: So Chrome originates the event up the tree to the first non-inert ancestor, Gecko just hit-tests down to the next non-inert in the stacking layer 15:27:36 chrishtr: I see why Gecko does this - it's easy to reuse behavior - but do we think it's the right semantic choice? 15:27:49 emilio: No strong opinion, but if there is a better choice it shoudl be a pointer-events value 15:28:14 ntim: Makes sense to me because you can have non-inerts inside of inert trees 15:28:54 chrishtr: But that's non web-exposed as a feature, just for this thing 15:29:11 TabAtkins: But it's a reasonable use-case that authors would want to do similar things with; why would we treat it as a special case they can't use? 15:29:30 chrishtr: Right. I think the question of mixed inertness is separate from whether you hit-test below it. 15:29:35 emilio: Yes, orthogonal 15:29:49 q+ 15:29:52 chrishtr: So argument ot make is that p-e:none is already there and sky isn't falling, so maybe it's fine 15:30:07 emilio: Yeah, and if we did it another way anyway, we should just add a new p-e value to it 15:30:31 flackr: I think hit-testing behidn the thing works well for a lot of use-cases where you have an event handler on an ancestor 15:30:59 TabAtkins: That works either way tho - Chrome's behavior will walk the 15:31:37 smfr: But that could mean an element gets the event even if you're lcicking elsewhere, if the clicked child is positioned outside 15:31:48 TabAtkins: Yeah, but it would have gotten the element if the child weren't inert 15:32:13 smfr: [missed about backdrop] 15:32:19 ntim: You can display:none the ::backdrop 15:32:28 ntim: Question was if we can pierce the top-layer, yes we can 15:32:36 chrishtr: Visually yes, but not hit-testing 15:32:41 ntim: Because everything else is inert, yes 15:32:47 q+ 15:32:54 ack smfr 15:33:01 q+ 15:33:22 emilio: Lacking a strong use-case to pursue a new p-e value, I suggest we just stick with none, and maybe change in the future if we feel it's needed 15:33:37 emilio: I'm okay on blocking on the new value if people think it's useful, but unless there's a strong reason to do it... 15:34:01 flackr: And there are a lot of use-case for *not* hitting an ancestor, which is p-e:none today, so we should stick with that by default 15:34:03 ack chrishtr 15:34:07 ack emilio 15:34:21 chrishtr: Agree with emilio and rob that we don't have a strong reasons to *not* use p-e:none, so we should just use that 15:34:25 chrishtr: So that allows us to resolve 15:34:47 chrishtr: I propose we resolve on the webkit behavior - don't expose the computed style (for the reason brian mentioned) and use p-e:none behavior 15:35:07 chrishtr: And when inert is set, force p-e, focus, etc in a user-agent way that's not exposed to devs 15:35:15 chrishtr: And elementFromPoint() skips the inert elements 15:35:30 astearns: I'm a little concerned about having this magic UA behavior... 15:35:56 astearns: If it's not *expressible* by authors; I want to make sure that what the UA does is something all the engines can implement in an interoperable way 15:36:03 astearns: Usually that means we have a property with the behavior 15:36:11 astearns: I'm concerned that magic means we might not get the details right 15:36:25 chrishtr: emilio, am I right that the Gecko impl just sets a UA-internal prop? 15:36:27 emilio: Yeah 15:36:46 flackr: And I think it's equivalent to a descendant selector with p-e:none in the UA, and equivalent rule for modals, etc 15:36:58 emilio: Not quite there becuase of shadow dom, it's actually inherited, but close enough 15:37:10 astearns: I don't think we've done a feature as a magic property 15:37:32 TabAtkins: We've never *specified* one as such, but several features are implemented as such 15:37:44 +1 I'm not concerned about speccing this 15:37:49 +1 15:38:02 bkardell_: I kinda agree with everyone else; if we can come up with a demonstrable reason to expose this, that should be a separate discussion 15:38:58 ack fantasai 15:38:58 Proposed resolution: Resolve on WK behavior. Use pointer-events:none, but don't reflect into computed style (use "behaves as" wording); same with user-select and related focus behavior 15:39:16 ntim: question about interaction of inert and modals, what if you have an inert node as ancestor of modal? 15:39:35 emilio: depends on details of how we spec, maybe modal dialogs are just always non-inert 15:40:07 bkardell_: The direct descendant of a top-layer should never be inert, right? 15:40:20 ntim: We could let people explicitly opt out of inert 15:40:28 emilio: I agree this is a different issue 15:40:47 emilio: If we decide that inert works this way, they can still spec it how they want 15:41:05 emilio: I do think that a modal dialog should never be inert unless exlicitly given inert 15:41:11