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

Disallow interactive content in <summary> #2272

Open
zcorpan opened this issue Jan 19, 2017 · 6 comments

Comments

@zcorpan
Copy link
Member

commented Jan 19, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Jan 19, 2017

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

@sideshowbarker

@sideshowbarker

This comment has been minimized.

Copy link
Member

commented Jan 19, 2017

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

This comment has been minimized.

Copy link
Member

commented Jan 19, 2017

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.

domenic added a commit that referenced this issue Jan 19, 2017

Add activation behavior for <summary>
Fixes #2246. This also fixes the value that the open attribute is set to
to be the empty string, instead of "open", matching existing
implementations.

Tests at web-platform-tests/wpt#4539 show that
both implementers of <details> follow these same semantics, despite
there having been no spec previously. The only exception is that Blink
included a being-rendered check, but that was removed; see
https://bugs.chromium.org/p/chromium/issues/detail?id=681711.

There's still some discussion ongoing as to whether we should change the
content models to disallow interactive descendants of <summary>
elements, happening in #2272.
@zcorpan

This comment has been minimized.

Copy link
Member Author

commented Jan 19, 2017

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

This comment has been minimized.

Copy link
Member

commented Jan 27, 2017

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

This comment has been minimized.

Copy link

commented Mar 19, 2017

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

alice added a commit to alice/html that referenced this issue Jan 8, 2019

Add activation behavior for <summary>
Fixes whatwg#2246. This also fixes the value that the open attribute is set to
to be the empty string, instead of "open", matching existing
implementations.

Tests at web-platform-tests/wpt#4539 show that
both implementers of <details> follow these same semantics, despite
there having been no spec previously. The only exception is that Blink
included a being-rendered check, but that was removed; see
https://bugs.chromium.org/p/chromium/issues/detail?id=681711.

There's still some discussion ongoing as to whether we should change the
content models to disallow interactive descendants of <summary>
elements, happening in whatwg#2272.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.