[Bug 25343] Expose an isClosed property on Blob Objects
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25343 Simon Pieters changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Simon Pieters --- I'm not aware of any particular impl costs with exposing it. I think this feature has been given enough consideration at this point, and on balance I agree it's OK to have it in. So let's close this as FIXED. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [push-api] Identifying registrations
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 at 4:08 PM, 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.
>
> --Martin
>
> p.s., the register() method on PushManager should be updated to return
> Promise or Promise as appropriate.
>
> [1] see webp...@ietf.org and related effort there
[push-api] Identifying registrations
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.
--Martin
p.s., the register() method on PushManager should be updated to return
Promise or Promise as appropriate.
[1] see webp...@ietf.org and related effort there
[push-api] Object values in push messages
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 XmlHTTPRequest API (or whatever folks who are working on that might wish XHR looked like) so that pushed messages can contain MIME bodies. 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.
[push-api] Version information in push API
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 by the API. I think that removing version would simplify server implementation. Doug T also mentioned that there was an event that is fired when messages might have been missed, presumably relying on the version number to detect gaps. I don't see this in the editor's draft, so maybe this was only something in the mozilla implementation. The drawback of making this simplification is that applications will have to detect gaps or duplicates themselves. If we consider the standard comsec adversary model, in which the push server is not trusted, this is something that application should be doing for itself anyway.
[Bug 25142] [Custom]: Missing created callback should not prevent other callbacks from being enqueued.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25142 Dimitri Glazkov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dimitri Glazkov --- https://github.com/w3c/webcomponents/commit/61093a7d9562a6ea5a1926529406cf1bc3255778 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25669] New: [Custom]: Make ES6 prose normative when ES6 ships
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 Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: dglaz...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 Once ES6 is released, we need to turn the informative section at: http://w3c.github.io/webcomponents/spec/custom/#es6 into normative prose. -- You are receiving this mail because: You are on the CC list for the bug.
[webcomponents]: Informal Shadow DOM Survey
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: https://www.surveymonkey.com/results/SM-SQX77WF/ :DG<
Re: Blob URL Origin
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 URL(url)).origin should work, no? > I don't think there have been any real differences to argue between the "implicitly" or "explicitly" approaches, but this does argue for "explicit". Otherwise, new URL(blobURL) would have to synchronously read the associated Blob's metadata (which might be on disk or in another process), and the result of new URL() would change when a blob URL is revoked. -- Glenn Maynard
Re: [webcomponents]: Regular Conference Call Survey
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 amazing coincidence, 2 of them proposed exactly the same meeting time -- Tuesday 9am PDT. I know this doesn't work well for folks with UTC>+4, but I am tempted to start there and tweak as we go for next (if any) instances. So, let's try for next Tuesday, May 20. I'll announce it again (hopefully with more details) next Monday morning. :DG< On Thu, May 1, 2014 at 11:44 AM, Dimitri Glazkov wrote: > Greetings, WebApp-ateurs! > > At the last F2F, there was some positive sentiment toward setting up a > regular conference call to discuss Web Components-related topics. > > On Art's advice, I thereby present this lovely survey that seeks to > find a good time slot for such a conference call: > > https://docs.google.com/forms/d/1jpHhCPE_avjtRZbll7ezmZ_4yHwrBv9qijOGEQCX0RY/viewform?usp=send_form > > If you're interested in participating, please fill out this form by > Friday, May 16, 2014. > > Thanks! > > :DG<
Re: Custom Elements: 'data-' attributes
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 up in the prototype chain. It's true that this >> custom element's contentEditable would have completely different semantics >> from that on other elements but that wouldn't break websites that use this >> custom element as long as authors are only accessing contentEditable >> property on instances of the custom element for semantics C. > > I forgot the exact details, but we had some amount of trouble when we > introduced min and max attributes due to sites using expandos with the > same names. But expandos are usually added to HTMLElement and other builtin elements, right? 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. - R. Niwa
[Bug 25655] Proposal for UIEvent "role" property
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25655 Travis Leithead [MSFT] changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events Assignee|tra...@microsoft.com|gary...@google.com --- Comment #3 from Travis Leithead [MSFT] --- (In reply to caitp from comment #2) > I've been looking over the IndieUI proposals, and I think it covers some of > this, but not all of it, and not necessarily very well. > > Adding new event types seems like a non-solution which complicates things > further. Instead, annotating existing events with a role for their > particular UI interaction, and providing a way to listen to events filtered > based on the annotated interaction, seems much simpler, and easier to > polyfill. > > But I suppose discussions about that would be better suited for the IndieUI > WG. > > But it's good that there's at least an interest in working with high-level > interactions rather than low-level inputs, so that's great. Thanks! There may be something we can add in to some events to improve the situation. Note: moving to UI Events path which is where future work and feature requests are being collected at the moment. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Blob URL Origin
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. 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. > > > We actually aren't obliging web pages parse these strings to get the origin. In fact, blob: URL strings shouldn't even be of interest to web pages. They aren't today, and I don't envision them being of interest even with "origin tagging." That is, I can't think of why exactly a web developer would want to look into the blob: URL strings. UA's should just "do the right thing" once a Blob URL is coined. I suspect that some pages will want to check the origin of a url before firing off a load to it. For example complex app frameworks like facebook's. However I agree that this wont be a core use case. So not something to worry too much about. The strongest reason I could see for doing anything here is that when it comes to security it is extra important to en courage people to not do the wrong thing. Though, would simply `URL(url).origin` work? If so that might be enough. / Jonas
Re: Blob URL 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 want a consistent story. 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. The origin model for http has so far worked better for us I think. / Jonas
Re: Blob URL Origin
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 returns its origin seems like it should be pretty easy for UAs to implement, though. (new URL(url)).origin should work, no? But creating an even eased way to get the origin of a url might be good. Though I don't think this is a specific problem to blob: URLs, so I wouldn't create a solution that is specific to them. Maybe a static URL.getOrigin(url). / Jonas
Re: contentEditable=minimal
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 conceivable that given enough time and energy the current contentEditable behaviour could be made interoperable, but the problem is that even if that happened it seems clear from developers' feedback that it wouldn't do what they want. A lot of the time you would still want to disable a lot of what it does by default and handle it yourself. This is therefore just intended as a way of providing developers with primitives for editing. Intercepting key strokes is already now possible and probably the best one can do. The one thing where this gets complicated is when typing characters using more than one key stroke. such as ~ + n to make ñ. I am not sure if you include that under the "Some keyboard input handling". Yes, text input is a hard problem and you can't get away without solving it. We are talking about providing primitives here, so things can be expected to be a little bit hairy though. DOM 3 Events has something called composition events for the example you bring up (which can get a whole lot more complicated, notably with things like Kotoeri and such). On the face of it it would seem to be the needed part but I've never used them (or seen them used) in the real world. (The quality of browser support is also unclear at this point.) Some cases also require the IME API. Developers relying on the bare bones cE would probably have to handle the rendering of ongoing composition themselves (which isn't the end of the world, but you need to think about it or you are guaranteed to mess things up). This is probably acceptable at this level, libraries can make it easier. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: data:, was: Blob URL Origin
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, implementations don’t behave this way; the problem is inheriting origins. Here’s the pertinent thread: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0682.html
Re: Blob URL Origin
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 returns its > origin seems like it should be pretty easy for UAs to implement, though. We actually aren’t obliging web pages parse these strings to get the origin. In fact, blob: URL strings shouldn’t even be of interest to web pages. They aren’t today, and I don’t envision them being of interest even with “origin tagging.” That is, I can’t think of why exactly a web developer would want to look into the blob: URL strings. UA’s should just “do the right thing” once a Blob URL is coined. The question is really whether origin should be implicit or explicit. Fx’s implementation makes it implicit. so that there’s no way to deduce origins from the Blob URL itself, but it just “does the right thing” in terms of origin strictures. That hasn’t been a problem, but it’s hard to spec. it that way. Also, it makes Blob URLs only usable within APIs that are aware of them, which honestly is the case today. So what if we tag origin into the strings? Would that be so bad? It’s not doing anything other than denoting the incumbent script setting object’s origin, no? Even in the Chrome/Safari cases, I can’t think of web developers using that information. — A*
Re: Blob URL Origin
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 some such, not a static on Blob, if we want a way to expose the origin to script. -Boris
Re: Blob URL Origin
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 returns > its origin seems like it should be pretty easy for UAs to implement, though. 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). And then for etc. only allow loading "same-origin" blob: URLs. It seems this could also be achieved via other means, such as scoping the minted uuids to a particular origin. And I guess it protects against someone handing you a URL and you assuming loading that is safe. Again, seems like that could be achieved by scoped uuids if we think it's desirable. -- http://annevankesteren.nl/
Re: Blob URL Origin
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 UAs to implement, though. -Boris
Re: Blob URL Origin
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 origin into the URL seems fine. Per the URL Standard scheme data consists of http://url.spec.whatwg.org/#url-code-points which include both : and // so blob:https://origin:42/uuid would be fine. The URL Standard does not define how to parse scheme data though so you'd have to define that if you want implementations to be able to extract data from it. 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. -- http://annevankesteren.nl/
data:, was: Blob URL Origin
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, and I'd prefer to change Gecko to be closer to what other browser do, than the other way around, see my proposal about explicit opt-in). ... Could you please clarify what spec you are referring to, and in which way it's not implemented correctly? Best regards, Julian
Re: Custom Elements: 'data-' attributes
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 future due to @@unscopables. -- http://annevankesteren.nl/
Re: Custom Elements: 'data-' attributes
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 up in the prototype chain. It's true that this custom element's contentEditable would have completely different semantics from that on other elements but that wouldn't break websites that use this custom element as long as authors are only accessing contentEditable property on instances of the custom element for semantics C. I forgot the exact details, but we had some amount of trouble when we introduced min and max attributes due to sites using expandos with the same names. I think we need something better than encouraging certain conventions if we want this to work. Bare names in event handler content attributes are troublesome. For instance, sites doing: made us have to rename to (the new .action reflecting action="" was closer in the scope chain than the intended function). Global attributes have the same issue. 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. -- Simon Pieters Opera Software
Re: Custom Elements: 'data-' attributes
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 > element's contentEditable would have completely different semantics from that > on other elements but that wouldn't break websites that use this custom > element as long as authors are only accessing contentEditable property on > instances of the custom element for semantics C. I forgot the exact details, but we had some amount of trouble when we introduced min and max attributes due to sites using expandos with the same names. I think we need something better than encouraging certain conventions if we want this to work. -- http://annevankesteren.nl/
Re: Blob URL Origin
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 having a good way to denote origin > within the URL that signifies the origin of the incumbent settings > object is problematic for Fetch and Parse specifications that need > origin information. Wouldn't it be nice if there was a programmatic way to probe if a blob URI belongs to a specified origin or not? If they had an origin attribute one could compare them to location.origin or so. But well, they are DOMStrings and not objects...
