Re: [whatwg] A few hints on html5 -- part 2
On Tue, 16 Dec 2008, Calogero Alex Baldacchino wrote: The removeEventSource() method is provided to remove one instance of a source (one matching URL) per invocation, but no way is defined to know whether other instances are yet listed, or if the operation succeeded. Maybe such method could return a boolean value telling whether the operation was successful, so that, i.e., all matching URLs could be removed at once in a simple iteration calling the method until it returns false. Maybe a remove all method could be considered too. The model used here is similar to addEventListener/removeEventListener. The actual list of event listeners, or event sources in this case, is not exposed, so that different scripts can reuse the same mechanism for their features without clashing with other scripts. If you want to keep track of what has been added, you can do so by wrapping the addEventSource (or addEventListener) method. I guess a single RemoteEventTarget can list several time the same remote source to take advantage of more than one connection (maybe non-http) to fetch different resources and/or to ask for different server-side computations in parallel; however, it might be helpful to define either a mechanism to remove a precise source (i.e. passing an index or the alike, not just the URL) instead of removing a source on a per enter position basis (that is, the first encountered is removed, as could be thought) or a precise choice algorithm (i.e., skipping an active URL), since without neither a precise targeting nor a precise algorithm a somewhat user agent could remove the wrong url upon request, and so closing for instance a connection with a pending get operation: one of a RemoteEventTarget message event handlers could receive an end event and try and close its connection, but the implementation, by mistake, could remove a source URL used by another handler waiting for a response, or the method could be invoked from a piece of code outside any handler, and so the choice might become more difficult. Otherwise, an algorithm should be defined to switch the communications from a closed source to another still active. We don't really want to optmise for the case of the same URI being used twice, as that is an unlikely scenario other than when there is a bug -- thus the current behavior. According to the previous hint, let me suggest the following: - a streamed event should be associate to a numerical index [...] Since this is an edge case that doesn't really have a use case, I don't really want to add features to handle it. a remove source as possible task is a task delegated to remove the source URL from the list of event sources and to close the related connection as soon as any pending event is completely received and dispatched to every listening handler and no message has been post to the remote server (otherwise wait for the response event); a remove source immediately task is a task performing the same operation but without waiting for pending events: as soon as the task is executed, the event source is eliminated. This can be done now; just wait for that last event and then unregister the event source. If there's an infinite stream of events, and thus no last event, then it doesn't matter if you didn't get a whole event. Thus, the current model. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] A few hints on html5
On Tue, 16 Dec 2008, Calogero Alex Baldacchino wrote: About the cross-document messaging Let's consider the following scenario. A somewhat productivity suite (or any sort of web applications collection) is made up of a few different top-level/auxiliary browsing contexts - let's call each one a module - eventually from different origins, and exploits cross-document communications to some extent, i.e. to delegate some computations or some shareable communications with a remote server; each module is independent and can instantiate the proper auxiliary module(s). Here we are: as far as the modules are instantiated as auxiliary browsing contexts of one other module (i.e. through a call to 'window.open()'), communications are easily established, but what if any module is instantiated by the user as a separate top-level browsing context, i.e. opening a new tab or window and recalling the module document from a bookmark? I'd suggest the following: - a mechanism is established to get access, without any restriction, to every browsing context for which the user agent can individuate a non-empty, non-null, non-undefined name attribute, at least with the capability to let cross-origin access to the postMessage() methods. For instance, the specifications could clearly state that the Window open() method must return an existing window reference with the specified name when invoked with an empty string or null as URL argument, with no security restriction (security restrictions should apply just to the returned window object properties). When more than one browsing context share the same name, actual rules for choosing a browsing context given a browsing context name should apply to choose a first result, without checking if current browsing context is allowed to navigate that browsing context; it might be helpful to get instead a list of all browsing contexts with the same name, obtained as follow: a Window object is created as a pseudo unit of browsing contexts, so that each browsing context is reachable both by invoking the XXX4() method and by accessing the frames property; each browsing context is wrapped in a Window object with 1)accessible postMessage() methods, calling the wrapped window ones, 2)an accessible parent attribute referring to the grouping Window object, 3)a self attribute referring to the wrapped object, accessible if access to the wrapped object is allowed by security restrictions, 4) access denied, without any exception/error arising, to any other method/attribute; the first member of the group (i.e. the object returned by calling XXX4(0) on the grouping Window) is the wrapper for a Window object determined by the rules for choosing a browsing context given a browsing context name (i.e. the most recently opened, or focused, or the most related with the open() method caller browsing context) and is returned. That seems like an exceedingly high level of complexity to address a very odd corner case. I would recommend instead using shared workers to communicate between these windows -- after all, it is likely that such an application would need a shared worker anyway to handle things like synchronising shared databases with the server. Anyway, going through a shared worker you could negotiate a MessagePort communication channel from the two end points. Also, note that the spec doesn't disallow browsers from doing what you say with respect to giving all named frames access to all other named frames, but it does allow user agents to limit it. This is because we received requess from user agents asking for that to be allowed to be limited to handled a set of legacy applications that otherwise cause havoc in multiple-window environments. - optionally, a few postMessageToAll() methods (with about the same arguments of the postMessage() ones) could be considered to let any browsing context to communicate, through its own Window interface, either to any other browsing context (eventually allowing communications from current browsing context as source, see below), or to every browsing contexts constrained by the same name (passed as, let's say, first argument), or to every browsing contexts with the same domain (specified, let's say, as the second argument). That's an interesting idea, probably something to consider in a future version based on our experience with what is currently specified. Let's consider another scenario. A site (perhaps a blog) embeds content from a forum (or any social network), and uses script code to connect to the remote server and keep it's content up to date, but also to notify the user about any changes in other contents the remote server holds as subscribed (this scenario can be extended to mail notifications in the previous example of a productivity suite, or to a groupware). When the user navigates other documents from the site in different
[whatwg] A few hints on html5 - part 1
Let me suggest a few hints on html5 specs, maybe some hints will be minor or less important, maybe some others might be useful for a somewhat next version of these specifications. Let me also apologize if the following points have been yet discussed and I'm missing such discussions, or if I've misunderstood any part of the specs. -- this was a longer message, but the list bot refused it, thus I'm splitting it into a few messages (and thus the subject, part 1 etc.) First, maybe the less relevant: in the Script execution contexts section a request is made for some couple of terms other than with/without script. OK, let me suggest scriptable/unscriptable or reachable/unreachable by script, for instance. Just a simple hint, no more. The former suggests me a possible (partial) solution for the events section question about events handling for non active or browsing context-less documents: being script execution not allowed in such situations, we could state that any event exclusively thought for script interaction should never fire, unless any valid motivation arises to let the event fire and be dispatched to the corresponding handler(s), and in such a case the whole mechanism of deciding whether script execution must be allowed or not should be revisited. Otherwise, if any script related resources are thought to be kept alive in a somewhat frozen state (in example, in a previously active document, a connection buffer with last received, not yet elaborated content, the connection itself to be re-established, or its status), then any related event could fire and be frozen in a pending state, or just be frozen or pending, meaning in a before firing state, ready to fire (and be dispatched) as soon as the document enters a scriptable state (i.e. becomes active or gains a browser context). Furthermore, the event loop and task queue definitions suggests me that a somewhat user agent could implement a sort of all-in-one mechanism to handle together (maybe for an improved interaction?) both implementation-related and script-related events, i.e. queueing together both types of event (or the related tasks), with a somewhat precedence rule between them, or even, in some cases, the very same event/task to be first handled by the underlying implementation, then passed (wrapped?) to the script specific mechanism (for instance, when a document, or an object inside a document, is fully loaded, a native load event is generated to increment/complete the document rendering and then it is wrapped and sent to any script related handler). In such a case, the specification could establish, for clearness sake, that only implementation related events must fire, if meaningful for the implementation in a non-scriptable context (an inactive or context-less document), while any script related event (even the same wrapped event, after the underlying elaboration) must either be discarded (it does not fire) or be frozen (if applicable) for a further possible resuming. Might such a clarification be helpful for such an (unrealistic? strange? possible?) implementation, in order to avoid or reduce confusion or possible side effects? Anyway, such considerations might perhaps either be left to the user agent implementation, or be deferred to a next version of html5 specs... For the How do we allow non-JS event handlers? concern, let me distinguish two different cases: 1) an event handler content attribute is set in the markup: Let's assert it must conform to the ECMAScript FunctionBody production rules by default, unless another language is stated elsewhere as the default scripting language for the whole document or for a particular element. As for the whole document, a meta tag could be used, such as 'meta http-equiv = Content-Script-Type content = a_valid_scripting_mime_type /' or the alike. If the declared mime-type is not supported, it could be defaulted to the ECMAScript one. For the element by itself, an attribute could be added both to the markup and the DOM, either to describe a script language valid for all the script content attributes (i.e. 'defaultscript=appropriate_mime-type'), or to define a list of valid mime-types (i.e. 'acceptedscripts=first_mimetype;second_mimetype'). In the latter case, for each parsed script content attribute, the first declared mime-type should constrain the production rules, or be skipped if not supported, using the next mime-type upon failure or after skipping an unsupported one; if all sequentially applied production rules fail, let a SYNTAX_ERR arise (or any other appropriate error/exception); if no mime type is supported, the default script language rules are applied (if not listed, that is, yet tried in the previous step), and if even this fails, let an appropriate error/exception (maybe the SYNTAX_ERR itself) arise. For the sake of a graceful degradation, the script content attribute whose production has failed could be
[whatwg] A few hints on html5 -- part 2
About the RemoteEventTarget interface The removeEventSource() method is provided to remove one instance of a source (one matching URL) per invocation, but no way is defined to know whether other instances are yet listed, or if the operation succeeded. Maybe such method could return a boolean value telling whether the operation was successful, so that, i.e., all matching URLs could be removed at once in a simple iteration calling the method until it returns false. Maybe a remove all method could be considered too. I guess a single RemoteEventTarget can list several time the same remote source to take advantage of more than one connection (maybe non-http) to fetch different resources and/or to ask for different server-side computations in parallel; however, it might be helpful to define either a mechanism to remove a precise source (i.e. passing an index or the alike, not just the URL) instead of removing a source on a per enter position basis (that is, the first encountered is removed, as could be thought) or a precise choice algorithm (i.e., skipping an active URL), since without neither a precise targeting nor a precise algorithm a somewhat user agent could remove the wrong url upon request, and so closing for instance a connection with a pending get operation: one of a RemoteEventTarget message event handlers could receive an end event and try and close its connection, but the implementation, by mistake, could remove a source URL used by another handler waiting for a response, or the method could be invoked from a piece of code outside any handler, and so the choice might become more difficult. Otherwise, an algorithm should be defined to switch the communications from a closed source to another still active. According to the previous hint, let me suggest the following: - a streamed event should be associate to a numerical index representing either the relative position (i.e. indicating it's the Nth occurrence) or the absolute position of the source URL in the RemoteEventTarget list of event sources; for this purpose, the last event id attribute should be considered unreliable; - a removeEventSource() method variant is provided accepting the index as a second parameter; - when the removeEventSource is invoked without the index argument (i.e. to iteratively remove all occurrences), the following algorithm is applied: 1) if the URL resolution fails return false and abort these steps; 2) pick the first occurrence of src argument in the list of event sources, if any; 3) if no occurrence has been found return false and abort these steps; 4) if a remove source as possible task or a remove source immediately task has been tailed for src, stop execution and return true; 5) queue a remove source as possible task and return true; - when the removeEventSource is invoked with the index argument follow the previous steps but change step 2) and 3) as follow: 2) pick the source occurrence in the list of event sources corresponding to the index argument and compare it with src argument; 3) if comparison fails return false and abort these steps; a remove source as possible task is a task delegated to remove the source URL from the list of event sources and to close the related connection as soon as any pending event is completely received and dispatched to every listening handler and no message has been post to the remote server (otherwise wait for the response event); a remove source immediately task is a task performing the same operation but without waiting for pending events: as soon as the task is executed, the event source is eliminated. - a couple of removeEventSourceNow() methods is provided with the same characteristics of the previous, but queueing a remove source immediately task. - if needed, an appropriate task source is provided. Regards, Alex -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Tom Raider Anniversary ora sul tuo cellulare! Entra in azione! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8277d=16-12
[whatwg] A few hints on html5 - part 3
About the cross-document messaging Let's consider the following scenario. A somewhat productivity suite (or any sort of web applications collection) is made up of a few different top-level/auxiliary browsing contexts - let's call each one a module - eventually from different origins, and exploits cross-document communications to some extent, i.e. to delegate some computations or some shareable communications with a remote server; each module is independent and can instantiate the proper auxiliary module(s). Here we are: as far as the modules are instantiated as auxiliary browsing contexts of one other module (i.e. through a call to 'window.open()'), communications are easily established, but what if any module is instantiated by the user as a separate top-level browsing context, i.e. opening a new tab or window and recalling the module document from a bookmark? I'd suggest the following: - a mechanism is established to get access, without any restriction, to every browsing context for which the user agent can individuate a non-empty, non-null, non-undefined name attribute, at least with the capability to let cross-origin access to the postMessage() methods. For instance, the specifications could clearly state that the Window open() method must return an existing window reference with the specified name when invoked with an empty string or null as URL argument, with no security restriction (security restrictions should apply just to the returned window object properties). When more than one browsing context share the same name, actual rules for choosing a browsing context given a browsing context name should apply to choose a first result, without checking if current browsing context is allowed to navigate that browsing context; it might be helpful to get instead a list of all browsing contexts with the same name, obtained as follow: a Window object is created as a pseudo unit of browsing contexts, so that each browsing context is reachable both by invoking the XXX4() method and by accessing the frames property; each browsing context is wrapped in a Window object with 1)accessible postMessage() methods, calling the wrapped window ones, 2)an accessible parent attribute referring to the grouping Window object, 3)a self attribute referring to the wrapped object, accessible if access to the wrapped object is allowed by security restrictions, 4) access denied, without any exception/error arising, to any other method/attribute; the first member of the group (i.e. the object returned by calling XXX4(0) on the grouping Window) is the wrapper for a Window object determined by the rules for choosing a browsing context given a browsing context name (i.e. the most recently opened, or focused, or the most related with the open() method caller browsing context) and is returned. - optionally, a few postMessageToAll() methods (with about the same arguments of the postMessage() ones) could be considered to let any browsing context to communicate, through its own Window interface, either to any other browsing context (eventually allowing communications from current browsing context as source, see below), or to every browsing contexts constrained by the same name (passed as, let's say, first argument), or to every browsing contexts with the same domain (specified, let's say, as the second argument). Let's consider another scenario. A site (perhaps a blog) embeds content from a forum (or any social network), and uses script code to connect to the remote server and keep it's content up to date, but also to notify the user about any changes in other contents the remote server holds as subscribed (this scenario can be extended to mail notifications in the previous example of a productivity suite, or to a groupware). When the user navigates other documents from the site in different browsing contexts, each one is aware of the others (perhaps establishing a connection through a call to postMessageToAll, or by getting a reference by name); to avoid increasing the number of connections per server, any successive document navigated as a standalone browsing context (after the first or after a certain number) won't connect to the remote server, but will communicate with the document having an active remote connection. That is: the first navigated document maintains a remote connection and receives notifications as remote events; if it is fully active, the notifications are shown to the user, otherwise a message is sent to any other known document capable to handle the notification, hoping one is fully active; the first document becoming fully active handles the messages and notifies to the other documents that any required operation has been performed; when the remote events handling document(s) are to become no more active (i.e. they unload), a message is sent to the remaining documents so they can decide (somehow) who's the next dispatcher. The above could
[whatwg] A few hints on html5 - part 4
Miscellaneous The Window interface open method accepts a features argument for historical (and backward compatibility) reasons, which, as stated, has no actual effect. I was considering the opportunity, instead, of maintaining the old functionality as an alternative and redundant implementation of the make application state. That could work this way: any browser feature set disabled in the features string is disabled and not shown in the newly opened window, BUT, a somewhat element, clearly being part of the browser application, is provided to let the user enable any hidden feature (either altogether, or one by one), so to reset the normal application condition; when a browser interface component is hidden, any related key binding is freed from usual capture, and redirected to the window active document, so that a full standalone behaviour is transparently shown to the user (the reset element should never be disabled), while when that component is re-enabled its normal behaviour is re-established; if the application is going full-screen the user is clearly advised about this and allowed to block the operation (in the case the operation is allowed, the reset element should become floating and maybe half-transparent -- I was thinking on a possible, future 2D or even 3D web based game...). - Current draft provides a few overloaded methods (like postMessage() variants) differing for the number, type and order of their attributes. A first concern could arise on the choice to overload functions in IDL interfaces, since any of the possible supported/supportable script language could not provide such a feature, making implementation more difficult; however, this could be a minor concern, both since a script with C-like syntax (as most are) usually let functions be overloaded, one way or another, and because a different kind of language, not providing such, could overcome the problem by defining methods with slightly different names and binding them to the appropriate interface (but this would lead maybe to a longer learning period and to possible, successive even greater difficulties whether such names would clash with future standard names). Maybe the parameters order and number could be another concern, since a script language could (like JavaScript does) allow functions overloading by varying the number of passed arguments, without caring about arguments types, and leaving to the inner code any checking and choice of what to do (that's closer to a C++ function declaration with default arguments, than to a full overload); this is not a real problem, but perhaps a little improvement in current specs might result from changing the arguments order so that the arguments list of an overloaded method's two variant, when compared, is equal for the first 'x' arguments, where 'x' is the length of the shortest list, since this could reduce the translation work the script engine must do before calling the underlying implementation (i.e., it could be a slightly easier casting of the arguments to their correspondent native types, without any previous checking for the right type, before calling the interface native implementation - the point is: a check is likely to be done by the casting routine(s), so couldn't it be avoid before casting?). Furthermore, any language missing the overload semantics could expose just one method with the whole list of possible arguments, corresponding to the idl declared method with the longer list, and I think that defining idl methods with some care for arguments order would be a neater choice. - Current browsers provides facilities to parse xml code (either the DOMParser object or a DOM Load and Save Parser). All fail with html tag soup, so if for any reason a somewhat string of html code must be parsed to manipulate its DOM representation before taking any action, a workaround must be found (i.e. calling document.implementation.createHTMLDocument() and somehow inserting the string into such fake document, then getting the DOM structure - this could be quite unreliable too, as a parsing alternative, if any script code in that string were executed). Since one of the goal of html 5 specifications is the definition of a standard parser, with a standard parse error management, maybe the opportunity of exposing an html-specific parser (skipping script execution) through the DOM might be considered. - Current draft states a script element set through the innerHTML property is not executed at all, while it is when added by calling document.write() (what about insertAdjacentHTML()?). However, I think that allowing script execution in the former case would made of the innerHTML property a truly live one, with some possible benefit: i.e. it could be a way to insert new script elements into the document head section from outside the head element (i.e. from an event listener on an eventsource, to dynamically
