httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: conditional html
Date Thu, 12 Oct 1995 18:23:51 GMT
On Thu, 12 Oct 1995, Dean Gaudet wrote:
>     UserAgent '^Mozilla/1' tables forms jpeginline images backgrounds
>     UserAgent #^Mozilla/2# tables forms jpeginline images backgrounds java
>     UserAgent :^Lynx: forms

The new version of Lynx can do tables.

Which brings up a fundamental inelegancy - there's no way for a new 
browser to "get in on the action", i.e., sending a list of capabilities 
it supports.  Well, there is, it's called the Accept: header, but 
that deals with separate data types and only very crudely with 
fine-grained capabilities within a data type.  Dan Connolly at W3 
suggested there be an HTML capabilities registry, where each enhancement 
is assigned a bit in a bitmap, so a browser could send

Accept: text/html; capabilities=EA23

which would be a compact representation for saying "hey, I understand tables,
embed, and figures".  I expressed my doubts about whether even W3C could get
the industry motivated enough and disciplined enough to do this.  I
elaborated on my doubts, and why a bitmap isn't really needed, in a post
called "HTML Evolution Considered Harmful" - in it I suggested that we drop
the model of making HTML everything but the kitchen sink, and pushing new
functionality in its own data types.  I.e., mathematics capabilities are
already pretty solidly in TeX - if TeX is too large for browser develoeprs to
support, then a subset of teX could be defined for maths (which is
essentially where the maths capability of HTML was headed).  Anyways, this
frozen-HTML should be 2.0 + tables + I18N + CLASS/ID attributes + file-upload
capabilities in forms.  Everything except CLASS/ID attr's are well on their
way to RFC status, so we could reach closure within a few months.  This I
think is the minimum for making HTML useful for 90% of the document needs out
there, particularly when combined with a solid style sheet mechanism which
would be largely accomplished outside the realm of HTML syntax - CLASS/ID
attr's are just about all that is needed.  The other 10% can be accomplished
with Acrobat, Director, PostScript, or other document formats more
appropriate to the message being delivered and the desires of the author. 

To get back to the point, there are cases in the above example where 
content negotiation can work, TODAY.   For example, "jpeginline" - we 
are using negotiation between jpg and gif on, and we've 
found that surprisingly every current browser out there gets its Accept: 
headers right when it comes to embedding images.  Yay!  Secondly, IF java 
applets are embedded into the page using <EMBED> or <FIG> or something 
other than <APP> or <APPLET>, then content negotiation *can* be used on 
that as well.  There are other things like images (using the alt tag) and 
backgrounds (use, don't abuse! :)  which can be provided in a graceful 
way across the board.

Well, those are my thoughts, and why I've never pursued conditional 
HTML (beyond putting smarts here and there in CGI scripts).  I just 
consider it a logical black hole.


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--  http://www.[hyperreal,organic].com/

View raw message