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 17030 - Lists should permit interleaved structuring
Summary: Lists should permit interleaved structuring
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 critical
Target Milestone: ---
Assignee: Edward O'Connor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-10 14:26 UTC by Francis Davey
Modified: 2013-02-18 19:39 UTC (History)
8 users (show)

See Also:


Attachments

Description Francis Davey 2012-05-10 14:26:26 UTC
It is common for lawyers to use numbered lists extensively, for example in contracts and statutes. It is good style, and logical, to be able to group parts of such a document using some form of document structuring and to give parts of the document headings.

Doing this job properly in html is, at the moment, not possible if one wishes to obey the DTD: <ol> may only have <li> as children.

I write a lot of website terms and conditions and I would like to use HTML more widely as a source document for legal works. I am unhappy at having to adopt hacks to achieve this or to change, what seems to me a useful semantics for no good reason. 

I would not be surprised if this kind of interleaving was not also desirable in other contexts.

I suggest it would be useful to be able to markup numbering in a way that would allow at least headings and possible other structuring such as <section> to be interleaved with that numbering. To that end, could the <h?> tags <hgroup> and <section> be allowed as children of <ol>?

I realise there are hacks that would allow this. They are all quite ugly and in some cases rather awkward. I can also see no good reason for the restriction.
Comment 1 theimp 2012-07-05 02:53:44 UTC
Originally, <ol> meant Ordered List, not Numbered List. User Agents had to convey order somehow, which could have been anything from numbering, to using an ever-larger font for higher-value items, to inserting the text "Ordered List" before the list block.

The principle is that <ol> and <ul> are one-dimensional; the "numbering" of <ol> list items is as meaningless as the bullets against <ul> list items. If the numbers mean something, it's content, which makes it inappropriate for a one-dimensions list, and should be specified another way. Otherwise, it's presentation, and should be specified with eg. stylesheets.

In practice, people mostly decided that <ol> specifically implied numbering, which brought the above assumption into collision with the expectation that numbering should be content that they can control.

So, implementation of the advanced CSS solution ( http://www.w3.org/TR/css3-lists/ ) has been idle for almost a decade, while conversely, every implementor has dome something different to each other (See for example Bug 14548).

And then there's the accessibility concerns which transcend HTML/browsers (see for example Bug 13668)

This conflict of content/structure/presentation has also made other messes. See for example Bug 17632 and Bug 17633. It seems that it's no longer possible to treat ordered lists specifically as being only structural, only presentational, or only content. All three concepts must be implemented consistently with each other for predictable results. HTML5 does not intend to address this decisively.

And this has all made it extremely difficult to properly mark up things like legal documents, where, for example, "Section 1A" *must* have the number "1A" in all user agents and under all circumstances. Difficult to the point that the usual solution is to not use semantic markup, and just have a big plain text dump.

---

Now, as for a solution to the issue you've mentioned specifically, try using the DL/DT/DD structure, where you have a list where the numbering is critical.

Something like:

<style>
dl {
background-color: #0000ff;
}
dt {
display: inline;
float: left;
width: 3em;
margin-right: 1em;
text-align: right;
background-color: #ff0000;
}
dd {
background-color: #00ff00;
margin-left: 4em;
}
dt:after {
content: ".";
}
</style>
<dl>
<dt>abc</dt>
<dd> def ghi</dd>
</dl>

The benefit of this is made even better for things like legal documents, where complex markup (such as <span> or <abbr>) can be used within the "list marker" (dt). You can have sublevels (nest more DLs within DTs), and individual styles, and so on. Be careful with completely unnumbered (ie. empty) entries, though; it's syntactically legal, but semantically problematic.

In any case; don't use <ol> anywhere that the numbering itself is vital (then it's content; use <dl> or <table>). This is true now and will remain true after HTML5 is standardized.
Comment 2 contributor 2012-07-18 07:09:07 UTC
This bug was cloned to create bug 17868 as part of operation convergence.
Comment 3 Erika Doyle Navara 2012-09-10 22:22:57 UTC
As outlined in Comment 1, there are a number of pitfalls and arguments against expanding the functionality of OLs. In any case, let's revisit the feature request for interleaved lists in post-HTML5.
Comment 4 Robin Berjon 2013-01-21 15:58:08 UTC
Mass move to "HTML WG"
Comment 5 Robin Berjon 2013-01-21 16:00:53 UTC
Mass move to "HTML WG"
Comment 6 Edward O'Connor 2013-02-18 19:39:46 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: Section numbers should be explicitly present in the text content of
legal documents. Are there other use cases we should consider?