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.

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.)?

(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.

OK.  Can the same approach be taken about the numeric attributes?

(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.

Yep, I think that makes sense.  Thanks!

Web Audio API issues have been migrated to Github. 
See https://github.com/WebAudio/web-audio-api/issues

Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.