No dark grey line in Konqueror 4.8.4 or Chromium 20 here, but Firefox 13.0.1 does mess it up like he says. (EDIT: browser versions added, OS is 64-bit Arch Linux)
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.
I don't see this as the browsers fault (as a person that does graphics outside of the web space). If you're blending something it's important to be clear /what/ you're blending to, and the RGB matter just as much as the A. "transparent" might be a part of the spec, but its tragically imprecise.
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.
First, I'm not convinced if all (r, g, b, 0) should be different colours or not, especially given how CSS lets you have a "transparent" colour -- that implies it will blend with any colour towards its transparent version.
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.
But you'd have to figure out how to use Mozilla's bug tracker first. And that has prevented me from reporting Bugs in Firefox every single time so far. And I guess I'm not the only one.
I'm not a professional in the field but I filed my first bug in Bugzilla some years ago effortlessly. I'd expect a web author to be even better at using technical tools.
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.
I was about to agree with you (especially when compared to Github's issue tracker, since everyone has a Github account), but while poking around I noticed that it offers login via BrowserID, which I just so happen to have. Since registering a new account is the biggest barrier to participating in any service, that's not so bad after all.
> As it stands, many, many things use transparent black when they shouldn't.
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.
Firefox 14.0.1, Windows 7 x64. Grey line is visible for a split second as page loads then disappears. EDIT: well now this is bizarre - it disappears and reappears as I scroll.
Same here (also 14.0.1, Win7 x64), the grey line only appears when the triangle scrolls near the top or the bottom of the viewport. In the middle of the viewport it is gone.
Premultiplied alpha exists to solve one problem: multiplying by the alpha channel is common to almost all of the Porter-Duff compositing operations, and computers used to be slow, so premul came about as a way of speeding up drawing operations. Instead of multiplying each time, you simply multiplied the alpha channels in advance.
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.
I'm no graphics expert, but I'm pretty sure premul is not just an optimization technique -- it's a fundamentally different approach at alpha blending, and it makes some new things possible and some behavior more correct. See http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premulti... . Sure, if you don't need the extra features premul provides (like the built-in ability for additive blending), then you can do some clever computations like IE apparently does to get the same result, but it's much simpler just to do things with premul.
I do not know why premultiplied alpha was invented in the first place but it does exactly solve the problem stated in the article. From the wikipedia article on "Alpha compositing": "Premultiplied alpha has some practical advantages over normal alpha blending because premultiplied alpha blending is associative and linear interpolation gives better results". I'd go even farther and say that linear interpolation of nonpremultiplied alpha gives incorrect results. Since antialiasing results in pixels that are a linear interpolation of the foreground and background color this is exactly what causes this problem and would be solve by premultiplied alpha. While unrelated to this problem, associativity of blending is a very usefull property for any graphics system since you can draw primitives into a temporary image and then draw that temporary image onto the target image and get the same results as you would get when drawing into the target image directly. I do not know any problem of the unspecified ton of problems you mentiond, but these two properties are so useful that I would not want to work with any system that does not use (or at least support) premultiplied alpha.
RGBA can be unintuitive. Opera implemented transitions by interpolating them (I think it's solved now), which turns out not to work very well: http://bugs.hawn.be/opera/transitions/color/
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.