[tei-council] TEI TITE question

Martin Holmes mholmes at uvic.ca
Tue May 8 11:31:48 EDT 2012


Just a reminder that this suggestion is in conflict with an existing 
feature request:

<http://purl.org/TEI/FR/3519866>

As Sebastian says on that ticket, we're unlikely ever to reach a 
consensus on this; there's a large group of people already using @rend 
with CSS in it, and an equally large group of people who think that's 
abusive.

I think we need to recognize that:

  - Those who want to use @rend for CSS at the tag level (not through 
@rendition) need to be accommodated, either by loosening its data type 
or by the provision of another attribute for that purpose.

  - Those who still follow the traditional use of @rend by supplying 
data.word values for it also have a strong desire for a set of 
recommended values, to enhance interoperability.

  - The current situation is a bit of a mess, because nobody is 
particularly happy.

Cheers,
Martin

On 12-05-08 07:43 AM, Gabriel BODARD wrote:
> All of the below. If you want better interchangeability, then let's
> argue for a list of recommended values for @rend, rather than for adding
> yet one more way of doing this.
>
> I would support this argument.
>
> @rend (rendition) indicates how the element in question was rendered or
> presented in the source text.
> Status 	Optional
> Datatype 	1–∞ occurrences of data.word separated by whitespace
> Values 	may contain any number of tokens, each of which may contain
> letters, punctuation marks, or symbols, but not word-separating
> characters. Suggested values include:
> 	italic
> 	bold
> 	superscript
> 	subscript
> 	underline
> 	larger
> 	smaller
>
> This won't force anyone to do this, and it won't break backward
> compatibility or fix the mess that exists in old texts, but it will
> reduce the likelihood in future of values such as "italics", "i", "ii",
> "it", "ital", etc.
>
> G
>
> On 08/05/2012 15:34, Kevin Hawkins wrote:
>> On 5/8/2012 10:25 AM, Gabriel BODARD wrote:
>>> We already have a long-established way to encode the undistinguished use
>>> of italics, the only argument against which is that it's more keystrokes
>>> than<it>. We could easily encourage more consistency in attribute
>>> values if we really wanted to--though I predict there will be resistance
>>> to doing so.
>>
>> But what is this long-established way?  I can think of many (with
>> non-canonical practices marked with an asterisk):
>>
>> <hi rend="i">
>>
>> <hi rend="ii">
>>
>> <hi rend="ital">
>>
>> <hi rend="italic">
>>
>> <hi rend="italics">
>>
>> <hi rend="Kursiv">
>>
>> <hi rendition="#foo">   with<rendition xml:id="foo"
>> scheme="css">font-style: italic</rendition>
>>
>> <hi rendition="#foo">   with<rendition xml:id="foo" scheme="free">This
>> text is italicized.</rendition>
>>
>> *<hi rend="font-style: italic">
>>
>>> There is also a certain semantic value in the<hi>    element, by which I
>>> mean in its very name, not it's attribute values: this text is
>>> highlighted in some way to set it apart from the surrounding text. I can
>>> imagine a transcription scenario when all you want to encode is that the
>>> text is set apart, not how it is rendered.
>>
>> I agree with the value of<hi>   and do not think we should eliminate this
>> element.
>>
>>> My opinion remains that there is a place for elements such as<i>,<b>,
>>> <sup>, etc., but that that place is in a custom schema for
>>> encoders/vendors, not in the published, interchangeable TEI.
>>
>> But it would be enormously helpful if the TEI could promote interchange
>> of encoding of italics, bold, and other of the most common features in
>> printed source documents!
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


More information about the tei-council mailing list