- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 9 Nov 2021 19:00:05 -0500
- To: www-style@w3.org
=========================================
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 Wednesday, 10 November 2021 00:00:49 UTC