WebKit (well, one twisted soul, I think) has started a meme collection. It’s true that Mozilla has a quotes database, which sometimes we are even gracious enough to share with them [more here]). But we have no meme collection.
Mozilla Internetizens, fix this. Pronto.
UPDATE: jdm follows through with Mozilla Memes. Next step: ADDRESS THE GAP.
UPDATE 2: The gauntlet has been thrown down.
This is what the Acid2 test looks like in the very very super-duper-latest Firefox builds (slated for the version after 3.1, mind, not for 3.1):
Bug, you say? No! The last test in row 13 tests that this CSS doesn’t apply:
.parser { background: red pink; }
Two colors for a background as valid CSS? Surely you jest!
Actually, we don’t. CSS3 says background-color takes two colors, one for normal use and one for use if a corresponding background-image doesn’t load. The red ends up getting used as the background color, and the yellow that would have been present if the property hadn’t applied no longer shows. CSS3 makes previously-invalid CSS valid, and that’s okay, because CSS error handling is explicitly designed to allow it.
So no, “failing” Acid2 for now isn’t fail, it’s WIN. Hopefully the test will be updated soon so that that particular rule is invalid again.
Incidentally, the specification for this changed recently, which I presume is why WebKit/Safari/Chrome et al. don’t fail. I don’t know whether they implement the fallback color process or not, presumably not given how they handle this testcase, which should show a green square if CSS3 background colors are implemented to latest spec, but in any case they won’t trigger it even tho they’ve implemented a bunch of other parts of the CSS3 backgrounds spec.
Update: As Dan notes in comments, the once-invalid syntax is now invalid again, as fallback color support has been removed from CSS3 partially over syntax concerns and partially over its lack of generalizability to other cases in CSS. Now that support for fallback colors has been removed from trunk, Acid2 in bleeding-edge Firefox now displays as it was intended to display.
Every so often (okay, ALL THE TIME) someone (Linux users, of course 🙂 ) wonders why Mozilla doesn’t use platform libraries for things like networking code. One commonly-argued reason is that it gives us the flexibility to fix security problems without waiting on those upstream libraries to make the fix themselves — we control the code, and we can make the fixes ourselves.
Another reason not to use platform libraries occurred to me while reading Planet WebKit today, specifically the recent WebKit’s week – #7 post. Quoting from that post, added emphasis mine:
HttpOnly Cookie (38566)
An Internet Explorer extension (added in Firefox and Opera since) will soon be supported by WebKit based browsers. This restricts the access to certain cookies. They are only available for an HTTP request and so not from JavaScript. This is an important functionality to restrict the damages of an XSS vulnerability. This is not available in the nightlies because you need some updated Apple proprietary libraries (CFNetwork).
As noted, Firefox supports HTTPOnly cookies; after the patch to add this support was committed, you could download nightly builds which included the fix, and HTTPOnly would Just Work. No mess of upgrading platform libraries to make it happen, no separate-package updating, no waiting on Apple to update their platform libraries. (Incidentally, will Apple make those updates for 10.4 users as well, assuming they even decide to release a browser upgrade for a, er, “dying” OS release? Maybe, maybe not, who can say; “Apple does not comment on future products.”) Just download the build, build it from source yourself if you like building from source or if you’re a Gentoo ricer, and you have a working browser with the fix.
There are tradeoffs to be made rolling your own code when you could use something provided by the OS or by a third-party library. However, it should be equally clear that there are tradeoffs to be made going the other way, at least if you truly care about being cross-platform.
(On an almost entirely unrelated note, I was pleased to discover while writing this post that HTML5‘s outline-generation algorithm properly handles headings inside blockquote elements. Yay for specs anticipating my concerns! 😀 )