Menu
▾
▴
#460 list/@type="unordered" is not recommended, but used often
closed-fixed
9(high)
2014-08-31
2012-10-25
No
The definition of list/@type suggests these values:
ordered
list items are numbered or lettered.
bulleted
list items are marked with a bullet or other typographic device.
simple
list items are not numbered or bulleted. [Default]
gloss
each list item glosses some term or concept, which is given by a label element preceding the list item.
However, the stylesheets are peppered with uses of "unordered" (which used to be in there, but is not any more). These should be replaced with "bulleted", presumably.
an attDef mode="change", that is :-}
fair enough. "ingredients", "dramatis_personae", "syllogism" (I borrow from EEBO)
--
Sebastian Rahtz
Director (Research) of Academic IT
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
Last edit: Kevin Hawkins 2013-04-25
Won't
<list type="dramatis_personae">collide with<castList>?Of "ordered," "numbered," and "sequenced," I think "ordered" is the most apt. It seems to me irrelevant whether some specialized domain attaches a restricted meaning to a term (and I'm not convinced, anyway, that "formal linguistics" has a consensus opinion about the nature of lists). Besides the problem with "numbered" that Lou anticipates (that the "numbers" sometimes aren't), it re-introduces rendition into the issue of typology. It's easy enough to think of lists whose items aren't marked by letters, numbers, or anything else but are still ordered. And a good case could be made that lots of lists aren't ordered--my shopping list, for example. "Sequenced" strikes me as just a synonym for "ordered."
One consideration here is minimizing the impact on users. Many will have to consider switching their use of @type to @rend; if we can't agree on what to call what-used-to-be-ordered, shouldn't we just stick with what we have, and minimize the burden?
On 23 Apr 2013, at 22:32, Martin Holmes martindholmes@users.sf.net
wrote:
true. bit misleading.
Sebastian Rahtz
Director (Research) of Academic IT
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
Last edit: Kevin Hawkins 2013-04-25
I don't agree with Martin that we should keep changes to a minimum. While we are disrupting things for our users, we might as well take the opportunity to rectify anything else that needs rectifying.
Still, I agree with Brett that "ordered" is intuitive for most people that we need not be concerned about the restricted meaning of "ordered list" in computer science and possibly formal linguistics.
For @rend, I would actually prefer if we dropped "ordered" as a suggested value and included "decimal", "lower-roman", and "upper-roman" (or something similar) as some sample values. To me, @rend should more precisely describe rendering in a source document than simply "ordered" (or "sequential"). Even though we are trying to differentiate between @type and @rend, giving something like "ordered" as a sample value continues to blur the distinction because, in my mind at least, there is a strong semantic difference between an ordered and unordered list. If I were composing a document in TEI, in many cases I would happily use @type='ordered' and @type='unordered' to control whether the list should be rendered with some sort of numbering/letter or some sort of bullets. Therefore, I suggest giving the following sample values for @type:
ordered
unordered
gloss
ingredients
syllogism
That will get people started down the path of imagining their own typology of lists.
Surely we just had this discussion at the Council meeting, and decided that "ordered" and "unordered" are not types of list; they relate to rendering. If you want to get into the types of numbering, the way to do it is surely with @style and all the list-style-type values. Lists are inherently ordered, and cannot be otherwise; the distinction between "ordered" and "unordered" which we share with HTML's ul vs ol elements is actually a distinction between numbered-in-some-way and bulleted-in-some-way; and those are rendering things, albeit not very precise.
Okay, right, the discussion at Council is coming back to me. Sorry for not reviewing the minutes before responding.
If Council decided that lists are inherently ordered and can't be otherwise (I see where that comes from and partly agree, though I still like the idea of an unordered list), then I retract my previous comment except for the following parts ...
I don't agree with Martin that we should keep changes to a minimum. While we are disrupting things for our users, we might as well take the opportunity to rectify anything else that needs rectifying.
Still, I agree with Brett that "ordered" is intuitive for most people that we need not be concerned about the restricted meaning of "ordered list" in computer science and possibly formal linguistics.
What remains to be done on this ticket?
examples all changed @rend to @type, I believe, and the stylesheets supported that. I'd suggest we close this until it comes up again.
Both @rend and @type are still in use in the Glines, and the values "ordered" and "simple" are both used. We even have
<list rend="runon" type="ordered">. I think I should do a quick audit of what we're actually doing now, and compare it with what we're advising, then we can decide whether it's worth taking any action or not.Analysis of usage of list/@type and list/@rend in the Guidelines:
Our suggested values for list/@type are:
ordered, bulleted, simple, gloss
In Guidelines prose, we use:
list type="gloss": 59
list type="simple": 107
list type="ordered": 32
list rend="simple": 4
list rend="ordered": 4
list rend="specList": 1
In examples:
list type="ordered": 19
list type="gloss": 25
list type="speakers": 8
list type="simple": 8
list type="bullets": 3
list type="unordered": 2
list type="index": 2
list type="attendance": 2
list type="參與者": 1
list type="inline": 1
list type="indexentry": 1
list type="encoders": 3
list type="編碼員": 1
list rend="runon": 5
Brief analysis and recommendations sent to Council list 2013-12-20.
A wiki page with a set of recommendations and plans for implementation is being developed here:
http://wiki.tei-c.org/index.php/List_types_and_rendering
Council (2014-06-30) decides this is release blocking. Martin and Syd to carry it out. All of council to read the wiki page and feedback to M & S within a week.
In several commits up to 12952, the following changes have been made:
This means the ticket is basically complete, but Syd has been tasked by the Council teleconference of 2014-08-01 to read the relevant Guidelines prose section (3.7) and perhaps strengthen the recommendation to use @rendition or @style rather than @rend. We need to strike a balance between providing an easy update path (@rend) for people who were used to using @type, and recommending a better approach (@rendition/@style) which requires more knowledge (
<rendition>and CSS).Last edit: Martin Holmes 2014-08-01
I wonder whether we should have another 'type' of list provided of 'simple' or something. Or is that just stating the obvious when it is just a basic list of items.
list="inline" ?
for things like "my favourite fruit are apples, oranges, and bananas"
No, 'inline' is a form of rendition. I might equally render that as:
"My favourite fruit are
- apples,
- oranges,
- and bananas
but really blueberries are better than all of those."
list/@type="simple" suggests to me that it's a list of simple things. We already have @rend="simple" (no markers, numbers etc.).
It's easy to think of different types of list, but there's no imaginable justification for selecting some of them from the possible millions and making them suggested values; the only reason "gloss" is in there is that it involves a very specific and complicated use of list markup, with implications for other elements used, which is exemplified at length in the Guidelines.
I tend to agree with Martin, but I do think that the "my favourite fruit" kind of list is a different kind, not because of its formatting, but because of its status with respect to the text around it. Maybe "runon" or "embedded" would be better names. (I claim that James's version would be @type="runon" rend="bulleted")
We can't, surely, have @type used simultaneously, in the same suggested valList, to characterize what sort of things are in the list (glosses) and what sort of appearance the list has (runon/inline). That's the source of all these problems in the first place. I don't see the difference between inline and runon, myself, but if there is one, there's nothing to prevent users from characterizing it through either @type or @rend or both; but I want to avoid recommending or exemplifying any usage which is confusingly borderline like this. Let's keep it clean.
Following suggestions from Paul, I've now added "index", "instructions", "litany" and "syllogism" to the suggested value list for list/@type, along with a couple of examples from his post. I think this provides a more helpful set of examples from which it's much clearer what the purpose of @type is, in contrast with @rend.
Following Council discussions, I've removed the override of @rend from the list.xml spec. We will stick with suggestions in the prose chapter. I think this ticket is now done.