W3C home > Mailing lists > Public > public-html@w3.org > June 2011

[Bug 13062] New: HTML spec should not dictate first/last child nesting level and exact order of child siblings

From: <bugzilla@jessica.w3.org>
Date: Sun, 26 Jun 2011 14:12:06 +0000
To: public-html@w3.org
Message-ID: <bug-13062-2495@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13062

           Summary: HTML spec should not dictate first/last child nesting
                    level and exact order of child siblings
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: major
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: mtanalin@yandex.ru
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org
        Depends on: 12834,12835


Instead of purely theoretical:
"[Some-child] should be first child of a [some-parent] element",

it makes sense to use more practical definition:
"[Some-parent] element should be first _structural_ parent of [some-child]
element".

Difference is huge for any web developer who makes websites everyday:

1. First (used in current spec) definition dictates child element's position
both as for hierarchy nesting level and child order regardles of whether
intermediate hierarchy element is semantic (structural) or not.

2. Second one (proposed in the bug report) perfectly defines _semantic_
parent/child relations while _not_ making unneeded and harmful restrictions as
for parent/child nesting level and exact child order.

DIV is free from any semantic (structural) sense, so DIV (any number of) should
not be prohibited to be an intermediate hierarchical "layer" between structural
parent and child elements.

When parent semantic element can contain exactly one semantic child element
(e.g., fieldset/legend, figure/figcaption), HTML spec should also not dictate
exact child order: child element should be allowed to not be exactly first/last
child since there is no _practical_ need to make such restrictions as for child
order.

Example:

    <fielset>
        <div>
            <ul>
                <li><a href="#">Minimize</a></li>
                <li><a href="#">Close</a></li>
            </ul>
            <legend>Example</legend>
        </div>
    </fieldset>

Here, FIELDSET is not _direct_ parent of LEGEND, but _is_ still first
_structural_ parent of LEGEND.

Therefore, there is no need to restrict legend to be exactly first and direct
child of fieldset. Its functional sense is evident, and it is easy for User
Agent to determine parent/child relations in this case.

Another example:

    <dl>
        <div>
            <dt>Example</dt>
            <dd>Lorem ipsum</dd>
        </div>
    </dl>

Here, DL is not _direct_ parent of DT/DD, but _is_ first _structural_ parent of
DT/DD, so the code is perfectly OK.

One more example:

    <ul>
        <div>
            <li>Example</li>
        </div>
    </ul>

Here, UL is not _direct_ parent of LI, but _is_ first _structural_ parent of
LI. This is more than enough for UA to determine _semantic_ parent/child
relations, so such code is perfectly OK.

DIV is free from structural sense, so following nesting order:

    fieldset => div => legend
    dl => div => dt
    dl => div => dd
    ul => div => li

is _semantically_ absolutely _equivalent_ to:

    fieldset => legend
    dl => dt
    dl => dd
    ul => li

It's not of HTML spec responsibility at all to restrict semantic child nesting
level and first/last ordering. Child element should not be functionally similar
(and limited to be) just an attribute of its parent element (however, when
child position and nesting level is dictated by HTML spec, such child element
actually _is_ much similar to just attribute of parent element).

All such limitations are purely theoretical, completely detached from reality,
and should be dropped at all and avoided forever.

Thanks.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Sunday, 26 June 2011 14:12:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:25 UTC