Topic on Extension talk:EmbedScript/Flow

I like this idea very much. A few points:

• It seems like this might blur the distinction between Wikipedia ("encyclopedic content") and Wikiversity ("learning resources", which I've taken to mean this kind of thing), if this is used on WP pages.
• Being able to feed Wikidata into an embedded script opens some interesting possibilities...
• In a while, it seems like users are going to need to know javascript, CSS, Lua, and parserfunctions in order to be able to edit all layers of the content, which is up from the current CSS, parserfunctions, magic words, and wikitext formatting. I'm not sure whether this is something to be concerned about.
• Unless I'm mistaken, while using an off-domain iframe removes the most severe security problems, there could still be issues with the possibility of, say, having the script activate Special:UserLogout, which would be really annoying if it was vandalized onto a semi-protected page. I think it could probably also watch or unwatch pages without the user's consent (or were those changed to require tokens?).
• WebGL in Mediawiki pages. Awesome.
• Having part of the content dependent on actual javascript limits the potential reuse of Wikimedia projects. Printed pages, audio versions, Wikipedia readers, etc. won't be able to make use of embedded scripts, so no ES's can really be allowed to be vital to the article.
• I can think of lots of places being able to use js on pages could be useful outside the content space, such as in editing tutorials, demonstration of user scripts, easier explaining of certain things for people with good technical abilities but horrible language skills :) ,etc... Hmmm...
• I think this would open up the possibility of audio running without the reader's consent, which was previously impossible. I don't think that would be really considered a major issue, though. (And plugins running from unsafesubdomainofdoom.wikimedia.org are not safe, good for people to know :P )
• All iframes must be clearly iframes, if phishing is to be avoided (I think?).
• Is it likely enough that this is going to be enabled on Wikimedia wikis at some point that it would make sense for people to start creating ES's in advance? If so, it might make sense to publicize this somewhat.

Tl;dr JS in content, must have.

More:

• There have been requests for expandable trees that can load further Wikidata content on-demand. It could be useful if the iframe could request that the parent frame retrieve Wikidata content via the API. (Things like Wikidata's d:Template:Tree can only load so much at once...)
• Not all users will be able to use the embedded scripts, either due to JS being disabled, certain features being unsupported, etc. This issue could be alleviated somewhat by adding the option to add fallback content.
• Using the sandbox attribute eliminates risks of plugins, along with certain other risks.
• Embedded scripts could allow for some very cool data visualizations, perhaps using things like the D3.js library.

I'm starting this project back up; following up on some old comments. :)

• Re: some of the potential issues with unexpected audio content, etc -- click-to-play might make sense, though currently I've got it running things 'live'.
• Related & re: printable/offline/no-JS content -- I'm thinking about reworking it from standalone JS scripts to a structured code tree including HTML scaffold, CSS, JS, and "fallback content" methods. The fallback content, or a variant of it, could also do a "snapshot" or "thumbnail" to be shown before we load the live code, if we do click-to-play.
• I'm VERY interested in being able to query data, but need to think about the security implications of doing things on the user's behalf
• Visualizations could kick butt -- reminds me need to provide some sort of library functionality maybe