RE: In WebIDL, should having a .prototype on interface objects be optional?

2012-09-28 Thread Travis Leithead 
I was alluding to this behavior for interface objects (e.g., "URL"):

4.4.1.1. Interface object [[Call]] method 
ยง
If the interface is 
declared with a 
[Constructor] extended 
attribute, then 
the interface 
object can be 
called as a function to create an object that implements that interface. 
Interfaces that do not have a constructor will throw an exception when called 
as a function.
..."not supported" just means "URL is not a constructor/won't parse a URL 
string parameter". As Cameron noted, it's not an idea test-in the instance you 
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; public-webapps
Subject: Re: In WebIDL, should having a .prototype on interface objects be 
optional?


On Fri, Sep 28, 2012 at 4:14 PM, Cameron McCormack 
mailto:c...@mcc.id.au>> 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, rather than checking the existence of the prototype as a proxy for that 
test.

If URL.prototype was required to exist, you could just do ("href" in 
URL.prototype).  Since it currently doesn't, you could do ("href" in 
(URL.prototype || {})).

I'm interested in knowing more about what would throw. If URL is not a 
constructor function, it will throw, but if it is what aspect of the above 
would be "not supported". I ask because currently Chrome's URL (webkitURL) can 
construct, but it constructs a fairly useless instance and throws nothing (new 
webkitURL("/test");)

Thanks in advance

Rick

Re: In WebIDL, should having a .prototype on interface objects be optional?

2012-09-28 Thread Rick Waldron 
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, rather than checking the existence of the prototype as a proxy
> for that test.
>
> If URL.prototype was required to exist, you could just do ("href" in
> URL.prototype).  Since it currently doesn't, you could do ("href" in
> (URL.prototype || {})).
>

I'm interested in knowing more about what would throw. If URL is not a
constructor function, it will throw, but if it is what aspect of the above
would be "not supported". I ask because currently Chrome's URL (webkitURL)
can construct, but it constructs a fairly useless instance and throws
nothing (new webkitURL("/test");)

Thanks in advance

Rick

Re: In WebIDL, should having a .prototype on interface objects be optional?

2012-09-28 Thread Cameron McCormack 

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.


If URL.prototype was required to exist, you could just do ("href" in 
URL.prototype).  Since it currently doesn't, you could do ("href" in 
(URL.prototype || {})).

RE: In WebIDL, should having a .prototype on interface objects be optional?

2012-09-28 Thread Travis Leithead 
> 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 checking for the file API bits.  How do you
> check whether you can actually work with URL objects?

I guess you'd check for URL.href then? Or try { new URL("/test"); } catch (ex) 
{ console.log("not supported"); }

[Bug 18221] the word 'using' is repeated in the last line following 'Shared Blacklists' (This information can then be shared with other sites, using using visitors' IP)

2012-09-28 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18221

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 18189] "The DedicatedWorkerGlobalScope interface must not exist ..." s/interface/interface object/ ?

2012-09-28 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18189

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||i...@hixie.ch
 Resolution||WORKSFORME

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: In WebIDL, should having a .prototype on interface objects be optional?

2012-09-28 Thread Boris Zbarsky 

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 actually work with URL objects?


-Boris

RE: In WebIDL, should having a .prototype on interface objects be optional?

2012-09-28 Thread Travis Leithead 
> 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 really important to avoid a prototype from existing on URL in
> > this case?  I think I'd rather just leave it exist.
> 
> I think the idea is to allow object-detection of whether the URL spec is
> supported.

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. I also 
think .prototype removal need not be a special case for
this circumstance.

Re: In WebIDL, should having a .prototype on interface objects be optional?

2012-09-28 Thread Boris Zbarsky 

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 think I'd rather just leave it exist.


I think the idea is to allow object-detection of whether the URL spec is 
supported.


-Boris

[Bug 19114] (editorial) ""gopher" missing quote

2012-09-28 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19114

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ann...@annevk.nl
 Resolution||FIXED

