[tei-council] Should Roma be doing this?

[Syd Bauman]

[Continuing old thread ...]

I think Martin has hit a nail on the head, here, and that the idea of
separating out the renditional semantics of list/@type into our trio
of renditional attrs is a good one. As for leaving @type to mean "of"
the same way we do with name/@type is worth discussion.

But to re-iterate the point about "ordered": I think of it as a type
(although not an "of" type), not a rendition. To explain -- all lists
are inherintly ordered, but for some the order matters (sequence of
steps to remove a HDD from a laptop), and others it does not (typical
shopping list). Either might have labels that are numbers; either
might not. Perhaps a better value would be "toBeTakenInSequence".

> >> I think the core problem here is that we've been using @type on
> >> <list> for all these years when we should have been using @rend.
> >
> > yes and no. I can't shake my conviction that every _modern_ system
> > does make that fundamental distinction between the ordered and
> > unordered list. Yes of course we are about transcribing what we
> > see, but those modern things didnt appear from nowhere.
> 
> But the same thing applies to italics, or drop-caps, doesn't it? As
> Syd says, lists are ordered and can't be otherwise; the issue is
> whether they're explicitly numbered, and that's a typographical
> rendition issue. I think the unfortunate issue of HTML ul/ol versus
> the CSS that should do the job (list-style-type), but which only came
> later, has confused our thinking on this. If there were a true
> difference in type, wouldn't TEI have created two separate elements?
> 
> >> Doesn't this
> >> sound more sane?
> >>
> >> @rend="bulleted"
> >> @rend="numbered"
> >> @rend="simple"
> > well, sort of. I've always disliked the over-specific "bulleted",
> > and I've never understood "simple" but I accept thats my problem
> > :-{
> 
> At least "bulleted" is a clear description of the rendering of the
> list.
> 
> >> The only value of @type that really looks like a type to me is
> >> "gloss", but this is used, as far as I understand it, when there
> >> is a <label> preceding the <item>, and in that case the presence
> >> of <label> is sufficient to determine the output appearance.
> > yes, thats true. if there are label children, its a gloss list.
> >>
> >> So I would recommend:
> >>
> >> 1. Changing our recommendation so that we provide suggested values
> >> for @rend, not @type.
> >
> > ok, I suppose
> >
> >> 2. Adding a suggestion that using @style with CSS will provide a
> >> useful range of precise options that cover most cases.
> >>
> > or better, @rendition, in fact. @rendition="#romannumbered" is a
> > more useful scenario
> 
> How about <list style="list-style-type:upper-roman;">?
> 
> >> 3. Leaving @type on <list>, for backward compatibility, but
> >> providing no suggested values for it.
> > not suggested values, but with an example? can we think of one?
> 
> <list type="instructions">
> 
> <list type="recipe">
> 
> <list type="shopping">
> 
> These are all actual types of list; any of them might be rendered
> with bullets or numbers, without changing their type.
> 
> >> This will cause Sebastian considerable stylesheet-related pain, I
> >> know, so apologies for that.
> >
> >
> > yes, I haven't the faintest idea how to know whether to make <ul>
> > or <ol>.
> 
> Yes, damn it, that's the heart of the problem. HTML was wrong to have
> two separate tags. But if you create a <ul> and make it
> list-style-type: upper-roman, you'll get roman numerals, and if you
> give an <ol> list-style-type: disc, you'll get a bulleted list. If we
> believe that all lists are inherently ordered, we could just use <ol>
> in the output and let CSS do the styling.
> 
> > I suggest that this is such a big bucket of worms that it needs
> > public discussion. @type on <list> seems so well established in
> > both instances and tools that I can't help feeling we may provoke
> > howls of protest across the seven seas.
> 
> Indeed. But we don't have to break backwards compatibility; you could
> still detect the old values in the stylesheets and retain the old
> behaviour.