- From: <bugzilla@jessica.w3.org>
- Date: Mon, 25 Jul 2011 18:45:10 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13345 --- Comment #3 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-07-25 18:45:08 UTC --- (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. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 25 July 2011 18:45:15 UTC