Re: SSI usefulness (was RE: OBJECT, inheritance, and rendering)

> I'm now finding myself taking a more pragmatic approach to what solutions I
> once would have dismissed as architecturally unsound.  So, for example, how
> do we deploy simple CSS features such as .margin-left in a world in which
> probably the most widely used browser (Netscape 4)  has great difficulties
> in printing documents containing such trivial, but useful CSS?  I'm inclined
> to go for the bad idea of user-agent negotiation as I can't see an
> alternative.   It's interesting that the W3C Core Styles gallery at
> http://www.w3.org/StyleSheets/Core/ uses browser-sniffing to chose what CSS
> to send (the files differ greatly, between about 200 and 800 lines for
> Netscape and IE).

Given the current state of CSS implementations, CSS isn't usable in a
real application. If you require (the illusion of) that level of
control of the presentation, then you have no choice but to do some
kind of browser sniffing. Whether you then spit out CSS or
browser-specific HTML is immaterial.

That the W3C gallery requires browser-sniffing to work right seems
like pretty solid evidence that the current CSS implementations are
unusable. If that's not the case, and this is the way CSS is
*expected* to work - then I'm dissapointed, as the most use I'll get
out of it is the extra configurability that well-written browsers will
provide.

> I've also spoken to W3C staff who seem to feel that deployment of support
> for devices such as PDAs will require server-side processing - and not
> sending a large file with CSS, JavaScript, etc. to your networked watch, PDA
> or car computer.

Well, creating things that work properly on PDAs requires some
thought.  Doing all your navigation in a large JPEG file is going to
make users of the current generation of PDAs unhappy, assuming they
can use them at all. If you want pages that look like that and are
*also* usable by PDA browser, then you have to do some kind of
server-side procesing. The vast majorit of people don't seem to care -
they just produce pages that are ugly or unusable on anything but one
of the big two browsers (if they work that well). A sizable minority
is willing to do whatever it takes to get pages that work on all
browsers. Those who want both that control and working on all browsers
are, for now, very frustrated.

> Note that Jakon Neilson in his AlertBox at
> http://www.useit.com/alertbox/980322.html argued that "The road to better
> Web design is to move complexity and advanced design to the server
> and provide more intelligently processed services to the users."  This
> sounds like server-side processing.

That sounds like dynamic pages to me, which is a radically different
type of creature than the kind of include facilities we were
discussing here.

And I concur completely. Putting more smarts on the server side means
you can reach a broader audience than doing things client side. 

> I've written a article suggesting that the server-side processing could take
> place in proxies.  See
> http://www.ariadne.ac.uk/issue16/web-focus/

Well, I think it's an interesting idea. I didn't chase through your
references, but two examples - "capturing" a browser, and ad removal -
came immediately to mind.

You also missed *my* favorite reason for disliking UA negotiation - it
tends to leave the very capable but non-mainstream browsers with the
lowest-common-denominator pages. For instance, inline JPEG, PNG and
and PostScript were all done well before Navigator did them. However,
if you do a UA negotation without a fairly complete database, those
advanced browsers are liable to get the low-quality version.

	<mike

Received on Friday, 7 August 1998 19:34:52 UTC