Rytis writes "Opera has just become the second browser after Safari to be able to pass completely the famous ACID2 test. Mark Wilton-Jones is running a little article on the history of the Opera and ACID tests. Of course, it includes a screenshot of Opera 9 showing the nice happy face saying "Hello world!"."
Actually, Konqueror passed second. Some might say this is less of an achievment since the fixes that allowed Safari to pass could be more easily ported into the Konqueror codebase, but I still think the OSS project that passed Acid2 first should probably get more respect on/.;)
RTFA and you'll see this. "Opera 9 (get the weekly build) now passes the Acid 2 test, making it the second browser to do so. And yes, I can count. Safari passed first, and Opera is second. Konqueror and iCab almost pass (and claim to pass), but they both fail to apply one of the styles required by the test..."
I don't know, but Konqueror does indeed appear to pass the Acid2 test [imageshack.us]. The only problem I can see is this odd scrolling bug [imageshack.us], but that probably isn't supposed to be able to scroll anyhow.
I was merely pointing out what the article said. And since the Opera guy points out the page *isn't* supposed to scroll, I imagine a scrolling bug would indeed qualify as incorrect rendering, so the artifacts in your screenshot would merely support Opera's point.
Actually they care a lot about it - see Bug #289480 [mozilla.org]
It's just such a complex problem to tuckle that it seems to me (as a sideline spectactor) to be stupid to block the entire Firefox train just for it. They are working on it.
I'm not much of a MS fan myself, but can you really say "paraphrased without bias" and not be trolling?
From your link: "I want to be clear that our intent is to build a platform that fully complies with the appropriate web standards, in particular CSS 2 ( 2.1, once it's been Recommended)."
Its not really paraphrasing when you make up ideas. That's called "reading between the lines", and you didn't even do that.
It's not supposed to have a scrollbar at all. The parent div (or html or body - I haven't checked the source for a while) is given a property of overflow: hidden.
That's not a bug, that's exactly what is supposed to happen when you scroll the page. From the technical guide [webstandards.org]:
In the markup, the row is represented by a p element which is fixed to the window rather than the scrollable canvas. If the Acid2 page is scrolled, the scalp will stay fixed in place, becoming unstuck from the rest of the face, which will scroll.
I don't think this should be judged based on how much of an achievement it is. The important part is that the browser passes the ACID2 test. How hard it was for each individual browser to get there is not important.
Who got there first also isn't important, we just need all browsers to get there.
by Anonymous Coward
on Sunday March 12 2006, @12:47PM (#14902871)
> I'm all for web standards, but isn't ACID2 a purely academic excercise? It's nice that a browser passes it, > of course, but in the real world practically nobody is going to be using CSS in that way.
It's not purely academic, it's eminently practical - as the site explains, all of the features are unlikely to be used on the same page, but designers rely on each one of them to work correctly at some point, and have been requesting proper support for years so their pages look consistently good on all browsers.
"Konqueror and iCab almost pass (and claim to pass), but they both fail to apply one of the styles required by the test, and as a result they display a scrollbar even though they shouldn't (the Acid 2 guide neglects to mention this style, but see the source code for the test itself):
html {... overflow: hidden;/* hides scrollbars on viewport, see 11.1.1:3 */... }"
Well, since KHTML and KJS (I think?) were ported over to Mac OS in the first place in order to create Safari, which then allowed the Apple devs to create the patches that allowed it to pass Acid2, patches which could not then be easily applied back to KHTML and KJS because the code sometimes didn't meet KDE's standards or because the patches were sometimes not supplied in a format that they could easily work with, maybe the KDE devs put in more effort overall:-P
But seriously, who gives a shit who came first, second or whatever; I think the important thing is that browser developers are obviously making an effort to ensure stricter standards compliance. I assume someone must be working on this for Firefox, so does anybody know when we can expect to see Firefox pass Acid2 as well?
https://bugzilla.mozilla.org/show_bug.cgi?id=acid2 Track Gecko progress here. Including screenshots. Link as plain text due to/. referers being blocked.
In a discussion about the Acid2 test, you claim that Safari isn't free software:
WebKit, the rendering engine Safari uses, is an open source project. Safari itself is very much closed source.
But the frontend code isn't very relevant to this discussion. Safari passes Acid2 if and only if [wikipedia.org] WebKit passes Acid2. Or do you claim that Apple maintains a private WebKit tree with patches that don't get released to the public and that one or more of the private patches is required for WebKit to pass Acid2?
Great that they pass the ACID test, but the real-world is just not perfect or by-the-book. They need to be able to handle what really happens, too.
Example, my workplace Exchange web interface- Safari misses parts of the page, FireFox renders it fine. ACID test or no, I like the one that works in all situations.
by Anonymous Coward
on Sunday March 12 2006, @10:24AM (#14902393)
Could you be a little more vague? It's not unexpected for browsers with different rendering engines to render things differently, especially for web interfaces, very especially if it comes from Microsoft.
Moreover, it's a fallacy to expect a browser to "work in all situations". I'm sure there are plenty of real-world situations where Firefox fails as well, and where Safari were to succeed in it's place. It's tests like ACID2 that determine a browsers capability to handle all situations.
The problem Safari is having with Exchange is very likely due to poor coding. Considering it's from Microsoft (you said Exchange web interface, right?), I'm sure Microsoft implemented a slew of hacks to have Firefox compliance (Microsoft is well known for improper web developing practices, to put it lightly).
Safari's DOM API is very incomplete. Probably only about 60-70% of what Firefox implements. Oprah's worse, maybe only 30-40%
I haven't found that. Firefox is ahead on some things and behind on others. For example, Safari supports DOM 2 mutation events, but Firefox doesn't.
As Internet Explorer has shown, having a solid JS DOM is much more important than supporting every CSS corner case.
You're joking, right? Internet Explorer's DOM support is prone to memory leaks and doesn't support basic things like event handling. I'd rephrase your statement as:
"As Internet Explorer has shown, having the largest market share is much more important than supporting most of the CSS or DOM specifications, because that way the web developers work for you, not the other way around."
I think that a lot of people have blind spots, where they are completely unaware of many parts of the specifications, because they don't work in Internet Explorer or Firefox.
IE does support event handling, it just doesn't work the official way.
It doesn't support event handling as defined by the DOM specifications. My comment is perfectly clear when you don't cut the quote off prematurely.
Referring to Internet Explorer's proprietary DHTML interface as a "DOM", while technically accurate, is misleading as in common use, the term "DOM" refers to the W3C specifications.
boohoo.
How about a little maturity?
As for memory leaks, FF DOM has the same kinds of issues.
a) No it doesn't, many Internet Explorer memory leaks [microsoft.com] are an artifact of the JScript engine being unable to refcount properly.
b) You implied that Internet Explorer had a "solid" DOM. That is not true regardless of the quality of Firefox's DOM. Internet Explorer's DOM doesn't get more "solid" if you distract people by talking about other browsers.
ACID test or no, I like the one that works in all situations.
First off that one hasn't been built, as I've seen IE manage to screw up royally too on sites claiming to work with IE, sometimes only with IE. The trouble with trying to match IE bug for bug is that you can't succeed as you can never duplicate the implementation exactly, you need to render pages wrong according to the standard, and worst of all it is never predictable. I really hate "trial-and-error" programming, and IE is the worst of the bunch.
In your case, you're trying to use MS generated HTML. I'm sure the fact that Firefox can render it is completely accidental and will be fixed in the next Exchange service pack. You can't expect a company that has a vested business interest in not playing nice, to play nice. The ACID2 test is an assurance that if I code to the standard, I will see none (or at least very few) rendering issues on any browser (except IE). That is very reassuring to people who think "OMG supporting five browsers, do I have to make 5x the number of hacks?" No, you don't. In fact, you'll code to one standard and fix hacks for one browser. Which is actually better than to code to zero standards and fix hacks for one browser...
Example, my workplace Exchange web interface- Safari misses parts of the page, FireFox renders it fine. ACID test or no, I like the one that works in all situations.
There are a lot of crappy pages out there. If a page doesn't make it through the HTML validator why should anyone expect a browser to render it? Are your pages at work valid? What's the point of standards-compliant rendering engines if they all allow exceptions to the standard to be rendered?
A lot of times Safari won't render big chunks of web pages because of malformed markup [mozillazine.org]. Dave Hyatt (rightly, I believe) doesn't want to spend lots of coding effort dealing with error recovery when parsing sloppy web pages. Browsers like MSIE and Netscape (pre-Mozilla) are too permissive and have allowed people to get away with downright bad HTML.
That said, the Safari Compatibility Hit List [opendarwin.org] was recently created, to either fix Safari compatibility problems or to encourage sites to fix their markup.
by Anonymous Coward
on Sunday March 12 2006, @10:52AM (#14902497)
I agree with you on that. It can pass all the certifications it wants, but until Opera supports some of the more basic javscript methods IE and FF have no problem with, it will never be my browser of choice.
The problems with Opera's JS arise in three situations:
1) The site specifically blocks out Opera due to scripts 5-6 years old, but happily copypasted throughout the web project by brainless "web designers". Or server-side sniffing, like Yahoo did and still does, AFAIK.
See here for example, one that I found just a few minutes ago when informing myself of the latest and greatest Bollywood hit: http://www.rangdebasanti.net/ [rangdebasanti.net]
Their JS code contains this:
var dom=document.getElementById&&navigator.userAgent.i ndexOf("Opera")==-1... if (ie||dom)...
Use Proxomitron or Opera's cloaking techniques to get rid of the "Opera" part in UA string, and what do you know, the site works perfectly!
2) The site doesn't block Opera per se, but exhibits "if IE or Netscape" behaviour. Of course Firefox deals with those, as it descends from Netscape. Opera doesn't, and Opera is not IE, either, so it end up in no man's land...
3) The site has JS errors, and Opera is pretty strict when parsing JS, more so than Firefox or IE.
Honestly, Opera does not have any JS issues. None whatsoever. It's brainless webmonkeys who have issues with their JavaScript.
What's more interesting, will it pass ACID3? It's easy to tweak the engine untill it passes a single known test. Historicaly, Opera had (and still has?) problems with both JavaScript and CSS. I must admit though, that the rendering in Opera 8 (pre ACID2) is much better than Mozilla's.
Opera 9 still displays visual artifacts when using DHTML/DOM Scripting/(whatever people are calling it this week). I recently coded up a quick demo for a bigger project - the demo allowed an image to be uploaded, resized and moved about using Javascript, then "stamped out" by using js+php. I only tested Opera out of interest as It's always been pretty flaky with Javascript/CSS. Moving images with the mouse was fine, but resizing (in the app, this was done by grabbing a corner and moving it) resulted in pixel trails which looked kind of cool, but were not supposed to be there. The "fix", was to continually change the z-index of the image as it was being resized, causing Opera to refresh the canvas.
The reason Opera is "victimised" by older scripts is due to the ridiculous decision of that company to add code stubs for functions it did not actually support (I remember when it had document.getElementById(), which always returned null - that's why many scripts look for the Opera string, and block it).
A big well done to the Opera team. Safari passed the test in November last year, and hopefully Firefox will pass soon as well. Increased standards compliace is a Good Thing(tm) for users and webmasters alike. If the minority browsers continue to push standards (which the tech-savvy webmasters follow) it will push IE into improving its own rendering engine. Although even their unreleased version seems to be a bit behind the times...
From TFA:It is somewhat worrying that IE 6 renders Acid 2 very similarly to Opera 3.6, and the hyped IE 7 renders it very similarly to Opera 4.
'Somewhat worrying' indeed. I know people (of the pretty-damn-computer-literate variety) that won't switch from IE6 because it "works fine for them". I'm sure they know about the vulnerabilities [now that Symantec says so, it must be official!], the rendering issues and speed*, but they are sticking to their guns. So the only way people like this will have their experience enhanced is by teams like Mozilla and Opera pushing the browser envelope and hoping IE take interest. Either that or some X factor that makes the alternative browser a 'killer app', rather than IE, which is an app killer. (I couldn't resist, sorry!)
Well done again to Opera. Webmasters everywhere are silently saying a big 'thank you'.
*Note: I am aware that some will say that IE 6 loads quicker/renders quicker than FF. I have found the two of comparable speed for light pages, and FF slightly faster for 'heavier' pages. Opera is faster than both of them. Draw your own conclusions, and install all three (or two if your run a non-Windows OS). I found an old demo disc with IE 3 recently, and will be trying that out.
I am happy to see that Internet Explorer 7 passes the ACID2 test somewhat better now. It is actually possible to see the resemblance of a happy face now. Good job, Microsoft!
Opera has just become the second browser after Safari...
Second browser after Safari? Which was the first after Safari to do it? Oh, you mean the second browser, after Safari...It's amazing what commas can do. Learn to use them.
Can you be more specific what's not handled correctly? I can block third party cookies, I can manually delete third party cookies, and I can allow them, and the cookie settings seem to reflect they're not added when they should, and respected when they're allowed. If you're talking about a specific bug here, you must be much more clear about what you're talking about.
Mark Wilton-Jones is running a little article on the history of the Opera and ACID test
There's a more useful history about it here [timaltman.com] (in reverse chronological order), describing what exactly the standard compliance problems were, and how they fixed them, starting with Opera 8.00.
And go to the Opera Desktop Team blog [opera.com] to download the actual build that works with this. However, note that this build should be treated like a Firefox nightly, and there may be some pretty serious rendering regressions, doing currently more damage to the layout engine than good from following the Acid2 test.;-)
Firefox is good. The plugins extend the browser hugely.
But I'm happy with Opera, be it for the faster responce I get on the same machine as I have Firefox installed on, the ability not to search for plug ins for whatever feature I need, 'it just works'
I just find Opera is faster at implementing standards, is more reliable with IE geared sites (don't like the fact, but I have to be pragmatic and deal with it as promoting interoperability is not what pays my bills), is more innovative (has important new features first and has them 'out of the box') and makes a good testing ground for my projects, and is all together very nice. And now it's free (as in beer).
Firefox is good. Opera is good too. Different priorities for different users, I don't have access to source code or the ability to contribute in the same way, but for me I'm fine with that. Both are far superior to IE's features, security and map for an interoperable internet in the future. Nuff said.
According to WaSP (the people who wrote the Acid2 test), [Browser not for Microsoft Windows] passed first, followed by [a second browser not for Microsoft Windows] and [a third browser not for Microsoft Windows]. [...] That makes Opera the 4th browser to render Acid2 correctly.
It also makes Opera the first publicly available web browser that renders the Acid2 page correctly under the Microsoft Windows operating system. This is important if you don't want to have to re-buy your PC (in switching to Mac OS X, which runs only on Apple hardware) or your peripherals (in switching to Linux, where SANE still doesn't support my flatbed scanner [sane-project.org]). Or is Konqueror for Cygwin/X considered stable yet?
I can clearly see the blue nose in the opera screen shot, and it's meant to be black in the reference diagram.
The nose changes color when you mouseover it. Even in the mess that is Firefox's rendering of the page [webstandards.org] hovering your mouse over the face causes the nose to change colour from black to blue.
I guess that's something they really should specify in the reference diagram, but it's still a pass for Opera 9.
The point is that the CSS spec specifies exactly the behavior a browser should use to handle invalid CSS: It should ignore the declaration, but continue to parse the file. A browser that accepts invalid CSS declarations, or fails to recover and continue parsing is not conformant.
So the test is verifying conformance not only with treatment of valid CSS, but also correct treatment of invalid CSS, which is very important given that a significant part of compatibility problems between current web-browsers is caused by different behavior in the face of errors - whether they ignore it, stop parsing, try to render it anyway etc.
I've barely been making websites a year, and even I've learned that on the web, markup standards are only a guideline.
Then maybe you should stop making websites, because people like you are the problem.
They're "only a guideline" in that the FBI won't knock on your door if you don't follow the standards. And oh yeah, a lot of browsers will accept your sloppy coding and "render it fine." However, if you want a world where all browsers render all content in the same way, that can't be accomplished by the developing team of any browser. That can only be accomplished by developing and following standards. So, you blame the browser when they don't follow them, and you blame the web developer when he doesn't follow them.
I'm fine with browsers who want to go the extra mile and have non-standard code render correctly, as long as they don't sacrifice proper rendering of the standard code to do it. That doesn't excuse you coding incorrectly, though.
I really d I really don't see how I can be considered part of the problem.
Well, it's great that you do all that work to consider your visitors. What I was referring to was your comment that following standards isn't really that important, it's just a guideline. That train of thought is part of the problem.
Think of a world where every browser renders everything in the standard correctly. Suddenly, your job is easier. In order to make sure that your web page renders correctly for the visitors using IE, Firefox, Safari, Opera, Konqueror, whatever, you don't need to actually test it with each one of those browsers. You just need to make sure your site follows the standards, and the rest "just works". If you skip out on things because "they're dumb," well, you may think you're right, but why do you expect browser developers to share your opinion?
You'll see 12 ridiculous errors
Depends on your definition of ridiculous. You wouldn't expect c code that doesn't have syntax exactly right to compile, so why do you expect html syntax that isn't exactly right to render correctly?
from things like > characters whose position it disagrees with
I didn't find that. I found error #3. It's not complaining about the position of the character, it's complaining that you placed that tag inside your unordered list, but not within a list item tag. I checked the source code and you have:
<ul id="utabs">
<a href="?page1"><<</a>
If it's part of the unordered list, it should be inside a <li> tag. If you don't want for that to appear the same as the other list items, you should give it a class attribute and handle it in your css (there are other correct ways of handling it too, if you don't like that for some reason).
That and a childish remark about my html tag which was funny for the 1.3 seconds I spent writing the top line...
It wasn't your remark that it complained about. It complained about your type. That's not how you specify 4.01. From a W3C page, there's this example, using SGML to do what you want (for strict 4.01).:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
Heck...you should be fine just skipping that altogether. Close your html tag, and don't put the type thing.
errors that don't tell me anything useful or constructive at all
The validator doesn't tell you how to fix it, just that it found something wrong. However,
a wikipedia url I pasted, which the validator decided to parse and rate
For that error, the validator told you exactly what was wrong...in bold. "The most common cause of this error is unencoded ampersands in URLs". I've actually noticed that in other places in your html code for that page, stuff that I expected the validator to complain about, but it didn't.
In html, if you want to have a "<" or ">" that is not part of a tag, you use a code. you type in "<" for < and ">" for >. If you want to type "&", you type "&" Replace the & in that url, and it'll pass. You should replace the <'s I mentioned in error #3 with the correct codes too, even if the validator doesn't complain about it.
I'm not trying to be a bastard about it. I hope my comments help you understand the validator better, and see that it's not so useless as you've come to believe. It's great that you've been putting effort to make sure your visitors get the best experience they can on your site, and I hope you'll keep doing so.
Konqueror passed 2nd (Score:4, Informative)
Info here [kdedevelopers.org].
Re:Konqueror passed 2nd (Score:5, Informative)
"Opera 9 (get the weekly build) now passes the Acid 2 test, making it the second browser to do so. And yes, I can count. Safari passed first, and Opera is second. Konqueror and iCab almost pass (and claim to pass), but they both fail to apply one of the styles required by the test..."
Parent
Re:Konqueror passed 2nd (Score:5, Interesting)
Parent
Re:Konqueror passed 2nd (Score:5, Informative)
Parent
Actually Firefox do care a lot about Acid2 (Score:5, Informative)
It's just such a complex problem to tuckle that it seems to me (as a sideline spectactor) to be stupid to block the entire Firefox train just for it. They are working on it.
Parent
Re:Konqueror passed 2nd (Score:5, Insightful)
From your link:
"I want to be clear that our intent is to build a platform that fully complies with the appropriate web standards, in particular CSS 2 ( 2.1, once it's been Recommended)."
Its not really paraphrasing when you make up ideas. That's called "reading between the lines", and you didn't even do that.
Parent
Re:Konqueror passed 2nd (Score:4, Informative)
--
onedotzero
thedigitalfeed.co.uk [thedigitalfeed.co.uk]
Parent
Re:Konqueror passed 2nd (Score:5, Informative)
That's not a bug, that's exactly what is supposed to happen when you scroll the page. From the technical guide [webstandards.org]:
Parent
Re:Konqueror passed 2nd (Score:5, Informative)
From what I've read here, Konquerer still shows the scroll bar, and Opera doesn't have the scalp come off when you scroll.
So, Safari passes, everything else still got some work?
At least they all pass a hundred times better than IE...
Parent
Re:Konqueror passed 2nd (Score:5, Insightful)
Who got there first also isn't important, we just need all browsers to get there.
Parent
Re:Konqueror passed 2nd (Score:5, Insightful)
> of course, but in the real world practically nobody is going to be using CSS in that way.
It's not purely academic, it's eminently practical - as the site explains, all of the features are unlikely to be used on the same page, but designers rely on each one of them to work correctly at some point, and have been requesting proper support for years so their pages look consistently good on all browsers.
Parent
It claims to but fails (Score:5, Informative)
"Konqueror and iCab almost pass (and claim to pass), but they both fail to apply one of the styles required by the test, and as a result they display a scrollbar even though they shouldn't (the Acid 2 guide neglects to mention this style, but see the source code for the test itself):
html {
Parent
Re:Konqueror passed 2nd (Score:5, Interesting)
But seriously, who gives a shit who came first, second or whatever; I think the important thing is that browser developers are obviously making an effort to ensure stricter standards compliance. I assume someone must be working on this for Firefox, so does anybody know when we can expect to see Firefox pass Acid2 as well?
Parent
Re:Konqueror passed 2nd (Score:4, Informative)
Track Gecko progress here. Including screenshots.
Link as plain text due to
Parent
Re:Konqueror passed 2nd (Score:5, Informative)
Safari is an OSS project too.
No it isn't, WebKit, the rendering engine Safari uses, is an open source project. Safari itself is very much closed source.
Parent
WebKit matters, not the Safari frontend (Score:4, Insightful)
In a discussion about the Acid2 test, you claim that Safari isn't free software:
But the frontend code isn't very relevant to this discussion. Safari passes Acid2 if and only if [wikipedia.org] WebKit passes Acid2. Or do you claim that Apple maintains a private WebKit tree with patches that don't get released to the public and that one or more of the private patches is required for WebKit to pass Acid2?Parent
Re:WebKit matters, not the Safari frontend (Score:5, Interesting)
Not tested any others but I'm sure Xylescope, TextMate and OmniBrowser all use WebKit too.
Parent
ACID passed, real world? (Score:5, Insightful)
Re:ACID passed, real world? (Score:5, Informative)
Moreover, it's a fallacy to expect a browser to "work in all situations". I'm sure there are plenty of real-world situations where Firefox fails as well, and where Safari were to succeed in it's place. It's tests like ACID2 that determine a browsers capability to handle all situations.
The problem Safari is having with Exchange is very likely due to poor coding. Considering it's from Microsoft (you said Exchange web interface, right?), I'm sure Microsoft implemented a slew of hacks to have Firefox compliance (Microsoft is well known for improper web developing practices, to put it lightly).
Parent
Re:ACID passed, real world? (Score:4, Insightful)
I haven't found that. Firefox is ahead on some things and behind on others. For example, Safari supports DOM 2 mutation events, but Firefox doesn't.
You're joking, right? Internet Explorer's DOM support is prone to memory leaks and doesn't support basic things like event handling. I'd rephrase your statement as:
"As Internet Explorer has shown, having the largest market share is much more important than supporting most of the CSS or DOM specifications, because that way the web developers work for you, not the other way around."
I think that a lot of people have blind spots, where they are completely unaware of many parts of the specifications, because they don't work in Internet Explorer or Firefox.
Parent
Re:ACID passed, real world? (Score:4, Informative)
Parent
Re:ACID passed, real world? (Score:5, Informative)
It doesn't support event handling as defined by the DOM specifications. My comment is perfectly clear when you don't cut the quote off prematurely.
Referring to Internet Explorer's proprietary DHTML interface as a "DOM", while technically accurate, is misleading as in common use, the term "DOM" refers to the W3C specifications.
How about a little maturity?
a) No it doesn't, many Internet Explorer memory leaks [microsoft.com] are an artifact of the JScript engine being unable to refcount properly.
b) You implied that Internet Explorer had a "solid" DOM. That is not true regardless of the quality of Firefox's DOM. Internet Explorer's DOM doesn't get more "solid" if you distract people by talking about other browsers.
Parent
Re:ACID passed, real world? (Score:5, Informative)
First off that one hasn't been built, as I've seen IE manage to screw up royally too on sites claiming to work with IE, sometimes only with IE. The trouble with trying to match IE bug for bug is that you can't succeed as you can never duplicate the implementation exactly, you need to render pages wrong according to the standard, and worst of all it is never predictable. I really hate "trial-and-error" programming, and IE is the worst of the bunch.
In your case, you're trying to use MS generated HTML. I'm sure the fact that Firefox can render it is completely accidental and will be fixed in the next Exchange service pack. You can't expect a company that has a vested business interest in not playing nice, to play nice. The ACID2 test is an assurance that if I code to the standard, I will see none (or at least very few) rendering issues on any browser (except IE). That is very reassuring to people who think "OMG supporting five browsers, do I have to make 5x the number of hacks?" No, you don't. In fact, you'll code to one standard and fix hacks for one browser. Which is actually better than to code to zero standards and fix hacks for one browser...
Parent
Safari hates malformed pages (Score:5, Interesting)
There are a lot of crappy pages out there. If a page doesn't make it through the HTML validator why should anyone expect a browser to render it? Are your pages at work valid? What's the point of standards-compliant rendering engines if they all allow exceptions to the standard to be rendered?
A lot of times Safari won't render big chunks of web pages because of malformed markup [mozillazine.org]. Dave Hyatt (rightly, I believe) doesn't want to spend lots of coding effort dealing with error recovery when parsing sloppy web pages. Browsers like MSIE and Netscape (pre-Mozilla) are too permissive and have allowed people to get away with downright bad HTML.
That said, the Safari Compatibility Hit List [opendarwin.org] was recently created, to either fix Safari compatibility problems or to encourage sites to fix their markup.
Parent
Re:ACID passed, real world? (Score:5, Informative)
The problems with Opera's JS arise in three situations:
1) The site specifically blocks out Opera due to scripts 5-6 years old, but happily copypasted throughout the web project by brainless "web designers". Or server-side sniffing, like Yahoo did and still does, AFAIK.
See here for example, one that I found just a few minutes ago when informing myself of the latest and greatest Bollywood hit: http://www.rangdebasanti.net/ [rangdebasanti.net]
Their JS code contains this:
Use Proxomitron or Opera's cloaking techniques to get rid of the "Opera" part in UA string, and what do you know, the site works perfectly!
2) The site doesn't block Opera per se, but exhibits "if IE or Netscape" behaviour. Of course Firefox deals with those, as it descends from Netscape. Opera doesn't, and Opera is not IE, either, so it end up in no man's land...
3) The site has JS errors, and Opera is pretty strict when parsing JS, more so than Firefox or IE.
Honestly, Opera does not have any JS issues. None whatsoever. It's brainless webmonkeys who have issues with their JavaScript.
Parent
Tweaked (Score:5, Interesting)
Re:Tweaked (Score:4, Interesting)
The reason Opera is "victimised" by older scripts is due to the ridiculous decision of that company to add code stubs for functions it did not actually support (I remember when it had document.getElementById(), which always returned null - that's why many scripts look for the Opera string, and block it).
Parent
Good news (Score:4, Insightful)
A big well done to the Opera team. Safari passed the test in November last year, and hopefully Firefox will pass soon as well. Increased standards compliace is a Good Thing(tm) for users and webmasters alike. If the minority browsers continue to push standards (which the tech-savvy webmasters follow) it will push IE into improving its own rendering engine. Although even their unreleased version seems to be a bit behind the times...
From TFA: It is somewhat worrying that IE 6 renders Acid 2 very similarly to Opera 3.6, and the hyped IE 7 renders it very similarly to Opera 4.
'Somewhat worrying' indeed. I know people (of the pretty-damn-computer-literate variety) that won't switch from IE6 because it "works fine for them". I'm sure they know about the vulnerabilities [now that Symantec says so, it must be official!], the rendering issues and speed*, but they are sticking to their guns. So the only way people like this will have their experience enhanced is by teams like Mozilla and Opera pushing the browser envelope and hoping IE take interest. Either that or some X factor that makes the alternative browser a 'killer app', rather than IE, which is an app killer. (I couldn't resist, sorry!)
Well done again to Opera. Webmasters everywhere are silently saying a big 'thank you'.
*Note: I am aware that some will say that IE 6 loads quicker/renders quicker than FF. I have found the two of comparable speed for light pages, and FF slightly faster for 'heavier' pages. Opera is faster than both of them. Draw your own conclusions, and install all three (or two if your run a non-Windows OS). I found an old demo disc with IE 3 recently, and will be trying that out.
I like how... (Score:5, Insightful)
Internet Explorer getting better (Score:5, Funny)
Re:Internet Explorer getting better (Score:5, Informative)
Parent
Re:Internet Explorer getting better (Score:4, Funny)
IE 7, the Hannibal of web standards?
Parent
who was first after safari? (Score:3, Insightful)
Second browser after Safari? Which was the first after Safari to do it? Oh, you mean the second browser, after Safari...It's amazing what commas can do. Learn to use them.
An ACID test giving a smiley? (Score:5, Funny)
Re:An ACID test giving a smiley? (Score:5, Funny)
Parent
See how your browser fares... (Score:5, Informative)
Lynx doesn't pass... (Score:5, Funny)
Parent
Yeah, but... (Score:5, Interesting)
Re:Yeah, but... (Score:5, Interesting)
Parent
More elaborate history (Score:5, Informative)
There's a more useful history about it here [timaltman.com] (in reverse chronological order), describing what exactly the standard compliance problems were, and how they fixed them, starting with Opera 8.00.
And go to the Opera Desktop Team blog [opera.com] to download the actual build that works with this. However, note that this build should be treated like a Firefox nightly, and there may be some pretty serious rendering regressions, doing currently more damage to the layout engine than good from following the Acid2 test.
Re:Cool (Score:5, Insightful)
But I'm happy with Opera, be it for the faster responce I get on the same machine as I have Firefox installed on, the ability not to search for plug ins for whatever feature I need, 'it just works'
I just find Opera is faster at implementing standards, is more reliable with IE geared sites (don't like the fact, but I have to be pragmatic and deal with it as promoting interoperability is not what pays my bills), is more innovative (has important new features first and has them 'out of the box') and makes a good testing ground for my projects, and is all together very nice. And now it's free (as in beer).
Firefox is good. Opera is good too. Different priorities for different users, I don't have access to source code or the ability to contribute in the same way, but for me I'm fine with that. Both are far superior to IE's features, security and map for an interoperable internet in the future. Nuff said.
Parent
Re:*smack* (Score:3, Informative)
Safari, iCab, and Konqueror aren't for Windows (Score:5, Interesting)
It also makes Opera the first publicly available web browser that renders the Acid2 page correctly under the Microsoft Windows operating system. This is important if you don't want to have to re-buy your PC (in switching to Mac OS X, which runs only on Apple hardware) or your peripherals (in switching to Linux, where SANE still doesn't support my flatbed scanner [sane-project.org]). Or is Konqueror for Cygwin/X considered stable yet?
Parent
Re:For the curious - (Score:5, Informative)
Parent
No it hasn't... (Score:5, Informative)
Parent
Re:This does NOT pass Acid 2 (Score:5, Informative)
The nose changes color when you mouseover it. Even in the mess that is Firefox's rendering of the page [webstandards.org] hovering your mouse over the face causes the nose to change colour from black to blue.
I guess that's something they really should specify in the reference diagram, but it's still a pass for Opera 9.
Parent
Re:This does NOT pass Acid 2 (Score:5, Interesting)
Parent
Re:ACID2: valid test or not? (Score:5, Insightful)
So the test is verifying conformance not only with treatment of valid CSS, but also correct treatment of invalid CSS, which is very important given that a significant part of compatibility problems between current web-browsers is caused by different behavior in the face of errors - whether they ignore it, stop parsing, try to render it anyway etc.
Parent
Re:Ah opera... (Score:5, Insightful)
Then maybe you should stop making websites, because people like you are the problem.
They're "only a guideline" in that the FBI won't knock on your door if you don't follow the standards. And oh yeah, a lot of browsers will accept your sloppy coding and "render it fine." However, if you want a world where all browsers render all content in the same way, that can't be accomplished by the developing team of any browser. That can only be accomplished by developing and following standards. So, you blame the browser when they don't follow them, and you blame the web developer when he doesn't follow them.
I'm fine with browsers who want to go the extra mile and have non-standard code render correctly, as long as they don't sacrifice proper rendering of the standard code to do it. That doesn't excuse you coding incorrectly, though.
Parent
Re:Ah opera... (Score:5, Informative)
Well, it's great that you do all that work to consider your visitors. What I was referring to was your comment that following standards isn't really that important, it's just a guideline. That train of thought is part of the problem.
Think of a world where every browser renders everything in the standard correctly. Suddenly, your job is easier. In order to make sure that your web page renders correctly for the visitors using IE, Firefox, Safari, Opera, Konqueror, whatever, you don't need to actually test it with each one of those browsers. You just need to make sure your site follows the standards, and the rest "just works". If you skip out on things because "they're dumb," well, you may think you're right, but why do you expect browser developers to share your opinion?
You'll see 12 ridiculous errorsDepends on your definition of ridiculous. You wouldn't expect c code that doesn't have syntax exactly right to compile, so why do you expect html syntax that isn't exactly right to render correctly?
from things like > characters whose position it disagrees with
I didn't find that. I found error #3. It's not complaining about the position of the character, it's complaining that you placed that tag inside your unordered list, but not within a list item tag. I checked the source code and you have:
<ul id="utabs">
<a href="?page1"><<</a>
If it's part of the unordered list, it should be inside a <li> tag. If you don't want for that to appear the same as the other list items, you should give it a class attribute and handle it in your css (there are other correct ways of handling it too, if you don't like that for some reason).
That and a childish remark about my html tag which was funny for the 1.3 seconds I spent writing the top line...
It wasn't your remark that it complained about. It complained about your type. That's not how you specify 4.01. From a W3C page, there's this example, using SGML to do what you want (for strict 4.01).:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
Heck...you should be fine just skipping that altogether. Close your html tag, and don't put the type thing.
errors that don't tell me anything useful or constructive at all
The validator doesn't tell you how to fix it, just that it found something wrong. However,
a wikipedia url I pasted, which the validator decided to parse and rate
For that error, the validator told you exactly what was wrong...in bold. "The most common cause of this error is unencoded ampersands in URLs". I've actually noticed that in other places in your html code for that page, stuff that I expected the validator to complain about, but it didn't.
In html, if you want to have a "<" or ">" that is not part of a tag, you use a code. you type in "<" for < and ">" for >. If you want to type "&", you type "&" Replace the & in that url, and it'll pass. You should replace the <'s I mentioned in error #3 with the correct codes too, even if the validator doesn't complain about it.
I'm not trying to be a bastard about it. I hope my comments help you understand the validator better, and see that it's not so useless as you've come to believe. It's great that you've been putting effort to make sure your visitors get the best experience they can on your site, and I hope you'll keep doing so.
Parent