[widgets] Null in PC
Hi, I had a discussion with an implementer who was a bit confused about the concept of null in the specification. The problem is that I kinda wrote the spec as if it was to be implemented in Java or JavaScript. This has resulted in confusion wrt how null is to be interpreted in languages that don't have that concept/data type. So, in an effort to clarify that, I've added the following to Processing Rules section of PC: [[ In the following algorithms, the concept of null is used as a special symbol to indicate that a variable has no data associated with it. For example, let x be null or if y is empty, then return null. Note: Although ECMAScript and Java support null as a native value type, there are some programming languages that have no notion of null or where null is problematic (e.g. C++). For those languages, it is OK for an implementation to substitute the null for some other value or symbol (or for nothing at all). For example, it is ok to have the value 0 represent null for the height of a widget as the height of a widget is defined as a non-negative integer greater than 0. In such a case, 0 would behave as if it is null. ]] I don't have much experience programming in anything but Java and ECMAScript (why would anyone program in something else?!;)), so please let me know if it makes sense or if it could be better defined.
Re: [widgets] Null in PC
On Tue, 02 Feb 2010 13:29:42 +0100, Marcos Caceres marc...@opera.com wrote: Hi, I had a discussion with an implementer who was a bit confused about the concept of null in the specification. The problem is that I kinda wrote the spec as if it was to be implemented in Java or JavaScript. This has resulted in confusion wrt how null is to be interpreted in languages that don't have that concept/data type. So, in an effort to clarify that, I've added the following to Processing Rules section of PC: [[ In the following algorithms, the concept of null is used as a special symbol to indicate that a variable has no data associated with it. For example, let x be null or if y is empty, then return null. Note: Although ECMAScript and Java support null as a native value type, there are some programming languages that have no notion of null or where null is problematic (e.g. C++). For those languages, it is OK for an implementation to substitute the null for some other value or symbol (or for nothing at all). For example, it is ok to have the value 0 represent null for the height of a widget as the height of a widget is defined as a non-negative integer greater than 0. In such a case, 0 would behave as if it is null. ]] I don't have much experience programming in anything but Java and ECMAScript (why would anyone program in something else?!;)), so please let me know if it makes sense or if it could be better defined. HTML5 solves this with: Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#conformance-requirements -- Simon Pieters Opera Software
Re: One feature, multiple resources
(IMPORTANT: New test in the test suite, please see below if you have already submitted your results) On Fri, Jan 29, 2010 at 1:45 PM, Arve Bersvendsen ar...@opera.com wrote: This is an excerpt of something I wrote on the #webapps IRC channel: arve hm arve I have some exploratory work here (not going into details) arve let's just say that param for feature isn't enough arve but an example is actually Opera's own Unite arve (looking a bit further, though) arve let's say I wanted to spawn two workers, each with their own web service arve simply speaking, I can't arve currently, all I can do is: arve feature name=http://xmlns.opera.com/webserver; arve param name=type value=service / arve param name=servicepath value=foo / arve /feature The problem is roughly that the param key-value pair is insufficient when a feature needs to both specify and configure multiple resources, such as one Opera Unite widget configuring two different web services. The example above could only ever load one single service per widget (and it would be what's specified in the widget's content element, to boot). A widget which wanted to configure one document per widget would need to nest the param's in something. The spec purposely does not give guidance on what to do when two features with the same name are encountered, apart from parsing them as normal. Hence, given the following, the feature list would end up with two objects containing distinct parameters. feature name=http://xmlns.opera.com/webserver; param name=type value=service / param name=servicepath value=foo / /feature feature name=http://xmlns.opera.com/webserver; param name=type value=service / param name=servicepath value=bar / /feature It would then be left up to the implementation to make use of those objects as it sees fit, or, the specification that defines the said feature, needs to give guidance as what to do in case of a name collision. I've added the following test to the test suite: test id=ha for=ta-rZdcMBExBX src=test-cases/ta-rZdcMBExBX/002/ha.wgt Test the UA's ability to handle multiple feature elements with the same value for the name attribute, but with different param elements. To pass, the feature list must contain two features. Both are named 'feature:a9bb79c1'. One feature must have a parameter named test whose value is pass1 The other feature must have a parameter named test whose value is pass2 (the order in which the features appear in the feature list in not relevant). /test -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Null in PC
On Tue, Feb 2, 2010 at 2:20 PM, Simon Pieters sim...@opera.com wrote: On Tue, 02 Feb 2010 13:29:42 +0100, Marcos Caceres marc...@opera.com wrote: Hi, I had a discussion with an implementer who was a bit confused about the concept of null in the specification. The problem is that I kinda wrote the spec as if it was to be implemented in Java or JavaScript. This has resulted in confusion wrt how null is to be interpreted in languages that don't have that concept/data type. So, in an effort to clarify that, I've added the following to Processing Rules section of PC: [[ In the following algorithms, the concept of null is used as a special symbol to indicate that a variable has no data associated with it. For example, let x be null or if y is empty, then return null. Note: Although ECMAScript and Java support null as a native value type, there are some programming languages that have no notion of null or where null is problematic (e.g. C++). For those languages, it is OK for an implementation to substitute the null for some other value or symbol (or for nothing at all). For example, it is ok to have the value 0 represent null for the height of a widget as the height of a widget is defined as a non-negative integer greater than 0. In such a case, 0 would behave as if it is null. ]] I don't have much experience programming in anything but Java and ECMAScript (why would anyone program in something else?!;)), so please let me know if it makes sense or if it could be better defined. HTML5 solves this with: Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#conformance-requirements yeah, that's pretty good... but the problem is still in the definition of null, I feel. Anyway, hopefully with the clarification I've added, everything will be clear enough. I've also added the text you suggested above as a final fallback. -- Marcos Caceres http://datadriven.com.au
Re: One feature, multiple resources
After looking at the spec a bit more closely, I noticed that the following requirement from how to process a feature element (Step 7): If the name attribute of this feature element is absent, then the user agent must ignore this element. I've now added that. We had tests for this behavior in the test suite: http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-rZdcMBExBX/000/ http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-rZdcMBExBX/001/ But it was not explicitly written into the spec :( Kind regards, Marcos On Tue, Feb 2, 2010 at 4:27 PM, Marcos Caceres marc...@opera.com wrote: (IMPORTANT: New test in the test suite, please see below if you have already submitted your results) On Fri, Jan 29, 2010 at 1:45 PM, Arve Bersvendsen ar...@opera.com wrote: This is an excerpt of something I wrote on the #webapps IRC channel: arve hm arve I have some exploratory work here (not going into details) arve let's just say that param for feature isn't enough arve but an example is actually Opera's own Unite arve (looking a bit further, though) arve let's say I wanted to spawn two workers, each with their own web service arve simply speaking, I can't arve currently, all I can do is: arve feature name=http://xmlns.opera.com/webserver; arve param name=type value=service / arve param name=servicepath value=foo / arve /feature The problem is roughly that the param key-value pair is insufficient when a feature needs to both specify and configure multiple resources, such as one Opera Unite widget configuring two different web services. The example above could only ever load one single service per widget (and it would be what's specified in the widget's content element, to boot). A widget which wanted to configure one document per widget would need to nest the param's in something. The spec purposely does not give guidance on what to do when two features with the same name are encountered, apart from parsing them as normal. Hence, given the following, the feature list would end up with two objects containing distinct parameters. feature name=http://xmlns.opera.com/webserver; param name=type value=service / param name=servicepath value=foo / /feature feature name=http://xmlns.opera.com/webserver; param name=type value=service / param name=servicepath value=bar / /feature It would then be left up to the implementation to make use of those objects as it sees fit, or, the specification that defines the said feature, needs to give guidance as what to do in case of a name collision. I've added the following test to the test suite: test id=ha for=ta-rZdcMBExBX src=test-cases/ta-rZdcMBExBX/002/ha.wgt Test the UA's ability to handle multiple feature elements with the same value for the name attribute, but with different param elements. To pass, the feature list must contain two features. Both are named 'feature:a9bb79c1'. One feature must have a parameter named test whose value is pass1 The other feature must have a parameter named test whose value is pass2 (the order in which the features appear in the feature list in not relevant). /test -- Marcos Caceres http://datadriven.com.au -- Marcos Caceres http://datadriven.com.au
[WARP] Use cases for local network access
All, As actioned in the 21st Jan teleconference, here are the use cases that have motivated my specific proposal for supporting local network access in the WARP spec (see http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0173.html for details). 1. A developer wishes to write widgets that can connect to the web API exposed by a network-connected television or personal video recorder (aka digital video recorder) on their home network. This API allows (for example) the channel being viewed to be changed or the list of scheduled recordings to be modified, via a user interface presented by the widget. 2. A developer wishes to write widgets that can connect to the web interface (or API) of a home network router, in order to monitor the ADSL connection state, discover the external IP address of the router's NAT function, control the forwarding of ports to internal servers, etc. 3. A developer wishes to write widgets that can connect to the WebDAV interface provided by a NAS box on a home network, for the purposes of accessing or managing the contents of the remote filesystem. 4. A developer wishes to write widgets that can access the web interface of a networked security camera on a home network, for the purposes of viewing the images it captures. 5. A developer wishes to write widgets that can access the web API of a home automation system running on their home network, for the purposes of monitoring and controlling the devices connected to it. Of these, I only have a direct professional interest in the first in the list. (Which shouldn't surprise anyone, given the organisation that I represent on this WG.) S
Re: [WebTiming] HTMLElement timing
Hi, Olli, On Fri, Jan 29, 2010 at 6:15 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 1/27/10 9:39 AM, Zhiheng Wang wrote: Folks, Thanks to the much feedback from various developers, the WebTiming specs has undergone some major revision. Timing info has now been extended to page elements and a couple more interesting timing data points are added. The draft is up on http://dev.w3.org/2006/webapi/WebTiming/ Feedback and comments are highly appreciated. cheers, Zhiheng Like Jonas mentioned, this kind of information could be exposed using progress events. What is missing in the draft, and actually in the emails I've seen about this is the actual use case for the web. Debugging web apps can happen outside the web, like Firebug, which investigates what browser does in different times. Why would a web app itself need all this information? To optimize something, like using different server if some server is slow? But for that (extended) progress events would be good. And if the browser exposes all the information that the draft suggest, it would make sense to dispatch some event when some new information is available. Good point and I do need to spend more time on the intro and use cases throughout the specs. In short, the target of this specs are web site owners who want to benchmark their user exprience in the field. Debugging tools are indeed very powerful in development but things could become quite different once the page is put to the wild, e.g., there is no telling about dns, tcp connection time in the dev space; UGC only adds more complications to the overall latency of the page; and, what is the right TTL for my dns record if I want to maintain certain cache hit rate?, etc. There are also undefined things like paint event, which is referred to in lastPaintEvent and paintEventCount. And again, use case for paintEventCount etc. Something like Mozilla's MozAfterPaint? I do need to work on more use cases. The name of the attribute is very strange: readonly attribute DOMTiming document; agreed... how about something like root_times? What is the reason for timing array in window object? Why do we need to know anything about previous pages? Or what is the timing attribute about? Something got missing in this revision, my bad. The intention is to keep previous pages' timing info only if these pages are all in a direction chain. From the user's perspective, the waiting begins with the fetching of the first page in a redirection chain. thanks, Zhiheng -Olli
Re: [WebTiming] HTMLElement timing
Jonas,
On Fri, Jan 29, 2010 at 12:50 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jan 28, 2010 at 10:53 PM, Zhiheng Wang zhihe...@google.com
wrote:
Also, what is the use case for the Ticks interface?
The Ticks interface is a convenient way to store time measurements
and
retrieve it later on a page.
I will have some example there.
Why not just do:
myTimings = {};
myTimings.fooStart = new Date();
etc? Javascript has perfectly good ways to store values already.
window.timing property keeps timing info of previous navigation as
well
so the Tick
interface also provides a way to pass custom POI to the next page. Some
security
measure need to be added later though.
Sounds like simply using
sessionStorage.myTimings = {};
sessionStorage.myTimings.fooStart = new Date();
right. Tick() is indeed supposed to be a thin wrapper around the web
storage.
Now come to think of it, I tend to agree that it is probably not worthy
putting in the spec.
Thanks for the catch.
I would really encourage that this spec be reduced to the most
important parts first and wait for browsers to catch up before adding
nice to have features.
Agree and we do keep that in mind. Most of the the properties
specified
right now are
on the critical path of user perceived latency though.
That surprises me. See my first answer above.
I meant these properties are in the latency critical path of the
element
it belongs to...
If implementations implement progress events on the various elements
it would seem like you would get most of the advantages from this
spec.
The progress events are great, except that they mostly focus on
downloading the content but
not much about everything else, say, parseStart.
Specs can be changed, nothing is set in stone :)
Good to know. :-) Having more data exported in the progress events
will
be
good news to those performance debugging tools. When collecting latency
field data, many developers perfer to fetch all timing info of an
element (window.document?)
at once and send a json object.
thanks,
Zhiheng
While I agree that timing information is important, I don't think it's
going to be so commonly used that we need to add convenience features
for it. Adding a few event listeners at the top of the document does
not seem like a big burden.
User latency is quite sensitive to scripts at the top of the page.
And it would be really bad if the measurement instrumentations themselves
would much slow down the page. :-) Also, event listeners might not work in
some corner cases (meta-refresh redirection?) Last, some (probably minor)
concerns rise from the discrepancies between a natively recorded timestamp
and that done in a js callback.
thanks,
Zhiheng
/ Jonas
Re: [XHR2] AnonXMLHttpRequest()
On Sun, Jan 31, 2010 at 11:03 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious what practical differences there are between CORS with the credentials flag set to false and the origin set to null, and UMP. Are there any? The credentials flag in CORS is underspecified, so it's hard to answer this question. Since we've all noted that CORS and UMP take a different approach to the problem, I think it would be confusing to bundle them in a single spec. If CORS wants to be a superset of UMP, then I think it's best to write CORS as an extension of UMP, and so referencing UMP, rather than absorbing it. This specification layout would also make it easier to communicate the differences between an AnonXMLHttpRequest (or UniformRequest) and an XHR2; each would link to their corresponding spec document without needing to select only the relevant sub-sections. Since UMP is also much smaller and simpler than CORS, I think it makes sense to push it through the standardization process at a faster pace than CORS. For example, I think it is reasonable to move UMP to Last Call as early as next month, or the even the end of this month. Note: in light of the above, I think AnonXMLHttpRequest would be almost the same as XDomainRequest, the only difference being that it would send Origin: null instead of the sender's actual Origin. As the UMP spec notes, it is within the intersection of what has been commonly deployed across user-agents. I'm curious to learn Microsoft's assessment of UMP, since, as you note, it is very close to their own XDomainRequest. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/1/2010 8:17 PM, Pablo Castro wrote: [snip] the existence of currentTransaction in the same class). beginTransaction would capture semantics more accurately. b. ObjectStoreSync.delete: delete is a Javascript keyword, can we use remove instead? I'd prefer to keep both of these as is. Since commit and abort are part of the transaction interface, using transaction() to denote the transaction creator seems brief and appropriate. As far as ObjectStoreSync.delete, most JS engines have or should be contextually reserving delete. I certainly prefer delete in preserving the familiarity of REST terminology. [PC] I understand the term familiarity aspect, but this seems to be something that would just cause trouble. From a quick check with the browsers I had at hand, both IE8 and Safari 4 reject scripts where you try to add a method called ?delete? to an object?s prototype. Natively-implemented objects may be able to work-around this but I see no reason to push it. remove() is probably equally intuitive. Note that the method ?continue? on async cursors are likely to have the same issue as continue is also a Javascript keyword. You can't use member access syntax in IE8 and Safari 4 because they only implement EcmaScript3. But obviously, these aren't the target versions, the future versions would be the target of this spec. ES5 specifically contextually unreserves keywords, so obj.delete(id) is perfectly valid syntax for all target browser versions. ES5 predates Indexed DB API, so it doesn't make any sense to design around an outdated EcmaScript behavior (also it is still perfectly possible to set/call the delete property in ES3, you do so with object[delete](id)). - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktogZkACgkQ9VpNnHc4zAytzgCeIssVuHKnsYaQ7Nd9Dhm5LxVN K+EAn32wlsyD17GKDqIPonEKLqt6v9nm =jTAo -END PGP SIGNATURE-
Re: [widgets] Null in PC
Hi, Marcos- Marcos Caceres wrote (on 2/2/10 7:29 AM): I had a discussion with an implementer who was a bit confused about the concept of null in the specification. The problem is that I kinda wrote the spec as if it was to be implemented in Java or JavaScript. This has resulted in confusion wrt how null is to be interpreted in languages that don't have that concept/data type. So, in an effort to clarify that, I've added the following to Processing Rules section of PC: [[ In the following algorithms, the concept of null is used as a special symbol to indicate that a variable has no data associated with it. For example, let x be null or if y is empty, then return null. Note: Although ECMAScript and Java support null as a native value type, there are some programming languages that have no notion of null or where null is problematic (e.g. C++). For those languages, it is OK for an implementation to substitute the null for some other value or symbol (or for nothing at all). For example, it is ok to have the value 0 represent null for the height of a widget as the height of a widget is defined as a non-negative integer greater than 0. In such a case, 0 would behave as if it is null. ]] It seems strange to me to use language like OK in a spec, since it seems overly casual and definitely not normative; I suggest you replace all instances of OK with awesome. Failing that, maybe wording like this might better capture the interop aspects? We want all the C++ implementations to behave the same, even if they are crippled by their language. :P (I used to be a C++ programmer... I thought it did have a NULL, but I guess that's only for pointers.) [[ In the following algorithms, the concept of null is used as a special symbol to indicate that a variable has no data associated with it. For example, let x be null or if y is empty, then return null. Note: Although languages such as ECMAScript and Java support null as a native value type, there are some programming languages that have no notion of null or where null is problematic (e.g. C++). Implementations in these languages should substitute a language-specific value or symbol which is functionally equivalent to null, or if no equivalent exists, to have no value at all. For example, the value 0 may represent null for the height of a widget, since the height of a widget is defined as a non-negative integer greater than 0. In such a case, 0 should be treated as if it were null. ]] I'm not satisfied by that wording either, to be frank... I think it needs to be precise about the value for each language that's affected. I also think we need to make a distinction between the implementation language and the content language... the content should not get a '0', right? It should get 'null', I'd think. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: [WebTiming] HTMLElement timing
On Tue, Feb 2, 2010 at 10:36 AM, Zhiheng Wang zhihe...@google.com wrote: Hi, Olli, On Fri, Jan 29, 2010 at 6:15 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 1/27/10 9:39 AM, Zhiheng Wang wrote: Folks, Thanks to the much feedback from various developers, the WebTiming specs has undergone some major revision. Timing info has now been extended to page elements and a couple more interesting timing data points are added. The draft is up on http://dev.w3.org/2006/webapi/WebTiming/ Feedback and comments are highly appreciated. cheers, Zhiheng Like Jonas mentioned, this kind of information could be exposed using progress events. What is missing in the draft, and actually in the emails I've seen about this is the actual use case for the web. Debugging web apps can happen outside the web, like Firebug, which investigates what browser does in different times. Why would a web app itself need all this information? To optimize something, like using different server if some server is slow? But for that (extended) progress events would be good. And if the browser exposes all the information that the draft suggest, it would make sense to dispatch some event when some new information is available. Good point and I do need to spend more time on the intro and use cases throughout the specs. In short, the target of this specs are web site owners who want to benchmark their user exprience in the field. Debugging tools are indeed very powerful in development but things could become quite different once the page is put to the wild, e.g., there is no telling about dns, tcp connection time in the dev space; UGC only adds more complications to the overall latency of the page; and, what is the right TTL for my dns record if I want to maintain certain cache hit rate?, etc. There are also undefined things like paint event, which is referred to in lastPaintEvent and paintEventCount. And again, use case for paintEventCount etc. Something like Mozilla's MozAfterPaint? I do need to work on more use cases. In practice I think this will be useless. In a page that has any sort of animation, blinking cursor, mouse movement plus hover effects, etc the 'last paint time' will always be immediately before the query. I would recommend dropping it. - James The name of the attribute is very strange: readonly attribute DOMTiming document; agreed... how about something like root_times? What is the reason for timing array in window object? Why do we need to know anything about previous pages? Or what is the timing attribute about? Something got missing in this revision, my bad. The intention is to keep previous pages' timing info only if these pages are all in a direction chain. From the user's perspective, the waiting begins with the fetching of the first page in a redirection chain. thanks, Zhiheng -Olli
Re: element.onresize
On 2/2/10 11:09 PM, Gregg Tavares wrote: I'm not sure if this is the correct place for this but: Has there been any discussion of adding an element.onresize event? The issue that has come up is the canvas tag, in 2d or 3d, when the canvas changes its displayed size, a webapp might want to respond by changing the size of the internal representation of the canvas. Unfortunately an appt has no way to know when the canvas's display size has changed. The developer can use window.onresize but that only triggers when the window itself has changed size. If the canvas element has changed size for some other reason (another element's css or size were changed for example) no window.onresize is sent and so their is no easy way to know the display size of the canvas changed. This could be added to just the canvas tag but it seems like it would be more appropriate to be added to all (visual?) elements. I can see for example, setting img.src depending on the display size of the img element or changing the content of a div depending on its display size. DOM Events 3 draft has currently resize event. The definition of it may still change, since there are still problems to fix. http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-resize I *believe* currently only IE supports resize, and even it has some hacks around it. -Olli
Re: element.onresize
The problem with this is one of performance. For example resizing the window could easily cause every single element on the page to change size. If every element fired an event, that could easily mean firing thousands of events. Yes, in many situations the implementation could optimize and not fire events when no one is listening. However mutation events has proved that even just checking for event listeners bares significant cost and complexity. Not to mention the fact that a feature isn't very useful if it slows down the page so much that you generally don't want to use it. This is slightly different for the IE implementation since they don't use real DOM Events. In particular I don't think they have a capturing phase. This makes event dispatch significantly faster. / Jonas On Tue, Feb 2, 2010 at 1:09 PM, Gregg Tavares g...@google.com wrote: I'm not sure if this is the correct place for this but: Has there been any discussion of adding an element.onresize event? The issue that has come up is the canvas tag, in 2d or 3d, when the canvas changes its displayed size, a webapp might want to respond by changing the size of the internal representation of the canvas. Unfortunately an appt has no way to know when the canvas's display size has changed. The developer can use window.onresize but that only triggers when the window itself has changed size. If the canvas element has changed size for some other reason (another element's css or size were changed for example) no window.onresize is sent and so their is no easy way to know the display size of the canvas changed. This could be added to just the canvas tag but it seems like it would be more appropriate to be added to all (visual?) elements. I can see for example, setting img.src depending on the display size of the img element or changing the content of a div depending on its display size.
Re: element.onresize
On 2/2/10 11:56 PM, Jonas Sicking wrote: The problem with this is one of performance. And the problem is also how to specify it so that resize events loops aren't possible (or at least not easy to cause). What if resize event listener causes a new resize ... -Olli Btw, discussion about DOM Events happens in www-...@w3.org
Re: Allow to return same NodeList object for queries like getElementsByTagName, getElementsByClassName and getElementsByName
Hey folks, Any thoughts on this? I think it would be wise to issue an errata against DOM 3 Core to allow caching of NodeLists, and make sure to fix this in DOM4. IE and Firefox seem to do it, and it can be a big performance benefit, so I think the DOM spec should allow it. The three errata needed would be: http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-A6C9094 Change return value of getElementsByTagName on Document from: NodeList A new NodeList object containing all the matched Elements. To: NodeList A NodeList object containing all the matched Elements. http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-getElBTNNS Change return value of getElementsByTagNameNS on Document from: NodeList A new NodeList object containing all the matched Elements. To: NodeList A NodeList object containing all the matched Elements. http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-A6C90942 Change return value of getElementsByTagNameNS on Element from: NodeList A new NodeList object containing all the matched Elements. To: NodeList A NodeList object containing all the matched Elements. If we agree to these errata, I would also suggest that related methods in HTML5 (getElementsByName, getElementsByClassName) should be consistent and should also not require a new NodeList every time. Does anyone disagree? Regards, Maciej On Jan 22, 2010, at 5:11 AM, Anton Muhin wrote: Good day. Currently DOM core 3 spec is somewhat inconsistent regarding if invocations of getElementsByTagName and alike must return a new NodeList or could cache this list. For Document it's mandated for both getElementsByTagName and getElementsByTagNameNS, but for Element, it's only worded for getElementsByTagNameNS, but not for getElementsByTagName. Maciej noticed as well difference between getElementsByTagName and other getElementsBy queries (see http://www.w3.org/Bugs/Public/show_bug.cgi?id=8792). And word new is missing from ECMAScript bindings spec: http://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html Is it possible to allow caching for those cases? Firefox caches those node lists for a long time (Maciej found the related bug https://bugzilla.mozilla.org/show_bug.cgi?id=140758). IE8 caches as well. Opera, Safari and Chrome do not. Performance-wise it's a notable win (the less js objects one needs to create, the more efficient and less memory consuming browser one gets). Given that node lists are live, what are the reasons for mandating creation of new object per query? yours, anton.
Re: Window id - an idea to make multi page web application easier
On Jan 29, 2010, at 6:36 AM, Sebastian Hennebrueder wrote: Arthur Barstow schrieb: Sebastian, All, On Jan 18, 2010, at 10:54 AM, ext Sebastian Hennebrueder wrote: About half a year ago I came up with an idea to add a unique window id as request header to each browser request. I published this initially on my website http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html Now, I have stumbled upon the WebApps Working Group and would like to introduce this here as well. WebApp'ers - does anyone have any feedback for Sebastian? Would this idea be more applicable to HTML5? -Art Barstow Hi Art, thank you for the feedback. HTML 5 defines precise scopes for per window or per browser which can be used by JavaScript. The missing bit is to pass a window id to the server with the HTTP request. I don't know to which spec this actually belongs to. I am hoping that people here can help me or finally convince me that my idea is useless. I think this request would be more appropriate for HTML5, yes. Please bring it to the HTML WG or WHATWG. Regards, Maciej
Re: [XHR2] AnonXMLHttpRequest()
On Feb 2, 2010, at 11:15 AM, Tyler Close wrote: On Sun, Jan 31, 2010 at 11:03 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious what practical differences there are between CORS with the credentials flag set to false and the origin set to null, and UMP. Are there any? The credentials flag in CORS is underspecified, so it's hard to answer this question. Can you be more specific? What is underspecified about it? Sounds like something we should fix. Since we've all noted that CORS and UMP take a different approach to the problem, I think it would be confusing to bundle them in a single spec. If CORS wants to be a superset of UMP, then I think it's best to write CORS as an extension of UMP, and so referencing UMP, rather than absorbing it. This specification layout would also make it easier to communicate the differences between an AnonXMLHttpRequest (or UniformRequest) and an XHR2; each would link to their corresponding spec document without needing to select only the relevant sub-sections. CORS algorithms are parameterized, so API specs don't have to link to a specific section, just define the input parameters. Does UMP have extension hooks sufficient to allow CORS to be written as a UMP extension as you suggest? Since UMP is also much smaller and simpler than CORS, I think it makes sense to push it through the standardization process at a faster pace than CORS. For example, I think it is reasonable to move UMP to Last Call as early as next month, or the even the end of this month. I'm not sure this makes sense if we want to maintain the subset relation. And if we don't want to maintain the subset relation, then I would oppose advancing UMP at all. Note: in light of the above, I think AnonXMLHttpRequest would be almost the same as XDomainRequest, the only difference being that it would send Origin: null instead of the sender's actual Origin. As the UMP spec notes, it is within the intersection of what has been commonly deployed across user-agents. I'm curious to learn Microsoft's assessment of UMP, since, as you note, it is very close to their own XDomainRequest. Actually, it's not within the intersection, since it requires Origin: null rather than the actual Origin. No user agent currently has an API that generates UMP-conformant requests. Regards, Maciej
Re: Allow to return same NodeList object for queries like getElementsByTagName, getElementsByClassName and getElementsByName
I definitely am in favor of this, unsurprisingly given that we've chosen to do this in Firefox. / Jonas On Tue, Feb 2, 2010 at 5:02 PM, Maciej Stachowiak m...@apple.com wrote: Hey folks, Any thoughts on this? I think it would be wise to issue an errata against DOM 3 Core to allow caching of NodeLists, and make sure to fix this in DOM4. IE and Firefox seem to do it, and it can be a big performance benefit, so I think the DOM spec should allow it. The three errata needed would be: http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-A6C9094 Change return value of getElementsByTagName on Document from: NodeList A new NodeList object containing all the matched Elements. To: NodeList A NodeList object containing all the matched Elements. http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-getElBTNNS Change return value of getElementsByTagNameNS on Document from: NodeList A new NodeList object containing all the matched Elements. To: NodeList A NodeList object containing all the matched Elements. http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-A6C90942 Change return value of getElementsByTagNameNS on Element from: NodeList A new NodeList object containing all the matched Elements. To: NodeList A NodeList object containing all the matched Elements. If we agree to these errata, I would also suggest that related methods in HTML5 (getElementsByName, getElementsByClassName) should be consistent and should also not require a new NodeList every time. Does anyone disagree? Regards, Maciej On Jan 22, 2010, at 5:11 AM, Anton Muhin wrote: Good day. Currently DOM core 3 spec is somewhat inconsistent regarding if invocations of getElementsByTagName and alike must return a new NodeList or could cache this list. For Document it's mandated for both getElementsByTagName and getElementsByTagNameNS, but for Element, it's only worded for getElementsByTagNameNS, but not for getElementsByTagName. Maciej noticed as well difference between getElementsByTagName and other getElementsBy queries (see http://www.w3.org/Bugs/Public/show_bug.cgi?id=8792). And word new is missing from ECMAScript bindings spec: http://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html Is it possible to allow caching for those cases? Firefox caches those node lists for a long time (Maciej found the related bug https://bugzilla.mozilla.org/show_bug.cgi?id=140758). IE8 caches as well. Opera, Safari and Chrome do not. Performance-wise it's a notable win (the less js objects one needs to create, the more efficient and less memory consuming browser one gets). Given that node lists are live, what are the reasons for mandating creation of new object per query? yours, anton.
RE: [IndexedDB] Detailed comments for the current draft
On Mon, Feb 1, 2010 at 1:30 AM, Jeremy Orlow jor...@google.com wrote: 1. Keys and sorting a. 3.1.1: it would seem that having also date/time values as keys would be important and it's a common sorting criteria (e.g. as part of a composite primary key or in general as an index key). The Web IDL spec does not support a Date/Time data type. Could your use case be supported by storing the underlying time with millisecond precision using an IDL long long type? I am willing to change the spec so that it allows long long instead of long IDL type, which will provide adequate support for Date and time sorting. Can the spec not be augmented? It seems like other specs like WebGL have created their own types. If not, I suppose your suggested change would suffice as well. This does seem like an important use case. I agree, either we could augment the spec or we could describe it in terms of Javascript object values. That is, we can say something specific about the treatment of Javascript's Date object. Would that be possible? E.g. we could require implementations to provide full order for dates if they find an instance of that type in a path. b. 3.1.1: similarly, sorting on number in general (not just integers/longs) would be important (e.g. price lists, scores, etc.) I am once again hampered by Web IDL spec. Is it possible to leave this for future versions of the spec? Actually Web IDL does define the double type and its Javascript binding. Can we add double to the list of types an index can be applied to? c. 3.1.1: cross type sorting and sorting of long values are clear. Sorting of strings however needs more elaboration. In particular, which collation do we use? Does the user or developer get to choose a collation? If we pick up a collation from the environment (e.g. the OS), if the collation changes we'd have to re-index all the databases. I propose to use Unicode collation algorithm, which was also suggested by Jonas during a conversation. I don't think this is specific enough, in that it still doesn't say which collation tables to use and how to specify them. A single collation strategy won't do for all languages (it'll range from slightly wrong to nonsense depending on the target language). This is a trickier area than I had initialize thought. We'll bake on this a bit and get back to this group with ideas. d. 3.1.3: spec reads .key path must be the name of an enumerated property.; how about composite keys (would make the related APIs take a DOMString or DOMStringList) I prefer to leave composite keys to a future version. I don't think we can get away with this. For indexes this is quite common (if anything else to have stable ordering when the prefix of the index has repeats). Once we have it for indexes the delta for having it for primary keys as well is pretty small (although I wouldn't oppose leaving out composite primary keys if that would help scope the feature). b. Query processing libraries will need temporary stores, which need temporary names. Should we introduce an API for the creation of temporary stores with transaction lifetime and no name? Firstly, I think we can leave this safely to a future version. Secondly, my suggestion would be to provide a parameter to the create call to indicate that an object store being created is a transient one, i.e., not backed by durable storage. They could be available across different transactions. If your intention is to not make these object stores unavailable across connections, then we can also offer a connection-specific transient object store. In general, it requires us to introduce the notion of create params, which would simplify the evolution of the API. This is also similar to how Berkeley DB handles various options, not just those related to creation of a Berkeley database. Let's see how we progress on this one, and maybe revisit it a bit later. I'm worried about code that wants to do things such as a block-sort that needs to spill to disk, as it would have to either use some pattern or ask the user for temp table names. c. It would be nice to have an estimate row count on each store. This comes at an implementation and runtime cost. Strong opinions? Lacking everything else, this would be the only statistic to base decisions on for a query processor. I believe we need to have a general way of estimating the number of records in a cursor once a key range has been specified. Kris Zyp also brings this up in a separate email. I am willing to add an estimateCount attribute to IDBCursor for this. EstimateCount sounds good. d. The draft does not touch on how applications would do optimistic concurrency. A common way of doing this is to use a timestamp value that's automatically updated by the system every time someone
Re: [IndexedDB] Detailed comments for the current draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/2/2010 8:37 PM, Pablo Castro wrote: d. 3.2.4.2: in our experiments writing application code, the fact that this method throws an exception when an item is not found is quite inconvenient. It would be much natural to just return undefined, as this can be a primary code path (to not find something) and not an exceptional situation. Same for 3.2.5, step 2 and 3.2.6 step 2. I am not comfortable specifying the API to be dependent on the separation between undefined and null. Since null is a valid return value, it doesn't make sense to return that either. The only safe alternative appears to be to throw an error. What do other folks think about this? I understand your concern, but it makes writing regular code really noisy as you need try/catch blocks to handle non-exceptional situations. I agree with returning undefined for non-existent keys. JavaScript objects are key-value sets, and they return undefined when you attempt to access a non-existent key. Consistency suggests that JavaScript database should do the same. I also agree with Pablo's point that users would be likely to turn to doing an exists() and get() call together, which would most likely be more expensive than a single get(). - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkto+I4ACgkQ9VpNnHc4zAzi+wCgqbHM+uYRUlgE8fX4br88IkFx k+AAoJRQ9aFmGx7hicGolb2jEnzxHJy8 =j7lx -END PGP SIGNATURE-
Re: [XHR2] AnonXMLHttpRequest()
On Tue, Feb 2, 2010 at 5:14 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 2, 2010, at 11:15 AM, Tyler Close wrote: On Sun, Jan 31, 2010 at 11:03 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious what practical differences there are between CORS with the credentials flag set to false and the origin set to null, and UMP. Are there any? The credentials flag in CORS is underspecified, so it's hard to answer this question. Can you be more specific? What is underspecified about it? Sounds like something we should fix. Nowhere does CORS define what a credential is. Nowhere does it list specific credentials a browser may have but should not use when the credential flag is false. Does CORS treat the Origin header as a credential? What other identifiers are not credentials? What about proxy credentials? Since we've all noted that CORS and UMP take a different approach to the problem, I think it would be confusing to bundle them in a single spec. If CORS wants to be a superset of UMP, then I think it's best to write CORS as an extension of UMP, and so referencing UMP, rather than absorbing it. This specification layout would also make it easier to communicate the differences between an AnonXMLHttpRequest (or UniformRequest) and an XHR2; each would link to their corresponding spec document without needing to select only the relevant sub-sections. CORS algorithms are parameterized, so API specs don't have to link to a specific section, just define the input parameters. This is far more confusing that just linking to the corresponding spec. There's too much extra information that only serves to confuse. The UMP spec will be consumed not just by API spec writers, but also by Web application developers. Does UMP have extension hooks sufficient to allow CORS to be written as a UMP extension as you suggest? UMP has a declarative specification. You extend UMP the same way you extend other HTTP-based protocols, by defining new protocol tokens and attaching semantics to them. For example, CORS would define new semantics for new values of the Access-Control-Allow-Origin header. Since UMP is also much smaller and simpler than CORS, I think it makes sense to push it through the standardization process at a faster pace than CORS. For example, I think it is reasonable to move UMP to Last Call as early as next month, or the even the end of this month. I'm not sure this makes sense if we want to maintain the subset relation. I don't follow, why does maintaining the subset relation preclude Last Call for UMP? It seems quite unfair for the maturity of the UMP specification to be held hostage by the CORS specification when UMP has no dependency on CORS. And if we don't want to maintain the subset relation, then I would oppose advancing UMP at all. Note: in light of the above, I think AnonXMLHttpRequest would be almost the same as XDomainRequest, the only difference being that it would send Origin: null instead of the sender's actual Origin. As the UMP spec notes, it is within the intersection of what has been commonly deployed across user-agents. I'm curious to learn Microsoft's assessment of UMP, since, as you note, it is very close to their own XDomainRequest. Actually, it's not within the intersection, since it requires Origin: null rather than the actual Origin. No user agent currently has an API that generates UMP-conformant requests. As you said above, there is a subset relation between CORS and UMP, which puts UMP in the intersection of existing CORS implementations. With some awkward messing around with iframes and such, I think the existing implementations can be made to put a non-meaningful identifier in the Origin header. Not a situation I'd want to work with going forward, but good enough to claim the intersection. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [XHR2] AnonXMLHttpRequest()
On Feb 2, 2010, at 9:42 PM, Tyler Close wrote: On Tue, Feb 2, 2010 at 5:14 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 2, 2010, at 11:15 AM, Tyler Close wrote: On Sun, Jan 31, 2010 at 11:03 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious what practical differences there are between CORS with the credentials flag set to false and the origin set to null, and UMP. Are there any? The credentials flag in CORS is underspecified, so it's hard to answer this question. Can you be more specific? What is underspecified about it? Sounds like something we should fix. Nowhere does CORS define what a credential is. Nowhere does it list specific credentials a browser may have but should not use when the credential flag is false. Does CORS treat the Origin header as a credential? What other identifiers are not credentials? What about proxy credentials? Fair point. It looks like the only actual statement about the effect of the credentials flag is: Whenever the make a request steps are applied, make a request to request URL, using method request method, entity body request entity body, including the custom request headers, and include credentials if the credentials flag is true (e.g. HTTP authentication data and cookies). There's two problems with this: (1) It's not normatively defined what constitutes a credential. (2) It says to include credentials when the credentials flag is true, but it doesn't say they must not be included when the credentials flag is false. I think the credentials flag should specifically affect cookies, http authentication, and client-side SSL certs, but not proxy authentication (or, obviously, Origin). Anne, can you fix this? Does UMP have extension hooks sufficient to allow CORS to be written as a UMP extension as you suggest? UMP has a declarative specification. You extend UMP the same way you extend other HTTP-based protocols, by defining new protocol tokens and attaching semantics to them. For example, CORS would define new semantics for new values of the Access-Control-Allow-Origin header. A CORS message would clearly not satisfy the declarative definition of a Uniform Request. Since this definition is based partly on what MUST NOT be included, I don't see any way to extend it. And if we don't want to maintain the subset relation, then I would oppose advancing UMP at all. Note: in light of the above, I think AnonXMLHttpRequest would be almost the same as XDomainRequest, the only difference being that it would send Origin: null instead of the sender's actual Origin. As the UMP spec notes, it is within the intersection of what has been commonly deployed across user-agents. I'm curious to learn Microsoft's assessment of UMP, since, as you note, it is very close to their own XDomainRequest. Actually, it's not within the intersection, since it requires Origin: null rather than the actual Origin. No user agent currently has an API that generates UMP-conformant requests. As you said above, there is a subset relation between CORS and UMP, which puts UMP in the intersection of existing CORS implementations. No existing CORS implementation will satisfy the requirements for a Uniform Request, as far as I can tell, since it includes information obtained from... the referring resource, including its origin. It is possible to send a request satisfying the Uniform Request requirements by passing the right parameters to CORS (a unique identifier origin would result in Origin: null being sent), so the subset relation exists at the protocol level. But I don't think any implementation will end up passing the right parameters to CRS, so the intersection of the subsets of CORS supported by existing implementations does not overlap the UMP subset of CORS. (I note also that the definition of Uniform Request includes some messages that could not be produced by CORS at all. For example it seems like it would be valid to send no Origin header at all, instead of Origin: null. This arguably violates the subset relation. It also allows a Uniform Request to look just like a same-origin XHR request from a legacy UA, which is not possible with CORS. Not sure if that is in itself a problem. This is in addition to the previously identified violation of the subset relation in redirect handling. where CORS will allow the client to read the results of following a redirect in some cases where CORS will not. Can we use some kind of bug tracker to track these issues?) With some awkward messing around with iframes and such, I think the existing implementations can be made to put a non-meaningful identifier in the Origin header. Not a situation I'd want to work with going forward, but good enough to claim the intersection. I don't see how? Making an XDR or XHR2 request will always send an Origin. Using an iframe and postMessage (or similar technique) you could get them to send a different Origin than the
