13062 – HTML spec should not dictate first/last child nesting level and exact order of child siblings

This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13062 - HTML spec should not dictate first/last child nesting level and exact order of child siblings

Summary: HTML spec should not dictate first/last child nesting level and exact order o...

Status:	RESOLVED WONTFIX

Alias:	None

Product:	HTML WG
Classification:	Unclassified
Component:	LC1 HTML5 spec (show other bugs)
Version:	unspecified
Hardware:	All All

Importance:	P4 enhancement
Target Milestone:	---
Assignee:	contributor
QA Contact:	HTML WG Bugzilla archive list

URL:	http://tanalin.com/_experimentz/bugs/...
Whiteboard:
Keywords:

Depends on:	12834 13128
Blocks:
	Show dependency tree / graph

Reported:	2011-06-26 14:12 UTC by Marat Tanalin \| tanalin.com
Modified:	2011-12-02 17:03 UTC (History)
CC List:	6 users (show)

See Also:

Attachments

Description Marat Tanalin | tanalin.com 2011-06-26 14:12:04 UTC

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.

Comment 1 Boris Zbarsky 2011-06-26 15:01:59 UTC

> DIV is free from any semantic (structural) sense

That's not quite true.  It has the semantic sense of "a group".  Worse yet, it requires a CSS box.

Try using your examples in current browsers; they all break the rendering completely as a result of those two points....

Comment 2 Marat Tanalin | tanalin.com 2011-06-26 16:06:19 UTC

