19902 2012-11-07 23:28:43 +0000 Clarify what happens if you set PannerNode.{panningModel,distanceModel} to an invalid value 2014-10-28 17:17:27 +0000 1 1 1 Unclassified AudioWG Web Audio API unspecified PC All CLOSED WONTFIX P2 normal TBD 1 ehsan crogers public-audio oldest_to_newest 78020 0 ehsan 2012-11-07 23:28:43 +0000 I think we should throw DOM_INDEX_SIZE_ERR. (This and other similar bugs wouldn't have been a problem if we used Web IDL enums... :/ ) 78288 1 crogers 2012-11-13 22:32:30 +0000 If you feel strongly about Web IDL enums, we can still consider switching to them. But since these enums are already in wide use as integers, we'd have to support setters as either int or string. We'd still have to throw an exception for illegal values even for Web IDL. 78334 2 ehsan 2012-11-15 01:32:24 +0000 We're considering enabling Web IDL enum attribute setters to throw if passed an invalid value, which would mean that we'll get what I'm asking for here for free. And yes, I still think that using Web IDL enums would be a good change because of the increase in code readability and the possibilities of using the IDL parser to do various sorts of checking for the implementers. However I don't think that it would be very good for us to allow setting these both as integers and strings... How did WebKit deal with the other breaking changes that was recently made in the spec (such as renaming functions, etc.)? 78417 3 crogers 2012-11-16 18:41:46 +0000 (In reply to comment #2) > We're considering enabling Web IDL enum attribute setters to throw if passed > an invalid value, which would mean that we'll get what I'm asking for here > for free. And yes, I still think that using Web IDL enums would be a good > change because of the increase in code readability and the possibilities of > using the IDL parser to do various sorts of checking for the implementers. > > However I don't think that it would be very good for us to allow setting > these both as integers and strings... How did WebKit deal with the other > breaking changes that was recently made in the spec (such as renaming > functions, etc.)? For the recent name changes such as noteOn() -> start(), WebKit continues to provide legacy support, which can eventually be phased out during a transition period. I added a section in the spec called "Deprecation Notes" to make note of these types of changes. Different implementations may choose to support or not support the legacy names, and for how long they would be supported. 78420 4 ehsan 2012-11-16 19:31:34 +0000 OK. Can the same approach be taken about the numeric attributes? 78422 5 crogers 2012-11-16 19:58:19 +0000 (In reply to comment #4) > OK. Can the same approach be taken about the numeric attributes? Yes, for the "enum" type attributes I think so. The only gotcha is that the "getters" would now return a string instead of an integer. But I think the main backwards compatibility concern is people setting these attributes, so I'm not so worried about that. 78426 6 ehsan 2012-11-16 22:18:58 +0000 Yep, I think that makes sense. Thanks! 113929 7 olivier.thereaux 2014-10-28 17:14:30 +0000 Web Audio API issues have been migrated to Github. See https://github.com/WebAudio/web-audio-api/issues 114079 8 olivier.thereaux 2014-10-28 17:17:27 +0000 Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.