| Summary: | CSSComputedStyleDeclaration::getPropertyCSSValue returns rgba(0, 0, 0, 0) instead of transparent | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> | ||||
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED INVALID | ||||||
| Severity: | Normal | CC: | ap, cdumez, cnardi, glenn, hyatt, mitz, oliver, simon.fraser | ||||
| Priority: | P2 | Keywords: | HasReduction | ||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | PC | ||||||
| OS: | OS X 10.5 | ||||||
| Attachments: |
|
||||||
I believe that there is content that relies on this behavior, but maybe I am thinking about different yet closely-related behavior. 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. (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. > (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.
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 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) |
Created attachment 61133 [details] 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".