You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@wired.com> on 1995/10/12 17:26:00 UTC
conditional html
My conditional html code is 'finished' and we're testing it now. After I'm
satisfied it's working fine I'm willing to release it. However I'm not
sure it'll match everyone's expectations here. I made some design choices
that were driven by local concerns.
The code doesn't use flex (I found myself using too many states). It
only uses bison for parsing the expressions. It does include a new
scanner that should be more efficient than the old find_string -- but I
don't have profiling information on it yet.
Just for interest sake: I profiled our servers (before the rewrite) and
the top 3 routines in order were _encrypt, find_string, and rputc.
Unfortunately there's no gprof for IRIX, so this is just flat profile
information.
Included below is some rough documentation.
Dean
<html>
<head>
<title>Conditional HTML</title>
</head>
<body>
<p>Conditional HTML constructs allow the author to issue different documents
according to the browser used.
The following tags may be placed anywhere within a document:
<tt><ul>
<li> <if <i>conditional-expr</i>>
<li> <elsif <i>conditional-expr</i>>
<li> <else>
<li> <endif>
</ul></tt>
<p>A <i>conditional-expr</i> can use the logical operators <tt>and</tt>,
<tt>or</tt>, and <tt>not</tt>. Parentheses <tt>(</tt>, and <tt>)</tt>
may be used for grouping. The actual terms presently have only one
form:
<ul>
<li><tt>supports=<i>property</i>
</ul>
A <i>property</i> is one of the following:
<dl>
<dt><tt>backgrounds</tt>
<dt><tt>font</tt>
<dt><tt>forms</tt>
<dt><tt>imagealign</tt>
<dt><tt>images</tt>
<dt><tt>java</tt>
<dt><tt>jpeginline</tt>
<dt><tt>math</tt>
<dt><tt>tables</tt>
<dt><tt>vrml</tt>
</dl>
<p>For example:
<pre>
<p>This paragraph will always be present.
<if supports=tables>
<p>This paragraph will only be present on browsers supporting
tables.
<else>
<p>This paragraph will only be present on browsers which do
not support tables.
<endif>
<if supports=tables and supports=forms>
<p>Text for browsers supporting both forms and tables.
<endif>
</pre>
<h3>Declaring Properties of Browsers</h3>
<p>The properties of a browser are declared in the <tt>httpd.conf</tt> file
used to boot the webserver. The configuration tag is <tt>UserAgent</tt>
and has the following format:
<tt><pre>
UserAgent /regexp/ property1 property2 ...
</pre></tt>
<p>The <tt>UserAgent</tt> tag can be placed in the global section (for all
servers) or in a particular virtual server section. The <tt>User-Agent</tt>
header is matched against the <tt>UserAgent</tt> tags in the order
given. The <tt>/</tt> characters can be replaced by any matching character.
For example:
<tt><pre>
UserAgent '^Mozilla/1' tables forms jpeginline images backgrounds
UserAgent #^Mozilla/2# tables forms jpeginline images backgrounds java
UserAgent :^Lynx: forms
</pre></tt>
<p>The regular expressions available correspond to
<a href="http://edit.hotwired.com/info2www/info2www.cgi?(regex)">basic
POSIX regular expressions</a>.
<h3>CGI Support</h3>
The environment variable <TT>BROWSER_SUPPORTS</TT> is set to the list of
properties for the user agent.
</body>
</html>
Re: conditional html
Posted by Brian Behlendorf <br...@organic.com>.
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.
Dig?
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 www.levi.com, 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.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/