reassign to myself; apparently i am not the default assignee for this component

(In reply to comment #0)
> the current definition of Screen.colorDepth excludes alpha channel;
> 
> it is also desirable to expose the alpha depth supported by the screen in
> order to make effective decisions about the use of the opacity property;

Can you elaborate on how one would use this information? Do you have any examples on pages working around the lack of this feature with e.g. browser sniffing?

> this is particularly important on television and some handheld devices that
> have limited transparency support

Which devices have limited transparency support? Are they still relevant?

Client JS can use this information to make a wide variety of decisions about what image resources to use, about what opacity values may be significant, about various compositing features etc.

Every device has limited transparency support in the sense that it (the device) doesn't support more depth than its hardware permits. So yes it is relevant.

I'd like to see examples on pages working around the lack of this feature with e.g. browser sniffing or stated implementor interest from a browser vendor.

We don't need a "statement of interest from a browser vendor" when its the right thing to do.

(In reply to comment #5)
> We don't need a "statement of interest from a browser vendor" when its the
> right thing to do.

Yes, we absolutely do, when it's a feature with a high chance of being useless in practice.

I'm with Simon - unless you can show devices which are important enough for authors and/or implementors to care about, I'm against adding this.  It's not important enough to stand on its own theoretical legs ahead of demonstrated interest.

(In reply to comment #6)
> (In reply to comment #5)
> > We don't need a "statement of interest from a browser vendor" when its the
> > right thing to do.
> 
> Yes, we absolutely do, when it's a feature with a high chance of being
> useless in practice.
> 
> I'm with Simon - unless you can show devices which are important enough for
> authors and/or implementors to care about, I'm against adding this.  It's
> not important enough to stand on its own theoretical legs ahead of
> demonstrated interest.

I wouldn't mind removing pixelDepth and colorDepth, which are equally "useless in practice" and possess no justification for inclusion other than they happen to be implemented in a bug-for-bug compatible manner.

However, if these are to be implemented, then I will formally object if an alphaDepth is not defined as well.

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > We don't need a "statement of interest from a browser vendor" when its the
> > > right thing to do.
> > 
> > Yes, we absolutely do, when it's a feature with a high chance of being
> > useless in practice.
> > 
> > I'm with Simon - unless you can show devices which are important enough for
> > authors and/or implementors to care about, I'm against adding this.  It's
> > not important enough to stand on its own theoretical legs ahead of
> > demonstrated interest.
> 
> I wouldn't mind removing pixelDepth and colorDepth, which are equally
> "useless in practice" and possess no justification for inclusion other than
> they happen to be implemented in a bug-for-bug compatible manner.
> 
> However, if these are to be implemented, then I will formally object if an
> alphaDepth is not defined as well.

I mean "implemented in the spec".

(In reply to comment #7)
> I wouldn't mind removing pixelDepth and colorDepth, which are equally
> "useless in practice" and possess no justification for inclusion other than
> they happen to be implemented in a bug-for-bug compatible manner.

Would you object if they were defined to return a predefined value of 24 and the spec noted that they are useless but are included for compatibility?

(In reply to comment #9)
> (In reply to comment #7)
> > I wouldn't mind removing pixelDepth and colorDepth, which are equally
> > "useless in practice" and possess no justification for inclusion other than
> > they happen to be implemented in a bug-for-bug compatible manner.
> 
> Would you object if they were defined to return a predefined value of 24 and
> the spec noted that they are useless but are included for compatibility?

No (I wouldn't object). But I would question the need or wisdom to codify such nonsense in a W3C spec. Just because some feature is implemented in some set of browsers is no reason to necessarily write it into a W3C spec. In this case, we would be better off to leave it out of the spec IMO.

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #7)
> > > I wouldn't mind removing pixelDepth and colorDepth, which are equally
> > > "useless in practice" and possess no justification for inclusion other than
> > > they happen to be implemented in a bug-for-bug compatible manner.
> > 
> > Would you object if they were defined to return a predefined value of 24 and
> > the spec noted that they are useless but are included for compatibility?
> 
> No (I wouldn't object). But I would question the need or wisdom to codify
> such nonsense in a W3C spec. Just because some feature is implemented in
> some set of browsers is no reason to necessarily write it into a W3C spec.
> In this case, we would be better off to leave it out of the spec IMO.

If there is compat reason to do so, we leave them in and render them cheap and useless.  If there's not, we drop them.  It's a really simple calculus.

(In reply to comment #10)
> No (I wouldn't object).

Thanks.

https://dvcs.w3.org/hg/csswg/rev/e87354ee3440