On Mon, Oct 1, 2012 at 10:58 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
> From: Rick Waldron [mailto:waldron.r...@gmail.com]
> >
> > I wasn't specific enough in my original question, but I did note that I
> wasn't referring to construction exceptions, so I'm guessing by your
> res
From: Rick Waldron [mailto:waldron.r...@gmail.com]
>
> I wasn't specific enough in my original question, but I did note that I
> wasn't referring to construction exceptions, so I'm guessing by your response
> that you actually _just_ meant testing for "constructability". I apologize
> for not b
** **
>
> *From:* Rick Waldron [mailto:waldron.r...@gmail.com]
> *Sent:* Friday, September 28, 2012 4:24 PM
> *To:* Cameron McCormack
> *Cc:* Travis Leithead; Boris Zbarsky; public-script-co...@w3.org;
> public-webapps
> *Subject:* Re: In WebIDL, should having a .prototype on interface
note in Chome, that's due to the subtle difference in implementation of WebIDL
per the above requirement.
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, September 28, 2012 4:24 PM
To: Cameron McCormack
Cc: Travis Leithead; Boris Zbarsky; public-script-co...@w3.org; pub
On Fri, Sep 28, 2012 at 4:14 PM, Cameron McCormack wrote:
> Travis Leithead:
>
>> I guess you'd check for URL.href then? Or try { new URL("/test"); } catch
>> (ex) { console.log("not supported"); }
>>
>
> I agree with Travis, you should be checking the particular features you
> want to use, rathe
Travis Leithead:
I guess you'd check for URL.href then? Or try { new URL("/test"); } catch (ex) {
console.log("not supported"); }
I agree with Travis, you should be checking the particular features you
want to use, rather than checking the existence of the prototype as a
proxy for that test.
> From: Boris Zbarsky [mailto:bzbar...@mit.edu]
>
> On 9/28/12 12:38 PM, Travis Leithead wrote:
> > It seems more important to check for the features of the spec, rather
> than spec support in general. I would expect if (URL.createObjectURL) for
> example.
>
> You have it backwards. That's check
On 9/28/12 12:38 PM, Travis Leithead wrote:
It seems more important to check for the features of the spec, rather than spec
support in general. I would expect if (URL.createObjectURL) for example.
You have it backwards. That's checking for the file API bits. How do
you check whether you can
> From: Boris Zbarsky [mailto:bzbar...@mit.edu]
>
> On 9/28/12 4:28 AM, Cameron McCormack wrote:
> > 1. Should we make it so that if you implement one or more partial
> > interfaces but not the actual one, then an empty actual interface is
> > implied?
>
> That's fine by me.
>
> > 2. Is it reall
On 9/28/12 4:28 AM, Cameron McCormack wrote:
1. Should we make it so that if you implement one or more partial
interfaces but not the actual one, then an empty actual interface is
implied?
That's fine by me.
2. Is it really important to avoid a prototype from existing on URL in
this case? I
Boris Zbarsky:
Should WebIDL change here? Should FileAPI change?
Technically, it is not possible to implement File API without also
implementing the URL specification, since if there is a "partial
interface URL" then there must also be a "interface URL" in the set of
IDL fragments that you
> From: Boris Zbarsky [mailto:bzbar...@mit.edu]
>
> On 9/21/12 12:39 PM, Travis Leithead wrote:
> > I believe that firstly, the File API spec needs to be rationalized
> against the URL API
>
> They're already there. File API explicitly says that if you support URL
> API then you get a normal int
On 9/21/12 12:39 PM, Travis Leithead wrote:
I believe that firstly, the File API spec needs to be rationalized against the
URL API
They're already there. File API explicitly says that if you support URL
API then you get a normal interface object and proto object.
Once that happens, I wond
> From: Boris Zbarsky [mailto:bzbar...@mit.edu]
>
> The spec currently says[1]:
>
>The value of the "prototype" property of an interface object for a
>non-callback interface MUST be an object called the interface
>prototype object.
>
> At the same time, we have specs like File API de
14 matches
Mail list logo