Re: [cssom-view] colorDepth/pixelDepth, match implementations or theoretical purity?

On Tue, Jun 18, 2013 at 3:25 AM, Simon Pieters <> wrote:
> In we have a situation
> where all implementations and the spec agree on one thing, but that thing is
> wrong according to the industry standard terms. It is obvious that Glenn and
> I have different ideas about what the spec should say. In HTML, the policy
> in situations like these have almost always been to just match the
> implementations.
> There can be reasonable exceptions where we would want to not match
> implementations despite interoperability, like if a security problem is
> identified or if a different definition would be vastly superior *and* the
> feature is not widely used in the Web such that changing it does not cause
> compat problems.
> In the case of colorDepth and pixelDepth, the proposed change does not
> address any security problem. It would start to expose the number of bits in
> the alpha channel (also see
> The attributes can be used for fingerprinting. The proposed change does not
> change that, in fact it probably increases the fingerprinting. If we want to
> remove this fingerprinting vector, the attributes can be made to return a
> static value, probably 24. It seems at least some current implementations do
> not return a static value.
> I'd like to hear from other people what they think. Do implementers want to
> change these to match the industry terms? Or remove the fingerprinting
> vector? Or leave as is?

Following up on this, since the discussion took place on the bug instead...

These features are basically useless.  Nearly every device that
matters has 24/8 color, and even for those that have 30/2 or something
more exotic, you need the entire browser and rendering pipeline to
support it before it makes sense to return the value to authors.

I support speccing colorDepth/pixelDepth as a static 24 for now, and
separately, checking usage to see if we can just drop it.  I support
*not* implementing alphaDepth at all, for the reasons stated above.


Received on Wednesday, 19 June 2013 21:50:48 UTC