3 ms·
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/
by overgard 14y ago
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.
- anonymous 14y agoFirst, 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.
- codeka 14y agoI would buy your argument if we were talking about a gradient. But this isn't a gradient, it's an anti-aliased line. 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.