Re: ISSUE-93 Details change proposal discussion

On Sun, May 2, 2010 at 5:44 PM, Benoit Piette <benoit.piette@gmail.com> wrote:
> 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.

The semantics of <details> are valid to be used quite widely, so if
you really want the behavior, it's very likely that you can justify
the semantics.

If you want to provide details without autohiding them, you just
provide them.  You don't need a special element for that; you're not
conveying any special semantics, or at least none that we care about
enough to special-case.


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

That sort of case can probably be done by simply putting a summary in
<summary>, and then the entire <table> in the content.  When that's
not enough (when you *really really* want <thead> to show/hide the
<tbody>), it's enough of an edge-case that I'm okay with <details> not
covering it.  Do you have examples of that sort of thing being done on
the web?


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

Yeah, like I said before, if you don't want to auto-hide the contents,
you don't need any special markup.  Just put the content right in.

Alternately, use <details open></details>; that is, have the contents
shown by default, but able to be closed.

That pretty much covers everything.  If you think the content may or
may not be useful, use <details>.  If you think it may or may not be
useful, but want to go ahead and show it by default, use <details
open>.  Otherwise, you clearly think it'll be useful, so just put it
in.


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

I'd rather have the markup be as simple as possible, and then solve
the styling problem separately.  <details><summary/></details> is as
simple as possible.  A lot of the time you won't need to change
anything in particular; when you do, we can just present all the hooks
you need.

And, if you really want to totally change how the element is handled,
all you have to do is wait for browsers to support XBL2, and change
the binding of the element.  ^_^  I hear that Firefox is going to be
adding initial XBL2 support in the immediate future.


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

I agree that the first example is very redundant.  Your second example
is redundant too, though.  Why use the <details> at all?  Users of
normal browsers can just skip it themselves, and alternate browsers
like screenreaders often give their users the ability to skip around
by headings

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

Now, the question to ask yourself is, are you solving a useful
problem?  Are you solving it better than the existing solution?  As I
said earlier, I don't think there's a problem to solve in the example
you provided.

When applied to stuff that is more unambiguously <details>-fodder, is
there benefit in marking it up like:

<section has-details>
  Spoilers for Star Wars!
  <details>
    Luke killed Vader in the study with the candlestick.
  </details>
</section>

over...

<details>
  <summary>Spoilers for Star Wars!</summary>
  Luke killed Vader in the study with the candlestick.
</details>

?

~TJ

Received on Monday, 3 May 2010 01:24:21 UTC