Disallow interactive content in <summary>

[zcorpan]

https://html.spec.whatwg.org/#the-summary-element:concept-element-content-model

Content model:​
Either:​ phrasing content.
Or:​ one element of heading content.

From #2246 -- the content model for summary should disallow interactive content descendants.

[zcorpan]

Hmm I just realized that wpt-stability-checker in web-platform-tests uses links in summary. Maybe it should be allowed? 😐

@sideshowbarker

[sideshowbarker]

Hmm I just realized that wpt-stability-checker in web-platform-tests uses links in summary. Maybe it should be allowed?

Maybe so, given we know at least one real-world use case for it (which just spontaneously emerged from how we ended up building out the format of the stability-checker comments—as opposed to being some synthetic demo constructed to advocate for the need).

[domenic]

Maybe one path would be to add guidance in the rendering section asking UAs to make it possible to toggle the details even if the summary contains entirely interactive content? That seems to be what everyone does so far.

[zcorpan]

Well... with summary having activation behavior, this results in quite confusing UI when interactive elements are nested, like for other interactive elements, which is why nesting them is generally disallowed.

See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4821

In Chrome/Opera/Firefox/Safari, for several of the things (but not the link), clicking also toggles the details's open state. Focusing and pressing space or enter as well (but not for the link).

I don't know right now what correct behavior should be per spec for these cases. Should compare with elements with activation behavior in label as well...

[domenic]

That's really strange. I wonder why <a> is special. It'd be good to understand that better.

Maybe links should be allowed, but other interactive content should not?

[patrickdark]

@domenic a should definitely be allowed within summary for <a rel="bookmark"/>. If you can absolutely position one piece of interactive content over another, I see no reason why you shouldn't be able to nest such content instead to get the benefits of inline text flow alignment.

(IMO, a elements should also allow interactive content such as and button and select elements—for a language switcher that flows inline with a linkified heading—which implies that summary should allow them as well since it's just a special type of heading, but that seems to be out of the scope of this issue.)

[JAWS-test]

Not only interactive content, but any content within summary that has an implicit role should be prohibited. The element is treated like a button by the accessibility interfaces. However, a button has implicit role=presentation, i.e. with assistive technology any content of a button is output as plain text, any roles (such as links, headlines, etc.) are not perceptible. This also applies analogously to buttons (<button>), in which no interactive elements are currently allowed, but elements with an implicit role.