14072 2011-09-08 01:24:17 +0000 Screen.alphaDepth missing 2013-08-08 13:28:48 +0000 1 1 1 Unclassified CSS CSSOM View unspecified All All RESOLVED WONTFIX P2 normal --- 1 glenn zcorpan jackalmage mike www-dom zcorpan public-css-bugzilla oldest_to_newest 56504 0 glenn 2011-09-08 01:24:17 +0000 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; this is particularly important on television and some handheld devices that have limited transparency support 71814 1 glenn 2012-08-03 05:55:24 +0000 reassign to myself; apparently i am not the default assignee for this component 87643 2 zcorpan 2013-05-14 12:12:05 +0000 (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? 89462 3 glenn 2013-06-18 09:20:36 +0000 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. 89464 4 zcorpan 2013-06-18 09:27:38 +0000 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. 89465 5 glenn 2013-06-18 09:33:35 +0000 We don't need a "statement of interest from a browser vendor" when its the right thing to do. 89543 6 jackalmage 2013-06-19 05:36:57 +0000 (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. 89545 7 glenn 2013-06-19 05:55:19 +0000 (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. 89546 8 glenn 2013-06-19 05:55:56 +0000 (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". 89547 9 zcorpan 2013-06-19 06:07:09 +0000 (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? 89554 10 glenn 2013-06-19 06:37:21 +0000 (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. 89556 11 jackalmage 2013-06-19 07:00:29 +0000 (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. 89575 12 zcorpan 2013-06-19 08:56:20 +0000 (In reply to comment #10) > No (I wouldn't object). Thanks. https://dvcs.w3.org/hg/csswg/rev/e87354ee3440