Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#430 @render only implemented for some elements

closed-fixed
5
2012-10-21
2012-08-19
Lou Burnard
No

Setting a CSS property for <persName> inside <p> by means of the @render attribute on the appropriate <tagsDecl> works for the <p> but not for the <persName> . It does however work for a <date>, as reported by Peter MacDonald on TEI-L on 2012-08-17

Discussion

  • Lou Burnard
    Lou Burnard
    2012-08-19

    User's test file

     
    Attachments
  • I am working on a completely new implementation of @rend, @rendition, tagsDecl/@render,
    and (soon) @style, but it will take me a while. I am pondering how to do it consistently. Considering a pre-processor.

     
  • Lou Burnard
    Lou Burnard
    2012-10-05

    It would be nice if there were *something* in place when @style is added. Otherwise it all looks remarkably silly.

     
  • if you are volunteering to make a test document exhibiting a wide range of pathological behaviour covering all the available methods, I accept with much gratitude

     
  • Martin Holmes
    Martin Holmes
    2012-10-05

    I've just been looking through all this stuff again, and the Guidelines truly are confusing. It really isn't clear whether <rendition> is intended to contain information about how something looks in the original text or how it's supposed to be rendered in some output process. When @render is pointing at a <rendition>, it seems like the latter:

    "@render specifies the identifier of a rendition element which defines how this element is to be rendered."

    But when @rendition points to a <rendition>, it's the former:

    "@rendition points to a description of the rendering or presentation used for this element in the source text."

    And we have reinforced this with a note:

    "The rendition attribute is used in a very similar way to the class attribute defined for XHTML but with the important distinction that its function is to describe the appearance of the source text, not necessarily to determine how that text should be presented on screen or paper."

    It's not unreasonable to say that <rendition> itself is neutral with regard to its usage -- if it's pointed to by @render, it's meant for output instructions, but if it's pointed to by @rendition it contains a description of the original source -- but if so, I think we should be more explicit about that in the definition of <rendition>, which currently has this:

    "The present release of these Guidelines does not specify the content of this element in any further detail. It may be used to hold a description of the default rendition to be associated with the specified element, expressed in running prose, or in some more formal language such as CSS."

    Ideally, though, we should separate elements and attributes describing the original appearance of the text completely from those which contain rendering instructions for a processor, shouldn't we? This is assuming they're different, of course; in my own projects I use <rendition> (and abuse <rend>) to describe the original appearance of the text, but then use the CSS directly in the output to render it as well.

     
  • Lou Burnard
    Lou Burnard
    2012-10-05

    Agreed that the definition for @render is wrong, or at least inconsistent with the others. That should probably be on a different ticket though.

     
  • I can see a case for saying that @render is prescriptive, and the others descriptive. from a rendering point of view, it would imply that @render overrides the others. If the original is in italic, as noted by @rend or whatever, tagsUsage/@render may say that bold is to be used instead.

    I guess its more likely that the founding fathers didnt intend @render to be prescriptive, though.

     
  • Lou Burnard
    Lou Burnard
    2012-10-05

    Except that that isn't how it works. @render supplies the default styling info for an element, and @rendition over-rides that on given instances. Styling info always relates to the source. We have repeatedly re-asserted that.

     
  • Martin Holmes
    Martin Holmes
    2012-10-05

    @Lou:

    "Styling info always relates to the source. We have repeatedly re-asserted that."

    That's not true, though, surely:

    "@render specifies the identifier of a rendition element which defines how
    this element is to be rendered."

    "is to be rendered" surely means that some rendering will take place, which has to be during an output process. If not, then it's seriously misleading.

    And we need also to bear in mind that TEI is increasingly used for born-digital documents. <tagUsage>/@render is a natural to provide rendering hints for an output processor, and if it's not for that, then there needs to be something else which is.

    Sebastian's distinction between descriptive and prescriptive, if it maps directly onto "source text" and "output rendering", is a very useful one, and the system and the guidelines should make a clear distinction between them.

     
  • Lou Burnard
    Lou Burnard
    2012-10-05

    @Martin. Yes, the <desc> for @render is the one (and I believe only) place where we contradict what we elsewhere say repeatedly -- that all such styling indications refer to the source not the output -- which is why if you read my comment several inches below this you will see I suggest that is a bug. I think we need to have a different and longer discussion about how the GL should talk about output rendering. Not on this ticket, which is concerned with clarifying the status quo.

     
  • release 6.17 of the stylesheets now deals a lot more consistently with @rend, @rendition, tagUsage etc. I am sure it will be easy to make examples where you will catch it out, of course.

     
    • status: open --> closed-fixed