Skip to content
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

Open
wants to merge 64 commits into
base: main
Choose a base branch
from

Conversation

keithamus
Copy link
Contributor

@keithamus keithamus commented Oct 8, 2023

This adds the commandfor & command attributes and a "command" event using the CommandEvent 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 )
/webappapis.html ( diff )

@keithamus keithamus changed the title Add invoke Add InvokeElement & InvokeEvent IDLs for Invoke proposal Oct 9, 2023
@keithamus keithamus changed the title Add InvokeElement & InvokeEvent IDLs for Invoke proposal Add InvokeElement & InvokeEvent IDLs & invocation steps for Invoke proposal Oct 9, 2023
@keithamus keithamus marked this pull request as ready for review October 10, 2023 22:28
@keithamus keithamus force-pushed the add-invoke branch 3 times, most recently from 45e4032 to 9579336 Compare October 17, 2023 20:32
@scottaohara
Copy link
Collaborator

scottaohara commented Oct 18, 2023

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 <button popovertarget=foo disabled> testing in chrome, results in that element not exposing whether the popover is in the expanded or collapsed state - as I'm assuming due to

"If node is disabled, then return null."

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

@keithamus

This comment was marked as outdated.

@lukewarlow
Copy link
Member

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?

@domenic
Copy link
Member

domenic commented Nov 5, 2023

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.

@keithamus
Copy link
Contributor Author

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.

@domenic
Copy link
Member

domenic commented Nov 5, 2023

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.

@lukewarlow
Copy link
Member

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.

@lukewarlow
Copy link
Member

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.

@mfreed7
Copy link
Contributor

mfreed7 commented Jan 17, 2024

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.

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.

@keithamus
Copy link
Contributor Author

I'd be happy to get reviews, I think this is in a good position for that.

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
@mfreed7
Copy link
Contributor

mfreed7 commented Jan 17, 2024

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.

source Outdated
Comment on lines 53538 to 53539
<td><dfn attr-value for="html-global/command"
data-x="attr-button-command-custom"><code>(valid custom command)</code></dfn>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would make this:

A valid custom command

with "valid custom command" cross-referenced, but not code. However, I'm also thinking that we should rename it to "custom command keyword". There's no invalid custom commands after all.

Though also, now that we have a state, do we even need a separate definition of "custom command keyword" or can we just state here

A string whose first two code points are U+0002D (-)

? That would simplify this even more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The notes column is non-normative though right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the question in light of the suggestion. This is about the keyword column.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I thought you meant to add the statement to the notes section.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In light of the current changes, where the keyword says A <span data-x="attr-button-command-custom">custom command keyword</span>, do you think it makes more sense to add the definition to the keywords table or to keep it as is?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have to update the other references to "attr-button-command-custom". Given that there is a reference in the Indices section I'm inclined to say we have to keep this as-is. It could potentially be inlined like:

A custom command keyword, which is any string whose first two code points are U+002D (-)

but I'm not sure if that's an improvement. Might be something Domenic has an opinion about, but otherwise I'd leave it as-is (modulo updating the references to it; I noticed some casing issues and weird parenthesis).

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated
Comment on lines 53867 to 53868
<p>The following code shows how buttons can use commandfor to show and hide a popover box when
activated:</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to cross-reference these terms and use code appropriately. Across all examples. I've left this comment many times now. :-(

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry maybe I’m failing to understand what you mean by “use code”?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@annevk I've added the references, using <code> elements. Is this what you meant? I'll leave you to click Resolve conversation if you're happy with it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also expect "button" to be referenced and maybe "popover", but I guess it's okay like this...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I've linked both buttons and popovers here.

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. This is getting close now. I'd really appreciate it if someone else could do one detailed read through as after this many takes I'm probably missing things. Maybe @domenic or @domfarolino?

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
Copy link
Member

@domfarolino domfarolino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took a brief scan before going OOO for Thanksgiving, and mostly only came up with editorial things.

source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Outdated
</ol>
</li>

<li><p>Otherwise, run the <span>popover target attribute activation behavior</span> given
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we could elevate this to handle this case first, and early return. That way all of the entire invoker-is-null steps could be dedented by one, and we can remove a whole level of nesting in this algorithm. That seems just a bit more readable (just a suggestion though).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was an intentional editorial choice and an intentional choice in the code to keep these steps last to emphasise their order of precedence. Happy to change though.

source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Outdated Show resolved Hide resolved
<li><p>If <var>continue</var> is false, then return.</p></li>

<li><p>If <var>command</var> is in the <span
data-x="attr-button-command-custom-state">Custom</span> state, then return.</p></li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it matters much, but what if the result of firing the event changed the button's command state to "Custom"? In that case, this algorithm would not early-return here because we're looking at a snapshot of <var>command</var>. I assume that's fine, and maybe even desirable, but I just want to make sure that's what we expect and ask if this definitely matches what implementations would do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I believe it was deemed quite early on that scripting shouldn't change the type of gesture halfway through. I think there could be some interesting use cases for it (such as just-in-time determining if you want something as show-modal vs show-popover), but I am not convinced they're practically worthwhile in the face of potential problematic use cases.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, command is the attribute, so it's not a snapshot. If you want a snapshot you need to do something else.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I'd need attribute value? And presumably also attribute state or similar, so that we can capture and continue to test the state?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regardless, it sounds like you don't want to compute the state on the fly like that (i.e., by grabbing its "state" (unliked)). It sounds like you want to do this early, by pulling it out sometime before we run script, so that we have the snapshot you were expecting. Right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the prose above I'm assuming that command holds the attribute value in which case it's grabbed early. It's only the attribute that's live (and which most of the existing infrastructure assumes is used).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah. I read #9841 (comment) as you saying the current prose grabs the live version of the attribute state/value, not a snapshot.

Copy link
Member

@annevk annevk Nov 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current prose grabs the attribute, which is live by definition. If you grab the value instead you'll have to change how you inspect state, which is what the above wording is for.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I've pushed up something I think works.

@keithamus
Copy link
Contributor Author

Thanks for the review @domfarolino - I wonder if you'd be interested in another sweep given the changes to the if statements?

source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.