Re: Promise broken on ISSUE 204?

On Mon, May 7, 2012 at 8:58 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> There likely would be a strong objection to Cynthia's and (and possibly
> your) proposal(s):
>
>  http://krijnhoetmer.nl/irc-logs/html-wg/20120505#l-142
>
> The basis of this was a statement that the spec text as drafted would
> specifically preclude UAs (including browsers) from ever giving a better
> experience:
>
>  http://krijnhoetmer.nl/irc-logs/html-wg/20120504#l-2920

I take it you're talking about this objection from Maciej:

> # [23:58] <timeless> mjs: it seems that if a user tabs to something offscreen
> # [23:58] <timeless> ... you should temporarily show it
> # [23:58] <timeless> ... if a UA can give a better experience
> # [23:58] <timeless> ... i think they should be encouraged to try
> # [23:58] <timeless> ... i can see the argument for not encouraging authors to try
> # [23:58] <timeless> ... while they do not exist

And I take it this refers to this proposed text from the TF's change
proposal which John has dropped in his revision:

"User agents should not render elements that have the hidden attribute
specified. User agents should not create accessible objects in the
platform accessibility API tree for elements that have the hidden
attribute specified.  User agents should use the text-children of the
hidden element to create a plain-text string, and use that string to
fill in name and description properties in the objects created for the
referring element, which does not have the hidden attribute
specified."

I have my own problems with this text, but can we unpick Maciej's
objection a little?

The rationale for introducing @hidden (née @irrelevant) was to provide
a clear way to communicate that parts of the DOM are not relevant to
the current state of the application. Originally, for example,
@irrelevant was going to be used to distinguish parts of the DOM that
were (temporarily) not part of a modal dialog. Obviously user agents
should prevent users tabbing out of a modal dialog into other parts of
the DOM. This was a worthy addition to the language as authors today
often misuse authorial style suggestions (display: none) to hide text
that should not be rendered in the current state, for example error
messages for forms.

The Google search page offers a prominent example. Try turning off
author styles in Firefox (View menu, Page Style submenu, select No
Style). Note the visible text warns that "Google Instant is
unavailable" and "Google Instant is off due to connection speed" even
though it's actually on.

In the future, such messages could be hidden with @hidden and thus
kept out of the way even when author styles are rejected. The
alternative technique is to add/remove content from the DOM as
appropriate, but authors who prefer to keep content for other states
in the DOM can use @hidden as a drop-in replacement for "display:
none". So that use case makes sense to me.

Could those who want to make it possible to display or interact with
@hidden content please explain what they think is the point of
including the attribute in the language? What use cases would it solve
that are not already solved better by existing techniques, such as:
when JS is available, hide extra content off-screen but move it
on-screen if it receives focus?

As far as I know, nobody has put forward a single example where they
are happy to declare that placing accessibility-related content in
@hidden would be better for users and authors than alternative
techniques. So it seems bizarre that we are talking about preventing
@hidden meeting its original use cases in service of such usage.

--
Benjamin Hawkes-Lewis

Received on Monday, 7 May 2012 22:04:29 UTC