reintroduce model/@class

[tuurma]

to specify persistent and human/designer-friendly class names to be passed through to the output

[lb42]

This is a bit gnomic. Can you expound?

[tuurma]

sure, in the early versions we actually did have @Class to be used for the purpose of specifying css class name, with the intention that designer can specify necessary styling in static css. Later we dropped the idea afair without any real thought, on the assumption that generated class names can be used to the same purpose. Which is true, in a way, but leads to recurring trouble in real-life application, as additions to the odd trigger renumbering of generated class names, so designer has hard time to keep up. Not to mention that in numerous cases it just leads to redundant css classes, that are exact copies apart for their names.

[lb42]

So this is more or less exactly the same as @rendition ?

[tuurma]

Yes, but done properly :)

[lb42]

I am resisting the temptation to ask what is improper about the current @rendition : the point is that we don't want to invent a new attribute if there's already one that does the job

[tuurma]

Sorry, I mean done in a neater way than our current outputRendition stuff. I have no quarrel wih @rendition itself.

[wolfgangmm]

To support this request: from a workflow point of view, a web developer would usually start with a mockup and create the CSS before plugging in TEI. So there will be CSS classes defined already and you would expect the output of the TEI-HTML transformation to respect them and not vice versa. Just imagine you have to tell your designer to adjust all his neatly organised stuff to the arbitrary, non-telling class names produced by the PM.

Also, in a real-world app you'll have a mix of static and dynamic content, and you want to reuse your classes for both in a consistent way.

[lb42]

I understand and support the use case: I'm just quibbling about the name of the attribute. We do have a global attribute @rendition which can be used to specify how the content of content-bearing elements should be formatted: I just wonder if we could repurpose this on <model> to do what you want. But if not, can we have a more explicit attribute name: @cssClass for example.

[martindholmes]

@rendition is one-or-more pointers; it would be rather abusive to store CSS class names in it unless there were some kind of private URI scheme or convention such as css:className.
I agree that @cssClass is much more explicit, especially in the context of ODD where "class" has other meanings.

[tuurma]

For the sake of discussion: We could actually point to rendition entry in the header to store the css that reflects actual editorial decision (following the editor/designer separation of concerns), which would fit nicely with the documentary purpose of the odd and would fit with @rendition's content model. @cssClass is self-explanatory though and doesn't force editors to do anything more.

[lb42]

Ah, but if you use @rendition like that on <model>, then strictly speaking you are talking about how the model element should be rendered, not the things that use it. So probably better stick with the idea of a separate new attribute @cssClass

[martindholmes]

Remember @rendition and the <rendition> element are intended to describe the appearance of the original source text -- we say that explicitly in the Guidelines, and we've always made a big deal about it. We can't now start repurposing that mechanism for describing what we want the output to look like.

[lb42]

Agreed. I just wanted to get clarity on what this proposed new attribute was for.

[tuurma]

Are we in agreement then and shall we proceed and add @cssClass?

[lb42]

I am not sure. Why is this not an attribute on (or content of) <outputRendition> ?

Why not, for example, use @n on <outputRendition> ? It's meant to "supply a name or number" for the element content, which is surely what we are doing here?