Menu
▾
▴
#371 Extend the enumerated values for list/@type
closed-rejected
1(low)
2013-11-12
2012-07-26
No
It's too bad that the suggested values for @type in <list> doesn't match CSS's list for list-style-type.
Consider extending the suggestions to include CSS's circle, disc, square, none, decimal, lower-latin, and so on.
The CSS values are (naturally) entirely presentational. I think we should be thinking more in terms of semantic categories, shouldn't we? Presentational decisions belong in the XSLT and CSS. (I appreciate that our "bulleted" value already looks a bit presentational, but that's always bothered me a bit. "ordered", "simple" and "gloss" are more semantic.)
surrely that mapping to presentation is what @rend is for?
I believed that type="bulletted" is just bad, and should be dropped from the guidelines ASAP.
Yep, @rend should be used. The existing mix of semantics and presentation misled me.
What about replacing the current list with "ordered", "unordered", "gloss" and "runon"? I can't think what "simple" would indicate. If there is one high-level semantic difference in lists, surely it is between those that are ordered and those that are unordered.
Examples in the Guidelines sometimes use @rend="runon", but "runon" does have semantic import. It says: This list is embedded in the grammatical structure of what surrounds it.
The difference between
<list type="ordered>
<head>First Presidents of the United States</head>
<item>Washington</item>
<item>Adams</item>
<item>Jefferson</item>
</list>
and
On those remote pages it is written that animals are divided into <list>
<item n="a">those that belong to the Emperor, </item>
<item n="b">embalmed ones, </item>
<item n="c">those that are trained, </item>
<item n="d">suckling pigs.</item></list>
is more than presentational.
Even my list (!) isn't orthogonal though. You could have an ordered or unordered glossary, ordered or unordered runon. So maybe there should be one attribute @ordered that just indicates "ordered" / "unordered", those being the only allowed values, one of them being the default; then another unconstrained attribute for type.
I see that other listLike elements make no mention of these types.
The trouble is that our @type values really are presentational. "ordered" doesn't mean (as it should) "you monkey with the order of these items at your peril" but rather "these items are all prefixed by some ordering label"; that's why "bulleted" is there. And "simple" does actually mean "runon". I like the idea of adding @ordered though.
louburnard writes: "And 'simple' does actually mean 'runon.'"
Really?
The one example given in 3.7 encodes what in the source was not a runon. There was a column with several items, each beginning on a new line, like what you'd get in HTML with <ul> and CSS of list-style-type:none
In 3.7, the example given of rend="runon" encodes a paragraph where the list items appeared in running prose, sentence after sentence. The type attribute was "ordered" and indeed in the source, the listed sentences were preceded by numbers.
Is it really the case that TEI's "@type values really are presentational"? It seems the current values are a mix of semantics and presentation but more semantics than presentation -- and should be 100% semantic.
I wonder: In say a header field where a <list> is a list of phone numbers, I might be comfortable saying the list is unordered. But if encoding a printed source, to mark a list as unordered would be to add interpretation. Those "simple" lists in the Guidelines encode Robinson Crusoe's lists of good and bad things about his situation. The lists were not numbered, but it would be an interpretation to say the author intended nothing significant by the order of presentation.
Council (Oxford, 2012-09) rejects adding these to @type but will provide examples of doing so with @rend. assigned to pfschaffner
A TEI Council subgroup decided that even though name of @type attribute sounds semantic and non-presentational, it is in fact widely used purely presentationally and defined that way, so we shouldn't scrap it because it will be massively disruptive. To clarify usage, though, we would introduce some examples using @rend and the new @style (pending http://purl.org/TEI/FR/3519866 ) to convey various ways of describing a labeling of list items (different types of bullets, roman numerals, arabic numerals).
Have made notes toward redoing lists in P6:
http://wiki.tei-c.org/index.php/P6-dev
I ended up doing this in CSS, in this order:
[display='list-item'][hasNumber] {list-style-type:none} /* the @n gets used instead */
[tei="list"] {list-style-type:square}
[tei="list"][type="ordered"] {list-style-type:decimal}
[tei="list"][type="bulleted"] {list-style-type:disc}
[tei="list"][type="simple"] {list-style-type:none}
[tei="list"][rend*="armenian"] {list-style-type:armenian}
[tei="list"][rend*="circle"] {list-style-type:circle}
[tei="list"][rend*="cjk-ideographic"] {list-style-type:cjk-ideographic}
[tei="list"][rend*="decimal"] {list-style-type:decimal}
[tei="list"][rend*="decimal-leading-zero"] {list-style-type:decimal-leading-zero}
[tei="list"][rend*="georgian"] {list-style-type:georgian}
[tei="list"][rend*="hebrew"] {list-style-type:hebrew}
[tei="list"][rend*="hiragana"] {list-style-type:hiragana}
[tei="list"][rend*="hiragana-iroha"] {list-style-type:hiragana-iroha}
[tei="list"][rend*="katakana"] {list-style-type:katakana}
[tei="list"][rend*="katakana-iroha"] {list-style-type:katakana-iroha}
[tei="list"][rend*="lower-alpha"] {list-style-type:lower-alpha}
[tei="list"][rend*="lower-greek"] {list-style-type:lower-greek}
[tei="list"][rend*="lower-latin"] {list-style-type:lower-latin}
[tei="list"][rend*="lower-roman"] {list-style-type:lower-roman}
[tei="list"][rend*="none"] {list-style-type:none}
[tei="list"][rend*="square"] {list-style-type:square}
[tei="list"][rend*="upper-alpha"] {list-style-type:upper-alpha}
[tei="list"][rend*="upper-latin"] {list-style-type:upper-latin}
[tei="list"][rend*="upper-roman"] {list-style-type:upper-roman}