Re: April face-to-face meetings for HTML and WebApps
Or the other way around. In any case, I was only making a point against systematic avoidance of major religious holidays, in favor of a more case-by-case basis. On Thu, Feb 9, 2012 at 6:38 AM, Marcos Caceres w...@marcosc.com wrote: On Thursday, February 9, 2012 at 4:18 AM, Andres Riofrio wrote: Regarding the checklist: perhaps these things are only relevant if there are Christian/Jewish/Muslim people in the group. And if there are people that prefer not to meet on Saturday. It seems to me more reasonable to expect people with prior commitments, that plan to attend, to speak up, and expect the rest to understand and try to come to a consensus. That's why people ask for objections anyway. Right, sometimes one might have to make sacrifices and forgo a Saturday or observing some religious thingy out of respect for the sectarian nature of the W3C membership (and for the advancement of our beloved and sacred Web). Kind regards, Marcos
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Fri, 10 Feb 2012 01:24:05 +0100, Ian Hickson i...@hixie.ch wrote: We're going out of our way to do lots of special processing for HTML in a paste. Why doesn't a drop of HTML get the same treatment? This is a good question. Presumably the scenario is that hostile page A provides some content and gets the user to select and copy or drag it to page B's contentEditable region, including any script in the selection, which once pasted becomes a cross-site scripting vulnerability. That might be one threat model, but it's one that UAs are already handling. Most UAs remove or plan to remove SCRIPT tags from pasted HTML data. I've mentioned this in the drag-and-drop spec. Goo idea. Now, I don't think that was the question Daniel Cheng was asking. If you look at the HTML/XHTML specific instructions for the paste event (in the processing model section: http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll see that it specifies quite a bit of parsing and such. The goals are: * Resolve URLs and links - the page script won't know the base URI to resolve against (on Windows this is in the CF_HTML format's meta data and the page script doesn't get access to it) * Make it possible to paste HTML from a local application that embeds local resources (img src=file://..) and enable page scripts to process and upload said resources * Optionally do extra privacy or security-related filtering if the UA implementor considers it useful So, I think the question Daniel is asking, is: why don't we process URLs and local resources this way if HTML data is drag-and-dropped to a page? Should this processing be moved to the DnD spec? Finally, regarding the topic this E-mail's subject is dealing with, I've spec'ed this: implementation should use clipboard content sequence number on platforms where this is available, creativity elsewhere, to make sure script can only access one single clipboard entry. I've also added a test for this. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: Enabling a Web app to override auto rotation?
Device-level orientation lock deals with different use-cases than the ones we are discussing here. It let's the user force the device into either of portrait or landscape mode whatever the physical orientation of the device actually is. The main reason for this need is that orientation of the device is relative to the Earth's gravitational field and not to the physical position of the user. That's typically annoying when you want to read while lying down on your side. If the device's orientation was obtained relative to the user's face (e.g. by means of a camera doing facial recognition) the need for a device-level orientation-lock might not even exist. Document-level orientation lock is different. It isn't so much about enabling applications to change orientation as it is about signaling to the UA that UI only exists in one of portrait or landscape mode. A good analogy is to think of photos or movies. The device's orientation (or the dimensions of the screen) on which they are displayed won't suddenly modify their characteristics. A picture in portrait mode is a picture in portrait mode. Rotating it sideways won't suddenly turn it (hah!) into a picture in landscape mode. How the device decides to display it (cropping it, surrounding is with black bars, asking the user to rotate the device) is an orthogonal issue. Of course there are a number of points of friction (e.g. how do you handle document-level and system-level oreientation-locks conflict, what happens when you browse through a series of documents which have different document-level orientation-locks, etc.), but these are best discussed as part of the WG's work rather than in a preamble to decide whether or not this is worth adding to the charter. --tobie On 2/10/12 6:28 AM, timeless timel...@gmail.com wrote: Personally I consider this a QoI issue for UAs. There will be lots of web pages that won't support / use this auto-rotation suppressor. UAs will need and want to let their users deal with this. The BlackBerry PlayBook for instance has an item for it: swipe in from top right corner, tap the orientation widget, select lock orientation, tap the application content area, move on with life. I'm not saying it's perfect, and I've been planning to write out more detailed proposals for more advanced things, but sometimes adding a web-API doesn't really help the user. This isn't a web page problem, it's a system problem, and the user will benefit from having a *single* and *consistent* method for addressing it across all applications, native, web, and web written by other people who decide to put buttons and widgets in places the user won't expect. Disclaimer: while my employer isn't endorsing my opinion, I'm happy to use its products. On 2/8/12, Tobie Langel to...@fb.com wrote: The general use case is any UI that's been designed exclusively for portrait or landscape mode because displaying it in the other mode either doesn't make any sense (e.g. most platform games), requires some artifice that the designer wanted to avoid (e.g. to function in landscape mode, e-readers rely on the book metaphor), or isn't cost effective (i.e. it requires designing two radically different UIs instead of one). --tobie On 2/8/12 9:16 AM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, 8 February 2012 at 07:39, Charles Pritchard wrote: In case it's needed; use case: User is drawing a sketch on their mobile phone and their rotation is intentional as if they are working with a physical piece of paper. or a car game where the driving is controlled by how much the device is rotated (you want the orientation locked, probably to landscape)Š There are other games, like Rolando [1], that make use of both portrait, landscape, and a kind of fixed modeŠ where the orientation is fixed no matter what way you rotate the screen (think of rotating a video cameraŠ the world in the view finder stays fixed) [1] http://rolando.ngmoco.com/ -- Sent from my mobile device
Re: Enabling a Web app to override auto rotation?
Absolutely. This is currently handled at the application level by the games themselves, which is ridiculous. If there was a proper way for a game to specify in what orientation it was supposed to be played, then conflicts between the game's needs and the device's current orientation could be handled at system level and be consistent across all applications. --tobie On 2/10/12 8:29 AM, Jordan Dobson jordandob...@gmail.com wrote: One way people do this today already is to use media queries to hide the UI when it's rotated into an orientation they don't support. Example: * http://mrgan.com/pieguy/ * http://cl.ly/E5fw * http://cl.ly/E56V Hope this helps if anyone is looking to do anything similar in the near future. - Jordan On Thu, Feb 9, 2012 at 9:28 PM, timeless timel...@gmail.com wrote: Personally I consider this a QoI issue for UAs. There will be lots of web pages that won't support / use this auto-rotation suppressor. UAs will need and want to let their users deal with this. The BlackBerry PlayBook for instance has an item for it: swipe in from top right corner, tap the orientation widget, select lock orientation, tap the application content area, move on with life. I'm not saying it's perfect, and I've been planning to write out more detailed proposals for more advanced things, but sometimes adding a web-API doesn't really help the user. This isn't a web page problem, it's a system problem, and the user will benefit from having a *single* and *consistent* method for addressing it across all applications, native, web, and web written by other people who decide to put buttons and widgets in places the user won't expect. Disclaimer: while my employer isn't endorsing my opinion, I'm happy to use its products. On 2/8/12, Tobie Langel to...@fb.com wrote: The general use case is any UI that's been designed exclusively for portrait or landscape mode because displaying it in the other mode either doesn't make any sense (e.g. most platform games), requires some artifice that the designer wanted to avoid (e.g. to function in landscape mode, e-readers rely on the book metaphor), or isn't cost effective (i.e. it requires designing two radically different UIs instead of one). --tobie On 2/8/12 9:16 AM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, 8 February 2012 at 07:39, Charles Pritchard wrote: In case it's needed; use case: User is drawing a sketch on their mobile phone and their rotation is intentional as if they are working with a physical piece of paper. or a car game where the driving is controlled by how much the device is rotated (you want the orientation locked, probably to landscape)Š There are other games, like Rolando [1], that make use of both portrait, landscape, and a kind of fixed modeŠ where the orientation is fixed no matter what way you rotate the screen (think of rotating a video cameraŠ the world in the view finder stays fixed) [1] http://rolando.ngmoco.com/ -- Sent from my mobile device -- Jordan Dobson ? Designer / Developer ? 425-444-8014 ? JordanDobson.com http://JordanDobson.com
Re: April face-to-face meetings for HTML and WebApps
On Thu, 09 Feb 2012 19:11:05 +0100, Andres Riofrio ariof...@cs.ucsb.edu wrote: Or the other way around. In any case, I was only making a point against systematic avoidance of major religious holidays, in favor of a more case-by-case basis. As ne of the chairs who was involved in scheduling... I try to avoid major holidays that I know will cause problems for many people. And events which will do the same - a lot of the group might go to Google I/O or SxSW, or somehow think the world knows or cares when thanksgiving is and why we should avoid holding meetings then. In the end, there will always be someone who can't make a meeting - this is one of their inherent drawbacks. Thinking about how to make sure it isn't always the *same* someone is important. (And Josh has a fair point, there *are* jewish people involved here who take their religion seriously enough that it causes them a problem). I made an assumption about when passover is that was incorrect, instead of checking, which contributed to the problem. I don't actually believe that your religious holiday/kids' special event/wife's anniversary/much-anticipated holiday is less important than the future of the web. But nor do I know of any individual alive whose presence is critical to the success of a webapps / HTML meeting. There are many people who will, should they be able to, contribute greatly to that success, and if we can't get enough people to the meeting we won't run it. The current W3C process allows people to object to other people having formal meetings (which strikes me as very asymmetrical - you can't object to a self-selected bunch of people meeting without inviting anyone else) without sufficient notice. It also (quite reasonably) allows people to point out that we have what amounts to a systemic bias in the way we organise them (more than one - we have a very conscious bias towards helping out Bay Area residents at the cost of everyone else :( ), which is what happened here. If you're likely to attend, please say so. If you're unlikely to attend wherever and whenever the meeting is, you don't need to say anything. If you would attend under different circumstances, feel free to say what they are... For the record: I prefer to hold meetings in Europe (in the large, including Russia, North Africa, ...) as it is easier to have Opera people present at them. But we will make the effort to contribute when- and wherever the meeting may be. cheers On Thu, Feb 9, 2012 at 6:38 AM, Marcos Caceres w...@marcosc.com wrote: On Thursday, February 9, 2012 at 4:18 AM, Andres Riofrio wrote: Regarding the checklist: perhaps these things are only relevant if there are Christian/Jewish/Muslim people in the group. And if there are people that prefer not to meet on Saturday. It seems to me more reasonable to expect people with prior commitments, that plan to attend, to speak up, and expect the rest to understand and try to come to a consensus. That's why people ask for objections anyway. Right, sometimes one might have to make sacrifices and forgo a Saturday or observing some religious thingy out of respect for the sectarian nature of the W3C membership (and for the advancement of our beloved and sacred Web). Kind regards, Marcos -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: connection ceremony for iframe postMessage communications
On Thu, Feb 9, 2012 at 11:53 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 9 Feb 2012, John J Barton wrote:
On Thu, Feb 9, 2012 at 4:42 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 9 Feb 2012, John J Barton wrote:
However the solution has two significant problems:
1. There is no way to know if portToOtherWindow is connected before
you issue postMessage()
Just have the target message you when it's ready.
What I meant was just to do this on the receiving side (inside the
iframe), after the onmessage handler has been set up (which we are
assuming happens after the 'load' event for some reason):
parent.postMessage('load', '*');
That way you don't have to depend on the 'load' event, you can just wait
for the message from the inner frame. Then when you get it, you know you
can start sending..
The problem here is that the iframe may issue
parent.postMessage('load', '*) before the parent onmessage handler
has been set up. Modern apps no longer use single-point
synchronization. The parent window 'load' event has no time relation
to the onmessage handler setup, neither the iframe load event.
Instead we have multiple synchronizations based on the dependency
relationships. This started with script loading but eventually all
content will be loaded this way.
In the past I've created synchronization in the parent by making the
iframe loading dependent upon the onmessage handler set up. But this
complicates and thus constraints the design. A peer-to-peer or
symmetric solution would be better.
And when you do send, you just send a message whose contents are just a
single key saying what API endpoint you want, and a port, which you then
use for all communication for that particular API call.
Just to clarify, I want to see the layer you just outlined be standard
so we can design iframe components and apps to mix and match. This can
be two simple layers on the current messaging: 1) the connection
ceremony, 2) the key/API format.
No races or anything.
Unfortunately for devs, the Web app world is becoming asynchronous.
jjb
--
Ian Hickson U+1047E )\._.,--,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: April face-to-face meetings for HTML and WebApps
I'm definitely interested in attending some f2f webapps meetings. I have no real preference on location. ~TJ
[FileAPI] RfC of pre-LC version; deadline Feb 24
Arun's latest updates to File API means the spec is very close to being ready for Last Call WD. As such, this is a Request for Comments of a pre-LC version of the spec using the latest ED as the basis: http://dev.w3.org/2006/webapi/FileAPI/ Please review the latest ED (above) now and send all comments to public-webapps by February 24. FYI, the spec's bug list is currently zero [1]. -AB [1] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=File%20APIresolution=---
Re: connection ceremony for iframe postMessage communications
On Fri, 10 Feb 2012, John J Barton wrote:
What I meant was just to do this on the receiving side (inside the
iframe), after the onmessage handler has been set up (which we are
assuming happens after the 'load' event for some reason):
parent.postMessage('load', '*');
That way you don't have to depend on the 'load' event, you can just
wait for the message from the inner frame. Then when you get it, you
know you can start sending..
The problem here is that the iframe may issue parent.postMessage('load',
'*) before the parent onmessage handler has been set up.
You can always guarantee that you've set up your handler before you create
the iframe. But, suppose that's somehow not possible. Then you just define
ping as a message you can send to the inner frame, which the inner frame
then responds to with the aforementioned load message.
So now you have the following situations:
- parent is set up first, then opens iframe:
- iframe sends 'load' message when ready
- parent opens iframe, then sets up communications, iframe is quicker:
- iframe sends 'load' message when ready, but it gets missed
- parent sends 'ping' message
- iframe sends 'load' message in response
- parent opens iframe, then sets up communications, parent is quicker:
- parent sends 'ping' message, but it gets missed
- iframe sends 'load' message when ready
In all three cases, the first 'load' message that is received indicates
that the communication system is ready.
(In practice it's usually much simpler than any of this because the parent
can guarantee that it sets up its communications first, before the iframe
is even created, and the child can guarantee that it sets up its
communications before it finishes loading, so the parent can just use the
regular 'load' event on the iframe and the child never needs to wait at
all if it wants to start communicating first.)
And when you do send, you just send a message whose contents are just
a single key saying what API endpoint you want, and a port, which you
then use for all communication for that particular API call.
Just to clarify, I want to see the layer you just outlined be standard
so we can design iframe components and apps to mix and match. This can
be two simple layers on the current messaging: 1) the connection
ceremony, 2) the key/API format.
No reason for it to be standard, just define it as part of the protocol
you are implementing over postMessage().
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: connection ceremony for iframe postMessage communications
On Fri, Feb 10, 2012 at 10:58 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 10 Feb 2012, John J Barton wrote: Just to clarify, I want to see the layer you just outlined be standard so we can design iframe components and apps to mix and match. This can be two simple layers on the current messaging: 1) the connection ceremony, 2) the key/API format. No reason for it to be standard, just define it as part of the protocol you are implementing over postMessage(). Ok, so I define it for my app. You write an iframe. You read my definition and I can load your iframe. Yay! Then Boris write an app. He defines it for his app. You change your iframe to deal with my app and Boris' app. Ok. Then Mark Zuckerberg and Larry Page define apps. Soon you are spending all of your money hiring devs to deal with connection protocols. Then maybe you will have a reason for a standard? jjb -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[FileAPI] Various comments
Hi Arun,
I've read the File API specification, and have a number of comments:
== 1. Introduction ==
Binary Large Object -- a name originally introduced to web APIs in Google
Gears
should use an en dash (—, U+2013) instead of two hyphens.
This paragraph is inconsistent about linking File and Blob to their
definitions.
The example has
if(evt.target.error.name == NOT_READABLE_ERR) {
which probably should be NotReadableError.
== 2. Conformance ==
I think it's surprising that notes are normative, unlike (AFAICT) most
other Web API specifications.
== 4. Terminology and Algorithms ==
The = and = operators don't seem to be used in the specification.
== 6. The Blob Interface ==
The constructor can use the new WebIDL unions types, as
Constructor((ArrayBuffer or Blob or DOMString)[] blobParts,
optional BlobPropertyBag options)
=== 6.1. Constructors ===
The reference to ES5 doesn't seem necessary.
=== 6.2. Attributes ===
On getting, conforming user agents SHOULD return the MIME type of the Blob, if
it is known.
Should be MUST, as we already have if it is known.
=== 6.3. Methods and Parameters ===
The contentType normalization should not special-case undefined; if an
author passes undefined, it should be treated as undefined per WebIDL.
== 7. The File Interface ==
Something's weird with the indentation in the IDL block here.
readonly attribute Date lastModifiedDate;
should be Date?, as it can return null.
== 8. The FileReader Interface ==
=== 8.1. The FileReader Task Source ===
The FileReader interface enables asynchronous reads on individual
Blob objects by firing progress events as the read occurs to event
handler methods on the FileReader, which is an EventTarget
[DOMCore].
This seems to suggest that one can only use the event handler methods
(attributes?), but not add/removeEventListener. Maybe just remove to
event handler methods.
=== 8.5. Reading a File or Blob ===
The result attribute should probably be declared as
| readonly attribute (DOMString or ArrayBuffer)? result;
8.5.7. Blob Parameters
I have no idea what this section is actually supposed to define.
= 8.5.9.1. Event Summary =
… the table below is normative for the events in this specification.
The table should not be normative; the events are already fired in the
respective algorithms.
= 8.5.9.2. Summary of Event Invariants =
The following are normative invariants …
What are normative invariants? This seems to be a list of statements
of fact [1], and as such should be informative.
== 10. Errors and Exceptions ==
=== 10.1. Throwing an Exception or Returning an Error ===
Synchronous read methods throw exceptions of the type in the table
below if there has been an error with reading or .
Or?
The EncodingError cell seems to confusingly use encoding for a concept
related to the length of a data URL and character encodings; I don't see
how these concepts are related.
== 11. A URI for Blob and File reference ==
=== 11.1. Requirements for a New Scheme ===
This section uses |img| and img inconsistently, it should use the former.
=== 11.2. Discussion of Existing Schemes ===
Choosing a name that clarifies the primary use case -- namely, access
to memory-resident Blob resources -- is a worthwhile compromise, and
favors clarity, familiarity, and consistency across the web platform.
En dashes again.
=== 11.3. Definition of blob URI Scheme ===
Opaque strings MUST NOT include any reserved characters from
[RFC3986] without percent-encoding them; these characters MUST be
percent-encoded.
Redundant requirements.
=== 11.6. Lifetime of Blob URIs ===
Should reference the oneTimeOnly argument here.
=== 11.8. Creating and Revoking a Blob URI ===
// Window implements URL;
// WorkerUtils implements URL;
Those statements are out of place, and don't mean what they seem to.
Instead, they would require createObjectURL and revokeObjectURL to exist
on the Window and WorkerUtils interfaces.
=== 11.9. Examples of Blob URI Creation and Revocation ===
Blob URIs are strings that dereference Blob objects, and can persist
for as long as the document from which they were minted using
URL.createObjectURL() -- see _Lifetime of Blob URIs_.
En dash, and the Lifetime of Blob URIs link is broken.
In the example below, two Image elements
Should say |img| elements for consistency.
== 16. References ==
Aryeh Gregor is now also editing DOM Core, which has been renamed to DOM4.
The URL specification is now at
http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html.
The Stream API reference has a broken link.
HTH
Ms2ger
[1] http://ln.hixie.ch/?start=1140242962count=1
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Fri, 10 Feb 2012, Hallvord R. M. Steen wrote: Now, I don't think that was the question Daniel Cheng was asking. If you look at the HTML/XHTML specific instructions for the paste event (in the processing model section: http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll see that it specifies quite a bit of parsing and such. The goals are: * Resolve URLs and links - the page script won't know the base URI to resolve against (on Windows this is in the CF_HTML format's meta data and the page script doesn't get access to it) Well presumably all the URLs should be made absolute in the copy/drag code, not the paste/drop code. The paste/drop code has no context. No parsing needed for that though, the URLs are already resolved in the DOM so it's just a matter of serialising them. * Make it possible to paste HTML from a local application that embeds local resources (img src=file://..) and enable page scripts to process and upload said resources How would you distinguish this case from a hostile app tricking the user into copying HTML that has pointers to sensitive local files? * Optionally do extra privacy or security-related filtering if the UA implementor considers it useful I wouldn't do this via parsing, but DOM filtering. That's the semantic layer. A whitelist DOM filter will ensure that only the stuff the browser thinks is safe can get through. So, I think the question Daniel is asking, is: why don't we process URLs and local resources this way if HTML data is drag-and-dropped to a page? Should this processing be moved to the DnD spec? I guess we could say that HTML dragged from the page could have URLs absoluted in the serialisation. The other stuff doesn't seem necessary. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: connection ceremony for iframe postMessage communications
On Fri, 10 Feb 2012, John J Barton wrote: On Fri, Feb 10, 2012 at 10:58 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 10 Feb 2012, John J Barton wrote: Just to clarify, I want to see the layer you just outlined be standard so we can design iframe components and apps to mix and match. This can be two simple layers on the current messaging: 1) the connection ceremony, 2) the key/API format. No reason for it to be standard, just define it as part of the protocol you are implementing over postMessage(). Ok, so I define it for my app. You write an iframe. You read my definition and I can load your iframe. Yay! Then Boris write an app. He defines it for his app. You change your iframe to deal with my app and Boris' app. Ok. Then Mark Zuckerberg and Larry Page define apps. Soon you are spending all of your money hiring devs to deal with connection protocols. Then maybe you will have a reason for a standard? Why would the connectivity part of this be the hard part? Each of these apps has an entire protocol you'll have to reimplement if you want to connect to it! The connectivity part is trivial in comparison. I'm all for people standardising their postMessage() protocols, though, if they want to. Nothing is stopping people from doing so. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
This discussion seems to raise the issue of what happens to URLs to images (or other embedded objects) that are unresolved but become resolved when pasted. E.g. file:///Users/anton/Library/AddressBook (if that ever made sense) Should these also be sanitized away so that they do not, suddenly become attempted? Paul Le 10 févr. 2012 à 22:36, Ian Hickson a écrit : On Fri, 10 Feb 2012, Hallvord R. M. Steen wrote: Now, I don't think that was the question Daniel Cheng was asking. If you look at the HTML/XHTML specific instructions for the paste event (in the processing model section: http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll see that it specifies quite a bit of parsing and such. The goals are: * Resolve URLs and links - the page script won't know the base URI to resolve against (on Windows this is in the CF_HTML format's meta data and the page script doesn't get access to it) Well presumably all the URLs should be made absolute in the copy/drag code, not the paste/drop code. The paste/drop code has no context. No parsing needed for that though, the URLs are already resolved in the DOM so it's just a matter of serialising them. * Make it possible to paste HTML from a local application that embeds local resources (img src=file://..) and enable page scripts to process and upload said resources How would you distinguish this case from a hostile app tricking the user into copying HTML that has pointers to sensitive local files? * Optionally do extra privacy or security-related filtering if the UA implementor considers it useful I wouldn't do this via parsing, but DOM filtering. That's the semantic layer. A whitelist DOM filter will ensure that only the stuff the browser thinks is safe can get through. So, I think the question Daniel is asking, is: why don't we process URLs and local resources this way if HTML data is drag-and-dropped to a page? Should this processing be moved to the DnD spec? I guess we could say that HTML dragged from the page could have URLs absoluted in the serialisation. The other stuff doesn't seem necessary. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: connection ceremony for iframe postMessage communications
On Fri, Feb 10, 2012 at 10:58 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 10 Feb 2012, John J Barton wrote:
What I meant was just to do this on the receiving side (inside the
iframe), after the onmessage handler has been set up (which we are
assuming happens after the 'load' event for some reason):
parent.postMessage('load', '*');
That way you don't have to depend on the 'load' event, you can just
wait for the message from the inner frame. Then when you get it, you
know you can start sending..
The problem here is that the iframe may issue parent.postMessage('load',
'*) before the parent onmessage handler has been set up.
You can always guarantee that you've set up your handler before you create
the iframe. But, suppose that's somehow not possible. Then you just define
ping as a message you can send to the inner frame, which the inner frame
then responds to with the aforementioned load message.
So now you have the following situations:
- parent is set up first, then opens iframe:
- iframe sends 'load' message when ready
- parent opens iframe, then sets up communications, iframe is quicker:
- iframe sends 'load' message when ready, but it gets missed
- parent sends 'ping' message
- iframe sends 'load' message in response
- parent opens iframe, then sets up communications, parent is quicker:
- parent sends 'ping' message, but it gets missed
- iframe sends 'load' message when ready
In all three cases, the first 'load' message that is received indicates
that the communication system is ready.
Thanks. As a hint for the next person, it seems like the asymmetric
messages (parent 'ping', iframe 'load') is easier than symmetric
('hello'/'ack')
I think there are two more cases. Because the messages are all async,
the 'it gets missed case can be it gets delayed. That causes
additional messages.
- parent opens iframe, then sets up communications, iframe is quicker:
- iframe sends 'load' message when ready, but it gets delayed
- parent sends 'ping' message
- parent get first 'load' message, responds with port
- iframe sends 'load' message in response to 'ping'
- parent opens iframe, then sets up communications, parent is quicker:
- parent sends 'ping' message, but it gets delayed
- iframe sends 'load' message when ready
- iframe gets 'ping' message, sends 'load' message in response
- parent gets 'load' message, responds with port
This doe not change your conclusion, the first 'load' message
indicates ready, but I believe it does mean that a third message
(sending the port) is needed. The 'load' message cannot also send the
port. It also affects when one removes the listener.
(In practice it's usually much simpler than any of this because the parent
can guarantee that it sets up its communications first, before the iframe
is even created, and the child can guarantee that it sets up its
communications before it finishes loading, so the parent can just use the
regular 'load' event on the iframe and the child never needs to wait at
all if it wants to start communicating first.)
Entangling communications setup with iframe 'load' just makes a
complicated problem harder, not simpler. If we can encapsulate the
above logic in a communications library then we don't have to involve
the UI or impact performance delaying load.
jjb
Re: connection ceremony for iframe postMessage communications
On Fri, 10 Feb 2012, John J Barton wrote: I think there are two more cases. Because the messages are all async, the 'it gets missed case can be it gets delayed. That causes additional messages. - parent opens iframe, then sets up communications, iframe is quicker: - iframe sends 'load' message when ready, but it gets delayed - parent sends 'ping' message - parent get first 'load' message, responds with port - iframe sends 'load' message in response to 'ping' Yeah, after receiving the first 'load', the parent should stop listening for more 'load's. - parent opens iframe, then sets up communications, parent is quicker: - parent sends 'ping' message, but it gets delayed - iframe sends 'load' message when ready - iframe gets 'ping' message, sends 'load' message in response - parent gets 'load' message, responds with port That's equivalent to the case of the parent not hooking things up until after the iframe is ready. This doe not change your conclusion, the first 'load' message indicates ready, but I believe it does mean that a third message (sending the port) is needed. Well, probably far more than three messages -- each time you want to start a conversation you would send a port for that conversation. (By conversation I mean an instance of the parent invoking a feature that the iframe provides.) The 'load' message cannot also send the port. Sure. (In practice it's usually much simpler than any of this because the parent can guarantee that it sets up its communications first, before the iframe is even created, and the child can guarantee that it sets up its communications before it finishes loading, so the parent can just use the regular 'load' event on the iframe and the child never needs to wait at all if it wants to start communicating first.) Entangling communications setup with iframe 'load' just makes a complicated problem harder, not simpler. If we can encapsulate the above logic in a communications library then we don't have to involve the UI or impact performance delaying load. Whatever works for you. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: connection ceremony for iframe postMessage communications
On Fri, Feb 10, 2012 at 1:37 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 10 Feb 2012, John J Barton wrote: On Fri, Feb 10, 2012 at 10:58 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 10 Feb 2012, John J Barton wrote: Just to clarify, I want to see the layer you just outlined be standard so we can design iframe components and apps to mix and match. This can be two simple layers on the current messaging: 1) the connection ceremony, 2) the key/API format. No reason for it to be standard, just define it as part of the protocol you are implementing over postMessage(). Ok, so I define it for my app. You write an iframe. You read my definition and I can load your iframe. Yay! Then Boris write an app. He defines it for his app. You change your iframe to deal with my app and Boris' app. Ok. Then Mark Zuckerberg and Larry Page define apps. Soon you are spending all of your money hiring devs to deal with connection protocols. Then maybe you will have a reason for a standard? Why would the connectivity part of this be the hard part? Because the existing information on cross-domain iframe communications is incomplete and written in terms few Web app developers understand, the browser implementations are new and the error messages they emit are puzzling. Solutions for same-domain cases don't work for cross-domain. Async communications is hard to debug. Each of these apps has an entire protocol you'll have to reimplement if you want to connect to it! The connectivity part is trivial in comparison. Probably not, at least to start. Most of the early efforts are just things like setting UI sizes or passing config strings. In the long run the essential difference between a JS library widget and an iframe widget will be asynchronous message passing. Libraries, tools, and languages features are gearing up to help. I'm all for people standardising their postMessage() protocols, though, if they want to. Nothing is stopping people from doing so. public-webapps would seem to be an appropriate venue to begin the discussion, esp. since this is where the expertise on web messaging exists. jjb
Re: connection ceremony for iframe postMessage communications
On 2/10/2012 3:44 PM, John J Barton wrote:
Thanks. As a hint for the next person, it seems like the asymmetric
messages (parent 'ping', iframe 'load') is easier than symmetric
('hello'/'ack')
I think there are two more cases. Because the messages are all async,
the 'it gets missed case can be it gets delayed. That causes
additional messages.
I've been pursuing something like this for transferring content between
frames. That's part of why I was excited to see Web Intents taking off.
I also went with a ping mechanism for messaging.
I recommend taking this thread over to the Web Intents list and
examining it there. I see every reason to want a loose idea of what Web
Intents over postMessage would look like.
They have a shim mechanism for demo purposes and backwards
compatibility, but they don't have the same focus you do (or I do), on
iframe postMessage.
-Charles
