Re: CfC: publish FPWD of UI Events; deadline May 4
On Sat, Apr 27, 2013 at 3:30 PM, Arthur Barstow art.bars...@nokia.com wrote: As discussed during WebApps' April 25 meeting, this is a Call for Consensus to publish a First Public Working Draft of the UI Events spec using the following ED as the basis: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm My main concern with this work, which I've already expressed and should not block publication but I think is worth repeating, is that this should not be a delta-specification. It should be a complete reference for MouseEvent, KeyboardEvent, etc. The goal should be to obsolete those bits of DOM Level 3 Events that DOM not already obsoleted. -- http://annevankesteren.nl/
Re: CfC: publish FPWD of UI Events; deadline May 4
+1 On 04/27/2013 05:30 PM, Arthur Barstow wrote: As discussed during WebApps' April 25 meeting, this is a Call for Consensus to publish a First Public Working Draft of the UI Events spec using the following ED as the basis: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does _not_ necessarily mean there is consensus on the spec's contents. If you have any comments or concerns about this CfC, please reply to this e-mail by May 4 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. -Thanks, AB Original Message Subject: ACTION-682: Start a CfC for FPWD of UI Events (and make sure it has a Bugzilla component) (Web Applications Working Group) Date: Thu, 25 Apr 2013 17:29:27 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-682: Start a CfC for FPWD of UI Events (and make sure it has a Bugzilla component) (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/682 On: Arthur Barstow Due: 2013-05-02 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
[quota-api] Seeking status and plans for Quota Mangement API
Hi Kinuko - during WebApps' f2f meeting last week, someone asked [Mins] about the status and plans of the Quota Management API [ED] (last published in July 2012). We would appreciate it, if you would please provide a short status and plan for that spec, especially any data you have regarding implementations and what needs to be done before the spec is feature complete. (I noticed this spec has no Bugzilla component so I will ask Mike Smith to add one.) [Mins] http://www.w3.org/2013/04/25-webapps-minutes.html#item03 [ED] https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html Original Message Subject: ACTION-679: Ask Kinuko about status and plans for Quota Mangement API (Web Applications Working Group) Date: Thu, 25 Apr 2013 17:03:03 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-679: Ask Kinuko about status and plans for Quota Mangement API (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/679 On: Arthur Barstow Due: 2013-05-02 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
[selectors-api2] Seeking implementation data re Selectors API Level 2
Hi Lachlan, During WebApps' f2f meeting last week, someone asked [Mins] about the implementation status of Selectors API Level 2. Do you have any implementation data re selectors-api2 you can share with us? -Thanks, AB [Mins] http://www.w3.org/2013/04/25-webapps-minutes.html#item03 Original Message Subject: ACTION-680: Ask Lachlan if he has some impl data re Selectors API v2 (Web Applications Working Group) Date: Thu, 25 Apr 2013 17:04:04 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-680: Ask Lachlan if he has some impl data re Selectors API v2 (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/680 On: Arthur Barstow Due: 2013-05-02 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
Re: Proposal for a DOM L3 Events Telecon
On Mon, Apr 29, 2013 at 12:59 PM, Travis Leithead travis.leith...@microsoft.com wrote: I’d like to propose we start a call to begin to work toward resolving the final bugs in the spec and for other business related to getting DOM L3 Events to CR. On the call we can workout what subsequent meetings we should also arrange. ** ** Does next Tuesday (May 7th), at 11 am PST work your you? Note that 11am PDT = 3am JST. If Masayuki is interested in joining, we should pick a late afternoon PDT time: 4pm PDT (Tue) = 8am JST (Wed) 5pm PDT (Tue) = 9am JST (Wed)
ZIP archive API?
Hi all, at the last TPAC there was discussion of a ZIP archive proposal. This has come and gone in various guises. Are there people currently interested in being able to work with ZIP in a web app? Are there implementors and is there an editor? cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: ZIP archive API?
On Tue, Apr 30, 2013 at 1:07 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi all, at the last TPAC there was discussion of a ZIP archive proposal. This has come and gone in various guises. Are there people currently interested in being able to work with ZIP in a web app? Are there implementors and is there an editor? We have https://wiki.mozilla.org/WebAPI/ArchiveAPI which is implemented as well (cc'd Andrea, who implemented it). There's also https://bugzilla.mozilla.org/show_bug.cgi?id=681967 about a somewhat-related proposal by Paul. -- http://annevankesteren.nl/
Re: ZIP archive API?
I am very interested in working with archives. I'm currently using it as a delivery from server (like quake packs), import and export format for WebGL apps. On Tue, Apr 30, 2013 at 3:18 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 30, 2013 at 1:07 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi all, at the last TPAC there was discussion of a ZIP archive proposal. This has come and gone in various guises. Are there people currently interested in being able to work with ZIP in a web app? Are there implementors and is there an editor? We have https://wiki.mozilla.org/WebAPI/ArchiveAPI which is implemented as well (cc'd Andrea, who implemented it). There's also https://bugzilla.mozilla.org/show_bug.cgi?id=681967 about a somewhat-related proposal by Paul. -- http://annevankesteren.nl/
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
The thing about reprojection is that it makes implementers life harder but it makes developers life easy. I'd rather have us do the hard work here. For the record, we have two independent implementations of the Shadow DOM spec so that should debunk some of the myths that this is too hard to implement and maintain. On Tue, Apr 30, 2013 at 10:37 AM, Ryosuke Niwa rn...@apple.com wrote: On Apr 25, 2013, at 2:42 PM, Edward O'Connor eocon...@apple.com wrote: First off, thanks to Dimitri and others for all the great work on Shadow DOM and the other pieces of Web Components. While I'm very enthusiastic about Shadow DOM in the abstract, I think things have gotten really complex, and I'd like to seriously propose that we simplify the feature for 1.0, and defer some complexity to the next level. I think we can address most of the use cases of shadow DOM while seriously reducing the complexity of the feature by making one change: What if we only allowed one insertion point in the shadow DOM? Having just 1 insertion point would let us push (most? all?) of this complexity off to level 2: * distribution, getDistributedNodes(), etc. * selector fragments matching criteria * /select/ combinator * content select * shadow ? * reprojection I'm in favor of removing all forms of redistributions except the one where the entire content is inserted at exactly one location. This will reduce things authors can do but it will considerably reduce the implementation complexity and eliminates almost all performance penalties. - R. Niwa -- erik
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
I'm concerned that we're over engineering here. I do understand adding reprojection significantly reduces the need to write author scripts, but I would like to see us implement the truly minimal set of features, have all browsers ship it, and see how authors, particularly that of high profile websites such as Facebook and Twitter use it in real life. Granted, I know people have talked to developers and got feedback, etc… but nothing beats the use in production code. I'd like to see the Web platform improve organically by means of positive feedback loop between browser vendors and Web developers. Take position: sticky for example. We saw web developers using JavaScript and CSS to emulate a particular mode of layout so we've added a new CSS value to natively support that. For reprojection, I don't think we have sufficient data points to tell how exactly authors are going to use or what they're going to create with shadow DOM, and what percentage of common use cases reprojections address. On Apr 30, 2013, at 10:52 AM, Erik Arvidsson a...@chromium.org wrote: The thing about reprojection is that it makes implementers life harder but it makes developers life easy. I'd rather have us do the hard work here. For the record, we have two independent implementations of the Shadow DOM spec so that should debunk some of the myths that this is too hard to implement and maintain. On Tue, Apr 30, 2013 at 10:37 AM, Ryosuke Niwa rn...@apple.com wrote: On Apr 25, 2013, at 2:42 PM, Edward O'Connor eocon...@apple.com wrote: First off, thanks to Dimitri and others for all the great work on Shadow DOM and the other pieces of Web Components. While I'm very enthusiastic about Shadow DOM in the abstract, I think things have gotten really complex, and I'd like to seriously propose that we simplify the feature for 1.0, and defer some complexity to the next level. I think we can address most of the use cases of shadow DOM while seriously reducing the complexity of the feature by making one change: What if we only allowed one insertion point in the shadow DOM? Having just 1 insertion point would let us push (most? all?) of this complexity off to level 2: * distribution, getDistributedNodes(), etc. * selector fragments matching criteria * /select/ combinator * content select * shadow ? * reprojection I'm in favor of removing all forms of redistributions except the one where the entire content is inserted at exactly one location. This will reduce things authors can do but it will considerably reduce the implementation complexity and eliminates almost all performance penalties. - R. Niwa -- erik
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
On 4/30/13 1:52 PM, Erik Arvidsson wrote: For the record, we have two independent implementations of the Shadow DOM spec Do we? Correct ones that are actually shipping in a UA? -Boris
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
I'm concerned that if the spec shipped as you described, that it would not be useful enough to developers to bother using it at all. Without useful redistributions, authors can't use composition of web components very well without scripting. At that point, it's not much better than just leaving it all in the document tree. I too would like to see the Web develop organically bits at a time, but ShadowDOM fundamentally changes how the DOM works. This feels like at the inception of the automobile, deciding that a gasoline engine is too complicated and instead selling customers a horse hitched to body. We won't get good feedback on developer uptake if we take out the biggest gamechanger. On Tue, Apr 30, 2013 at 11:10 AM, Ryosuke Niwa rn...@apple.com wrote: I'm concerned that we're over engineering here. I do understand adding reprojection significantly reduces the need to write author scripts, but I would like to see us implement the truly minimal set of features, have all browsers ship it, and see how authors, particularly that of high profile websites such as Facebook and Twitter use it in real life. Granted, I know people have talked to developers and got feedback, etc… but nothing beats the use in production code. I'd like to see the Web platform improve organically by means of positive feedback loop between browser vendors and Web developers. Take position: sticky for example. We saw web developers using JavaScript and CSS to emulate a particular mode of layout so we've added a new CSS value to natively support that. For reprojection, I don't think we have sufficient data points to tell how exactly authors are going to use or what they're going to create with shadow DOM, and what percentage of common use cases reprojections address. On Apr 30, 2013, at 10:52 AM, Erik Arvidsson a...@chromium.org wrote: The thing about reprojection is that it makes implementers life harder but it makes developers life easy. I'd rather have us do the hard work here. For the record, we have two independent implementations of the Shadow DOM spec so that should debunk some of the myths that this is too hard to implement and maintain. On Tue, Apr 30, 2013 at 10:37 AM, Ryosuke Niwa rn...@apple.com wrote: On Apr 25, 2013, at 2:42 PM, Edward O'Connor eocon...@apple.com wrote: First off, thanks to Dimitri and others for all the great work on Shadow DOM and the other pieces of Web Components. While I'm very enthusiastic about Shadow DOM in the abstract, I think things have gotten really complex, and I'd like to seriously propose that we simplify the feature for 1.0, and defer some complexity to the next level. I think we can address most of the use cases of shadow DOM while seriously reducing the complexity of the feature by making one change: What if we only allowed one insertion point in the shadow DOM? Having just 1 insertion point would let us push (most? all?) of this complexity off to level 2: * distribution, getDistributedNodes(), etc. * selector fragments matching criteria * /select/ combinator * content select * shadow ? * reprojection I'm in favor of removing all forms of redistributions except the one where the entire content is inserted at exactly one location. This will reduce things authors can do but it will considerably reduce the implementation complexity and eliminates almost all performance penalties. - R. Niwa -- erik
[webcomponents]: Comprehensive update of Custom Elements spec
Greetings, fellow public-webappsters! Over the past few weeks, I've been digging through implementation feedback and bugs, and polishing the Custom Elements spec. I think it is now in a pretty nice state, so come lookit: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html Notable changes/additions: 1) Removed declarative stuff for now -- will rewrite it based on our recent discussions 2) Added lifecycle callbacks on prototype and machinery to maintain them: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18747, https://www.w3.org/Bugs/Public/show_bug.cgi?id=21660 3) Made all elements upgrade (not just those in trees): https://www.w3.org/Bugs/Public/show_bug.cgi?id=21485 4) Lots of terminology polish 5) Reorganized the spec to flow more naturally. Comments/critique/bugs are appreciated! :DG
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
On Apr 18, 2013 6:19 PM, Paul Bakaus pbak...@zynga.com wrote: Hi Jonas, Thanks for this I feel this is heading somewhere, finally! I still need to work on submitting my full feedback, but I'd like to mention this: Why did nobody so far in this thread include real world use cases? For a highly complex topic like this in particular, I would think that collecting a large number of user use cases, not only requirements, and furthermore finding the lowest common denominator based on them, would prove very helpful, even if it's just about validation and making people understand your lengthy proposal. I.e. a news reader that needs to sync content, but has an offline UI. Do you have a list collected somewhere? Sorry for not including the list in the initial email. It was long enough as it was so I decided to stop. Some of the use cases we discussed were: Small simple game The game consists of a set of static resources. A few HTML pages, like high score page, start page, in-game page, etc. A larger number of media resources. A few data resources which contain level metadata. Small amount of dynamic data being generated, such as progress on each level, high score, user info. In-game performance is critical, all resources must be guaranteed to be available locally once the game starts. Little need for network connectivity other than to update game resources whenever an update is available. Advanced game Same as simple game, but also downloads additional levels dynamically. Also wants to store game progress on servers so that it can be synced across devices. Wikipedia Top level page and its resources are made available offline. Application logic can enable additional pages to be made available offline. When such a page is made available offline both the page and any media resources that it uses needs to be cached. Doesn't need to be updated very aggressively, maybe only upon user request. Twitter A set of HTML templates that are used to create a UI for a database of tweets. The same data is visualized in several different ways, for example in the user's default tweet stream, in the page for an individual tweet, and in the conversation thread view. Downloading the actual tweet contents and metadata shouldn't need to happen multiple times in order to support the separate views. The URLs for watching individual tweets needs to be the same whether the user is using appcache or not so that linking to a tweet always works. It is very important that users are upgraded to the latest version of scripts and templates very quickly after they become available. The website likely will want to be able to check for updates on demand rather than relying on implementation logic. If the user is online but has appcached the website it should be able to use the cached version. This should be the case even if the user navigates to a tweet page for a tweet for which the user hasn't yet cached the tweet content or metadata. In this case only the tweet content and metadata should need to be downloaded and the cached templates should be used. If the user does not have twitter in the appcache and navigates to the URL for an individual tweet the website needs to be able to send a page which inlines resources such as CSS and JS files. This is important in order to avoid additional round trips. Webmail A lot of simularities with the twitter use case. The website is basically a UI for the database of emails. However its additionally important that the user can compose emails, including attach attachments, which are saved and synchronized once the user goes online. There are also other actions that the user might have taken while offline. This means that complicated conflict resolution might need to be done in order to synchronize with changes that has happened on the server. Blog reading Store the last X days of blog posts locally. Each blog post consists of the blog text as well as a few images. Other websites can link to individual posts. Each post contains a list of comments for the post. Adding comments should be possible even while offline. Once the user goes online it should be possible to submit these comments. Blog authoring Same as blog reading, but probably want to cache a larger set of posts. Repository of unpublished posts should be available for editing offline. Once the user goes online these edits are synced to server, and any posts that were published while offline are automatically published. Both adding and removing comments should be possible while offline. These changes too are published once user goes online. News website Front page with links to various articles. Each article as well as front page contains both text and images/media. Both front page and articles contains ads. A set of top articles are automatically cached and kept up-to-date. Potentially users can configure additional areas of interest which would cause additional articles from those areas to get cached. We should definitely put
Re: Fixing appcache: a proposal to get us started
On Mon, Apr 1, 2013 at 4:03 AM, Glenn Jones
glennjones...@googlemail.com wrote:
I think this outline for improving AppCache is a really good start, but I
can see one major problem with it. As you point out AppCache was initially
designed for building simple single page web apps.
The appcache appears to be aimed at too simple applications. It works
fine if the website you want to cache consists of a small set of
static resources and otherwise only use features like IndexedDB or
localStorage to manage dynamic data. But once an application uses
server-side processing to dynamically generate resources based on
query parameters or other parts of the URL, then it requires that you
change the way that your application works.
I completely agree with the above point, but I don’t think it can be done
with prefix URLs, which are all but useless in dealing with “dynamically
generated resource based” sites. The example code you give for urlmaps only
shows how prefixs can be used to handle querystrings.
What is required is a way to cover all the common URL design patterns found
in the real world i.e. paving cow paths. Most importantly we need url
matching that works against section namespace design patterns i.e.
https://github.com/glennjones/microformat-node/issues
http://lanyrd.com/2012/jsconf-us/speakers/
http://www.quora.com/URLs/recent
To deal with theses URL structures you need to use something like the route
matching built into JavaScript MVC frameworks
urlmap: [{
url: https://github/:*/:*/issues;,
page: https://github/profile/project/issues;
}]
In the example above the :* wildcards match against the section of the URL
which needs to be ignored and allows you to match at a deeper level than
prefix urls.
Unless the new version of AppCache supports the current patterns of URL
design used on the web it will be forever assigned to build single page
apps. There will be no chance of progressively enhancing a large complex
site with AppCache, if it cannot deal with pre-existing URL design.
I like this a lot! I definitely want to make sure that we don't end up
with full regexp complexity in the type of patterns that we support,
but I agree that only supporting prefixes does seem like too small of
a subset.
I wouldn't be surprised if we'll end up having to expand to support
things like query parameters as well, but starting with prefixes and
patterns that can do wild-cards for individual path segments sounds
great.
/ Jonas
Re: Fixing appcache: a proposal to get us started
On Wed, Apr 3, 2013 at 5:50 AM, Robin Berjon ro...@w3.org wrote:
On 29/03/2013 21:08 , Jonas Sicking wrote:
* Cache both files (poor bandwidth)
* We could enable some way of flagging which context different URLs
are expected to be used in. That way the UA can send the normal
content negotiation headers for images vs media files. I'm not sure
that this is worth it though given how few websites use content
negotiation headers.
* Use script to detect which formats are supported by the UA and then
use cacheURL to add the appropriate URL to the cache.
* Use the NavigationController feature.
* Use UA-string detection. You can either send different manifests
that point to different URLs for the media, or use a single manifest
but do the UA detection and serve different media files from the same
media URL. This is a pretty crappy solution though.
Another option: in your list of URLs to cache, instead of just strings you
can also have objects of the form { video/webm: kittens.webm,
video/evil: dead-kittens.mv4 } that would operate in a manner modelled
on source, caching only what's needed.
It's a bit verbose, but it's a lot less verbose than loading the content
twice.
Yes. The proposal already suggests using objects to express individual
resources. Something like the above seems like a natural extension.
Audio and video in general will be tricky until there's a set of
codecs that can be universally depended on. We'd likely have to deal
with video players written in flash too :(
/ Jonas
Re: Fixing appcache: a proposal to get us started
On 01/05/2013, at 2:20 PM, Jonas Sicking jo...@sicking.cc wrote: The current AppCache spec suffers from this too, but only once users go offline. I.e. I can use FALLBACK to take over http://users.example.edu/~alice/ using a resource from from http://users.example.edu/~bob/newalice.html But that only works when the user is offline, which limits the damage a little. Yeah, I noticed that too; like you say, it's pretty limited. I did some quick testing and couldn't get current implementations to do it (I think because either they haven't completely implemented fallback, or I wasn't properly triggering it). The only solution that I can see to this problem is requiring that manifests, or navigationcontroller-scripts are only allowed to take over URLs that are below them. I.e. http://users.example.edu/~bob/manifest.json could only control navigations to URLs with the prefix http://users.example.edu/~bob/;. You could still redirect resource loading in more flexible ways, but maybe top-level page loads needs to have this restriction. Possibly. I'm still a bit wary of that; there are some *weird* CMSs out that that hide lots of things behind opaque, unstructured URLs. Cheers, -- Mark Nottingham http://www.mnot.net/
