I'm not sure how that's relevant, misunderstandings of your post's parent aside.
On the subject of unsupported browser tests, a question: how much value do you actually derive in real-world browsing from SMIL, the remaining area of Acid3 not supported in Firefox? (Aside from being able to run Acid3 and see it pass, that is.) How much do you expect you would derive if SMIL support were widespread in browsers? I think the answer is very little, and I think my opinion deserves at least some consideration given that Ian has repeatedly stated that adding the SVG-related tests to Acid3 was a mistake. (I don't know that my questions touch upon the reasons Ian has for thinking that a mistake, but I do suspect unusefulness in general, even in an ideal world of SMIL-supporting browsers, played a factor.)
Acid2 was good in my book, but Acid3 was much more of a grab bag. It mostly consisted of browser bugs found by searching through bug databases and through suggestions to Ian (I suggested a few, actually, based on knowledge of various Mozilla bugs), not something that deliberately set out to test functionality useful to web developers in general. Some of the fixes were utterly trivial (I fixed one that was a one-line change); others were more involved but not particularly difficult (I fixed several of these as well). Really, tho, the fundamental problem was that Acid2 tested things developers wanted to use but couldn't; Acid3 tested many things which will never see much use by developers.
Not really; if you support CSS level 2, 2.1, or don't support the CSS3 backgrounds and borders spec, the reference rendering of Acid2 is fully correct. The problem is Acid2 made an assumption that a standard CSS2.1 property would never be extended in a particular way by future CSS levels/specifications, but it was. If you support CSS3's current definition of background-color, then Firefox's rendering is correct. If you don't, then the reference rendering is correct. So really, latest Firefox and Safari are both correct.
The problem isn't that anyone is or isn't failing, it's that Acid2's pass condition is not correct independent of implementation of future CSS specifications. It's not like this could really have been predicted, so it's more an odd quirk of the standards process than anything else.
Incidentally, the spec might still change on this, partly because Acid2 would be broken and partly because the fallback color in CSS3 that causes the problem here is a bit of an oddball feature, both conceptually and syntactically. If it stays the fallback color might move to, say, background-image or require a disambiguating slash or something else to avoid this edge case (and not "regress" Acid2 to show red in compliant implementations).
I think that illustrates why we shouldn't rely on tests like the Acid Tests too much when determining standards compatibility.
I'll agree with this. The Acid tests demonstrate support for precisely what they contain; they imply support for much more than that, since nobody really thinks a full stack of Acid-specific hacks wouldn't go unnoticed if it were attempted, but unless you wrote or reviewed the patch it's going to be hard to find the unaddressed edge cases that the changes might not address in the relevant functionality.
Nothing really demonstrates standards compatibility. However, a lot of tests of simple uses and complex uses in which multiple features interact in complex ways go a long way to showing that the particular features probably work correctly in practice.
(Oh, I wrote the post you linked, if my username didn't make that clear. Good ol' referrer tracking for the win...)
Do orinoco wireless cards work with the udev/kernel used in FC5? The latest udev in FC4 breaks orinoco NICs, and I'd rather not install FC5 to find that it's still broken. (Presumably it is since there's been no activity in the bug recently, but there's always the chance it was fixed upstream and never noticed by Red Hat.) With FC4 I could revert the kernel/udev updates that broke it; doing the same with FC5 isn't just installing the "previous" udev/kernel packages (since there are none unless I want to start tracking through rawhide), and I don't have the time to make the effort.
Feeds are really nothing more than supercharged bookmarks that are constantly updated. Google gets by perfectly well with bookmarks still around, so why would they suddenly feel threatened by feeds? Don't tell me you use search to get to sites you read every day whose URLs you know by heart.
In response to the feed ads Google's testing, the reason they're experimenting is that such ads are a potential source of income, and as a company Google only survives as long as it has income.
but what about re-arranging tabs? Same problem. I need an extension. Can't find one.
I'll agree on this.
And you know what? So does Ben Goodger.
Those of us who happened to tune in to the live webcast on the day Firefox was released heard Ben tell us that MiniT (draggable tabs) was one very few extensions he used. He also said that the extensions he used were truly extensions -- except for one: MiniT. He later said he intends to implement MiniT functionality in Firefox.
So there's your answer: it's not there yet (and the main project developer agrees that it should be there), but it'll be there soon.
You can also view the credits in Firefox as well. (I'd link to the specific line in code, but because it's in an HTML page LXR displays the HTML instead of outputting it by line number.) I'm pretty certain the author qualifies as a useful open source contributor.
"What if the company that produces Viagra ever wanted to send out an e-mail?" Spira mused. "The value of that mark in that context has been utterly diminished."
With Viagra losing its trademark potency...
If anyone's still moderating this discussion, I think it's worth noting the writer's mistake...that last bit should have been:
Seriously though, as I'm sure many of these hackers/crackers will be heralded as (demi-)heroes [...], it should not be forgotten that they -did- commit a crime.
The potential margin of uncatchable error is large enough that it was larger than the margin of victory in the deciding area of the last presidential election.
Potential margin of error? So did Democrat chads hang more often than Republican or Independent chads?
Sure, the small margin of victory did make any error all the more significant, but the error should have evened out over the large number of votes.
This is the key problem with e-voting: if the machines are hackable, there will be too few hacks, all with unpredictable impacts, to keep statistical error to a minimum. Millions of votes will, however, minimize the error from chads (or other current, fallible methods) to zero.
Slashdot Mirror
I'm not sure how that's relevant, misunderstandings of your post's parent aside.
On the subject of unsupported browser tests, a question: how much value do you actually derive in real-world browsing from SMIL, the remaining area of Acid3 not supported in Firefox? (Aside from being able to run Acid3 and see it pass, that is.) How much do you expect you would derive if SMIL support were widespread in browsers? I think the answer is very little, and I think my opinion deserves at least some consideration given that Ian has repeatedly stated that adding the SVG-related tests to Acid3 was a mistake. (I don't know that my questions touch upon the reasons Ian has for thinking that a mistake, but I do suspect unusefulness in general, even in an ideal world of SMIL-supporting browsers, played a factor.)
Acid2 was good in my book, but Acid3 was much more of a grab bag. It mostly consisted of browser bugs found by searching through bug databases and through suggestions to Ian (I suggested a few, actually, based on knowledge of various Mozilla bugs), not something that deliberately set out to test functionality useful to web developers in general. Some of the fixes were utterly trivial (I fixed one that was a one-line change); others were more involved but not particularly difficult (I fixed several of these as well). Really, tho, the fundamental problem was that Acid2 tested things developers wanted to use but couldn't; Acid3 tested many things which will never see much use by developers.
Not really; if you support CSS level 2, 2.1, or don't support the CSS3 backgrounds and borders spec, the reference rendering of Acid2 is fully correct. The problem is Acid2 made an assumption that a standard CSS2.1 property would never be extended in a particular way by future CSS levels/specifications, but it was. If you support CSS3's current definition of background-color, then Firefox's rendering is correct. If you don't, then the reference rendering is correct. So really, latest Firefox and Safari are both correct.
The problem isn't that anyone is or isn't failing, it's that Acid2's pass condition is not correct independent of implementation of future CSS specifications. It's not like this could really have been predicted, so it's more an odd quirk of the standards process than anything else.
Incidentally, the spec might still change on this, partly because Acid2 would be broken and partly because the fallback color in CSS3 that causes the problem here is a bit of an oddball feature, both conceptually and syntactically. If it stays the fallback color might move to, say, background-image or require a disambiguating slash or something else to avoid this edge case (and not "regress" Acid2 to show red in compliant implementations).
I'll agree with this. The Acid tests demonstrate support for precisely what they contain; they imply support for much more than that, since nobody really thinks a full stack of Acid-specific hacks wouldn't go unnoticed if it were attempted, but unless you wrote or reviewed the patch it's going to be hard to find the unaddressed edge cases that the changes might not address in the relevant functionality.
Nothing really demonstrates standards compatibility. However, a lot of tests of simple uses and complex uses in which multiple features interact in complex ways go a long way to showing that the particular features probably work correctly in practice.
(Oh, I wrote the post you linked, if my username didn't make that clear. Good ol' referrer tracking for the win...)
I can't see why not.
Do orinoco wireless cards work with the udev/kernel used in FC5? The latest udev in FC4 breaks orinoco NICs, and I'd rather not install FC5 to find that it's still broken. (Presumably it is since there's been no activity in the bug recently, but there's always the chance it was fixed upstream and never noticed by Red Hat.) With FC4 I could revert the kernel/udev updates that broke it; doing the same with FC5 isn't just installing the "previous" udev/kernel packages (since there are none unless I want to start tracking through rawhide), and I don't have the time to make the effort.
Feeds are really nothing more than supercharged bookmarks that are constantly updated. Google gets by perfectly well with bookmarks still around, so why would they suddenly feel threatened by feeds? Don't tell me you use search to get to sites you read every day whose URLs you know by heart. In response to the feed ads Google's testing, the reason they're experimenting is that such ads are a potential source of income, and as a company Google only survives as long as it has income.
I'll agree on this.
And you know what? So does Ben Goodger.
Those of us who happened to tune in to the live webcast on the day Firefox was released heard Ben tell us that MiniT (draggable tabs) was one very few extensions he used. He also said that the extensions he used were truly extensions -- except for one: MiniT. He later said he intends to implement MiniT functionality in Firefox.
So there's your answer: it's not there yet (and the main project developer agrees that it should be there), but it'll be there soon.
You do know what the author does in his spare time, don't you?
The Burning Edge
Security holes in Mozilla the author's found
The author's checkins to Mozilla source code
Helpful bookmarklets for searching through Bugzilla, Mozilla's public bug database
You can also view the credits in Firefox as well. (I'd link to the specific line in code, but because it's in an HTML page LXR displays the HTML instead of outputting it by line number.) I'm pretty certain the author qualifies as a useful open source contributor.
If anyone's still moderating this discussion, I think it's worth noting the writer's mistake...that last bit should have been:
With Viagra becoming impotent
*duck*
Sorry, but I just couldn't resist... ;-)
Since when has that mattered to anyone? (link to news about a certain ex-NY Times reporter and a book deal...)
Potential margin of error? So did Democrat chads hang more often than Republican or Independent chads?
Sure, the small margin of victory did make any error all the more significant, but the error should have evened out over the large number of votes.
This is the key problem with e-voting: if the machines are hackable, there will be too few hacks, all with unpredictable impacts, to keep statistical error to a minimum. Millions of votes will, however, minimize the error from chads (or other current, fallible methods) to zero.