-
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
Add commandfor & command attributes to HTMLButtonElement #9841
base: main
Are you sure you want to change the base?
Conversation
45e4032
to
9579336
Compare
I realize this is also in the steps for getting the popover target element, but in both cases I'm wondering why its specified to return null if the node is in the disable state? Doing so, at least with
that state gets removed. That's unexpected, to have that state removed based on whether the button is disabled or not. And for invokertarget - if it is really is going to do more than just show/hide content - there are a lot of other states that should still be exposed, regarless of if the element is in the disabled state or not. edit: I can file a bug for disabled / popovertarget if necessary - i just wanted to get insight on this first, before I went and made that issue. cc @mfreed7 |
This comment was marked as outdated.
This comment was marked as outdated.
7f0f9ea
to
834a8b1
Compare
See related spec PR whatwg/html#9841
Fwiw HTML requires a positive standards position or for chrome LGTMs on an intent to ship to be considered supportive. Saying that Mozilla have marked their position as positive so that's 1 implementor interested. I do wonder how this requirement works for a feature such as this which will require multiple PRs to add to the spec? |
I'm confused why this feature is being done as multiple PRs; it makes review a good deal harder. |
If it makes it easier to review I’m happy to put more into one PR. I figured it would be worthwhile splitting it into the core vs each elements behaviour as I imagine there will be more to discuss with each elements behaviour. |
Well, it'd make it easier for me, but I haven't signed up to review yet, so no need to make any changes until we get some more opinions :) Edited to add: the reason it makes it more difficult is that I don't think we want to accept the feature piecemeal. |
As per openui/open-ui#900 (comment) this'll need updating to only fire the event when the action is custom (has a hypen) or is recognised and valid (correct action name on correct element). TLDR is that this will allow us to add default actions in future without conflicting with user land code. |
In openui/open-ui#952 (comment) we resolved that "Invokers v1 will be popover and dialog invoking." This should help keep this initial PR as small as possible while also avoid the issue of reviewing stuff piecemeal. So #9875 can be merged into this along with dialog related changes. |
Chromium is explicitly supportive of this proposal, so I believe it has two implementer support (including Mozilla). Is this PR in a state that it can get a review? I'm happy to do so, if it'd help. |
I'd be happy to get reviews, I think this is in a good position for that. |
Done - I added a first set of comments. |
I just added a few additional changes based on recent decisions. As far as know this is now up to date. |
Great! Thanks. So I believe we've got all of the checkboxes checked, right? Can we land this now? |
I believe there are more changes to this spec based on this comment: #9625 (comment). I'll make those now. |
Okay I think that is everything. @annevk this removes the input attributes and inlines the mixin per #9625 (comment) |
Oops, I do remember seeing that comment, but missed it because it was on the issue. Thanks for making the rest of the changes. Hopefully that's all that's needed in order to land this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks reasonable, but it needs quite a bit of editorial polish still. Note that I didn't highlight every error as quite a few are repeated throughout. Hopefully these comments give you enough to pattern match across all the changed text.
source
Outdated
<p>The <dfn attribute for="CommandEvent"><code data-x="dom-CommandEvent-source">source</code></dfn> | ||
getter steps are to return the result of <span data-x="dom-retarget">retargeting</span> <code | ||
data-x="dom-CommandEvent-source">source</code> against <var>this</var>'s <code | ||
data-x="dom-Event-currentTarget">currentTarget</code>.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how this ends up working with the event machinery we have in place.
are examples (similar or complementing/expanding what was added for popover) going to be added to this PR / a following PR? Or will examples be reserved for MDN? |
Good call. We should add at least one example to the |
@annevk I've reorganised based on your feedback, as well as renamed various things, and also added multiple examples. Hopefully this is clearer now! Let me know if you think there is any more editorial polish needed and I'll be sure to make it so. |
This adds the
commandfor
&command
attributes and a "command" event using theCommandEvent
interface.Button activation checks if the button has a "commandfor" target and if so performs invoker command behaviour depending on
command
and the target element.(See WHATWG Working Mode: Changes for more details.)
/dom.html ( diff )
/form-elements.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/popover.html ( diff )
/webappapis.html ( diff )