Re: New Topic: HTML and the Visually Impaired [long]
Terry Allen <terry@ora.com>
Date: Thu, 8 Sep 94 10:33:09 EDT
Message-id: <199409081429.HAA21528@rock>
Reply-To: terry@ora.com
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: Terry Allen <terry@ora.com>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: New Topic: HTML and the Visually Impaired [long]
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
|
| I hope this is actually of interest to more than just Terry
| and me.
At least it has been educational for me, and I think this last
post of Yuri's (last in the sense of most recent ...) states
the matter clearly. I have a few remarks, but one big question:
how can we legitimately include Proposed stuff in 2.0? This
applies to some of the material that Dan had labelled Proposed,
too. If 2.0 is current practice, shouldn't this stuff go in
a 2.1 version (to be constructed almost immediately after 2.0)?
And I agree with Yuri that it's about time to arrive at consensus;
I'll go with the flow.
| (Responding to Terry's responses is kind of a full-time job!)
Have to earn my salary some way ...
| For instance: Let's flog this sidebar a bit more. A textbook publisher
| has a document with sidebars. There is a concept of a sidebar in the
| Braille output as well.But we're asking them (if I understand Terry's next
| comment correctly) to encode the file in HTML rather than ICADD.
| So the fact that such-and-such is a sidebar gets lost, turned into
| a paragraph perhaps (for display only) rendered as a pointer to a
| separate file, perhaps as text set off by HR elements before and
| after. However, the critical thing from the point of view of the
| Braille renderer (and the large print version for that matter) is that
| this was a sidebar and that fact is now lost. We've down-translated
| too early, so to speak.
True only if there is no remaining info to identify the sidebar
as a sidebar. A hotspot labelled "Sidebar" or an appropriate
attribute value on the link to the exterior-file-sidebar could
preserve that info. (SDL has this concept, and so does HTML
in the sense that unspecified atts are to be ignored.)
| > Right, but this could be in HTML instead of ICADD proper. In
| > other words, if HTML has ICADD fixed atts, it's a better presentation
| > format than ICADD-DTD-encoding.
| >
| A better presentation format for the Web perhaps, but not for
| the other requirements -- unless we add that handful of elements
| that will make HTML a true superset of ICADD! In which case,
| people creating files for Braille directly can use ICADD and those
| files will browse in a WWW browser. People creating files in
But people should *stop* creating files for Braille directly in ICADD,
because it handles only nonprint, nonvisualonline rendering. They
should start using some richer DTD (12083, for example), so they can
go to print directly, or, if they use HTML, to online directly.
Asking too much?
| We're mixing apples and potatoes here. I was thinking of an actual
Makes the potatoes sprout.
| I think "Tag Abuse" syndrome is actually the opposite. In my mind it's
| the situation in which one uses the wrong element to achieve some
| sort of visual effect. I'm saying there is an effect we want -- the concept
| of the sidebar -- and concocting it any way but through a specific element
| would be a case of Tag Abuse.
Well, here's the rub. If we add SIDEBAR to HTML, and different
browsers implement it rather differently, users who use only one
browser will start using this not-for-online element to get some
sort of special effect, then be alarmed that the effect is not produced
by another browser. Whether you call this Tag Abuse or not, it's
like like putting a drum in a kindergarten and expecting not to
hear it played.
| > I now understand much better, Yuri; let's mull over this mapping
| > problem some more and see if we can get a better result. Would it
| > be too difficult to map-on-the-fly a BOX to a new HTML instance
| > with a link to it that has "See Sidebar" as its hot spot? After
| > all, a sidebar is really only out-of-flow material, often allowed
| > to float in the context of page composition; we don't need to
| > worry about floats online, and we can reproduce the effect of
| > being out of flow by linking.
|
| No, I don't think it would be too difficult, but my position is that this
| should be a question for a browser implementor, not for a DTD writer.
| That's presentation; as far as I'm concerned, SIDEBAR is a *logical
| construct* which, along with LIST HEADING, AUTHOR, INK PRINT
| PAGE and PAGE REFERENCE, make sense in a forthcoming HTML
| -- even if only in a ICADD marked section which is defaulted to
| INCLUDE.
This absolutely *the* point of our disagreement. I don't think
Sidebar is a logical construct in the online world. Sidebar is
"out-of-flow" material for the printed page. Online, it's just
another node, like Footnote (which we also don't have in HTML),
except that it's not explicitly linked to a point in the main
text. I understand that you want to push the issue out to the browser
layer by including the element in HTML, but to me that seems to
do violence to the presentation semantics of HTML. In other words,
HTML and ICADD presently deal with different sets of presentation
semantics, for different, um, media, or different means of using
different media, or something like that. Instead of munging
them together in HTML, it would be better to generalize the
semantics and harmonize both DTDs.
So (and remember, I said I'd go with the consensus, just shush
me if this is going on too long), instead of adding SIDEBAR it
would be better to add OUTOFFLOW aliased to SIDEBAR, and try
to figure out what the heck OUTOFFLOW means online.
--
Terry Allen (terry@ora.com) Editor, Digital Media Group
O'Reilly & Associates, Inc. Sebastopol, Calif., 95472