Þ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.
