Re: Getting beyond the ping pong match (was RE: Cleaning House)

John Foliot - WATS.ca wrote:
> Lachlan Hunt wrote:
>> No, it seems you missed the point of my questions.  You and several
>> others are arguing that we should drop <b> and <i> in favour of adding
>> more specific semantic elements.  I am asking you to be more specific.
>>
>>> (There, I just made the word "reason" purple in this HTML rich
>>> exchange
>> Purple?  Sorry, plain text only. but I'll just pretend it was.
> 
> ...and in a devilishly evil way, *that* is exactly the point.  A
> presentational artifact was lost on you - several in fact as the sentence
> was marked with colors, bold and italicized text.  And so some visual
> meaning was lost to you - some of that visual rendering may have been for a
> purpose, whilst other was pure whimsy.  But you don't know, and can't know,
> as you did not have the benefit of VISUAL PRESENTATION.

Typical conversions from HTML to plain text often lose semantic 
information as well as presentational information, so this isn't a 
persuasive demonstration. I'd like to reframe it slightly.

The problem with basic presentational markup is not /intrinsically/ one 
of media independence, but rather that it makes it difficult to infer 
authorial intentions. This is in itself a problem for people with 
learning disabilities or facing cultural and language barriers: and that 
means it's a big problem. In the UK population of 60 million, for 
example, perhaps 2 million have learning disabilities and 3 million do 
not speak English as their first language:

http://www.learningdisabilities.org.uk/page.cfm?pagecode=ISBISTBI

http://www.literacytrust.org.uk/Database/stats/EALstats.html

Presentational information like colors, bold, and italic can all be 
represented in non-visual media. Talking browsers and screen readers may 
read italic and bold in a different voice and report changes in font. 
Braille actually has better provision for directly representing such 
typographic stylings than semantics:

http://www.brl.org/formats/rule03.html

But presentational markup becomes an accessibility problem in non-visual 
media for two reasons. The most important reason is efficiency. Visual 
media copes comparatively well with semantics being vaguely implied by 
typography because people can absorb layout and typography 
simultaneously with what is being formatted. This is difficult if your 
listening to an audio stream or reading a braille stream. Effective 
communication in a single channel depends on stripping out non-essential 
information. Otherwise too much time is spent extracting meaning from 
detritus. For example, many screen reader users turn most punctuation 
off. Properly written braille should only use its typographic stylings 
to convey semantic information, never purely for presentational effect. 
Print and braille have different conventions about what formatting to 
use for what semantics. For example, in a dictionary entry, the headword 
would typically receive special formatting in print, but not in braille. 
So braille displays rendering HTML glossaries would need <dfn> or <dt> 
to render correctly. <b> and <i> would result in a potentially confusing 
non-standard rendering.

The second reason is quality of experience. Ship names and book titles 
may be italicized in print and braille, but they are not overly stressed 
in speech. If a talking browser knows a bit of text is a quotation or a 
thought, it can use a completely different voice just as you would do if 
you were reading material aloud. Given the high levels of illiteracy 
across the world and the greater naturalness of speech, it's not obvious 
that we should optimize the web for visual rather than aural presentation.

In these ways even simple presentational markup /does/ indirectly 
interfere with media independence.

But even for visual media, using <b> and <i> to imply semantics is risky 
when elements can also be styled by browsers and CSS. For example, let's 
say you use <i> for foreign phrases and you make a <blockquote> which 
contains a foreign phrase. If <blockquote> is styled italic by the 
author, the browser, or the user, then the foreign phrase's styling will 
be obliterated.

Sadly, our current HTML/CSS stack has no easy solution to this problem, 
since CSS cannot select by style. i.e. you can't do something like:

em {font-style:italic;}
style("font-style:italic;") em {font-style:normal;}

>> I wasn't asking if there are any use cases for <b> and <i>.  I'm
>> saying there are use cases for which bold and/or italic are
>> typographical conventions, and I was asking you to pick at least one
>> and answer the questions for it.
> 
> And see, this is where it breaks down.  The web is not about type-setting!
> It's about conveying knowledge and ideas, without physical constraints - it
> is that "power" that TBL keeps talking about - it transcends the printed
> document and typographical conventions.

You seem to be talking past what Lachlan was getting at. He's saying 
that typography is used to indicate (vaguely) semantics in print and in 
practice on the web, acknowledging that those semantics could (in 
theory) be expressed using semantic markup, and asking you to 
demonstrate the practical utility of such markup. He's basically 
implying that the usability benefits to users of more precise markup are 
too small to trump the usability costs to authors /in this case/, such 
that either the specification would be ignored or semantic markup 
misused. If true, this could actually interfere with the overall goal of 
transcending the printing document in other ways (e.g. non-linearity, 
easier navigability, instant connections, interactivity etc.).

> In this scenario, it matters not whether it is <i> or <em> (as Raman said,
> it is effectively the same to his screen reading tech at this point), but we
> can now associate the reason why we've italicized (or emphasized) that
> particular word or phrase.  WYSIWYG editors could provide the means, when
> "clicking the B button" to provide a "meaning" wizard/dialogue box - perhaps
> pre-populated with some common reasons/meanings...

Whether role or class is used, what should non-technical authors do when 
they cannot find a role or class to represent their meaning? Use <span>? 
I'm not suggesting this situation would be common, but it does bear 
thinking about.

--
Benjamin Hawkes-Lewis

Received on Saturday, 5 May 2007 13:50:29 UTC