https://www.w3.org/Bugs/Public/show_bug.cgi?id=25343
Simon Pieters changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
The thinking behind this would be that people might use the
pushEndpoint as the 'type' of push notification service you are
talking to (gcm, mozilla, samsung, apple, etc) and the
pushRegistrationID as the identifier. Doing it this way avoids having
to parse URLs... sorta.
On Mon, May 12, 2014
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 pushRegistrat
The current editors draft of the push API includes an `Object` in the
PushMessage class.
This assumes a great deal about the nature of the contents of pushed
messages. I think that arbitrary data is more appropriate for this
channel. To that end, I propose that the API be made congruent with
the
The push-api currently stipulates a method whereby applications can
learn of missed messages. This uses a number that increases with
every push message (version).
This places some constraints on the push server implementation that
are largely unnecessary when generic data transport is supported b
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25142
Dimitri Glazkov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25669
Bug ID: 25669
Summary: [Custom]: Make ES6 prose normative when ES6 ships
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severi
Howdy, Web-Appa-rishi,
Last week, I was looking at the Shadow DOM bugs and, sort of
impulsively, put together a quick "top 10" survey that I then promptly
twittered here:
https://twitter.com/dglazkov/status/462319811326791680
I thought it might be interesting for y'alls to see the results so far
On Mon, May 12, 2014 at 11:41 AM, Jonas Sicking wrote:
>
> I'd really rather we didn't make web pages parse these strings to get the
> origin. A static method on Blob that takes a valid blob: URI and returns
> its origin seems like it should be pretty easy for UAs to implement, though.
>
> (new U
I am sure you were all at the edge of your seats, in anticipation of
the results of this survey being announced. I have good news: data was
collected!
There were just 4 responses recorded. Not sure if this in itself is a
vote against of a regular call. There's one way to find out for sure
:)
In a
On May 12, 2014, at 2:00 AM, Anne van Kesteren wrote:
> On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa wrote:
>> On the other hand, if the same element had exposed contentEditable property,
>> then UA's native contentEditable property would simply be overridden since
>> it would appear higher
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25655
Travis Leithead [MSFT] changed:
What|Removed |Added
CC||public-webapps@w3.org
On May 12, 2014 8:57 AM, "Arun Ranganathan" wrote:
> On May 12, 2014, at 10:31 AM, Boris Zbarsky wrote:
>
> > On 5/12/14, 5:28 AM, Anne van Kesteren wrote:
> >> so blob:https://origin:42/uuid would be fine.
> >
> > I'd really rather we didn't make web pages parse these strings to get
the origin.
On May 12, 2014 5:29 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
On May 12, 2014 7:33 AM, "Boris Zbarsky" wrote:
>
> On 5/12/14, 5:28 AM, Anne van Kesteren wrote:
>>
>> so blob:https://origin:42/uuid would be fine.
>
>
> I'd really rather we didn't make web pages parse these strings to get the
origin. A static method on Blob that takes a valid blob: URI and re
On 12/05/2014 00:46 , Johannes Wilm wrote:
Also this looks good. There seems to be consensus that contenteditable
is just not going o get fixed, and so removing the faulty behavior
entirely and replacing it with this would be almost as good.
It depends on what you mean by "fixed". It is conceiv
On May 12, 2014, at 6:26 AM, Julian Reschke wrote:
> Could you please clarify what spec you are referring to, and in which way
> it's not implemented correctly?
Well, I think http://tools.ietf.org/html/rfc6454#section-4 is is supposed to be
normative for data: URL origin. But, implementation
On May 12, 2014, at 10:31 AM, Boris Zbarsky wrote:
> On 5/12/14, 5:28 AM, Anne van Kesteren wrote:
>> so blob:https://origin:42/uuid would be fine.
>
> I'd really rather we didn't make web pages parse these strings to get the
> origin. A static method on Blob that takes a valid blob: URI and
On 5/12/14, 7:46 AM, Anne van Kesteren wrote:
I thought the idea was to associate the origin of
URL.createObjectURL() with the Blob object (which might be different
from the Blob object's origin).
Er, right, these URLs come from URL.createObjectURL. So we'd want a
URL.getObjectURLOrigin() or
On Mon, May 12, 2014 at 4:31 PM, Boris Zbarsky wrote:
> On 5/12/14, 5:28 AM, Anne van Kesteren wrote:
>> so blob:https://origin:42/uuid would be fine.
>
> I'd really rather we didn't make web pages parse these strings to get the
> origin. A static method on Blob that takes a valid blob: URI and r
On 5/12/14, 5:28 AM, Anne van Kesteren wrote:
so blob:https://origin:42/uuid would be fine.
I'd really rather we didn't make web pages parse these strings to get
the origin. A static method on Blob that takes a valid blob: URI and
returns its origin seems like it should be pretty easy for UA
On Sun, May 11, 2014 at 9:30 PM, Arun Ranganathan wrote:
> Useful input from implementers will be about URL-nesting and security
> implications, including the pros and cons of URL-encoding components of
> origin strings.
Well, we don't want "URL nesting" (e.g. what jar: does). Embedding the
origi
On 2014-05-10 01:22, Jonas Sicking wrote:
...
A strong reason not to go with the data: design is that data: is still
not implemented consistently across browsers. It's fairly clear that
the current spec for data: isn't going to be implemented as-is (I
think gecko is has the closest implementation
On Mon, May 12, 2014 at 11:24 AM, Simon Pieters wrote:
> So when we research if it's safe to add a new global attribute, it's not
> enough to measure how often such an attribute is used in the wild. We need
> to research bare names in event handlers also.
This we can thankfully mitigate in the fu
On Mon, 12 May 2014 11:00:20 +0200, Anne van Kesteren
wrote:
On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa wrote:
On the other hand, if the same element had exposed contentEditable
property, then UA's native contentEditable property would simply be
overridden since it would appear higher
On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa wrote:
> On the other hand, if the same element had exposed contentEditable property,
> then UA's native contentEditable property would simply be overridden since it
> would appear higher up in the prototype chain. It's true that this custom
> elem
On 09.05.2014 23:29, Arun Ranganathan wrote:
> ..
> So this is problematic: we don’t have a common syntax on the web, and
> even implementations which share code don’t do it exactly the same. Of
> course, blob: URLs aren’t supposed to be human readable, or really
> viewed by the developer. But not
27 matches
Mail list logo
