- From: Sebastian Zartner <sebastianzartner@gmail.com>
- Date: Fri, 12 Nov 2021 21:54:59 +0100
- To: Dael Jackson <daelcss@gmail.com>
- Cc: www-style list <www-style@w3.org>
- Message-ID: <CAERejNZV0sikTOkUkPgsqvtZHSpqOLD-oHLDunRFjcxOT5n=jw@mail.gmail.com>
Just for reference, because it seems the gap issue wasn't mentioned in the grid area pseudo-elements discussion in the end, it is https://github.com/w3c/csswg-drafts/issues/2748. There are also the related issues https://github.com/w3c/csswg-drafts/issues/5080 and https://github.com/w3c/csswg-drafts/issues/6748. Sebastian On Wed, 10 Nov 2021 at 01:03, Dael Jackson <daelcss@gmail.com> wrote: > ========================================= > These are the official CSSWG minutes. > Unless you're correcting the minutes, > Please respond by starting a new thread > with an appropriate subject line. > ========================================= > > > CSS Grid > -------- > > - Discussed proposal for grid-area pseudo elements. There were some > concerns about the grid-area pseudo-elements' identities > depending on grid item placement, and whether use cases would > require scripting and event handling as on elements. > - It was recommended to solve gap styling first, as grid-area pseudos > would likely be leveraged for that if it was not solved first. > https://github.com/w3c/csswg-drafts/issues/499 > - RESOLVED: jensimmons and rachelandrew to write up use cases, > examples, and syntax for this proposal (Issue #499: > https://github.com/w3c/csswg-drafts/issues/499 ) > > Hit Testing > ----------- > > - RESOLVED: 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 (Issue #6685: Impact of `inert` on hit-testing > needs to be specified) > - RESOLVED: Add definition of pointer-events:none, at least, to UI 4 > (Issue #6685) > - RESOLVED: Steal the top-layer spec from Fullscreen, put it into > Position 3 (Issue #6685) > > ===== FULL MINUTES BELOW ====== > > Agenda: https://github.com/w3c/csswg-drafts/projects/22 > > Present: > Rachel Andrew > Rossen Atanassov > Tab Atkins-Bittner > David Baron > Oriol Brufau > Tantek Çelik > Daniel Clark > Emilio Cobos Álvarez > Elika Etemad > Brandon Ferrua > Robert Flack > Megan Gardner > David Grogan > Chris Harrelson > Daniel Holbert > Jonathan Kew > Rune Lillesveen > Chris Lilley > Peter Linss > Alan Stearns > François Remy > Florian Rivoal > Cassondra Roberts > Jen Simmons > Miriam Suzanne > Fuqiao Xue > > Scribe: castastrophe > > > CSS Grid > ======== > > Decorative grid-cell pseudo-elements > ------------------------------------ > github: > https://github.com/w3c/csswg-drafts/issues/499#issuecomment-926122734 > > fantasai: This is largely prompting from jensimmons going over > use-cases for this > fantasai: There was a syntax in the original context that was > grid-area pseudo element as the grid area shorthand > fantasai: so we asked what are the questions we need to answer in the > spec to have something that works > [ fantasai summarizes comment > https://github.com/w3c/csswg-drafts/issues/499#issuecomment-926122734 > ] > fantasai: Would not accept the grid-placement properties > fantasai: ...a whole pile of details that we think makes this into > something we can possibly spec up > jensimmons: The goal here is to create a pseudo element without > having to place empty divs in a cell; > jensimmons: this really is about creating a way to target a track an > area or a cell directly and not need empty divs > jensimmons: This felt like the simplest approach without having all > the craziness > Rossen: We'll go through the queue, circle back to the specifics and > knock out some of the bullets > > emilio: Are they tree-abiding pseudo elements? > fantasai: Yes > emilio: Seems a bit weird, imagine you have a bunch of conditions ... > emilio: Concerned about creating multiple boxes per selector > emilio: Need to go through all the grid area selectors independent of > all the... > fantasai: Not sure, but are you referring to how you need to do > placement before deciding which/how many boxes you have? > emilio: It can possibly work, it's just weird to do that > emilio: You can have a first-line style, if the page doesn't use them > at all, just skip this mess > emilio: I need to work out all the details > emilio: Multiple of these selectors can, and their declarations need > to cascade; the fact that this happens before box construction > iank: This would invalidate layout potentially right? > fantasai: Placement first but then layout second > fantasai: just impacts box-tree and auto-placement > <fremy> @emilio: you mean like table backgrounds and borders ^_^ > jensimmons: There are use-cases where it could be helpful to do more > than borders and backgrounds > 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 > > 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 > 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 > Rossen: For example focus and app development management that make > sense, especially in the grid layout which can vary vastly > 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 > Rossen: multi-column columns where people want to be able to target > and style individual columns > Rossen: The difference there is that multi-column is a scoped > use-case to grid > 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" > Rossen: I'm concerned about trying to fit functionality and user > expectations of elements into pseudo-elements > <astearns> 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 > > 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 > rachelandrew: authors will use this to style the gaps > rachelandrew: I kind of like this idea, I understand where Rossen is > coming from > rachelandrew: We add all these pseudo-elements and authors use it to > add borders because authors want to use them to style > the gaps > rachelandrew: that comes up for me far more often than trying to > style the grid > <jensimmons> I agree with rachelandrew 's point — let's make sure we > spec styling gaps before finishing this... and encourage > implementers to ship gap styling before or with cell > styling. > rachelandrew: If people can do this grid, why can't we do this with > multi-column? > rachelandrew: It's the same in their minds; is this not something > we'll need to do in multi-column too? > rachelandrew: For authors, it could reduce mental load > fantasai: +1 to rachelandrew > fantasai: gaps issue is coming > fantasai: I agree with the prioritization of shipping order > > chrishtr: It sounds like this is a feature that allows you to do > something you can already do in a more convenient way > 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 > chrishtr: Does this use-case justify complexity > jensimmons: I think there are quite a few use-cases that this could > solve for > Rossen: You can do that if you add elements there > chrishtr: You can do all this with adding the elements > jensimmons: There's a big difference between having elements in the > tree and targeting the space with CSS > <TabAtkins> I'm not sure what would slow things down more than adding > those elements as real HTML > <fremy> @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... > <chrishtr> Don't pseudo-elements affect layout and take up space? > <emilio> yeah, that's my understanding > > iank: I want to bring up how this interacts with a11y > iank: Currently we have before and after markup, depending on the > context > iank: I'd be concerned that people would use the content property > iank: to add more content in CSS > > florian: From an author standpoint, this syntax seems spot-on, once > I've seen it can't think of anything else > florian: This makes it extremely learnable > florian: When you start thinking about pointer events, etc. - on the > one hand yes, on the other, we're overdue on discussing > these issues > florian: I'd like to hear from jensimmons about use-cases that go > beyond border and background > florian: without needing a subtree or a pseudo-element > jensimmons: <pulling up slides> > jensimmons: I feel unprepared to answer this question > jensimmons: it would be great to allow an element to tilt without an > nth-child > jensimmons: There's this idea that content can flow automatically, > especially with responsive design > 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 > jensimmons: This is not about creating more content, this is about > styling > > emilio: The example shared jensimmons, I thought the idea was > creating boxes / grid-items and being able to style them > emilio: What you showed was that these items would exist inside the > grid > fantasai: I don't think we can do that example in the proposal that > we have > fantasai: We could possibly do that if you didn't want the content to > rotate > fantasai: You could do that with the pseudo-items and have the > grid-item on top of that > emilio: If I understand, then you can do this with regular elements > fantasai: The problem is that with a regular element, you would have > to inject a bunch of empty divs > <rachelandrew> https://github.com/w3c/csswg-drafts/issues/1943 is > more like that first use case > emilio: I agree, I just wanted to wrap my head around it > emilio: A syntax to inject a bunch of elements onto the grid in a > particular order to style them > fantasai: If we could select things by their placement in the grid, > that would also be awesome > fantasai: That has a problem of the selection being dependent on a > layout > fantasai: change as the size of the page changes > fantasai: Part of what this is trying to solve is a handful of cases > that don't involve styling the element itself > > 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 > fantasai: Block out the cells you want to block out by making them > iank: Wouldn't that expand out the grid > fantasai: Yes, you wouldn't use that when you only have a few items > 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 > iank: I'm a little suspicious of the "knows how many items". For that > use-case where you want to skip grid areas > iank: It seems like it's actually easier to inject DOM > iank: Or a grid property that says, skip this grid area > iank: dynamic size of content didn't mesh in my mind > fantasai: I agree in that use-case it would be better to specify > skipped cells in a property > > astearns: Next steps to draw out use-cases and corner-cases so we can > talk through code examples > astearns: it doesn't sound like we're ready to say yes let's put this > in a working draft > iank: I don't think we need an editor's draft, just writing down the > examples in the issue > astearns: I think this is getting too complicated for an issue > astearns: Spec text would be helpful; we wouldn't have to adopt the > draft if we weren't happy with it > jensimmons: If folks are willing to explore this area, this seems > like something we want to solve > jensimmons: Yes, an editor's draft with real-world use-cases > jensimmons: then we can point at items and identify what needs to be > better > > florian: I support this for those who feel this is a bit early, think > of that early spec as an explainer > florian: I came in really liking it and wondering if it's an uncanny > valley of too much and not enough > florian: Want to see more examples to see if this comes close enough > iank: use-cases written down clearly would be really useful; there > might be multiple avenues we can explore > iank: We've talked about styling columns and gaps, the rotated item > case, that could be a different selector > iank: Multiple avenues we could go down > astearns: Makes sense > jensimmons: I will help make use-cases > jensimmons: I can't help write the spec > rachelandrew: Happy to help with this > astearns: task jensimmons and rachelandrew to work through examples > and syntax > > RESOLVED: jensimmons and rachelandrew to write up use cases, > examples, and syntax for this proposal > > Hit Testing > =========== > scribe: TabAtkins > > Impact of `inert` on hit-testing needs to be specified > ------------------------------------------------------ > github: https://github.com/w3c/csswg-drafts/issues/6685 > > smfr: There has been a history of implementations of `inert` that > haven't matched > smfr: Chrome and Gecko already mismatch, now WebKit is implementing > and want a spec that is clear > smfr: Historically, Chrome's was more in terms of DOM propagation > smfr: If an event hit an inert node it would skip up to an ancestor > smfr: Gecko was in terms of pointer-events; it would ignore the inert > element so clicks could go to underneath it > 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 > smfr: Also questions about whether inert effects APIs like > elementFromPoint() > smfr: And some keyboard interactions > chrishtr: I did not unfortunately get to talk to a11y team in Chrome, > but I did review the discussions again. > 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 > > chrishtr: Also no browsers publicly ship the attribute yet, so all > browsers are still changeable right now > 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 > smfr: So even if the attribute hasn't shipped, there are implications > on those features > chrishtr: I didn't look at the code for dialog/fullscreen, did anyone > else > chrishtr: I assume it ignores hit-test events in the dialog > chrishtr: So I think we can discuss this holistically and probably > dialog impl could be changed in Chromium, unless someone > knows about compat problems > 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 > 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 > > bkardell: Interesting because 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 > 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 > 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 > bkardell: There has been an incredible amount of discussion on this > topic. Before Alice left on sabbatical, she agreed there > were things in Chrome to work on. > bkardell: So I think it's worth talking about top-layer first to set > up the questions about inert, imo > chrishtr: I see now that Tim did put some comments on Chrome's > behavior and quirks > > smfr: One of 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... > smfr: And if the impl is pointer-events based, you are allowed to > make a descendant of a pointer-events:none node > pointer-events:normal > ntim: WebKit recently implemented a pointer-events-based approach, > similar to Firefox > > astearns: So bkardell suggested starting with top layer > bkardell: So let's discuss how it's defined and how it works > 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 > bkardell: If talking about the tree itself and where it lives > normally in the tree, things get a lot more complicated > smfr: I think we're happy with the way top-layer is specified; it > renders z-ordered above the rest of the doc > smfr: I think Chrome/WEbKit do that now > smfr: If there are implications for event propagation, maybe they're > not clear enough > > scribe: fantasai > > <smfr> can someone link to the top layer spec > <ntim> smfr: https://fullscreen.spec.whatwg.org/#rendering > > TabAtkins: IIRC, the way we've described top layer is that it get > re-parented in the layer tree sense > TabAtkins: being a direct child of the top-level document/canvas/thing > TabAtkins: That way nothing can interfere with its positioning > TabAtkins: That's how we specced it, are we doing something different > now? > chrishtr: No, that's what spec and impl do > chrishtr: Re-parent into new stacking context that is z-indexed above > everything else > chrishtr: It's well-specified, afaict > TabAtkins: Shouldn't have any effect on events, that works normally > chrishtr: My guess is chromium, hit testing happens on the layout box > tree > chrishtr: so the impl probably sees the dialog element and then fails > to look up the tree to see the inert attribute above it > chrishtr: If you see an inert node, stop at that node, but don't > check ancestors > chrishtr: I think that's how impl, and not consistent with spec > > chrishtr: Maybe we should discuss directly, should the impl just be > exactly what Firefox and WebKit have already implemented? > chrishtr: Seems the difference is "?? cannot be inert, except when > ... dialog" > emilio: That's a Gecko bug > emilio: Dialog is inert, we use the same mechanism > emilio: should be fixable > emilio: Rest of document is inert so can't do anything > emilio: but that seems like Gecko bug > > emilio: Other question is, does this affect computed value of > pointer-events? > emilio: In Gecko it does > emilio: The alternative was to have an internal property and check > that everywhere you check pointer-events: none > emilio: This way clearer for implementers and more useful to authors > emilio: And less likely to accidentally cause divergence in the future > chrishtr: UA style sheet? > emilio: A bit more magic than that > emilio: It's like an inherited property, which causes a bunch of > other properties to compute differently > emilio: It's conceptually same as UA rule > emilio: In practice, we made an internal property to handle the > inheritance. > emilio: Anything in subtree will have pointer-events: none forever, > unless inert value is changed on descendant > > [discussion of the implementation detail and how it's not visible to > authors] > > <ntim> > https://searchfox.org/mozilla-central/source/layout/style/res/ua.css#171 > <ntim> > https://searchfox.org/mozilla-central/source/layout/style/res/html.css#836 > bkardell: Does that also affect the accessibility bits? > emilio: Yes > chrishtr: What about dialog? > emilio: Sets the internal bit on the document element > emilio: and then dialog has a UA rule that applies this inert > property to the default when modal > chrishtr: So special exception not accessible to developers > emilio: Right > emilio: There's no way, spec-wise, for devs to override that > > emilio: We could add that capability, unsure how it would look > emilio: Spec says anything under inert subtree is inert, and no way > to un-inert a node > flackr: I think it'd get complicated for anything other than > top-layer to override > bkardell: That's why top layer is important here > bkardell: if you are in top layer, can reason about things > > bkardell: Some details that are observable that we need to agree on > and document > 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 > bkardell: There was some hesitance to say the magic *was* > pointer-events > bkardell: because seemed architecturally unfortunate > emilio: Why? > emilio: pointer-events shouldn't really be a CSS property, but we're > way past that point now > emilio: So given that, I'm happy to say that inert is managed via > pointer-events > chrishtr: In the Intent to Ship that didn't complete for this feature > chrishtr: Alice tried it and didn't like it > chrishtr: Didn't like that not targettable from getElementsFromPoint > bkardell: Makes inspector break > emilio: Yeah, but that's an issue with inspector > chrishtr: It doesn't make sense to have pointer-events: none; and > then ... > chrishtr: UA can special-case inspector > bkardell: We have problem with top layer already, can't inspect stuff > underneath > > scribe: TabAtkins > > smfr: We could always add an options dictionary to > getElementsFromPoint > smfr: To let it include pointer-events:none or inert if we wanted to > bkardell: And then devtools would use that by default > chrishtr: and we could do that as a feature enhancement and devtools > can just use magic > chrishtr: Asking tim/simon, is what Emilio said consistent with what > WebKit does? > chrishtr: You do some magic thing that makes descendants of inert > pointer-events:none and the dialog is exempted? > ntim: It's mostly the same yeah, we just don't change the computed > styles for pointer-events > emilio: I slightly prefer actually changing the computed style, for > the reasons I described before, but don't feel super strongly. > emilio: Would just be a little unfortunate and easy to make mistakes > in the future for authors > ntim: Not changing computed styles gives us flexibility to change > inert in the future or not be fully consistent with the > pointer-events:none value, but don't feel strongly either > bkardell: I have a slight pref for Apple's because Firefox's makes > the implementation details observable > 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 > 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 > > chrishtr: So next is whether pointer-events:none is okay > astearns: Do we want to resolve on that first? > chrishtr: Talk about the next first > 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 > chrishtr: I see why Gecko does this - it's easy to reuse behavior - > but do we think it's the right semantic choice? > emilio: No strong opinion, but if there is a better choice it should > be a pointer-events value > ntim: Makes sense to me because you can have non-inerts inside of > inert trees > chrishtr: But that's non web-exposed as a feature, just for this thing > 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? > chrishtr: Right. I think the question of mixed inertness is separate > from whether you hit-test below it. > emilio: Yes, orthogonal > chrishtr: So argument to make is that pointer-events:none is already > there and sky isn't falling, so maybe it's fine > emilio: Yeah, and if we did it another way anyway, we should just add > a new pointer-events value to it > flackr: I think hit-testing behind the thing works well for a lot of > use-cases where you have an event handler on an ancestor > TabAtkins: That works either way though - Chrome's behavior will walk > the... > smfr: But that could mean an element gets the event even if you're > clicking elsewhere, if the clicked child is positioned outside > TabAtkins: Yeah, but it would have gotten the element if the child > weren't inert > smfr: [missed about backdrop] > ntim: You can display:none the ::backdrop > ntim: Question was if we can pierce the top-layer, yes we can > chrishtr: Visually yes, but not hit-testing > ntim: Because everything else is inert, yes > > emilio: Lacking a strong use-case to pursue a new pointer-events > value, I suggest we just stick with none, and maybe change in > the future if we feel it's needed > 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... > flackr: And there are a lot of use-case for *not* hitting an > ancestor, which is pointer-events:none today, so we should > stick with that by default > chrishtr: Agree with emilio and rob that we don't have a strong > reasons to *not* use pointer-events:none, so we should just > use that > chrishtr: So that allows us to resolve > chrishtr: I propose we resolve on the webkit behavior - don't expose > the computed style (for the reason brian mentioned) and use > pointer-events:none behavior > chrishtr: And when inert is set, force pointer-events, focus, etc in > a user-agent way that's not exposed to devs > chrishtr: And elementFromPoint() skips the inert elements > > astearns: I'm a little concerned about having this magic UA > behavior... > 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 > astearns: Usually that means we have a property with the behavior > astearns: I'm concerned that magic means we might not get the details > right > chrishtr: emilio, am I right that the Gecko impl just sets a > UA-internal property? > emilio: Yeah > flackr: And I think it's equivalent to a descendant selector with > pointer-events:none in the UA, and equivalent rule for > modals, etc > emilio: Not quite there because of shadow dom, it's actually > inherited, but close enough > astearns: I don't think we've done a feature as a magic property > TabAtkins: We've never *specified* one as such, but several features > are implemented as such > <fantasai> +1 I'm not concerned about speccing this > <emilio> +1 > 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 > > 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 > > ntim: Question about interaction of inert and modals, what if you > have an inert node as ancestor of modal? > emilio: Depends on details of how we spec, maybe modal dialogs are > just always non-inert > bkardell: The direct descendant of a top-layer should never be inert, > right? > ntim: We could let people explicitly opt out of inert > emilio: I agree this is a different issue > emilio: If we decide that inert works this way, they can still spec > it how they want > emilio: I do think that a modal dialog should never be inert unless > explicitly given inert > > bkardell: Do we need to talk about isInert()? > ntim: That's internal > ntim: What about <dialog modal inert>? > emilio: We should let HTML decide on that > emilio: I think it's edge-casey and we should just deal with the > general problems here > astearns: So punt on explicitly-inert dialog question for now. > astearns: Any other discussion? > > smfr: Where are we writing this? No spec for hit-testing yet > chrishtr: Should it live in HTML? > TabAtkins: We've got other hit-testing things that we need to define > in CSS > <fantasai> https://www.w3.org/TR/css-backgrounds-3/#corner-clipping > chrishtr: But for this it just needs to define that something > "behaves as..." > ntim: And there's already an HTML heading for it > florian: Do we need a spec for this with a "Hit Testing: TBD" > section, and the rest of the spec being a copy of the > relevant part of CSS2? > chrishtr: Yes, I took an action item to find someone for that two > weeks ago. > chrishtr: Would be useful to make an empty spec with a TODO > fantasai: Maybe useful for a subsection in UI-4? > florian: pointer-events:none is not really specified > chrishtr: Oh yeah jeez, we should add a paragraph saying > pointer-events:none means you're not hit-tested > > RESOLVED: 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 > RESOLVED: Add definition of pointer-events:none, at least, to UI 4 > > <ntim> > https://html.spec.whatwg.org/multipage/interaction.html#inert-subtrees > <smfr> we need a place for “top layer” stuff too > <ntim> top layer is very intuitively in fullscreen > <chrishtr> @smfr what was the top layer stuff that needed specifying > that tab just mentioned? > <smfr> chrishtr: see https://fullscreen.spec.whatwg.org/#rendering > <TabAtkins> Yeah they want us to steal that section > <TabAtkins> So we should > > [disussing who should draft spec text] > TabAtkins: Also, should we steal the rendering section of fullscreen > and import into csswg? > smfr: We might already have a resolution for specifying top-level > astearns: So proposed resolution is to put top layer into Positioning > if we don't already have a resolution for it > bkardell: There were some PRs about top layer in HTML itself. > astearns: I imagine we can steal the current spec text as-is and the > inherit any issues from Fullscreen and HTML > astearns: Objections? > > RESOLVED: Steal the top-layer spec from Fullscreen, put it into > Position 3 > > <br> > >
Received on Friday, 12 November 2021 20:55:30 UTC