consider whether we should have implementation or authoring requirements for nested <details name=...>

[dbaron]

What is the issue with the HTML Standard?

One thing I didn't consider when we specified <details name=...> is that it's possible to nest one details element with the same name inside of another. @scottaohara just got some feedback from somebody recently who tried this, and it does lead to surprising results. In particular, if you try to open the inner details element, then the outer one that contains it will close. This is certainly surprising.

I think there are a few things we could do about this:

1. leave things as-is and say it's working as intended
2. add an authoring conformance requirement not to nest details elements with the same name
3. add some sort of implementation behavior exception for this case (i.e., saying that opening a details with a name closes all other details except for any that contain it)... which does require then going back and handling the possibility in other cases that there's more than one open details in a group

I think I probably don't want to do (3) but I think (2) may be reasonable.

[scottaohara]

here's the link to the codepen i shared with David: https://codepen.io/scottohara/pen/abXRJZL

[sideshowbarker]

I think (2) may be reasonable

I agree. I don’t know whether there are any actual use cases for intentionally nesting one details element with a particular name inside another with the same name — but regardless, it seems likely that whenever it might occur in a document, it’s much more likely to be an authoring mistake rather than intentional.

And given that, the HTML checker (validator) could be helpful to developers in such cases — by emitting an error to alert them of the likely mistake.

But in order for the HTML checker to emit an error for it, the spec would need to be updated to explicitly define it as a conformance error — that is, (2).

I think I probably don't want to do (3)

I would object to doing (3) unless someone can describe a compelling use case for ever nesting one details element with a particular name inside another with the same name. Otherwise, I don’t think it merits the additional spec complexity nor especially the additional implementation complexity that would be needed to handle it.

It’s worth mentioning that the current behavior (that if you try to open the inner details element, then the outer one that contains it will close) is actually well-defined — I mean, as opposed to being undefined behavior.

It’s clear that behavior isn’t desirable or useful for anything — but I think it would only be surprising to anybody in practice if they actually had some good reason for nesting the elements that way, and were doing it intentionally (rather than just testing it to see what would happen).