Re: ISSUE-93 Details change proposal discussion

On Sun, May 2, 2010 at 12:43 PM, Benoit Piette <benoit.piette@gmail.com> wrote:
> What if is some content can be defined as supplemental, details of some
> other content. Should we use the details element? Clearly not, because the
> details element is a widget / component, not an element that helps to
> structure a document. We have been told not to use table for presentation,
> but now, if we want an “activate to expand widget” we are told to use an
> element that looks structural, but is not. You can use the semantics in it,
> but only in the context of an activate to expand widget.

Actually, it should be fine for that sort of purpose.  The main
problem <details> is solving is that hiding some content and making it
showable through some control is a very common pattern in webpages,
but it's done badly almost every single time.  People (like, um, me)
pull in entire giant libraries like jQuery just to implement this
trivial sort of thing.  They screw up the mechanics, for example only
allowing it to respond to clicks, so keyboard users can't access it.
They screw up the semantics, so that screen readers simply ignore the
hidden content, rather than exposing it as optional content to the
user.

<details> solves all of these problems once and for all in a simple,
elegant manner.


> I think this is a very bad precedent and basically throws out the window the
> principles of separating content behavior and presentation. I know that
> there are elements with a mix of presentation and semantics (hr, i, br,
> etc), but they are there for historic reasons, not as an example of good
> language design.

Keep in mind the reasoning behind the separation of content, behavior,
and presentation.  It's not because there's some theoretically pure
ideal design that we're striving towards.  It's because separating
them is *useful*.  You make code easier to understand, and easier to
reuse.  You add useful structure that can be exploited by other
technologies, such as how <h1-6> can be used to outline a page for
easy navigation with screen-readers, which couldn't be consistently
done if they were just <p class=header1>.

<details> appears to be the sort of thing that falls squarely into the
"useful to keep together" category.  It's a mix of semantics,
presentation, and behavior, but it's a *very common* mix, and one that
is hard to tie together in all the right ways if you use the
traditional separation.  Thus, it's more useful for authors,
implementors, and most importantly users if you slightly violate the
theoretical guidelines in favor of more practical concerns.


> If we want widget elements in HTML5, and maybe we do for accessibility
> reasons, here is what I advise:
> 1) they should be completely separated them from structural elements
> 2) semantics should be left with the structural elements
> 3) they should have widget names (behavioral names like expandable)
> 4) If we want to mix behavior and structure, structure and behavior binding
> should be explicit and easily overridable.

This seems to me to be the worst possible solution.  It is, as you
state below, exactly like recreating <font> in a new form; you're just
creating a purely behavioral element with no semantics.

What problem is solved by doing it this way?  How is this a better
solution for authors or users than <details>?  Remember that
theoretical purity is far down the list of constituent concerns.
Making the language pure generally loses to making implementors happy,
which generally loses to making authors happy, which generally loses
to making users happy.  This ensures that the language we end up with
is one that is designed for the end-user first, rather than being an
over-architected framework that you need a team of consultants to use
properly.


Also, apologies, but I'm going to hijack your post temporarily to
publish some thoughts on the styling issue.  Right now, <details>
cannot be consistently styled in pure CSS.  The basic idea is that you
could use something like this in the UA stylesheet:

details:not([open]) > :not(summary) { display: none; }
details[open] > summary::before { content: url(icon:disclosure-open); }
details:not([open]) > summary::before { content: url(icon:disclosure-closed); }

But that doesn't work correctly, as the contents of <details> may just
be text nodes, which won't be targetted by the first rule.  As well,
though the style of "disclosure triangle in the summary, before the
text" is probably going to be the style most browsers use, it's
certainly reasonable that it may work slightly differently.

To address these issues, we can introduce some pseudoelements,
presumably created by the default binding assigned to the element.  A
::disclosure pseudo would represent the disclosure triangle, and a
::content pseudo would represent the non-summary contents of
<details>.  The styling would then be:

details:not([open])::content { display: none; }
details[open]::disclosure { content: url(icon:disclosure-open); }
details:not([open])::disclosure { conent: url(icon:disclosure-closed); }

This is more robust against text node children, and ensures that it's
easy to override the UA's disclosure icon.

The only apparent problem is what happens if there is content before
the <summary>, but the spec already handles that in its description of
the default binding - all non-summary children are put into a block
box that follows <summary>.  So we just have to give that box a name -
::content - and we're golden.

~TJ

Received on Sunday, 2 May 2010 22:51:32 UTC