Re: <details> element clarifications

The first message of the thread was published on
http://lists.w3.org/Archives/Public/public-html/2014Nov/0041.html.
By replying to that, I am copying the text of our previous emails, along
with this answer.
You will find the complete conversation clicking on the "Next in Thread"
link below your message.
Hope you can use it.
Good luck.
Andrea

2014-11-11 19:56 GMT+01:00 Maksim Chemerisuk <chemerisuk@gmail.com>:

> Thanks for clarification Andrea, I guess you answered all my questions. I
> was confused by the definition from the spec because browser vendors use
> :first-of-type CSS selector to catch <summary>, not :first-child. It looks
> like they just try to fix such invalid markup. In my case I decided to move
> the element to the first child position to avoid such confusing
> presentation.
>
> Will this conversion be published somewhere, so I can reference to it?
>
> ---
> Maksim
>
> On 11 November 2014 18:35, Andrea Rendine <master.skywalker.88@gmail.com>
>  wrote:
>
>> Hi again Maxim.
>> I re-read your definition. Better to clarify that point first.
>> At this moment, no definition state that it is correct to put summary as
>> second, third etc. child element of <details>.
>> *The first summary element child of the element, if any, represents the
>> summary or legend of the details. If there is no child summary element, the
>> user agent should provide its own legend (e.g. "Details").*
>> This sentence only states one thing: if by mistake <details> contains
>> more than 1 <summary> child element, only the first is meant to be the
>> legend for the widget.
>> The only allowed subtree for this element is:
>> - details
>>    - summary
>>    - [other flow content]
>> while content rearrangement mechanics must be seen only as error handling
>> (in some sense, as browsers handle incorrect nesting for paragraphs and
>> text formatting.
>> So of course all issues regarding content flow must take into account
>> that putting <summary> after other flow elements is, by any mean,
>> incorrect, and as such doesn't deserve any other rule for displaying.
>> In my opinion it would have been much better for spec authors to state
>> that a <details> should have a summary attribute, not element, so that its
>> text value could be displayed as the element's legend. But i suppose that
>> it was meant for legacy user agents who wouldn't have known how to display
>> a new attribute.
>> Summarizing:
>>
>>    - the only correct DOM subtree for the element is the one stated
>>    above.
>>    - definition 1 states that,
>>    - if more than 1 summary element is present, then only the first must
>>    be considered.
>>    - the first summary element is the <details>' legend, thus opening
>>    way to error handling.
>>    - both these statements are edge cases and incorrect. But authors
>>    still ignore correctedness several times.
>>    - definition 2 is currently the correct way.
>>
>> Thank you for the note about Safari. I reported you what Steve Faulkner
>> stated:
>> http://lists.w3.org/Archives/Public/public-html/2014Nov/0039.html
>> No doubt I will reply to his message, now that you mention it.
>> Bye!
>> Andrea
>>
>> 2014-11-11 14:22 GMT+01:00 Maksim Chemerisuk <chemerisuk@gmail.com>:
>>
>>> Thanks for the response Andrea.
>>>
>>> Does it really make sense to allow <summary> NOT to be the first child
>>> and then fix it visually? From what I understood HTML allows such kind of
>>> markup, but not XHTML. I believe it will be much clearer to fix the problem
>>> in the definition, because such edge case makes harder creating a polyfill.
>>> Moreover a display result may look confusing, because normal element flow
>>> is different from rendered result, where <summary> is always on the top of
>>> <details> even it's not the first child (this is what we have at present in
>>> WebKit actually). Any reasons why it wasn't defined in this way?
>>>
>>> I checked http://validator.w3.org/nu/ too, it looks like it works
>>> according to the <summary> context definition: only first child is allowed.
>>> Does it mean that this is the correct markup then? If yes, I do suggest to
>>> fix the confusing definition I mentioned in the first email.
>>>
>>> The argument for the second question is clearer, thanks.
>>>
>>> BTW you can count Safari as another one browser that supports <details>:
>>> http://caniuse.com/#feat=details
>>>
>>> ---
>>> Thanks,
>>> Maksim
>>>
>>>
>>>
>>> On 11 November 2014 04:33, Andrea Rendine <master.skywalker.88@gmail.com
>>> > wrote:
>>>
>>>> Sidenote: Validator.w3.org/nu <http://validator.w3.org/nu> does not
>>>> flag <details> as not allowed, yet. Or already, as it will be probably
>>>> allowed when UAs restore support. It flags its use as "not advised because
>>>> of poor implementation", though.
>>>> Anyway, it considers an error to put elements before the <summary>.
>>>> Both Opera and Chrome display it correctly when the order is messed (Opera
>>>> still supports <details>. Great.)
>>>> Bye.
>>>>
>>>> 2014-11-11 2:24 GMT+01:00 Andrea Rendine <master.skywalker.88@gmail.com
>>>> >:
>>>>
>>>>> Hi Maksim.
>>>>> For what I remember, in the WHATWG version of the spec it was
>>>>> explicitly stated that <summary> can be something different than the very
>>>>> first child element of a <details>. I tried to wayback the page, but
>>>>> there's nothing old enough to support my statement. Anyway i guess their
>>>>> living standard had tree construction rules for repositioning the first
>>>>> <summary> child element as first element inside <details>. It must be so,
>>>>> because toggling the show/hide action, the rest of the <details> content is
>>>>> shown below the summary, so ideally the element must be first.
>>>>> It's almost the same than <table><tbody><tr> issue (it isn't correct
>>>>> to put <tr> directly inside <table>. Thus said, browsers know what to do
>>>>> and build fake <tbody>s wrapping rows).
>>>>>
>>>>> As for the second question, consider that the purpose of <details> is
>>>>> not semantic, but strictly presentational: it represents a collapsible
>>>>> widget. So it MUST have a control for the collapse/espand action. If the
>>>>> author doesn't insert it by himself, the browser has to work it around.
>>>>>
>>>>> Of course these answers only apply to HTML. XHTML document DOM trees
>>>>> cannot be changed, so the element must a) be present and b) be first.
>>>>>
>>>>> A last point: <details> has very poor implementation, for what I know
>>>>> at this very moment only Google Chrome latest release supports it. It has
>>>>> also been removed from W3 HTML5 Recommendation, due to the lack of at least
>>>>> 2 interoperable implementations.
>>>>>
>>>>> Hope this helped.
>>>>> Regards.
>>>>> Andrea R.
>>>>>
>>>>> 2014-11-09 22:18 GMT+01:00 Maksim Chemerisuk <chemerisuk@gmail.com>:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I'm writing an article about <details> element polyfil and after
>>>>>> reading the specification at
>>>>>> http://www.w3.org/html/wg/drafts/html/master/interactive-elements.html#the-details-element want
>>>>>> to clarify some parts in it.
>>>>>>
>>>>>> *The first summary element child of the element, if any, represents
>>>>>> the summary or legend of the details. If there is no child summary element,
>>>>>> the user agent should provide its own legend (e.g. "Details").*
>>>>>>
>>>>>> 1)
>>>>>>
>>>>>> The first definition of <summary> assumes that it may NOT be the
>>>>>> first child of <details>. Later, I found a correction at
>>>>>> http://www.w3.org/html/wg/drafts/html/master/interactive-elements.html#the-summary-element
>>>>>> :
>>>>>>
>>>>>> *Contexts in which this element can be used:*
>>>>>> *As the first child of a details element.*
>>>>>>
>>>>>> So what's the correct answer then? Is it valid for the <summary>
>>>>>> element not to be the first child?As far as I see in Webkit implementation
>>>>>> allows that.
>>>>>>
>>>>>> 2)
>>>>>>
>>>>>> What's the goal of adding fake "Details" legend if <details> does not
>>>>>> contain a child <summary>? It's a bit weird so I'd like to understand this
>>>>>> edge case better to be as much complied to the spec as possible.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> ---
>>>>>> Maksim Chemerisuk
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>