Add the interesttarget attribute
#11006
Conversation
|
This is an initial translation of https://open-ui.org/components/interest-invokers.explainer/ to spec language, with a lot of things incomplete. @mfreed7 I think the two biggest points of uncertainty I have now are the integration with mouse/keyboard/touch input on the one end, and with CSS on the other. For showing interest, the timing of these algorithms relative to "mouseover" and other events needs to be defined. For CSS, the fact that there are CSS properties controlling the timing means we need to think about:
There are many more minor TODOs, but I'd like to get the high-level flow settled first. |
foolip
changed the title
interesttarget attribute
source
Outdated
| @@ -74941,6 +74947,13 @@ contradict people? | |||
| data-x="concept-selector-active">being activated</i>.)</p> | |||
| </dd> | |||
|
|
|||
| <dt><dfn selector noexport><code data-x="selector-has-interest">:has-interest</code></dfn></dt> | |||
There was a problem hiding this comment.
Does this belong here in HTML? Or better only in CSS?
There was a problem hiding this comment.
The typical setup is that https://drafts.csswg.org/selectors/ defines that the selectors exist, and then HTML defines when it matches for HTML. The idea is that HTML is a "host language" and there can be others, like SVG.
source
Outdated
| </div></code></pre> | ||
| </div> | ||
|
|
||
| <p>Every <span data-x="HTML elements">HTML element</span> has a <dfn>has interest</dfn>, which is a |
There was a problem hiding this comment.
I know this is the HTML spec, but the plan at least was to minimally support <svg> <a> elements. So perhaps this should be just Element?
There was a problem hiding this comment.
Popovers were only made to work for HTML elements, if I'm reading the spec correctly. Would just interesttarget without fully working popovers be useful, or would it seem broken? (We can fix both, if it would be useful.)
There was a problem hiding this comment.
Yeah, I know. But popovers (the popovertarget attribute) should likely have supported SVG <a> also. But let's not fight that battle now - it's ok by me to keep this as-is, using HTML element. Side note: even if we support interesttarget on non-HTML elements, it's still ok that the target element as a popover is only supported on HTML elements.
source
Outdated
|
|
||
| <ul> | ||
| <li><p>Actually invoke the capture/lose algorithms.</p></li> | ||
| <li><p>Which algorithm reads the computed style for interest-target-delay?</p></li> |
There was a problem hiding this comment.
There need to be algorithms equivalent to these from Chromium code:
I think those three should hit most of the things in this list. Hopefully.
foolip
force-pushed
the
foolip/interesttarget
branch
from
0aac997 to
9e40cb6
Compare
| <ul> | ||
| <li><p><dfn export for="interest state" data-x="interest-state-none">none</dfn></p></li> | ||
|
|
||
| <li><p><dfn export for="interest state" data-x="interest-state-partial">partial</dfn></p></li> |
There was a problem hiding this comment.
@mfreed7 Chromium additionally has a "potential partial interest" state used for popovers:
Do we have to do the same in the spec? Or can we check if the target element is a popover when the scheduled task runs? The popover attribute could be removed before the task runs, so checking it ahead of time seems like it adds the need to double-check it later.
(See WHATWG Working Mode: Changes for more details.)
/browsers.html ( diff )
/form-elements.html ( diff )
/image-maps.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/popover.html ( diff )
/semantics-other.html ( diff )
/text-level-semantics.html ( diff )
/interesttarget.html ( diff )