[tei-council] list types and rends: bug 460

[Martin Holmes]

As I work on the wiki page for this  work, I've been looking at the 
Guidelines prose for Chapter 3.7:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COLI>

and there are some rather nasty-looking survivals from P4 here. For 
instance, the prose recommends that:

"If however an enumerator is retained in the encoded text, it may be 
supplied either by using the n attribute on the item element, or by 
using a label element."

It provides examples of the former, like this:

<list rend="runon" type="ordered">
  <item n="1">My first rough manuscript, without any
    intermediate copy, has been sent to the press.</item>
  <item n="2">Not a sheet has been seen by any human
    eyes, excepting those of the author and the printer:
    the faults and the merits are exclusively my own.</item>
</list>

where the numbers in the @n attribute are transcribed from the text. 
This seems to me egregious: transcribed text should never be in 
attribute values.

Do you agree?

My developing wiki page is here:

<http://wiki.tei-c.org/index.php/List_types_and_rendering>

and it should be ready for discussion at the next telco.

Cheers,
Martin

On 13-12-22 07:19 AM, Martin Holmes wrote:
> I take your point about the value "numbered", although a), b) c) is just
> a kind of numbering really (if it were labelling, then the order of the
> letters wouldn't matter).
>
> On the point that the rest of the world uses the "ordered" vs
> "unordered" distinction, outside of HTML (which I think got this wrong,
> although the decision was made before CSS existed), what other standards
> use those terms? XSL:FO doesn't (it relies on fo:list-item-label, which
> can be a bullet or a number). ODF (on which I'm no expert, so correct me
> if I'm wrong) uses text:list-level-style-number> alongside
> text:list-level-style-bullet>.
>
> On balance, I still prefer "numbered", but another possibility would be
> "enumerated" -- is that actually different, and if it is, would it be
> better?
>
> I'm going to turn this into a formal proposal on the wiki; it's
> obviously not going into the next release, because the stylesheets
> obviously have to be ready at the same time as the Glines changes.
>
> On the question of handling old values in the Stylesheets, I think we
> have to, at least for a while; people will scream instantly if @type
> values we've been recommending for many years suddenly don't work
> properly with a new release of the Stylesheets. This brings up the
> possibility of deprecation in the Stylesheets, of course.
>
> Cheers,
> Martin
>
> On 13-12-21 09:49 AM, Sebastian Rahtz wrote:
>>
>> On 20 Dec 2013, at 19:54, Martin Holmes <mholmes at uvic.ca> wrote:
>>> 	Recommendation:
>>>
>>> 	Leave "gloss" as a suggested value for @type.
>>>
>> yes. for all its weirdness.
>>
>>> ..
>>
>>> 	Recommendations:
>>>
>>> 	Remove "simple" as a suggested value from @type, and make it a
>>> suggested value on @rend.
>>> 	Render it as list-style-type="none" (i.e. no bullets), so that it has a
>>> function distinct from "bulleted".
>>> 	Change usage in the Guidelines prose to rend="bulleted" where we
>>> actually intend bullets.
>>> 	Change examples of @type="simple" to @rend="simple”.
>>
>> Agreed. because people who have been using @type=“simple” for years
>> to mean “unordered” can carry right on doing so. If Stylesheets doesn’t
>> do what they expect, they never had any guarantees from there.
>>
>>>
>>> "ordered": As we have discussed on the ticket and in meetings, "ordered"
>>> and "unordered" are really meaningless; all lists are ordered and cannot
>>> be otherwise. Neither are they types of list
>> some danger here in flying in the face of the rest of the world, who
>> use <ul> and <ol> happily. In most cases one would expect things like
>> that to map to @type in TEI. But I accept your arguments
>>
>>> 	Recommendations:
>>>
>>> 	Remove "ordered" as a suggested value for @type.
>>> 	Add "numbered" as a suggested value for @rend.
>>
>> hmm. I am less happy about that.  if, for example, you
>> use a sequence like a), b). c), calling it “numbered” doesn’t
>> really fit the bill. I’d actually keep @rend=“ordered”, simply
>> cos the rest of the world does so.
>>
>>> 	Provide examples of the use of @style="list-style-type: [whatever]" to
>>> show the range of different numbering options available through @style
>>> with CSS.
>> fine
>>
>>> 	Change all instances of @type="ordered" in the Guidelines to
>>> @rend="numbered”.
>> not entirely happy
>>
>>> 	Update processing to render list[@rend="numbered"] as HTML <ol> (and
>>> PDF equivalent).
>>> 	Rewrite all examples of list[@type="ordered"] in the Guidelines, along
>>> with associated prose, to @rend="numbered" or to use @style.
>> ok
>>
>>>
>>> "bulleted"/"bullets": This is clearly a rendering feature, not a type of
>>> list.
>> again, “bullets” is very specific rendering. I have always disliked that.
>> I wish there was another word… But I think I can’t fight it.
>>>
>>> 	Recommendations:
>>> 	
>>> 	Remove "bulleted" as a suggested value for @type.
>>> 	Add "bulleted" as a suggested value for list/@rend.
>>> 	Change all examples using @type="bullets" to @rend="bulleted".
>>> 	Add processing for @rend="bulleted" to produce HTML <ul> and PDF
>>> equivalent.
>>> 	Add examples showing the use of @style with CSS for various bullet types.
>> agreed, with sadness
>>
>>>
>>> "specList": There is only a single example of this, in the FT chapter.
>>> It looks odd, and I think it might be a survival from a previous
>>> incarnation of the chapter, since it duplicates to some extent the
>>> <specList> directly above it (although it does provide more detail). It
>>> renders with no bullets or numbers.
>>>
>>> 	Recommendation:
>>>
>>> 	Look at the possibility of eliminating this bit of the Guidelines. If
>>> it is retained, re-encode it with @rend="simple”.
>> or @rend=‘specList’ presumably
>>
>>>
>>> "inline": This only appears in one example, but it is clearly a
>>> rendering feature (in CSS terms, it means "display: inline").
>>>
>>> 	Recommendations:
>>>
>>> 	Add "inline" as a suggested value for list/@rend.
>>> 	Add processing for @rend="inline" to create inline lists in HTML and PDF.
>> agreed
>>
>>>
>>> "runon": This appears in examples in
>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COLI>, in
>>> conjunction with @type="ordered". It appears to be doing the same job as
>>> "inline" above.
>>>
>>> 	Recommendations:
>>>
>>> 	Replace rend="runon" type="ordered" with rend="inline numbered".
>>> 	Update preceding prose to clarify what "inline" means here.
>>>
>> fair enough.
>>
>> I am in two minds as to whether the Stylesheets should support the old @type values as well
>> as the new recommended @rend values
>> --
>> Sebastian Rahtz
>> Director (Research) of Academic IT
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>