[ gratuitous quote and reaction of my example deleted ]
>I don't consider format negociation a hack. I consider it an
>important, though underutilized part of the web functionality.
I consider any approach using n different layout versions of documents with
the same content -- a hack, regardless it uses automatic negotiation or
"click here if you use..."
>Your suggestion on the the other hand... well... could you give
>a formal description of the language you're suggesting we adopt?
It should be the same (almost the same) as the current HTML 2.0/3.0 in
terms of DTD, with different/more elaborate implementation guidelines for
HTML user agents to achieve backward-forward compatibility. After all,
(layout) tags are just tags, it's the content that really matters.
>I don't consider "try it on a couple browsers and see it it works" a
>viable specification for HTML.
Let me take the liberty to quote the specification you conveniently forgot:
ftp://ds.internic.net/internet-drafts/draft-ietf-html-spec-01.txt
(which I find it hard to believe because you are a co-author of it :)
2.2 Undefined Tag and Attribute Names
An accepted networking principle is to be conservative
in that which one produces, and liberal in that which
one accepts. HTML user agents should be liberal except
when verifying code. HTML generators should generate
strictly conforming HTML.
The behavior of HTML user agents reading HTML documents
and discovering tag or attribute names which they do not
understand should be to behave as though, in the case of
a tag, the whole tag had not been there but its content
had, or in the case of an attribute, that the attribute
had not been present.
This is the basis why lynx etc., decent/friendly non-table browsers can
deal with my examples gracefully, because they can conveniently ignore any
unrecognized tags and correctly interpret the remaining ones. The only
problems I can see are for table-capable browsers: 1) (functional) partial
implementation causes more problems -- basically (tag) name space pollution
because partial implementation is _different_ from full implementation. 2)
How to deal with redundant layout tags (in this case pre; most html tags
are allowed in pre anyway, why not table stuff, after all they are just
layout hints).
Fortunately, these are only for newer browsers and there is at least one
browser (mozilla) deals with it gracefully. Specification is written by
people/human (vs. god) and can be changed as we see fit. And that's why
this html-wg exists.
>I expect that HTML will be more and more subject to machine
>interpretation -- automatic indexing etc. I'd like to facilitate
>those sorts of tools, not make them hopelessly complex and fragile.
That's right. I believe it would just confuse html-munching robots more if
you maintain different version of html of the same real content. I don't
see any problem for a robot to deal with my examples -- lots of logical
hints there :)
>The 2.0 HTML DTD doesn't facilitate this very much. I think we need
>to take the "strict" mode even further -- introduce hierarchy and such,
>while making the "loose" version even looser -- more in line with
>what browsers really implement.
I agree wholeheartly with you here.
To reiterate my major points in my previous response:
1) Format negotiation for layout purpose is not necessary because it
can be solved less intrusively with the appropriate tag interpretation
guidelines for HTML user agents.
2) The format negotiation proposed can NOT solve (functional) conflicts
between different implementation of layout tags. (e.g., Mosaic X11 2.5
vs. Mozilla 1.1b1)
3) Format negotiation might be necessary for functional purpose like
user interaction capabilities a la HTML FORM stuff.
BTW, while we are arguing about this, service providers like somebody from
totally.wired.com are checking out my examples with browsers from Mozilla
to Arena. I envisage more and more service providers will adopt my
DOIT(tm, Duplication Of Ignorable Tags :) technique in the near future.
-- Luke Y. Lu mailto:ylu@mail.utexas.edu/ http://www.utexas.edu/~lyl/