| By making changes backwards compatible we greatly increase the
| speed in which the changes can be used. Very few web authors are
| willing to break all the older browsers coming to their site
| until they are in the very smallest minority.
Note that what is broken here is that some unwanted text appears;
the whole message gets through, though.
Considering how quickly browsers are changing, and how cheaply they
are priced, I think we can afford a certain amount of such breakage.
We shouldn't refuse to allow nontitle elements in HEAD to have
content for this reason.
| > If we don't believe in format negociation, then all style info has
| > to go in attributes. We can never add a new block element.
| We can add more block elements but we need to be aware of the
| very serious cost that we are imposing on the web. As a
| result new block elements should be avoided whenever possible.
I nominate <style> in <body> as something to be avoided. Kevin's
long post made a good case for using the CLASS attribute to key
style sheet info. (This is equivalent but not as strong in the
SGML sense as pointing to elements by ID.) Thus all the info can
go in the HEAD.
Lou's argument for style attributes on elements seems to be based
mostly on the convenience of writing out the markup (is that fair,
Lou?). Putting the same info in HEAD with a CLASS key if needed
seems not so much harder on the author. (And people *will* use
standard style sheets so as to avoid the effort of doing their
own, you can count on it.
| > I think folks that want a lot more structure etc. should look into
| > building their own DTDs and using something like the DSSSL-Lite
| > browsers that are in development. Check out docbook, qwertz, etc.
| It's important to keep to a single format, that's one of the
| web's biggest features, a unifying layout language that encompasses
| vast amounts of information.
Dead wrong. It's the UR* mechanism, plus HTTP, that unifies the Web.
SGML+style info (or SGML+browser-supplied-style) is just the most efficient
way of sending the info. Get ready for more formats! SGML, of course
(Any Day Now), but I do expect to be seeing RTF any time now.
| > I think folks that want a lot more presentation info should look
| > into PDF, dvi and the like.
| PDF does provide alot of presentation support but it has lots and
| lots of drawbacks as well. It's hugh and bulky and hard to
| process as well as not adapting to resizing windows.
I don't have much of an urge to use PDF, but there must be some uses
for it. It will come into use on the Web for sure.
| > We've got a little more work to do on HTML so that it can represent
| > conventional word-processing documents, and then we should close
| > the book and move on.
(Dan wrote hopefully.)
| I completely disagree. HTML is capible of defining completely
| new dynamic interfaces and unique electronic-only styles. We
| should be expanding HTML to take advantage of it's medium.
Lou, you've had enough experience with SGML by now to know that
it's not computationally friendly. Why should future scripting
languages be based on such an unsatisfactory base? I'd like to
use HTML for the text bits and find something better for
"defining completely new dynamic interfaces." I agree we want
to take advantage of the medium, but trying to do it all in HTML
seems like a real cramping approach.
I also say again that there needs to be some specification, some
general API, for browser behavior or (UA, if you like). This is
logically distinct from SGML markup, and breaking it out as a topic
would help us all.
Regards,
-- Terry Allen (terry@ora.com) O'Reilly & Associates, Inc. Editor, Digital Media Group 101 Morris St. Sebastopol, Calif., 95472 occasional column at: http://gnn.com/meta/imedia/webworks/allen/A Davenport Group sponsor. For information on the Davenport Group see ftp://ftp.ora.com/pub/davenport/README.html or http://www.ora.com/davenport/README.html