Allow toggles to work on elements with existing behavior

[mirisuzanne]

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]

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

[mirisuzanne]

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]

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]

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

[tabatkins]

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]

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

[tabatkins]

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]

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).