Re: ISSUE-93 Details change proposal discussion

Answers bellow,

2010/5/2 Tab Atkins Jr. <jackalmage@gmail.com>

> 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.
>
>
The problem I see in this is what happens if you want the behavior, but not
the semantics associated with it, (I know, this is very theoretical) or the
semantics, but not the behavior (less theoritical, the example I gave with
ul ). I also don't think that the summary element name is particularly
elegant.


> > 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.
>
>
>
But in its current form, it is not very flexible. What if you want to use
the concept of details with a table heading being the summary, and the table
body being the details, how do you markup it without it looking like
spaghetti code? (The table already has all the encapsulating markup that can
be used as details and summary). You are just adding a behavior on the
table, not new semantics.


> > 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.
>
> But I want to be in that team of consultants! Just joking. I still go to
the example of when you want to use the semantics, but not the behavior.
That's the main problem. But we can always choose to ignore the elements
that transgresses the purity if we wish.


> 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:
>
>
No problem at all, styling details is a problem and we must find a simple
way to do it.
Don't you think it would be better to change the details element so that it
could be styled without adding new pseudoelements? I think that it was one
of the things I tried to do on my last examples. By adding a behavior /
presentation switch on an element, you could either use the default
implementation (that's what most people would use) or use "normal"
javascript and CSS, without loosing the important accessibility hooks. In
that case, you could also use the part of the element that is 100% semantic
and keep the purity that some people (like me and evil consultants) are so
fond of.


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

What if I want something like this :
<section>
<details>
<summary><h1>My title for my little story content box</h1>
<p>I have a little story to tell, but you might think it's a little long so
you might as well skip it</p>
</summary>
<p>Once upon a time, there was this small village that had a small, well a
big problem. A giant made its home
in it. It had a really big beard. So big in fact, that giant lice were
living in it... etc This is actually a story I tell my children before they
sleep. Yes it is better than lorem ipsum.</p>
</details>
</section>

It's not just semantic purity here, you get semantics x 2. Details and
section are redundant, and you could replace summary with header or have
both. We could leave section, but we would loose semantics that is more
relevant than details here.

I would rather have something like this :

<section>
<h1>My title for my little story content box</h1>
<p>I have a little story to tell, but you might think it's a little long so
you might as well skip it</p>
<details>
<p>Once upon a time, there was this small village that as a small, well a
big problem. A giant made its home
in it. It had a really big beard. So big in fact, that giant lice were
living in it... etc This is actually a story I tell my children before they
sleep. Yes it is better than lorem ipsum.</p>
</details>
</section>

Now, the details semantics is not redundant. It tells us that the second
paragraph is optional. With conventions you can tell that the enclosing
section is the one that should have a disclosure widget. But that's
overridable with a for attribute. You can add and override attribute to tell
the browser that the behavior and presentation is done (or not) by
javascript and css. The pseudo-elements you presented would be quite useful
to simplify implementation also. No parent css selectors makes CSS harder to
do though.

Haha! I know now why I'm not a browser implementer! The trouble here (I
suppose) is that the parser does not know that section is a parent of a
details before it encounters details, leading to all sorts of performance
problems (that's why there is no CSS parent selectors). You have to tell the
parser (correct me if I'm wrong) that section has a detail behavior, that's
why we need the duplicated elements...

Then...

<section has-details>
<h1>My title for my little story content box</h1>
<p>I have a little story to tell, but you might think it's a little long so
you might as well skip it</p>
<details>
<p>Once upon a time, there was this small village that as a small, well a
big problem. A giant made its home
in it. It had a really big beard. So big in fact, that giant lice were
living in it... etc This is actually a story I tell my children before they
sleep. Yes it is better than lorem ipsum.</p>
</details>
</section>

No need to have the for attribute then... Not sure about this... That's why
I still support removing the details element... Until we find something that
is really better...


Benoit Piette
http://benoitpiette.com
http://w3qc.org