Re: Offline Web Applications status
The main requirement for a webapp (or a website) to use App Cache, is AJAX capability. Without AJAX, the webapp is just like offline STATIC application (which is boring). So, in order to use App Cache, developers must re-design their websites so that it is AJAX enabled (which requires too much work). Now, if only there is a way to avoid the main page (index.html) to be cached, then AJAX is NOT REQUIRED! The developers can just list down the manifest as it is, but the index.html will always be updated. So, no need AJAX to deliver what's new on the page. Note that the webapp can still be used offline (the old index.html is served if the user is offline). The App Cache is used purely to cache the most likely immutable resources (images, javascripts, csss, flashes, etc..) And with this, the developers DON'T need to change anything on their working website, except adding manifest link! With this, the whole web will be far far far faster (imagine how many jQuery users and jQuery UI and other libraries can be cached!). So, if you really want the App Cache to be used virally, the browser vendors better start giving option to EXCLUDE the main page to be cached. So far I haven't see why this option can't be done? Felix Halim 2011/3/23 louis-rémi BABE lrb...@gmail.com: Hello Webapps working group, I'm an intern at Mozilla Developers Engagement team and I'm currently working on promoting Offline Web Applications. My first task is to understand what did go wrong with the App Cache mechanism... ## Maybe Web devs don't use App Cache because they don't understand what it is... ## The possibility of using Webapps offline has a great potential but its adoption by developers didn't reach our expectations. We asked Web developers some time ago what were their feelings regarding application cache (see http://hacks.mozilla.org/2010/05/revitalizing-caching/ ) and it appeared that the name was misleading, as they expected it to be more of an auxiliary cache than an offline mechanism. You can find evidences of this confusion on StackOverflow, where some people struggle to use the application cache as a mean to boost performances of their Websites. ## Can you see other reasons? ## Before going back to developers or writing yet another App Cache documentation, I wanted to have *your* feelings about this mechanism. You might have a different impression about its adoption and be aware of successful real-world use-cases. You might have asked developers yourself and received a different feedback. Maybe you feel that Web advocates are not doing a good enough job at documenting this feature, producing demos and clarifying its nature. Maybe you think that the problem has to do with the specification itself. Maybe there is an evolution of the specification underway that I am not aware of. ## Two naive questions ## After reading a large amount of documentation, I have to admit that I am myself confused about app cache: Do you think it *can* be used as an auxiliary cache mechanism, and what would be the limitations? The main problem I see is that there is no way to white-list the referring document (e.g. index.html). Currently, I would advocate *against* using it as an auxiliary cache. Why isn't there any DOM API allowing a fine-grained control of the application cache? applicationCache.cache.add( URI ); applicationCache.cache.remove( URI ); Thank you in advance, Louis-Rémi Babé
Re: RfC: WebApps Testing Process
On Thu, Mar 31, 2011 at 8:04 AM, Arthur Barstow art.bars...@nokia.com wrote: 3. http://www.w3.org/2008/webapps/wiki/Approval - how to start a test case review, approval process, how to update an approved test case It looks like every submitted test suite must undergo a CfC, and so must every update. I'll first say that this is much better than the way the HTMLWG currently works, which requires explicit endorsement by a reviewer before approval but provides no way to obtain such review other than hoping someone will be willing to give it. But it's also much more cumbersome than the process for changing the actual specifications. In writing specs, instead, we designate one or more people as editors for each spec, and let them make changes at will. Others who have suggestions can use the bug-tracking system, and contentious issues must be addressed during Last Call before a specification can become a Candidate Recommendation. This procedure is well-optimized for the fact that realistically, the large majority of changes are uncontroversial, so it makes the most sense to assume that changes are uncontroversial until someone actually objects, without any formal approval requirements. I propose that the Working Group follow this model for tests too. For each specification, we should designate certain people as maintainers for that specification's tests. They should be allowed to update the tests and add new tests freely, and should be responsible for responding to bug reports. At Last Call, we should explicitly ask for feedback for the test suite as well as the specification, and treat feedback on tests similarly to feedback on the spec. I suggest that for starters, the editors of a spec should also be maintainers of its tests. Additional test maintainers for each spec can be added by a WG CfC. This recognizes the fact that the editors of a spec are presumably competent to judge tests, but that many editors won't want to also review tests and many test reviewers won't want to edit specs, so there's value in keeping the groups separate. If the approval model currently on the wiki page is adopted, I predict that it will become extremely cumbersome to maintain large test suites for any specification that's not already very stable. Any significant specification change will require a CfC to change all affected test cases, which will be a lot of spam to sift through if we have lots of tests and spec changes. This model also prevents editors who want to write their own tests from writing the tests in conjunction with the specification, because of the higher approval bar for tests than for spec edits. I don't think it makes sense at all.
Re: Mail List Etiquette [Was: WebSQL] Any future plans, or has IndexedDB replaced WebSQL?]
On Thu, Mar 31, 2011 at 3:37 PM, Arthur Barstow art.bars...@nokia.com wrote: Hear. I am starting to think that Mozilla will step up and provide an embedding of SQLite, even if it has to only think of it as such. It will have to. People would rather use a working database than something crippled albeit specced (see LocalStorage or IndexedDB). It was things like XHR in all their unspecced glory that brought the web to where it is today. Joran - as one of the moderators of public-webapps, I find your comments above offensive to those that work on the specs you mention. FWIW, I think the comments were substantive and made a potentially valid point, without impugning the editors of the relevant specifications in any way. Functionality is very important to authors, and it's fair to argue that underspecified but powerful and easy-to-implement features can sometimes be better than better-specified features that won't have nearly as many features for some years to come. We should all remember that while interoperability is important, so are features, and we cannot rule out technologies for not being interoperable enough without considering their advantages as well. (I have no strong opinion on the specific issue in question, though.) I would not be offended if someone made comments such as this about a spec I write, and think it would be bad to discourage feedback like it.
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On Thu, Mar 31, 2011 at 12:28 PM, Boris Zbarsky bzbar...@mit.edu wrote: No, it actually sounds like a success; it prevented a specification being created which would have been tied to a particular implementation, no matter how widely-deployed. For comparison, IE6 was very widely deployed circa 2002. And yet specifying CSS, say, by saying just do exactly what IE6 does would not have been a good idea. Neither is defining WebSQL to do exactly what some particular version of SQLite does, and no one stepped up to define it better. IE6 is closed-source software written for a single platform. SQLite is in the public domain, works for all major operating systems and lots of minor ones, and is already used (I think?) by every major browser except IE. That makes all the difference. There's some benefit to having multiple interoperable implementations even if the reference implementation is public-domain, but enormously less than when the only implementations are controlled by particular parties. I think SQLite isn't a great long-term solution, because in the long term a single implementation stifles innovation. But it's also very powerful, pretty familiar to web developers (who are used to MySQL), requires vastly less implementation effort than making up a new system, and is in practice going to be much more interoperable than anything written separately by different browsers. So refusing to consider it just because there isn't a written standard or multiple interoperable implementations is not sound. When the Wikimedia Foundation was considering an official Board-approved policy for what file formats they'd allow for upload on sites like Wikimedia, the draft http://meta.wikimedia.org/wiki/File_format_policy required that the format be Defined by an open standard, implementation, or specification not under proprietary control. Notice that an open *standard* was not required -- an open *implementation* was enough. .doc need not apply, but LaTeX or MediaWiki wikitext are perfectly fine. The proposal was never formally adopted, but I think this philosophy makes a lot of sense. Many (although certainly not all) of the reasons for standards evaporate when you have a reference implementation under a BSD-style license or better. So if the only objection to WebSQL is there's no way we're going to get a formal spec or two interoperable implementations, I'd really encourage objectors to step back and ask themselves why they *want* a formal spec and two interoperable implementations. Those requirements are not axiomatic, they're means to obtain practical ends like allowing competitions and avoiding user lock-in. How many of those ends are really contrary to using SQLite as a de facto standard, and do the remaining ones really outweigh the practical advantages? (I came to this discussion very late, so apologies if there are additional objections to WebSQL that no one's mentioned in this specific thread, but have mentioned in the dozens of threads about this before now.)
Re: Mail List Etiquette [Was: WebSQL] Any future plans, or has IndexedDB replaced WebSQL?]
Yes I agree, as has been said before on this list, that comments are always welcome and let's all please make sure those comments are consistent with the principles to which I referred. -Art Barstow On Apr/1/2011 12:21 PM, ext Aryeh Gregor wrote: On Thu, Mar 31, 2011 at 3:37 PM, Arthur Barstowart.bars...@nokia.com wrote: Hear. I am starting to think that Mozilla will step up and provide an embedding of SQLite, even if it has to only think of it as such. It will have to. People would rather use a working database than something crippled albeit specced (see LocalStorage or IndexedDB). It was things like XHR in all their unspecced glory that brought the web to where it is today. Joran - as one of the moderators of public-webapps, I find your comments above offensive to those that work on the specs you mention. FWIW, I think the comments were substantive and made a potentially valid point, without impugning the editors of the relevant specifications in any way. Functionality is very important to authors, and it's fair to argue that underspecified but powerful and easy-to-implement features can sometimes be better than better-specified features that won't have nearly as many features for some years to come. We should all remember that while interoperability is important, so are features, and we cannot rule out technologies for not being interoperable enough without considering their advantages as well. (I have no strong opinion on the specific issue in question, though.) I would not be offended if someone made comments such as this about a spec I write, and think it would be bad to discourage feedback like it.
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On 4/1/2011 5:40 AM, Nathan Kitchen wrote: Are there any browser vendor representatives on the mailing list who would care to comment on the criteria for implementing something akin to Keean's RelationalDBhttps://github.com/keean/RelationalDB idea? What would need to be in place to start work on such an implementation? It wouldn't be terribly difficult to prototype this as an add-on for Firefox, I don't think (and I'd be happy to provide technical assistance to anyone wishing to do so). Doing this would allow web developers to install the add-on and play with it, which can give us useful feedback. I'm not saying we'd move it into the tree at that point, but it's a good first step to building a case to take it. 1. Opportunity to explore more solutions to offline data than *just * IndexedDB. There is also http://dev.w3.org/html5/spec/offline.html and http://dev.w3.org/html5/webstorage/ (even if you don't like them, they are other solutions to the offline problem). Browser vendors are not just looking at IndexedDB. 2. Many web developers have a working knowledge of SQL, so the concepts of a relational database may be more familiar. If adoption could be considered a proxy for the success of a standard, I'd suggest that aiming for something the web development community understands would be a large factor in adoption. I don't really think IndexedDB is that dissimilar to a relational database. There are a lot of one-to-one mappings of concepts of one to the other. 3. It's probably (!) easier to implement RelationalDB than IndexedDB, as it maps fairly cleanly to existing relational database technologies. This would allow vendors to implement it using Sqlite, Access, etc independent of the spec. Given that most vendors already have working implementations of IndexedDB, I don't think this is a good argument ;) Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On 4/1/2011 9:39 AM, Aryeh Gregor wrote: IE6 is closed-source software written for a single platform. SQLite is in the public domain, works for all major operating systems and lots of minor ones, and is already used (I think?) by every major browser except IE. That makes all the difference. There's some benefit to having multiple interoperable implementations even if the reference implementation is public-domain, but enormously less than when the only implementations are controlled by particular parties. How, exactly, does it make all the difference? I sure hope you aren't suggesting that the spec say do what this code does. So if the only objection to WebSQL is there's no way we're going to get a formal spec or two interoperable implementations, I'd really encourage objectors to step back and ask themselves why they *want* a formal spec and two interoperable implementations. Those requirements are not axiomatic, they're means to obtain practical ends like allowing competitions and avoiding user lock-in. How many of those ends are really contrary to using SQLite as a de facto standard, and do the remaining ones really outweigh the practical advantages? That's not the only reason. Mozilla laid out others ten months ago: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On Fri, Apr 1, 2011 at 9:39 AM, Aryeh Gregor simetrical+...@gmail.com wrote: On Thu, Mar 31, 2011 at 12:28 PM, Boris Zbarsky bzbar...@mit.edu wrote: No, it actually sounds like a success; it prevented a specification being created which would have been tied to a particular implementation, no matter how widely-deployed. For comparison, IE6 was very widely deployed circa 2002. And yet specifying CSS, say, by saying just do exactly what IE6 does would not have been a good idea. Neither is defining WebSQL to do exactly what some particular version of SQLite does, and no one stepped up to define it better. IE6 is closed-source software written for a single platform. SQLite is in the public domain, works for all major operating systems and lots of minor ones, and is already used (I think?) by every major browser except IE. That makes all the difference. There's some benefit to having multiple interoperable implementations even if the reference implementation is public-domain, but enormously less than when the only implementations are controlled by particular parties. I think SQLite isn't a great long-term solution, because in the long term a single implementation stifles innovation. But it's also very powerful, pretty familiar to web developers (who are used to MySQL), requires vastly less implementation effort than making up a new system, and is in practice going to be much more interoperable than anything written separately by different browsers. So refusing to consider it just because there isn't a written standard or multiple interoperable implementations is not sound. When the Wikimedia Foundation was considering an official Board-approved policy for what file formats they'd allow for upload on sites like Wikimedia, the draft http://meta.wikimedia.org/wiki/File_format_policy required that the format be Defined by an open standard, implementation, or specification not under proprietary control. Notice that an open *standard* was not required -- an open *implementation* was enough. .doc need not apply, but LaTeX or MediaWiki wikitext are perfectly fine. The proposal was never formally adopted, but I think this philosophy makes a lot of sense. Many (although certainly not all) of the reasons for standards evaporate when you have a reference implementation under a BSD-style license or better. So if the only objection to WebSQL is there's no way we're going to get a formal spec or two interoperable implementations, I'd really encourage objectors to step back and ask themselves why they *want* a formal spec and two interoperable implementations. Those requirements are not axiomatic, they're means to obtain practical ends like allowing competitions and avoiding user lock-in. How many of those ends are really contrary to using SQLite as a de facto standard, and do the remaining ones really outweigh the practical advantages? (I came to this discussion very late, so apologies if there are additional objections to WebSQL that no one's mentioned in this specific thread, but have mentioned in the dozens of threads about this before now.) There are several reasons why we don't want to rely exclusively on SQLite, other than solely W3C formalia. First of all, what should we do once the SQLite team releases a new version which has some modifications in its SQL dialect? We generally always need to embed the latest version of the library since it contains critical bug fixes, however SQLite makes no guarantees that it will always support exactly the same SQL statements. For normal software this is fine. You simply retest your software after upgrading to the latest version and if it treats any of your queries differently, you simply adjust your query or your code to account for this. However web apps are afforded no such luxury. They have no control over when users upgrade their browsers to one with a new version of SQLite. This is why it is critically important on the web to maintain stable APIs. Unfortunately SQLite does not provide such a stable API. To make matters worse, since we are exposing the SQLite engine directly to potentially harmful web content, it is extra important to be tracking the latest version of SQLite as to pick up any and all security fixes. Second, as a browser developer, I am not at all excited about the idea of locking myself in to shipping SQLite forever. What if a new better embeddable SQL engine comes along and I want to switch to using that? Just because SQLite is popular now doesn't mean that in 10 years it couldn't be a unmaintained project largely replaced by some other embeddable SQL engine. Lastly, some vendors have expressed unwillingness to embed SQLite for legal reasons. Embedding other peoples code definitely exposes you to risk of copyright and patent lawsuits. While I can't say that I fully agree with this reasoning, I'm also not the one that would be on the receiving end of a lawsuit. Nor am I a lawyer and so
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On Apr/1/2011 3:39 PM, ext Glenn Maynard wrote: If SQLite was to be used as a web standard, I'd hope that it wouldn't show up in a spec as simply do what SQLite does, but as a complete spec of SQLite's behavior. FYI, the Web SQL Database NOTE says: [[ http://www.w3.org/TR/2010/NOTE-webdatabase-20101118/#web-sql 5. Web SQL User agents must implement the SQL dialect supported by Sqlite 3.6.19. ]] and I don't recall anyone ever committing to creating the later. -AB
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On Fri, Apr 1, 2011 at 12:39 PM, Glenn Maynard gl...@zewt.org wrote: Lastly, some vendors have expressed unwillingness to embed SQLite for legal reasons. Embedding other peoples code definitely exposes you to risk of copyright and patent lawsuits. While I can't say that I fully agree with this reasoning, I'm also not the one that would be on the receiving end of a lawsuit. Nor am I a lawyer and so ultimately will have to defer to people that know better. In the end it doesn't really matter as if a browser won't embed SQLite then it doesn't matter why, the end result is that the same SQL dialect won't be available cross browser which is bad for the web. If SQLite was to be used as a web standard, I'd hope that it wouldn't show up in a spec as simply do what SQLite does, but as a complete spec of SQLite's behavior. Browser vendors could then, if their lawyers insisted, implement their own compatible implementation, just as they do with other web APIs. I'd expect large portions of SQLite's test suite to be adaptable as a major starting point for spec tests, too. Have you read the WebSQL spec? Creating such a spec would be a formidable task, of course. Indeed. One that the SQL community has failed in doing so far. And they have a lot more experience with SQL than we do. / Jonas
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On Fri, Apr 1, 2011 at 3:53 PM, Jonas Sicking jo...@sicking.cc wrote: Creating such a spec would be a formidable task, of course. Indeed. One that the SQL community has failed in doing so far. And they have a lot more experience with SQL than we do. That suggests a very different rationale for not using SQL: it's too complex to specify interoperably. If true, it is, in my opinion, a much more compelling line of argument than the others. -- Glenn Maynard
[Bug 12321] Add compound keys to IndexedDB
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12321 Jonas Sicking jo...@sicking.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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: How to standardize new Offline Web app features? [Was Re: Offline Web Applications status]
Hi Art, Please don't assume I know how the w3c works. I'm not subscribed to the public-html list and honestly don't have a good understanding of which list is for what. I consider the feature set provided in by the Application Cache to harmonize with other topics discussed on the public-webapps list, so it seemed like the natural place to discuss it. Actually Louis-Rémi started the thread to which I responded. Interesting question about moving the Offline Web Applications out of HTML5 to a new home. I doesn't matter to me where this is spec'd or discussed so much, what matters is that progress is made as I think it's clear there is demand for more in this area. I have not been party to any discussions about relocating the Offline WebApps part of the HTML5 spec. Since you asked, I'm guessing you think that could help with making faster progress? -Michael On Fri, Apr 1, 2011 at 3:51 AM, Arthur Barstow art.bars...@nokia.comwrote: Michael, All, On Mar/31/2011 6:18 PM, ext Michael Nordman wrote: I have in mind several extensions to the ApplicationCache that I think could address some of the additional desirements from the web developement community. I'll post them here because people seem to be more willing to have a discussion on the topic here than over in whatwg. From the process perspective, I think it is fine to discuss this feature on public-webapps but since Offline Web applications is defined in the HTML5 spec, I am curious why you didn't use the public-html list. BTW, has there been any discussion (e.g. in the WHATWG or HTMLWG) about moving the Offline Web application out of the HTMLWG's HTML5 spec and into a separate spec? I'm wondering if that could help facilitate the standardization of new features like those you proposed in this thread [1]. -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/1121.html
Re: How to standardize new Offline Web app features? [Was Re: Offline Web Applications status]
Michael Nordman wrote: Hi Art, Please don't assume I know how the w3c works. I'm not subscribed to the public-html list and honestly don't have a good understanding of which list is for what. I consider the feature set provided in by the Application Cache to harmonize with other topics discussed on the public-webapps list, so it seemed like the natural place to discuss it. Actually Louis-Rémi started the thread to which I responded. Interesting question about moving the Offline Web Applications out of HTML5 to a new home. I doesn't matter to me where this is spec'd or discussed so much, what matters is that progress is made as I think it's clear there is demand for more in this area. I have not been party to any discussions about relocating the Offline WebApps part of the HTML5 spec. Since you asked, I'm guessing you think that could help with making faster progress? They do seem awfully related to the Widgets specifications though..
Selectors API IDL Issues
Hi,
Presently, the IDL in Selectors API defines the NodeSelector
interface using [Supplemental, NoInterfaceObject].
I'm not quite sure why I have supplemental in there, but it seems to be
left over from an old edit that should have been removed, since
NodeSelector is not a pre-existing interface that this is supplementing.
So I will be removing [Supplemental] from the IDL when I make the
edits necessary to take the spec to PR.
It's also been brought to my attention that the use of
[NoInterfaceObject] may not be quite right either and I would like to
get clarification.
According to a mail from Cameron [1], the use of [NoInterfaceObject] and
the implements statement has an observable difference from defining a
Supplemental interface, though I originally thought there would not be.
I thought that the following were identical from a black box
implementation perspective:
1)
[Supplemental]
interface Element {
Element querySelector(in DOMString selectors, in optional any
...
}
2)
[NoInterfaceObject]
interface NodeSelector {
Element querySelector(in DOMString selectors, in optional any
...
};
Element implements NodeSelector
(And similarly for Document and DocumentFragment, omitted for simplicity)
The querySelector methods should exist on Element.prototype, which does
seem to be what Opera, Gecko and WebKit do.
According to Cam's mail, that is what does happen in case #1, but is not
in case #2, as in the current spec, though I'm not sure why. So I would
like to get clarification whether that is in fact the case, and whether
[NoInterfaceObject] really is what I should be using here.
[1] http://lists.w3.org/Archives/Public/public-web-perf/2011Mar/0058.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
Hi Shawn I would be interested in this. What would need to be done to make this a Firefox plugin? I've done XPCOM stuff before in xulrunner if that's any help. Cheers, Keean On Apr 1, 2011 6:09 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 4/1/2011 5:40 AM, Nathan Kitchen wrote: Are there any browser vendor representatives on the mailing list who would care to comment on the criteria for implementing something akin to Keean's RelationalDBhttps://github.com/keean/RelationalDB idea? What would need to be in place to start work on such an implementation? It wouldn't be terribly difficult to prototype this as an add-on for Firefox, I don't think (and I'd be happy to provide technical assistance to anyone wishing to do so). Doing this would allow web developers to install the add-on and play with it, which can give us useful feedback. I'm not saying we'd move it into the tree at that point, but it's a good first step to building a case to take it. 1. Opportunity to explore more solutions to offline data than *just * IndexedDB. There is also http://dev.w3.org/html5/spec/offline.html and http://dev.w3.org/html5/webstorage/ (even if you don't like them, they are other solutions to the offline problem). Browser vendors are not just looking at IndexedDB. 2. Many web developers have a working knowledge of SQL, so the concepts of a relational database may be more familiar. If adoption could be considered a proxy for the success of a standard, I'd suggest that aiming for something the web development community understands would be a large factor in adoption. I don't really think IndexedDB is that dissimilar to a relational database. There are a lot of one-to-one mappings of concepts of one to the other. 3. It's probably (!) easier to implement RelationalDB than IndexedDB, as it maps fairly cleanly to existing relational database technologies. This would allow vendors to implement it using Sqlite, Access, etc independent of the spec. Given that most vendors already have working implementations of IndexedDB, I don't think this is a good argument ;) Cheers, Shawn
Re: Selectors API IDL Issues
On 4/1/11 4:51 PM, Lachlan Hunt wrote:
[Supplemental]
interface Element {
Element querySelector(in DOMString selectors, in optional any
...
}
This adds another method to Element.prototype
[NoInterfaceObject]
interface NodeSelector {
Element querySelector(in DOMString selectors, in optional any
...
};
Element implements NodeSelector
This adds a new interface called NodeSelector and says that any instance
of Element must implement this interface. But it does not add to
Element.prototype; the method goes on the mixin prototype object. See
http://www.w3.org/TR/WebIDL/#host-object-mixin-prototype
[NoInterfaceObject] just means there is no window.NodeSelector.
-Boris
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On Fri, 1 Apr 2011, Arthur Barstow wrote: On Apr/1/2011 3:39 PM, ext Glenn Maynard wrote: If SQLite was to be used as a web standard, I'd hope that it wouldn't show up in a spec as simply do what SQLite does, but as a complete spec of SQLite's behavior. FYI, the Web SQL Database NOTE says: [[ http://www.w3.org/TR/2010/NOTE-webdatabase-20101118/#web-sql 5. Web SQL User agents must implement the SQL dialect supported by Sqlite 3.6.19. ]] and I don't recall anyone ever committing to creating the later. Actually I did, multiple times. But nobody was interested in reimplementing that dialect independently, so all the points Jonas raised still apply. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On Fri, 1 Apr 2011, Glenn Maynard wrote: On Fri, Apr 1, 2011 at 2:39 PM, Jonas Sicking jo...@sicking.cc wrote: First of all, what should we do once the SQLite team releases a new version which has some modifications in its SQL dialect? We generally always need to embed the latest version of the library since it contains critical bug fixes, however SQLite makes no guarantees that it will always support exactly the same SQL statements. I don't find this compelling, because it assumes that the release methodology of SQLite is fixed in stone. It would be incredibly rude of us to force an independent team of developers to change development practices for our benefit. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On Sat, Apr 2, 2011 at 12:33 AM, Ian Hickson i...@hixie.ch wrote: I don't find this compelling, because it assumes that the release methodology of SQLite is fixed in stone. It would be incredibly rude of us to force an independent team of developers to change development practices for our benefit. You can certainly ask if they're interested in doing so, not for our benefit (whoever our means), but for the benefit of the Web as a whole, and there's nothing at all rude in asking. I'd say the opposite: it's rude to assume they wouldn't be interested, rather than asking and letting them come to their own decision. (I don't know where the notion of forcing them to do anything came from.) -- Glenn Maynard
Re: Selectors API IDL Issues
Lachlan Hunt:
[Supplemental]
interface Element {
Element querySelector(in DOMString selectors, in optional any
...
}
This adds another method to Element.prototype
[NoInterfaceObject]
interface NodeSelector {
Element querySelector(in DOMString selectors, in optional any
...
};
Element implements NodeSelector
Boris Zbarsky:
This adds a new interface called NodeSelector and says that any
instance of Element must implement this interface. But it does not
add to Element.prototype; the method goes on the mixin prototype
object. See
http://www.w3.org/TR/WebIDL/#host-object-mixin-prototype
Boris is right, that’s the difference, as it currently stands in Web IDL
(forgetting for a moment that [Supplemental] isn’t defined). What I
will do in the near future is implement the proposed changes to remove
multiple inheritance from Web IDL and add the “mixin prototype” concept,
which will allow you to specify the augment-an-existing-prototype
behaviour that [Supplemental] would have given you.
[NoInterfaceObject] just means there is no window.NodeSelector.
Yep. That’ll be the default for these mixin interfaces, too.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On Friday, April 1, 2011, Glenn Maynard gl...@zewt.org wrote: On Sat, Apr 2, 2011 at 12:33 AM, Ian Hickson i...@hixie.ch wrote: I don't find this compelling, because it assumes that the release methodology of SQLite is fixed in stone. It would be incredibly rude of us to force an independent team of developers to change development practices for our benefit. You can certainly ask if they're interested in doing so, not for our benefit (whoever our means), but for the benefit of the Web as a whole, and there's nothing at all rude in asking. I'd say the opposite: it's rude to assume they wouldn't be interested, rather than asking and letting them come to their own decision. (I don't know where the notion of forcing them to do anything came from.) I am incredibly uncomfortable with the idea of putting the responsibility of the health of the web in the hands of one project. In fact, one of the main reasons I started working at Mozilla was to prevent this. / Jonas
