W3C home > Mailing lists > Public > public-digipub-ig@w3.org > December 2013

Re: [Styling and Layout] new use case added: Lists, Outline Lists

From: Cramer, Dave <Dave.Cramer@hbgusa.com>
Date: Tue, 17 Dec 2013 10:28:30 -0500
To: Jean Kaplansky <Jean.Kaplansky@aptaracorp.com>, Ivan Herman <ivan@w3.org>
CC: W3C Digital Publishing IG <public-digipub-ig@w3.org>, Bert Bos <bert@w3.org>
Message-ID: <CED5CD13.4398B%david.cramer@hbgusa.com>
On 12/17/13 8:34 AM, "Jean Kaplansky" <Jean.Kaplansky@aptaracorp.com<mailto:Jean.Kaplansky@aptaracorp.com>> wrote:

Ivan -

The problem is that we have to go to CSS to construct a hierarchical list in the first place. Publishers don’t want that. They want a way to distinctly separate the markup for an ordinary list <ol> from an outline (which could be an entirely new element, or <ol> with some sort of type attribute indicating that it is an outline) where the numbering is automatically supplied by the UA, but is still intrinsic to the meaning of the list – a true hierarchical outline.

I just made up a little sample with two types of lists, one numbered 1.1.1 etc., and the other an outline list (with I., A., 1., etc.) I used class attributes on the lists to distinguish the cases, and five lines of CSS:

ol.outline { list-style-type: upper-alpha; }
ol.outline ol { list-style-type: upper-roman; }
ol.outline ol ol { list-style-type: decimal; }
ol.nested { counter-reset: item; list-style-type: none;}
ol.nested li::before { content: counters(item, ".") ".  "; counter-increment: item; }

I see at least three possible issues which make this more difficult than it should be:

[1] Spotty support for CSS counters. In particular, I don't know if much of this works in some common ebook reading systems.
[2] Many people have very little experience working with CSS counters, as well as pseudo-elements.
[3] The cascade gets tricky.


I don’t think this use case starts with the CSS group. It should start with the HTML group where the markup can be modeled effectively. UA’s can then use browser default CSS to support the markup.

You mentioned above that it might be OK for an outline list to be marked up as ol with a special type attribute. Does that make this a case where the problem isn't so much that HTML needs a new list structure, but that HTML needs a better/more standard mechanism for adding semantic information to existing markup?


However the HTML group decides to go, there should be markup treated by the UA such that individual list items are always marked with a concatenation of their own marker + all ancestors’ markers in the UA with no extra CSS necessary on the part of the author.

I see CSS as the way that authors control what they want to see. In a regular outline list, you don't want those markers concatenated.

It looks like the CSS counter styles spec may make all of this much easier (http://dev.w3.org/csswg/css-counter-styles-3/). It would be interesting to see if this could help with the use cases that will come out of this group.

Regards,

Dave


I can go work on the wording of the use case to clarify this.

Please let me know any further questions/comments.

Thanks,
Jean

From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Date: Tuesday, December 17, 2013 at 3:26 AM
To: Jean Kaplansky <jean.kaplansky@aptaracorp.com<mailto:jean.kaplansky@aptaracorp.com>>
Cc: DPUB <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>, Bert Bos <bert@w3.org<mailto:bert@w3.org>>
Subject: Re: [Styling and Layout] new use case added: Lists, Outline Lists

Jean,

I would need a clarification.

When using CSS, there is a fairly well working 'idiom' to build hierarchical numbering of list elements. A nice example I found is:

http://jsfiddle.net/qGCUk/4/

But I presume you guys know that:-)

Do I understand it well that what the requirement is is to be able to define that declaratively, without the necessity to build the CSS structure as above? First of all, I believe the use case should emphasize this, because the current text suggests that this is not possible with CSS (which is not true). Also... I think we will have a hard time convincing the CSS folks about the validity of that specific requirement when a mechanism already exists and is well established (I cc Bert explicitly to draw his attention:-), ie, we would need some stronger arguments.

Ivan


On 17 Dec 2013, at 01:37 , Jean Kaplansky <Jean.Kaplansky@aptaracorp.com<mailto:Jean.Kaplansky@aptaracorp.com>> wrote:

http://www.w3.org/dpub/IG/wiki/UseCase_Directory#Lists
Goes to
http://www.w3.org/dpub/IG/wiki/Lists
Where I have added a use case for Outline Lists that Tzviya and I discussed last week. It occurred to us that only the most rudimentary outline lists are currently supported in HTML5 with UA defaults and CSS. We can certainly use CSS to imply more specific outlining scenarios, but publishers, especially STM and legal publishers, often distinguish between regular ordered lists and highly specific outlines. For example, many hierarchical outline concatenate list item numbers based on point in hierarchy, so you could have  list with items 1.1, 1.2, 1.3, or 1.a, 1.b, 1.c. Right now, there’s no OOTB way to do this in HTML5 without building custom CSS to imply the hierarchy.
Please let Tzviya or I know any questions about this use case.
Thanks,
Jean Kaplansky
Digital Content Solutions Architect, Aptara
Invited Expert Member  l  W3C Digital Publishing Interest Group
Task Force Lead  l  W3C Digital Publishing MathML/STM Interest Group
Member  l  IDPF Indexing and Open Annotations EDUPUB Working Groups,
BISG Content Structure Committee, STC, and SSP
jean.kaplansky@aptaracorp.com<mailto:jean.kaplansky@aptaracorp.com>
+1.518.487.9670
Skype: JeanKaplansky
Twitter: @JeanKaplansky
<04503480-0856-4E40-B984-E9E64C468C2E[105].png>


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
GPG: 0x343F1A3D
FOAF: http://www.ivan-herman.net/foaf







________________________________
This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
Received on Tuesday, 17 December 2013 15:28:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:18 UTC