Closed kshawkin closed 7 years ago
As much as I love the fact that we suggest the WWP Rendition Ladder system, @style
is simply more appropriate.
Our examples are now all or mostly CSS. I’m in favor of making them all @style
with CSS.
Just documentation/prose changes to mention @style including in examples across most levels (ODD file) ... in the main-driver.odd file.
Peter agrees to implement.
Are we not going to mention @rend at all, then, in 3.8.4 and subsequently - just swap @style for @rend?
Since 3.8.4 already confines @rend values to CSS, simply swapping in @style makes sense. However.... (and I always feel the need to ask this): what about formatting features that cannot be expressed as CSS? (or at least cannot be expressed by my CSS skillset?) The commonest in my work is rendition of spans or blocks of text (usually but not always quotations) by means of marginal turned commas, single or double, or other characters such as asterisks or dots--one of the commonest features in books printed before (say) 1880, and of course very similar to one of the commonest features in the display of email (marginal angle brackets), but with no obvious way to express it in CSS. Unless you know of one! (please do.) I resort to stuff like this:
HI[REND~="margQuotes"] { display: block; font-style: normal; margin: 0px; padding-left: 20px; background-image: url(http://www.lib.umich.edu/tcp/docs/pix/other/commas1.gif); background-position: left; background-repeat: repeat-y; }
Good use case Paul. I think dot leaders (e.g. as used in tables) are another difficult case. Rereading Kevin's initial comments, it seems that @rend would not be forbidden; we'd just urge the use of @style rather than @rend for formatting that can be expressed as CSS. I suppose the question is where and how to address the possible use of @rend—which I support, if only as a last resort.
I also wonder (and hope to be informed) whether use of CSS 'font-family' with home-brewed arbitrary values is really legitimate CSS. This is of course necessary when capturing anything but the most modern of typefaces. Even 'blackletter' is not defined as a generic font family in CSS, much less the different flavors of blackletter (rotunda, textura, bastarda, and the various Continental variants of those, including proto-Fraktur faces). Is { font-style: 'bastarda', 'hybrid-blackletter', fantasy ; } the recommended way to do things? See examples
I think we're leading parallel lives: just this week I've been grappling with the font issue, both with blackletter and with things like this:
(the last, as often, containing a mistake--should end in a 'd' not an 'eth.')
Here's what I'd like to say in 3.8.4, after changing existing examples of @rend to @style:
<p>If there are formatting features in the source that cannot be expressed with CSS syntax, the <att>rend<att> attribute may be used, as in the section on Hyphenation above. This may be also be necessary to encode font shifts in texts (e.g. blackletter) for which CSS does not provide adequate options.</p>
If we're really privileging @style over @rend, should section 3.2.1 (Punctuation) also be revised? The examples can be encoded as CSS, though @rendition needs to be used:
<p>When removing punctuation marks whose rendering in the source document is worth preserving, use the <gi>rendition</gi> <emph rend="font-weight: bold;">element</emph> in the header to describe the punctuation marks that were removed: <egXML xmlns="http://www.tei-c.org/ns/Examples"> <rendition xml:id="dQuoteBefore" scheme="css" scope="before">content: '“';</rendition> <rendition xml:id="dQuoteAfter" scheme="css" scope="after">content: '”';</rendition> <rendition xml:id="sQuoteBefore" scheme="css" scope="before">content: '‘';</rendition> <rendition xml:id="sQuoteAfter" scheme="css" scope="after">content: '’';</rendition> </egXML>
and the <att>rendition</att> <emph rend="font-weight: bold;">attribute</emph> on the appropriate element to link to those descriptions. For example:
<egXML xmlns="http://www.tei-c.org/ns/Examples"> <p>She said, <said rendition="#dQuoteBefore #dQuoteAfter">Nobody uses the term <soCalled rendition="#sQuoteBefore #sQuoteAfter">electronic text</soCalled> anymore</said>!</p> </egXML> </p>
Everywhere else the change from @rend to @style seems to be trivial.
Regarding @pcgorman 's suggested revision to section 3.8.4, I suggest not mentioning the hyphenation section directly, at least till we know how https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/21 will be resolved. Otherwise, his two proposed sentences are clear though kind of redundant. Maybe just say this:
<p>If there are formatting features in the source that cannot be expressed with CSS syntax, the <att>rend<att> attribute may be used.</p>
I think this would be best inserted before the discussion of <rendition>
.
Regarding @pcgorman 's question about section 3.2.1, it appears that this section was written, like the most of the rest of the BPTL, to use @rend
in a way that is basically how @style
was later designed for P5. So it should be revised to change @rend
to @style
.
I don't think that <rendition>
is required here. In section 3.2.1, we only say to use <rendition>
in cases where the value of @rend
is not CSS. However, the values of @rend
given in section 3.2.1 are in fact CSS values, albeit rarely used ones. So I don't think <rendition>
is needed here.
This has been partially implemented in #35 . We still haven't revised 3.2.1 (on punctuation), and we might be more explicit in recommending use of @style
over @rend
.
Emailed Peter to see if he's interested in finishing this.
Have now revised section on punctuation: https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/commit/79c01ea776ef1ec91a30935630a0b5366aa5f64f .
P5 2.2.0 introduced @style, which is to be used much like the BP recommends using @rend. We should drop any mention of @rend in the section on @rend and @rendition (but keep it elsewhere in the BP, where it has specialized uses, such as on
<milestone>
and<lb>
) and instead recommend use of @style. We could maintain our mention of @rendition since the level of indirection could still be useful.