42017 2010-07-09 18:20:47 -0700 CSSComputedStyleDeclaration::getPropertyCSSValue returns rgba(0, 0, 0, 0) instead of transparent 2018-01-23 08:54:17 -0800 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) PC OS X 10.5 RESOLVED INVALID HasReduction P2 Normal --- 1 rniwa webkit-unassigned ap cdumez cnardi glenn hyatt mitz oliver simon.fraser oldest_to_newest 249419 0 61133 rniwa 2010-07-09 18:20:47 -0700 Created attachment 61133 demonstrates the bug When obtaining the background color from the computed style, it returns rgba(0, 0, 0, 0) even when the background color is not specified. This behavior deviates from other browsers such as Firefox which returns "transparent". 249429 1 mitz 2010-07-09 18:30:02 -0700 I believe that there is content that relies on this behavior, but maybe I am thinking about different yet closely-related behavior. 249430 2 mitz 2010-07-09 18:30:50 -0700 Specifically, I’m thinking of the content from bug 36700. 250794 3 ojan 2010-07-13 16:00:36 -0700 FF3.6 and Opera 10.6 return "transparent" in the test case. Not sure that we can fix this though given the compatibility issue. We could try to convince Firefox/Opera to switch to returning rgba in this case? It's worth filing bugs with them at least to see if they'd be willing to given that there are pages that depend on this behavior. 250827 4 rniwa 2010-07-13 17:00:32 -0700 (In reply to comment #2) > Specifically, I’m thinking of the content from bug 36700. I think those tests can be fixed. Since most of major browsers return "transparent", it's sensible for us to conform to the de-facto standard. Otherwise, Web developers have to keep adding a special case for the WebKit. (In reply to comment #3) > FF3.6 and Opera 10.6 return "transparent" in the test case. Not sure that we can fix this though given the compatibility issue. We could try to convince Firefox/Opera to switch to returning rgba in this case? It's worth filing bugs with them at least to see if they'd be willing to given that there are pages that depend on this behavior. I'm not sure if convincing two other UAs to WebKit's behavior is a sensible thing to do given the total market share of FF and Opera compared to that of ours. 250831 5 ojan 2010-07-13 17:07:10 -0700 > (In reply to comment #3) > > FF3.6 and Opera 10.6 return "transparent" in the test case. Not sure that we can fix this though given the compatibility issue. We could try to convince Firefox/Opera to switch to returning rgba in this case? It's worth filing bugs with them at least to see if they'd be willing to given that there are pages that depend on this behavior. > > I'm not sure if convincing two other UAs to WebKit's behavior is a sensible thing to do given the total market share of FF and Opera compared to that of ours. Except we know that there is a web compatibility problem with the FF/Opera implementation. We don't know of a compatibility problem with the WebKit implementation. 731377 6 glenn 2012-09-30 21:35:28 -0700 I've just drafted serialization rules for this at [1]. If it is accepted, then it should justify keeping the current WK behavior, and not returning 'transparent'. [1] http://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#serializing-css-values 1392048 7 cnardi 2018-01-23 07:07:58 -0800 This bug should be closed; the spec now specifies that this is the correct behavior (see https://drafts.csswg.org/css-color-4/#resolving-color-values) 61133 2010-07-09 18:20:47 -0700 2010-07-09 18:20:47 -0700 demonstrates the bug computedStyleTest2.html text/html 261 rniwa PGh0bWw+Cjxib2R5Pgo8cD4KPHNwYW4gaWQ9InRlc3QiIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OiBpbmhlcml0OyI+aGVsbG8sIHdvcmxkPC9zcGFuPgo8L3A+CjxzY3JpcHQgdHlwZT0idGV4dC9q YXZhc2NyaXB0Ij4KCnZhciBlID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ3Rlc3QnKTsKZG9j dW1lbnQud3JpdGUod2luZG93LmdldENvbXB1dGVkU3R5bGUoZSwgbnVsbCkuYmFja2dyb3VuZENv bG9yKTsKCjwvc2NyaXB0Pgo8L2JvZHk+CjwvaHRtbD4K