[whatwg] Making cross-origin (partly) usable
This thread discussed solutions for, amongst others, the following use cases, provided to me off-list by Steven Wittens: > A first huge use case is Facebook Apps, which are inserted using > iframes. They currently use ugly cross-frame communication methods > to shrink-wrap and auto-size the iframe. As an ex-FB dev, this has > always been a huge source of frustration and bugs. Facebook Apps > don't want to inherit CSS from the parent site, it only means the > layout will break whenever Facebook makes a stylistic change or > reorganizes their CSS. Replace Facebook with any other service > provider that allows some form of 3rd party development/integration > through iframes. > > A second use case would be any sort of embeddable widget that comes > with "pre-baked" styles (think Twitter sidebar widgets). Same > problem, but in reverse. At my last job, we had a drop-in iframe > product that provided an entire "contest in a box", with media > submission, entry browsing/searching, modal dialogs, etc. Inheriting > styles from the parent page would simply destroy the careful layout > of what's inside. We shrink wrapped it by requiring people to embed > a script tag rather than iframe tag, using cross frame communication > to send a manual measurement from the frame to the parent. Ugly, and > didn't work in older browsers, and we didn't have the resources to > come up with an XD-proxy workaround like Facebook has. Markus Ernst also discussed the use cases: On Fri, 13 Apr 2012, Markus Ernst wrote: > > I assume that one popular use case for seamlessly embedding cross-origin > frame content is: A service provider allows his/her customers to embed > the pages provided. In this case, the info needed is a list of domains > that are allowed to embed the content, rather than an allowseemless > yes/no flag. On Sun, 27 May 2012, Markus Ernst wrote: > > My use case is a content provider, who provides e.g. a Sudoku > application or a weather forecast for wind surfers. Paying customers are > allowed to embed the content seamlessly in their web sites. The content > can also be embedded for free, but not seamlessly. > > The content provider includes some corporate info, such as his/her own > logo, and a "provided by XY" notice and link to his/her own page. The > paying customers then can apply their own styling, and set the corporate > info to "display:none" in the style sheet of the top document, via > seamless embedding. ...and Adam Barth posted some on the wiki: > Dashboard: A dashboard web site wishes to display status indicators that > are hosted on a number of different domains. The size of these status > indicators varies depending on the status. For example, if a given > domain is having difficulty, the status indicator might list the > problems the domain is having. > Expandable Advertisement: A publisher wishes to display an advertisement > that expands when the user interacts with the advertisement. Today, the > common practice is for the advertising network to run script in the > publisher's page that receives postMessage instructions to resize the > advertisement's iframe, but this requires that the publisher allow the > advertisement to run script in its page, potentially compromising the > publisher's security. So basically, we're just looking for a way to let cross-origin content opt-in to being shrink-wrapped and/or styled on a per-origin basis. On Thu, 12 Apr 2012, Adam Barth wrote: > > [...] something like an attribute on the element might be a > better mechanism [...] That wouldn't work because you need to know before you start parsing, because at any time after you start parsing you might have to render, and you need to have decided whether to shrink-wrap or not by then. Also, it's probably best if we don't make this something you can dynamically change while the page is loaded, at least unless there's a compelling use case. On Thu, 12 Apr 2012, Anne van Kesteren wrote: > > [...] the enormous growing number of one-off flags developers can attach > to resources for various features is starting to get worrisome. Yes, reusing something that exists already seems like a solid win. It's not clear anything suitable exists, though. On Sat, 26 May 2012, Adam Barth wrote: > > [CSP] CSP doesn't seem to include any features that would let you limit who is allowed to iframe you, so I don't think CSP as designed today provides a solution for the per-origin part. Could it be extended? > [X-Frame-Options] This doesn't let you chose on a per-origin basis whether you can be framed either (since you don't get an Origin header in the request, and the X-F-O header only gives a thumbs-up or thumbs-down in general). I'm dubious about extending X-F-O since it lacks a spec and so how exactly to change it in a backwards-compatible way is unclear and getting it wrong would be very dodgy. On Thu, 12 Apr 2012, Ojan Vafai wrote: > > we could add a special http header and/or
Re: [whatwg] Make DOMStringMap constructable, and el.dataset writeable?
On Fri, 30 Nov 2012, Tab Atkins Jr. wrote: > On Fri, Nov 30, 2012 at 4:01 PM, Ian Hickson wrote: > > On Fri, 30 Nov 2012, Tab Atkins Jr. wrote: > >> She's making a game, where the game initialization script expects > >> certain types of elements, and for the initial state data of the > >> elements to be present in data attributes on them. She'd like to be > >> able to pause the game, shifting all the state data into localStorage, > >> then later resume by pulling it back onto elements before starting the > >> game script. > > > > Presumably you wouldn't necessarily want to grab _all_ the data-* > > attributes, since some might be from other libraries, or temporary > > transitional values used for animations or tracking things like mouse > > position. > > Nah, that's fine. Might be non-optimal in some cases, but then you > can just pick them out individually. Well that's kind of my point. You can pick them out individually... how common is it going to be that you want all of them? > >> It would be somewhat cleaner if she could simply construct a > >> DOMStringMap and assign it > > > > I don't really understand what you would do with the DOMStringMap and > > localStorage. Can you elaborate? > > Sorry, when putting it in localStorage, you have to serialize it to > JSON. Then you want to revive it as a DOMStringMap initialized by an > object. If you're going to do all that work, why not just do it with the element? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make DOMStringMap constructable, and el.dataset writeable?
On Fri, Nov 30, 2012 at 1:31 PM, Boris Zbarsky wrote:
> On 11/30/12 2:23 PM, Tab Atkins Jr. wrote:
>> It would be somewhat cleaner if she could simply construct a
>> DOMStringMap and assign it, like so:
>>
>> for(var i = 0; i < cards.length; i++) {
>>cards[i].dataset = new DOMStringMap(carddata[i]);
>
> So this would copy the DOMStringMap into the dataset, not actually change
> the value of cards[i].dataset, right?
Sure. I presume you're afraid of multiple elements sharing the same object?
> Given that, would it make more sense to just have a setFrom method on
> dataset that takes a string? I guess the problem with that is name
> collisions with data items...
Yes, collisions make this a no-go.
> Really, what we want to be able to do here is assign a string to .dataset
> and have it do the right thing... WebIDL doesn't really support that very
> well; perhaps it should.
What would the string be? String-serialized JSON object?
Isn't this what [PutForwards] is for?
>> Another potentially interesting use-case for this is making it
>> possible to "transfer" data-* attributes from one element to another
>> with a simple "el1.dataset = el2.dataset;" statement.
>
> Again, this would copy, not share, yes?
Yes. I presume same fear?
~TJ
Re: [whatwg] Make DOMStringMap constructable, and el.dataset writeable?
On Fri, Nov 30, 2012 at 4:01 PM, Ian Hickson wrote: > On Fri, 30 Nov 2012, Tab Atkins Jr. wrote: >> She's making a game, where the game initialization script expects >> certain types of elements, and for the initial state data of the >> elements to be present in data attributes on them. She'd like to be >> able to pause the game, shifting all the state data into localStorage, >> then later resume by pulling it back onto elements before starting the >> game script. > > Presumably you wouldn't necessarily want to grab _all_ the data-* > attributes, since some might be from other libraries, or temporary > transitional values used for animations or tracking things like mouse > position. Nah, that's fine. Might be non-optimal in some cases, but then you can just pick them out individually. >> It would be somewhat cleaner if she could simply construct a >> DOMStringMap and assign it > > I don't really understand what you would do with the DOMStringMap and > localStorage. Can you elaborate? Sorry, when putting it in localStorage, you have to serialize it to JSON. Then you want to revive it as a DOMStringMap initialized by an object. ~TJ
Re: [whatwg] Make DOMStringMap constructable, and el.dataset writeable?
On Fri, 30 Nov 2012, Tab Atkins Jr. wrote: > > She's making a game, where the game initialization script expects > certain types of elements, and for the initial state data of the > elements to be present in data attributes on them. She'd like to be > able to pause the game, shifting all the state data into localStorage, > then later resume by pulling it back onto elements before starting the > game script. Presumably you wouldn't necessarily want to grab _all_ the data-* attributes, since some might be from other libraries, or temporary transitional values used for animations or tracking things like mouse position. > It would be somewhat cleaner if she could simply construct a > DOMStringMap and assign it I don't really understand what you would do with the DOMStringMap and localStorage. Can you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make DOMStringMap constructable, and el.dataset writeable?
On 11/30/12 7:07 PM, Tab Atkins Jr. wrote: Sure. I presume you're afraid of multiple elements sharing the same object? We can call it "afraid" or we can call it "nonsensical" since the object is just syntactic sugar on top of the (not shared) attributes the objects have ;) Really, what we want to be able to do here is assign a string to .dataset and have it do the right thing... WebIDL doesn't really support that very well; perhaps it should. What would the string be? String-serialized JSON object? Whatever you're proposing be passed to the DOMStringMap constructor, no? Isn't this what [PutForwards] is for? Unfortunately, no. [PutForwards] will take the RHS and pass it to the setter of some attribute of the LHS. But that requires there to be such an attribute, which is a no-go due to the name collision thing... Basically what we want here is an IDL attribute for which the getter returns one type but the setter takes a different type. Or something. We can do it the way you proposed, but it seems like a workaround for the lack of ability to declare such a thing in WebIDL. Yes. I presume same fear? Yes. -Boris
[whatwg] Firing all the "the end" messages on abort
On Wed, 29 Aug 2012, Boris Zbarsky wrote: > On 8/29/12 6:11 PM, Ian Hickson wrote: > > Documents that are aborted do not need to work, they were aborted > > precisely because they don't need to work and are no longer needed. > > Or because once again some ad was taking forever to load and the web > page developer is doing all their stuff from onload, so the user just > hit stop to finally get the damn ui to show up. On Thu, 30 Aug 2012, Simon Pieters wrote: > > Indeed. It would be pretty bad user experience if we didn't fire load > when the user clicks "stop". That's for the "stop" key, though, right? Not for aborts that occur e.g. due to navigation, document.open(), or window.stop(). The spec doesn't say what browser UI should do, so if this is just about the stop key, I don't think this needs a spec change. The browser can do whatever it wants when you hit the stop key, e.g. just closing all network sockets, or stopping JS, or stopping animations, or whatever. As far as I can tell, firing 'load' events when a document gets aborted due to new navigation, or document.open(), or window.stop(), is not Web-compatible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make DOMStringMap constructable, and el.dataset writeable?
On 11/30/12 2:23 PM, Tab Atkins Jr. wrote:
It would be somewhat cleaner if she could simply construct a
DOMStringMap and assign it, like so:
for(var i = 0; i < cards.length; i++) {
cards[i].dataset = new DOMStringMap(carddata[i]);
So this would copy the DOMStringMap into the dataset, not actually
change the value of cards[i].dataset, right?
Given that, would it make more sense to just have a setFrom method on
dataset that takes a string? I guess the problem with that is name
collisions with data items...
Really, what we want to be able to do here is assign a string to
.dataset and have it do the right thing... WebIDL doesn't really
support that very well; perhaps it should.
Another potentially interesting use-case for this is making it
possible to "transfer" data-* attributes from one element to another
with a simple "el1.dataset = el2.dataset;" statement.
Again, this would copy, not share, yes?
-Boris
Re: [whatwg] URL: URLQuery
On Fri, Nov 30, 2012 at 10:02 AM, Alexandre Morgaut wrote: >> Only feedback left is the return types of set(), append(), and delete(). > > Maybe remove() would be better than delete() as delete is a reserved JS > keyword ;-) Nope, it's contextually reserved. You can use in places like a method name without a problem. ~TJ
Re: [whatwg] URL: URLQuery
On Fri, Nov 30, 2012 at 9:47 AM, Anne van Kesteren wrote: > On Fri, Nov 30, 2012 at 6:42 PM, Tab Atkins Jr. wrote: >> Only feedback left is the return types of set(), append(), and delete(). >> >> In Maps, set() returns the map, so you can chain more easily. TC39 >> hasn't yet made delete() return the map, but they plan to (baby steps, >> apparently, but us jumping on it will help). Obviously, append() >> should match set(). > > Right, once I have a definitive answer to > http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0164.html > I will update a bunch of APIs to use chaining (assuming the answer is > that yes, this is the plan). I'm not really a fan of the style myself > so I'm not sure I want to be the one to push TC39 :-) Map#set returning the map is already in the draft, and there are no plans to change it. ~TJ
Re: [whatwg] URL: URLQuery
> > Only feedback left is the return types of set(), append(), and delete(). > Maybe remove() would be better than delete() as delete is a reserved JS keyword ;-) Alexandre Morgaut Wakanda Community Manager 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email :alexandre.morg...@4d.com Web : www.4D.com
Re: [whatwg] Adding crossorigin="" to more elements
On Thu, Nov 29, 2012 at 6:44 PM, Ian Hickson wrote: > On Thu, 29 Nov 2012, Boris Zbarsky wrote: >> > Anyway, this is somewhat moot to me because it'll all have to be >> > defined by whatever spec it is that currently says that a CSS sheet on >> > http: can't import an image on file:, etc. >> >> Heh. Does it affect things like CSP in any way? > > No idea. Adam? I'm not sure I have all the context for this question, but generally CORS and CSP don't really interact with each other. If something is blocked by CSP, the user agent never gets to the point where it wonders about CORS. Adam
Re: [whatwg] Make DOMStringMap constructable, and el.dataset writeable?
On Fri, Nov 30, 2012 at 8:23 PM, Tab Atkins Jr. wrote: > Thoughts? URLQuery uses this model. But I reckon that for DOMStringMap it is a bit trickier since it is actually mostly about manipulating DOM attributes through a simpler interface. It's not a map that is serialized to attributes whenever you manipulate it and seeded from attributes whenever those are manipulated. -- http://annevankesteren.nl/
[whatwg] Make DOMStringMap constructable, and el.dataset writeable?
Currently, el.dataset is readonly. A friend of mine passed along a
use-case for making it writeable.
She's making a game, where the game initialization script expects
certain types of elements, and for the initial state data of the
elements to be present in data attributes on them. She'd like to be
able to pause the game, shifting all the state data into localStorage,
then later resume by pulling it back onto elements before starting the
game script.
Right now she has to do this with a for-in loop, like:
for(var i = 0; i < cards.length; i++) {
for(var k in carddata[i]) {
cards[i].dataset[k] = carddata[i][k];
}
}
It would be somewhat cleaner if she could simply construct a
DOMStringMap and assign it, like so:
for(var i = 0; i < cards.length; i++) {
cards[i].dataset = new DOMStringMap(carddata[i]);
}
Another potentially interesting use-case for this is making it
possible to "transfer" data-* attributes from one element to another
with a simple "el1.dataset = el2.dataset;" statement.
Thoughts?
~TJ
Re: [whatwg] URL: URLQuery
On Fri, Nov 30, 2012 at 7:02 PM, Alexandre Morgaut wrote: > Maybe remove() would be better than delete() as delete is a reserved JS > keyword ;-) We use it because ES6's Map uses it. It should be no problem, except with syntax highlighting, but that is already broken by Map's existence as I understand it. -- http://annevankesteren.nl/
Re: [whatwg] URL: URLQuery
On Fri, Nov 30, 2012 at 6:42 PM, Tab Atkins Jr. wrote: > Only feedback left is the return types of set(), append(), and delete(). > > In Maps, set() returns the map, so you can chain more easily. TC39 > hasn't yet made delete() return the map, but they plan to (baby steps, > apparently, but us jumping on it will help). Obviously, append() > should match set(). Right, once I have a definitive answer to http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0164.html I will update a bunch of APIs to use chaining (assuming the answer is that yes, this is the plan). I'm not really a fan of the style myself so I'm not sure I want to be the one to push TC39 :-) -- http://annevankesteren.nl/
Re: [whatwg] Canvas in Workers
On Fri, 30 Nov 2012, Gregg Tavares (社�~T�) wrote: > > on ImageBitmap should zero size canvases just work (and create a 0 sized > ImageBitmap)? > > My personal preference is for APIs that just work with zero sizes so I > don't have to write lots of special cases for handling zero. > > For example [1,2,3].slice(0,0) returns []. It doesn't throw. > "abc".substring(0,0) returns "" it doesn't throw. fillRect(x, y, 0, 0) > doesn't throw. etc... > > It just makes life a lot easier The main reason 0-sized canvases have always thrown in drawImage() is that I couldn't work out what you would paint, nor why you'd have a zero-sized canvas, and throwing seemed like it'd be the best way to help the author figure out where the problem was, rather than just ignoring the call and having the author scratch their head about why nothing was happening. If there's cases where you would legitimately end up with zero-sized canvases that you'd try to draw from, though, I'm happy to change it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] URL: URLQuery
On Fri, Nov 30, 2012 at 9:17 AM, Anne van Kesteren wrote: > On Sat, Oct 13, 2012 at 12:24 AM, Tab Atkins Jr. wrote: >> If we do stick with the method-based map, I strongly feel we should >> match the JS Map API, and have a has() method as well. *Ideally*, >> this would be a subclass of Map. > > This is now done: http://url.spec.whatwg.org/#urlquery > > Feedback welcome! Only feedback left is the return types of set(), append(), and delete(). In Maps, set() returns the map, so you can chain more easily. TC39 hasn't yet made delete() return the map, but they plan to (baby steps, apparently, but us jumping on it will help). Obviously, append() should match set(). ~TJ
Re: [whatwg] URL: URLQuery
On Sat, Oct 13, 2012 at 12:24 AM, Tab Atkins Jr. wrote: > If we do stick with the method-based map, I strongly feel we should > match the JS Map API, and have a has() method as well. *Ideally*, > this would be a subclass of Map. This is now done: http://url.spec.whatwg.org/#urlquery Feedback welcome! (Note that IDL bits for initializing with a dictionary and making it based on Map underneath are still in progress.) -- http://annevankesteren.nl/
Re: [whatwg] Menus and Toolbars
Hi, I like the 2nd proposal, but #3 would be ok too in my opinion Jan On Wed, Nov 28, 2012 at 1:12 AM, Ian Hickson wrote: > > (If you're cc'ed, your opinion likely affects implementations of this and > so your input is especially requested. See the question at the end. If you > reply to this, please strip the cc list as the mailing list software will > otherwise block your post for having too many cc's. Thanks.) > > There's a big section in the spec that tries to do three things: > > * context menus > * toolbars > * menu buttons > > Right now it's not implemented by anyone, though Firefox has a variant. > >http://whatwg.org/html/#the-menu-element > > This section has two big problems: > > 1. Styling of toolbars and menu buttons is just not defined. > > Toolbars could be a purely stylistic issue, to be solved either excluively > by CSS, or CSS plus a component/widget binding model (whatever solution we > end up with for that). > > Menu buttons are a real widget, though, so we can't just leave them to CSS > styling of s, there needs to be some real styling going on. Right > now, because of the algorithm mentioned in #2 below, this is very > complicated. I'll get back to this. > > (Styling for context menus is not a big deal, they just use native UI.) > > > 2. Nobody is implementing it, in particular, the algorithm that converts > HTML elements into a menu structure seems unpopular. > > Right now, the spec has this algorithm that defines how to map existing > HTML semantics to a context menu or menu button (or toolbar, though the > latter is less important if we move to a pure-CSS rendering model for > toolbars, since we'd just drop the algorithm for them then). > > The idea here is that you don't have to use JavaScript to replicate the > effects of existing semantics. For example, if you want a menu button > which acts as a navigation mechanism, you just put elements in your > markup and they automatically get turned into menu items. > > There's also a generic element for when you don't need an > existing element to be used. Firefox essentially only implements this, > though it's called in Firefox. also supports an > attribute that points at other elements to indirectly define features. > > > To move forward on this, here are some proposals: > > #1: Drop and all related features. I don't think we should do this, > but if we can't get agreement on what to implement, this is the only > option left, so it's on the table. > > > #2: A design that supports context menus and menu buttons using dedicated > markup, with support for indirect defining of commands. > > First, we make take three values: "toolbar", which just > means to render the element using CSS (the default value for legacy pages, > too), and "context" and "button", which define menus. "context" menus > would be hidden by default, "button" menus would render as a button, > which, when clicked, shows the menu. contextmenu="" can be used to point > to a . > > The element in "context" and "button" modes would only have three > elements as descendants: elements, elements, and > elements. (Or maybe no s, and we do separators by using groups of > elements without labels.) Other children are ignored. > > elements would just have a label="" attribute and, optionally, > a command="" attribute. The command="" attribute would work as it does in > the spec now, deferring to some existing element. When the menu item is > selected, it would fire click on the , and then as a default > action do whatever the action of the command="" is, if specified. (We can > talk about whether to bother supporting icons in the , and if so > how, especially given high-res screens, but that's a minor detail.) > > With type=button, CSS would apply to the and elements, > maybe with a limited set of properties applying. Long term, we look to XBL > or Web components or whatever for styling. > > We drop entirely. > > > #2a: Same as #2, except we keep as a way to introduce commands > without using existing elements. > > > #3: We forget the non-JS case; so, the same as #2, but doesn't > get a command="" attribute. We add radio menu items, checkbox menu items, > and the like, over time, as features on . (Defined much like > has some of them defined today.) > > > #4: We do what the spec has now. > > > #5: We do what the spec has now, except we change the type=toolbar to just > be rendered in CSS (and remove type=list, making toolbar the default). > > > #6: Your idea here. > > > So, implementors: Which of these would you be willing to implement? Are > there constraints I've not thought of? Are there features that we need to > deal with that I haven't mentioned above? Are there use cases that we > should just abandon that could simplify the solution drastically? > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `
