Open mfreed7 opened 1 year ago
See also these related discussions:
popover-delay
, perhaps invoker-delay
?Can this work at the level of matching selectors by inventing functional forms for them like :focus(visible, 30ms)
and adding arguments to forgiving selectors like :where(0 0 0, .3s / :not(:active))
?
Can this work at the level of matching selectors by inventing functional forms for them like
:focus(visible, 30ms), :hover(3s)
or adding arguments to forgiving selectors like:where(0 0 0, 300ms / :target, :active)
?
I'd be worried about that approach, because then you'd need a CSS way to actually trigger the popover/behavior. I.e. you'd need :focus(visible,30ms) { trigger-popover-now: yes; }
. So far (and as far as I can see it going), that really belongs in the HTML part of this feature, right? Also, I think the feature I've described doesn't have an equivalent pseudo state already. :focus
gets the keyboard part, :hover
gets the mouse hover part, nothing gets the long-press part, and (most importantly) nothing enforces that you need to use them all together or someone will be broken.
If authors want to control popovers regardless of the state provided by :popover-open and default styles, they can already do that, that is not a problem.
then you'd need a CSS way to actually trigger the popover
the display property defines an element’s display type
so far (and as far as I can see it going), that really belongs in the HTML part of this feature, right?
user agents are not required to present HTML documents in any particular way
the feature I've described doesn't have an equivalent pseudo state already
custom selector which is written as a pseudo-class with the given \
nothing gets the long-press part
:active pseudo-class applies while any generated box of any element (or pseudo-element) is being actively indicated by a pointing device (in the “down” state), e.g. between the time the user presses the primary mouse button and releases it, or while a finger is pressing on a touchscreen
Yeah, this isn't really doable via Selectors, it's triggering a different behavior that's not CSS controlled. CSS doesn't make something a popover, that's a quality of it imposed by the DOM APIs (or the UA itself in some cases). So that's not a viable approach.
Back to the OP, this seems reasonable.
I agree that it would make the most UX sense to set both the show and hide delays on the same element. I could see it being set on either the button or the popover, tho - as you say, both the popover and the invoker button need to be dehovered before the hide timer starts. Since you're setting the "interest" popover method on the button, and these are both effectively just applying some config to the "interest" method, I think it probably makes the most sense to put them both on the button, then?
One note is that we don't use CSS to configure/control non-CSS concepts much (at all?). Is it needed here, or should it be communicated in the DOM attribute? Why are the delays in CSS, but the indication that you want to use "interest" method is in the DOM? I presume the reason to put the delays into CSS is because they're unlikely to be different per-invoker, so you can reduce a lot of repetitive attribute values by making it a property, but would that similarly apply to the popover method?
(I think CSS should be used for non-CSS concepts a lot more, it's a rich and powerful language both in values and targeting, and authors are intimately familiar with it. I'm just wondering what the reasoning behind this particular slicing of responsibility is.)
Also #6719 can be useful in this case, with ::popup
it will be possible to bind more properties to the popover associated with a particular button, including the suggested.
By the way, the name of the issue is a little confusing, it seems to describe the need for a general mechanism for this, the description only mentions the use case for opening or closing popovers.
I agree that it would make the most UX sense to set both the show and hide delays on the same element. I could see it being set on either the button or the popover, tho - as you say, both the popover and the invoker button need to be dehovered before the hide timer starts. Since you're setting the "interest" popover method on the button, and these are both effectively just applying some config to the "interest" method, I think it probably makes the most sense to put them both on the button, then?
Interesting idea to put it on the button. I was initially thinking it made more sense to put them on the popover, since that's the thing that is showing and hiding. But I like the idea of adding both to the button; that also makes it possible to use the same popover invoked via different buttons that each have different delays. I'm not sure what the use case is, but it just feels more flexible which is good.
One note is that we don't use CSS to configure/control non-CSS concepts much (at all?). Is it needed here, or should it be communicated in the DOM attribute? Why are the delays in CSS, but the indication that you want to use "interest" method is in the DOM? I presume the reason to put the delays into CSS is because they're unlikely to be different per-invoker, so you can reduce a lot of repetitive attribute values by making it a property, but would that similarly apply to the popover method?
(I think CSS should be used for non-CSS concepts a lot more, it's a rich and powerful language both in values and targeting, and authors are intimately familiar with it. I'm just wondering what the reasoning behind this particular slicing of responsibility is.)
The reason I proposed using CSS for this is exactly what you said: it's just easier to do it there. I would bet that the overwelmingly-common thing is for all popover invokers on a page to use the same standard delays. So it's easier to do button[interesttarget] {interest-delay: 0.5s 0.5s;}
once and not have to worry about adding attributes to all the buttons. The interesttarget
attribute is in the DOM because (I think) it's somewhat semantic - it tells you these two elements are linked together via this connection. Also the a11y associations typically happen as a result of the DOM content and not as a result of anything from CSS.
I would bet that the overwelmingly-common thing is for all popover invokers on a page to use the same standard delays. So it's easier to do
button[interesttarget] {interest-delay: 0.5s 0.5s;}
once and not have to worry about adding attributes to all the buttons.
Another solution would be to make the proposed properties inheritable so that authors can set them directly to the root.
Hello, I'd like to ping this issue as the result of a good discussion we just had in OpenUI related to the delays discussed on this issue:
https://github.com/openui/open-ui/issues/963#issuecomment-1856462744
There are a number of things discussed there, including the concept of a safe-area triangle. But related to this issue, a few interesting things were discussed. First, it does seem that folks like the idea of allowing CSS to control these delays, independently for the "show" and "hide" actions. In addition, we had a good discussion about specifying the delays themselves. As background, there are several issues with these delays:
Given the above constraints, the new idea is to specify the delays not as actual time values, but as "slow" or "fast", etc. So:
button[interesttarget] {
interest-delay: [none|slow|normal|fast] [none|slow|normal|fast];
/* interest-delay: interest-delay loseinterest-delay */
}
It would then be up to the UA to determine how to resolve "slow" into an actual delay value in seconds. The UA could also offer a user preference like "Minimal delays please" which would then reduce the delay value for all settings, or "I want more time" to increase them.
Thoughts? Suggestions?
Since we don't have a good handle on a cross-platform solution to "rich tooltips" WebKit doesn't think this is ready to move forward. See https://github.com/WebKit/standards-positions/issues/305#issuecomment-2231000262 for additional context.
Since we don't have a good handle on a cross-platform solution to "rich tooltips" WebKit doesn't think this is ready to move forward. See WebKit/standards-positions#305 (comment) for additional context.
Thanks. See also my response. This issue is about solving one small piece of the tooltip puzzle. You've raised other issues, such as touchscreen, on the WebKit standards position. I hope you can help us with solutions to the issues you've raised! But since this issue is unrelated, perhaps we can still discuss it?
One thing that came up in this discussion on X (then still Twitter) was that a delay itself doesn’t always cut it.
Sometimes, you want the delay to only start counting from the moment the user has actively stopped over on the element instead of just a fly-by hover which just happens to be slow enough for the delay to expire.
/cc @simevidas
The CSS Working Group just discussed Add hover/focus/long-press triggering delays to CSS
.
Thanks for the great discussion and ideas. I heard these general viewpoints (none were unanimous):
0.5s
) rather than long
/short
named values. It's still possible for UAs to override this for users, e.g. via a "make delays 10x longer" setting.:interest-target-showing
or something?Further ideas and discussion is welcome!
Comments promised in the call:
@flackr: I wanted to make an argument against complete customisation. […] The argument for this is that the UA could provide a consistent experience across sites and the OS.
I think the web platform is rich enough to have vastly different types of apps and sites in it, where it might not be possible to normalize them to a specific set of values. Some apps might want to have snappier values, others — more relaxed. A work tool like a monitoring app will likely need a different set of values compared to something like a casual blog or a promo page. short
and long
could mean different things in the context of the corresponding design systems, and a pre-defined list of UA-only values couldn't cover all the use cases (but might be useful as the default consistent list).
@mfreed7: It's still possible for UAs to override this for users, e.g. via a "make delays 10x longer" setting.
@dholbert: I worry a little that with specifying exact time, developers would coordinate animations with delays which would look cool but would break with UA adjustments.
I like an idea of a global 10x longer setting. For cases where we'd need to synchronize things, we could introduce something similar to forced-color-adjust
property, but for these delays/transitions.
My argument for not customizing this is that it empowers the UA to provide all of these good behaviors to all popover hints rather than requiring each developer to think about them, e.g.:
I also feel like the use cases for instant reveal are fundamentally different than a "short" delay, and may be best represented by either a different named concept, e.g. hover.
Some apps might want to have snappier values, others — more relaxed.
I worry that this sort of customization may not actually be providing a better user experience.
There were some questions during the call about touch - I think that just like click, contextmenu, :hover, and other "mouse-centric" properties where we already have a way to trigger with touch, we would do the same for this capability. My proposal which aligns with android behavior would be to show it after a short delay of pressing down - long enough to not be considered a click.
Re: customizing delays vs not -- why not both? Provide at least an auto
value that leaves it up to the UA to align to preferences, perhaps also short
/ long
/ etc. for variances where the author wants some variance but doesn't care about specific values, and also accept <time>
for authors who have specific values in their design language - with the provision that UAs can still override those specific values using a forced colors like mechanism.
Clear allowance to align with user / OS preferences,
A predefined list of keywords would be enough for most cases, while a custom duration will be an escape hatch for those cases where things are important for the authors. “Simple thing easy, complex — possible”.
Can be based on a time after stopping movement
I don't think this contradicts a user-defined value. This could be a default behavior, with a potential additional option to opt-out of it (but I don't think it is necessary).
Can eliminate or significantly reduce the delay for opening the n'th hint after a first one is open
The problem: there are cases where we'd like to have independent groups of tooltips. Two toolbars on two different sections would want to “share” one delay across items inside them, but not across sections.
I worry that this sort of customization may not actually be providing a better user experience.
Relying solely on the OS/UA behavior will mean there will be no room for innovation, and as soon as someone will want to do something unusual and modify the experience a bit, they will have to opt out of the default behavior completely, rather than use an escape hatch. Which will lead to a much worse experience and potential footguns while trying to re-implement it with other means.
Relying solely on the OS/UA behavior will mean there will be no room for innovation, and as soon as someone will want to do something unusual and modify the experience a bit, they will have to opt out of the default behavior completely, rather than use an escape hatch. Which will lead to a much worse experience and potential footguns while trying to re-implement it with other means.
So to be clear, I'm not saying that we shouldn't also allow some customizations, but I am concerned that if we try to design a bunch of strictly specified individual features we may make it harder for the UA to innovate while still honoring the developer specified values. My proposal is more that we determine what properties a common solution can have, and then add customizations as needed to meet the use cases (with clear examples) that are fundamentally different.
I built a demo to show what's possible based on an immediate state change (e.g. :hover
) using transitions on a custom property with style queries on that property:
https://codepen.io/flackr/pen/gONXNdV
Please see the Popover Hint and Hover explainer for more context:
https://open-ui.org/components/popover-hint.research.explainer/
We're working on an addition to the Popover feature that allows authors to easily and declaratively get hover-triggering of popovers. (And to make sure all input modalities are covered, "hover" includes keyboard focus and also touch screen long-press.) The idea for now is to use the
popovertargetaction
attribute, with a new value calledinterest
(see this discussion for context on the name) that enables this new mode of triggering. Whenpopovertargetaction=interest
on a button that points (viapopovertarget=foo
) to a popover, that popover will be triggered when one of these things happens:The key phrase above, and the point of this issue, is that the delay should be developer-configurable. Leaving this delay up to the UA leads to issues and missed use cases. For example, the built-in tooltip that shows up as a result of the
title
attribute has one major, common complaint: the UA-imposed delay is too long. Other, more creative use cases of this feature would also require a customizable hover-delay. For that reason, I'd like to propose that this delay is set in CSS, via a new property:There is another quite related, yet separate, set of behaviors that happens after the popover is shown. Typical "tooltip" use cases would also like the tooltip to be hidden after the tooltip stops being hovered for a period of time. To make this work, both the invoker (the button above) and the popover should be able to be hovered to maintain the popover in the open state. But once both of them have been de-hovered for a period of time, the popover can be closed. For this, I propose:
Note that in the above proposal, the "show" delay is applied to the button that triggers the popover, while the "hide" delay is applied to the popover. That's because those elements are where the action takes place. However, one could make the case that it'd be nice to instead put both properties on one element, and the
[popover]
would seem to be the natural place to put it. In that case, the above properties could also be combined into a single two-valued property (credit @una for the idea):Thoughts?