Re: [whatwg] handler URI escaping in 4.5.1 appears to be different from encodeURIComponent
On Wed, 26 Sep 2007, Dan Mosedale wrote: The escaping specified in http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers is slightly different than the escaping done by encodeURIComponent (as described at http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Functions:encodeURIComponent). Specifically, encodeURIComponent is documented as not escaping: ! * ' ( ) characters, whereas the spec seems to want these characters to be escaped. Is this intentional? If so, what's the motivation? The spec was changed recently to just require that things that can't be in the query component of a URI be escaped, instead of saying everything must be escaped. Is that ok? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 : Misconceptions Documented
On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
On Wed, Jul 30, 2008 at 8:33 AM, Garrett Smith wrote:
(3) There is no specification for a special [[Get]] for the elements
HTMLCollection as a shortcut to namedItem, either (though this would not
seem to be a problem,
Actually, there is:
http://www.w3.org/TR/html5/dom.html#htmlcollection
and I believe the elements property of HTMLFormElement is actually
an HTMLFormControlsCollection:
http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection
First off, the IndexGetter behavior on the HTMLCollection[1] is the
authors imagination. It is a shame to see such misinformation has made
it so far.
The following example shows that indexed Properties exist on
NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
There is no [[ IndexGetter ]] as Cameron likes to make pretend.
==
!DOCTYPE HTML
html
head
titleAdditional Properties on NamedNodeMap, HTMLCollection, NodeList/title
link rel=author title=Garrett Smith href=mailto:[EMAIL PROTECTED]/
/head
body id=body
select id='s'
option/option
/select
pre
script type=text/javascript
var s = document.getElementById('s');
document.write([
NamedNodeMap: '0'in document.body.attributes :
+ ('0'in document.body.attributes),
HTMLCollection '0'in document.body.childNodes :
+ ('0'in document.body.childNodes),
HTMLOptionsCollection '0'in s.options :
+ ('0'in s.options),
NodeList: '0'in document.getElementsByTagName('*') :
+ ('0'in document.getElementsByTagName('*')),
'id'in document.body.attributes :
+ ('id'in document.body.attributes)
].join('\n'));
/script
/pre
p
This test is informative. It is not pass/fail. There is no public standard.
/p
/body
/html
==
Even if the author wrote 0 tests, simple observations should show him
just how wrong he is. I wrote about this twice on public-webapi list,
addressing Cameron McCormick with direct questions. Both messages died
with 0 replies. The second one I wrote to the public-webapi list:-
| It can be demonstrated that all of: NamedNodeMap, NodeList, and
| HTMLCollection are implemented in the top 4 browsers with extra
| numeric properties being added.
|
http://html5.googlecode.com/svn/trunk/incoming/garrett-smith/noIndexGetter.html
| StyleSheetList, and CSSRuleList also have this behavior. I can't
| find an object that implements indexed properties the way you
| have documented them.
| Although the HTML DOM spec defines a 'length' property for
| NamedNodeMap, yet provides no way to access items by index. This
| seems to be a strange design decision, though not the most harmful.
| Ideally, such decisions would be tested out before writing a lengthy
| document. Firefox, Opera, Safari, and IE all allow access by ordinal
| index, via property access, but not by the way you have described in
| your document.
My example demonstrates that there is no [[ IndexGetter ]] on
NamedNodeMap, et c. Ignoring valid criticism serves no useful purpose.
This was documented in IDL, of all the places.
and all implementations have supported this behavior for quite a long time).
Note that all implementations also supports the same behavior on
HTMLFormElement and HTMLDocument.
That is not true about document. There no indexed properties, no [[
IndexGetter ]], and no [[ NameGetter ]] and no named property. There
may be either a specialized [[ IndexGetter ]] or an indexed property
on a Form Element, and the [[ IndexedGetter ]] exists only in Firefox,
on the HTMLFormElement. I cannot understand decision to specify [[
IndexGetter ]] as standard for all objects with indexed properties
when it has been demonstrated to exist only on HTMLFormElement and
only in one browser:
Firefox.
==
!DOCTYPE HTML
html
head
titleDocument/title
style type='text/css'
li {
display: none;
}
/style
/head
body id=test
h1Document Has/h1
ul
li id='nameProperty'Named Property/li
li id='noNameProperty'No Named Property/li
li id='nameGetter' [[ NameGetter ]]/li
li id='indexProperty'Indexed Property/li
li id='indexGetter'[[IndexGetter]]/li
li id='noIndexProperty'No Indexed Property/li
/ul
h1Form Has/h1
ul
li id='fnameProperty'Named Property/li
li id='fnoNameProperty'No Named Property/li
li id='fnameGetter'[[ NameGetter ]]/li
li id='findexProperty'Indexed Property/li
li id='findexGetter'[[IndexGetter]]/li
li id='fnoIndexProperty'No Indexed Property/li
/ul
form action= name=f
input type=text name=t id=t
/form
script type=text/javascript
var ids = [];
if('test' in document) ids.push('nameProperty');
else {
ids.push('noNameProperty');
if(document.test) ids.push(nameGetter);
}
if('0'in document) ids.push('indexProperty');
else {
ids.push('noIndexProperty');
if(document[0]) ids.push('indexGetter');
}
var f =
Re: [whatwg] Workers comments
On Mon, Aug 4, 2008 at 8:24 PM, Jonas Sicking [EMAIL PROTECTED] wrote: The overall concern is that I think the spec is unnecessarily complicated. I'll comment in detail below on specific features. An overall requirement for mozilla is that we are very selective about which features are exposed on the thread. For example exposing a full navigator or window object is a huge amount of work. This doesn't mean that it shouldn't be done, but there needs to be very good reasons when exposing things. I don't see anything about a 'navigator' object except this comment: May need to define a browser sniffing API (like window.navigator). That doesn't imply to me that it will be the entire navigator object, just something having similar capabilities wrt browser sniffing. Similarly, the only thing that the spec says should be available from Window are the things listed in these two interfaces: http://www.whatwg.org/specs/web-workers/current-work/#the-windowworker http://www.whatwg.org/specs/web-apps/current-work/#window This is a very small subset of Window. So the first comment is the 'window' and 'self' properties. I agree, these seem unnecessary. On the subject of window. I think the fact that the global scope interface is named something with 'Window' is very confusing for anyone reading the spec. While I agree that there is some amount of association between the global scope and the window, I think there is a much stronger association between window and the properties that live on it, such as window.location, window.document, window.frames, window.scrollX, etc. I agree with this. I think the global object in a worker should be called something different, such as WorkerGlobal or WorkerContext. I don't think we should pay too much attention to trying to make existing code compatible with this environment, as that seems hopeless. However, I do feel that in the cases where an existing interface works nicely for its intended purpose, there's no point reinventing it. Less brain print, as a coworker likes to say. So for example, I would be for moving over a subset of the navigator and location objects as-is (these seem to work well), but against moving over the document.cookie interface (it works poorly). Additionally I am worried that sharing interfaces between the global scope object for browser contexts, and the global scope object for workers is going to lead to unnecessary feature creep with argument such as the object is available in the browsing context, so why not make it available in the worker context. I much rather want arguments like this feature is needed in thread contexts because of reason X and use case Y. I don't think having a common base interface in the spec is going to make this kind of feature creep any more or less likely. It just seems natural that if functionality is available in both workers and the main browsing context, it should work the same way. What is the use cases for the onconnect and onunload properties? 'onconnect' doesn't seem to add anything beyond simply leaving the code outside any function. I.e. doing I believe that onconnect is meant to be how a worker gets the MessagePort object from people who are trying to talk to it. Hixie, it occurs to me that it might be helpful for everyone if you could add some code samples for how applications would use this API to the top. It's easier to grok what the point is at a glance, and allows people to think about the API proposal holistically instead of trying to piece it together from the algorithms. The fact that the only way to communicate between workers and the main browser context is through MessagePorts seems unnecessarily complex as well as differing from how windows communicates using postMessage. I think MessagePorts are a fine concept, but I don't think they should be mandatory as I think in many cases they are more complicated than needed. The whole concept of entangled message ports that clone and die when you pass them around is something that I don't think we should force upon developers unless absolutely needed. In the current draft I can't even see how to reach the message port object inside the worker, though that might be a temporary oversight. But it does indicate that the level of complexity for communication is non-trivial. A better model seems to be reusing what we do for window objects. Simply make createWorker return a Worker object that has a sole .postMessage property, and make it possible to pass a Worker object through postMessage. We would also have to expose some way to send messages to the main browsing context, either through a separate postMessageToWindow function inside the worker context, or through a Worker object representing the main browser context. This doesn't stop us from adding support for MessagePorts as well, but it allows sites not to mess with them unless needed. I can get behind simplifying the API. However, the simple I would go
Re: [whatwg] document.readyState and its initial value
On Mon, 23 Jun 2008, Frode Børli wrote:
1. Which readystate does an img object have, before it is added to the
DOM? Example:
var i = document.createElement(IMG);
alert(i.readystate); // afaict the state SHOULD be uninitialized here...
i.onreadystatechange(function(){alert(this.readystate);}
i.src = some_url.jpg;
alert(i.readystate);
It seems only IE supports this property, so hopefully we don't need to
spec it (or support it in other UAs).
The example applies to iframes as well, i believe.
I couldn't reproduce this.
2. How can we listen to the onreadystatechange, if we want to trigger an
event when the object starts loading? It will not change readystate
since it was already in the state loading.
In HTML5 there's no way to get an event when an img begins loading. It
begins loading when the src= is set.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Methods defined for one document called after that document is no longer the one being displayed
I would like some input from browser vendors. Right now, if you navigate an iframe to a document, and take a reference to a method defined in that document, and then navigate that iframe to another document, and then call the method, browsers differ in what they do. There are several behaviours: - In one browser, the Window object changes with each navigation, and the global object is that object, and the method runs fine. - In one browser, the method call fails, saying that methods can't be called while the document that defined them isn't the active document of the browsing context whose global object is the method's. - In one browser, the Window object acts as a kind of view on the global object, which changes with each navigation, leading the method to see the original global object in its scope chain, but the new one if it uses the 'window' object. (In this environment, 'this' at the top scope returns the 'window' object, not the global object.) - In one browser, the global object and the Window are the same, but the global object is totally wiped out with each navigation, preventing the method from accessing its global object's data. (In this browser, the results are slightly different when navigating top-level windows instead of frames.) These results were derived from: http://damowmow.com/playground/demos/global-object/004.html I propose to adopt the second behaviour above. It seems by far the simplest behaviour to define and implement. Are there any objections to this? Given the lack of interoperability here, it seems like we aren't really constrained to pick something due to compatibility. The change would be that if a method is invoked when the script execution context that the method was running in has a Document object that is not the active Document object of its browsing context, then that method immediately throws an exception. Access to variables obtained from such script execution contexts would be unaffected. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Methods defined for one document called after that document is no longer the one being displayed
On Tue, Aug 5, 2008 at 1:12 AM, Ian Hickson [EMAIL PROTECTED] wrote:
Right now, if you navigate an iframe to a document, and take a
reference to a method defined in that document, and then navigate that
iframe to another document, and then call the method, browsers differ in
what they do.
By 'method' do you mean any function object, defined anywhere in that
window? For example, does document.getElementById count? Does the foo
in var myglobal = {foo:function(){...}}; ? What about getters?
- In one browser, the method call fails, saying that methods can't be
called while the document that defined them isn't the active document
of the browsing context whose global object is the method's.
Off the cuff, this behavior seems good to me. I think it would be good
if this applied to any function or getter.
- a
Re: [whatwg] Use of 'direction' of canvas element
On Fri, 13 Jun 2008, L. David Baron wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html#text has the following bullet point: # Form a hypothetical infinitely wide CSS line box containing a # single inline box containing the text text, with all the # properties at their initial values except the 'font' property of # the inline element set to font and the 'direction' property of # the inline element set to the 'direction' property of the canvas # element. [CSS] This should describe what to do if the canvas element is not in a document (and therefore has no 'direction'). It should probably fall back to 'ltr' as a last resort. However, as an intermediate step, it might be worth falling back to the direction property of the root element (if present) of the canvas element's ownerDocument. I've made it depend on the 'dir' attribute of the cavnas element if the CSS property doesn't have a defined computed value. Thanks, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Methods defined for one document called after that document is no longer the one being displayed
On Tue, 5 Aug 2008, Aaron Boodman wrote:
On Tue, Aug 5, 2008 at 1:12 AM, Ian Hickson [EMAIL PROTECTED] wrote:
Right now, if you navigate an iframe to a document, and take a
reference to a method defined in that document, and then navigate that
iframe to another document, and then call the method, browsers differ in
what they do.
By 'method' do you mean any function object, defined anywhere in that
window? For example, does document.getElementById count? Does the foo in
var myglobal = {foo:function(){...}}; ? What about getters?
I think I mean any function object, including getters and setters defined
by the script (i.e. not host objects). But I haven't checked. Possibly any
code whose global object is that global object.
- In one browser, the method call fails, saying that methods can't be
called while the document that defined them isn't the active document
of the browsing context whose global object is the method's.
Off the cuff, this behavior seems good to me. I think it would be good
if this applied to any function or getter.
Agreed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Fwd: Nested lists
Blarg forward to list. -- Forwarded message -- From: Tab Atkins Jr. [EMAIL PROTECTED] Date: Tue, Aug 5, 2008 at 9:15 AM Subject: Re: [whatwg] Nested lists To: noclip [EMAIL PROTECTED] On Mon, Aug 4, 2008 at 8:15 PM, noclip [EMAIL PROTECTED] wrote: Are there plans to natively support nested unordered lists in HTML 5? I'm referring here to something like this: Top level list item |-- Childless second level list item |-- Another childless second level list [+]- Collapsed second level list item with children [-]- Expanded second level list item with children ||-- Third level list item ||-- Another third level list item | [+]- Collapsed third level list item with children | [-]- Expanded third level list item with children |||-- Fourth level list item |||__ Another fourth level list item ||__ A final third level list item [+]- Another collapsed second level list item |__ A final second level list item This is already possible through CSS, but these kinds of nested lists are more organizational than presentational and could benefit from native support with their own kind of unordered list element. The markup for the above list could be something like this: nl li id=fooTop level list item/li lg parent=foo liChildless second level list item/li liAnother childless second level list item/li li id=barCollapsed second level list item with children/li lg parent=bar !-- Child list items here -- /lg li id=threeExpanded second level list item with children/li lg parent=three liThird level list item/li liAnother third level list item/li li id=fourCollapsed third level list item/li lg parent=bar !-- Child list items here -- /lg li id=fiveExpanded third level list item with children/li lg parent=bar liFourth level list item/li liAnother fourth level list item/li /lg liA final third level list item/li /lg li id=booAnother collapsed second level list item/li lg parent=boo !-- Child list items here -- /lg liA final second level list item/li /lg /nl Or you could define the list groups separately, at the beginning or end of the nl. Could you be more specific about how this is better than just nesting uls? Your example can be organized just as well with: ul liFoo/li li ul liBar/li liBaz/li ... This markup has the added advantage that it'll display a nested list no matter what - it is it's own fallback content if the UA doesn't have appropriate CSS support. Plus it automatically nests appropriately, without the need to specify parents explicitly. As shown in your example, that's somewhat error-prone ( below li id=five you have lg parent=bar, which should obviously be lg parent=five). ^_^
Re: [whatwg] document.readyState and its initial value
Ian Hickson wrote: But, oddity is par for the course in DOM, so I guess we'll just follow the HTML 5 spec as-is, initialize readyState to loading in the object constructor, and keep our fingers crossed. If you find any problems with doing this, please let me know, so we can update the spec! The concern I have with doing that is that document created through other means, such as .implementation.createDocument, XSLTProccessor.transformToDocument, DOMParser.parse, etc, probably should not be in the 'uninitialized' state. Especially the last two should return documents that is in the 'complete' state I would think. / Jonas
Re: [whatwg] document.readyState and its initial value
2. How can we listen to the onreadystatechange, if we want to trigger an event when the object starts loading? It will not change readystate since it was already in the state loading. In HTML5 there's no way to get an event when an img begins loading. It begins loading when the src= is set. Nothing prevents an implementation from firing ProgressEvents while loading images though, that would give you an event when an image starts loading. I don't think any browser does that as of yet though. / Jonas
[whatwg] Web Workers and MessagePort feedback
I'm still digesting the Web Worker proposal, but here is some
feedback. Sorry it is a bit long.
Structural API stuff:
- I still haven't really internalized the need to either have workers
speak directly to anyone other than the person who created them, or
the other use cases that MessageChannels are intended for. There is a
lot of complexity here. I think we need to add some requirements and
motivations to the top of the doc, and some code samples showing the
intended usage before implementors can really decide whether it's
worth taking on.
- It seems like we might want an object that represents workers. This
would allow us put the 'onload' and 'onerror' events from MessagePort
there, instead of on MessagePort, which makes more sense to me (I
don't know what it means for a MessagePort to 'load' or 'error'
outside of the context of a worker). MessagePort.onunload could then
change to 'onclose' to go with the close() method.
It seems like over time, we might want to be able to perform other
operations on a worker and having the worker object might be handy.
I know this is weird wrt GC when combined with MessagePorts, and I
don't have a proposed solution.
- It's odd to me that the way to establish a channel to a worker
depends on whether you are the creator of the worker or not. The
creator gets a MessagePort to a new channel back from createWorker(),
but any other function must pass a new MessagePort over the original
one, and the worker must know to use that secondary port to talk back.
I would prefer to see something like:
void Worker.postMessage(DOMString message)
void Worker.postMessage(DOMString message, MessagePort port)
That way the way to establish a new channel is the same for all
callers. It also has the advantage of looking similar to a window's
postMessage API.
Here is how the previous two suggestions would look together:
var worker = new Worker(foo.js);
worker.onload = function() { ... }
worker.onerror = function() { ... }
worker.onunload = function() { ... } // called when the worker shuts down
worker.sendMessage(hello!);
var channel = new MessageChannel();
channel.port1.onmessage = function(e) { ... }
worker.sendMessage(please return my call, channel.port2);
// called when the channel is closed, either because the worker shut down taking
// the other end of the port with it, or because the other end of the
port was GC'd,
// or because the other port was explicitly closed.
channel.port1.onclose = function() { ... }
semantics questions
- The spec doesn't seem to say what happens if you send a worker a
message before it has finished loading. I think that the message
should be queued and delivered when the worker load is complete. This
makes waiting for onload unnecessary, unless preparing the message you
want to send is somehow expensive.
- The spec says that as soon as a worker is not reachable (determined
via GC) from any MessagePort, it is eligible for shutdown. Shutdown
would attempt to finish all queued messages, but not allow any new
ones.
This concerns me because it means that workers will have different
behavior depending on GC timing. If a worker is not referenced from
any port, and it sends an XHR, that XHR may or may not be sent
depending on when GC runs. This is different than how XHR behaves
normally. Typically, XHR objects that have outstanding IO but no
referers will not be GC'd until they complete or fail.
Finally this does not allow use cases such as creating a worker to
synchronize a local database with the network without ever sending
notifications back to the parent.
Maybe workers should stay alive as long as any of the following are true:
- There is script running in them
- There are messages to them queued
- There is a messageport alive anywhere that could send messages to them
- There are asynchronous operations (xhr, timers, database
operations) inside them outstanding
API nitpickery
- Why is there an ownerWindow property on MessagePort? If I understand
correctly, this is just a synonym for the 'window' object of the
currently executing script context. I think it should go away.
- I'm curious as to why MessagePort and WindowWorker do not implement
EventTarget. It seems like we may as well reuse it. And at least for
WindowWorker, it seems like the same problems of having multiple
functions clobber each other that motivated EventTarget would apply.
- The purpose of 'import()' on WindowWorker was not immediately
obvious to me from its name. Should it be 'importScript()'? or
'includeScript()' maybe?
- Should import() accept an array of URLs, so that the UA can fetch
them in parallel if it has the ability to do that?
- The string URL property on the WindowWorker interface is less useful
than the parsed structure that window.location has. Can we use
something like this instead, except making it read-only?
- The front-line nomenclature was a bit weird to me. How about top-level?
- Would it be too weird to have createWorker overloaded to
Re: [whatwg] Context help in Web Forms
On Mon, 2 Jun 2008, Matthew Paul Thomas wrote: The disadvantage of using a data-* attribute is that more kinds of mistakes would be undetectable by a validator. It would have no idea that (a) the value of the attribute must be the ID of an element elsewhere in the document, and (b) each value must be unique within the document. I wonder if the data-* attribute naming scheme could be classified somehow to allow basic type checking like this. I expect there will be other cases where authors want an attribute value to match the ID of an element in the page. On Tue, 3 Jun 2008, Henri Sivonen wrote: I don't like the idea of trying to encode the datatypes of data-* attributes in a validator-sensitive way. What datatypes would a validator support for data-* attributes? The HTML5 datatype library used by Validator.nu already contains 41 datatypes, but people will likely want to have others. The whole point of data-* is to provide a place where a validator doesn't go without authors having to abuse e.g. title which is a freeform but exposed to humans. The foreseeable problem with data-* is, of course, that microformat-like activity will happen there instead of going through the trouble of getting unprefixed validator-sensitive attributes minted with community review in the WHATWG and the HTML WG. On Wed, 4 Jun 2008, Anne van Kesteren wrote: That'd be wrong as data-* does not allow implementation by UAs... Having said that, if we don't make it clear what the idea is that might end up happening in practice here and there. I agree that not constraining data-* will lead to a validation hole where people can't check that their data is matching their presumed schema, but I think the right solution to this is for validators to offer out-of-band ways to specify schemas for data-* attributes, not for the spec to constrain the values, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] document.readyState and its initial value
On Tue, 5 Aug 2008, Jonas Sicking wrote: 2. How can we listen to the onreadystatechange, if we want to trigger an event when the object starts loading? It will not change readystate since it was already in the state loading. In HTML5 there's no way to get an event when an img begins loading. It begins loading when the src= is set. Nothing prevents an implementation from firing ProgressEvents while loading images though, that would give you an event when an image starts loading. Well, nothing allows it either, at the moment. Would this be useful? I mean, I can add it if there is a desire for browsers to do this. It doesn't seem that useful though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Psuedo classes based on DOM Events
On Tue, 5 Dec 2006, Rohan Prabhu wrote: Dear all, i was just wondering, that in the Web Controls 1.0 specifications, in the psuedo classes specifications, could it be that the psuedo classes could also be the DOM Events which would modify the style information attached to it. Like for ex: #objectid:onmouseup #objectid:onmousedown #objectid:onmouseover #objectid:onmouseout #objectid:onkeypress etc... just a idea from the silly mind of mine :D .. but do give ur comments on that.. Sorry for the delay in responding. It looks like the Web Controls spec might never actually see the light of day; features like ARIA have been developed in the meantime to address much of the same use cases. I recommend contacting the CSS working group with the idea described above, as they might be in a better position to follow up on this. Thanks for the feedback though; I will keep track of it in case we ever do work on the Web Controls spec after all. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Workers and MessagePort feedback
Aaron Boodman wrote:
I'm still digesting the Web Worker proposal, but here is some
feedback. Sorry it is a bit long.
Structural API stuff:
- I still haven't really internalized the need to either have workers
speak directly to anyone other than the person who created them, or
the other use cases that MessageChannels are intended for. There is a
lot of complexity here. I think we need to add some requirements and
motivations to the top of the doc, and some code samples showing the
intended usage before implementors can really decide whether it's
worth taking on.
- It seems like we might want an object that represents workers. This
would allow us put the 'onload' and 'onerror' events from MessagePort
there, instead of on MessagePort, which makes more sense to me (I
don't know what it means for a MessagePort to 'load' or 'error'
outside of the context of a worker). MessagePort.onunload could then
change to 'onclose' to go with the close() method.
It seems like over time, we might want to be able to perform other
operations on a worker and having the worker object might be handy.
Agreed.
I know this is weird wrt GC when combined with MessagePorts, and I
don't have a proposed solution.
I don't think we should say much regarding GC at all. All we should say
is that GC should not affect the operation of the page. I.e. it is not
allowed to GC an Worker that someone still has references to, or a
Worker that has XHR loads in progress or timers pending.
Very few other specs mention GC and I haven't noticed that ever being a
problem. For example everyone agrees that it's a bug that gecko
sometimes GCs the parent of a node, if you're not actively holding any
references to anything in the parent chain.
- It's odd to me that the way to establish a channel to a worker
depends on whether you are the creator of the worker or not. The
creator gets a MessagePort to a new channel back from createWorker(),
but any other function must pass a new MessagePort over the original
one, and the worker must know to use that secondary port to talk back.
I would prefer to see something like:
void Worker.postMessage(DOMString message)
void Worker.postMessage(DOMString message, MessagePort port)
That way the way to establish a new channel is the same for all
callers. It also has the advantage of looking similar to a window's
postMessage API.
Agreed.
Here is how the previous two suggestions would look together:
var worker = new Worker(foo.js);
worker.onload = function() { ... }
worker.onerror = function() { ... }
worker.onunload = function() { ... } // called when the worker shuts down
worker.sendMessage(hello!);
So I really like this API. However it makes it completely impossible to
ever pass worker objects across threads. I.e. we could never allow:
worker1.postMessage(..., worker2);
This would be very strange if we had .onload, .onerror etc on the worker
object itself since those properties wouldn't make much sense living in
multiple threads at once.
While I agree direct communication between sibling workers is an
edgecase, it's something I would prefer to not make impossible for
future versions of the spec.
Though I just realized that we could cover that case using only
MessagePorts. So we say that you can only communicate with your creator,
and any children using direct .postMessage. If you want to more complex
communication patterns then set up MessagePorts.
- The spec says that as soon as a worker is not reachable (determined
via GC) from any MessagePort, it is eligible for shutdown. Shutdown
would attempt to finish all queued messages, but not allow any new
ones.
This concerns me because it means that workers will have different
behavior depending on GC timing. If a worker is not referenced from
any port, and it sends an XHR, that XHR may or may not be sent
depending on when GC runs. This is different than how XHR behaves
normally. Typically, XHR objects that have outstanding IO but no
referers will not be GC'd until they complete or fail.
Finally this does not allow use cases such as creating a worker to
synchronize a local database with the network without ever sending
notifications back to the parent.
Maybe workers should stay alive as long as any of the following are true:
- There is script running in them
- There are messages to them queued
- There is a messageport alive anywhere that could send messages to them
- There are asynchronous operations (xhr, timers, database
operations) inside them outstanding
Agreed. Like I said above, I think the less we say about GC the better.
GC effects should not be noticeable to the page.
- Why is there an ownerWindow property on MessagePort? If I understand
correctly, this is just a synonym for the 'window' object of the
currently executing script context. I think it should go away.
If we put postMessage directly on the Worker object we don't need to
mention MessagePorts in the Web workers spec at all. They can just be an
Re: [whatwg] Web Workers and MessagePort feedback
Thanks for the quick reply...
On Tue, Aug 5, 2008 at 2:52 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
I know this is weird wrt GC when combined with MessagePorts, and I
don't have a proposed solution.
I don't think we should say much regarding GC at all. All we should say is
that GC should not affect the operation of the page. I.e. it is not allowed
to GC an Worker that someone still has references to, or a Worker that has
XHR loads in progress or timers pending.
Very few other specs mention GC and I haven't noticed that ever being a
problem. For example everyone agrees that it's a bug that gecko sometimes
GCs the parent of a node, if you're not actively holding any references to
anything in the parent chain.
The spec doesn't have to mention GC, but it does mention
'reachability' right now and what happens when an object is no longer
reachable. This has an impact on interop, so I think it should be
well-defined.
Here is how the previous two suggestions would look together:
var worker = new Worker(foo.js);
worker.onload = function() { ... }
worker.onerror = function() { ... }
worker.onunload = function() { ... } // called when the worker shuts down
worker.sendMessage(hello!);
So I really like this API. However it makes it completely impossible to ever
pass worker objects across threads. I.e. we could never allow:
worker1.postMessage(..., worker2);
This would be very strange if we had .onload, .onerror etc on the worker
object itself since those properties wouldn't make much sense living in
multiple threads at once.
While I agree direct communication between sibling workers is an edgecase,
it's something I would prefer to not make impossible for future versions of
the spec.
Though I just realized that we could cover that case using only
MessagePorts. So we say that you can only communicate with your creator, and
any children using direct .postMessage. If you want to more complex
communication patterns then set up MessagePorts.
Makes sense, and I like how this is something that could be layered in
a later version.
- The spec says that as soon as a worker is not reachable (determined
via GC) from any MessagePort, it is eligible for shutdown. Shutdown
would attempt to finish all queued messages, but not allow any new
ones.
This concerns me because it means that workers will have different
behavior depending on GC timing. If a worker is not referenced from
any port, and it sends an XHR, that XHR may or may not be sent
depending on when GC runs. This is different than how XHR behaves
normally. Typically, XHR objects that have outstanding IO but no
referers will not be GC'd until they complete or fail.
Finally this does not allow use cases such as creating a worker to
synchronize a local database with the network without ever sending
notifications back to the parent.
Maybe workers should stay alive as long as any of the following are true:
- There is script running in them
- There are messages to them queued
- There is a messageport alive anywhere that could send messages to them
- There are asynchronous operations (xhr, timers, database
operations) inside them outstanding
Agreed. Like I said above, I think the less we say about GC the better. GC
effects should not be noticeable to the page.
Ok, but right now, the spec says something that contradicts this. It
should either be changed, or removed, if people think the right
behavior goes without saying.
- Why is there an ownerWindow property on MessagePort? If I understand
correctly, this is just a synonym for the 'window' object of the
currently executing script context. I think it should go away.
If we put postMessage directly on the Worker object we don't need to mention
MessagePorts in the Web workers spec at all. They can just be an orthogonal
specs.
This feedback was referencing the separate MessageChannel section of
the web-apps spec. I glommed my feedback together because it was the
first time I'd looked at MessageChannels closely and they go together
for my purposes.
- The string URL property on the WindowWorker interface is less useful
than the parsed structure that window.location has. Can we use
something like this instead, except making it read-only?
Why do we need it at all?
If we do think it's useful, most of the uses that I've seen for the parsed
URL structure has been to set the .hash in order to scroll around on a page
or communicate between iframes of different origins (ugh!!). Neither of
these applies here I'd say.
The protocol, host, hostname, port, pathname, and search properties
are all very useful. An application might want to compare the origin
of a message it receives with it's own host and port, for example.
Providing these split out avoids common parsing mistakes.
- The front-line nomenclature was a bit weird to me. How about
top-level?
I didn't try to grokk this part yet. Is it just about estabilishing lifetime
of the worker objects? If so,
Re: [whatwg] document.readyState and its initial value
Ian Hickson wrote: On Tue, 5 Aug 2008, Jonas Sicking wrote: Ian Hickson wrote: But, oddity is par for the course in DOM, so I guess we'll just follow the HTML 5 spec as-is, initialize readyState to loading in the object constructor, and keep our fingers crossed. If you find any problems with doing this, please let me know, so we can update the spec! The concern I have with doing that is that document created through other means, such as .implementation.createDocument, XSLTProccessor.transformToDocument, DOMParser.parse, etc, probably should not be in the 'uninitialized' state. Especially the last two should return documents that is in the 'complete' state I would think. IE doesn't have any of those mechanisms. In IE, w(new ActiveXObject(Msxml.DOMDocument).readyState); ...returns 4, which isn't any of the values I expected. Right now the spec says that anything that doesn't go through a parser will remain in the readyState == loading state forever. Is that a problem? The one usecase I have heard for .readystate is to figure out if the document has had its onload event fired yet, or if one is coming later. In that scenario it would seem unexpected to return loading as no onload event is about to fire. We could define that mechanisms that create a Document object without an associated parser set it to complete if you want. I'm not sure that that would be especially useful, although it would, I guess, be somewhat more self-consistent. Yeah, i think so. / Jonas
Re: [whatwg] HTML 5 : Misconceptions Documented
On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote:
On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote:
Actually, there is:
http://www.w3.org/TR/html5/dom.html#htmlcollection
and I believe the elements property of HTMLFormElement is actually
an HTMLFormControlsCollection:
http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection
First off, the IndexGetter behavior on the HTMLCollection[1] is the
authors imagination.
Aren't document.forms[0] and document.forms.myform working?
The following example shows that indexed Properties exist on
NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
There is no [[ IndexGetter ]] as Cameron likes to make pretend.
This is an implementation detail of the ECMAScript binding.
In C#, these would obviously be mapped to indexers (public
HTMLElement this[int index] { get { ... } } and public object
this[String name] { get { ... } }), and there is no equivalent in
Java.
I guess that in Python and Ruby, which share their dynamic nature
with ECMAScript, these wouldn't be true properties as well (i.e. '0'
in document.forms would be False, and document.forms[0] wouldn't be
equivalent to document.forms[0])
--
Thomas Broyer
Re: [whatwg] Proposal for a link attribute to replace a href
Simon Pieters wrote: On Mon, 04 Aug 2008 20:21:01 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: However if we want to add support for the long list of JS attributes that exist on a elements today on each and every HTML element I suspect that is going to get messier. Especially considering the collisions for base and link. What would myBaseElement.accessKey do? And is myDivElement.protocol really intuitive what it does? Also it would quite likely clash with existing content that expects that those attributes don't exist on e.g. divs. (Opera has had problems with some new DOM attributes in WF2 due to legacy.) One idea is to enable all elements to cross-reference to hyperlink (a or link) elements. This could be achieved with a link attribute that contains the ID of the hyperlink element. The behavior of elements with @link would be UA defined, but could be: onclick: follow the hyperlink on the referenced a or link elemenr oncontextmenu: offer menu options to a) scrollTo the hyperlink element or b) follow the hyperlink. If the link attribute is present but empty then it could be assumed to reference getElementsByTagName(a)[0]. Pros: - don't need to add properties of hyperlink elements to other elements - Javascript implementations for older browsers would be trivial - the link attribute can be used as a styling hook - multiple elements can use the one hyperlink Cons: - won't inherit :visited styles
