Re: [whatwg] Stability of tokenizing/dom algorithms
Edward Z. Yang: Sounds good, since HTML4 is a strict subset of HTML5 (correct me if I'm wrong?) Ian Hickson: Mostly, yes. (There are exceptions, but they're not things you'd really want to be using anyway, e.g. obscure SGML features.) Note though that it's not possible to write a document that is both valid HTML 4 and HTML 5, since they both require a different DOCTYPE to be used. That's right, Cameron, but you could change nothing more than the DOCTYPE in order to validate if you have choosen a right subset of HTML 4.x. iñigo -- Cameron McCormack ≝ http://mcc.id.au/ -- Iñigo Medina García Tecnología http://www.toprural.com Tu guía de turismo rural
Re: [whatwg] Thoughts on HTML 5
Am Dienstag, den 16.12.2008, 14:22 + schrieb Philip Taylor: On Tue, Dec 16, 2008 at 2:15 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: As I said, invalid input should be rejected in the first place. When I write a blog post, I usually catch errors like this when I click on the preview button and its all yellow. But you still accept user input that can lead to ill-formed output, like in http://blog.dieweltistgarnichtso.net/?s=%ef%bf%bf :-) (That particular case probably doesn't affect anyone other than the user who enters that URL, but it's a pain whenever the user input is displayed back to other users or shown in admin interfaces, and very few people seem to implement it correctly in practice.) Please, its Wordpress ! Those are the people that use eval() when parsing input. I already have hacked a bit and will no doubt do something about input as soon as my HTML5 theme based on sandbox is ready. In the meantime, don't input this character in the comments, I've not really thrilled to see that stuff implode. Oh and btw, my own web app *will* reject input and / or normalize it (whenever it is done, with which I mean: I first have to sort out some issues with the database ...). Greetings -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Thoughts on HTML 5
On Mon, Dec 15, 2008 at 8:36 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: You're not Nicholas. We don't know if that is what Nicholas expects his HTML to do or if he is expecting something else. In absence of an example, I can't do much more than guess. I cannot expect your assumptions to be correct. Well, of course, but you sent the message to the entire group, so you should be ready for answers from the whole group. ^_^ You've not stated how creating invalid HTML can control scripts. Having an interest in scripting, I would like to know how this works. Dude, come on. You're trying to poison the dialogue here. The point Instead of a complaining about my intentions, why don't you post an example that shows the problem (demonstrate need), how the problem is overcome (the invalid HTML solution), and what browsers actually do? Sorry, I thought I was demonstrating it, but I guess I was being too general. An example I know of off the top of my head is the jQuery Validation plugin[1]. If you can uniquely identify the elements in your form (either through #id or other structural means) and can place scripts (not always possible for end-users of a CMS application or something), you can tell the plugin exactly how to validate each form element when you first invoke it, through the script. If either of these are false, though, you can instead place the attributes on the element itself, and the script will read them off while it's executing. Many of the common ones can be easily and usefully embedded in @class (giving an element a class of required, frex, can also help with styling), but using the more complex validation routines in @class requires you to embed JSON, which is a horrible hack (as the parser doesn't recognize this and just tokenizes it as multiple oddly named classes). The script reads the entire class attribute as a string and parses this effectively, but it can have unintended consequences. Instead, you can embed these more complex routines in custom attributes. jQuery has a plugin that allows easy access to these in a cross-browser way (the Metadata plugin[2]). Doing this allows you to embed complex validation instructions on the elements themselves in an easily human-readable and human-writable format, with an absolute minimum of side-effects (generally, *no* side effects). I've seen code that has invalid attributes. These attributes won't always have the same effect as the author wanted them to. Not all authors expect the same thing from their invalid HTML. Recent c.l.js discussions have included examples of page author using a named element where that element does not support the name attribute, e.g. span name='fred'. The author had expected the element to be included with getElementsByName, but it wasn't. (not the first time someone has expected nonstandard behavior from an attribute). I've seen other uses of invalid HTML that did what the author wanted to in most cases. This is (one reason) why I objected to using the blanket term invalid HTML, because it covers far more than what we're talking about here. *I*, and Nicholas I'm sure, are referring solely to using *custom* attributes. In this example, you're talking about hacking an existing attribute, and being surprised at the outcome. (I find it likely that the author was trying to use @name as a replacement for @class, hoping to lean on the already-implemented getElementsByName function rather than rolling his own getElementByClass). As to how custom attributes can help control scripts, look into any decent javascript plugin. Many of them utilize some form of metadata What is a javascript plugin? The param element is designed for associating data with a plugin, such as a swf movie. Is this an allusion? I apologize; I thought the term was widespread enough. When using things like the jQuery library, additional scripts built on top of it are termed 'plugins'. In general, though, the case for custom attributes is identical to the case for JS expando attributes, which *have* been around for a long time. It can be very useful for a script to store arbitrary data on an element, and the simplest way to do this in many cases is by creating a new expando attribute. Custom attributes is nothing more than a way to embed this information in the static HTML as well, so that it can be authored and carried around independently of the script, or provide good 'initial values' to the script. And again, as stated previously, this discussion *has* already been settled. We have the data-* attributes as an officially blessed way to provide custom attributes on HTML, and as a recommended way to add expando attributes via JS. What I'm talking about is only 'invalid HTML' in HTML4 - it's perfectly valid html5 now. 1: http://bassistance.de/jquery-plugins/jquery-plugin-validation/ 2:
Re: [whatwg] Web Workers Draft
On Tue, 9 Dec 2008, Douglas Mayle wrote: I was taking a look at the Web Workers Draft ( http://www.whatwg.org/specs/web-workers/current-work/ ), and I couldn't find any mention of cross domain workers. I've read a bit about relaxing domain restrictions on documents, but worker's don't seem to have a document object. I also see the details about location, but I haven't found any information about relaxing the origin. Is there any plan to allow cross-domain workers? I'm currently using them in Gears to enable a shared storage solution, and would like to be able to migrate one day to official standards. On Tue, 9 Dec 2008, Douglas Mayle wrote: After sending this, it occurs to me that at the worst, I could have a separate document to marshal access to a cross domain web worker. It's an extra hoop to jump through, but at least it would work. Currently, scripts run in the origin of their main script, and the main script of a worker has to be same-origin with the creator of the script. We might change this once we have implementation experience, but in general having an iframe doesn't seem like a great burden for now. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[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
Re: [whatwg] Thoughts on HTML 5
2008/12/16 Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net Am Dienstag, den 16.12.2008, 14:32 +0100 schrieb Giovanni Campagna: (The same behaviour can be achieved also with a @namespace rule, putting non-standard attributes in an application-specific namespace) Since data attributes do not exist as of yet, I believe people would use XML for namespaces, so I somehow don't see your problem. 1) data attributes are not standarized and the dataset DOMStringMap is not present, but if you try using them with domCore interfaces they should work (i haven't tested though) 2) XML serialization is much more difficlut to implement than old HTML, and, as i said before, in many cases it is not implementable at all: probably a company which hosts user-generated content such as blogs or forums won't like that no browser can display his pages because someone wrote invalid html even the most experienced can mis-type code, and in that case the only way to solve is to manually edit source using a plain text editor, which is not possible with user-generated content 3) the dataset DOMStringMap is a quite useful way to enumerate attributes explicitly marked as application data
Re: [whatwg] Thoughts on HTML 5
Am Dienstag, den 16.12.2008, 14:32 +0100 schrieb Giovanni Campagna: (The same behaviour can be achieved also with a @namespace rule, putting non-standard attributes in an application-specific namespace) Since data attributes do not exist as of yet, I believe people would use XML for namespaces, so I somehow don't see your problem. -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Thoughts on HTML 5
Am Dienstag, den 16.12.2008, 15:38 +0100 schrieb Giovanni Campagna: Browser assume that author knows XML because he's put an application/* +xml mime type. On the other hand, this assumption cannot be done for blogger, who aren't expected to know XML / XML 1.1 / XHTML 1.0 / HTML5 specs (they're not expected to know about what or w3c either) Then they shouldn't write XHTML in the first place ... there *are* some good autoformatters which handle stuff for you (think: newline - br/, two newlines - paragraph). Also, WYSIWYG editors should *not* gave you the oppontuniy to mess up your code. Could not save you post, invalid XML markup (Mismatched end tag, expecting img, found /p) See W3C XML1.1 specification (link to XML spec) for further information about this. Or just Not well-formed (attribute values must be encoded in double quotes) The current error messages are crap, that is totally right. They could certainly be more user-friendly. You have no page, thus no way to edit! The admin interface should be always well-formed, having the offending portion in a textarea (or similar) for easy editing and an iframe for viewing. -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Thoughts on HTML 5
2008/12/16 Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net Am Dienstag, den 16.12.2008, 15:38 +0100 schrieb Giovanni Campagna: Browser assume that author knows XML because he's put an application/* +xml mime type. On the other hand, this assumption cannot be done for blogger, who aren't expected to know XML / XML 1.1 / XHTML 1.0 / HTML5 specs (they're not expected to know about what or w3c either) Then they shouldn't write XHTML in the first place ... there *are* some good autoformatters which handle stuff for you (think: newline - br/, two newlines - paragraph). Also, WYSIWYG editors should *not* gave you the oppontuniy to mess up your code. In a forum you usually write BBCode (or similar), that is server-side parsed with the same hacks as the HTML5 parser, while in other context it is definitely more powerful to write directly HTML Secondly, this: pClick on my icon a href=somewhere.htmlimg width=88 height=15 src=myicon.png/p is valid HTML although not valid XHTML. Do you mean this with messing up your code? Could not save you post, invalid XML markup (Mismatched end tag, expecting img, found /p) See W3C XML1.1 specification (link to XML spec) for further information about this. Or just Not well-formed (attribute values must be encoded in double quotes) The current error messages are crap, that is totally right. They could certainly be more user-friendly. Have you got any ideas? You have no page, thus no way to edit! The admin interface should be always well-formed, having the offending portion in a textarea (or similar) for easy editing and an iframe for viewing. In any case, it is not allowable for companies to have their site down because of an user, even for just few minutes (if your lucky and find bug immediately)
Re: [whatwg] Terminate a Worker algorithm
On Tue, 16 Dec 2008, Alexey Proskuryakov wrote: Dec 16, 2008, в 9:43 AM, Ian Hickson написал(а): 1) The algorithm assumes that a WorkerGlobalScope exists, and doesn't specify what happens if it is invoked before WorkerGlobalScope is created (e.g. if the script is still being loaded, or the scope is being created, but Worker.terminate() is called from JS). I think that the right behavior is to re-invoke the algorithm after the scope is created, because it may be too late to prevent its creation. It can't be invoked before the WorkerGlobalScope is created. The WorkerGlobalScope is created before the constructor returns the Worker object. This means that creating a Worker would involve running a nested run loop, waiting for WorkerGlobalScope to be created in another thread/process. I think that WorkerGlobalScope needs to be created asynchronously. The above is the only observable difference with synchronous creation that I could find, so I think that requiring synchronous operation is unnecessary. Sure, implementation-wise there is a race condition to take care of. But the behavior to implement is well-defined. 2) Events in WorkerGlobalScope event queue are dropped when terminating a worker, but messages posted to Worker are not. I think that the expected behavior is that after calling Worker.terminate(), no messages will be dispatched to worker's event listeners. Once 'closing' is set to true, the queue discards any additional tasks. There is no closing flag on the Worker object, it's only defined on WorkerGlobalScope as far as I can see. Oh I see what you're saying. Sorry, I misunderstood. I guess we could empty the queue of messages once a worker is terminated... Ok, done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Error propagation in child workers
On Thu, 27 Nov 2008, ben turner wrote: I just got around to fixing the error handling in our worker implementation and realized that the spec is a little vague here, especially when workers are created within workers. This is what we have now, and Jonas and I both find it intuitive and useful: Assuming we have a page that creates a worker (let's call this worker the parent), and it creates a new worker (the child). First, we currently use a MessageEvent object for our 'error' events where the 'data' property contains a string representing the exception, but we don't really like that. We'd like to propose that we use a new type of event, ErrorEvent, that looks like this: interface ErrorEvent : Event { readonly attribute DOMString message; readonly attribute DOMString filename; readonly attribute unsigned long lineno; } How do you feel instead about using the same mechanism on Worker objects as we currently use on Window for error handling? Specifically, window.onerror is called as a function with three arguments when an error occurs. I'm suggesting that when a worker has an unhandled exception, we fire Worker.onerror outside the worker, again with three arguments (message, script url, line number). If the function return false, then the error reporting is quenched; otherwise, it is reported in the warning console. For shared workers, we could either support this in the same way, or always report the errors to the console and not have a way to catch them. Or, we could not have any ways to catch these unhandled exceptions at all. I'm interested in feedback from other implementors here -- is this something you are interested in? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
Am Dienstag, den 16.12.2008, 15:02 +0100 schrieb Giovanni Campagna: 2) XML serialization is much more difficlut to implement than old HTML, and, as i said before, in many cases it is not implementable at all: probably a company which hosts user-generated content such as blogs or forums won't like that no browser can display his pages because someone wrote invalid html It is not hard to reject input if its not well-formed. If browsers can do it, why shouldn't web apps be able to ? even the most experienced can mis-type code, and in that case the only way to solve is to manually edit source using a plain text editor, which is not possible with user-generated content As I said, invalid input should be rejected in the first place. When I write a blog post, I usually catch errors like this when I click on the preview button and its all yellow. -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Thoughts on HTML 5
Am Dienstag, den 16.12.2008, 14:14 +0100 schrieb Giovanni Campagna: Maybe so-called invalid HTML attributes are not the only solution, but in my opinion it is a simple way to embed metadata within any element. What metadata are you talking about ? Microformats already exist. Personally I prefer the latter (XML) solution, but there are context where using XML serialization is not possibile (for example in user generated content) so there is a definite need for a SGML way to add custom attributes without conflicting with standards. HTML5 is not derived from SGML anymore. Greetings -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Thoughts on HTML 5
2008/12/16 Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net Am Dienstag, den 16.12.2008, 14:14 +0100 schrieb Giovanni Campagna: Maybe so-called invalid HTML attributes are not the only solution, but in my opinion it is a simple way to embed metadata within any element. What metadata are you talking about ? Microformats already exist. I'm talking of any data that is related semantically to element and should not be printed to the user or interact with default browser behaviour. There is an example in the HTML5 spec of an element representing a spaceship in a browser game, with data- attributes to provide fire / armour values Imagine the spaceship has class spaceship, then i can write the following css: .spaceship:after { display:block; height: 10px; width: attr(data-attack,px); background-color: red; color: white; text-align: center; content: Attack value attr(data-attack,string); } .spaceship:after:after { display:block; height: 10px; width: attr(data-defence,px); background-color: green; color: white; text-align: center; content: Defence value attr(data-defence,string); } (The same behaviour can be achieved also with a @namespace rule, putting non-standard attributes in an application-specific namespace) Personally I prefer the latter (XML) solution, but there are context where using XML serialization is not possibile (for example in user generated content) so there is a definite need for a SGML way to add custom attributes without conflicting with standards. HTML5 is not derived from SGML anymore. My fault, I meant the HTML serialization of HTML5. Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
Maybe so-called invalid HTML attributes are not the only solution, but in my opinion it is a simple way to embed metadata within any element. Imagine that such markup is then passed to a web application through XHR. In that case scripts aren't parsed and executed. In this case you have three ways to attach a behaviour: 2) on-event standard attributes (but they not performant since they're parsed every time the event fires and the cannot include chars like or , they need to be escaped) 3) assigning a class and some metadata using data-, then getElementsByClassName and addEventListener The same with CSS: you can use style for each element or data- attributes queried by attr() For what concerns browser support, these attributes are at all part of the DOM tree, so I can pass their names to getAttribute and setAttribute, but they don't get any special interface. It's the same in the XML serialization with different application-specific namespaces: they use only DOMAttr interface defined in DOM3Core and they're not part of any infoset (not part of ID list or NAME list) Personally I prefer the latter (XML) solution, but there are context where using XML serialization is not possibile (for example in user generated content) so there is a definite need for a SGML way to add custom attributes without conflicting with standards.
Re: [whatwg] Stability of tokenizing/dom algorithms
Ian Hickson wrote: Mostly, yes. (There are exceptions, but they're not things you'd really want to be using anyway, e.g. obscure SGML features.) Are these exceptions, by any chance, documented somewhere? Cheers, Edward
Re: [whatwg] Thoughts on HTML 5
I tried following this thread but I can't find what I would need to change in the spec to address the feedback so far. If this feedback relates to requests for the spec, please elaborate on exactly what it is that should change -- thanks! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stability of tokenizing/dom algorithms
On Tue, 16 Dec 2008, Edward Z. Yang wrote: Ian Hickson wrote: Mostly, yes. (There are exceptions, but they're not things you'd really want to be using anyway, e.g. obscure SGML features.) Are these exceptions, by any chance, documented somewhere? http://wiki.whatwg.org/wiki/Differences_from_HTML4 http://dev.w3.org/html5/html4-differences/ -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Error propagation in child workers
Ian Hickson wrote: On Thu, 27 Nov 2008, ben turner wrote: I just got around to fixing the error handling in our worker implementation and realized that the spec is a little vague here, especially when workers are created within workers. This is what we have now, and Jonas and I both find it intuitive and useful: Assuming we have a page that creates a worker (let's call this worker the parent), and it creates a new worker (the child). First, we currently use a MessageEvent object for our 'error' events where the 'data' property contains a string representing the exception, but we don't really like that. We'd like to propose that we use a new type of event, ErrorEvent, that looks like this: interface ErrorEvent : Event { readonly attribute DOMString message; readonly attribute DOMString filename; readonly attribute unsigned long lineno; } How do you feel instead about using the same mechanism on Worker objects as we currently use on Window for error handling? Specifically, window.onerror is called as a function with three arguments when an error occurs. I'm suggesting that when a worker has an unhandled exception, we fire Worker.onerror outside the worker, again with three arguments (message, script url, line number). If the function return false, then the error reporting is quenched; otherwise, it is reported in the warning console. I talked with Ben about this. We don't really feel strongly either way, so changing it is fine. That said, we already have the other behavior implemented so unless anyone feels strongly I suggest we keep it. I do agree there would be more consistency with window.onerror if we went the other way, but there would be less consistency with the other Worker.on*. In any case, I do think that the bubbling mechanism should remain. I.e. that if the main window creates worker A, which creates a child worker B, and an error happens in B, then the following should happen: 1. A should be first given a chance to handle the error using B.onerror 2. If A doesn't handle the error the error is forwarded to the main window by calling A.onerror 3. If the main window doesn't handle the error, the error gets reported to any developer-error-console mechanism that the UA has (if any). / Jonas
Re: [whatwg] Preventing nested click() calls
On Mon, 10 Mar 2008, Antti Koivisto wrote: WebKit, Firefox and IE all implement a protection mechanism against re- entering click() on the same element: input type=checkbox onclick=this.click() WebKit (and based on testing Firefox) make click() a no-op when invoked as a result of a click event generated by calling click() on the same element. For IE this seems to be true even for user generated click events. On Fri, 14 Mar 2008, Erik Arvidsson wrote: To me it just seems wrong to prevent this. This is in theory no different than a recursive call and just like recursion it can end up in an infinite loop. Having a limit seems OK since most JavaScript engines already have a limit on the size of the call stack. On Fri, 14 Mar 2008, Antti Koivisto wrote: In practice all browsers already treat click() as a special case. Removing the nesting protection completely (and relying on js stack limits) would break web sites so it is not an option. The only question is whether the limit should be 1 or some other number. Matching the existing implementations and disallowing nesting seems like a right thing to do here. On Fri, 14 Mar 2008, Geoffrey Garen wrote: You're right, it is no different *in theory*. It is, however, different in practice. If we allow click() to re-enter itself, popular websites stop working. On Mon, 17 Mar 2008, Antti Koivisto wrote: Hixie asked for a concrete example of page that breaks if click() limit is removed so here is one: 1. Go to http://forums.whirlpool.net.au/ 2. Under Whirlpool (righthand side) go to 'Feedback Forum' 3. Click on any Forum 4. Click reply to this post (righthand) side 5. Login (you need to create an account) 6. Click 'Show quoted' box Without click() protection the last step hangs the browser (at least until javascript time limit kicks in). Script is sufficiently complex and slow to execute that it won't hit javascript stack limit. I tried having a minimum nesting limit that passes Acid3 (10 iterations) and that too produces a noticeable ~1s pause. On mobile class hardware that would be a complete hang. I've added the reentrancy block to HTML5. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should enter be mapped to click?
On Tue, 15 Jul 2008, Anne van Kesteren wrote: On Tue, 15 Jul 2008 09:50:25 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Jul 2008, Aaron Leventhal wrote: Now that tabindex can be used on any element to make it focusable, it makes sense that it should be possible to trigger a click on those elements with the keyboard. Opera maps Enter to click. As far as I know, other browsers only do that for a few elements likea. What do people think? Should it be spec'd? 3.4.1.7. Interactive content, paragraph 3: | When activation is performed via some method other than clicking the | pointing device, the default action of the event that triggers the | activation must, instead of being activating the element directly, be to | fire a click event on the same element. Last I checked that doesn't say each focusable element actually gets activation behavior as well. Here's an example: div tabindex=0 onclick=alert(0)TEST/div The specification states that only certain elements are interactive content, not everything that's focusable. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'