W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2011

[Bug 13345] <details> should be allowed in <p>

From: <bugzilla@jessica.w3.org>
Date: Mon, 25 Jul 2011 18:45:10 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QlQ9O-0005tU-M4@jessica.w3.org>

--- 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:56 UTC