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/ *****************************************************
