This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Because that's what I see Chrome do, so that's how I spec'ed it :-p On a less flippant note, calling this method without arguments or with too many is probably a mistake that implementations should flag early.
getData()?
Heh, too deep inside what I was writing to be really clear.. This getData(): http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dom-datatransfer-getdata
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: I don't understand what it is you want me to change. There's nothing special about getData(), it's just a one-argument function, and it works the same regarding handling missing or extra arguments as all other functions, as defined by WebIDL.
OK, I don't understand (yet) how to piece together the HTML5 and WebIDL specs to get the full picture. Guess "3. If S is empty, throw a TypeError." under http://dev.w3.org/2006/webapi/WebIDL/#es-operations is what I'm missing. Chrome raises a SyntaxError, not a TypeError though. Does that mean the IDL in the HTML5 spec should change DOMString getData(in DOMString format); to DOMString getData(in DOMString format) raises SyntaxError; ?
Please note that the plan is to make functions calls with too few or too many arguments *not* to throw (mentioned in http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0094.html). `aDataTransfer.getData()` would thus be equivalent to `aDataTransfer.getData("undefined")`. raises() clauses are entirely optional -- implementations of IDL operations are allowed to throw exceptions that are not listed in a raises() clause. Also, TypeError and SyntaxError are not concepts that exist at the IDL level. Only exceptions explicitly defined in IDL can be listed there. (It may make sense to change that, in the spirit of "serve JS first, allow other languages second".)
Makes sense to me not to throw by default - it's not like JS is consistent anyway.. Unless WebIDL defines an extended attribute [ThrowsIfNumberOfArgumentsIsUnexpected] or something like that, individual specs should say in the prose what happens. (Then again, it would be nice to have a way to indicate this in the IDL without repeating such things in prose all over the place.. A related question - JS only - is how methods behave if they are called with an unexpected this object. There is no IDL attribute to indicate whether i.e. "window.alert.call(document, 'Do you see this alert?')" should throw? But now I'm off-topic..) I think that means it's over to you again, Ian ;) I propose adding a sentence more or less like "If getData() is called with less than or more than one single argument, the implementation must throw a SyntaxError exception." (Opera's old WRONG_ARGUMENTS_ERROR would have been nice but I think we never got that into a spec? Haven't looked it up, so I may be plain wrong.. In any case better to just follow WebKit on this.)
(In reply to comment #6) > A related question - JS only - is how methods behave if > they are called with an unexpected this object. There is no IDL attribute to > indicate whether i.e. "window.alert.call(document, 'Do you see this alert?')" > should throw? But now I'm off-topic.. You're right, Web IDL doesn't make this throw. I thought I had wording in there to make it throw, but I can't see any. I think there should be a step in http://dev.w3.org/2006/webapi/WebIDL/#es-operations that checks that the this object is of the right type and throws a TypeError if it is not. Filed bug 12635 for that.
What is special about getData() here?
(In reply to comment #6) > individual > specs should say in the prose what happens. I strongly object to this. This should all be defined in WebIDL and all specifications should use the default behaviour, unless there is strong compat risk to that.
(In reply to comment #8) > What is special about getData() here? *If* most other methods defined by the implementation do not throw when called with too many or too few arguments, doing so makes getData() special. I don't know if that is the case. Having thought a bit more, I now think it would make sense to throw by default, because AFAIK WebIDL already has a way to mark methods that accept a variable number of arguments. Going forward, spec authors should be required to mark up those methods accordingly and the rest should throw. If Cameron agrees with that we can close this bug again :-)
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: getData() is not special here
(In reply to comment #10) > Having thought a bit more, I now think it would make sense to throw by default, > because AFAIK WebIDL already has a way to mark methods that accept a variable > number of arguments. Going forward, spec authors should be required to mark up > those methods accordingly and the rest should throw. > > If Cameron agrees with that we can close this bug again :-) Sorry, I missed this comment until now. Web IDL recently changed to throw if too few arguments are passed, but to ignore any extra arguments. Specs shouldn't override this unless they have good reason to (e.g. web compatibility concerns). I haven't added any syntactic facility to do this overriding in the IDL.
mass-move component to LC1