Hacker News Reader

Comment by ruddzw | Hacker News Reader

"Basically, if some HTML/CSS works on Safari, the chances are very high it will work on Firefox 2 and higher, and on IE 6 and higher (with minor tweaks)."

I don't get it. A lot of the hardship that comes with web development is that stuff that works great in modern standards-based browsers like Safari doesn't work when you try to view it in IE. I can't count the number of times I've taken a webpage that I developed to work in Safari (or Firefox) and seen it break completely in IE. And it often takes more than "minor tweaks" to fix it.

View on HN

I'm new to web development, and I keep asking this question but I've never heard and answer to it:

What's stopping us from making a tool that parses HTML/CSS and points out constructs that are known to be bad in certain browsers? Sort of like lint: "It looks like you're sending element foo inside element bar to IE6. This probably won't work right"

I personally don't have a windows box to test IE, and I'm not looking forward to the day when I'll have to test on IE. Surely there is a better solution than manually testing browsers?

It would be cool to have HTTP proxy software that did this. So you set it as 'ie6' and it looks at your CSS and HTML and translates it into the "ie6 view" with problems annotated.

I suspect this kind of thing is a lot harder than it sounds.

There are a few things you could catch, like CSS features that just don't exist in IE6, but trying to predict if your particular mix of content+HTML+CSS is going to "look wrong" when viewed in IE is not a trivial problem.

You could probably match some patterns, but things can get really complicated when you introduce javascript into the mix. All of a sudden your tool needs to test every button on a page to make sure your ajaxed data tables won't blow up your layout.

Also, web development tends to push the envelope often. I've built literally hundreds of web sites / apps and I still come across nasty unexplicable post-ajax redraw bugs in IE6 that I've never seen before (using markup that I used to consider "safe", but which turns out to break under a new novel condition).

have you heard of ie7-js? it uses javascript to fix many such problems.

http://code.google.com/p/ie7-js/

I realise you're hoping for a better solution than manual testing and I can assure you, so is everyone else. However, if you do not have a real or virtual Windows box to test on, you might find these links of interest:

http://www.browsrcamp.com/

http://www.browsercam.com/

Yea this line also baffled me. I love safari and I use it for my development, but I didn't understand his reasoning behind this.

Evidently, the author got a bit carried away there. The implication that just because your HTML works in Safari means that it'll also work in IE or Firefox with "minor tweaks" is simply bogus. Anyone with any significant web development under his/her belt would vehemently disagree. I think the author is just an ardent Safari user. That's all good and dandy if you ask me. However, we should call it for what it is: that was a blanket statement. As such, it lacks verifiable, factual information.

The only way I can see this is when talking about Firefox. I have built stuff using Safari and when I test it out in FF my padding is off by like 5 px or something silly.

Using another browser like IE usually breaks the whole thing.

If you happen to like inline-block (which I do), you’ll break FF 2 fairly reliably, as well.

+1 for inline-block

I've always used -moz-inline-block for FF2, and it has worked for me so far, although PPK warns that it's not always the case: http://www.quirksmode.org/css/display.html#inlineblock

But at this point in time, I'd drop FF2 support (pixel perfection) for most projects.

Indeed. Sounds very much backwards to me.

If anything, stuff developed to work with the restricted CSS-support in older MSIE versions (MSIE8 is actually not that bad) has a much higher chance of rendering correctly in Firefox, Opera and Safari than the other way around.

It may sound backwards but is it not. It is a broad topic and much can be said on this, but the short version is: it is always advisable to develop looking at more standards compliant browsers and then tweak it to work in IE. Usually it will take less effort.

The reason for this is that IE let's you deviate more from standards, and then fixing it for other browsers will take more time. Also, other browsers albeit having own quirks are much more consistent – that means that if it works in Safari it is most likely to work in Firefox and Opera too.

Of course IE does not support a lot of things other browsers do. Maybe it is time to weight you options there: are you sure you want site to look the same across all the browsers and is it worth the effort? Or can you live with simpler version for IE but gaining advantage of having to write and maintain less code?

Highly recommended site ;) : http://dowebsitesneedtolookexactlythesameineverybrowser.com/

While I can see your point, my approach is more of a middle way.

I use a up to date standard compliant browsers like Firefox 3.5 when developing sites, but I keep the my CSS restricted to what I expect will be supported in MSIE. If I go overboard with new CSS features, I know I will be creating a much bigger job trying to fix it for older browser (like Firefox 2.0, not just MSIE).

I find that so far that has worked well for me.

Reply on news.ycombinator.com