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...
Re: Custom Elements: 'data-' attributes
On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa rn...@apple.com 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: Custom Elements: 'data-' attributes
On Mon, 12 May 2014 11:00:20 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa rn...@apple.com 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: button onclick=action() made us have to rename button action to button formaction (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 Mon, May 12, 2014 at 11:24 AM, Simon Pieters sim...@opera.com 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: 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 Mon, May 12, 2014 at 4:31 PM, Boris Zbarsky bzbar...@mit.edu 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 iframe 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, 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 May 12, 2014, at 10:31 AM, Boris Zbarsky bzbar...@mit.edu 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: data:, was: Blob URL Origin
On May 12, 2014, at 6:26 AM, Julian Reschke julian.resc...@gmx.de 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: 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: Blob URL Origin
On May 12, 2014 7:33 AM, Boris Zbarsky bzbar...@mit.edu 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: Blob URL Origin
On May 12, 2014 8:57 AM, Arun Ranganathan a...@mozilla.com wrote: On May 12, 2014, at 10:31 AM, Boris Zbarsky bzbar...@mit.edu 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: Custom Elements: 'data-' attributes
On May 12, 2014, at 2:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa rn...@apple.com 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
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 dglaz...@google.com 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: Blob URL Origin
On Mon, May 12, 2014 at 11:41 AM, Jonas Sicking jo...@sicking.cc 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
[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
[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 dglaz...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dimitri Glazkov dglaz...@chromium.org --- https://github.com/w3c/webcomponents/commit/61093a7d9562a6ea5a1926529406cf1bc3255778 -- You are receiving this mail because: You are on the CC list for the bug.
[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.
[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] 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
PromisePushRegistration or PromiseDOMString as appropriate.
[1] see webp...@ietf.org and related effort there
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
martin.thom...@gmail.com 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
PromisePushRegistration or PromiseDOMString as appropriate.
[1] see webp...@ietf.org and related effort there