--- Comment #1 from Anne  2012-09-28 12:59:03 UTC ---
https://github.com/whatwg/url/commit/d462418c63a14e8797ed1ee835f55adce61ce14c

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 19114] New: (editorial) ""gopher" missing quote

2012-09-28 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19114

   Summary: (editorial) ""gopher" missing quote
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: URL
AssignedTo: m...@w3.org
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


http://url.spec.whatwg.org/#urls

[[
"gopher
]]

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 10894] [pending URL spec] Reflecting an IDL attribute with a URL should try to canonicalize whatever value is set

2012-09-28 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10894

Anne  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Anne  2012-09-28 10:47:41 UTC ---
http://url.spec.whatwg.org/ now defines this. HTML just needs to be updated to
refer to it.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 17772] [URL] The definition of "absolute url" makes https:foo not an absolute url, since its behavior depends on whether the base is https: or not. Is that desired? In particular, using this

2012-09-28 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17772

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Anne  2012-09-28 10:43:56 UTC ---
http://url.spec.whatwg.org/ defines this behaviour now and makes browsers'
behavior for ws/wss conforming. All that is left here is updating the WebSocket
API to refer to the new URL standard.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 15684] [URL] Replacing backslash with forward slash in URIs doesn't seem to be necessitated by web compat

2012-09-28 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15684

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #6 from Anne  2012-09-28 10:42:20 UTC ---
As far as I can tell Gecko is the only browser that does not do this. I'd
rather convince Gecko to change than everyone else. http://url.spec.whatwg.org/
handles / and \ identically in URLs with hierarchical schemes.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 14210] Reflecting href with a URL that doesn't resolve doesn't return the empty string in browsers (at least opera/moz, don't know what URL would fail to resolve in webkit). Instead it returns

2012-09-28 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14210

Anne  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||ann...@annevk.nl
 Resolution||FIXED

--- Comment #6 from Anne  2012-09-28 10:34:43 UTC ---
http://url.spec.whatwg.org/ defines this per how browsers work. So now all that
is needed is that HTML needs to use the definitions from
http://url.spec.whatwg.org/

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 15718] Need to decide if URLs can ever fail to parse

2012-09-28 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15718

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ann...@annevk.nl
 Resolution||FIXED

--- Comment #1 from Anne  2012-09-28 10:33:37 UTC ---
I have decided that yes, there are some cases where the "invalid flag" will be
set.

http://url.spec.whatwg.org/

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: [widgets] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) is a Proposed Edited Recommendation

2012-09-28 Thread Tobie Langel 
On 9/28/12 10:18 AM, "Charles McCathie Nevile" 
wrote:

>On Thu, 27 Sep 2012 23:55:37 +0400, Tobie Langel  wrote:
>
>> On 9/27/12 9:35 PM, "Arthur Barstow"  wrote:
>>
>>> W3C Advisory Committee members are asked to "Please review the
>>> specification and indicate whether you endorse it as W3C Recommendation
>>> or object to its advancement by completing the following questionnaire
>>> ".
>>
>> I'm getting the following error when answering the questionnaire:
>
>Hopefully it is fixed now (Dom++)

It is. Thanks, Dom!

--tobie

Re: In WebIDL, should having a .prototype on interface objects be optional?

2012-09-28 Thread Cameron McCormack 

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


Some questions then:

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?  If not, then File API needs to define an empty URL interface 
for the partial one to latch on to.


2. Is it really important to avoid a prototype from existing on URL in 
this case?  I think I'd rather just leave it exist.

Re: [widgets] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) is a Proposed Edited Recommendation

2012-09-28 Thread Charles McCathie Nevile 

On Thu, 27 Sep 2012 23:55:37 +0400, Tobie Langel  wrote:


On 9/27/12 9:35 PM, "Arthur Barstow"  wrote:


W3C Advisory Committee members are asked to "Please review the
specification and indicate whether you endorse it as W3C Recommendation
or object to its advancement by completing the following questionnaire
".


I'm getting the following error when answering the questionnaire:


Hopefully it is fixed now (Dom++)

cheers

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com