Re: IndexedDB: negative zero as keys/values
On Friday, September 16, 2011, Joshua Bell wrote:
> There appears to be a minor edge case in the IndexedDB draft (
http://www.w3.org/TR/IndexedDB) - and inconsistencies between
implementations - for the ECMAScript "negative zero" number value. While the
other numeric edge cases - NaN and +/-Infinity - are called out explicitly
in the draft when discussing keys, negative zero is not. The intended
handling of -0 in values could, in theory, be covered by the HTML5
structured clone algorithm (
http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data),
but it also has no explicit mention of -0.
> In Chrome 14, -0 and 0 are treated as the same key, and -0 values are read
back as 0. In Firefox 6, -0 is preserved as a value, but 0 and -0 are
treated as the same key. (I have not tested IE10)
> e.g.
>store.put(-0, 'key for -0');
>store.put('value for key -0', -0);
>store.put('value for key 0', 0);
>store.get('key for -0').onsuccess = function (e) {
> assertEqual(-0, e.target.result, '-0 as a value'); };
>store.get(-0)..onsuccess = function (e) {
> assertEqual('value for key -0', e.target.result, '-0 as a key');
};
> ... for some suitably -0-aware assertEqual comparison - e.g.
http://wiki.ecmascript.org/doku.php?id=harmony:egal
> This will "fail" in both cases in Chrome 14, and "fail" in the second case
only in Firefox 6.
> In other words, in at least these two current implementations, -0 is
treated as the same key as 0. However, the two current implementations
disagree about storing/retrieving -0 values.
> Should the draft codify the handling of -0 in keys? And is the handling of
-0 in values properly deferred to the structured clone algorithm?
Given that -0 === 0 in JS, and that IEEE754 defines that -0 is equal to 0, I
think we should treat them as the same key.
As to what to return for a key when -0 was originally used, I don't really
have a strong opinion.
/ Jonas
IndexedDB: negative zero as keys/values
There appears to be a minor edge case in the IndexedDB draft (
http://www.w3.org/TR/IndexedDB) - and inconsistencies between
implementations - for the ECMAScript "negative zero" number value. While the
other numeric edge cases - NaN and +/-Infinity - are called out explicitly
in the draft when discussing keys, negative zero is not. The intended
handling of -0 in values could, in theory, be covered by the HTML5
structured clone algorithm (
http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data),
but it also has no explicit mention of -0.
In Chrome 14, -0 and 0 are treated as the same key, and -0 values are read
back as 0. In Firefox 6, -0 is preserved as a value, but 0 and -0 are
treated as the same key. (I have not tested IE10)
e.g.
store.put(-0, 'key for -0');
store.put('value for key -0', -0);
store.put('value for key 0', 0);
store.get('key for -0').onsuccess = function (e) {
assertEqual(-0, e.target.result, '-0 as a value'); };
store.get(-0).onsuccess = function (e) {
assertEqual('value for key -0', e.target.result, '-0 as a key'); };
for some suitably -0-aware assertEqual comparison - e.g.
http://wiki.ecmascript.org/doku.php?id=harmony:egal
This will "fail" in both cases in Chrome 14, and "fail" in the second case
only in Firefox 6.
In other words, in at least these two current implementations, -0 is treated
as the same key as 0. However, the two current implementations disagree
about storing/retrieving -0 values.
Should the draft codify the handling of -0 in keys? And is the handling of
-0 in values properly deferred to the structured clone algorithm?
-- Josh
Re: [editing] Using public-webapps for editing discussion
Apologies to Tab and Aryeh, I did not mean to suggest that they, nor their employer, have any bad intent in the specs process. I have no doubt, that they have the best of intentions. -Charles On 9/16/11 12:06 PM, Doug Schepers wrote: Hi, Charles- I understand that it is frustrating to butt heads with a set of people who all share similar perspective and priorities, if you do not share those particular views. However, I don't think it's productive to impute that a specific company is pushing their agenda, or blocking progress on other efforts. For example, I've spoken to many Google people with different perspectives and goals (often at odds with other Googlers), and there are also many people outside Google who share some of the same opinions and methods as Hixie, Tab, and Aryeh, like Anne, Ms2ger, Marcos, Maciej, and many others (though there are many ways in which they all differ, as well). Nor is this the only cadre of like minds in W3C and web standards; the accessibility community, the XML community, the SVG community... many people with similar backgrounds or interests tend to bond and work together toward a goal. Google is a diverse company with a wide diversity of opinions, like many companies; if they are active in web standards, it should be no surprise, since they are a Web company, with a search engine, browser, advertising service, and many prominent webapps. I don't think it's accurate or productive to single Google out as some sort of "bad player" here. If you differ with individuals or sets of individuals, that is certainly a valid critique, is it is kept to the topic of process, working methods, or technical matters. Please don't stray into the slippery slope of accusing companies of malice. Instead, raise technical issues, with solid use cases and requirements, and defend your point. That said, if you (or anyone) believe that there is collusion or willful or abusive disregard of comments (yours or anyone else's), then bring it to the attention of me or the chairs, and we will look into it. In the case of the HTML Editing APIs, I haven't seen anything particularly harmful yet... we're in an experimental stage with Community Groups, and I think it's healthy to look at alternative working modes and processes. So... please tone it down a bit... don't risk being seen as the guy who screams, "Company X is evil!!!", because nobody listens to that guy. ^_^ Thanks- -Doug Schepers W3C Developer Outreach Project Coordinator, SVG, WebApps, Touch Events, and Audio WGs On 9/16/11 1:44 PM, Charles Pritchard wrote: On 9/15/2011 1:26 PM, Aryeh Gregor wrote: > Apple, Google and Microsoft representatives have vetoed rich text editing as > a supported use case for public-canvas-api, the Google/WHATWG editing > specification is now the -only- supported solution for developers to author > editing environments. It is not accurate to refer to the specification as Google or WHATWG. It's in the public domain, so Google has no more right to it than anyone else. Google paid for its development up to this point, but no one from Google but me has exercised any discretion as to its contents, and I'll continue working on it under different employment if necessary. The spec has nothing to do with the WHATWG, except that I used their mailing list for a while. Google's support of editors is a net benefit for all of us. I greatly appreciate the CC0 license that you and other editors have put onto your specs. That said, Google's support of various editors that have disdain for W3C process, has real-world consequences. You're not alone, amongst your co-workers when you state: "I don't believe that the W3C Process is useful, and in fact I think it's actively harmful" I don't think it's malicious. But, Google has unprecedented control over these W3C specs. They are absolutely using that control to benefit their priorities. That's their right, as you say: "my time is my own or my employer's, and no one else has any right to place demands on how I spend it". This puts non-vendors in a bad situation. Where Google has purchased the space to play both sides of the game, the rest of us are struggling to have our use cases accepted as legitimate. By funding so many editors, for so many years, they gained control of the specs. That's fine... But the specs are now driven by individuals who have no deference to the W3C, and thus, no deference to the use cases that various member organizations and developers are -actively- engaged in. Yes, you have a public domain document, and yes, you're likely in the same boat as Tab Atkins: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1265.html "The editor is the *lowest* level in the hierarchy of constituencies" The "vendor" implementation is the highest level... Your company has the full vertical. They use that position to knock-down use cases. When a use case serves Google Docs, or Gmail, it's heard. When i
[Bug 14068] Think about what to return for backColor/hiliteColor value if it winds up being fully transparent
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14068 Aryeh Gregor changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Aryeh Gregor 2011-09-16 20:51:06 UTC --- https://dvcs.w3.org/hg/editing/rev/846e125a5e07 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [DOM4] Remove Node.isSameNode
On Fri, Sep 9, 2011 at 6:38 PM, Sean Hogan wrote: > On 10/09/11 11:00 AM, Jonas Sicking wrote: >> >> On Fri, Sep 9, 2011 at 2:27 PM, Sean Hogan >> wrote: >>> >>> On 10/09/11 3:21 AM, Jonas Sicking wrote: It's a completely useless function. It just implements the equality operator. I believe most languages have a equality operator already. Except Brainfuck [1]. But the DOM isn't implementable in Brainfuck anyway as it doesn't have objects, so I'm ok with that. [1] http://en.wikipedia.org/wiki/Brainfuck >>> >>> If a DOM implementation returns node-wrappers instead of exposing the >>> actual nodes then you could end up with different node-refs for the same >>> node. I'm not sure whether that violates other requirements of the spec. >> >> I would expect that to violate the DOM spec. I.e. I would say that if >> an implementation returned true for >> >> someNode.firstChild != someNode.firstChild >> >> then I would say that that that shouldn't be allowed by the DOM. >> >> / Jonas >> > The other scenario I can think of is casting. What if I want an object that > only implements the Element interface of an element, even if it is a > HTMLInputElement? The two objects will not be equal, but will represent the > same node. I imagine that was the motivation for initially including the > method. JS doesn't have casting. At a minimum it should be removed from JS bindings. > Having said that, if no-one is using it then it is completely useless.
Re: [editing] Using public-webapps for editing discussion
Hi, Charles- I understand that it is frustrating to butt heads with a set of people who all share similar perspective and priorities, if you do not share those particular views. However, I don't think it's productive to impute that a specific company is pushing their agenda, or blocking progress on other efforts. For example, I've spoken to many Google people with different perspectives and goals (often at odds with other Googlers), and there are also many people outside Google who share some of the same opinions and methods as Hixie, Tab, and Aryeh, like Anne, Ms2ger, Marcos, Maciej, and many others (though there are many ways in which they all differ, as well). Nor is this the only cadre of like minds in W3C and web standards; the accessibility community, the XML community, the SVG community... many people with similar backgrounds or interests tend to bond and work together toward a goal. Google is a diverse company with a wide diversity of opinions, like many companies; if they are active in web standards, it should be no surprise, since they are a Web company, with a search engine, browser, advertising service, and many prominent webapps. I don't think it's accurate or productive to single Google out as some sort of "bad player" here. If you differ with individuals or sets of individuals, that is certainly a valid critique, is it is kept to the topic of process, working methods, or technical matters. Please don't stray into the slippery slope of accusing companies of malice. Instead, raise technical issues, with solid use cases and requirements, and defend your point. That said, if you (or anyone) believe that there is collusion or willful or abusive disregard of comments (yours or anyone else's), then bring it to the attention of me or the chairs, and we will look into it. In the case of the HTML Editing APIs, I haven't seen anything particularly harmful yet... we're in an experimental stage with Community Groups, and I think it's healthy to look at alternative working modes and processes. So... please tone it down a bit... don't risk being seen as the guy who screams, "Company X is evil!!!", because nobody listens to that guy. ^_^ Thanks- -Doug Schepers W3C Developer Outreach Project Coordinator, SVG, WebApps, Touch Events, and Audio WGs On 9/16/11 1:44 PM, Charles Pritchard wrote: On 9/15/2011 1:26 PM, Aryeh Gregor wrote: > Apple, Google and Microsoft representatives have vetoed rich text editing as > a supported use case for public-canvas-api, the Google/WHATWG editing > specification is now the -only- supported solution for developers to author > editing environments. It is not accurate to refer to the specification as Google or WHATWG. It's in the public domain, so Google has no more right to it than anyone else. Google paid for its development up to this point, but no one from Google but me has exercised any discretion as to its contents, and I'll continue working on it under different employment if necessary. The spec has nothing to do with the WHATWG, except that I used their mailing list for a while. Google's support of editors is a net benefit for all of us. I greatly appreciate the CC0 license that you and other editors have put onto your specs. That said, Google's support of various editors that have disdain for W3C process, has real-world consequences. You're not alone, amongst your co-workers when you state: "I don't believe that the W3C Process is useful, and in fact I think it's actively harmful" I don't think it's malicious. But, Google has unprecedented control over these W3C specs. They are absolutely using that control to benefit their priorities. That's their right, as you say: "my time is my own or my employer's, and no one else has any right to place demands on how I spend it". This puts non-vendors in a bad situation. Where Google has purchased the space to play both sides of the game, the rest of us are struggling to have our use cases accepted as legitimate. By funding so many editors, for so many years, they gained control of the specs. That's fine... But the specs are now driven by individuals who have no deference to the W3C, and thus, no deference to the use cases that various member organizations and developers are -actively- engaged in. Yes, you have a public domain document, and yes, you're likely in the same boat as Tab Atkins: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1265.html "The editor is the *lowest* level in the hierarchy of constituencies" The "vendor" implementation is the highest level... Your company has the full vertical. They use that position to knock-down use cases. When a use case serves Google Docs, or Gmail, it's heard. When it does not, it's shuttered. That's a problem. And it comes up again and again. With all of the best intentions, you are a part of that group. It's not a malicious interaction, it's not something I'm overly concerned about. But it is real. Lucky
Whoa! [Was: Re: [editing] Using public-webapps for editing discussion]
Hi All, This thread has taken a few twists and turns and is now relatively far from Aryeh's original question of "Does anyone object to public-webapps being used to discuss the HTML Editing spec?". I will start a separate RfC or CfC on that specific question. In the meantime, if you want to continue discussions that go beyond the narrow scope of the original question, I ask that you *please* continue on some other Public list (perhaps www-talk or www-archive) and not use public-webapps. Some very good points about general process issues have been raised in this thread. I am not trying to stop discussions on the broader process issues. On the contrary, I encourage everyone to continue those discussions elsewhere (perhaps use www-archive as the default?). (I have previously proposed the W3C create a Public mail list for general process-related discussions but received negative feedback. I will try again and will report back if I get some "joy"). -AB On 9/16/11 2:20 PM, ext Tab Atkins Jr. wrote: On Fri, Sep 16, 2011 at 10:44 AM, Charles Pritchard wrote: Yes, you have a public domain document, and yes, you're likely in the same boat as Tab Atkins: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1265.html "The editor is the *lowest* level in the hierarchy of constituencies" The "vendor" implementation is the highest level... Your company has the full vertical. Incorrect. Browsers are below authors, who are below users. The full hierarchy of constituencies that I and several others subscribe to is: 1. Users 2. Authors 3. Implementors 4. Spec Authors / Theoretical Purity (these two levels are close enough that they're not really useful to distinguish, I think) They use that position to knock-down use cases. When a use case serves Google Docs, or Gmail, it's heard. When it does not, it's shuttered. That's quite a forceful statement. It's also completely untrue. For example, I have never talked to the Gmail team about my work. I've talked to Docs, but only about CSSOM measurement APIs because it's hard to gather concrete use-cases for some of these things even though they're obviously useful. I would appreciate not being publicly slandered in the future. ~TJ
Re: [editing] Using public-webapps for editing discussion
On Fri, Sep 16, 2011 at 1:44 PM, Charles Pritchard wrote: > I don't think it's malicious. But, Google has unprecedented control over > these W3C specs. > They are absolutely using that control to benefit their priorities. Google has exercised no control over my spec. I've written it entirely at my own discretion. Various individuals have given me feedback publicly or privately about the spec, and I've taken their feedback into consideration based on what I think its technical merits are. The two people who have the most influence are Ehsan Akhgari (Mozilla) and Ryosuke Niwa (Google), because they're the ones who will be implementing it. I don't give Ryosuke any more say than Ehsan just because he works for Google. Nor do I care more about Google products than others, except to the extent that they're more popular or I'm more familiar with them or the teams that develop them give more or better feedback. Just to be absolutely clear here: I'm an outside contractor working for Google. I have never set foot inside a Google office, nor do I have access to any internal Google mailing lists or other resources. The only time I've met in person with anyone from Google about my work was at a two-day Mozilla/Google meetup a few weeks back at Mozilla Toronto. The only person within Google who has any direct authority over my work is Ian Hickson, and he hasn't read most of the spec, let alone told me how I should write it. Google employees send me feedback publicly and privately, but so do others. The extent of Google's involvement with my work is Hixie suggesting I work on HTML editing, and me submitting an invoice occasionally and getting paid. If you want to say that in the end I only care what browser implementers think, that's a fair point. But Google has nothing to do with it. > This puts non-vendors in a bad situation. Where Google has purchased the > space to play both sides of the game, the rest of us are struggling to have > our use cases accepted as legitimate. By funding so many editors, for so > many years, they gained control of the specs. Google has no control over the specs in practice. Individuals do, who in some cases are paid by Google. I am not receiving any marching orders from higher-ups beyond "write specs for browsers to implement", and from what I've heard, the same is true for regular employees of Google too. If you would like to criticize our approaches to spec writing, criticize them as the individual opinions they are, not as part of a plot by Google. > They use that position to knock-down use cases. When a use case serves > Google Docs, or Gmail, it's heard. When it does not, it's shuttered. Point me to anywhere where I ignore use-cases because of who presented them. (Obviously, except for the fact that I'll prioritize use-cases that affect more users.) I'll listen very seriously to what anyone on the Gmail or Docs team says, but no more than Yahoo! Mail or TinyMCE or any other major HTML editing developers. The goal is to make APIs that anyone can use. All this is beside the point, though. If you want more feedback from W3C stakeholders, then you should be happy that I want to use the public-webapps list.
Re: [editing] Using public-webapps for editing discussion
On Fri, Sep 16, 2011 at 10:44 AM, Charles Pritchard wrote: > Yes, you have a public domain document, and yes, you're likely in the same > boat as Tab Atkins: > http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1265.html > "The editor is the *lowest* level in the hierarchy of constituencies" > > The "vendor" implementation is the highest level... Your company has the > full vertical. Incorrect. Browsers are below authors, who are below users. The full hierarchy of constituencies that I and several others subscribe to is: 1. Users 2. Authors 3. Implementors 4. Spec Authors / Theoretical Purity (these two levels are close enough that they're not really useful to distinguish, I think) > They use that position to knock-down use cases. When a use case serves > Google Docs, or Gmail, it's heard. When it does not, it's shuttered. That's quite a forceful statement. It's also completely untrue. For example, I have never talked to the Gmail team about my work. I've talked to Docs, but only about CSSOM measurement APIs because it's hard to gather concrete use-cases for some of these things even though they're obviously useful. I would appreciate not being publicly slandered in the future. ~TJ
Re: [editing] Using public-webapps for editing discussion
On 9/15/2011 1:26 PM, Aryeh Gregor wrote: > Apple, Google and Microsoft representatives have vetoed rich text editing as > a supported use case for public-canvas-api, the Google/WHATWG editing > specification is now the -only- supported solution for developers to author > editing environments. It is not accurate to refer to the specification as Google or WHATWG. It's in the public domain, so Google has no more right to it than anyone else. Google paid for its development up to this point, but no one from Google but me has exercised any discretion as to its contents, and I'll continue working on it under different employment if necessary. The spec has nothing to do with the WHATWG, except that I used their mailing list for a while. Google's support of editors is a net benefit for all of us. I greatly appreciate the CC0 license that you and other editors have put onto your specs. That said, Google's support of various editors that have disdain for W3C process, has real-world consequences. You're not alone, amongst your co-workers when you state: "I don't believe that the W3C Process is useful, and in fact I think it's actively harmful" I don't think it's malicious. But, Google has unprecedented control over these W3C specs. They are absolutely using that control to benefit their priorities. That's their right, as you say: "my time is my own or my employer's, and no one else has any right to place demands on how I spend it". This puts non-vendors in a bad situation. Where Google has purchased the space to play both sides of the game, the rest of us are struggling to have our use cases accepted as legitimate. By funding so many editors, for so many years, they gained control of the specs. That's fine... But the specs are now driven by individuals who have no deference to the W3C, and thus, no deference to the use cases that various member organizations and developers are -actively- engaged in. Yes, you have a public domain document, and yes, you're likely in the same boat as Tab Atkins: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1265.html "The editor is the *lowest* level in the hierarchy of constituencies" The "vendor" implementation is the highest level... Your company has the full vertical. They use that position to knock-down use cases. When a use case serves Google Docs, or Gmail, it's heard. When it does not, it's shuttered. That's a problem. And it comes up again and again. With all of the best intentions, you are a part of that group. It's not a malicious interaction, it's not something I'm overly concerned about. But it is real. Lucky for all of us, WebKit is open source, it's very open to community contributions, and the upstream is shared by several major vendors. -Charles
Re: Widgets & ApplicationCache
On 9/16/11 8:00 AM, Dominique Hazael-Massieux wrote: Le vendredi 16 septembre 2011 à 21:36 +0700, Marcos Caceres a écrit : I think they are actually not so different, and share many use cases. Ok, I strongly object in the strongest of terms to them being put together and I'm more than happy to debate any argument you might have for lumping them together. Here we go :) http://www.w3.org/2011/web-apps-ws/ Dominique is not the only one to be wondering about the distinction. I've been watching Google implement their .crx packaging mechanism over the past year and a half: in that time, they've not reconciled the two distribution strategies any further. Hosted apps, still, are what we are looking at for distribution. A hosted app consists of a very simple permissions manifest (title, author, url, permissions requested) and for efficiency and offline use, a website that implements applicationCache. Google has also, for some time, carried a development flag "CRX-less Web Apps - Enables support for installing Chrome apps that are deployed using a manifest file on a webpage, rather than by packaging the manifest and icons into a crx file.". This brings packaging even closer to the applicationCache model. As a developer, I'd like to see a little bit of both: I'd like to be able to ship all of my content in a Widget, to save myself the use of bandwidth, but allow the application to be updated via applicationCache mechanisms. ApplicationCache can be used to group a bunch of HTML, CSS and JS files that constitue an "installable application" (e.g. the way the iOS safari browser let you save to your homescreen an offline Web app when an application cache is present). I'm sorry, but that has absolutely nothing to do with Application cache. It's done like this: Sure, that bits helps for having an icon on the homescreen; it's fair to say that rel="apple-touch-icon" (and its standard equivalent rel="icon" with the sizes attribute) completes ApplicationCache in matching the features that widget packaging provides. But without the application cache, your nice and shiny icon won't load anything if you're not connected; is the equivalent to in config.xml, where ApplicationCache is the list of files encoded in the Zip file. It's also quite similar to favicon. Favicon sure has had a long run. It's becoming even more widely used, with browser home screens turning into application-launcher screens. There are so many ways we need to package icons now. Google and Apple platforms ask for a whole collection of them in different sizes. I tell you, as absurd as it may be, a css media type of "icon" is closing in on us. ApplicationCache is cache control thing: it does not "package" a Web Application; just makes some resources available from the cache (potentially for off-line use). The end user has not control over it and the author can shut it off at any point. The end user *could* have control over it if the user agent let her (the But the user agent doesn't let her, because he is mean. And I don't think that is the way the spec was written (though I need to check). But I doubt the spec says anything about that, as it seems the author is king in that situation. I agree that the widget specs say a lot more on application management than ApplicationCache (which more or less only deals with updates and connectivity); but the applicationcache spec certainly doesn't forbid user agents to do smart things with it, as the iPhone implementation shows. As far as I know, (at least) Mozilla is working on "saving as Web application", and I would be extremely surprised if they didn't use the applicationcache when available to do that. I expect the same. When/if a user decides that a web application is -important- to them, they do grant it additional permissions, such as increasing file storage limits (or perhaps, duration of the temporary file system). That method seems to be working, and preferred, for most use cases. I know that one of our apps asks for "access to everything you have ever done" -- It could be more granular, if mechanisms were in place... Asking for things like CORS exceptions. Whether packaged as a widget, or distributed via applicationCache, there is the question of automatic updating, and how to handle all of that. I'm certainly more pleased with Google Chrome's automatic updating feature than I am with the bi-weekly (I kid) updates pushed out by Oracle for Java, interrupting my day to remind me that Java is installed on my OS. I think "updating" ought to be looked at from a permissions perspective. As a user, I'd like to be able to say: keep this app cache, no matter what. That'd let me lock-down some systems from man in the middle attacks, once the app is installed. Considering recent SSL breaches, it's a reasonable use case. same way a widget user agent could also automatically remove widgets that their authors wish to retract). There is no prov
Re: Widgets & ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
On 16 Sep 2011, at 13:55, Dominique Hazael-Massieux wrote: > >> IMO, keeping them together will lead to confusion. The use cases are >> different: a widget can embed content that uses ApplicationCache, as >> well as load in proprietary APIs (e.g., WAC). > > Surely a Web-applicationcached app could also load proprietary APIs. And > an application cache could also have a widget as part of its list of > cacheable resources. > >> It can be used for defining other classes of applications and formats >> (e.g., Opera Extensions). > > I can also imagine using ApplicationCache to do that. I can imagine using all kinds of other things to do that. The point is, I don't want to, I want to use one standard way to do it along with all other companies in the space so we have a market, not a whole bunch of non-interoperating silos, and have a consistent message for users. I don't really understand what the point is of putting these things together. Other than to annoy Marcos of course :) > > Widgets and ApplicationCache differ in some ways (e.g. the security > model of widgets is different, widgets currently don't have an origin, > etc), but I still don't see how they would fundamentally address > different use cases. > > Dom > > >
Re: [DOM4] Remove Node.isSameNode
I'm also in favor of removing this. This does more harm than good. Unfortunately I found ~200 uses of this in code search. http://www.google.com/codesearch#search/&q=%5C.isSameNode%5C(%20lang:javascript&type=cs erik On Thu, Sep 15, 2011 at 00:33, Anne van Kesteren wrote: > On Fri, 09 Sep 2011 19:21:53 +0200, Jonas Sicking wrote: >> >> It's a completely useless function. It just implements the equality >> operator. I believe most languages have a equality operator already. >> Except Brainfuck [1]. But the DOM isn't implementable in Brainfuck >> anyway as it doesn't have objects, so I'm ok with that. > > If you can get this removed from Gecko without it causing compatibility > issues consider it gone from the specification. I'm all for less methods, > especially useless methods. > > >> [1] http://en.wikipedia.org/wiki/Brainfuck > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > >
Re: Widgets & ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
Le vendredi 16 septembre 2011 à 21:36 +0700, Marcos Caceres a écrit : > > I think they are actually not so different, and share many use cases. > > Ok, I strongly object in the strongest of terms to them being put together > and I'm more than happy to debate any argument you might have for lumping > them together. Here we go :) Well, you are on the program committee of an upcoming workshop that lumps them together: As mentioned above, the World Wide Web Consortium has already developed standards to facilitate the development of off-line Web applications: the HTML 5 Working Group's Application Cache; the Web Applications Working Group's Packaging and XML Configuration. http://www.w3.org/2011/web-apps-ws/ > > ApplicationCache can be used to group a bunch of HTML, CSS and JS files > > that constitue an "installable application" (e.g. the way the iOS safari > > browser let you save to your homescreen an offline Web app when an > > application cache is present). > > I'm sorry, but that has absolutely nothing to do with Application cache. It's > done like this: > > Sure, that bits helps for having an icon on the homescreen; it's fair to say that rel="apple-touch-icon" (and its standard equivalent rel="icon" with the sizes attribute) completes ApplicationCache in matching the features that widget packaging provides. But without the application cache, your nice and shiny icon won't load anything if you're not connected; is the equivalent to in config.xml, where ApplicationCache is the list of files encoded in the Zip file. > > > ApplicationCache is cache control thing: it does not "package" a Web > > > Application; just makes some resources available from the cache > > > (potentially for off-line use). The end user has not control over it > > > and the author can shut it off at any point. > > > > The end user *could* have control over it if the user agent let her (the > But the user agent doesn't let her, because he is mean. And I don't > think that is the way the spec was written (though I need to check). > But I doubt the spec says anything about that, as it seems the author > is king in that situation. I agree that the widget specs say a lot more on application management than ApplicationCache (which more or less only deals with updates and connectivity); but the applicationcache spec certainly doesn't forbid user agents to do smart things with it, as the iPhone implementation shows. As far as I know, (at least) Mozilla is working on "saving as Web application", and I would be extremely surprised if they didn't use the applicationcache when available to do that. > > same way a widget user agent could also automatically remove widgets > > that their authors wish to retract). > > There is no provision in any of the specs to do this. Certainly not by > design, unlike HTML5. Right; but knowing how application stores tend to have a remove-this-app switch, I'd be surprised if many applications stores based on widgets didn't have a similar ability. > > > IMO, keeping them together will lead to confusion. The use cases are > > > different: a widget can embed content that uses ApplicationCache, as > > > well as load in proprietary APIs (e.g., WAC). > > > > Surely a Web-applicationcached app could also load proprietary APIs. > > How? What mechanism does a proprietary unpacked web application have to do > this? And do you have any actual real examples of this happening in the wild? > ActiveX and other plugins seem to have provided this for quite some time? Not to mention vendor-prefixed APIs? > > And > > an application cache could also have a widget as part of its list of > > cacheable resources. > > Sure, they could have bananas too and all sorts of hypothetical things too. > But they don't. Right, because that's not terribly useful. But you brought the fact that one technology could embed the other, I didn't. > > > It can be used for defining other classes of applications and formats > > > (e.g., Opera Extensions). > > > > I can also imagine using ApplicationCache to do that. > > You have a wild imagination :) I'm sure there is a good reason why no > one has done it. > > In any case, the document is discussing concrete things, not > imaginary things. Right; the document is not discussing the fact that widgets can also be used for creating browser extensions, or providing server-side lump of content. It's discussing packaging web applications for offline usage. > Please base the document on real world things, not on things you > imagine. I don't think I'm imagining that both widgets and applicationcache provide a way to package Web applications for users. At least, you still haven't convinced me that they don't. I don't think that lumping them together means they are the same technology covering exactly the same use cases, otherwise my document would also assert that SVG, canvas and CSS are the same. > > Widgets
Re: Widgets & ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
Hi Dom, On Friday, 16 September 2011 at 19:55, Dominique Hazael-Massieux wrote: > Hi Marcos, > > Le samedi 03 septembre 2011 à 22:47 +0200, Marcos Caceres a écrit : > [sorry for the delay in responding] > > > Thank you for continuing to keep the document up to date. This document is > > very helpful. > > Thanks! > > > I have request: can you please ungroup Widgets and HTML's > > ApplicationCache? They are conceptually different things and have > > different use cases. > > I think they are actually not so different, and share many use cases. Ok, I strongly object in the strongest of terms to them being put together and I'm more than happy to debate any argument you might have for lumping them together. Here we go :) > > Widgets are a way to zip up a bunch of HTML, CSS, and JS files that > > constitute an "installable application" (or some such). That is, > > something someone might want to distribute to keep. > > ApplicationCache can be used to group a bunch of HTML, CSS and JS files > that constitue an "installable application" (e.g. the way the iOS safari > browser let you save to your homescreen an offline Web app when an > application cache is present). I'm sorry, but that has absolutely nothing to do with Application cache. It's done like this: It's consequential that a web application is using app cache. > > ApplicationCache is cache control thing: it does not "package" a Web > > Application; just makes some resources available from the cache > > (potentially for off-line use). The end user has not control over it > > and the author can shut it off at any point. > > The end user *could* have control over it if the user agent let her (the But the user agent doesn't let her, because he is mean. And I don't think that is the way the spec was written (though I need to check). But I doubt the spec says anything about that, as it seems the author is king in that situation. > same way a widget user agent could also automatically remove widgets > that their authors wish to retract). There is no provision in any of the specs to do this. Certainly not by design, unlike HTML5. > I don't think there is anything > fundamental is the underlying technologies that prevent or facilitate > that particular use case. It's clearly evil to do this (specially in the widget case, implying you do it with updates). Imagine if Microsoft decided one day to trash every user's copy of Windows through an update. Yeah, it's possible, but it just would not happen…. on the other hand, it seems to the norm with AppCache (as things are updated… though I have been in situations where I was locked out of an app, much to my annoyance). > > IMO, keeping them together will lead to confusion. The use cases are > > different: a widget can embed content that uses ApplicationCache, as > > well as load in proprietary APIs (e.g., WAC). > > Surely a Web-applicationcached app could also load proprietary APIs. How? What mechanism does a proprietary unpacked web application have to do this? And do you have any actual real examples of this happening in the wild? > And > an application cache could also have a widget as part of its list of > cacheable resources. Sure, they could have bananas too and all sorts of hypothetical things too. But they don't. > > It can be used for defining other classes of applications and formats > > (e.g., Opera Extensions). > > I can also imagine using ApplicationCache to do that. You have a wild imagination :) I'm sure there is a good reason why no one has done it. In any case, the document is discussing concrete things, not imaginary things. Please base the document on real world things, not on things you imagine. > Widgets and ApplicationCache differ in some ways (e.g. the security > model of widgets is different, widgets currently don't have an origin, The do have an origin! It's called widget:// and it's an completely conforming origin: Please look up the definition of origin in the HTML5 spec. > etc), but I still don't see how they would fundamentally address > different use cases. If you don't understand widgets, then please read the specification, or take the Editor's word for it (I've been at this for 5 years, so I think I know what I am talking about when it comes to widgets) or please remove them from the document. Kind regards, Marcos
Re: [widgets] Proposal to publish Widget Requirements and Widget Landscape docs as Working Group Notes; deadline Sep 23
On Friday, 16 September 2011 at 20:04, Arthur Barstow wrote: > Marcos, All, > > To clearly state that WebApps' work on the Widget Requirements and > Widget Landscape documents has ended, I propose they be published as > Working Group Notes: > > http://www.w3.org/TR/widgets-land/ > http://www.w3.org/TR/widgets-reqs/ I think only the requirements should be published, because it was actually pretty useful in informing the standards development process. It's actually a pretty good document, if I do say so myself :) The landscape document was just created to inform the standardisation process of what was considered best practice at the time. If it's a W3C requirement that it be published as a WG Note, then it should be published as is (i.e., I don't wanna do any work on it unless I really have to). > If anyone has any comments or objections to publishing those docs - as > is (except for SotD updates) - as WG Notes, please reply by September 23 > at the latest. 0_o Kind regards, Marcos
[widgets] Proposal to publish Widget Requirements and Widget Landscape docs as Working Group Notes; deadline Sep 23
Marcos, All, To clearly state that WebApps' work on the Widget Requirements and Widget Landscape documents has ended, I propose they be published as Working Group Notes: http://www.w3.org/TR/widgets-land/ http://www.w3.org/TR/widgets-reqs/ If anyone has any comments or objections to publishing those docs - as is (except for SotD updates) - as WG Notes, please reply by September 23 at the latest. -AB
Widgets & ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
Hi Marcos, Le samedi 03 septembre 2011 à 22:47 +0200, Marcos Caceres a écrit : [sorry for the delay in responding] > Thank you for continuing to keep the document up to date. This document is > very helpful. Thanks! > I have request: can you please ungroup Widgets and HTML's > ApplicationCache? They are conceptually different things and have > different use cases. I think they are actually not so different, and share many use cases. > Widgets are a way to zip up a bunch of HTML, CSS, and JS files that > constitute an "installable application" (or some such). That is, > something someone might want to distribute to keep. ApplicationCache can be used to group a bunch of HTML, CSS and JS files that constitue an "installable application" (e.g. the way the iOS safari browser let you save to your homescreen an offline Web app when an application cache is present). > ApplicationCache is cache control thing: it does not "package" a Web > Application; just makes some resources available from the cache > (potentially for off-line use). The end user has not control over it > and the author can shut it off at any point. The end user *could* have control over it if the user agent let her (the same way a widget user agent could also automatically remove widgets that their authors wish to retract). I don't think there is anything fundamental is the underlying technologies that prevent or facilitate that particular use case. > IMO, keeping them together will lead to confusion. The use cases are > different: a widget can embed content that uses ApplicationCache, as > well as load in proprietary APIs (e.g., WAC). Surely a Web-applicationcached app could also load proprietary APIs. And an application cache could also have a widget as part of its list of cacheable resources. > It can be used for defining other classes of applications and formats > (e.g., Opera Extensions). I can also imagine using ApplicationCache to do that. Widgets and ApplicationCache differ in some ways (e.g. the security model of widgets is different, widgets currently don't have an origin, etc), but I still don't see how they would fundamentally address different use cases. Dom
[Bug 14180] Call onclose() passing as argument the WS close frame status and status code and reason
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14180 Iñaki Baz Castillo changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Iñaki Baz Castillo 2011-09-16 11:44:07 UTC --- I'm sorry, I missed that it's already defined in the WS API: http://dev.w3.org/html5/websockets/#event-definitions -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[widgets] Status of Packing, DigSig and view-modes Proposed Recommendations
[ + public-webapps ] Original Message Subject: [widgets] Status of Packing, DigSig and view-modes Proposed Recommendations Date: Fri, 16 Sep 2011 06:58:24 -0400 From: Arthur Barstow To: Marcos Caceres , Doug Schepers , Philippe Le Hégaret , Thomas Roessler , Rigo Wenning , Bert Bos , Daniel Glazman , Peter Linss On September 15, the Advisory Committee's "Call for Review: Widget Packaging and XML Configuration, XML Digital Signatures for Widgets, 'view-mode' Media Feature are W3C Proposed Recommendations" questionnaire ended, and the results are that all of the AC members that responded, said they "supports publication as a W3C Recommendation as is" (see the Member-only link at [1]). AFAIU, a Recommendation for Packaging and Configuration spec should now be possible (its only 2 non-REC refs are the WidgetDigSig and view-modes PRs): http://www.w3.org/TR/widgets/#normative-references Doug, PLH - what needs to be done to move the Widget P&C spec to Recommendation? The other two PRs have issues that are blocking their advancement to Recommendation: 1. XML Digital Signatures for Widgets - advancement to Recommendation is blocked by the XML Security WG's XMLDigSig11 CR and the Signature Properties CR and both of those specs are still blocked by an open Patent Advisory Group (PAG): http://www.w3.org/TR/widgets-digsig/#references Rigo, Thomas - when do you expect the XML Security PAG to end? 2. view-mode Media Feature - advancement to Recommendation is blocked by the CSS WG's Media Queries spec still being a CR: http://www.w3.org/TR/view-mode/#normative-references Bert, Daniel, Peter - when do you expect Media Queries to advance to PR? -Art Barstow [1] http://www.w3.org/2002/09/wbs/33280/widgets-2001-part1/results
[Bug 14180] New: Call onclose() passing as argument the WS close frame status and status code and reason
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14180 Summary: Call onclose() passing as argument the WS close frame status and status code and reason Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: i...@aliax.net QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org In some cases, the WebSocket server could decide to close the connection with the client due to a WS subprotocol violation in a message sent from the client to server. In such a case, the WS server could send a WS close frame with some custom status code (i.e. >= 4000) and some reason text. Both status code and reason are optional as per WebSocket specification. When this occurs, it would be nice that the WebSocket stack in the client calls onclose() WS API function by passing both the status code and the reason (if present), so the function definition would become: function onclose(status, reason) In case of abrupt TCP disconnection or in case a WS close frame with no status/reason was received, both status and reason arguments would have _null_ value. This would be useful to notify the client the reason of the disconnection from the server. The WebSocket subprotocol could define some own custom WS close status codes (>= 4000). But this would be also useful for determining core WS protocol errors (such those defined by status code 1XXX). -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
