What's waiting here?
> | Styles - no consensus yet
Regardless of how they get referenced, we need an explicit statement
of how you describe styles. Just saying "like you do X resources"
isn't enough for the average (ie non-X) user.
> | HyTime links - no consensus reached
IMHO HyTime goes on the list for HTML4...it's just too much/too big to
get into HTML3 st this stage.
> | Client-side scripting - no proposal yet
I don't know enough about the thoughts in this to comment.
> | Full SGML in the client - no proposal yet
Fine once we get enough bandwidth to handle the extra requests. See my
sketch proposal below, but this should be HTML4.
> | Unicode support - no consensus reached
No shit? I thought this one had been put to bed.
> | client side image map - no consensus reached
I say go for the arrangement as it stands in HTML3 unless there is
some major tech flaw.
no objections, but there may still be disagreement
on whether CLASS should have predefinable semantics or not;
(I believe it should not, though a list of suggested values
for various elements a la link relations is a good idea.)
Yes: suggestions (even strong ones) but not compulsion yet.
Footnotes -- OK, but should there be a separate FN element,
or should these be specified with <NOTE ROLE=footnote>?
(I say the FN element should be reintroduced.)
Yes. Footnotes are a part of the author's text, whereas other forms of
note may be things added by an editor. I believe these are
sufficiently different to warrant separate handling.
DIV element -- I believe there was consensus on this.
Other proposals included: multiple ranked <DIVn> elements;
requiring an <Hn> as the first element in any division;
separate recursive <DIV> and <SECT> elements, where <DIV>
was free-form and <SECT> required a heading; and
something really heinous-looking in the old HTML+ DTD :-)
Stick with <div class="chapter"> etc for the moment. Going for
fully-fledged <div0> <div1> etc is probably too much for the user
community.
Q. Do we get to allow users to put text as direct content of <li>,
<dd> etc without the need for an internal <p>?
OK: SGML. Some thoughts. If we can get to the stage of browser makers
distributing a half doz. assorted popular DTDs with their product, we
can go for <!doctype foo public "foo//bar//blort"> and have the
browser pick up the DTD and SGML Decl. from local disk, engage
whatever parsing code is embedded, and validate the doc.
Pro: it pleases the formal SGML community
Con: heavy cycle overhead
If foo.dtd is not on disk, the browser looks for it in the same
directory on the same server where it got the file. If not there, then
in one of some popular repositories. Once found, add it to local disk.
Repeat the process for a style file, if that's the way we go (I think
it should be, rather than embedding style directives in the header).
Overall, a heavy hit on bandwidth and processing. Can we devise some
way to insert a "guarantee" that the current file just retrieved is
indeed conformant with the DTD it claims to follow in its DOCTYPE? In
other words, can we get SGML editors to insert a "none genuine without
my signature" block in the file? Then there's no need for validating,
just follow the style directives for display. Only go get the DTD if
it's not one you already have. This way, uncertified instances cause
browser delay, which makes users pressurise authors to use whatever
form of prevalidation guarantee we settle on.
But I'm jumping the gun...let's get HTML3 out the door.
///Peter