CSS's "transparent" isn't all that transparent
coderwall.com
coderwall.com
From a practical standpoint I guess you should be careful around `transparent` if you're a designer, but the moral responsibility clearly falls on browser vendors here. It's not meaningful to talk about the "colour" of transparent objects, and using those values when doing anti-aliasing (however technically appealing) is wrong.
I think the problem is that they're doing the anti-aliasing "too early". They're not blending the colours you see, they're blending the colours they're painting as they paint them.
Its kind of like saying math is hard, so its up to the browser to fix it for you. Math is hard, but there's always a right answer. If you're blending things, there's a right answer too, and it's up to you to come up with it instead of asking the browser to fix things for you. That's just how computing is. Just because IE and chrome are clever enough to fix your own problems for you doesn't mean you should feel entitled to expect that. If you're saying "blend to (0,0,0,0)" you're literally saying "blend to black and transparent equally". There is no ambiguity there. It's what has been asked for, even if it's unintended. In a sense, I would say firefox is the only browser that has gotten this right.
The other issue is that Firefox is doing anti-aliasing incorrectly, no matter what you decide on the above. The colour between the two borders must be halfway between light grey and white, i.e. between the visible colours on the page.
The CSS describes a step transition from #eee to transparent, but because it's on a diagonal, the browser is anti-aliasing the line.
Note that the reason it looks right in Chrome is because Chrome doesn't anti-alias the line.
http://jsfiddle.net/liamnewmarch/GgUV2/
The top gradient is from transparent to red, the bottom is from rgba(255, 0, 0, 0) to red.
Notice how the top gradient fades through grey - this is because 'transparent' is a synonym for rgba(0, 0, 0, 0).
What the parent article picks up on, is how this is visible via Firefox's antialiasing.
A bug report with a minimal testcase would take 50% the time it took to write the article itself but actually have greater impact.
Bugzilla is a wonderful tool for Mozilla. Unlike other projects that use mailing lists or internal tools, Mozilla coordinates its projects mainly using Bugzilla. Developers discuss patch approaches there, post WIPs and do code reviews there. Considering Mozilla is comprised of many contributors all around the globe such software is a necessity. Bugzilla may look complicated and cumbersome but it's actually a powerful tool.
By comparison, the issue tracker used by the Chromium project is just a public-facing ad-hoc thing. The project's workings are mostly opaque, coordinated by Google's employees. The whole project works more like typical closed-source software.
Transparent is transparent. Some code might be lazy and calculate colors based on only three of four color channels but that is a bug and will be fixed.
Maybe this is hardware dependent? I do not have any hardware acceleration that I am aware of - integrated i3 graphics.
It's very cool to have a reason, and even better a solution.
But I'm worried about cross browser compatibility.
There is a grey line in frames 1 and 3 but not in 2.
Unfortunately, this causes a ton of problems when you're doing anything with transparent images outside the realm of Porter-Duff, since the process is not fully reversible. In addition, it has tainted the way that developers think about alpha channels, so that they erroneously act like there is only One True Clear Color, which is how we ended up with issues like the one described in TFA in the first place.
Premul is not the solution. Premul is the original problem.