What, as of today, would be the best way to handle browser differences

Forum Moderators: not2easy

Message Too Old, No Replies

What, as of today, would be the best way to handle browser differences

joliett89

2:04 pm on Feb 10, 2012 (gmt 0)

When starting to work on a website from scratch? For now, I use one of the CSS resets:

[developer.yahoo.com...]
[meyerweb.com...] (Eric Meyer)

Would you still worry about all that Internet Explorer issues (only about 3.1% of people use it as of 01.2012)? I know it depends on who is watching the website too (if there is a lot of visitors every day with IE it probably makes sense to make everything work right etc.)

[w3schools.com...]
[w3schools.com...]

What are the other things that you do in order to avoid the headache in the future?

Thank you.

rocknbil

5:53 pm on Feb 10, 2012 (gmt 0)

Internet Explorer issues (only about 3.1%

You must mean IE 7. The numbers are much higher for 8 and 9. In any case, all of the below - most of my documents render fine in IE7 (and thank Bezeebus it's finally going away.)

1. VALIDATE. :-)

2. Everyone is jumping on the HTML5 bandwagon. I'm holding off. Why?

In the 90's we put a great deal of effort and frustration into browser identification and applied all sorts of hacks to get them all to play along. What most found out was that there was a better way; code your way out of situations where you'd need to "trick" browsers into playing along.

So today in emergent HTML5 documents we have stuff like this

<!doctype html>



 <html lang="en" class="no-js"> 

or this

<!doctype html>
   
<html class="no-js" lang="en" itemscope itemtype="http://schema.org/Product">
<html class="no-js" lang="en" itemscope itemtype="http://schema.org/Product">

And I get a sickening feeling of deja vu, one that reminds me of the Great XHTML Bust. If you're easily swayed by terms like "MUST be cutting edge technology" and "forward thinking" and "take advantage of HTML5 technology," or are worried some competitor will come along and bash your work for being HTML 4 or XHTML, claiming "that's so last century," then be prepared for a lot of extra work, coding, and heavier documents involved in getting HTML 5 to work.

Take two documents. Do they render differently in HTML4 versus 5? No. An exception is if you NEED to use technologies in HTML 5, such as video without Flash.

If you don't require any specific HTML5 features, and your content is plain HTML, stick with HTML or even XHTML and validate it until the old browsers die out and the web is ready. Your valid (X)HTML documents will be very easy to convert to HTML5.

3. Code your way out of cross browser problems. I just ran across something the other day 'd never seen - a simple form was rendering weird in Chrome, the button was being pushed down an extra em. Even Internet Destroyer was playing along nicely. I found out the "user-agent style sheet" from Chrome was the cause. So I coded another way around it, without using hacks or conditionals. There is always a way if you let yourself see it.

4. Avoid hacks and conditionals. You can't ignore this one with HTML5. But with a validated (X)HTML approach, you can. Hacks and conditionals work, but there always exists the possibility that a future version will break your hacks, now you have to have a hack to fix the hack. It's nonsense. See #3: there is always a way.

That's how I see it, and it's working pretty well.

alt131

9:50 am on Feb 12, 2012 (gmt 0)

Hi joliett89 and welcome to css.

In terms of you specific question about ie, I suggest consider your target market rather than internet percentages. Certain demographics are sloooow to up-date and will remain tied to winxp for quite some time into the future, others will already be primarily using small-screen hardware. If you must indulge in the latest techniques choose between "graceful degradation" and "progressive enhancement" and code accordingly.

Aside from that Rocknbil and I seem to have a similar approach, so unfortunately my comments won't vary much. For general sites without specific needs, some things I would add/reiterate are:
1. Start with your content: Mark it up with semantically correct, valid HTML.
2. Code for usuablility and accessibility - then style.
3. Style for timelessness not current fashion.

On coding specifically, use less, not more - eg:
4. Just because you can, doesn't mean you should. Use the most simple techniques, the most resource conserving methods and the least client-dependent technology possible.
5. Code for what user agents can do, not what they can't. It is fashionable to assume ie is a problem - but no browser conforms 100% - every single user agent is a "problem". As Rocknbil has said, code to avoid issues rather than coding to create them.
6. Code only what you need. The generic resets are a good example - unless you are using kbd, samp, or tt don't waste time/code/bandwidth resetting them.
7. Lose control. Unless you have a specific design issue you don't need to control every pixel, and can't anyway. Make styles flexible enough to accommodate difference - especially the differences you can't possibly predict.
8. Be organised. I agree with Rocknbil about hacks, but if you really must use them or a client demands a newer effect that depends on vendor-specific extension then organise your code so they are easily identifiable and searcheable for when they can to be replaced.

I'm not planning anything special to avoid headaches in the future, but as an example I have a site coded in 2001 that still gets positive comment. Few commercial sites remain unchanged for that long, but zero headaches in more than a decade suits me fine. The timelessness and flexibility of the design and layout draws the favourable responses, but the reason the code is performing with minimal adjustments is because the site was built according to the above principles.