W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Re: IDL: number types

From: Rick Waldron <waldron.rick@gmail.com>
Date: Fri, 22 Mar 2013 08:04:13 -0400
Message-ID: <CAHfnhfrZ8T5Kbs8i-Ua=B_4+oeqmOett3V7HNuH5TQ+HzvVLgg@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Marcos Caceres <w3c@marcosc.com>, Yehuda Katz <wycats@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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
>
Received on Friday, 22 March 2013 12:05:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:09 UTC