Re: [HTML Imports] What is the imagined work flow?
Some of the ways Polymer team uses imports are as follows:
- aggregating script src and/or link rel=stylesheet elements into
functional units
- aggregating imports themselves into units
- expressing dependencies (N modules can each import jquery2-import.html
and I only get one copy of jquery)
- importing self-organizing databases via custom elements (e.g. core-meta
elements describe/provide metadata using monostate pattern)
Also, one of the first things Polymer does is register a custom-element
which itself provides a declarative interface to the custom element
machinery. Most other Polymer elements are then structured declaratively
(as HTML) which makes using imports highly convenient.
would stick a style element in the imported document
You can do that, reference an external stylesheet, or place a (scoped)
style tag directly in the shadow-root.
E.g. using Polymer idiom
polymer-element name=my-button noscript
template
style
:host div.someclass {
color: aliceblue;
}
/style
div class=someclassmy-button/div
/template
/polymer-element
On Tue, May 20, 2014 at 10:08 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Over here at mozilla we've been trying to understand how the HTML
Imports spec is intended to be used.
We have so far received descriptions of how the spec works. I.e. what
happens when the various import related attributes are added to an
link rel=import.
However I'm curious to understand the expected developer work flows.
Let me make a few guesses to clarify the type of description I'm looking
for.
Clearly imports are expected to be used together with web components.
However so far web components are mainly an imperative API, and not a
declarative thing. Any element registrations needs to be created
through JS calls, and all the shadow DOM inside a custom element needs
to be created using JS calls and then inserted into the shadow root
using script.
At first glance it seems like a simple script src=... would then
provide all that you need?
However it might be tedious to create all elements using createElement
and appendChild calls. A better work flow is to stick a script in a
link rel=imported document together with some template elements.
Then clone the of those templates from the constructors of the custom
elements.
And in order to style the custom elements, you would stick a style
element in the imported document which would have rules like
my-button::shadow div.someclass {
color: aliceblue;
}
Is this an accurate description? Are there other reasons to stick
non-script content in the HTML? Are there any examples out there of
how HTML imports are intended to be used?
/ Jonas
Re: [HTML Imports] What is the imagined work flow?
Sorry, but just a bit of follow up.
One may notice that the Web Components spec is imperative and assume that
declarative support is not important. But as it turns out, the notion of
using custom-elements to bootstrap declarative syntaxes allows various
parties to experiment in the real-world, as opposed to a working group
trying to resolve the trade-offs in an a-priori spec.
I mention this, because although I used Polymer as an example (it's my
project after all), the fact is we hope people will use web-components like
this:
link rel=import href=sweet-button.html
...
sweet-button/sweet-button
Is sweet-button implemented via Polymer? X-tags? Vanilla JavaScript? User
doesn't need to know to use the resource.
Ideally, best-of-breed technology emerges and the option to standardize is
still available.
On Tue, May 20, 2014 at 11:56 PM, Scott Miles sjmi...@google.com wrote:
Some of the ways Polymer team uses imports are as follows:
- aggregating script src and/or link rel=stylesheet elements into
functional units
- aggregating imports themselves into units
- expressing dependencies (N modules can each import jquery2-import.html
and I only get one copy of jquery)
- importing self-organizing databases via custom elements (e.g.
core-meta elements describe/provide metadata using monostate pattern)
Also, one of the first things Polymer does is register a custom-element
which itself provides a declarative interface to the custom element
machinery. Most other Polymer elements are then structured declaratively
(as HTML) which makes using imports highly convenient.
would stick a style element in the imported document
You can do that, reference an external stylesheet, or place a (scoped)
style tag directly in the shadow-root.
E.g. using Polymer idiom
polymer-element name=my-button noscript
template
style
:host div.someclass {
color: aliceblue;
}
/style
div class=someclassmy-button/div
/template
/polymer-element
On Tue, May 20, 2014 at 10:08 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Over here at mozilla we've been trying to understand how the HTML
Imports spec is intended to be used.
We have so far received descriptions of how the spec works. I.e. what
happens when the various import related attributes are added to an
link rel=import.
However I'm curious to understand the expected developer work flows.
Let me make a few guesses to clarify the type of description I'm looking
for.
Clearly imports are expected to be used together with web components.
However so far web components are mainly an imperative API, and not a
declarative thing. Any element registrations needs to be created
through JS calls, and all the shadow DOM inside a custom element needs
to be created using JS calls and then inserted into the shadow root
using script.
At first glance it seems like a simple script src=... would then
provide all that you need?
However it might be tedious to create all elements using createElement
and appendChild calls. A better work flow is to stick a script in a
link rel=imported document together with some template elements.
Then clone the of those templates from the constructors of the custom
elements.
And in order to style the custom elements, you would stick a style
element in the imported document which would have rules like
my-button::shadow div.someclass {
color: aliceblue;
}
Is this an accurate description? Are there other reasons to stick
non-script content in the HTML? Are there any examples out there of
how HTML imports are intended to be used?
/ Jonas
RE: where do tests for window.opener go?
From: Hallvord R. M. Steen [mailto:hst...@mozilla.com] Sent: Wednesday, May 21, 2014 4:22 AM To: public-webapps Subject: [web-platform-tests] where do tests for window.opener go? Hi, we have a window.opener issue and would like to have some tests for it. I'm planning to write some and thought I might as well add them to the web- platform-tests suite. Where? Would this be a suitable location: https://github.com/w3c/web-platform- tests/tree/master/html/browsers/the-window-object/security-window ? -HR For security, yes. For navigating auxiliary browsing contests in the DOM, better to https://github.com/w3c/web-platform-tests/tree/master/html/browsers/windows/auxiliary-browsing-contexts
CfC: to create a new developer's list for WebApps' specs; deadline May 28
Hi All, About two years ago I proposed in [1] creating a new list (f.ex. public-webapps-devs) that is targeted toward developers using WebApps' specs. Such a list would be used by developers using the APIs (as opposed to implementers) as well as other related purposes such as announcing relevant meetups, events, conferences, etc. WDYT? My personal take is that public-webapps is a bit of a fire hose for many people that use WebApps' specs so I think a developer oriented list would be useful. All feedback is welcome including explicit signs of support (even just a +1 would be helpful and if you don't want to reply to this list that's fine, just reply to me and Cc www-arch...@w3.org). -Thanks, ArtB [1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0395.html
Re: Blob URL Origin
On Tue, May 20, 2014 at 9:24 PM, Jonas Sicking jo...@sicking.cc wrote: I think you are confusing issues. Or at least talking about two separate issues at once in a way that I'm not sure what you are talking about. The issue of is there an XSS issue with treated blob: like we treat data: is a separate issue from should we treat cross-origin blob: like cross-origin http:, i.e. should we allow pointing an img to a cross-origin blob:. Sure, I'm still at the is there an XSS issue here given that we can pass Blob objects around without restrictions. I had hoped that we had settled the former and decided that blob: should not be treated as data:. And I think we've also decided that we should use the explicit origin syntax, i.e. something like blob:http://example.com/uuid; I'm not quite there yet. In part it seems this design stems from the fact that we cannot create unique enough IDs. My question was if things change if we did create unique enough IDs as it seems we are designing something around a rather artificial limitation. -- http://annevankesteren.nl/
Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28
On Wed, May 21, 2014 at 12:56 PM, Arthur Barstow art.bars...@gmail.com wrote: WDYT? Developers seem to complain about us using mailing lists to communicate rather than GitHub or some other centralized platform that is not email. Might be worth checking with them first. -- http://annevankesteren.nl/
Re: where do tests for window.opener go?
On Wed, 21 May 2014 17:54:44 +0900, Zhang, Zhiqiang zhiqiang.zh...@intel.com wrote: From: Hallvord R. M. Steen [mailto:hst...@mozilla.com] Sent: Wednesday, May 21, 2014 4:22 AM To: public-webapps Subject: [web-platform-tests] where do tests for window.opener go? Hi, we have a window.opener issue and would like to have some tests for it. I'm planning to write some and thought I might as well add them to the web- platform-tests suite. Where? Would this be a suitable location: https://github.com/w3c/web-platform- tests/tree/master/html/browsers/the-window-object/security-window ? -HR For security, yes. For navigating auxiliary browsing contests in the DOM, better to https://github.com/w3c/web-platform-tests/tree/master/html/browsers/windows/auxiliary-browsing-contexts Alternatively, if there are multiple plausible places, and you want some related tests to be in the same place but still annotate some of them as being a test for another section, you can do that with link rel=help. -- Simon Pieters Opera Software
Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28
On 5/21/14 7:02 AM, Anne van Kesteren wrote: Developers seem to complain about us using mailing lists to communicate rather than GitHub or some other centralized platform that is not email. Might be worth checking with them first. Yes, good point Anne. I tweeted this Q with some tags that were intended to extend the reach. If others would also reach out, I would appreciate it. I realize mail lists are a tool and there could be better ones to reach/engage the developer audience. -Thanks, AB
IndexedDB Proposed API Change: cursor.advance BACKWARD when direction is prev
[ Bcc www-tag ; Marc - please use public-webapps for IDB discussions ] On 5/20/14 7:46 PM, marc fawzi wrote: Hi everyone, I've been using IndexedDB for a week or so and I've noticed that cursor.advance(n) will always move n items forward regardless of cursor direction. In other words, when the cursor direction is set to prev as in: range = IDBKeyRange.only(someValue, prev) and primary key is auto-incremented, the cursor, upon cursor.advance(n), will actually advance n items in the opposite direction to the cursor.continue() operation. This is not only an issue of broken symmetry but it presents an obstacle to doing things like: keeping a record of the primaryKey of the last found item (after calling cursor.continue for say 200 times) and, long after the transaction has ended, call our search function again and, upon finding the same item it found first last time, advance the cursor to the previously recorded primary key and call cursor.continue 200 times, from that offset, and repeat whenever you need to fetch the next 200 matching items. Such algorithm works in the forward direction (from oldest to newest item) because cursor.advance(n) can be used to position the cursor forward at the previously recorded primary key (of last found item) but it does not work in the backward direction (from newest to oldest item) because there is no way to make the cursor advance backward. It only advances forward, regardless of its own set direction. This example is very rough and arbitrary. But it appears to me that the cursor.advance needs to obey the cursor's own direction setting. It's almost like having a car that only moves forward (and can't u-turn) and in order to move backward you have to reverse the road. That's bonkers. What's up with that? How naive or terribly misguided am I being? Thanks in advance. Marc
Re: Blob URL Origin
Hmm. One factor that might change my mind on this: If I pass a blob URL, revoking the URL appropriately becomes hard. Even if it gets implemented, auto-revoke can't help with this. That brings back all of the problems with non-auto-revoking blob URLs, and adds a new layer of complexity, since I have to coordinate between the site creating the blob URL and everyone receiving it to figure out when to revoke it. On the other hand, I can just post the blob itself. That avoids all of that mess, and the other side can just create a blob URL from it itself if that's what it needs. That suggests that it's not worth trying to make blob URLs more accessible cross-origin. I can't think of any case where I'd rather pass a blob URL instead of just posting the Blob itself. -- Glenn Maynard
Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28
On May 21, 2014 10:29 AM, Arthur Barstow art.bars...@gmail.com wrote: On 5/21/14 7:02 AM, Anne van Kesteren wrote: Developers seem to complain about us using mailing lists to communicate rather than GitHub or some other centralized platform that is not email. Might be worth checking with them first. Yes, good point Anne. I tweeted this Q with some tags that were intended to extend the reach. If others would also reach out, I would appreciate it. I realize mail lists are a tool and there could be better ones to reach/engage the developer audience. -Thanks, AB + public-nextweb... I've kind of thought of Web Platform Docs as the developer end of things and w3c specs for implementers and wgs - is it possible to set something up under that banner? As a developer, i like the push orientation of mailing lists too, but they suck for lots of other reasons too.
Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28
On Wed, 21 May 2014 16:27:36 +0200, Arthur Barstow art.bars...@gmail.com wrote: On 5/21/14 7:02 AM, Anne van Kesteren wrote: Developers seem to complain about us using mailing lists to communicate rather than GitHub or some other centralized platform that is not email. Might be worth checking with them first. Yes, good point Anne. I tweeted this Q with some tags that were intended to extend the reach. If others would also reach out, I would appreciate it. I realize mail lists are a tool and there could be better ones to reach/engage the developer audience. I don't object to creating a list enough to block the consensus, but as well as Anne's point, I wonder if we should be doing this in webapps or if we should be trying to support W3C's more general Dev Rel efforts instead. Which is partly a question to us, about the easiest way for us to provide any helping others capacity, and partly a question about how developers want help to get to them… cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28
On 5/21/14 11:17 AM, Robin Berjon wrote: I've been in several discussions on this topic over the past months, a good example of which is: https://twitter.com/tobie/status/457075677851037696 In reaction to that, I'm running an experiment to hold such discussions in a manner that may prove more usable: Discourse. It is being used by a growing number of open source projects and is under active development. You are more than welcome to discuss WebApps related topics there, and I'm happy to add relevant categories, make tweaks that may be needed, etc. See: http://discourse.specifiction.org/ Thanks for this information Robin. This could certainly be one way forward. -AB
[Bug 25854] New: Throwing an error in XHR.setRequestHeader for forbidden headers
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25854 Bug ID: 25854 Summary: Throwing an error in XHR.setRequestHeader for forbidden headers Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: manishea...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://xhr.spec.whatwg.org/#the-setrequestheader()-method [[ Terminate these steps if name is a forbidden author header name. ]] Perhaps we should throw a SecurityError or similar here? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25853] New: intentionally constraints
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25853 Bug ID: 25853 Summary: intentionally constraints Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: ms2...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://xhr.spec.whatwg.org/#the-setrequestheader()-method [[ intentionally constraints ]] Should be constrains -- You are receiving this mail because: You are on the CC list for the bug.
Re: IndexedDB Proposed API Change: cursor.advance BACKWARD when direction is prev
On Wed, May 21, 2014 at 7:32 AM, Arthur Barstow art.bars...@gmail.comwrote: [ Bcc www-tag ; Marc - please use public-webapps for IDB discussions ] On 5/20/14 7:46 PM, marc fawzi wrote: Hi everyone, I've been using IndexedDB for a week or so and I've noticed that cursor.advance(n) will always move n items forward regardless of cursor direction. In other words, when the cursor direction is set to prev as in: range = IDBKeyRange.only(someValue, prev) and primary key is auto-incremented, the cursor, upon cursor.advance(n), will actually advance n items in the opposite direction to the cursor.continue() operation. That runs contrary to the spec. Both continue() and advance() reference the steps for iterating a cursor which picks up the direction from the cursor object; neither entry point alters the steps to affect the direction. When you say you've noticed, are you observing a particular browser's implementation or are you interpreting the spec? I did a quick test and Chrome, Firefox, and IE all appear to behave as I expected when intermixing continue() and advance() calls with direction 'prev' - the cursor always moves in the same direction regardless of which call is used. Can you share sample code that demonstrates the problem, and indicate which browser(s) you've tested? This is not only an issue of broken symmetry but it presents an obstacle to doing things like: keeping a record of the primaryKey of the last found item (after calling cursor.continue for say 200 times) and, long after the transaction has ended, call our search function again and, upon finding the same item it found first last time, advance the cursor to the previously recorded primary key and call cursor.continue 200 times, from that offset, and repeat whenever you need to fetch the next 200 matching items. Such algorithm works in the forward direction (from oldest to newest item) because cursor.advance(n) can be used to position the cursor forward at the previously recorded primary key (of last found item) but it does not work in the backward direction (from newest to oldest item) because there is no way to make the cursor advance backward. It only advances forward, regardless of its own set direction. This example is very rough and arbitrary. But it appears to me that the cursor.advance needs to obey the cursor's own direction setting. It's almost like having a car that only moves forward (and can't u-turn) and in order to move backward you have to reverse the road. That's bonkers. What's up with that? How naive or terribly misguided am I being? Thanks in advance. Marc
RE: CommandEvent for user intentions
Great to hear! I’m working on an explainer document that will be more descriptive than the short wiki docs I wrote a couple weeks ago. My thoughts on your questions should be made clearer there. I’ll update this thread by the end of the week with more details, and my initial thoughts are below. I strongly agree that something like CommandEvents is necessary: a web developer should be able to respond to the user’s intent, aka “selectAll”, rather than enumerating, listening to, and responding to each and every platform specific way that the intention to selectAll can be communicated. How encompassing do you envision CommandEvents? Would it only cover well known keyboard shortcuts and actions like those currently used by execCommand? I see this as being more than just well-known keyboard shortcuts. I would like web developers to be able to extend it for their own purposes. What about taking this further and providing better events in two distinct areas: those involving selections (intents like selectAll, but also selection modifications like caret movement by keyboard or gestures, selection changes, etc) and those involving input (including paste/drop/cut/formatting, but also basic text insertion via keyboard/voice/etc). This is a great idea! I'll include it in my spec. I’m not sure an extra event type is necessary here though: why not use beforeinput for the input events, and selectionchange for selection events? Ryosuke’s selection spec currently has a placeholder for selectionchange, and seems like the right place and timing to work this in? My current thought is that Selection events should be used for selection, and CommandEvent for things that would be in a toolbar or context menu. I think the design should make it easy to create and style toolbars based on the available commands and their state. Input events don't cover everything that would be in a toolbar, and they fire for things that already have events for user intentions (like Clipboard Events).
Re: CommandEvent for user intentions
Have you seen the recent post about the rich text editor that Medium uses? It is a somewhat cheeky essay, including a mathematical proof, about how contentEditable is broken. The conclusion is that in order to move forward, we need to treat contentEditable as an API, rather than as a standalone component that tries to do everything itself. It discusses the idea of an edit intent API, which is very in line with this proposal for CommandEvents. https://medium.com/medium-eng/122d8a40e480 On Wed, May 21, 2014 at 11:51 AM, Ben Peters ben.pet...@microsoft.comwrote: Great to hear! I’m working on an explainer document that will be more descriptive than the short wiki docs I wrote a couple weeks ago. My thoughts on your questions should be made clearer there. I’ll update this thread by the end of the week with more details, and my initial thoughts are below. I strongly agree that something like CommandEvents is necessary: a web developer should be able to respond to the user’s intent, aka “selectAll”, rather than enumerating, listening to, and responding to each and every platform specific way that the intention to selectAll can be communicated. How encompassing do you envision CommandEvents? Would it only cover well known keyboard shortcuts and actions like those currently used by execCommand? I see this as being more than just well-known keyboard shortcuts. I would like web developers to be able to extend it for their own purposes. What about taking this further and providing better events in two distinct areas: those involving selections (intents like selectAll, but also selection modifications like caret movement by keyboard or gestures, selection changes, etc) and those involving input (including paste/drop/cut/formatting, but also basic text insertion via keyboard/voice/etc). This is a great idea! I'll include it in my spec. I’m not sure an extra event type is necessary here though: why not use beforeinput for the input events, and selectionchange for selection events? Ryosuke’s selection spec currently has a placeholder for selectionchange, and seems like the right place and timing to work this in? My current thought is that Selection events should be used for selection, and CommandEvent for things that would be in a toolbar or context menu. I think the design should make it easy to create and style toolbars based on the available commands and their state. Input events don't cover everything that would be in a toolbar, and they fire for things that already have events for user intentions (like Clipboard Events).
RE: CommandEvent for user intentions
That is a great article! “A good WYSIWYG editor of arbitrary HTML is just as impossible as the halting problem is impossible... we have to treat it as an editor platform and API, rather than as a standalone component that tries to do everything itself.” Let’s build a platform! From: Julie Parent [mailto:jpar...@gmail.com] Have you seen the recent post about the rich text editor that Medium uses? It is a somewhat cheeky essay, including a mathematical proof, about how contentEditable is broken. The conclusion is that in order to move forward, we need to treat contentEditable as an API, rather than as a standalone component that tries to do everything itself. It discusses the idea of an edit intent API, which is very in line with this proposal for CommandEvents. https://medium.com/medium-eng/122d8a40e480 On Wed, May 21, 2014 at 11:51 AM, Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com wrote: Great to hear! I’m working on an explainer document that will be more descriptive than the short wiki docs I wrote a couple weeks ago. My thoughts on your questions should be made clearer there. I’ll update this thread by the end of the week with more details, and my initial thoughts are below.
Re: contentEditable=minimal
I question whether contentEditable=minimal should actually handle text input. If the idea is to provide the base platform on which a developer can build the editing product of their dreams, isn't text insertion just another behavior they could potentially need to disable? Stepping back, there are distinct concepts that all combine to form the current editing environment: 1. Selections: Enable selections, perform cursor movement, scoping the boundaries on which the selection can operate. 2. Input: Perform dom modifications, dispatch events, not limited to keyboard input, also includes IME, paste, drop, etc. 3. Spell check: Enable spell check, modify the dom (or dispatch an event) when the user selects a replacement 4. Formatting magic: bold when the user hits control + b, change directionality on Ctrl+LeftShift , etc. It sounds like contentEditable=minimal as proposed would only enable #1 and #2, and perhaps allow for #3? To break editing down into true building blocks, I think we need to provide developers a way to explicitly enable each of these systems separably, and not require the element to be contentEditable. On Mon, May 12, 2014 at 9:26 AM, Robin Berjon ro...@w3.org wrote: 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 Wed, May 21, 2014 at 3:59 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 20, 2014 at 9:24 PM, Jonas Sicking jo...@sicking.cc wrote: I think you are confusing issues. Or at least talking about two separate issues at once in a way that I'm not sure what you are talking about. The issue of is there an XSS issue with treated blob: like we treat data: is a separate issue from should we treat cross-origin blob: like cross-origin http:, i.e. should we allow pointing an img to a cross-origin blob:. Sure, I'm still at the is there an XSS issue here given that we can pass Blob objects around without restrictions. The fact that we allow passing blobs around is no different from the fact that we allow passing an ArrayBuffer or a string around. Once a page knows that it has the blob/arraybuffer/string the only way to have it XSS you is to eval() it. Hopefully pages know not to do that when receiving a blob/arraybuffer/string from an untrusted party as it pretty obviously will enable that party to XSS you. eval() always *explicitly* runs code in your origin. Likewise, if you receive a blob from an untrusted party, and then do myscriptelement.src = URL.createObjectURL(blob), then that very explicitly will run code in your origin. It should be no surprise that that will cause an XSS risk and so hopefully pages know not to do that. URLs are different though. If you receive a URL from an untrusted party you can generally do window.location = url. Or you can do myiframeelement.src = url and the worst thing you need to worry about is that the contained page can navigate the top frame. And that you can protect against by using a sandbox attribute. It is not at all obvious that this can suddenly run code in your own origin. Designing a secure platform doesn't mean forbidding any action that can cause bad things to happen. Doing that might create a secure platform, but one that probably can't do anything interesting. Designing a secure platform is done by making things that can be insecure be very explicit about what they do. So if someone wants to do something that might be insecure that they have to very explicitly ask for that. Hopefully that will cause them to think twice about it and take any necessary precautions first. / Jonas
