Re: fixing appcache...
Hi Chaals, On 24/03/2013 01:33 , Charles McCathie Nevile wrote: 2. Bundles. Sometimes we need to load several resources (js/css/json/...) before we can actually show something to user. Like a dialog, or another complex control. Or if it's a single page application before change page. Again, it's often faster to make one request than several, but it would be even faster if we could then cache them separately: HttpCache.store(url1, content1); HttpCache.store(url2, content2); ... So that later we can use the files as usual (script, link...). Most of what you list can be handled by NavCon, but I was wondering about this specific case. Do you believe that this would be helped by having some form of simple packaging system that's addressable à la JAR? Basically you'd have one Zip archive containing your dependencies, and load them with script src='/wrapped-content.zip!/foo.js' and friends. There are a few slightly tricky bits to handle, but nothing insurmountable. This sort of stuff has been a small blip on the radar for essentially ever but if there's enough implementer interest it could be brought alive. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Fixing appcache: a proposal to get us started
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.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: Fixing appcache: a proposal to get us started
On Tue, Mar 26, 2013 at 7:02 AM, Jonas Sicking jo...@sicking.cc wrote: The details of the API in this worker is something we haven't looked at yet. It's a very big task in and of itself. Fortunately, Alex Russell and a few others have worked on a proposal for exactly this at [2]. The intent is for these two proposals to be aligned such that they work well together. They are already very complementary in their feature sets, so this should not be a problem. However this is something that we've just started looking at, and since both proposals are still under heavy development, I didn't want to wait until they are both aligned before publishing what we have so far. [2] https://github.com/slightlyoff/NavigationController So I think working on both makes a lot of sense as the requirements of one will influence the other in positive ways. However, when it comes to deploying, I think if we deployed the controller first and see what kind of feedback we get from library developers down the line and use that to further influence the development of the declarative model we'll yield better results. There are many hard problems to solve, some of which come down to heuristics, and it seems like letting hundreds of developers experiment rather than a couple of browser implementers will lead to better results down the line. Having said, what we need to resolve for both, and I think is one of the trickier bits, is the life cycle. How is it added, when does it go into effect, when and how is it replaced, etc. -- http://annevankesteren.nl/
[dom-futures] Making ProgressFuture use real events
The ProgressFuture strawman at https://github.com/slightlyoff/DOMFuture/blob/master/ProgressFuture.idl augments a future with an analog of progress events. Why isn't this just using actual events? That is, make ProgressFuture an eventTarget as well, which fires progress events. I'm fine with the existing API existing as it is, where convenience APIs are provided both for firing (a 'progress' method on the resolver) and listening to (a 'progress' method on the future) progress events. It just seems weird to implement events without them being actual Events. ~TJ
[Bug 21559] [IndexedDB] Term primary key needs defining
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21559 Joshua Bell jsb...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Joshua Bell jsb...@chromium.org --- Made those changes in https://dvcs.w3.org/hg/IndexedDB/rev/fa1c7695ba67 -- You are receiving this mail because: You are on the CC list for the bug.
Re: [dom-futures] Making ProgressFuture use real events
On Wed, Apr 3, 2013 at 10:43 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The ProgressFuture strawman at https://github.com/slightlyoff/DOMFuture/blob/master/ProgressFuture.idl augments a future with an analog of progress events. Why isn't this just using actual events? That is, make ProgressFuture an eventTarget as well, which fires progress events. I'm fine with the existing API existing as it is, where convenience APIs are provided both for firing (a 'progress' method on the resolver) and listening to (a 'progress' method on the future) progress events. It just seems weird to implement events without them being actual Events. Define seems weird. Using Events as a way to do callbacks has many advantages when using them on Nodes. However they provide much less value when used on standalone objects like XMLHttpRequest and a Future object. With using a callback it means that we can both provide a more convenient registration syntax: doSomeAsyncThing(...).progress(showProgress).then(processResult, handleError); Additionally the actual progress handler gets a cleaner API. Instead of having an Event object that has a bunch of irrelevant stuff on it, like .stopPropagation(), .preventDefault() and .bubbling, the caller just gets the relevant data. We've come to use Events as a general callback mechanism. However that's never been where they shine. Using Events here just causes more edge cases to define for us, likely more code for implementations, and more and less convenient API for authors. / Jonas
Re: [dom-futures] Making ProgressFuture use real events
On Wed, Apr 3, 2013 at 11:45 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Apr 3, 2013 at 10:43 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The ProgressFuture strawman at https://github.com/slightlyoff/DOMFuture/blob/master/ProgressFuture.idl augments a future with an analog of progress events. Why isn't this just using actual events? That is, make ProgressFuture an eventTarget as well, which fires progress events. I'm fine with the existing API existing as it is, where convenience APIs are provided both for firing (a 'progress' method on the resolver) and listening to (a 'progress' method on the future) progress events. It just seems weird to implement events without them being actual Events. Define seems weird. Using Events as a way to do callbacks has many advantages when using them on Nodes. However they provide much less value when used on standalone objects like XMLHttpRequest and a Future object. With using a callback it means that we can both provide a more convenient registration syntax: doSomeAsyncThing(...).progress(showProgress).then(processResult, handleError); Additionally the actual progress handler gets a cleaner API. Instead of having an Event object that has a bunch of irrelevant stuff on it, like .stopPropagation(), .preventDefault() and .bubbling, the caller just gets the relevant data. We've come to use Events as a general callback mechanism. However that's never been where they shine. Using Events here just causes more edge cases to define for us, likely more code for implementations, and more and less convenient API for authors. I'm fine if this kind of break is *intentional*. It wasn't clear to me that it was - it just looked like the API was reinventing events in a custom way, just like so many APIs reinvent futures in a custom way right now. If that's the case, it should be documented somewhere that, if you're attaching something event-like (where 0+ listeners subscribe to 0+ notifications) to a future, but don't need the full DOM event system, you should do it in this particular way. ~TJ
Re: File API: Blob.type
On Mar 19, 2013, at 8:52 PM, Glenn Maynard wrote: On Tue, Mar 19, 2013 at 1:41 PM, Arun Ranganathan a...@mozilla.com wrote: 2.Convert every character in relativeContentType to lower case. I recommend referencing Converting a string to ASCII lowercase in HTML. http://www.whatwg.org/specs/web-apps/current-work/#converted-to-ascii-lowercase Done. 1.If relativeContentType contains any non-ASCII characters, then set relativeContentType to the empty string and return from these substeps. 3.If relativeContentType contains any line break characters like CR or LF or any CTLs or separators, then set relativeContentType to the empty string and return from these substeps. #3 is too vague. I recommend combining #1 and #3, saying: If any character in relativeContentType outside of the range U+0020 to U+007E. That's the printable ASCII range, and excludes all control characters. Done (+ thanks). 4.Parse relativeContentType as an RFC2616 media-type, tokenizing it according to the ABNF for media-type [RFC2616] with the ASCII / character separating tokens representing the type and subtype productions. If relativeContentType cannot be tokenized according to the ABNF for media-type [RFC2616], then set relativeContentType to the empty string and return from these substeps. I'm not sure we should be this strict. I'd lean towards keeping it simple, allowing any string at all as long as it contains only lowercase, printable ASCII. Done -- we restrict it now, but don't mandate tokenization along the lines of RFC2616. You don't need to say The following requirements are normative for this parameter. That's what the normative language that follows (must) means. Done. My only concern is that blob.type should never contain parameters. Comparing it to text/plain or image/jpeg should work, and not mysteriously fail a year later when somebody eventually throws a MIME type parameter into the mix. Today, all browsers expose text files at text/plain. If a browser a year from now decides to call text files with a UTF-8 BOM text/plain; charset=UTF-8, it'll break interop. Additionally, determining a blob's file type seems like the most obvious use of this property, and making people say if(blob.type.split(;)[0] == 'text/plain') is simply not a good interface. OK -- you're strongly opinionated on the matter of NOT allowing a charset parameter. I'd like to see if implementers who had an opinion on its usefulness can weigh in -- Darin? Alexey? http://dev.w3.org/2006/webapi/FileAPI/ -- A*
Re: [webcomponents]: Scope of link rel=components, was: Naming the Baby
I was having a conversation with someone about this topic offline.
Given the legitimacy of:
link rel=import href=/imports/heart.html
link rel=stylesheet href=/stylesheets/style.css
The person felt they should be able / wants to be able to:
link rel=script href=/js/script.js
I didn't have a long conversation about this, just in passing. Basically
their reasoning was that they wanted a consistent syntax for importing
anything into the page that they needed, and seeing as how the syntax of
html and style imports are the same, they want to be able to load external
scripts in kind.
I explained, though, that both of these imports/links are synchronous and
blocking. If I'm reading the spec correctly then using this method to
import scripts would not have the same flexibility to use async and defer,
and loading your script this way (if it were possible) would be blocking.
Then, of course, they suggested we be able to async/defer ANY import/link.
That provoked my 'can of worms' feeling. Are there plans for anything like
async/defer for imports? It looks like in order to support this, link
would have to change considerably behind the scenes.
Would love to understand the non-obvious implications of these questions
and ideas.
Cheers,
- Angelina
On Wed, Apr 3, 2013 at 2:23 PM, Simon Pieters sim...@opera.com wrote:
On Wed, 03 Apr 2013 09:55:33 +0200, Scott Miles sjmi...@google.com
wrote:
Why don't we use script as the mechanism to import a component?
One of the primary advancements of Custom Elements spec lies in the
ability
to combine HTML (templates), scoped CSS, and JavaScript into
encapsulations. General HTML markup is an ideal vehicle.
Specific syntaxes are still under debate, but this is the kind of thing we
do using the polyfills:
element name='x-bundle-of-awesome'
template
style
/* scoped to this element */
/style
!-- Shadow DOM markup --
/template
script
// this === element
this.register({ /* controller prototype */});
/script
/element
I don't understand how the above answers my question.
--
Simon Pieters
Opera Software
RE: Reminder: Please register for Face to face by Friday
Chaals, The wiki says the host is eBay with an address given. Is the address still accurate? If not, will someone who knows the correct address update the wiki? http://www.w3.org/wiki/Webapps/April2013Meeting -Original Message- From: Chaals Nevile [mailto:w...@chaals.com] Sent: Wednesday, April 3, 2013 3:49 AM To: public-webapps WG Subject: Reminder: Please register for Face to face by Friday Hi folks, a reminder that Paypal (our meeting hosts) have asked us to have registration done by Friday to help their planning. If you expect to attend, but haven't got around to telling us, please do so at https://www.w3.org/2002/09/wbs/42538/webapps-april-2013/ If you are hoping to come but unable to confirm by Friday, please go ahead and register now, and note in the general comments section that you are not confirmed and when you expect to know for sure. If you do not register by the deadline, and later decide you want to attend, please contact Art and me, and we will see what we can do. cheers Chaals -- Chaals - standards declaimer
RE: Reminder: Please register for Face to face by Friday
Ah, good to know. Thanks. From: Chris Wilson [mailto:cwi...@google.com] Sent: Wednesday, April 3, 2013 3:15 PM To: Travis Leithead Cc: Chaals Nevile; public-webapps WG Subject: Re: Reminder: Please register for Face to face by Friday Paypal is in the same building complex with eBay (the address is the same, although I think the building number is different). On Wed, Apr 3, 2013 at 3:06 PM, Travis Leithead travis.leith...@microsoft.commailto:travis.leith...@microsoft.com wrote: Chaals, The wiki says the host is eBay with an address given. Is the address still accurate? If not, will someone who knows the correct address update the wiki? http://www.w3.org/wiki/Webapps/April2013Meeting -Original Message- From: Chaals Nevile [mailto:w...@chaals.commailto:w...@chaals.com] Sent: Wednesday, April 3, 2013 3:49 AM To: public-webapps WG Subject: Reminder: Please register for Face to face by Friday Hi folks, a reminder that Paypal (our meeting hosts) have asked us to have registration done by Friday to help their planning. If you expect to attend, but haven't got around to telling us, please do so at https://www.w3.org/2002/09/wbs/42538/webapps-april-2013/ If you are hoping to come but unable to confirm by Friday, please go ahead and register now, and note in the general comments section that you are not confirmed and when you expect to know for sure. If you do not register by the deadline, and later decide you want to attend, please contact Art and me, and we will see what we can do. cheers Chaals -- Chaals - standards declaimer
Re: Reminder: Please register for Face to face by Friday
Paypal is in the same building complex with eBay (the address is the same, although I think the building number is different). On Wed, Apr 3, 2013 at 3:06 PM, Travis Leithead travis.leith...@microsoft.com wrote: Chaals, The wiki says the host is eBay with an address given. Is the address still accurate? If not, will someone who knows the correct address update the wiki? http://www.w3.org/wiki/Webapps/April2013Meeting -Original Message- From: Chaals Nevile [mailto:w...@chaals.com] Sent: Wednesday, April 3, 2013 3:49 AM To: public-webapps WG Subject: Reminder: Please register for Face to face by Friday Hi folks, a reminder that Paypal (our meeting hosts) have asked us to have registration done by Friday to help their planning. If you expect to attend, but haven't got around to telling us, please do so at https://www.w3.org/2002/09/wbs/42538/webapps-april-2013/ If you are hoping to come but unable to confirm by Friday, please go ahead and register now, and note in the general comments section that you are not confirmed and when you expect to know for sure. If you do not register by the deadline, and later decide you want to attend, please contact Art and me, and we will see what we can do. cheers Chaals -- Chaals - standards declaimer
RE: Reminder: Please register for Face to face by Friday
Paypal was acquired by eBay, but kept Paypal brand, called eBay's Paypal business. Bin Hu | Service Standards | ATT +1-425-214-3305 From: Chris Wilson [mailto:cwi...@google.com] Sent: Wednesday, April 03, 2013 3:15 PM To: Travis Leithead Cc: Chaals Nevile; public-webapps WG Subject: Re: Reminder: Please register for Face to face by Friday Paypal is in the same building complex with eBay (the address is the same, although I think the building number is different). On Wed, Apr 3, 2013 at 3:06 PM, Travis Leithead travis.leith...@microsoft.commailto:travis.leith...@microsoft.com wrote: Chaals, The wiki says the host is eBay with an address given. Is the address still accurate? If not, will someone who knows the correct address update the wiki? http://www.w3.org/wiki/Webapps/April2013Meeting -Original Message- From: Chaals Nevile [mailto:w...@chaals.commailto:w...@chaals.com] Sent: Wednesday, April 3, 2013 3:49 AM To: public-webapps WG Subject: Reminder: Please register for Face to face by Friday Hi folks, a reminder that Paypal (our meeting hosts) have asked us to have registration done by Friday to help their planning. If you expect to attend, but haven't got around to telling us, please do so at https://www.w3.org/2002/09/wbs/42538/webapps-april-2013/ If you are hoping to come but unable to confirm by Friday, please go ahead and register now, and note in the general comments section that you are not confirmed and when you expect to know for sure. If you do not register by the deadline, and later decide you want to attend, please contact Art and me, and we will see what we can do. cheers Chaals -- Chaals - standards declaimer
Re: Reminder: Please register for Face to face by Friday
On 4/3/13 6:14 PM, ext Chris Wilson wrote: Paypal is in the same building complex with eBay (the address is the same, although I think the building number is different). Yes, thanks Chris. As the meeting date gets closer, Chaals or I will clarify the logistics (e.g. building number). (As I understand it, we will enter the main PayPal/eBay building at 2211 N. 1st St. San Jose, sign in and then get directed to our meeting room. Visitors are not required to sign a NDA.) -AB
Re: Fixing appcache: a proposal to get us started
I love the idea! It is the best solution listed so far.
On Wed, Apr 3, 2013 at 9: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.
--
Robin Berjon - http://berjon.com/ - @robinberjon
[selectors-api] References to Selectors 4
http://www.w3.org/TR/selectors-api2/#the-scope-pseudo-class This section has already been copied to Selectors 4 (and has been for awhile, actually), so should be removed here and replaced with references to Selectors 4. http://www.w3.org/TR/selectors4/#the-scope-pseudo If there's anything that needs to be fixed in Selectors 4 for this to be viable, then let us know and we'll fix it. :) http://www.w3.org/TR/selectors-api2/#grammar Tab just updated the grammar productions in Selectors 4 and defined some terms, so this section shouldn't need to define anything, just reference Selectors 4. http://dev.w3.org/csswg/selectors4/#grammar http://www.w3.org/TR/selectors-api2/#processing-selectors We also added the algorithm for absolutizing a relative selector to the Selectors 4 spec, so you can reference scope-relative selectors, as defined here: http://dev.w3.org/csswg/selectors4/#scoping Please let us know if there are any errors. We'll try to publish a new WD soon with the updated definitions. ~fantasai + TJ
