I kind go off topic a bit here but I think it's worth a read, and it
does come back to the point eventually.

I'm against hacks anyway and I even go as far as saying the @import
method of hiding from Nutscape 4 is a hack (and I'm pretty lonely on
that opinion) and this (mid pass filter) is just another "behaviour"
that has to be monitored into the future in case some later browser
(probably IE) does the wrong thing with it. 

Messing up the CSS code with anything that is only targetted to one
browser is confusing if the site needs to be handed on. The
professionalism of your code to a developer who eventually gets the job
is important to your reputation.

I'm sure I'm not the only developer who has had to undo some other
dodo's NetObjects Fusion or FrontPage site and that dodo's reputation
from that point on is pure excrement.

I'm pretty confident that nearly everyone on this list could take any of
our (Russ Rose Peter) sites and not have any issues with any of our
code, no learning curve and no need for massive documentation. Same with
my CF apps, any half decent CF developer could look at my code and know
exactly what's going on immediately (sure, they may have a slightly
different way of doing things but it's very clear). This is important,
and something that we are very proud of. 

Also on this point, we try very hard to make sure our (non ColdFusion)
sites can be taken from our Win2K/IIS server and slapped onto a *nix box
and they'll work straight away (always enforcing a standard of lower
case file names etc.). While I would never suggest doing this (Win/IIS
works extremely well for me), a client may well change ISPs and it's my
duty to make sure that a "website" that I have produced will work on a
"web server", regardless of platform.

My CF apps can generally be deployed to another CFMX box in minutes
(depending on the datasources). 

I guess this rave is about the KISS principal, and not trying to own a
site (through required knowledge) that actually belongs to a
client/employer. It's a great selling point for standards based coding.
We tell out clients that if they need (for any reason) to employ someone
else to look after the site in the future, then it will be totally clear
to any good web developer, and will gladly hand over a CD will all the
master images etc. for this purpose.

Another thing we do in this regard is to maintain standard practices
across all sites. We *try* to always use the same filenames like
/js/master.js for a javascript include required on every page,
/stylesheets/main.css, /stylesheets/advanced.css and
/stylesheets/print.css for the stylesheet names (or
/stylesheets/something_main.css and /stylesheets/somethingelse_main.css
if there are different sub sites in the same domain). ALL images sould
go into an /images/ dir (with subdirs for different site sections) so
that we can download the whole site sans images for global changes if
required, very quickly (I am still limited to a dial-up connection here
on the boat). 

We recently took on a job that had every file used in the site (and many
many test pages not used in the site) in the root dir. 590 objects
totalling 15.5MB in the root including class and jar files, images,
word, powerpoint and pdf documents, the Access databases, the admin
system for the CMS, and not even protecting that using a CF login (and
no Application.cfm)! 

We are starting from scratch and the developer has a really bad
reputation now.

Back to the issue...

If I had to take on a site that used content negotiation done by apache
with multiple content sources for different browsers, then it's going to
take me a good learning curve and I'd be cursing the previous developer
for it.

As Ben said, most people are not going to have the knowledge/access/time
to do this. If you tie content delivery into server configuration then
it may be a mess for the next person, and your rep may suffer in the
long run. If they change ISPs, disaster?

It also (to me) pretty well goes against the separation of style and
content as well. The point I like in using CSS is to have vanilla
mark-up in the content and setting up different versions for the server
to send adds the maintenance issues back in. The fact that we don't ever
have to provide a "Print" or "Text only" version as a separate page any
more is a dogsend (sorry, not religious). One content source to maintain
(be that hard coded html or data through application pages), many
different outputs depending on the style sheet employed.

P

> From: Ben Boyle
>
> I would have thought the best way to target a browser (be it 
> IE5 or other) was content negotiation. Detect the browser and 
> serve content in the appropriate format. Does anyone else get 
> the feeling this technique is rarely used whilst cruder 
> methods proliferate?
> 
> IMHO, web servers can do a lot more than just serve files and 
> should be exploited for all they are worth - and that's 
> plenty. I feel this cornerstone of the web is oft overlooked, 
> much to the detriment of the online experience when cruder 
> technologies are called on to compensate.
> 
> Maybe it's just too difficult for developers to get access to 
> webserver configuration, or too tedious to produce content in 
> multiple formats? Gotta weight that against the time and 
> effort we've all invested in workarounds and hacks though ... 
> The right tool for the job. One can't solve every problem 
> with a hammer.
> 
> cheers
> Ben

*****************************************************
The discussion list for http://webstandardsgroup.org/
***************************************************** 

Reply via email to