Clarify what happens if you set PannerNode.{panningModel,distanceModel} to an invalid value

[olivierthereaux]

Originally reported on W3C Bugzilla ISSUE-19902 Wed, 07 Nov 2012 23:28:43 GMT
Reported by Ehsan Akhgari [:ehsan]
Assigned to

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... :/ )

[olivierthereaux]

Original comment by Chris Rogers on W3C Bugzilla. Tue, 13 Nov 2012 22:32:30 GMT

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.

[olivierthereaux]

Original comment by Ehsan Akhgari [:ehsan] on W3C Bugzilla. Thu, 15 Nov 2012 01:32:24 GMT

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

[olivierthereaux]

Original comment by Chris Rogers on W3C Bugzilla. Fri, 16 Nov 2012 18:41:46 GMT

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

[olivierthereaux]

Original comment by Ehsan Akhgari [:ehsan] on W3C Bugzilla. Fri, 16 Nov 2012 19:31:34 GMT

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

[olivierthereaux]

Original comment by Chris Rogers on W3C Bugzilla. Fri, 16 Nov 2012 19:58:19 GMT

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

[olivierthereaux]

Original comment by Ehsan Akhgari [:ehsan] on W3C Bugzilla. Fri, 16 Nov 2012 22:18:58 GMT

Yep, I think that makes sense. Thanks!

[cwilso]

We've removed the integers.