Using the Acid3 test in this context is misleading. Acid3 tests a random selection features to ensure they work corrrectly. In this case, Firefox 3.5 fails on 7 of the tests and 5 of these are due to SMIL (pretty much SVG animation) and SVG fonts. They are obscure features, and don't provide a compelling reason to choose Safari over Firefox, least of all for development where you won't be able to use those features in the real world until other browsers implement them. Whatsmore, in designing Acid3, Hixie deliberately picked on browser bugs so the test didn't favour one vendor, irrespective of how they effect the real world - taking a single number out of context and point at that to prove the innate superiority of one browser over another, or that one browser follows "better standards", is incredibly simplistic, let along drawing conclusions that sites will be easier to port because of it. At worst, all it could tell you is that one vendor is focusing on passing a test and another isn't.
I don't really see the pre-optimisation as a real-world issue, and I seriously doubt bugs creep in through it. It feels very much like somebody making a problem out of nothing.
All projects have long niggles and bugs that have been there since the dawn of time. The fact that Firefox has bugs spanning years is more of a sign that the Mozilla project has been around for years than inehrent tardiness.
I also don't really understand the conclusion that "OS X is the only system that allows me to test all major browsers side-by-side by means of virtualization software". In actuality, if testing is your priority, then Windows would probably be the platform of choice as it's the only platform that can run all the major browsers (IE6, IE7, IE8, Firefox, Safari and Chrome) natively. Linux can also virtualise all the browsers not available natively through virtualisation of Windows, no different from Mac OS X.
Arguably, the only reason why OSX could be considered the only system that test via virtualization is that Apple makes it illegal to virtualize OSX in the first place.
"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.
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?
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).
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:
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.
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 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?
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).
According to the author that just means that you are using the wrong OS for web development, because despite how the world wide web is supposed to be platform independent, there is only one OS for web development</sarcasm>.
Besides a few profiling tools, his list of arguments seems to boil down to "things are prettier in Safari". Maybe it's just me, but that's really not my number one feature when looking at development tools.
Safari's available for Windows and the Mac. That means that 99% of computer users can use Safari.
Since when was "things are prettier" a bad thing? I do extensive Windows testing using browsers, and Safari's rendering engine is leagues ahead of everything else, its developments tools are more polished than Firebug and easier to figure out, and it's one of only two browsers that fully supports HTML 5. Firefox renders things shittily (even on the Mac, which has possibly the best rendering engine out there available for all apps by default, it fails Acid 3 at the moment, and while Firebug's great for some things, at other things it fails hard.
If I develop in a single OS, it doesn't matter to me where else my browser's available. So if I design things without using Linux, Safari's sufficient, and there's no disadvantage to my using it.
Two browsers can each be good without one rendering the other entirely useless. Safari's development environment is in many ways better than Firefox's, so why not use it when you've got it (which is 99% of the time)?
I spend less than 99% of my time under either Windows and OSX. In fact, it's a pain to work in an environment without proper software management (and no, macports and Fink are not enough, at least not for me)
I'm saying that things being pretty is not my primary concern when looking for development tools. It's OK if they are pretty, but that's pretty far down on the list of things I care for.
As for Safari's rendering engine, I see you claim that is "leagues ahead of everything else" on Windows. Are you talking about text-rendering? In that case I would like to comment on how it is different from all the other software on Windows. Running its own anti-aliasing it just stands out and looks weird.
If you are talking about speed, I honestly don't care. Same reason I am completely yawning over Chrome. If you are talking about CSS3 feature-set, I honestly don't care either, because using any CSS3 features while people are still using MSIE would be messing up the experience for about 50% of your visitors.
As for Safari being "one of only two browsers that fully supports HTML5"... You know that HTML5 is only a draft at this point? The spec isn't even finalized. The Acid 3 test even admits this much, saying it's testing features which may or may not end up in a official spec.
Excuse me for not caring very much for Safari, when Firefox is my main browser and does everything I need. I'll test my shit in Safari, but that's as far as I'm willing to go with exposure to craptacular Apple software on Windows.
It looks "weird" because it uses a much better method of anti-aliasing. The Windows system is worse than shit. It is hell for designers because it's impossible to make fonts look anything other than shit without turning them huge, and even then they look like shit. Safari is the shining exception.
I'm not defensive. You're the one who just got into a little minirant. I was explaining why I prefer Safari for development and you returned with the little gems like "Excuse me for not caring very much for Safari, when Firefox is my main browser and does everything I need." You know, some of us here don't comment just to "beat" you. Sometimes we comment because we honestly think you've raised a point worth debating and discussing. I'm sorry for responding to you like you wanted a debate, instead of assuming you were a prick.
If you are talking about speed, I honestly don't care. If you are talking about CSS3 feature-set, I honestly don't care either, because using any CSS3 features while people are still using MSIE would be messing up the experience for about 50% of your visitors.
So there's no room for graceful degradation, then? If CSS3 lets me craft a better user experience for some users, then I'll give it to them. It's why we don't primarily design for IE 6 and its crippled users. We give other users what they want, then focus on stepping down.
As for Safari being "one of only two browsers that fully supports HTML5"... You know that HTML5 is only a draft at this point? The spec isn't even finalized. The Acid 3 test even admits this much, saying it's testing features which may or may not end up in a official spec.
Safari supports what there is at the moment. That's better than Mozilla's "We don't need to do anything re:HTML 5 and our competitors are evil for supporting the standards" line that they touted last year.
I'll test my shit in Safari, but that's as far as I'm willing to go with exposure to craptacular Apple software on Windows.
Ignore all the other stuff I commented on, since it's obvious you'll just disagree and neither of us will get anything out of it. What makes Safari craptacular? Safari 4 on Windows has a native feel, it runs 3x faster than Firefox, uses less memory, has a smoother interface in many ways, and has quite a few features (including that anti-aliasing) that Firefox lacks. Perhaps it's not your choice for a web browser, which is totally coo', but I resent your calling it craptacular and implicitly insulting all the Windows users who think Safari 4 is worth their using.
Wow man, leave this crap on Slashdot where it belongs.
Nearly every statement you've made about Safari has been subjective. You're entitled to that. But there's no reason to lose your lunch when somebody disagrees.
I'll share my own subjectivity that the only thing "worse than shit" right now is your attitude about this.
We're talking about a browser.
And I'll tell you what... FF on Mac is absolutely horrible. I use safari on my mac (at home). When using Windows (at work), I use FF3 and Firebug.
I don't mind going back and forth between them. And I have learned to accept that fonts do look fuzzy in Safari and the dev-tools in FF are sub-optimal.
Sometimes we comment because we honestly think you've raised a point worth debating and discussing. I'm sorry for responding to you like you wanted a debate, instead of assuming you were a prick.
In that case, I guess I read your comment wrong. Sorry about that.
It looks "weird" because it uses a much better method of anti-aliasing.
It's still different from everything else on the platform. To me that's a bad thing. Maybe not to you, maybe not to designers, but to me it is.
So there's no room for graceful degradation, then?
There is. But in the meantime I've found that I can cover lots of browser shortcomings trough jQuery instead of CSS and browser-specific hacks. Definitely not ideal, but it works. When CSS3 gets here, I'll prefer that instead.
Safari supports what there is at the moment.
I'm not against progress, but even Firefox has limited HTML5 support these days, and it's really not a major selling point for me as of yet.
What makes Safari craptacular? Safari 4 on Windows has a native feel
I actually had to check this out. Seems you are actually right. Historically though Apple has always tried to cram the Apple look and feel down my throat when it is obvious I don't want a Mac, giving me a non-native interface. I resent that.
That said, the fact remains that it is simply not what I am looking for in a browser (see my other post [1]).
As for my main complaint (with regard to the software being crap), my Core i7 is the first machine which iTunes is actually responsive and non-laggy on. I was genuinely surprised when I discovered that. I had to get a 2GHz Dual Core machine before Quicktime could play things fullscreen without skipping. My 200MHz Pentium MMX could that without CPU load.
When I refer to Apple software on Windows as craptacular, that is because they have quite a history for being just that.
Prettiness? If it blends in with the native look of the OS, that is "pretty" to me. Safari fails at this. Firefox does not.
Speed? I have a Core i7 idling at 1% CPU all the time, unless I'm doing HD video encoding. Even on my Core2 Duo, I can't remember last time I was CPU-constrained when browsing stuff. Why on earth would I care about speed?
Standards compliance? Firefox is top notch, and while Opera and Safari may go full 100% on ACID3, that is for a spec which is not even finalized and standardized yet. Anyhow, you need to keep MSIE in mind when developing stuff, so this point is pretty moot.
So what do I care for in a browser?
Stability, that it works intuitively, that it's configurable, that it sports a decent feature set, keeping mouse-dependency to a minimum and that most operations apart from link-clicking can be done trough keyboard operations and probably most of all: that it is extendible and that I can add whatever crap I feel I need in a browser. Things like Ubiquity, Firebug, Flashblock, Adblock, Rikaichan, Mousegestures, Greasemonkey, custom dictionaries and Bugmenot.
I pretty much think that the browser should supply me with the core basics, and let me decide from there on what I think a browser should be. If the browser is going to be the "OS of the web and the future", you better believe I want to have a browser which I can make mine.
Edit: Evidently Safari 4 actually sports a somewhat native interface in Windows.
I've recently switched to Safari as well, for a very simple reason. Firefox performance was just too bad to deal with any longer. The combination of nutso RAM / CPU it took was bringing everything else on my machine to a slow crawl.
I'm developing a web service that spits out json. I dropped Safari immediately because it automatically downloads anything that is application/json, whereas Firefox will display it and syntax highlight it with the JSONView plugin [http://ajaxian.com/archives/jsonview-json-browser-from-withi...].
Despite the great improvements Safari has made with respect to its developer tools, it can't top Firefox's amazing third-party plugin selection.
I really want to use Safari for debugging but every time I get down to trying to do so, I find some irritating hangup in terms of clunkiness and polish versus Firebug, and I end up heading right back to Firebug. Two things off the top of my head:
1) console output is just not as good as Firebug. Example: try going on jquery.com and doing console.log($("p")). Instead of a pretty printed array with styled items as in Firebug in the form of <p>, with all their classes and ids and visibility status hinted in the rendering, you get an expandable HTMLParagraphElement object (and its name doesn't even respond to a click..). If you expand that, the first thing you see is a big list of DOM constants like DOCUMENT_FRAGMENT_NODE: 11, etc. In Firebug these are sorted, filtered, censored to fit to the way web developers actually work.
2) I've never been able to resize the Console/Debugger when displayed as a split pane in the Windows version. In OS X, it seems to work, but in Windows, nothing. Again, a huge irritant when you're trying to get a better look at something that's gone wrong.
Nit picks? Yes. But some of us work with these things many hours a day. Workflow issues and missing little details like these prevent my uptake of the otherwise very impressive developer tools in Safari.
I use both Safari and Firefox for my web development. Safari's web inspector has a nicer user interface for javascript debugging, but Firebug has better support for editing CSS on the fly.
It took me awhile to figure this out, but if you double click on the element styling you want to add additional CSS to (for example, the right column shows #content p has "color:#bbb;", double click on the "color:#bbb" part), add semicolons and the new style after the old one. (with the example the single line textbox should have "color:#bbb;padding:2em;") It'll correctly parse and add the new styling.
OK, maybe I'm stupid or slow, but there's something I just don't get about "browser wars".
Exactly where does it say that HTML, CSS, & Javascript has to be source code? If browser differences cause you so much grief, why don't you just treat whatever goes out to the client as "object code" of your own engine.
That engine would have to create a different page for each browser that you decided to support. Sure, it would be 4 times the work for every page, but that's work done by your engine, not you. Browser differences are accomodated through maintenance to your engine, not every page or library.
IE is not going away any time soon, so your output better be able to handle it's DOM. While you're at it, take a look at your user's resolution as well, and serve it the way they want to see it, not what you decided is best. No one likes horizontal scrolling or white space on the edges.
That's an interesting idea. The problem with it is that it takes a very long time and, depending on the OS being used to develop, would be a pain to work with. I'd have to be in Windows constantly to test the IE pages as I built them, and since there are 3 separate Internet Explorers I'd probably have to build 3 separate pages. If you combine both browser usage and resolution detection, suddenly I've got to make a dozen pages for every page on my web site, which is time consuming and not exactly a comprehensive approach either.
This approach works for the iPhone, which is standardized completely, but not for the complex and varying desktop browser scene.
If browser differences cause you so much grief, why don't you just treat whatever goes out to the client as "object code" of your own engine.
You mean like, swf?
Browser differences are accomodated through maintenance to your engine, not every page or library.
You mean like, by adobe?
While you're at it, take a look at your user's resolution as well, and serve it the way they want to see it, not what you decided is best. No one likes horizontal scrolling or white space on the edges.
Well if these are your priorities then I suggest to take a look at Flex.
You limit your audience to clients who have the plugin - but other than that it just works™.
The RGB thing also drives me completely crazy to the point that I have started muttering obscenities under my breath like a mad man every time I see one.
Do most browsers actually support hsl/hsla? Never actually paid attention to that. Would certainly be nice... though I've already put the conversion code in CP.
I recently switched from firefox 3.0 to safari 4 beta when it first came out, and then back to firefox 3.5.
Originally I switched to safari 4 beta because I'm on a machine that has limited ram and firefox 3.0 would buckle my system. Safari 4 is slick and runs much lighter and faster than firefox 3, however firefox 3.5 really levels the playing field and makes the comparison about features rather than resource consumption.
When you compare the two on features, safari is lacking. While safari has clean tools built in for web development, they are more for looking at a page rather than messing around with it. I find it a pain to go and change styles or elements in safari and also you can't delete elements out of the dom in safari which I find very annoying. Firebug is not as polished looking, but it definitely has the best set of features. Also firefox's extensive set of plugins is tough to live without.
I enjoyed my time with Safari, it was a very elegant polished experience, but web hacking is rarely both, which is where firefox and its plugins feature set really shines.
Almost. You can edit CSS styles, but not add new ones. You can add attributes (style=) to elements. It's been extremely clunky for me, but I have hope it'll be smoothed out in the future.
I know I risk getting downmodded to oblivion, but the developer tools in IE8 have actually brought me back to using IE for development some of the time. There are some specific features that are very handy - the debugger is awesome - better than the one in firebug. The CSS tracing features are even better than FireFox's for some specific situations. I now probably spend about 20% of my time in IE when developing pages (as opposed to almost never except for one off checking prior to IE8).
I like Safari's dev tools, but its missing some really basic stuff that Firebug makes easy.
In Firebug, you can double click on anything in the dom view and edit it. In the CSS view, you can easily add new attributes. The autocomplete for CSS styles is awesome.
Also, you can grab any asset file (css, js) and open it up in your default text editor.
Safari 4 web dev tools isnt quite there. It only needs a few tweaks, but they don't seem to be adding them anytime soon (people have been asking for these features for about a year now).
In addition to using Safari for rich web development, I assume we should all be using Textmate and working on our Macbooks in dimly lit coffee shops.
Give me a break. Use whatever you want to use for web development. As long as whatever you're doing works across _all_ A Grade browsers, I could care less what you use.
The only thing Firebug has over Safari is adding styles to a page. That's pretty huge when you are trying to get something to look right without 4 million page reloads. It's only one thing, but it's pretty huge.
Is it my impression or this is one more of those "Why I do X and why everybody should do it too because if they don't they are doing it completely wrong" posts?
Micro-Optimizations are bad? That is just a load of shit.
If you can prove that Firefox's optimizations actually make incorrect results in any way, I am 100% behind whoever claims that micro optimizations are bad. However by firefox making them it means that I don't have to worry about the nitty gritty details about what order of instructions will perform better without changing the code. Or things like loop unrolling that don't have to be done in my checked in source.
Yea I think this argument is about 30 years too late...
If anything this proves FF3 is awesome.
Regarding web standards... As much as I am 100% for having good web standards, what good is adhering to a standard when no one can use it. I use the acid tests as an indication that browser x, y and z are browsers I want to be supporting. Unfortunately I always have to support IE... Sometimes even IE6, so acid tests are just nice-to-haves at this point. I just can't wait till IE7 completely dies (hopefully it won't be as long as IE6).
Micro-optimizations aren't bad for users, but they can be bad when you're debugging. The source code you wrote is not necessarily the source code that Firefox displays to you.
> However by firefox making them it means that I don't have to worry about the nitty gritty details about what order of instructions will perform better without changing the code
Actually, Firefox benefits the most from tweaks like this, because its engine is so slow. For whatever reason. That's why I thought this post was interesting!
A good point. If the FF engine is so slow it needs this, then the engine needs help.
However I see no reason why you should not be able to indicate to firefox that for this page do not optimize the javascript, then vuala good debugging. The only catch is that the optimizations need to be proven to be correct in all cases.
Once we have Safari for Linux I will consider using it as the main browser...
Scratch that, once at work we officially support it ill consider it :)
The whole "This is the best thing EVAR!" articles really need to die.
In general the "best" tool is whatever one is best for the current job. Fortunately in the Webdev world our tools are free and easily accessible.
I personally use Safari, Chrome, Firebug AND IE8 (seriously, the built-in developer tools are actually decent!). Usually I start with Firebug, and if I run into a small issue instead of wasting time trying to fix the tool in that case I just try another tool. Usually one of the tools will handle the case with no problems and I can continue debugging/developing my core project instead of debugging the tool.
Using the Acid3 test in this context is misleading. Acid3 tests a random selection features to ensure they work corrrectly. In this case, Firefox 3.5 fails on 7 of the tests and 5 of these are due to SMIL (pretty much SVG animation) and SVG fonts. They are obscure features, and don't provide a compelling reason to choose Safari over Firefox, least of all for development where you won't be able to use those features in the real world until other browsers implement them. Whatsmore, in designing Acid3, Hixie deliberately picked on browser bugs so the test didn't favour one vendor, irrespective of how they effect the real world - taking a single number out of context and point at that to prove the innate superiority of one browser over another, or that one browser follows "better standards", is incredibly simplistic, let along drawing conclusions that sites will be easier to port because of it. At worst, all it could tell you is that one vendor is focusing on passing a test and another isn't.
I don't really see the pre-optimisation as a real-world issue, and I seriously doubt bugs creep in through it. It feels very much like somebody making a problem out of nothing.
All projects have long niggles and bugs that have been there since the dawn of time. The fact that Firefox has bugs spanning years is more of a sign that the Mozilla project has been around for years than inehrent tardiness.
I also don't really understand the conclusion that "OS X is the only system that allows me to test all major browsers side-by-side by means of virtualization software". In actuality, if testing is your priority, then Windows would probably be the platform of choice as it's the only platform that can run all the major browsers (IE6, IE7, IE8, Firefox, Safari and Chrome) natively. Linux can also virtualise all the browsers not available natively through virtualisation of Windows, no different from Mac OS X.