RE: [WSG] Targeting IE5 (and KISS)
Great comments guys, certainly a few things to weigh up in my mind. I
especially like Peter's comments re coding to support future maintenance.
Thinking of the 80-20 rule, this makes perfect business sense and shows an
admirable example of considerate industry practice. Kudos! I will certainly
take that on board :)
I don't use content negotiation often, preferring to redesign to avoid hacks
where possible, but when it comes down to a particular browser giving me
grief... The only example I can recall is a particular issue with using
floated labels for form layout. An extra stylesheet is sent to netscape6
containing label { float: none; } to avoid a browser bug.
I guess content negotation used this way is still a hack. I'm thinking of
designing forms in future so that the labels sit above the fields (rather
than to the left) and avoiding the float issue altogether.
thanks all!
Ben
*
The discussion list for http://webstandardsgroup.org/
*
RE: [WSG] Targeting IE5
Content negotiation by mime type is one thing, but because of the context (targeting IE5) I assumed user agent sniffing, which is another thing entirely. Maybe I misunderstood. I'd also second Peter's comments - we're on the same page but he was able to explain himself much better than I was. BTW: hiding from netscape using @import is a hack :) Cheers Mark __ Mark Stanton Technical Director Gruden Pty Ltd Tel: 9956 6388 Mob: 0410 458 201 Fax: 9956 8433 http://www.gruden.com * The discussion list for http://webstandardsgroup.org/ *
RE: [WSG] Targeting IE5 (and KISS) [Virus checkedAU]
This email is to be read subject to the disclaimer below. Hi Peter & all, I agree with just about everything you're saying here, as I'm a big fan of the KISS principle and consistency as well. I'd just like to add that there are cases where a problem cannot be solved just by relying on the KISS principle and you have to choose the option which is in your opinion the least evil (complex, non-portable or just unsatisfactory). In situations like this I would weight up my options, pick the least evil one and then I put a big fat comment above it, explaining what it does, and *why* it's needed. And that ought to do it for any maintenance programmer who has even a tiny bit of clue. My take on targeting IE? Unfortunately this is a necessity dictated by the two facts: 1.) IE is full of bugs and 2.) IE is on at least 90% of the world's computers. OTOH I'm extremely vary of using IE's CSS parser bugs for anything. Those who relied on certain parser bugs in IE 5.5 to fix some rendering bugs were sorely disappointed when IE 6 came out, and fixed the parser bug but not the rendering bugs. I don't want to recode anything when and if IE 6.5/7/whatever comes out. Server-side content-switching is a better solution but it's not 100% reliable as user-agent strings can be spoofed, and you might end up giving IE-specific content to a non-IE browser or even a spider. OTOH, I *did* like the conditional comments approach. Unlike the parser bugs, conditional comments are *features*, which will likely work in future IE versions. They can also be tailored for specific versions if you must go that far. But the best thing about them is that other browsers treat them like comments (I wouldn't use the alternate syntax that looks like a tag with line-noise in it, they would stop the page from validating). This means that in the rare cases where I need to for example override a position: fixed rule in IE, I can do it in a way that is completely transparent to any other browser. And if any other browser has a problem displaying position: fixed, then I just don't care, I'm following standards and the browser isn't. I go as far as to offer a workaround for IE so people who use standards-compliant browsers will still be able to use advanced CSS features, but that's about it (I would remove or rewrite CSS if it doesn't render properly in say Konqueror or Opera, I just wouldn't use 'hacks' to do it -- I would tweak the CSS until the page looks OK in each of the target browsers). But I think the best solution is to keep things sufficiently simple that you don't *need* the workarounds. Like keeping the page layout flexible enough that a few pixels difference between the old IE box model and the standard box model doesn't mean that things go out of alignment. Maybe I'm too much of a purist, but I am a coder not a designer -- I can see how designers want more control than what my way of thinking allows. I also think that rules can be bent if there is a strong enough reason to do so. Regards, Vik --- Viktor Radnai Web Developer Business Innovation Online Ernst & Young Australia http://www.eyware.com/ http://www.eyonline.com/ Direct: +612 9248 4361 Fax: +612 9248 4073 Mobile: +61408 662 546 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
RE: [WSG] Targeting IE5
If you're talking about content negotiation in the way I think you are (by the values passed to the server in the 'Accept' HTTP header) and not by getting the value of the 'User-Agent' HTTP header, then I'm all for it. One of my recent thoughts was to check if the UA had 'text/xml' or 'application/xhtml+xml' in the Accept header, and sending them back the appropriate mime-type for XHTML, while everyone else gets text/html. I'd even thought of going to the length of using PHP's output buffering to rewrite the XHTML into HTML4 for the text/html version so that it's totally valid, but that just seems like way too much work for so little gain :) (also, the W3C validator doesn't send an Accept header, so it would be getting HTML4 - still valid, but not exactly ideal to say a site is valid XHTML then have the W3C say it's HTML4 :)) To me, this doesn't seem like a hack at all, it is exactly what the Accept header is for - serving up different content types depending on what the browser (says) it supports. I'm sure you could also do the same with XML, and either send XML plus a stylesheet to UAs that support it, and do a server-side transform to HTML for those that don't (There are probably a number of flaws in this though (probably the biggest being that you'd have to write two versions of your presentation code), and I'll be stuufed if I can think of a single reason *to* do it apart from the 'hey, cool, I can do it' factor) /me should get back to work now... -- Lindsay Evans. Developer, Red Square Productions. [p] 8596.4000 [f] 8596.4001 [w] www.redsquare.com.au > -Original Message- > From: Ben Boyle [mailto:[EMAIL PROTECTED] > Sent: Thursday, 9 October 2003 10:02 PM > To: [EMAIL PROTECTED] > Subject: [WSG] Targeting IE5 > > > 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/ > * > * The discussion list for http://webstandardsgroup.org/ *
RE: [WSG] Targeting IE5
I agree completely James. Targetting browsers is an inefficient waste of time in about 95% of cases. AFAIK its a big step backwards. Having said that its hard to draw a line. We often find ourselves doing things like ...and hiding some stuff inside @import to work around browser issues. In my opinion this is ok because its not really breaking the semantics or relying on a flaw in a particular browser. This like the Tantek's box model hack, midpass & browser sniffing are a bad idea they can potentially impact badly on the shelf life of your site. New browser versions & patches can mean recoding which, as James points out, is NOT the direction we want to be heading in. One big exception to this is browser sniffing to decide on whether you want to dish up Flash content or not (ala James Ellis - http://www.sitepoint.com/article/1116). My only concern with this is that if you are that interested in making your content accessible - why use flash in the first place? But if you have to use flash this browser sniffing is the lesser of two evils. Cheers Mark __ Mark Stanton Technical Director Gruden Pty Ltd Tel: 9956 6388 Mob: 0410 458 201 Fax: 9956 8433 http://www.gruden.com * The discussion list for http://webstandardsgroup.org/ *
Re: [WSG] Targeting IE5
Maybe I'm misunderstanding you but I think it is a terrible idea to have multiple content streams. This can and often does lead to multiple headaches... Personally I favour having one content stream, but possibly multiple style/display streams. These could be assigned via server controls, or by careful creation of designs or by user action. I certainly do not favour many of the still widely used code forks and detections around, but there are ways to work around deficiencies of some older (and newer) platforms without shutting some things off from one or more users. Personally I'm looking forward to the day when I can serve the content in xml, and then style it with css, or svg or flash, (or whatever) depending on the user preference. And this would only be possible if everything understands the rules that everything else works under... standardsy stuff scottbp Ben Boyle wrote: 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/ * * The discussion list for http://webstandardsgroup.org/ *
RE: [WSG] Targeting IE5 (and KISS)
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
RE: [WSG] Targeting IE5
Isn't this targeting of specific browsers, be it server side or client side, what happened in the IE v NN browser wars, and one of the main reasons that standards are being pushed? Regardless of how efficient your detection is you are still writing multiple style sheets for different browsers, and the number of style sheets you need will increase with new releases. Updates to stylistic elements of the site must take place over many style sheets rather than one and development time may actually increase. I'm not arguing that it isn't a solution in some cases, but as a default position it seems to go against the grain of standards. James -Original Message- From: Ben Boyle [mailto:[EMAIL PROTECTED] Sent: Thursday, 9 October 2003 10:02 PM To: [EMAIL PROTECTED] Subject: [WSG] Targeting IE5 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/ * * The discussion list for http://webstandardsgroup.org/ *
RE: [WSG] Targeting IE5
Ben, I totally agree, there's so much that can be done either using some
Apache rewrite magic - %{HTTP_USER_AGENT} + Regular Expressions = powerful
client detection or even just with some embedded PHP code or similar so that
different pages and/or sections of pages can be pulled in as required.
There are some totally amazing things that can be done with Apache if start
playing with content negotiation, authorisation and access control and
rewrite rules etc - it's a real eye opener and a whole new world of goodness
:)
Best to all,
Beau
// -Original Message-
// From: Ben Boyle [mailto:[EMAIL PROTECTED]
// Sent: Thursday, 9 October 2003 8:02 PM
// To: [EMAIL PROTECTED]
// Subject: [WSG] Targeting IE5
//
//
// 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/
// *
//
//
//
*
The discussion list for http://webstandardsgroup.org/
*
