1) a large spec would be very difficult to implement
2) elements once added cannot be removed again
3) HTML is for presentation only, not for writing or archiving
(1) and (2) are valid reasons for being careful, and for taking the
development one step at a time. However, (1) has to be addressed
someday, because eventually we want to add more features, don't we?
(3) Is a stance that appeals to me, but it leaves a few questions. If
HTML is for presentation, what does one use for writing and storing
documents?
In fact, I've been writing docs in a superset of HTML+, and converting
them to plain HTML+ afterwards. This allows using all the facilities
of SGML, such as shortrefs, shorttags, entities, and subdocs, while
keeping the hypertext version simple. The richer source doc can also
be used for other things, such as converting to LaTeX. My `authoring
system,' if it deserves the name, consists of just Emacs, sgmls, and
make.
Could this be the solution? Maybe. But not until there are more
authoring tools available. And it postpones solutions for non-latin
alphabets (like Dave's ISOcyr1 example) to some time in the future.
In more detail, what are the things people want to drop or add?
Drop:
a) Anchor attributes TYPE, SIZE & METHODS (handled by the
protocol instead?) TITLE & PRINT also have limited use.
b) Conditional text. seems to introduce as many problems as it solves.
c) INDEX attributes. No function in browser. See (3) and comments above.
d) Several LINK REL types. `Guided tours' (Previous & Next) cannot be
specified in the docs. A doc could be part of several tours!
e) Document type subset (the top part that looks like <!DOCTYPE
HTMLPLUS [...]>). Not needed if entities, subdocs, etc. are left out.
f) Text flow around images. Maybe just keep the special case of an
image at the very start of a P?
g) In spite of Terry Allen's comments, I'm still of the opinion that a
DIRectory across the page is different from a bulleted list. The
latter is meant to be read, the former is for reference only. But
anyway some redundant items can be dropped from the spec.
h) Q. The quote is useful for writers, but little is lost when the
hypertext contains explicit `'.
i) WRAP attribute seems unnecessary in view of LIT
j) SEETHRU. Still too unsettled, Maybe we should wait until we have a
better idea of what we want or don't want in the way of inline
image display (alpha-channels? rotatable 3D?, inlined movies?)
k) L seems to be covered sufficiently by LIT, BR (for layout) and P
(for the ID attribute).
l) `Quote by name' suggestion. Let's stick to simple hyperlinks for
the moment. If needed we can let the server deal with it.
m) NEXTID. Might be useful for authoring, but is meaningless to the
browser.
n) CITE, PERSON & ABBREV. Just like Q and INDEX= it is good to have
something like this when writing, but for presentation literal
parentheses resp. nothing might be good enough.
Don't drop:
a) HEAD and BODY. They allow the HEAD or the BODY to be retrieved
independently, using simple SGML tools. They don't have to be in
the doc, as long as they are in the DTD.
b) TABLES. They can't be too hard to implement, can they? Would it be
easier without the ROWSPAN?
c) SUB & SUP. If only to keep people from using ugly IMGs instead.
To drop or not to drop?
a) U. As Marc Andreesen said, underlining is often used for indicating
links. On the other hand, it is a common decoration in
typewriter-style text.
b) LANG attributes. Can influence hyphenation, layout, quoting (`' ""
,,'' <<>>), font-selection (e.g., smaller caps for German), and
probably other things. Do we need that yet?
c) MH. What are the arguments pro & can for this?
d) MATH. I would love to have this, but it might be a burden on the
implementors.
e) `Document clusters' (LINK REL types such as UseIndex, Contents,
UseGlossary, Bookmark, Parent) change the way the Web is viewed: no
longer a flat system, but hierarchical collections of typed docs.
Add:
a) A LABEL attribute on the LI element, to override the default bullet
with some text (as suggested by Terry Allen)
Bert
--
_________________________________
/ _ Bert Bos <bert@let.rug.nl> |
() |/ \ Alfa-informatica, |
\ |\_/ Rijksuniversiteit Groningen |
\_____/| Postbus 716 |
| 9700 AS GRONINGEN |
| Nederland |
\_________________________________|