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

Allow toggles to work on elements with existing behavior #39

Open
mirisuzanne opened this issue Sep 6, 2022 · 8 comments
Open

Allow toggles to work on elements with existing behavior #39

mirisuzanne opened this issue Sep 6, 2022 · 8 comments

Comments

@mirisuzanne
Copy link
Collaborator

The current toggle-trigger production says:

If the element already has existing activation behavior from the host language, this value does nothing.

I'm not sure how clearly defined the term 'activation behavior' is, but it seems to imply that toggles can't be applied to button elements.

I believe that's a mistake, and should be clarified. But I'm also curious how strict we need to be here. For example, the proposed popup spec allows popup behavior on any element, including those with existing behavior - but the existing actions (e.g. form submission) take priority. It seems like the toggle spec could take a similar approach?

/cc @dbaron who initially pointed this out.

@bkardell
Copy link

bkardell commented Sep 6, 2022

I think the complete set defined in HTML with activation behavior is a, area, label, input, button, summary

@mirisuzanne
Copy link
Collaborator Author

It makes sense to me that the behavior of a link or form-submission would take precedence over a toggle. But it's not clear to me why otherwise we should restrict toggles from being used on these elements. In particular, I would expect we want people to primarily use toggles on non-submit buttons.

@dbaron
Copy link
Collaborator

dbaron commented Sep 6, 2022

For what it's worth, when I implemented this in Chromium, I reused logic from the <summary> element.

That logic (IsClickableControl) depends on Node::HasActivationBehavior (which is the above list, with html:a conditional on being a link, and svg:a added), but also includes other logic for form controls.

Speaking of that... I wouldn't want a click inside a <textarea> that's inside an element with toggle-trigger to trigger the toggle.

But maybe we should have a distinction between things with activation behavior that are the element with toggle-trigger versus those that are inside it?

@dbaron
Copy link
Collaborator

dbaron commented Sep 6, 2022

(Though maybe activating something inside an element precludes activating the ancestor element by the same action.)

@tabatkins
Copy link
Owner

Yeah my main concern was that links and buttons attached to forms shouldn't be toggleable, since then it's unclear which wins (or both). But a plain button without implicit form behavior should definitely work, and I need to figure out how to tweak the wording accordingly.

Speaking of that... I wouldn't want a click inside a <textarea> that's inside an element with toggle-trigger to trigger the toggle.

Ah, indeed, I'll need to be more precise with the wording about activation targets.

@dbaron
Copy link
Collaborator

dbaron commented Nov 17, 2022

I somewhat relaxed the restriction in the Chromium implementation in https://chromium-review.googlesource.com/c/chromium/src/+/3996338 .

@tabatkins
Copy link
Owner

tabatkins commented Nov 22, 2022

The behavior dbaron is referring to is to essentially copy what <summary> does - if it sees a click that passed thru an element with native activation semantics, like a link or input, it ignores that click. This allows you to click a link in a summary without it opening/closing the details.

This makes a lot of sense, tho it's somewhat tangential to the core issue in this thread. #43 is more germane, so let's move discussion on this point (activatable descendants) over there.

@dbaron
Copy link
Collaborator

dbaron commented Jan 9, 2023

Another related question is whether a descendant with toggle-trigger should count as a descendant with existing activation behavior (that prevents the ancestor from being activated at the same time).

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

No branches or pull requests

4 participants