Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#371 Extend the enumerated values for list/@type

AMBER
closed-rejected
1(low)
2013-11-12
2012-07-26
John P. McCaskey
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.

Discussion

1 2 > >> (Page 1 of 2)
  • Martin Holmes
    Martin Holmes
    2012-07-26

    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.

     
  • Lou Burnard
    Lou Burnard
    2012-09-16

    • milestone: --> 871209
     
  • Lou Burnard
    Lou Burnard
    2012-09-16

    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.

     
  • Lou Burnard
    Lou Burnard
    2012-09-21

    • assigned_to: nobody --> pfschaffner
     
  • James Cummings
    James Cummings
    2012-09-21

    Council (Oxford, 2012-09) rejects adding these to @type but will provide examples of doing so with @rend. assigned to pfschaffner

     
  • James Cummings
    James Cummings
    2012-09-21

    • milestone: 871209 --> 871208
    • status: open --> open-rejected
     
  • Kevin Hawkins
    Kevin Hawkins
    2012-09-21

    • milestone: 871208 --> AMBER
    • assigned_to: pfschaffner --> nobody
    • status: open-rejected --> open
     
1 2 > >> (Page 1 of 2)