Connect HTML spec up to new CSS interactivity property
#10956
Conversation
|
I think |
I added a |
Another issue is that no one's been able to come up with UA styles that actually works with shadow DOM. |
domenic
added
topic: style
integration
@scottaohara @aleventhal does this need any change to the HTML AAM spec? This PR (to HTML) doesn't actually change the behavior of existing things like |
|
What is the status of this in the CSS WG? It's relatively straightforward to get things in drafts, but that historically hasn't really conveyed any kind of stability. |
source
Outdated
| @@ -135626,6 +135652,14 @@ dialog:popover-open { | |||
| display:block; | |||
| } | |||
|
|
|||
| :modal { | |||
There was a problem hiding this comment.
Is this correct? When you have multiple modal elements in the top layer, don't all match :modal? You need a magic "topmost modal" thing here, right?
There was a problem hiding this comment.
No, I don't think so. Yes, this sets the interactivity to auto for all dialogs, but see the <dfn>blocked by a modal</dfn> section. In particular, there are some Notes about this behavior there. That section blocks all but the topmost via "html inertness". This CSS rule is here just to allow authors to re-override interactivity back to inert if they so desire.
In terms of the CSSWG's process (which follows W3C practices), it is in an editor's draft. There have been multiple CSSWG consensus resolutions, such as to add it and decide on behaviors like interaction with the top layer. |
But (IMO) we should not consider anything in CSSWG drafts as stable until there is at least a prototype and some tests. Lack of unresolved issues before that happens does not mean much |
Just to put it here, Blink has implemented this property, and written the WPTs: https://wpt.fyi/results/css/css-ui?label=master&label=experimental&aligned&q=interactivity |
|
The CSS Working Group just discussed The full IRC log of that discussion<past> https://github.com//pull/10956<hdv> masonf: quick intro… this is two sets of specs (CSS, HTML) for a new property called `interactivity`, works like `inert` in HTML, there's a spec PR in HTML that connects this up <hdv> masonf: both sides have some control here… HTML has a way to make things inert, CSS does too now, HTML can interconnect the two <hdv> masonf: and make sure overriding works as expected <hdv> masonf: this was editorially reviewed, am looking for implementor support <hdv> masonf: for both parts, HTML and CSS <lwarlow> q+ <emilio> q+ <hdv> annevk: what i'd like input from CSSWG… atm we take something with dep on HTML spec, it's the equivalent to CR spec in W3C land, taking a dependency in your work, if it breaks something you're invalidating implementations <hdv> fantasai: if something is in CR, it's def very stable. If not, it's not clear where it is in terms of stability <hdv> fantasai: we do have CSS snapshots, to show where things are <hdv> fantasai: also have availability to show 'these things are not in CR but stable enough to ship' <hdv> fantasai: kind of the only tool we have to indicate stability beyond CR flag <hdv> fantasai: sometimes a feature was worked on by one team but others haven't seen it yet, that convo prompts people to look at it and they might find design issue or issues that weren't paid attention to <hdv> fantasai: if you want something at the level of super stable, we can have that conversation <hdv> ack luke <hdv> ack lw <hdv> lwarlow: the propery name seems ambiguous <hdv> s/propery/property <hdv> lwarlow: makes me feel iffy re: what it wants to do in the future and if this naming allows it <hdv> lwarlow: maybe interactivity is clearer and I haven't read enough… interactivity doesn't _just_ mean is it inert or not… eg see focusability… there's a desire to have a CSS way to cover focusability, is that part of it or separate? <hdv> ack em <hdv> emilio: one of the comments on the PR was re the model <hdv> emilio: it feels iffy to deal with some things via CSS and with others, have it automatic, like auto <hdv> emilio: makes it a bit harder to reason about <masonf> q+ <hdv> emilio: if you're fine with that, seems fine implementation wise <past> ack masonf <fantasai> s/availability to show/capability in Snapshot to show for individual features,/ <hdv> masonf: pretty strong push from the a11y folks, reason the value is auto is… for somebody to be able to do body { /* set it to auto */ } would break all sorts of accessibility <hdv> emilio: there are other ways to do that… eg you could set important but would be annoying <hdv> emilio: if the spec could make that clearer, eg this is weird but this is why it is weird, would be ok. It's a bit annoying implementation wise, but it's okay <hdv> emilio: no concerns <hdv> masonf: can't really use !important either, you need to be able to re-inert a modal dialog via CSS <hdv> emilio: yes is weird <hdv> emilio: right now, webkit effectively has inheriit bit in the style object, basically an internal property <hdv> emilio: now, with a value on top of that… doesn't inert in HTML have similar concert? <hdv> s/concert/concerns <hdv> masonf: but then it's a developer side thing, modals are a bit more special I guess <hdv> emilio: not sure if I agree but its ok <hdv> masonf: just parroting what I've heard <hdv> panos: so this room's concensus is this is ok to move forward with? <hdv> emilio: I'm okay with that <hdv> olli: if you make something inert and focus is in that area, what happens to the focus? <hdv> emilio: same as if you make it visibility hidden or something else <hdv> annevk: what did you mean with move forward? <hdv> panos: is everyone ok with CSS side of things? <hdv> masonf: comment on weird side of things probably belongs in HTML <hdv> annevk: Luke brought op the name of the property, that seems essential for both specs <hdv> annevk: and we probably need good idea of what stability means on the CSS side <hdv> annevk: at TC39 we know stability/consensus within the group; it'd be trivial to organise the HTML stuff around that, but in CSS it's less clear <past> q? <hdv> fantasai: I think we can make it more clear,doing it more rigorously? <fantasai> s/doing it/just need to use Snapshot/ <hdv> masonf: does TC39 refer out to other specs and if so how? what we're discussing here is interdepencies of specs? <hdv> annevk: how? <hdv> masonf: release process was independent in the past <hdv> annevk: at TC39 usually have dependencies but one way, we know at which point it has a state where TC39 is happy about it <hdv> annevk: we want to avoid building on quicksand in this situation <hdv> past: is it okay for CSS WG to discuss internally and give out a signal that WHATWG can use as a stability indicator? <hdv> astearns: personally I think we should be careful about referencing something in a CSS spec assuming it is stable <hdv> astearns: lack of issues is one thing, usually issues come up when people try implementing something. I don't think this property has prototypes yes <hdv> masonf: it's fully implemented in Chromium and there are WPTs <hdv> astearns: in that case my concern is less, may be stable enough to reference <hdv> fantasai: I think it should be put in a snapshot… changes may happen due to more people looking at it… putting it into a snapshot could be a way to get people to chime in <fantasai> https://www.w3.org/TR/css/#CR-exceptions <hdv> astearns: we also had things ready to ship even if not ready completely yet <hdv> past: any other thoughts or feedback? <hdv> past: this seems like a question for CSSWG to answer <astearns> s/even if not/even if the whole module is not/ <fantasai> s/may happen/happen in response to implementation, but also in response to/ <hdv> past: sounded like you were waiting for implementor feedback, masonf ? <hdv> masonf: yes <hdv> emilio: without my mozilla hat on, sounds good to me <hdv> olli: I need to review the PR |
|
Given what we discussed today this looks good to me, but we should make very clear that the "make modal dialogs not overridable, but inert attribute overridable" is intentional. |
Great, thanks! I've checked the checkbox in the OP based on this comment. I also added a paragraph of more motivation for the "weird" behavior. LMK what you think. |
|
All the boxes here looked checked, but agreement is fresh off the presses and maybe people want to review the new note. We haven't gotten an answer back on whether this affects HTML-AAM / ARIA, but I am pretty sure it doesn't since there's no new HTML attributes or elements involved. I'll plan on merging this mid-next-week, assuming @mfreed7 addresses my nit and rebases on master to resolve conflicts by then. |
|
No, this cannot merge. The CSS side still has open issues and the CSS WG has not indicated this is stable to reference. |
annevk
added
the
do not merge yet
|
We don't have any items in our working mode for "the CSS side has open issues" or blocking on W3C process. I believe we meet all the criteria in https://whatwg.org/working-mode#additions and https://whatwg.org/working-mode#changes . Can you point to which one is not met? |
|
w3c/csswg-drafts#11849 is Luke's issue (for cross-referencing purposes) |
I was a bit unsure about a few parts of this PR, so help would be
appreciated from the editors. The idea is:
1. Remove duplication - allow the CSS spec to define the *concept*
of "inert".
2. Make the `inert` HTML attribute set `interactivity:inert` via
a new UA stylesheet rule.
3. Make modal dialogs non-inert via an `interactivity:auto` UA
stylesheet rule.
{eventual step 4} A rule likely needs to be added for fullscreen
elements also, setting `interactivity:auto`.
Fix reference
Add a bunch of notes, and refactor some things
Address comments
Start on "marked as explicitly inert"
Semi-revert the "marked as explicitly inert" approach, and tweak
Resolve nits
Add more to the Note about why the behavior is the way it is
Address nit
Merge fixup
Final
I'm pretty sure too, but @scottaohara did mention to me yesterday that he'd take a look at this soon. I'm ok waiting for that, just to confirm.
Ok, I addressed the nit, and rebased. The rebase wasn't super clean, given the dialog closedby changes, but I think I got it fixed up correctly. An extra pair of eyes wouldn't hurt. |
I was a bit unsure about a few parts of this PR, so help would be appreciated from the editors. The idea is:
inertHTML attribute setinteractivity:inertvia a new UA stylesheet rule.interactivity:autoUA stylesheet rule.:fullscreen {interactivity: auto}.CSS spec is here: https://drafts.csswg.org/css-ui-4/#inertness
interactivityproperty mdn/mdn#640(See WHATWG Working Mode: Changes for more details.)
/indices.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/rendering.html ( diff )