Re: IDL: number types

On Fri, Mar 22, 2013 at 1:06 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 3/21/13 10:58 PM, Rick Waldron wrote:
>
>> If you have a 100% provable test case, please file bugs at
>> http://bugs.jquery.com
>>
>
> Will do.  Clearly you don't consider things that change jQuery.attr or
> whatnot (which is used internally in jQuery code) interesting, right? What
> _do_ you consider interesting?


Thanks in advance.

This a tough question to answer, I'd say anything that redefines jQuery
APIs is out of scope, only because it's such a slippery slope. Any place
where the result of passing an some arbitrary, likely unexpected argument
is a program state that is either undocumented and not yet covered in the
tests is a bug and I want to know about it. We care a lot, and though we
can't always fix all of the edge case bugs, we absolutely want them
documented and understood.


>
>
>  I'd be interested in seeing jQuery's API overloads exposed as WebIDL.
>>
>
> Well, let's look at parseHTML.
>
> It's not quite identical, because WebIDL will coerce the first argument to
> string and because WebIDL won't let you duck-type contexts with
> createElement on them, but:
>
>   parseHTML(DOMString data, boolean context);
>   parseHTML(DOMString data, optional Document? context,
>             optional boolean keepScripts);
>


Wow, neat. Thanks for whipping that up :)

Rick


>
> -Boris
>