[whatwg] sic element

?ann fim 11. ?g?st 2011 04:54, skrifa?i Jukka K. Korpela:
> It's debatable and irrelevant in this context what RTF, TeX, and
> text/enriched are. The issue is whether HTML can express simple things
> like bolding in quoted material - or, rather, whether such simple
> expressivity is to be declared obsolete and an error (even though
> browsers are required to support it).
>
My take on it is that implementations should interpret typographic 
elements literally if descendants of <q> or <blockquote>, but as 
optionally offset spans otherwise (i.e. optionally spoken in an 
alternative mood, or rendered in an alternative font), using the 
intended font or style wherever practical.


>> The fact that speech renderings preserve neither bolding nor
>> italicization implies that implementors have not interpreted <b> and
>> <i> to mean bold and italics, respectively, but as hints as to
>> appropriate visual renderings
>
> Speech renderings cannot present bolding and italics at all, so the
> argument does not stand. It's not a matter of being hints versus
> essential markup but a matter of limitations of the medium.
>
The debate is about whether an expected speech rendering of e.g. <b>some 
text</b> would be "some text" or "[brief pause] bold [brief pause] some 
text [brief pause] end bold". The former rendering is lossy, and if the 
bold font is in fact "required", the latter rendering makes sense. The 
only use case I can come up with where the latter rendering would 
actually be useful is discussion of the typography of a printed 
document. That would clearly not be a great enough use case for 
introducing new elements to the standard, and only considered as the 
elements are widely implemented already.

>> that happen to map quite reliably to aural renderings
>
> No they don't, and speech renderings do not work consistently, even
> though some of them may, at least with some settings on, let <b> and <i>
> affect the rendering somehow. Bolding and italics are traditional
> devices of print typography, with multiple uses, and many of those uses
> (like italics for foreign words) do not involve any emphasis that should
> be expressed in speech.
>
The question is what *should* a user agent do with typographical 
elements when the appropriate font is unavailable?
A) Set it off from the surrounding text by other means, or ignore it
B) Convey the style by other means (such as by prefixing it with the 
font style name)
C) Ignore it

Ian's draft specifies A. I'd be (not quite) content with B in quotes and 
A otherwise. Are you arguing for C?

> This is not about stretching anything. The B and I elements were
> introduced at the same time as STRONG and EM, so they were clearly meant
> to have a different meaning, namely indication of physical presentation.
Yes, and more importantly the historical draft explicitly states that B 
and I are only to be bold and italic where practical, and that 
alternative mappings are allowed. Hence my interpretation: the 
appropriate font and style where practical, an alternative otherwise.

> The historical draft
> http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
> says this clearly, and it says:
>
> Some of these styles are more explicit than others about how they
> should be physically represented. The logical styles should be
> used wherever possible, unless for example it is necessary to refer
> to the formatting in the text. (Eg, "The italic parts are
> mandatory".)
>
> It does not sound good to tell authors to move away from HTML to a
> completely different data format just because there is a need to express
> bolding. And regarding new markup languages, well, they can be designed
> if desired, but we would need to allow several years for delivery, and
> while waiting for that, can we just keep using the well-defined
> classical tags, please?
>
HTML-compatible != completely different data format.
I meant to suggest using a subset of HTML with a new doctype, understood 
by existing HTML implementations, to instruct non-visual user agents to 
preserve the boldface and italics even in non-visual renderings. A 
processing instruction or attribute would achieve the same. I still 
don't understand how you want non-visual UAs to render typographical 
elements.

Received on Saturday, 13 August 2011 06:52:28 UTC