[whatwg] sic element
svartman95 at gmail.com
Sat Aug 13 06:52:28 PDT 2011
Þ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
> 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
> 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
More information about the whatwg