#520 @selector attribute for the `<rendition>` element

[Martin Holmes]

The combination of <rendition> and @rendition currently allows us to link specific elements with blocks of style code (almost always CSS) in the manner of the HTML @class attribute, and @style allows the direct application of CSS to a specific element. What we cannot currently do is specify a default rendition for an element or a set of elements, except through the use of <tagUsage>/@render; this is crude in allowing only the linking of style blocks with unqualified elements, and it also brings in the requirement that every element used be provided with a matching <tagUsage> element.

I would argue that a better approach would be a new attribute called @selector available on the <rendition> element, through the att.styleDef class. Its definition would be:

A selector or series of selectors specifying the elements to which the contained style description applies, expressed in the language specified in the @scheme attribute.

This would allow simple definitions like the following:

<rendition 
   scheme="css" 
   selector="text front back body div p ab">
      display: block;
</rendition>

making this a straighforward way in which to express a basic mapping between TEI elements and their default styles. It would of course allow much more sophisticated mapping, including for instance the use of @rend:

<rendition 
   scheme="css" 
   selector="*[rend*=italic]">
      font-style: italic;
</rendition>

and would make it easy to express different default rules for the same element in different contexts:

<rendition 
   scheme="css" 
   selector="front p, back p">
      margin-top: 0.5em;
</rendition>

<rendition 
   scheme="css" 
   selector="body p">
      margin-top: 0;
</rendition>

This could be made even more powerful and sophisticated by the addition of a second attribute, @selectorScheme, which would allow the use of another selector language such as XPath in place of the one specified in @scheme:

<rendition 
   scheme="css" 
   selectorScheme="xpath" 
   selector="p[string-length(.) gt 30][preceding-sibling::p]">
      text-indent: 0.5em;
</rendition>

In this case, the definition would be amended to say:

A selector or series of selectors specifying the elements to which the contained style description applies, expressed in the language specified in the @selectorScheme attribute, or, where this attribute is missing, in the language specified in the @scheme attribute.

Implementation of this feature request (in both variants, with or without #selectorScheme) would obviate the need for the existing @scope attribute, since its functionality is available as part of CSS selectors, and of the <tagUsage>/@render attribute, but it would provide a simpler and better way of doing what these attributes currently partially and inadequately do.

[James Cummings]

At Raleigh F2F Council agrees to make green and assigns to MartinH to investigate, report, and get council consensus concerning the problems with tagUsage/@render and priority.

[Lou Burnard]

We need to decide how to resolve potential conflict with use of @render

[Martin Holmes]

Three proposals need to developed as fully as possible to enable them to be compared:

1. The proposal as shown above (minus the xpath bit, which should be a separate ticket later).

2. Syd's proposal for a standoff element (renditionAssignment?) which has @match, @target and @render, the latter pointing to a two or more rendition elements. In this option, renditionAssignment would be implemented as a sibling of the rendition element.

3. The same as above, except that the element is a sibling of tagUsage, where it's a child of namespace and therefore applies only to elements in the namespace ancestor.

[James Cummings]

(actually leaving amber until MH reports)

[Martin Holmes]

I'm going to propose setting this ticket to red for the moment, not because I think it's a bad idea, but because I think it would overlap with the functionality of the Processing Model being developed as part of TEI simple. If the proposed PM is fully developed and integrated into P5, and covers the needs that gave rise to this ticket, it could be closed in due course.

[James Cummings]

Agreed. I think you should be able to do this with the processing model documentation. And indeed, this shows that we have existing use cases for it.

[Martin Holmes]

The only second thought I have is the slight worry that the PM is not strictly about describing the appearance of the source text, whereas <rendition> is.

[Martin Holmes]

Based on discussion on the Simple list today, I've changed my mind about this; the Simple PM is aimed purely at rendering, not at describing the source, so I think we need this.

[Sebastian Rahtz]

You know what I am going to say, don't you? that the use of selectoryScheme=xpath makes this much harder to implement. IMHO. What we had before, or with the addition of @selector, makes it relatively trivial to process. Yes, we shouldn't care about implementation in general, but I'd suggest that in this are you should do some proof of concept code to prove its possible. Otherwise its just old-style TEI wishful thinking.

[Martin Holmes]

Actually I agree with you. @selector alone (using CSS selectors) would make such a substantial improvement to expressibility that I think we should go with that for now and worry about more complicated stuff once we see how it pans out.

And CSS selectors are a lot more powerful than they used to be anyway. I'll propose we go with the simpler option at the FtF.

[Martin Holmes]

I've posted a formal proposal for Council to consider here:

http://wiki.tei-c.org/index.php/Proposal_for_@selector_attribute_on_rendition

[Original filename/title changed 2015-05-30 because a slash in the title made linking awkward.]

[Martin Holmes]

Implemented in rev 13264 and tweaked in 13266.

[Martin Holmes]

This is implemented. There is more work to do in the Stylesheets, but that presumably needs its own ticket.