[CSSWG] Minutes Virtual TPAC Meeting 2021-09-29 Part I: CSS Grid, Hit Testing [css-grid]

  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.
  - 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)


Agenda: https://github.com/w3c/csswg-drafts/projects/22

  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
  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
  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
  rachelandrew: If people can do this grid, why can't we do this with
  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
  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
  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

  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
  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
  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
  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

  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
  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
  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
  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
  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
  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
  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
  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

  <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*
  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
  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

  scribe: TabAtkins

  smfr: We could always add an options dictionary to
  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
  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
  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
  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,
  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


Received on Wednesday, 10 November 2021 00:00:49 UTC