On 1/7/2012 5:14 PM, Martin Holmes wrote:
> That's another strong argument for the use of CSS in @rend. We know
> what CSS means, and how it cascades.

Thereby binding TEI (further) to W3C-specified technologies and to tools
that implement them?

I'm not saying I'm against it. It's just that, as an old religionist,
I'm nervous about any canonical binding of that sort. There is also much
that CSS doesn't do. (And as to "know[ing] what CSS means, au contraire.
It's specified more completely than TEI @rend, but it's not watertight

This thread is a beautiful illustration of what I talked about in my
2009 paper, "How to Play XML: Markup Technologies as Nomic Game". The 
players stand in the middle of the field and negotiate the rules.

My own answer is "a sub- or superscript property inherits, compounding
with instead of replacing any nesting sub- or superscripts" (much as it
does in CSS, XSL-FO, or, say, MathML). But this is pragmatic, and I also
agree this is a nice example of both how @rend is underspecified (since
all the possible values are not specified nor are their relationships)
-- a good thing, TMM -- and how vexed is the question of the inheritance
of properties via element containment.

So if someone meant it to be otherwise I might consider it surprising
and potentially problematic (if considering interchange with a system I
implemented) without considering it "wrong".

(As for OpenOffice, I've run into its failure to respect this sort of 
inheritance in the past, and find it to be, if not wrong -- they make 
the rules to their own game -- at least terribly unfortunate and 

Sebastian adds:
> I think if I were starting an encoding project now, I'd avoid using
> @rend entirely and only allow @rendition. Poor @rend seems so
> inadequately specified, and so variably used, that it adds rather
> little to the encoding...

I have a great deal of sympathy with this. If I were trying to maintain 
TEI stylesheets for the world (which I categorically and definitively am 
not, being on record as feeling that such a resource is not an 
unmitigated good), I'd be tempted to say that @rend is for local 
projects, and nothing it says is warranted to interchange well.

But this is different from casting the idea of ad hoc description of 
rendition, without using CSS, into the outer darkness.


Wendell Piez                            mailto:[log in to unmask]
Mulberry Technologies, Inc.      
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
   Mulberry Technologies: A Consultancy Specializing in SGML and XML