Version 6 was a piece of shit. I was using 4.08 at that time. That was the last one I found to be stable until 7.1. I like the email and browser together... but I guess I'm gonna have to go the Firefox - Thunderbird route soon.
Actually, it sounds like you'd be more interested in SeaMonkey than Firefox+Thunderbird. It's a continuation of the Mozilla suite that was the basis for Netscape 7, and still has the combined browser & email. It's also still being developed as a Mozilla project, so it's current as far as capabilities & security fixes go.
Netscape is dead, and IE is still around. You certainly have a funny definition of "win".
But the codebase eventually became Firefox, which seems to be doing a lot better than Netscape these days.
It's kind of like the PC/Mac wars: IBM opened up the PC to clones. The PC platform went on to wild success, even though IBM's PC division dwindled until they sold it off.
That's pretty much the same path I took. Dropped Netscape 4 in favor of Opera 3, used it through Opera 5, then went over to Mozilla, eventually jumping to Firefox.
Though I kept paying for Opera upgrades until they went free-as-in-beer, in part to encourage them to keep developing the Linux version. These days I spend about 60% of my time in Firefox, and 35% in Opera (not counting web development).
Do I recall some kind of ridiculous refresh bug in one of the Netscape 4.x versions, whereas if you moved the browser on your screen the page refreshed?
Close. It was when you resized the browser window, and it was present throughout the 4.x series. I was sooooo happy when Mozilla did away with that problem.
My first browsers were Mosaic in the college computer labs, and Lynx on my dial-up shell connection. Then Netscape 1 once I got PPP access (or was it SLIP? I forget).
I remember reading about Cello and trying to track down a copy, but I don't think I ever got it to run.
Since Amazon launched their MP3 store, I've been trying to pick things up there if possible, then fall back on iTunes as a secondary source -- specifically because of the lack of DRM. Good to know the selection's about to jump.
The problem isn't actually the breaking, it's everyone not giving enough room between themselves and the person ahead of them to absorb small slowdowns.
I always try to allow a safe stopping distance for this reason. (Well, and the obvious reason too.) Unfortunately this usually means the driver who's been following 6 feet behind me decides to jump around and fill in what he perceives as a gap.
Either people don't know/care about stopping distance, or they think the ideal distance is a lot shorter than it actually is.
Doesn't matter. If it's fully CSS2 compliant, the behaviour when it sees something it doesn't recognise is to ignore it.
That would be an example of the standards specifying what the browser should do with incorrect code, and why it's important to do so in the specified manner. In fact, that argues in favor of testing a browser's ability to handle such code, so I'm a bit confused as to why you say it doesn't matter.
And then Slashdot collectively declared it to be the official response, and repeated it over and over ad nauseum until people believed it. Kind of like the "Acid2 only tests error handling" misconception that came up several times earlier today, even though if you actually look at the description of the test, it's only one aspect among many.
Most web pages seem to have images, which all together add up to more than 100k.
Not only that, but there are two sizes to deal with for images: compressed and uncompressed. A 100x100 pixel JPEG might take up 7K of file space, but that's 100*100*24 bits = 30K. I seem to recall reading that one of the changes they made to save memory in Firefox 3 was to drop the uncompressed copy of the image after a certain amount of time, since you can always re-extract it.
Okay, so explain how it is still rendering correctly in the Hv3 browser
It doesn't for me. I set up a test account, downloaded the static version of the browser, and ran it. The eyes are covered by a band of orange dithering like a blindfold, with a small rectangle that says, "ERROR". I'll admit it's different from what I see on Opera, Safari, and Firefox 3 beta, but it's still far from rendering correctly.
I think it would be nice if browsers continued to fix spaghetti, but also showed a message somewhere that indicated that the page was buggy. Not a pop-up or anything, but a small, unobtrusive icon that was green and happy for a good page, or red and frowny for a bad.
Not for me, it isn't. Opera 9, Firefox 3 and Konqueror 3 are all showing the exact same error. The left eye is replaced with an orange dither, while the center forehead and everything to the right are replaced with a wide black rectangle, a long horizontal scrollbar and a short vertical scrollbar. Hovering over it sometimes shows "Skip to content", and scrolling picks up things that look like tiny slivers of the www.webstandards.org website.
Safari for windows is not.
On second look, Safari on Windows is failing in a slightly different manner, with just the orange dither across both eyes like a blindfold. So there may be something else going on there.
I noticed the same error on Konqueror 3.5.8, Opera 9.5a, & Firefox 3 on Linux, and on Opera 9.24 and Safari 3.04 on Windows -- all of which are supposed to pass the test.
Earlier today I tried to pull up the webstandards.org website, and couldn't. This got me thinking it might be a server problem.
I looked at the code for the test, and at one point it has an OBJECT where it tries to load the url, http://www.webstandards.org/404/. That should fail, causing the browser to display the fallback content inside the OBJECT element instead.
Guess what? That URL is returning a 200 OK code instead of 404 Not Found, so the compliant browsers are doing what they're supposed to do and displaying the content of that page in a little rectangle with scroll bars, and hiding the fallback content that we would normally see.
When their webmaster fixes the server config, the various compliant browsers should start displaying it correctly again.
You're right about it not being a compliance test, in the sense that passing Acid2 doesn't indicate full compliance with any specific standard. It does, however, indicate that the browser handles a number of features from the specs that were poorly, rarely or not implemented when it was announced in 2005.
The point of the test was to prod browser developers into improving their products to better support the existing specifications. This would increase interoperability (because different browsers would treat these features the same way) and give web developers more tools that they could actually use in practice.
This has worked. Safari/WebKit fixed a bunch of bugs and added a bunch of features until it passed. Then Opera. Firefox will pass it soon: Gecko 1.9 will pass it (beta 1 did, beta 2 doesn't for some reason -- I expect they'll make sure that's fixed by the time 3.0 final is released). Various smaller browsers (iCab, Konqueror before they decided to re-merge KHTML with WebKit, etc.) did as well. Now internal builds of IE8 have the necessary improvements.
how back-portable is the IE8 browser? If it only runs on Vista, it's not going to matter much.
That depends on when IE8 is released. It took them 1.75 years to get from announcing IE7 (Feb 2005) to releasing it (Nov 2006). Presumably they've been working on IE8 for a while, but if it takes them another 21 months, we're looking at fall 2009. Who knows what the Windows install base will look like then?
Personally, I'm hoping it'll be out by the end of 2008, though my current goal is to get people the hell off of IE6. Upgrade to IE7, switch to Firefox, Opera, Safari, whatever, just ditch that aging monstrosity of a browser if you possibly can (and aren't barred by your IT department, or a need to access some critical site that only works in IE6).
It'll also be nice it it handles transparent PNGs properly with nothing more than an tag--like how IE/5 Mac did almost eight fucking years ago.
They finally did in IE7, released in November 2006.
And, from what I've read before, it tests how browsers handle incorrect code as much as anything else--i.e., if it deals with errors correctly.
That's not the only thing it tests, but proper error handling is critical for forward compatibility. A fully CSS2-compliant browser, when faced with CSS3, will see it as incorrect code. Ditto for an HTML4 browser looking at HTML5 or XHTML1. If there are well-specified ways to handle errors, and the browsers follow them, then you can predict what browsers will do if they don't support a particular feature.
Slashdot Mirror
Actually, it sounds like you'd be more interested in SeaMonkey than Firefox+Thunderbird. It's a continuation of the Mozilla suite that was the basis for Netscape 7, and still has the combined browser & email. It's also still being developed as a Mozilla project, so it's current as far as capabilities & security fixes go.
But the codebase eventually became Firefox, which seems to be doing a lot better than Netscape these days.
It's kind of like the PC/Mac wars: IBM opened up the PC to clones. The PC platform went on to wild success, even though IBM's PC division dwindled until they sold it off.
That's pretty much the same path I took. Dropped Netscape 4 in favor of Opera 3, used it through Opera 5, then went over to Mozilla, eventually jumping to Firefox.
Though I kept paying for Opera upgrades until they went free-as-in-beer, in part to encourage them to keep developing the Linux version. These days I spend about 60% of my time in Firefox, and 35% in Opera (not counting web development).
Close. It was when you resized the browser window, and it was present throughout the 4.x series. I was sooooo happy when Mozilla did away with that problem.
My first browsers were Mosaic in the college computer labs, and Lynx on my dial-up shell connection. Then Netscape 1 once I got PPP access (or was it SLIP? I forget).
I remember reading about Cello and trying to track down a copy, but I don't think I ever got it to run.
Sorry to get your hopes up!
Since Amazon launched their MP3 store, I've been trying to pick things up there if possible, then fall back on iTunes as a secondary source -- specifically because of the lack of DRM. Good to know the selection's about to jump.
I always try to allow a safe stopping distance for this reason. (Well, and the obvious reason too.) Unfortunately this usually means the driver who's been following 6 feet behind me decides to jump around and fill in what he perceives as a gap.
Either people don't know/care about stopping distance, or they think the ideal distance is a lot shorter than it actually is.
That would be an example of the standards specifying what the browser should do with incorrect code, and why it's important to do so in the specified manner. In fact, that argues in favor of testing a browser's ability to handle such code, so I'm a bit confused as to why you say it doesn't matter.
Right-click on the toolbar, and select Customize. Drag the search box off the toolbar onto the palette. Done!
s/always/once/ (that I can remember)
And then Slashdot collectively declared it to be the official response, and repeated it over and over ad nauseum until people believed it. Kind of like the "Acid2 only tests error handling" misconception that came up several times earlier today, even though if you actually look at the description of the test, it's only one aspect among many.
Not only that, but there are two sizes to deal with for images: compressed and uncompressed. A 100x100 pixel JPEG might take up 7K of file space, but that's 100*100*24 bits = 30K. I seem to recall reading that one of the changes they made to save memory in Firefox 3 was to drop the uncompressed copy of the image after a certain amount of time, since you can always re-extract it.
It doesn't for me. I set up a test account, downloaded the static version of the browser, and ran it. The eyes are covered by a band of orange dithering like a blindfold, with a small rectangle that says, "ERROR". I'll admit it's different from what I see on Opera, Safari, and Firefox 3 beta, but it's still far from rendering correctly.
Maybe it's something cache related?
Just out of curiosity, are you an iCab user?
Not for me, it isn't. Opera 9, Firefox 3 and Konqueror 3 are all showing the exact same error. The left eye is replaced with an orange dither, while the center forehead and everything to the right are replaced with a wide black rectangle, a long horizontal scrollbar and a short vertical scrollbar. Hovering over it sometimes shows "Skip to content", and scrolling picks up things that look like tiny slivers of the www.webstandards.org website.
On second look, Safari on Windows is failing in a slightly different manner, with just the orange dither across both eyes like a blindfold. So there may be something else going on there.
It looks like a server problem, since all previously-passing engines are displaying the same error. More detail in this comment.
It looks like a server error, since all Acid2-compliant browsers seem to be rendering it with the same exact error. More in this comment.
I think it's a server error, since the exact same problem occurs on supposedly-compliant versions ofFirefox, Opera and Safari. More in this comment.
I noticed the same error on Konqueror 3.5.8, Opera 9.5a, & Firefox 3 on Linux, and on Opera 9.24 and Safari 3.04 on Windows -- all of which are supposed to pass the test.
Earlier today I tried to pull up the webstandards.org website, and couldn't. This got me thinking it might be a server problem.
I looked at the code for the test, and at one point it has an OBJECT where it tries to load the url, http://www.webstandards.org/404/. That should fail, causing the browser to display the fallback content inside the OBJECT element instead.
Guess what? That URL is returning a 200 OK code instead of 404 Not Found, so the compliant browsers are doing what they're supposed to do and displaying the content of that page in a little rectangle with scroll bars, and hiding the fallback content that we would normally see.
When their webmaster fixes the server config, the various compliant browsers should start displaying it correctly again.
No, actually. That's part of it, yes, but nowehere near the whole thing.
You're right about it not being a compliance test, in the sense that passing Acid2 doesn't indicate full compliance with any specific standard. It does, however, indicate that the browser handles a number of features from the specs that were poorly, rarely or not implemented when it was announced in 2005.
The point of the test was to prod browser developers into improving their products to better support the existing specifications. This would increase interoperability (because different browsers would treat these features the same way) and give web developers more tools that they could actually use in practice.
This has worked. Safari/WebKit fixed a bunch of bugs and added a bunch of features until it passed. Then Opera. Firefox will pass it soon: Gecko 1.9 will pass it (beta 1 did, beta 2 doesn't for some reason -- I expect they'll make sure that's fixed by the time 3.0 final is released). Various smaller browsers (iCab, Konqueror before they decided to re-merge KHTML with WebKit, etc.) did as well. Now internal builds of IE8 have the necessary improvements.
And to follow up, here's a page that goes into much more detail on just what Acid2 tests, including:
That depends on when IE8 is released. It took them 1.75 years to get from announcing IE7 (Feb 2005) to releasing it (Nov 2006). Presumably they've been working on IE8 for a while, but if it takes them another 21 months, we're looking at fall 2009. Who knows what the Windows install base will look like then?
Personally, I'm hoping it'll be out by the end of 2008, though my current goal is to get people the hell off of IE6. Upgrade to IE7, switch to Firefox, Opera, Safari, whatever, just ditch that aging monstrosity of a browser if you possibly can (and aren't barred by your IT department, or a need to access some critical site that only works in IE6).
They finally did in IE7, released in November 2006.
That's not the only thing it tests, but proper error handling is critical for forward compatibility. A fully CSS2-compliant browser, when faced with CSS3, will see it as incorrect code. Ditto for an HTML4 browser looking at HTML5 or XHTML1. If there are well-specified ways to handle errors, and the browsers follow them, then you can predict what browsers will do if they don't support a particular feature.
I meant "for all I know in WebKit as well." Gecko, of course, is the engine used by Firefox.