(In reply to comment #1)
> > DIV is free from any semantic (structural) sense
> 
> That's not quite true.  It has the semantic sense of "a group".

It's not a semantic sense. It's just syntactic feature, and that does not affect the bug point.

> Try using your examples in current browsers

Added testcase URL.

As we can see, everything is OK here:

 Elements are styleable.

 Resulting body.innerHTML / DOM tree exactly corresponds to source code. Elements hierarchy is not affected/changed by browser's HTML-code error correction.

Tested on Firefox 5, Opera 11.11, Chrome 12, IE 7-9.

An only "nuance" is that LEGEND is shown not on top border of fieldset, but this is perfectly OK as for backward-compatibility.

Comment 3 Daniel.S 2011-06-26 16:49:25 UTC

(In reply to comment #0)
> 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 reason why we (authors) want and need a definition group element (<di>). It works almost everywhere already and we wouldn't have to wait another 10 years to have fitting pseudo elements defined in CSS.

Comment 4 Marat Tanalin | tanalin.com 2011-06-26 16:56:41 UTC

(In reply to comment #3)
> One reason why we (authors) want and need a definition group element (<di>).

This example is not about grouping DT/DD into semantic pairs at all, and probable semantic <di> element has nothing to do with the bug.

Comment 5 Daniel.S 2011-06-26 17:14:34 UTC

(In reply to comment #4)
> (In reply to comment #3)
> > One reason why we (authors) want and need a definition group element (<di>).
> 
> This example is not about grouping DT/DD into semantic pairs at all, and
> probable semantic <di> element has nothing to do with the bug.

I admit, the relation is subtle. I can't image why else you'd want to put a div inside dl but outside dt/dd.

The current content model is greatly based on legacy HTML.
In a XML/CSS world you don't necessarily need ul or dl elements, since CSS is able to generate Lists all by itself.
On the other hand, you do need the exact fieldset/legend pair; else, the relation between the two would be lost. Try your example without the div you deem theoretically forbidden.

Comment 6 Marat Tanalin | tanalin.com 2011-06-26 17:25:08 UTC

(In reply to comment #5)

The bug is not about DL/DT/DD in particular at all. The bug is about more common issue in HTML spec as a whole.

Please create separate bug for <di> if you want, and avoid offtopic in this bug. Thanks.

Comment 7 Daniel.S 2011-06-26 17:53:14 UTC

(In reply to comment #6)
> The bug is not about DL/DT/DD in particular at all. The bug is about more
> common issue in HTML spec as a whole.

I understand what this bug is about. Both, the content model you describe (though invalid) and the content model the spec calls for (due legacy) are possible to be authored already.
Coincidentally your example resembled the other discussion as well.

> Please create separate bug for <di> if you want, and avoid offtopic in this
> bug. Thanks.

Those exist already. I didn't intend to spam. Sorry, I'm out.

Comment 8 Aryeh Gregor 2011-06-26 22:46:47 UTC

(In reply to comment #1)
> > DIV is free from any semantic (structural) sense
> 
> That's not quite true.  It has the semantic sense of "a group".

Which would make sense in lists, and could be quite useful.  (The question of ordering of things like <legend> is a separate one and should really have been filed separately.)

> Worse yet, it requires a CSS box.
> 
> Try using your examples in current browsers; they all break the rendering
> completely as a result of those two points....

How so?  I don't notice any breakage.

Comment 9 Aryeh Gregor 2011-06-26 22:51:24 UTC

This bug deals with several things at once, which makes it hard to process.  If the three examples, your first is bug 12834, and the other two are about grouping list items, so I've repurposed this bug to just grouping list items.  If you have any specific concerns that aren't covered by these two existing bugs (plus bug 12835), please file further bugs, one per issue.  Bugs should be narrow in scope so related but separate issues can be handled separately.

Comment 10 Boris Zbarsky 2011-06-26 23:30:35 UTC

> How so?  I don't notice any breakage.

The <legend> not being a legend is not breakage?

Comment 11 Marat Tanalin | tanalin.com 2011-06-26 23:42:23 UTC

(In reply to comment #9)
> This bug deals with several things at once, which makes it hard to process.  If
> the three examples, your first is bug 12834, and the other two are about
> grouping list items, so I've repurposed this bug to just grouping list items. 
> If you have any specific concerns that aren't covered by these two existing
> bugs (plus bug 12835), please file further bugs, one per issue.  Bugs should be
> narrow in scope so related but separate issues can be handled separately.

The bug _is_ narrow: HTML spec currently uses wrong means to describe semantic parent/child relations.

Again:

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

Examples are just examples, they do not have sense out of context of this bug, and should not be considered separately. The issue is more common, systemic, and serious.

Thanks.

Comment 12 Marat Tanalin | tanalin.com 2011-06-26 23:43:38 UTC

(In reply to comment #10)
> > How so?  I don't notice any breakage.
> 
> The <legend> not being a legend is not breakage?

What do you exactly consider "legend is legend"?

Comment 13 Boris Zbarsky 2011-06-26 23:45:06 UTC

"renders like a legend for the fieldset".  You know, the issue you mention at the end of comment 2.

Comment 14 Marat Tanalin | tanalin.com 2011-06-26 23:47:44 UTC

(In reply to comment #13)
> "renders like a legend for the fieldset".  You know, the issue you mention at
> the end of comment 2.

It's not an issue. Old sites do not use proposed syntax. New sites will have new styles to have legend any needed visual appearance. For browsers, it will not be any hard to implement new parent/child relation logic.

Comment 15 Marat Tanalin | tanalin.com 2011-06-26 23:51:06 UTC

Considering the reasoning I've stated in comment 11, I'm renaming the bug back to original title since "Allow grouping list items with divs" does not reflect the real bug point.

Comment 16 Boris Zbarsky 2011-06-26 23:53:42 UTC

> New sites will have new styles to have legend any needed visual appearance.

No, new sites, if some browsers make this change, will just depend on that behavior and break in existing browsers...

But whatever.  Given your comments about browsers, I'm not sure it's worth spending more time on this.

Comment 17 Marat Tanalin | tanalin.com 2011-06-26 23:58:43 UTC

(In reply to comment #16)
> > New sites will have new styles to have legend any needed visual appearance.
> 
> No, new sites, if some browsers make this change, will just depend on that
> behavior and break in existing browsers...

Please give a _practical_ example of breaking that you mention if it really does exist.

> Given your comments about browsers, I'm not sure it's worth
> spending more time on this.

Can you specify more accurate what do you mean?

Comment 18 Marat Tanalin | tanalin.com 2011-06-27 00:21:31 UTC

To be clear: _visual_ browsers may not (or even should not) implement any changes related to proposed spec change. Current behavior of visual browsers is _already_ OK as for styling legend wrapped into extra div.

As for fieldset/legend _in particular_, as for browsers for visual impaired users, it would not be hard to implement updated logic that find legend related to a fieldset just taking into account that a div(s) may be an intermediate tree level between fieldset and legend, and that legend may not be exactly first child of fieldset.

Finally, the point of the bug is mainly just to _document_ existing behavior of all current browsers into the spec (such documenting is actually one of fundamental HTML5 spec purposes), and _not_ inventing or adding something brand new at all.

Comment 19 Aryeh Gregor 2011-06-27 17:41:33 UTC

(In reply to comment #10)
> The <legend> not being a legend is not breakage?

Oh, didn't notice that.  Yeah, we'd still have to require that <legend> be a child of <fieldset>, but we don't have to require that it be the first child.  But that's bug 12834.  AFAICT there are no problems with <div>s around list items, which strikes me as the most useful suggestion here (and the only specific one not already covered by another bug).

(In reply to comment #11)
> The bug _is_ narrow: HTML spec currently uses wrong means to describe semantic
> parent/child relations.

The bug proposes several different changes to the specification, in that several different changes would be made to different sections.  Moreover, it would be possible for the editor to accept some of the changes and not others: for example, he WONTFIXed bug 12835 but left bug 12834 open for now.  There should be separate bugs for separate requested changes (even if the *reason* is the same) so that they can be given different resolutions if necessary.  Bugs should be filed about what changes you want in the specification's text, not what changes you want in its philosophy -- the latter should be used as rationale for the former.

(In reply to comment #15)
> Considering the reasoning I've stated in comment 11, I'm renaming the bug back
> to original title since "Allow grouping list items with divs" does not reflect
> the real bug point.

I'm not going to argue further, but I advise you that I think this will hurt your bug's chances of being accepted.

Comment 20 Marat Tanalin | tanalin.com 2011-07-03 19:03:49 UTC

Filed bug 13128 dedicated to DIV-wrapping list items in particular.

Comment 21 Michael[tm] Smith 2011-08-04 05:05:18 UTC

mass-moved component to LC1

Comment 22 Ian 'Hixie' Hickson 2011-08-14 06:12:30 UTC

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: 

Since each case of this has case-specific considerations, please file a separate bug for each instance of this pattern that you want changed. For example, changing it for <figure> (which is new and mainly just based on CSS) may be easier than changing it for <fieldset> (which has lots of complicated legacy styling rules and is already widely implemented and used).

Some bugs already filed around this issue have been listed in the "Depends on" list for this bug.

Comment 23 Marat Tanalin | tanalin.com 2011-08-24 19:07:49 UTC

(In reply to comment #22)
> Since each case of this has case-specific considerations, please file a
> separate bug for each instance of this pattern that you want changed.

Bad thing is that separate bug-reports will not prevent making similar impractical spec-level mistakes again and again when inventing new structural markup for future HTML versions.

For example, if even current "child"-bugs will be fixed, then potential new markup in future could contain same absurd requirement like "Element A should be first direct child of element B" again and again. This might lead to reporting more "case-specific" bugs while keeping actual fundamental issue still nonresolved.

Purpose of the current bug-report is to prevent ALL such nonsensical requirements from appearing in the HTML spec forever.

Any element that can be styled at all (unlike, for example, PARAM inside OBJECT) should never be limited to be first or last child of any element. Otherwise, it will be inevitably abandoned in real practice in favor of more flexible (while less semantical) elements. This would be very harmful for semantics and for HTML itself.

Thanks.

Comment 24 Ian 'Hixie' Hickson 2011-12-02 17:03:41 UTC

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: I reject the premise that all such instances are automatically mistakes. And in any case, this bug wouldn't guarantee my future editing behaviour one way or another.