[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