This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html Multipage: http://www.whatwg.org/C#parsing-main-inbody Complete: http://www.whatwg.org/c#parsing-main-inbody Comment: I want to be able to put <details> inside <p>. The use-case is that I'm writing spec text and want to put rationale inline, collapsed in a <details>. I don't want it to be on its own line because then it would take up too much space: after all, that's why I made it collapsible. <details> should be inline by default, not block; if authors want a collapsible section that's within its own block, they can wrap it in a <div> or <p>. Posted from: 68.175.61.233 User agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.803.0 Safari/535.1
Note that this would affect all major browsers (any that have implemented the HTML parser) in a backward-incompatible way. This needs to be fixed ASAP if it's going to be fixed at all. I think it's still feasible, because <details> hasn't started being used significantly yet.
I don't think this makes much sense. It renders as a block-level widget. <details> is completely inappropriate for inline rationale. It's not a footnote element. It's specifically and exclusively intended to be a disclosure triangle widget. If we want a footnote element then we should add a footnote element. <details> is intended to be essentially be parallel to <fieldset>, the difference being that the group can be collapsed if it's a <details> element. (As a side-note, I believe this would be the first time we'd be allowing <p>s to be nested. I think keeping the language consistent in that you can never nest <p>s is a good thing.)
(In reply to comment #2) > I don't think this makes much sense. It renders as a block-level widget. I'm saying it shouldn't, by default. It should be allowed as a child of <p>, it should render inline by default, and its content model should be something like "transparent except it can have a summary at the start". Note that you can already make it inline in Chrome's implementation with details, summary { display: inline }. This is the only implementation so far AFAICT. Authors who wanted it to display block-level could use CSS, as for any presentational issue. Logically, an alternative would be for it to be block by default but let the author make it inline. But then we'd want it to autoclose <p>, and then it can't be used inline in some cases. The only way to allow both behaviors is make it inline by default and let authors opt into block with CSS. > <details> is completely inappropriate for inline rationale. It's not a footnote > element. It's specifically and exclusively intended to be a disclosure triangle > widget. > > If we want a footnote element then we should add a footnote element. What's the difference? What I want is content that's not displayed by default, but which the author can display by clicking on a provided button or link, without having to use JavaScript. Why does block vs. inline deserve two separate elements? > <details> is intended to be essentially be parallel to <fieldset>, the > difference being that the group can be collapsed if it's a <details> element. Why shouldn't it be usable for inline collapsed annotations as well? It's the exact same idea. > (As a side-note, I believe this would be the first time we'd be allowing <p>s > to be nested. I think keeping the language consistent in that you can never > nest <p>s is a good thing.) So don't allow that, change the content model too.
FWIW, in my spec I wound up going with floated buttons that expand to position: absolute divs so they don't disrupt the content when you click. It turned out lots of my comments were multi-paragraph, so making them inline didn't work well. So I could potentially use <details> as it stands (although right now I'm just using divs and JavaScript). So I guess I don't personally care much about this now.
mass-moved component to LC1
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: What you're describing isn't a disclosure triangle widget. It might be similar in concept, but a footnote and a disclosure triangle are not the same thing in practice, and overloading one element to do both is just going to make the element do neither well. If your use case is a valid use case, let's address it directly, not by trying to shoe-horn a similar element into doing double-duty.
Okay, that's probably reasonable.