Re: Seeking pre-LCWD comments for: Server-sent Events, Web {Database, Sockets, Storage Workers}; deadline 19 November
On Nov 25, 2009, at 8:42 PM, Jeremy Orlow wrote: On Wed, Nov 25, 2009 at 5:16 PM, Nikunj R. Mehta nikunj.me...@oracle.com wrote: On Nov 24, 2009, at 7:40 PM, Ian Hickson wrote: On Fri, 20 Nov 2009, Arthur Barstow wrote: Based on the responses for this call for comments, I see the next steps as: 1. Server-sent Events, Web Storage and Web Workers - ready for LCWD publication. Later today I will begin a CfC to publish LCWD of these three specs 2. Web Sockets API - the group should discuss Adrian's comments: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0842.html 3. Web Database - there is sufficient interest to keep this spec on the Recommendation track. However, there is an open question about who will commit to drive this spec, in particular who will commit to being its Editor. Hixie - would you please explain your intent/position here? My intent with the Web SQL Database spec (or whatever I end up calling it) is to continue to drive it to REC, but without defining the SQL dialect in any more detail than the draft does now (as edited after the F2F). This suggests that we are unlikely to make any progress on the draft past this point. I would not consider multiple implementations all using the same SQL backend to be fully independent for the purposes of getting two interoperable implementations for the purpose of exiting CR, and thus I do not expect this spec to ever get past that stage. I don't see any logic in this that would benefit this WG. I think the logic behind the decision is already clear in this thread. I don't see why you're being so adamant about this when you're affected very little by the decision either way (except that your proposal has less competition I suppose). My position about WebDatabase has been the same for over 8 months now. Needless to say, objections are about the substance not the business benefit or otherwise. If you or others can offer a clear solution about the substance of my issue, I will gladly withdraw my objection. There is no benefit in us discussing reasons for why we have a substantive issue. It exists therefore I have the issue and I am not willing to look the other way. Oracle cares to avoid needless confusion and I don't think I am doing any disservice to this WG as Oracle's representative in stating its position, which is principled, constructive and transparent. What doesn't make sense is to put this WG through the effort knowing fully well that the result cannot be accomplished. The editor's proposal appears to be an attempt at circumventing the W3C process. Not every behavior you or other vendors implement is a good or a legal standard. It is hypocritical to condone attempts at standardizing such behaviors. Nikunj http://o-micron.blogspot.com
Re: [selectors-api] querySelector with namespace
On Nov 26, 2009, at 13:18, Jonathan Watt wrote: During a discussion about xml:id I was about to make the throw away comment that you could use querySelector to easily work around lack of support for xml:id, but on checking it turns out that's not the case. querySelector, it seems, cannot be used to select on a specific namespace, since you can only use namespace prefixes in selectors, and querySelector does not resolve prefixes. Isn't the easiest solution not to support xml:id on the Web? It's not supported in Gecko, WebKit or Trident. What's the upside of adding it? xml:id doesn't enable functionality that the id attribute on HTML, MathML or SVG elements doesn't enable, but xml:id comes with all sorts of complications. In addition to this complication, it has the complication that in an xml:id-enabled world, an element doesn't have a single attribute that has IDness. Instead, it has to have two (the natural choice flowing from XML specs) or the IDness of attributes has to depend on the presence of other attributes (the choice taken by SVG 1.2 Tiny). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [selectors-api] querySelector with namespace
On Thu, 26 Nov 2009 09:33:28 -0200, Henri Sivonen hsivo...@iki.fi wrote: On Nov 26, 2009, at 13:18, Jonathan Watt wrote: [...] Isn't the easiest solution not to support xml:id on the Web? It's not supported in Gecko, WebKit or Trident. What's the upside of adding it? Besides that, querySelector(#foo) and getElementById(foo) should work fine in xml:id implementations and both are much less cumbersome to type. -- Anne van Kesteren http://annevankesteren.nl/
Re: [selectors-api] querySelector with namespace
Jonathan Watt wrote: During a discussion about xml:id I was about to make the throw away comment that you could use querySelector to easily work around lack of support for xml:id, but on checking it turns out that's not the case. querySelector, it seems, cannot be used to select on a specific namespace, since you can only use namespace prefixes in selectors, and querySelector does not resolve prefixes. What is the use case for xml:id on the web? Maybe the working group could consider adding some sort of non-prefix namespace support to selectors for the sake of querySelector/querySelectorsAll, something like: [url(http://www.w3.org/XML/1998/namespace;)|id=foo] Your proposal would require modifying the syntax of Selectors, which is out of scope for this working group. As for the issue of resolving namespace prefixes, the previous attempt at including them in the API proved to be a very difficult, time consuming and costly effort that failed to reveal substantial use cases, nor find a viable solution. As such, my current position is that there has been insufficient justification provided for spending such significant time and effort addressing this issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] querySelector with namespace
On 2009-11-26 12:33 PM, Henri Sivonen wrote: On Nov 26, 2009, at 13:18, Jonathan Watt wrote: During a discussion about xml:id I was about to make the throw away comment that you could use querySelector to easily work around lack of support for xml:id, but on checking it turns out that's not the case. querySelector, it seems, cannot be used to select on a specific namespace, since you can only use namespace prefixes in selectors, and querySelector does not resolve prefixes. Isn't the easiest solution not to support xml:id on the Web? It's not supported in Gecko, WebKit or Trident. What's the upside of adding it? Please note my use of the phrase work around. Nowhere in my email did I suggest supporting xml:id on the Web. Nevertheless, that doesn't mean that Web content shouldn't be able to process XML that uses xml:id using script and present the processed information to the user using content and semantics that *does* belong on the Web. Anyway, please also note that xml:id was just the example that drew my attention to this defficency in querySelector. It's an example, nothing more. The deficiency is my focus here. xml:id doesn't enable functionality that the id attribute on HTML, MathML or SVG elements doesn't enable, but xml:id comes with all sorts of complications. In addition to this complication, it has the complication that in an xml:id-enabled world, an element doesn't have a single attribute that has IDness. Instead, it has to have two (the natural choice flowing from XML specs) or the IDness of attributes has to depend on the presence of other attributes (the choice taken by SVG 1.2 Tiny). I've been active in the Mozilla bug report filed for xml:id, so I'm aware of the issues. To my knowledge these have all been resolved satisfactorily, and the only reason the patch that was landed in Mozilla (net increase of 80 lines of code) didn't make it through to a release in 2007 was because of a performance regression, causing it to be removed. That issue is now also thought to be solved I believe. Having said all that, I'm not very keen on adding native support for xml:id. I'd rather just make 'id' in the null namespace special if at all possible. KISS, right? Anyways, back to my main point: script should be able to process arbitrary XML to present the results of that processing to the user using a belongs on the Web format, and better support for namespaces in querySelector would certainly help with that. Jonathan
Re: [selectors-api] querySelector with namespace
On 2009-11-26 1:16 PM, Lachlan Hunt wrote: Jonathan Watt wrote: Maybe the working group could consider adding some sort of non-prefix namespace support to selectors for the sake of querySelector/querySelectorsAll, something like: [url(http://www.w3.org/XML/1998/namespace;)|id=foo] Your proposal would require modifying the syntax of Selectors, which is out of scope for this working group. You're right, I'll email the CSS WG. As for the issue of resolving namespace prefixes, the previous attempt at including them in the API proved to be a very difficult, time consuming and costly effort that failed to reveal substantial use cases, nor find a viable solution. As such, my current position is that there has been insufficient justification provided for spending such significant time and effort addressing this issue. I don't think supporting prefixes in querySelector makes much sense. Jonathan
Re: [selectors-api] querySelector with namespace
On 2009-11-26 2:16 PM, Jonathan Watt wrote: On 2009-11-26 1:16 PM, Lachlan Hunt wrote: Jonathan Watt wrote: Maybe the working group could consider adding some sort of non-prefix namespace support to selectors for the sake of querySelector/querySelectorsAll, something like: [url(http://www.w3.org/XML/1998/namespace;)|id=foo] Your proposal would require modifying the syntax of Selectors, which is out of scope for this working group. You're right, I'll email the CSS WG. See http://lists.w3.org/Archives/Public/www-style/2009Nov/thread.html#msg321
[widgets] element-based localization
Hi, I'm trying to implement the element-based localization and I found the spec unclear with regards to the inheritance of th xml:lang attribute and I would like to propose some improved text. First, this attribute is listed as an optional attribute of the widget element but the widget element is not localizable, so one does not understand why. Then, many other elements (author, preference, icon, content ...) don't list this attribute and are not localizable but they can inherit the value of this attribute. The rest of the elements may have the attribute specified or inherited and use it for localization. The paragraph explaining this behavior says: If an element is marked as being localizable via xml:lang with the word no, it means that the element is not localizable via element-based localization. In other words, exclusion of an xml:lang on an element indicates that that element is unlocalized content, except in the case whereby a parent element uses xml:lang (this maintains consistency with the behavior of xml:lang as specified in the [XML] specification). Explicitly declaring xml:lang overrides any xml:lang value inherited from a parent element. I think this paragraph (especially the last 2 sentences) are unclear. I would propose that you clarify as follows: As per [XML] specification, the xml:lang attribute can be specified on any element, including in the widget namespace, and the normal behavior for this attribute shall be applied (i.e. inheritance processing, and propagation of the xml:lang attribute on elements on which it is not specified). However, in this specification, the value of the xml:lang attribute (inherited or specified) shall be used for element-based localization only on the elements that indicates Localizable via xml:lang: Yes. I would also propose to remove the definition of the xml:lang attribute such as: xml:lang Authoring Guidelines:It is optional for authors to use the xml:lang attribute with an name element. because even if not written, XML allows specifying this attribute on any element. Finally, I would also create some tests in the test-suite to check that inheritance is applied and used or not depending on the element type.WDYT? Best regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: CfC - publish Selectors API as CR
Maciej Stachowiak wrote: The proposed exit criteria are in a separate thread, but essentially are: For a set of tests based on HTML, CSS 2.1 selectors and this spec, there are two implementations that pass every test interoperably, and do not fail any additional tests based on misimplementing this specification (i.e. failures based on not supporting a technology used only in the additional tests, such as MathML, will not be taken into account). Request for clarification. Does this require: A) There must be two implementations, each of which passes every test (i.e. the same two implementations pass all the tests); or B) For each test, there are two implementations that pass it (but not necessarily the same two for every test). It reads like (A), but I have seen similar wording interpreted as (B) in the context of other specs... The intention in the original exit criteria proposal [1] was for there to be at least two complete implementations, each passing 100% of the baseline tests. I can make this clearer in the exit criteria as follows: --- There must be at least two complete, independent implementations, each of which must pass 100% of the baseline testsuite and should pass additional tests, dependent on the following conditions: * The implementations must be native implementations in shipping products. (JavaScript library implementations don't count). * The baseline testsuite comprises tests that check for conformance to all requirements in the API using only HTML and Selectors defined in CSS 2.1. * Tests using Selectors introduced in Selectors Level 3, or XHTML+SVG, are considered to be additional tests. * An additional test may be marked as N/A for an implementation if: - The test uses a selector that the implementation does not support - The test uses XHTML+SVG that the implementation does not support * Implementations are not required to pass all additional tests, however no failures must be caused by an incorrect implementation of the API itself. Failures of additional tests caused only by an incorrect implementation of Selectors do not count. --- The current state of implementations is as follows: Minefield: Baseline Tests: HTML/CSS2.1:PASS Additional Tests: HTML/CSS3: PASS Additional Tests: XHTML+SVG/CSS3: PASS Opera gogi (Internal build) Baseline Tests: HTML/CSS2.1:PASS Additional Tests: HTML/CSS3: FAIL 4 (non-API bugs) Additional Tests: XHTML+SVG/CSS3: FAIL 22 (non-API bugs) WebKit: Baseline Tests: HTML/CSS2.1:FAIL 16 (API bug) Additional Tests: HTML/CSS3: FAIL 16 Additional Tests: XHTML+SVG/CSS3: FAIL 16 IE8: Baseline Tests: HTML/CSS2.1:FAIL 252 (API bugs) Additional Tests: HTML/CSS3: N/A Additional Tests: XHTML+SVG/CSS3: N/A BlackBerry 9700 browser: (Kartikaya Gupta from RIM e-mailed me off list about this to tell me, I'm unable to verify these results myself without access to the device.) Baseline Tests: HTML/CSS2.1:PASS Additional Tests: HTML/CSS3: PASS Additional Tests: XHTML+SVG/CSS3: PASS With Minefield and BlackBerry, we have two complete implementations passing everything. Opera's results also meet the above criteria, so that gives us 3 implementations. [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1221.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] querySelector with namespace
Jonathan Watt wrote: On 2009-11-26 12:33 PM, Henri Sivonen wrote: On Nov 26, 2009, at 13:18, Jonathan Watt wrote: During a discussion about xml:id I was about to make the throw away comment that you could use querySelector to easily work around lack of support for xml:id, but on checking it turns out that's not the case. querySelector, it seems, cannot be used to select on a specific namespace, since you can only use namespace prefixes in selectors, and querySelector does not resolve prefixes. Isn't the easiest solution not to support xml:id on the Web? It's not supported in Gecko, WebKit or Trident. What's the upside of adding it? Please note my use of the phrase work around. Nowhere in my email did I suggest supporting xml:id on the Web. Nevertheless, that doesn't mean that Web content shouldn't be able to process XML that uses xml:id using script and present the processed information to the user using content and semantics that *does* belong on the Web. Anyway, please also note that xml:id was just the example that drew my attention to this defficency in querySelector. It's an example, nothing more. The deficiency is my focus here. I really do not understand what use case you are trying to address. It appears that you are trying to find a solution to a problem that does not exist. Why does it matter that the API can't select xml:id using a selector involving namespaces, especially given that xml:id is not used on the web, and even if it was, the ID selector would work fine? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC - publish Selectors API as CR
Lachlan Hunt wrote: There must be at least two complete, independent implementations, each of which must pass 100% of the baseline testsuite and should pass additional tests, dependent on the following conditions: ... The current state of implementations is as follows: Minefield: Baseline Tests: HTML/CSS2.1: PASS Additional Tests: HTML/CSS3: PASS Additional Tests: XHTML+SVG/CSS3: PASS Opera gogi (Internal build) Baseline Tests: HTML/CSS2.1: PASS Additional Tests: HTML/CSS3: FAIL 4 (non-API bugs) Additional Tests: XHTML+SVG/CSS3: FAIL 22 (non-API bugs) ... With Minefield and BlackBerry, we have two complete implementations passing everything. Opera's results also meet the above criteria, so that gives us 3 implementations. Actually, correction. Minefield and Opera don't meet the condition if we keep the shipping requirement in the exit criteria. But as soon as either of those builds make it into release products, we'll be good to go. Alternatively, we could just say public development builds are good enough, and Minefield would count, but I don't see any problem with just waiting. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[widgets] test-suite, default xml:lang
Hi all, I'm trying to understand the difference between two tests: [1] http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-UEMbyHERkI/000/config.xml [2] http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-UEMbyHERkI/003/config.xml In [1], the first description element is supposed to be the valid one (it does not have an xml:lang attribute). In [2], the first description element as a dummy xml:lang that's not supposed to match anything. The second description element does not have the xml:lang attribute, but according to the expected result, it should not be the selected one. I don't understand why? Can you explain what the user locale should be in both cases? The test suite document indicates that it should be en. If this is the case, in [1] no description element shall match. Otherwise you probably want to indicate that some tests assumes * like [1] and others en like [2]. Am I wrong? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: CfC - publish Selectors API as CR
On Thu, 26 Nov 2009 15:58:56 +0100, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Lachlan Hunt wrote: There must be at least two complete, independent implementations, each of which must pass 100% of the baseline testsuite and should pass additional tests, dependent on the following conditions: ... The current state of implementations is as follows: Minefield: Baseline Tests: HTML/CSS2.1: PASS Additional Tests: HTML/CSS3: PASS Additional Tests: XHTML+SVG/CSS3: PASS Opera gogi (Internal build) Baseline Tests: HTML/CSS2.1: PASS Additional Tests: HTML/CSS3: FAIL 4 (non-API bugs) Additional Tests: XHTML+SVG/CSS3: FAIL 22 (non-API bugs) ... With Minefield and BlackBerry, we have two complete implementations passing everything. Opera's results also meet the above criteria, so that gives us 3 implementations. Actually, correction. Minefield and Opera don't meet the condition if we keep the shipping requirement in the exit criteria. But as soon as either of those builds make it into release products, we'll be good to go. Alternatively, we could just say public development builds are good enough, and Minefield would count, but I don't see any problem with just waiting. And I don't see any problem with using public development builds. Opinions? cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [widgets] about test d1.wgt
Hi Marcos, Marcos Caceres a écrit : Hi Cyril, On Fri, Nov 20, 2009 at 5:50 PM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi, The test d1.wgt is about the src attribute of the icon element. It says that it tests the following assertion: If the src attribute of this icon element is absent, then the user agent must ignore this element. but the config.xml contains an src attribute with an empty value. This seems a bit different to me. Maybe you should modify the spec as follows: If the src attribute of this icon element is absent *or empty*, then the user agent must ignore this element. Well, you get the same result when you actually search for the file , as it won't be found. But I agree, a simple clarification there won't actually hurt or change the ways UAs work at the moment. Also you should make sure the tests are aligned between the icon element and the content element. There does not seem to be such test with the content element. If you make such test, you should also align the spec in the same manner. I'm not sure I understand, can you design the test to show what you mean. I can then add it to the test suite. I meant that there is test like: widget xmlns=http://www.w3.org/ns/widgets; icon src=/ /widget but no test like: widget xmlns=http://www.w3.org/ns/widgets; content src= / /widget Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: CfC - publish Selectors API as CR
BlackBerry 9700 browser: (Kartikaya Gupta from RIM e-mailed me off list about this to tell me, I'm unable to verify these results myself without access to the device.) Baseline Tests: HTML/CSS2.1:PASS Additional Tests: HTML/CSS3: PASS Additional Tests: XHTML+SVG/CSS3: PASS Slight correction, the 9700 publicly-available build has some of the tests failing. The BlackBerry 9550 does pass all tests though. I ran the tests on the device simulator available from http://na.blackberry.com/eng/developers/resources/simulators.jsp and grabbed the following screenshots of the completed tests: http://stakface.com/pub/mango/selapi-suite1.jpg http://stakface.com/pub/mango/selapi-suite2.jpg http://stakface.com/pub/mango/selapi-suite3.jpg Note that if you plan to try this out yourself on a device or the simulator you'll need to uncheck the Terminate slow-running scripts checkbox in the browser options for it to work, since otherwise our javascript watchdog will kick in and kill the script before it's done. Cheers, kats
Re: CfC - publish Selectors API as CR
On 11/26/09 9:58 AM, Lachlan Hunt wrote: Actually, correction. Minefield and Opera don't meet the condition if we keep the shipping requirement in the exit criteria. Which imo we should. I don't think we want to be opening up that loophole. The Gecko 1.9.2 branch builds have the null/undefined issues, right? -Boris
Re: CfC - publish Selectors API as CR
On 11/26/09 11:52 AM, Charles McCathieNevile wrote: And I don't see any problem with using public development builds. The main problem I have with them is that they have typically not gone through the sort of full QA cycle that would point out possible problems in the implementation of the bad interaction with other specs or deployed content kind. One would hope that such issues were caught during spec writing, but I think this is an important sanity-check. Of course in this view not all implementations are equal (e.g. a walled-garden implementation wouldn't have the same compatibility constraints as web-facing one)... Not sure that others see this requirement in the same light as I do. -Boris
Re: CfC - publish Selectors API as CR
Boris Zbarsky wrote: On 11/26/09 9:58 AM, Lachlan Hunt wrote: Actually, correction. Minefield and Opera don't meet the condition if we keep the shipping requirement in the exit criteria. Which imo we should. I don't think we want to be opening up that loophole. The Gecko 1.9.2 branch builds have the null/undefined issues, right? If that's the branch that's going into Firefox 3.6, yes. Personally, I added the shipping requirement to the exit criteria when I revised it earlier today for basically the same reasons you outlined in your other e-mail, so I agree we should keep the requirement. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC - publish Selectors API as CR
On Thu, 26 Nov 2009 21:05:31 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 11/26/09 9:58 AM, Lachlan Hunt wrote: Actually, correction. Minefield and Opera don't meet the condition if we keep the shipping requirement in the exit criteria. Which imo we should. I don't think we want to be opening up that loophole. I agree. Without it, we could end up in a situation where there are two development builds passing the testsuite, so the spec exits CR, and during the beta phase the implementors find that something needs to change for Web compat. I think we should maybe even require the implementations to have been shipping for some amount of time, since some issues aren't found until the implementation is used on a wide scale. -- Simon Pieters Opera Software
Re: CfC - publish Selectors API as CR
Lachlan Hunt wrote: Maciej Stachowiak wrote: The proposed exit criteria are in a separate thread, but essentially are: For a set of tests based on HTML, CSS 2.1 selectors and this spec, there are two implementations that pass every test interoperably, and do not fail any additional tests based on misimplementing this specification (i.e. failures based on not supporting a technology used only in the additional tests, such as MathML, will not be taken into account). Request for clarification. Does this require: A) There must be two implementations, each of which passes every test (i.e. the same two implementations pass all the tests); or B) For each test, there are two implementations that pass it (but not necessarily the same two for every test). It reads like (A), but I have seen similar wording interpreted as (B) in the context of other specs... The intention in the original exit criteria proposal [1] was for there to be at least two complete implementations, each passing 100% of the baseline tests. I can make this clearer in the exit criteria as follows: --- There must be at least two complete, independent implementations, each of which must pass 100% of the baseline testsuite and should pass additional tests, dependent on the following conditions: * The implementations must be native implementations in shipping products. (JavaScript library implementations don't count). What is the reason for the native implementation requirement? Is it W3C policy? Sean
Selectors CR criteria (was re: Something else)
On Thu, 26 Nov 2009 23:04:35 +0100, Sean Hogan shogu...@westnet.com.au wrote: Lachlan Hunt wrote: ... * The implementations must be native implementations in shipping products. (JavaScript library implementations don't count). What is the reason for the native implementation requirement? Is it W3C policy? Nope. But we figured that we wanted this to be clearly tested for the real world, and some people think that insisting on it being native implementation shows that more clearly. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
