-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] Invoker Buttons - allowing popover/dialog and more to be invoked without JS #9625
Comments
Nice proposal and explainer! I'm generally supportive of the direction this is going, and I like that you've really expanded the capabilities to include things other than A few small comments related to parts of the proposal:
I think you'd want
Here, I think you likely can add back
I don't think this allows cross-root invokers, except in some cases. Note the complex conditions here.
Thanks for considering what happens with both attributes present. I think it should likely go the other way though - if you have both, respect the new
It should be made clear that this applies to the pair of the invoker element and the target element. For example, a button that opens a popover - to lose interest while using a mouse, you'd have to de-hover both the button and the popover. Overall, awesome proposal! I think it'd be a good idea to chat about this at an OpenUI meeting soon. I don't think I can Agenda+ it with any meaningful label, but would you mind if I get it on the next meeting's agenda? |
Also side note: see w3c/csswg-drafts#9236 for a very related CSS proposal to control the delays associated with gaining and losing "interest". |
would this cover a button that might need to have an associated tooltip, but also opens a popover, popover dialog, or modal dialog? |
How could the platform support having other elements (e.g. Custom Elements) to be invokers as well? |
I'd like us to consider that
I have no idea how
Thanks, added.
Yes that's a much better idea! Added.
Great point! Added
Please, this would be great to discuss further.
Yes I believe so: <button interesttarget="my-tooltip" invokertarget="my-dialog">Tooltip on hover/focus, click to open dialog</button>
It's a good question, and one that seems to largely revolve around this big open question of "how can a custom element be a button". We could add something to This is all to say I don't have a good answer for this, and it might need addressing at a larger scope than this proposal. |
@keithamus so that helps clarify a bit, but i'm still not sure what type of dialog is going to be invoked from that. a non-modal, a non-modal popover (in the top layer) or a modal dialog. I've looked at the InvokeEvent table from the explainer, and i'm seeing an expectation that something is a popover, or a modal dialog, but not a non-modal dialog (popover or not). is the intent for interest largely for tooltips? or is there the possibility that other types of content could be shown/hidden if associated in that way? not for or against whatever answer is given, just want to understand the potential UX ramifications of a dialog or large block of content showing up on someone simply trying to tab through an interface. Understanding this would also result in any accessibility properties that would need to be exposed for the Two other bits:
|
I've ignored the concept of non-modal-non-popover dialogs, and so an
Largely for tooltips. I can't think of a compelling use case that would not be disruptive to folks for anything else, but I'm hoping if there are some, someone will come forward with them.
I think so! It seems like spiritually these issues align. I want this proposal to effectively capture/replicate/explain any built-in interactive element, including
Absolutely please do! It's safe to assume that the whys behind my choices come from a place of ignorance and doing what I think is right without any hard research. |
thanks for all that, @keithamus your response about the non-modal dialog makes sense now with that context - as it didn't initially click to me before that
that was my read as well, which is great. I'll definitely come back and kick the tires on this some more, especially re: the next bit about updating some of the accessibility bits. Which truly thanks for even considering that stuff. It's mostly nits / suggestions to either match reality, or use this as an opportunity to force support / update the spec for a certain attribute. i'll put this on my todo to do another review / make a PR. Thanks! |
One such use case is a nested menu. (Try Google Docs for this exact behavior.) Click to open a menu (e.g. File), then hover over one of the items with a sub-menu. The sub-menu shows up after a slight delay. Note that their keyboard behavior is different - focusing on the item does nothing, and you have to hit the right-arrow to open the sub-menu. |
I suppose if we go with |
thanks @mfreed7 - yes that's a good example, and a good reason why |
So as mentioned above, we discussed this today at OpenUI, and the general tone was that this new proposal is generally a good direction to try to go. It has the flexibility needed to support many different element types, and it's expressive enough to work for many common use cases. One point was made that the What do folks think about this direction? @annevk @ntim @emilio |
General idea seems like the right way to go, though there's probably some bikeshedding to be done around naming and smaller details. |
Great! Do you think it's close enough that someone (@keithamus ??) should start drafting a spec PR? We're happy to prototype for Chromium. I do think we should just tackle My points of bikeshedding:
|
Happy to work on specs and implementations. I think your bike shedding points make sense and I agree with them; I was just being conservative in the explainer 😜 |
I'm not sure if these have already been discussed or not, but these feature requests for |
To be clear, Luke mentioned this but it got glossed over, Happy to inquire what colleagues think about |
If invoke is too technical trigger is a possibile alternative not as technical but basically means the same thing. Command could also work but I guess it's also technical (like command prompt?). If we could avoid clickactiontarget that would be nice. I'm sure we can run more polls on developer sentiment of names. Though it's obviously hard to make them unbiased and provide the necessary context. |
I'm hoping whatever we end up having here, would be like the click as it should have been, something independent of user input modality. We tried with DOMActivate years ago and failed, but now that we're tweaking the same area in the platform we might be able to get it right :) |
Interesting, my memory of that event was that Anyway, as mentioned above it would be of great help to have a more flushed out proposal around |
Okay I'll try; The attributes could become In terms of symmetry with interest, I think we can either have |
For |
In the WHATNOT meeting just now, we discussed this proposal, and in particular the names of the attributes. We did agree that the current approach of using two attributes, one to specify the target element and the other to (optionally) specify the action to be taken on the target, was a good one. We now need to brainstorm and select appropriate names for those two attributes. Here are the options I've heard; please comment with things I missed or suggestions for improvement.
{In all cases, A few points:
Ok, let me know your other suggestions for naming and I'll include them above. |
This is an interesting idea. It has somewhat limited use cases I think, perhaps this (dialog close) is the only one? It would also make understanding the behavior a bit tougher: in most cases, an |
Dialog and popover could have that "magic". And any future actions that apply to elements with children could have it too? I have opened openui/open-ui#1057 to discuss that. |
Sure, popovers could do the same thing, I just don't think that's a common use case for a popover. Explicitly avoiding "close" buttons and having popovers light dismiss is exactly why people like them. But sure. Thanks for opening the openui issue. |
This comment was marked as duplicate.
This comment was marked as duplicate.
As I mentioned during the meeting, I think we should figure out a way to get to a place where the attribute you always need to supply is the short one. When you encounter a set of identically-prefixed attributes it would be rather unnatural for the shorter one to be the optional one. For instance, |
We obviously need to think more on this. But I feel very strongly that the action suffix should be used for the action enum and not for the IDREF. clickaction="someDialog" is going to end up being very confusing, especially when compared to popover attributes. command="IDREF" is similarly odd on the surface (at least to me thinking of command as a noun by default), BUT command is at least also a verb so it could be thought of as here's the element you're commanding, (and then commandaction for the longer one seems okay?). Having said that the fact command can be both a noun (where you think it's gonna take the action) and a verb (where it's going to take the target) might make it trickier to teach and learn as a developer. |
The compat problem with |
Maybe reusing target instead of |
(Pros: already exists, cons: it has a different meaning, but not too different, for links) |
@emilio I thought people wanted a different target for this and "interest". Ideally they have a consistent API. @lukewarlow yeah, inverting it is tricky. I also thought of something along the lines of |
Symmetry could be achieved with |
All things equal, I agree that a shorter name is better. But I think here all things aren't equal, since this feature is somewhat nuanced and semi-novel, so clarity should trump brevity. I am biased, but I think These are all just my opinions. I'm happy if we can reach agreement on any reasonable set of names.
Let me know if you think these need to be added to the list above - happy to do so. |
I've updated my comment to include these two. Any further suggestions for other names from anyone? |
I agree with @mfreed7 that |
Just gonna echo @nt1m's concern here re: non-English speakers. That was my gut reaction regarding But that being said, I too have concern with basing the name around Anyways, in the hope of supporting the non-English speaking community claim, I ran polls on Mastodon and Twitter as well using Traditional Chinese (of which most if not all responders are Taiwanese). I know it's very much not big enough of a sample size but so is the nature of non-English speaking community feedback in general. I'd suspect a poll done in Japanese / Korean would yield similar results.
Lastly, I think I personally think Sorry to be chiming in so late and excuse me if I have missed some context and of why the above isn't valid. I haven't been following these discussions as close as I would like. |
Firstly a big thanks for running that poll, it's useful to have those sorts of data points when coming up with these decisions. As for the latter part, yes in its current form it's mostly toggling expanded states (though there are actions for explicitly closing or opening). But there's future aspirations for actions that aren't related to toggling the element's expanded state. Media controls for example. So toggle probably doesn't always work. Toggle is also a very overloaded term like you say. While I won't speak for Scott my understanding is that the aria-expanded state is instead of the aria-pressed state, so pressed wouldn't be appropriate here. |
Thanks for accommodating my belated contributions!
It sounds to me that this proposal especially with its initial problem statement and examples, should be primarily focusing on toggling (popover/dialog) as opposed to invoking, no? IMO it should be make clear if this goes through there is space left for a toggling attribute to be proposed; and if it does, why wouldn't
That makes sense. Thanks. Seeing the defaults it seems to me that |
thanks for covering the question, @lukewarlow. yes, we only use an expanded state for popovers/dialogs (truly, we don't 'need' the expanded state for modal dialogs - but that's off topic for now) Re: play/pause, @muan. I've mentioned this a few times in related issues for 'toggling' - but if the name of the control changes (play/pause) then it is not desired for there to also be a state change that would too be announced to users. aria-pressed state changes should occur if the name of the control remains unchanged. Like a bold button being in a pressed / not pressed state. But a button that toggles between a name change of "play" and "pause" should instead be firing a name change event |
I noticed. And I believe the proposal here does not include changing the name when the function is called, so it seems to me |
Following on from #3567 and #9456 where we tried to specify a way to open dialogs without JavaScript, @nt1m and @smaug---- raised concerns that the attribute was not extensible.
I've taken the feedback, and instead I'm proposing a new set of attributes that allow for opening dialogs and popovers, and also allow for extensibility for other interactions. I'll quote the summary:
I'm soliciting feedback on this, and if we think this is more tenable than #9456 I'm happy to go forward with specs/implementations.
The text was updated successfully, but these errors were encountered: