[Bug 24042] [imports]: Parser should not wait on external resources inside imports

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24042
Bug 24042 depends on bug 24808, which changed state.

Bug 24808 Summary: [imports]: document.write() in imports should do nothing.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24808

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 24808] [imports]: document.write() in imports should do nothing.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24808

Morrita Hajime  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Morrita Hajime  ---
(In reply to Ian 'Hixie' Hickson from comment #8)
> This is resolved now, no? Calling document.write() on an import doc throws,
> and calling it on a master document just works as already specified, nothing
> new.
You're right. This was reopened to request removing monkey-patching.
As it is merged to HTML, this will no longer an issue. closing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [push-api] Identifying registrations

[Martin Thomson]

On 13 May 2014 10:24, Michael van Ouwerkerk  wrote:
> Hi Martin, note that the latest proposal is to have only a single
> registration at a time:
> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0223.html

Oh well, that's a little unfortunate.  It's logical of course.
Applications can perform routing on their own.

[Bug 25697] New: [imports]: why can imports be sync?

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25697

Bug ID: 25697
   Summary: [imports]: why can imports be sync?
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: i...@hixie.ch
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 20683

"an import that is blocking scripts"

Isn't this exactly the kind of thing we learnt from style sheets we should
never do? Making anything synchronous will just make performance worse, no?

Isn't the best practice going to be to make them async and then have code
handle the components and stuff coming in later? e.g. the way Google+ loads a
static version of itself and then fixes itself up so that it loads "REALLY
FAST" but isn't actually interactive until sometime after it's loaded?

Why not make them all async?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 25696] New: [imports]:

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25696

Bug ID: 25696
   Summary: [imports]: 
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: i...@hixie.ch
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 20683

"The import is fetched and applied regardless of the media attribute of the
link matches the environment or not"

Why are we not just reusing the normal  logic here?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Blob URL Origin

[Jonas Sicking]

On Tue, May 13, 2014 at 11:19 AM, Arun Ranganathan  wrote:
> And really, all user agents seem to agree that the origin is that of the
> settings object today. That model seems to work. The remaining question is
> the pro and con of denoting this in the URL's syntax. abarth's advice is to
> put the syntax horse in front of the origin cart:
> http://krijnhoetmer.nl/irc-logs/whatwg/20140508#l-913

We definitely want to put the origin in the URL's syntax. The only
reason Gecko can get away with not doing that is because we are
single-process. But that's not something we want to impose on other
browsers.

I think the main issue to figure out is the exact syntax. I.e. if it's
ok that things like ':' and '//' appear in the URL. Given that Anne
said that it was I think the most obvious answer here is to use URLs
like:

blob:https://cantaloupe.org/e55f2c33-f000-4e88-b89c-874ae09e7f93
blob:http://example.com:8080/e55f2c33-f000-4e88-b89c-874ae09e7f93

/ Jonas

Re: Blob URL Origin

[Arun Ranganathan]

On May 12, 2014, at 8:28 AM, Anne Van Kesteren  wrote:

> It still seems a bit sad though to tie these URLs to origins in this
> fashion. Jonas is correct that there are inconsistencies in how data
> URLs and origins behave across browsers, but it seems like we should
> sort those out first then if we want a consistent story.




Since Blobs can be passed around in a number of well-known ways, it seems that 
the most legitimate origin of a Blob URL is the origin of the script that 
coined it. I’m not entirely sure how to take action on “it still seems a bit 
sad” though. Sad because of security considerations? After drying my tears, I 
can’t construct a meaningful attack, but I’d welcome more information about 
what benefits are gained by encoding certain “HTTP-reserved” components of URL 
nomenclature (and here, Chrome is inconsistent between blob: and filesystem:). 
Sad because of aesthetics? It’s pretty enough for Safari.

And really, all user agents seem to agree that the origin is that of the 
settings object today. That model seems to work. The remaining question is the 
pro and con of denoting this in the URL’s syntax. abarth’s advice is to put the 
syntax horse in front of the origin cart: 
http://krijnhoetmer.nl/irc-logs/whatwg/20140508#l-913

Also, if it’s “sad” because it doesn’t match data: URL’s way of reckoning 
origin, that doesn’t seem sad to me. 

— A*

Re: [push-api] Identifying registrations

[Michael van Ouwerkerk]

Hi Martin, note that the latest proposal is to have only a single
registration at a time:
http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0223.html

This means that unregister can remain on PushManager and requires no
arguments.

Yesterday I also posted a github issue with the suggestion to change the
unregister return value:
https://github.com/w3c/push-api/issues/4

Respec was fixed recently to support parameterization after this discussion:
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0697.html

Regards,

Michael






On Tue, May 13, 2014 at 6:10 PM, Martin Thomson wrote:

> On 13 May 2014 06:39, Michael van Ouwerkerk 
> wrote:
> > Martin, in Chrome we use registrationId and endpoint for distinct
> purposes.
> > The endpoint is the push server url to which the app server posts new
> > messages. The registrationId identifies the correct {device, user, page}
> to
> > which the message will be sent.
>
> I think that the spec needs to be a lot clearer on the purpose (and
> usage) of each of these things.  Personally, I think that a better
> model would be this:
>
> interface PushManager {
>   Promise register();
>   Promise> registrations();
> };
>
> interface PushRegistration {
>   Promise unregister();
>   attribute DOMString id;
>   attribute DOMString endpoint;
> };
>
> interface PushMessage {
>   attribute PushRegistration registration;
>   attribute ?? data;
> }
>
> Yes, aside from moving unregister, it's just names, but sometimes
> names are important.  The reason behind moving unregister being that
> 'id' is only present for bookkeeping purposes, and many apps won't
> have to use it.
>
> That said, looking at this, I am sorely tempted to suggest adding
> EventTarget to PushRegistration and use events.  Any reason that
> wouldn't be appropriate?
>
> p.s., I assume that the mess in the editor's draft regarding
> PushManager is due to a Respec.js issue around the use of promises.
>

Re: [push-api] Identifying registrations

[Martin Thomson]

On 13 May 2014 06:39, Michael van Ouwerkerk  wrote:
> Martin, in Chrome we use registrationId and endpoint for distinct purposes.
> The endpoint is the push server url to which the app server posts new
> messages. The registrationId identifies the correct {device, user, page} to
> which the message will be sent.

I think that the spec needs to be a lot clearer on the purpose (and
usage) of each of these things.  Personally, I think that a better
model would be this:

interface PushManager {
  Promise register();
  Promise> registrations();
};

interface PushRegistration {
  Promise unregister();
  attribute DOMString id;
  attribute DOMString endpoint;
};

interface PushMessage {
  attribute PushRegistration registration;
  attribute ?? data;
}

Yes, aside from moving unregister, it's just names, but sometimes
names are important.  The reason behind moving unregister being that
'id' is only present for bookkeeping purposes, and many apps won't
have to use it.

That said, looking at this, I am sorely tempted to suggest adding
EventTarget to PushRegistration and use events.  Any reason that
wouldn't be appropriate?

p.s., I assume that the mess in the editor's draft regarding
PushManager is due to a Respec.js issue around the use of promises.

Re: Blob URL Origin

[Jonas Sicking]

On Tue, May 13, 2014 at 6:00 AM, Anne van Kesteren  wrote:
> On Tue, May 13, 2014 at 10:33 AM, Boris Zbarsky  wrote:
>> It can't work, given how URL.origin is currently defined...  It's possible
>> that definition should change, though.
>
> We don't want new URL() to take ownership of the Blob object, so
> making new URL() reflect the origin of whoever created the uuid for
> the Blob object seems weird.

Why would it need to "take ownership of the Blob object"? First of
all, the origin of the blob: url is determined by who called
createObjectURL, not who owns the Blob instance. Hence you don't
actually need to touch the Blob instance to figure out the origin, but
rather just inspect the url itself (if we use explicit origin syntax),
or look up the origin in the internal url->Blob table (if we use
implicit origin syntax).

And even if you did somehow need to touch the Blob, the implementation
could just immediately release it before returning from the
constructor.

/ Jonas

Re: Custom Elements: 'data-' attributes

[Ryosuke Niwa]

> On May 13, 2014, at 2:37 AM, Anne van Kesteren  wrote:
> 
>> On Mon, May 12, 2014 at 9:39 PM, Ryosuke Niwa  wrote:
>> But expandos are usually added to HTMLElement and other builtin elements, 
>> right?
> 
> Depends, might be on instances too.

Sure, authors can do anything they please to do but a typical workflow is to 
define a property on element's prototype.

>> What we're talking about here is adding properties and methods on a custom 
>> element, which is a subclass of HTMLElement so I don't think it'll cause the 
>> same issue.
> 
> If a site has if (ele.prop) you'd have that issue since that suddenly
> starts returning true for e.g. the  element or some such.
> Similar reason is why getElementById() is not available on elements.

Right. I think we need to discourage authors from using such an idiom on 
inprefixed author defined properties.

If authors are writing terrible code, there is so much we can do to mitigate 
that.

> Sole had the idea of providing hooks for attributes so a component can
> say it handles them rather than the user agent. That makes a lot of
> sense to me. That way you can grab any name, even existing ones.

Sounds like a sensible idea.

- R. Niwa

Re: [push-api] Object values in push messages

[Martin Thomson]

On 13 May 2014 02:47, Anne van Kesteren  wrote:
> Can't we mirror WebSocket? That seems like it would be quite a bit
> simpler than full-blown HTTP messages.

Almost, though we'd need that single bit of metadata that
thewebsocketprotocol uses to signal text/binary.  I think that XHR is
a better fit, assuming that MIME makes sense architecturally.

Re: [push-api] Object values in push messages

[Martin Thomson]

On 13 May 2014 08:13, Peter Beverloo  wrote:
> There is a current, not yet implemented proposal to change the type of
> |data| to DOMString. This also allows for cases in which the UA cannot read
> the message's content, which could be the case when encryption is being
> used. JSON data would still be perfectly possible, but it has to be
> deserialized before usage.

That's where I'm going.  But I don't think that's far enough.

> It was discussed to use ArrayBuffers for this purpose, but that makes it
> significantly harder to deal with data in the common case.

This is why I proposed MIME.  ArrayBuffer is pretty unwieldy in the
common case, but a MIME type would allow browsers to identify when an
ArrayBuffer is necessary.  All the other times, a string can be
populated (or application/json parsed if you want to get fancy).

Re: [push] protocol drafts

[Doug Turner]

The websocket version documents what we did for Mozilla and TEF's push
system.  I also support Martin's draft as a base.

On Tue, May 13, 2014 at 8:44 AM, Peter Beverloo  wrote:
> While I haven't finished reviewing it yet, the removal of the dependency on
> Web Sockets is something we're strongly in favor of. Choosing which protocol
> the IETF group is going to pursue is a decision to be made there, at least
> until the Web Push API gains a formal dependency on it.
>
> For the record, I support taking Martin's draft as a base.
>
> Thanks,
> Peter
>
>
> On Tue, May 13, 2014 at 5:37 PM, Doug Turner  wrote:
>>
>> My draft is basically what we do today.  Martin's draft leverages
>> http2 and is much cleaner/simpler.  I am not sure which we are putting
>> our money on yet, but I suspect it will be Martin's.
>>
>> On Tue, May 13, 2014 at 4:41 AM, Arthur Barstow 
>> wrote:
>> > Hi Martin, Doug,
>> >
>> > I noticed there are two drafts related to push protocol:
>> >
>> > 
>> > 
>> >
>> > What are the plans and expectations for these specs (f.ex. do they
>> > address
>> > different use case and thus are independent; are they to be merged; is
>> > one
>> > to replaced/usurped by the other; survival of the fittest;
>> > standardization
>> > plans; ...)?
>> >
>> > -Thanks, ArtB
>> >
>> >
>>
>

Re: Custom Elements: 'data-' attributes

[Boris Zbarsky]

On 5/13/14, 7:31 AM, Dimitri Glazkov wrote:

Sole had the idea of providing hooks for attributes so a component can
say it handles them rather than the user agent. That makes a lot of
sense to me. That way you can grab any name, even existing ones.


<3 this idea, would love to hear more. It's like dinner reservations
for attributes!


I slightly worry about the performance implications of this and the 
number of changes to UAs this will require: any place inside a UA that 
examines attribute values (only for global attributes?) would need to 
consult this reservation information, right?


-Boris

Re: [push] protocol drafts

[Peter Beverloo]

While I haven't finished reviewing it yet, the removal of the dependency on
Web Sockets is something we're strongly in favor of. Choosing which
protocol the IETF group is going to pursue is a decision to be made there,
at least until the Web Push API gains a formal dependency on it.

For the record, I support taking Martin's draft as a base.

Thanks,
Peter


On Tue, May 13, 2014 at 5:37 PM, Doug Turner  wrote:

> My draft is basically what we do today.  Martin's draft leverages
> http2 and is much cleaner/simpler.  I am not sure which we are putting
> our money on yet, but I suspect it will be Martin's.
>
> On Tue, May 13, 2014 at 4:41 AM, Arthur Barstow 
> wrote:
> > Hi Martin, Doug,
> >
> > I noticed there are two drafts related to push protocol:
> >
> > 
> > 
> >
> > What are the plans and expectations for these specs (f.ex. do they
> address
> > different use case and thus are independent; are they to be merged; is
> one
> > to replaced/usurped by the other; survival of the fittest;
> standardization
> > plans; ...)?
> >
> > -Thanks, ArtB
> >
> >
>
>

Re: [push] protocol drafts

[Doug Turner]

My draft is basically what we do today.  Martin's draft leverages
http2 and is much cleaner/simpler.  I am not sure which we are putting
our money on yet, but I suspect it will be Martin's.

On Tue, May 13, 2014 at 4:41 AM, Arthur Barstow  wrote:
> Hi Martin, Doug,
>
> I noticed there are two drafts related to push protocol:
>
> 
> 
>
> What are the plans and expectations for these specs (f.ex. do they address
> different use case and thus are independent; are they to be merged; is one
> to replaced/usurped by the other; survival of the fittest; standardization
> plans; ...)?
>
> -Thanks, ArtB
>
>

Re: [push-api] Object values in push messages

[Peter Beverloo]

There is a current, not yet implemented proposal to change the type of
|data| to DOMString. This also allows for cases in which the UA cannot read
the message's content, which could be the case when encryption is being
used. JSON data would still be perfectly possible, but it has to be
deserialized before usage.

It was discussed to use ArrayBuffers for this purpose, but that makes it
significantly harder to deal with data in the common case.

Thanks,
Peter


On Tue, May 13, 2014 at 11:47 AM, Anne van Kesteren wrote:

> On Tue, May 13, 2014 at 12:56 AM, Martin Thomson
>  wrote:
> > I think that this offers applications more flexibility.  For instance,
> > there are limitations on what can be pushed efficiently, and an
> > application that aims to maximize the value of a push might want to
> > push a binary blob.
>
> Can't we mirror WebSocket? That seems like it would be quite a bit
> simpler than full-blown HTTP messages.
>
>
> --
> http://annevankesteren.nl/
>
>

Re: Custom Elements: 'data-' attributes

[Dimitri Glazkov]

On Tue, May 13, 2014 at 2:37 AM, Anne van Kesteren  wrote:

> Sole had the idea of providing hooks for attributes so a component can
> say it handles them rather than the user agent. That makes a lot of
> sense to me. That way you can grab any name, even existing ones.

<3 this idea, would love to hear more. It's like dinner reservations
for attributes!

:DG<

[Bug 25290] [Custom]: Ban uppercase and leading "xml" in custom element names?

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25290

Dimitri Glazkov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Dimitri Glazkov  ---
(In reply to Simon Pieters from comment #22)
> https://github.com/w3c/webcomponents/pull/15

Awesome! Thanks! :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [push-api] Identifying registrations

[Michael van Ouwerkerk]

Martin, in Chrome we use registrationId and endpoint for distinct purposes.
The endpoint is the push server url to which the app server posts new
messages. The registrationId identifies the correct {device, user, page} to
which the message will be sent.

Please see this diagram for the full picture:
https://www.lucidchart.com/documents/view/5c9b43c3-cd0a-44f2-95aa-27a22dad2d95/0

For more context, here's the general design document for our implementation
in Chrome:
https://docs.google.com/a/chromium.org/document/d/1-YTIsnKfLfqELO54vo-lz3WaW2R8LARBpH0AZKkze4M/edit

I realize these are very Chrome specific, and implementations may differ,
but some concrete examples might help this discussion.

Regards,

Michael






On Tue, May 13, 2014 at 10:10 AM, Tab Atkins Jr. wrote:

> On Tue, May 13, 2014 at 1:08 AM, Martin Thomson
>  wrote:
> > The push API currently identifies a registration with a tuple:
> >
> > interface PushRegistration {
> > readonlyattribute DOMString pushEndpoint;
> > readonlyattribute DOMString pushRegistrationId;
> > };
> >
> > It looks like both are used by the push server.  Local methods seem to
> > rely on the pushRegistrationId; the remote application server uses the
> > pushEndpoint, though details are not currently specified [1].
> >
> > In my experience, the pushEndpoint is a sufficiently unique
> > identifier.  Contingent on some conclusions on the protocol side, this
> > could be defined as a URL and used as an identifier.  That single
> > identifier should suffice.
>
> Using URLs as identifiers is an anti-pattern which we should have
> learned by now.  In practice, multiple distinct URLs map to the same
> resource, and people understand this intuitively.  The fact that those
> multiple distinct URLs are multiple distinct identifiers is
> unintuitive and hard to use correctly, as XML Namespaces has taught us
> well over the years.
>
> (For example, the presence/absence of a slash at the end of a URL is
> almost never relevant in real life, but you have to memorize which
> pattern is used by a particular URL-as-identifier, and there's no
> real-life consensus about which to use.  Same with ordering of query
> params, http vs https, capitalization of domain name, etc.  The hash
> is relevant as an identifier, but not as a URL.  It's all terrible.)
>
> ~TJ
>
>

Re: Blob URL Origin

[Anne van Kesteren]

On Tue, May 13, 2014 at 10:33 AM, Boris Zbarsky  wrote:
> It can't work, given how URL.origin is currently defined...  It's possible
> that definition should change, though.

We don't want new URL() to take ownership of the Blob object, so
making new URL() reflect the origin of whoever created the uuid for
the Blob object seems weird.


-- 
http://annevankesteren.nl/

Re: Blob URL Origin

[Anne van Kesteren]

On Mon, May 12, 2014 at 6:51 PM, Jonas Sicking  wrote:
> I agree with this. But Adam's assessment of how long that will take to get
> specced and implemented was in the order of year, not month. I share that
> assessment.
>
> I am also not at all convinced that I'd want blob: to behave like data: even
> if I could. The solution for data: is likely to get messy.

This keeps coming up. Is there a page where we have a description?


> The origin model for http has so far worked better for us I think.

I'm not sure how you can straightforwardly compare that to locally
created resources.


-- 
http://annevankesteren.nl/

[push] protocol drafts

[Arthur Barstow]

Hi Martin, Doug,

I noticed there are two drafts related to push protocol:




What are the plans and expectations for these specs (f.ex. do they 
address different use case and thus are independent; are they to be 
merged; is one to replaced/usurped by the other; survival of the 
fittest; standardization plans; ...)?


-Thanks, ArtB

Re: Custom Elements: 'data-' attributes

[Charles McCathie Nevile]

On Thu, 08 May 2014 19:42:04 +0200, Ian Hickson  wrote:


On Thu, 8 May 2014, Bruce Lawson wrote:

On 7 May 2014 20:03, Ian Hickson  wrote:
>
> Requiring a dash is pretty ugly. I would allow any attribute, and
> we'll just have to be careful when introducing new global ones.

I think the ship HMS Ugly has already sailed, given a dash is compulsory
for the names of custom elements. Also, requiring a dash in the names of
custom attributes would establish an easily-memorable convention for
authors, and safeguard new global attributes.


I disagree.


I think the HMS ugly really has been launched - and successfully sailed  
for years. I agree with Bruce that dashes in attributes are easy for  
everyone to remember. The question is really how important that is.



With element names, you really should be putting a uniquish
prefix on your element names to avoid clashes with other custom vocabs.  
So the dash is just the way we encourage that.


Right.


   
   

...etc.

But the attributes are _already_ scoped, since they're on the element.

   

...vs

   

The "data-" bits don't add anything useful.


if they were andr- they might remind authors that this is a width  
specifically scoped to the element (and measured in unicorns, or somehow  
different from the "normal" width). For more obviously custom attributes  
like


http://example.org/yvfol";>

I suspect this is actually helpful for authors in "getting it right".

But if we simply require everything to be data-* I agree that we're not  
likely to help anyone much.


So if we are going to do something, IMHO it should look more like "your  
attributes must have a dash in their name…"


Anne's point about the DOM interface also being an issue is very  
important also.


Yes.


Unless we're also going to be forcing everyone to prefix their
APIs, which would also be really ugly, the namespace wouldn't be
protected anyway.


True…

This a price of ditching XML and namespaces (which was done because there  
were benefits too). Those things are seperable, and there is no law that  
we can never re-invent namespaces for an HTML world if it turns out that  
the functionality really was needed.


Hence my initial question - can we get a really important benefit for some  
(more) ugliness in the Web platform, do we need to find another solution,  
or is the problem so small we don't need to worry? I'm dubious about the  
last suggestion, but whether one or the other of the first two is more  
likely to be correct isn't immediately apparent to me.


cheers

chaals

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

Re: [push-api] Object values in push messages

[Anne van Kesteren]

On Tue, May 13, 2014 at 12:56 AM, Martin Thomson
 wrote:
> I think that this offers applications more flexibility.  For instance,
> there are limitations on what can be pushed efficiently, and an
> application that aims to maximize the value of a push might want to
> push a binary blob.

Can't we mirror WebSocket? That seems like it would be quite a bit
simpler than full-blown HTTP messages.


-- 
http://annevankesteren.nl/

Re: Custom Elements: 'data-' attributes

[Anne van Kesteren]

On Mon, May 12, 2014 at 9:39 PM, Ryosuke Niwa  wrote:
> But expandos are usually added to HTMLElement and other builtin elements, 
> right?

Depends, might be on instances too.


> What we're talking about here is adding properties and methods on a custom 
> element, which is a subclass of HTMLElement so I don't think it'll cause the 
> same issue.

If a site has if (ele.prop) you'd have that issue since that suddenly
starts returning true for e.g. the  element or some such.
Similar reason is why getElementById() is not available an elements.


Sole had the idea of providing hooks for attributes so a component can
say it handles them rather than the user agent. That makes a lot of
sense to me. That way you can grab any name, even existing ones.


-- 
http://annevankesteren.nl/

[Bug 23346] Use TypeError for argument validation

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23346

Anne  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #11 from Anne  ---
I don't see what needs to be fixed on the WHATWG side here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [push-api] Identifying registrations

[Tab Atkins Jr.]

On Tue, May 13, 2014 at 1:08 AM, Martin Thomson
 wrote:
> The push API currently identifies a registration with a tuple:
>
> interface PushRegistration {
> readonlyattribute DOMString pushEndpoint;
> readonlyattribute DOMString pushRegistrationId;
> };
>
> It looks like both are used by the push server.  Local methods seem to
> rely on the pushRegistrationId; the remote application server uses the
> pushEndpoint, though details are not currently specified [1].
>
> In my experience, the pushEndpoint is a sufficiently unique
> identifier.  Contingent on some conclusions on the protocol side, this
> could be defined as a URL and used as an identifier.  That single
> identifier should suffice.

Using URLs as identifiers is an anti-pattern which we should have
learned by now.  In practice, multiple distinct URLs map to the same
resource, and people understand this intuitively.  The fact that those
multiple distinct URLs are multiple distinct identifiers is
unintuitive and hard to use correctly, as XML Namespaces has taught us
well over the years.

(For example, the presence/absence of a slash at the end of a URL is
almost never relevant in real life, but you have to memorize which
pattern is used by a particular URL-as-identifier, and there's no
real-life consensus about which to use.  Same with ordering of query
params, http vs https, capitalization of domain name, etc.  The hash
is relevant as an identifier, but not as a URL.  It's all terrible.)

~TJ

Re: Blob URL Origin

[Boris Zbarsky]

On 5/13/14, 1:20 AM, Frederik Braun wrote:

On 12.05.2014 18:41, Jonas Sicking wrote:

(new URL(url)).origin should work, no?


It does not work for blob URIs in Firefox.


It can't work, given how URL.origin is currently defined...  It's 
possible that definition should change, though.


-Boris

Re: Blob URL Origin

[Frederik Braun]

On 12.05.2014 18:41, Jonas Sicking wrote:
> (new URL(url)).origin should work, no?

It does not work for blob URIs in Firefox.

[Bug 23346] Use TypeError for argument validation

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23346

Simon Pieters  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||sim...@opera.com
 Resolution|WONTFIX |---

--- Comment #10 from Simon Pieters  ---
Please make the specs match each other.

See https://github.com/w3c/web-platform-tests/pull/974

-- 
You are receiving this mail because:
You are on the CC list for the bug.