629883 - Fix rgba serialization for fully transparent colors

Status: RESOLVED INVALID

(Core :: Graphics: Canvas2D, defect)

Description

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

We need to serialize 0 as 0.0, apparently. Opera and Chrome pass this test:

<http://www.w3c-test.org/html/tests/submission/PhilipTaylor/canvas/2d.fillStyle.get.transparent.html>

Comment 1

[Boris Zbarsky [:bzbarsky]]

> We need to serialize 0 as 0.0, apparently.

Why?  That's a ridiculous thing to do.  Why does the spec require that?

Comment 2

[Boris Zbarsky [:bzbarsky]]

If we do want to do this, the question is whether we should be hacking in a special-case for 0 in canvas code, changing ColorComponentToFloat to do this in general, or something else...

But really, I think the spec is broken in this case.

Comment 3

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Actually, you regressed this in bug 587106. I'm writing a patch.

Comment 4

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Attachment: Patch v1 (special case zero opacity)

Not yet tested

Comment 5

[Boris Zbarsky [:bzbarsky]]

"regressed" on purpose; see comment 2.  I made it work the same way serializing opacity values works everywhere else in the style system.  I don't think we should have separate rules for serializing it here vs other places.

Comment 6

[Boris Zbarsky [:bzbarsky]]

The patch is fine as far as it goes, but I still question whether this is a desirable change to start with.

Comment 7

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Attachment: Patch v1.1

I would be perfectly fine with the spec changing, but unless that happens (which I wouldn't expect, given the interoperable implementations), I don't think we should be changing away from the spec here.

This patch passes tests in content/canvas.

Comment 8

[Boris Zbarsky [:bzbarsky]]

OK.  How about we gather some data?  How does CSS rgba() color serialization work in the various browsers involved?  How does it work for canvas?  Before we start adding random extra code and special-casing things, I would like us to have some idea of what the goals are (if any; "just implement whatever hixie happened to spec" is NOT a goal for me).

Comment 9

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Looking at http://software.hixie.ch/utilities/js/live-dom-viewer/saved/813:

+-----------+-------------------+-------------------+---------------------+
| Browser   | doc.styleSheets   | getComputedStyle  | canvas              |
+-----------+-------------------+-------------------+---------------------+
| Fx 3.6    | rgba(0, 0, 20, 0) | transparent       | rgba(0, 0, 20, 0.0) |
| Trunk     | rgba(0, 0, 20, 0) | transparent       | rgba(0, 0, 20, 0)   |
| Opera 11  | rgba(0, 0, 20, 0) | rgba(0, 0, 20, 0) | rgba(0, 0, 20, 0.0) |
| Chrome 10 | rgba(0, 0, 20, 0) | rgba(0, 0, 20, 0) | rgba(0, 0, 20, 0.0) |
+-----------+-------------------+-------------------+---------------------+

It appears to me that matching columns are more useful for webdevs than matching rows.

Generally, I think that matching what's been specced since 2005 or earlier and has been interoperably implemented since should be preferred above platform consistency. It would have made a lot of sense to change this in 2005; I don't believe it makes sense to change it now. All it does now is make life harder for developers, as it adds a codepath that, AFAICT, didn't exist before.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> It appears to me that matching columns are more useful for webdevs than
> matching rows.

Well, ideally both columns and rows would match.

> Generally, I think that matching what's been specced since 2005 or earlier

Where by "specced" we mean "write up what got implemented by a particular implementation without worrying about whether it makes sense", right?

As for the cost of changing this, are web developers depending on this right now?  That's the real question...

Comment 11

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Well yes, reverse-engineered from WebKit. If I were designing this, I would certainly side with you. My point is that the design phase ended years ago, and, also, that this is not a worse inconsistency than the many others that riddle this lovely platform. I don't think having 0 instead of 0.0 is a big enough improvement to move away from the spec we're targeting.

Are there pages out there that depend on this behaviour (apart from the test that prompted this bug)? I don't know. Given the size of the web, I wouldn't be surprised if there were. In any case, if they rely on it, we're breaking them, and if they don't, we're not helping them.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> My point is that the design phase ended years ago

Why?  This is an area where there's active spec work and lots of incompatibility last I checked.  Why are we selectively freezing parts of it?

> I don't think having 0 instead of 0.0 is a big enough improvement to move away
> from the spec we're targeting.

I think you an I have very different opinions about the maturity of this spec...

Comment 13

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(In reply to comment #12)
> > My point is that the design phase ended years ago
> 
> Why?  This is an area where there's active spec work and lots of
> incompatibility last I checked.  Why are we selectively freezing parts of it?
> 
> > I don't think having 0 instead of 0.0 is a big enough improvement to move away
> > from the spec we're targeting.
> 
> I think you an I have very different opinions about the maturity of this
> spec...

IMO, the spec is stable when it's been interoperably implemented. That's not true for the entire spec, or for the canvas section, but it was true for this particular feature.

Comment 14

[Boris Zbarsky [:bzbarsky]]

And I think that "this particular feature" is too narrow to consider in isolation.

Comment 15

[Boris Zbarsky [:bzbarsky]]

And in particular, freezing parts of specs that are interoperably implemented but may be impacted by the parts that aren't isn't workable.

Comment 16

[Boris Zbarsky [:bzbarsky]]

By the way, based on http://crivens.net/test/rgba-results.html IE9 and Safari 5 agree with Firefox 4 here...

Comment 17

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

http://html5.org/tools/web-apps-tracker?from=5874&to=5875