CSS list types

[rbeezer]

I think I have a good handle on what I'd like us to use for "list types" in HTML.

Can we have classes as follows? Actual class names can be whatever makes sense. These new classes should have CSS that sets "list-style-type:" to one of the values below.

Maybe later we will want to adjust spacing above/below for all of these, when they occur as top-level/outermost lists, or maybe that is happening already.

On "ol" elements: decimal lower-alpha upper-alpha lower-roman upper-roman none

On "ul" elements: disc circle square none

[davidfarmer]

There is something I don't like about using a class to hold the value of what is already called "list-style-type".

What else might we do with a list that could require some styling? (That is, what types of "classes" of lists might we have?)

We can set a default style-type for a top-level list (presumably that will be "decimal", the same as the HTML default), and we can set a default style-type for a list-within-a-list, going down as many levels as we wish.

We can also have a list within an exercise have a different default style-type (presumably lower-alpha). Or we could have an ol with class="exercise" for a list within an exercise. That is more along the lines of how I would think of using a class for something more semantic than just setting the style-type.

Maybe a list in a theorem should also default to lower-alpha for the list-style-type? I'll look at some examples.

How many examples of lists do you have where a default style-type (once we choose what that is in various situations) would need to be overwritten?

On Sun, 12 Oct 2014, Rob Beezer wrote:

I think I have a good handle on what I'd like us to use for "list types" in HTML.

Can we have classes as follows? Actual class names can be whatever makes sense. These new classes should have CSS that sets "list-style-type:" to one of the values below.

Maybe later we will want to adjust spacing above/below for all of these, when they occur as top-level/outermost lists, or maybe that is happening already.

On "ol" elements: decimal lower-alpha upper-alpha lower-roman upper-roman none

On "ul" elements: disc circle square none

— Reply to this email directly or view it onGitHub.[211500__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyODc5Mjc5NSwiZGF0YSI6eyJpZCI6NDU1NzU4ODd9fQ==--2cf79baa9e4edd85c9193aae55c20ff5dc2ee d0b.gif]

[rbeezer]

I agree that it is a bit odd to use a class for this. Though I would prefer

li class="decimal"

to

li style="list-style-type: decimal"

I see this as a grey area for presentation vs semantics. And I thought we had agreed that we would let authors choose (A) versus -i-, etc. I do plan to let authors specify whatever numbering they want on lists, as overrides. And I find it increasingly hard to just go with setting defaults in LaTeX. Part of the problem is that "exercises" section are lists of exercises, though interupted by "exercisegroup"s. And I am allowing "references" sections anywhere, so as to support things like "Further Reading" in each chapter, and these are lists of bibitem-like items.

Anyway, here is a concrete problem. Suppose the default choices for numbering lists, as you nest them, is given by CSS rules. Now someplace you reference item A.iii.3. The HTML (maybe not the LaTeX) has to have the clickable had coded as A.iii.2. But if an alternative CSS is employed then it might choose to employ a different scheme for numbering the items, and then A.iii.2 will point to 1.C.ii.

To answer your question, I have and as the only unusual lists, though as you mention, I would like lists in theorem statements to behave predictably (discussion on mathbook-xml-support a few weeks back).

I have the option to hard-code an exercise number. I do not want to pull a busted problem and have all subsequent numbers change. So these are actually hard-coded in the HTML.

Short answer: this all gets very complicated and the more I work on it, the more I am leaning to being a bit more expedient than usual and hard-coding more of the labels, especially on the HTML side.

[davidfarmer]

Lists seem to look fine now.