>> Larry Masinter writes:
> In reviewing the HTML design, try to keep in mind folks with an audio
> interface, who expect the document to be read to them. There are lots
> of ways to render a heading or a title in spoken language, and even a
> way to render 'emphasis', and even varying degrees of emphasis.
> However, it's very hard to render 'bold'.
Good point! (In my office is a blind programmer, believe it or not)
>> In using emphasis authors would like to be sure that a given set of
>> emphasis tags will in fact be rendered differently on *ALL* browsers.
>> The precise way these are differentiated will clearly depend on the
>> characteristics of each browser, on dumb terminals email conventions
>> could be used while on others color and font attributes can be used.
Very true.
>> Now, while we could use neutral names such as <HP0> <HP1> ... <HP4>
>> most of us would prefer more meaningful names which convey the common
>> interpretation. This explains why <B>, <I> etc are well liked.
>> The problem with "logical" emphasis tags is there is no easy way of
^^^^^^^^^^^^^^^^^^^^^^^
>> pulling together an effective small set. In my attempts to do so for
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
maybe there is....
>> HTML+, it rapidly became apparent that this is a bottomless pit.
>> The set in the DTD provides just a few extras to those in HTML, perhaps
>> leaning too far towards the needs of computer manuals. As for <EM> and
>> <STRONG> these are ok for some purposes, but comprise too small a set.
>> Dave Raggett
All very good points, and I have hit this wall several times (ie: I
have many different 'logical' types of text), and ask myself such
questions as 'do I use <CODE> or <KBD> or <SAMP> to tag a directory
name', and so on. I am *eagerly* awaiting support for <RENDER ...> so
that I can preface my documents with <RENDER DIR KBD> (or whatever the
syntax; I don't have my HTML+ spec handy).
Does it not make sense to remove all of the physical styles (bold,
italic, underline, etc.) in favor of the logical (emphasis, strong,
etc.) since each author can use <RENDER> to make a HTML+ compliant
document using any tags that seem appropriate? In some respects I
think the generic names would be fine for the following proposal,
though I use <EM> and <STRONG> whenever possible.
Now, I know some folks will say "but I want this word ITALIC,
dagnabbit!". I firmly believe that the 'spirit' of HTML is that we
are free from having to make such decisions.
My suggestion is perhaps to have a <FACE> tag (or maybe <HINT> or
<STYLE>, but I'll use <FACE> for this discussion) which more-or-less
says "If at all possible, render <TAG> as 'style' (eg: <FACE EM
'italic'> would mean: if at all possible, render '<EM>' in an italic
style. The first argument (?) to FACE would be a valid tag such as
EM, STRONG, KBD, etc. The second argument would be a fixed set
of styles such as 'italic', 'bold', 'bold-italic', 'reverse', which
could be combined into 'faces' (ala emacs). Unlike RENDER, which is
effectively a preprocessor statement, <FACE> would speak directly to
the browser, expressing the wishes of the author. One could then do
something like (forgive syntactical errors):
<RENDER FILENAME KBD> <!-- render <FILENAME> like <KBD> -->
<RENDER DIRNAME KBD> <!-- ditto for <DIRNAME> -->
<FACE KBD 'fixed-bold'> <!-- suggest that <KBD> be rendered as -->
<!-- fixed-width characters, bolded -->
<H2>Typographic conventions</H2
The following typographic conventions are used in this document:<BR>
filenames are shown in <FILENAME>this font</FILENAME> (typically
bolded fixed width characters)<BR>
directory names are shown in <DIRNAME>this font</DIRNAME>... <BR>
... etc. and so on ad infinitum ad nauseum...
With this, authors are free to choose the emphasis styles that best
meet their needs for a given document, and HTML+ is not riddled with
100's of emphasis styles. Those that want to use <I> and <B> are
happy without having <I> and <B> officially part of the spec, and the
browsers can attempt to render the way the author intended.
Comments?
---------------------------------------------------------------------
Instrument Approach Procedures Automation DOT/FAA/AMI-230
---------------------------------------------------------------------
Bryan D. Oakley ctrbdo%[email protected]
KENROB and Associates, Inc. voice: (405) 954-7176 (work)
5909 NW Expwy Suite 209 (405) 366-6248 (home)
Oklahoma City, Ok. 73132