W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

[whatwg] <details> for long description of image/ video etc

From: Bjartur Thorlacius <svartman95@gmail.com>
Date: Mon, 4 Apr 2011 16:20:41 +0000
Message-ID: <BANLkTi=jPh5HDWoSGM1Lh2OEg_oWLKDUcw@mail.gmail.com>
On 4/4/11, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> Lachlan Hunt wrote:
>
>> Yes, it should be implemented equivalent to display:none.
>
> Please clarify. You seem to by trying to express it very briefly, at the
> cost of change of meaning. You don't really mean that the entire <details>
> element should not be displayed at all, do you? Just that only the <summary>
> element is displayed, the rest of <details> content being kept away, right?
>
> I think the assumed typical implementation of <details> rendering is
> described in some detail (no pun intended) at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-details-element-0
> Perhaps it is even too detailed to some extent. Personally I don't like the
> idea of defaults like 40px padding, in an environment where the pixel size
> and font size should be assumed to be unknown. (I can understand why some
> measures are given in pixels, following the bad tradition of browsers and
> "sample" stylesheets,  to prevent old documents from breaking apart, but for
> new elements, we could use the em unit, couldn't we?) And it's not quite
> clear what it means... but it makes it clear that only the implied "second
> container" is supposed to be removed from the rendering.
>
IMO, the specification of the <details> element is overly focused on
expected renderings. Rather than explicitly defining the semantics of
<details> with or without an @open attribute, and with or without a
<summary> child, sane renderings for medium to large displays whith
whom the user can interact are described, and usage is to be inferred
therefrom. This is suboptimal, as it allows hiding <details open>s on
small output windows but shoulds against it as strongly as ignoring
addition of the open attribute. Note that the <details> element
represents a disclosure widget, but the contents are nowhere defined
(neither as additional information (that a user-agent may or may not
render, depending on factors such as scarcity of screen estate), nor
as spoiling information that shouldn't be provided to the user without
explicit consent). I regard the two different use cases as different,
even though vendors might implement both with { binding: details; } on
some media. <Details> can't serve both. It's often spoken of as if
intended for something else than the YouTube video description use
case. <Details> mustn't be used for hiding spoilers, or else browsers
won't be able to intelligently choose to render the would-be concealed
contents.
Received on Monday, 4 April 2011 09:20:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:03 GMT