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

Re: [whatwg] summary/details - proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 8 Apr 2014 13:54:39 -0700
Message-ID: <CAAWBYDCAr4C-fSYx9a_y=D3aZe0_9e_UOLo5yUJrk9TXs46Meg@mail.gmail.com>
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: whatwg <whatwg@lists.whatwg.org>
On Tue, Apr 8, 2014 at 5:25 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote:
> avoiding unnecessary recourse to web component use is a reasonable and
> expected goal - built in vs bolt on accessibility is better. Having to use
> a web component to overcome the inability to make a html control usable
> without relying on CSS and Js and ARIA is unfortunate, and as you said
> yesterday

I still don't understand.  Do you think that what Hixie is saying
(about clicking on non-interactive text in <summary> toggling the
<details>) is wrong?

The behavior that Hixie describes is roughly what implementations do
today.  In Blink, clicking on any bare text in the <summary> toggles
the <details>, while clicking on an <input> does not.  However, Blink
current behavior with <label> is different - it basically ignores the
presence of the <label>, as far as I can tell, and still toggles the
<details> even if the <label> is redirecting the click to an <input>.

I would strongly object to any suggestion that <summary> should only
toggle <details> when you click on the disclosure triangle, unless you
add some additional markup like <label>.  That would be terrible UI.

Received on Tuesday, 8 April 2014 20:55:28 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:19 UTC