[whatwg] Error in 8.2.4.26 After DOCTYPE name state
In section 8.2.4.26 the spec says: If the next six characters are an ASCII case-insensitive match for the word PUBLIC, then consume those characters and switch to the before DOCTYPE public identifier state. The P has already been consumed at the beginning of this section. Thus, I believe it should read: If this character and the next five characters are an ASCII case-insensitive match for the word PUBLIC, etc. Same goes for the match for SYSTEM. Cheers, Edward
[whatwg] input type=image width/height attributes
Are there any plans to add the width/height attributes for the input element to the HTML5 spec? It seems that all browsers (Opera, FF, Safari, IE) support width/height on input type=image in both quirks and standards mode. There are websites that depend on this behavior (the select-your-postal-code landing page at canadiantire.ca is one example) and it doesn't seem to be specced anywhere that I could find. Cheers, kats
Re: [whatwg] input type=image width/height attributes
What's the problem with specifying that as style attributes? On Dec 23, 2008, at 3:43 PM, Kartikaya Gupta wrote: Are there any plans to add the width/height attributes for the input element to the HTML5 spec? It seems that all browsers (Opera, FF, Safari, IE) support width/height on input type=image in both quirks and standards mode. There are websites that depend on this behavior (the select-your-postal-code landing page at canadiantire.ca is one example) and it doesn't seem to be specced anywhere that I could find. Cheers, kats
Re: [whatwg] input type=image width/height attributes
On Tue, 23 Dec 2008 15:57:06 -0500, Douglas Mayle doug...@openplans.org wrote: What's the problem with specifying that as style attributes? I don't have a problem with it, and I think that's how authors should be doing it. However, I thought HTML5 was supposed to be describing existing browser behavior (in addition to adding new stuff), in which case this should be added. Cheers, kats
Re: [whatwg] Error propagation in child workers
On Tue, 16 Dec 2008, Jonas Sicking wrote:
Ian Hickson wrote:
On Thu, 27 Nov 2008, ben turner wrote:
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 ended up using a combination of both the event mechanism and the old
Window.onerror mechanism. The spec now says to fire onerror in the worker
global scope, using the old mechanism, and if that doesn't handle the
error then a series of events going up the chain to the browsing context
is fired until one is canceled.
--
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 Tue, Dec 23, 2008 at 4:10 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 16 Dec 2008, Jonas Sicking wrote:
Ian Hickson wrote:
On Thu, 27 Nov 2008, ben turner wrote:
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 ended up using a combination of both the event mechanism and the old
Window.onerror mechanism. The spec now says to fire onerror in the worker
global scope, using the old mechanism, and if that doesn't handle the
error then a series of events going up the chain to the browsing context
is fired until one is canceled.
What is the advantage of this? Seems like this is just re-inventing
try-catch. (yes, the same question can be posed for window.onerror,
but at least there there are legacy reasons).
/ Jonas
Re: [whatwg] input type=image width/height attributes
On Tue, 23 Dec 2008 22:08:35 +0100, Kartikaya Gupta lists.wha...@stakface.com wrote: On Tue, 23 Dec 2008 15:57:06 -0500, Douglas Mayle doug...@openplans.org wrote: What's the problem with specifying that as style attributes? I don't have a problem with it, and I think that's how authors should be doing it. However, I thought HTML5 was supposed to be describing existing browser behavior (in addition to adding new stuff), in which case this should be added. Note that much of the obsolete stuff that browsers have to support is not yet defined in detail, especially things that affect rendering. E.g., the various attributes for table elements that affect layout are not yet defined either, though should be in due course. (Although this prolly depends on the CSS WG defining a proper table layout model they can hook into.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Error propagation in child workers
Yes, I agree, try/catch works just as well for that. The only thing we
really need is a way to communicate errors to the parent IMO.
-Ben
On Tue, Dec 23, 2008 at 5:07 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Dec 23, 2008 at 4:10 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 16 Dec 2008, Jonas Sicking wrote:
Ian Hickson wrote:
On Thu, 27 Nov 2008, ben turner wrote:
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 ended up using a combination of both the event mechanism and the old
Window.onerror mechanism. The spec now says to fire onerror in the worker
global scope, using the old mechanism, and if that doesn't handle the
error then a series of events going up the chain to the browsing context
is fired until one is canceled.
What is the advantage of this? Seems like this is just re-inventing
try-catch. (yes, the same question can be posed for window.onerror,
but at least there there are legacy reasons).
/ Jonas
Re: [whatwg] input type=image width/height attributes
On Wed, 24 Dec 2008 00:12:56 +0100, Anne van Kesteren ann...@opera.com wrote: Note that much of the obsolete stuff that browsers have to support is not yet defined in detail, especially things that affect rendering. Fair enough. Just wanted to make sure it wasn't getting forgotten. Cheers, kats
Re: [whatwg] Error propagation in child workers
On Tue, 23 Dec 2008, Jonas Sicking wrote: I ended up using a combination of both the event mechanism and the old Window.onerror mechanism. The spec now says to fire onerror in the worker global scope, using the old mechanism, and if that doesn't handle the error then a series of events going up the chain to the browsing context is fired until one is canceled. What is the advantage of this? Seems like this is just re-inventing try-catch. (yes, the same question can be posed for window.onerror, but at least there there are legacy reasons). Having the error be first reported outside of the context that created the error seems really weird. window.onerror is a very widely used feature, I don't see why it wouldn't be equally widely used in workers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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
