Open mirisuzanne opened 2 years ago
I think the complete set defined in HTML with activation behavior is a
, area
, label
, input
, button
, summary
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.
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?
(Though maybe activating something inside an element precludes activating the ancestor element by the same action.)
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
Ah, indeed, I'll need to be more precise with the wording about activation targets.
I somewhat relaxed the restriction in the Chromium implementation in https://chromium-review.googlesource.com/c/chromium/src/+/3996338 .
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.
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).
The current toggle-trigger production says:
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.