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?

[tuurma]

First argument that comes to mind against <outputRendition> is there may co-exist a number of those in a model. There's no clear hierarchy between them and no other wrapper than <model> for them.
Eg.

<elementSpec mode="change" ident="corr">
            <model behaviour="inline">
                        <outputRendition scope="before">content: '[';</outputRendition>
                        <outputRendition scope="after">content: ']';</outputRendition>
            </model>
</elementSpec>

[lb42]

But surely in that case the before-ing and after-ing would both be handled in the CSS? so you wouldn't want to do it like that anyway?

<model behaviour="inline">
   <outputRendition n="bracketted"/>
   <!-- CSS class "bracketted" puts brackets before and after the content -->
</model>

[tuurma]

Depends how you think about it: should everything that can be done in CSS be done in CSS? No point in having outputRendition at all then. Yet we do, and I believe the intention was to provide a place to specify and document high level editorial decisions about the output. And statement that corrections are to be displayed in [] is clearly such a decision, hence this outputRendition case has made it into teisimple.odd

[lb42]

Exactly: it depends on where you have decided to draw the line between what's done in the CSS and what's done in the ODD. If you decided to document the bracketting in the ODD, you don't want to refer to the CSS class; if you decided to do it in the CSS, then your ODD needs to refer to that. Not both, or you make it possible for them to contradict each other.

[tuurma]

If you decided to document the bracketting in the ODD, you don't want to refer to the CSS class

This doesn't necessarily follow. I agree that line between what is an editorial decision (to be documented in the odd) an design one (to be provided via external css) is somewhat blurry, but there is no reason why certain element shouldn't be subject to both editorial decisions (like putting stuff in brackets) and design ones (like making it flamboyant red by mad designer). So yes, it is perfectly possible to want both outputRendition and css class at the same time.

We already mention the process of merging outputRendition with @useSourceRendition in the prose, which also can introduce conflicts. I don't see why we should worry about it here?

[lb42]

So, if I'm understanding correctly, the following is (more or less) what we/you want:

"The intended output to be generated for a particular behaviour of a processing model may be documented in one or all of the three following ways. Firstly, the @CSSclass attribute may be used to specify the name of a CSS style in some associated CSS stylesheet which is to be applied to each occurrence of a specified element found (in a given context, for a specified output). Secondly, the attribute @useSourceRendition may be used to indicate that the default rendition for occurrences of this element, as defined by a <rendition> element in the document header, should be applied. Thirdly, the styling to be applied may be specified explicitly as content of a child <outputRendition> element.

When more than one of these options is used, they are understood to be combined in accordance with the rules for multiple declaration of the styling language used. "

For consistency, maybe we should add a @Predicate attribute to <rendition> ? But that's another ticket.

[tuurma]

Your wording sums it up nicely indeed, thanks. One suggestion though

Firstly, the @CSSclass attribute may be used to specify the name of a CSS style in some associated CSS stylesheet which is to be applied to each occurrence of a specified element found (in a given context, for a specified output).

to be rewritten as

Firstly, the @CSSclass attribute may be used to specify the name of a CSS style in some associated CSS stylesheet which is to be applied to each occurrence of a specified element matched by current <model>.

@Predicate on <outputRendition> you mean I guess? As a child of <model> it inherits predicate already, doesn't it?

[lb42]

Not sure that I like your revision, because it's not clear what "matched by" means (a <model> isn't really a pattern is it?). My phrase is intended to make clear that we're talking about a specific context for a specific output, as specified on a <model>

And no, I did mean <rendition>. But looking at it again, probably <tagUsage would be more appropriate.

[tuurma]

specific context for a specific output, as specified on a <model>

if you could add these last few words then? Mentioning model explicitly sounds clearer, I think.

I have to admit I don't get rendition/tagUsage business but happy to be englightened on a separate ticket :)

[tuurma]

Firstly, the @CSSclass attribute may be used to specify the name of a CSS style in some associated CSS stylesheet which is to be applied to each occurrence of the element specified found in a context and for an output as specified via @Predicate and @output attributes of a <model>.

Would that be acceptable wording?