Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

2014-02-18 Thread Alex Russell
On Tue, Feb 18, 2014 at 4:59 AM, Arthur Barstow wrote:

> On 2/17/14 9:17 AM, ext Jungkee Song wrote:
>
>  On Mon, Feb 17, 2014 at 9:38 PM, Arthur Barstow 
> > art.bars...@nokia.com>> wrote:
>>
>> The only process requirement for a FPWD is that the group record
>> consensus to publish it. However, it's usually helpful if the FPWD
>> is feature complete from a breadth perspective but there is no
>> expectation the FPWD is complete from a depth perspective. As
>> such, if there are missing features, it would be good to mention
>> that in the ED and/or file related bugs.
>>
>> I believe things are mostly addressed in a breadth perspective albeit
>> quite a few issues are still being discussed and sorted out. We are
>> currently drafting the ED and thought the F2F is sort of a right time to
>> have a consensus for FPWD but think it'll be nicer if we can make it even
>> before that to get a wider review as soon as possible.
>>
>
> Given the broad interest in this spec, I think it would be helpful to move
> toward FPWD "as soon as possible". Would you please give a "rough
> guestimate" on when you think spec can ready for a CfC to publish a FPWD?
>

I've been waiting until we have all the algorithms filled in. It's a
non-sensical document until then.


Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

2014-02-18 Thread Arthur Barstow

On 2/17/14 9:17 AM, ext Jungkee Song wrote:
On Mon, Feb 17, 2014 at 9:38 PM, Arthur Barstow > wrote:


The only process requirement for a FPWD is that the group record
consensus to publish it. However, it's usually helpful if the FPWD
is feature complete from a breadth perspective but there is no
expectation the FPWD is complete from a depth perspective. As
such, if there are missing features, it would be good to mention
that in the ED and/or file related bugs. 



I believe things are mostly addressed in a breadth perspective albeit 
quite a few issues are still being discussed and sorted out. We are 
currently drafting the ED and thought the F2F is sort of a right time 
to have a consensus for FPWD but think it'll be nicer if we can make 
it even before that to get a wider review as soon as possible.


Given the broad interest in this spec, I think it would be helpful to 
move toward FPWD "as soon as possible". Would you please give a "rough 
guestimate" on when you think spec can ready for a CfC to publish a FPWD?


-Thanks, ArtB




Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

2014-02-17 Thread Jungkee Song
On Mon, Feb 17, 2014 at 9:38 PM, Arthur Barstow wrote:

> On 2/17/14 6:47 AM, ext Jungkee Song wrote:
>
>> On Feb 17, 2014 8:02 PM, "Maciej Stachowiak" > m...@apple.com>> wrote:
>>
>> I personally would like to see it become an official draft of the Working
>> Group if it isn't already
>>
>>
> Yes, me too.
>
>
>  (the Publication Status page implies not, but perhaps I have missed
>> something).
>>
>>
> (The data for the "AppCache/ServiceWorkers" row wasn't accurate, pending
> an update from the Editors. I just replaced that row with a single entry
> for Service Workers and included a link to the ED that Jungkee provided
> below.)
>
>
Thanks for the update.


>
>  If it is being actively implemented, it would be great to publish it as a
>> Working Draft also, so we can get the IPR disclosures out of the way.
>> >
>> > Regards,
>> > Maciej
>> >
>>
>> Great to hear that. The standard track document is being drafted here.
>> [1] It'll be nicer if WebKit folks have a chance to review the ongoing work
>> [2] and join the iteration at this time.
>>
>>
> Jungkee, Alex - what needs to be done before Service Workers is ready for
> FPWD?
>
> The only process requirement for a FPWD is that the group record consensus
> to publish it. However, it's usually helpful if the FPWD is feature
> complete from a breadth perspective but there is no expectation the FPWD is
> complete from a depth perspective. As such, if there are missing features,
> it would be good to mention that in the ED and/or file related bugs.


I believe things are mostly addressed in a breadth perspective albeit quite
a few issues are still being discussed and sorted out. We are currently
drafting the ED and thought the F2F is sort of a right time to have a
consensus for FPWD but think it'll be nicer if we can make it even before
that to get a wider review as soon as possible.



> BTW, I noticed there is no Bugzilla component for Service Workers so I
> will ask Mike Smith to create one).
>
> -Thanks, AB
>
>
>
>  [1] http://rawgithub.com/slightlyoff/ServiceWorker/
>> master/spec/service_worker/index.html
>> [2] https://github.com/slightlyoff/ServiceWorker
>>
>>
>


-- 

Jungkee Song


Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

2014-02-17 Thread Jungkee Song
On Mon, Feb 17, 2014 at 10:26 PM, Arthur Barstow wrote:

> On 2/17/14 8:03 AM, ext Marcos Caceres wrote:
>
>> On Monday, February 17, 2014 at 12:38 PM, Arthur Barstow wrote:
>>
>>  BTW, I noticed there is no Bugzilla component for Service
>>> Workers so I will ask Mike Smith to create one).
>>>
>> I think they bug tracker on GH is being used instead. It's already very
>> active and it would be a shame to have to move to Bugzilla.
>>
>
> I don't have a strong preference (Bugzilla vs. GH Issues) but I do think
> only one should be used and supported. Note the ED includes the following:
>
> [[
> Participate
>File bugs
> blocked=14968&short_desc=%5BCustom%5D%3A%20&product=
> WebAppsWG&component=Service%20Workers>(w3.org'sBugzilla
>)
> ]]
>
> So I naturally assumed Bugzilla would be used (and if this isn't the case
> the above should be fixed/clarified).
>
>
The work has been done in the GH repo and all the actual players are
actively collaborating there using the GH issues. I think we should keep
using it unless otherwise determined by the contributors. I'll fix the
above text to point to the GH issues.



> -Thanks, AB
>
>
>


-- 

Jungkee Song


Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

2014-02-17 Thread Arthur Barstow

On 2/17/14 8:03 AM, ext Marcos Caceres wrote:

On Monday, February 17, 2014 at 12:38 PM, Arthur Barstow wrote:


BTW, I noticed there is no Bugzilla component for Service
Workers so I will ask Mike Smith to create one).

I think they bug tracker on GH is being used instead. It's already very active 
and it would be a shame to have to move to Bugzilla.


I don't have a strong preference (Bugzilla vs. GH Issues) but I do think 
only one should be used and supported. Note the ED includes the following:


[[
Participate
   File bugs
   
(w3.org'sBugzilla
   )
]]

So I naturally assumed Bugzilla would be used (and if this isn't the 
case the above should be fixed/clarified).


-Thanks, AB





Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

2014-02-17 Thread Marcos Caceres



On Monday, February 17, 2014 at 12:38 PM, Arthur Barstow wrote:

> 
> BTW, I noticed there is no Bugzilla component for Service
> Workers so I will ask Mike Smith to create one).

I think they bug tracker on GH is being used instead. It's already very active 
and it would be a shame to have to move to Bugzilla.  




Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

2014-02-17 Thread Arthur Barstow

On 2/17/14 6:47 AM, ext Jungkee Song wrote:


On Feb 17, 2014 8:02 PM, "Maciej Stachowiak" > wrote:


I personally would like to see it become an official draft of the 
Working Group if it isn't already




Yes, me too.

(the Publication Status page implies not, but perhaps I have missed 
something).




(The data for the "AppCache/ServiceWorkers" row wasn't accurate, pending 
an update from the Editors. I just replaced that row with a single entry 
for Service Workers and included a link to the ED that Jungkee provided 
below.)


If it is being actively implemented, it would be great to publish it 
as a Working Draft also, so we can get the IPR disclosures out of the way.

>
> Regards,
> Maciej
>

Great to hear that. The standard track document is being drafted here. 
[1] It'll be nicer if WebKit folks have a chance to review the ongoing 
work [2] and join the iteration at this time.




Jungkee, Alex - what needs to be done before Service Workers is ready 
for FPWD?


The only process requirement for a FPWD is that the group record 
consensus to publish it. However, it's usually helpful if the FPWD is 
feature complete from a breadth perspective but there is no expectation 
the FPWD is complete from a depth perspective. As such, if there are 
missing features, it would be good to mention that in the ED and/or file 
related bugs. BTW, I noticed there is no Bugzilla component for Service 
Workers so I will ask Mike Smith to create one).


-Thanks, AB


[1] 
http://rawgithub.com/slightlyoff/ServiceWorker/master/spec/service_worker/index.html

[2] https://github.com/slightlyoff/ServiceWorker






Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

2014-02-17 Thread Jungkee Song
On Feb 17, 2014 8:02 PM, "Maciej Stachowiak"  wrote:
> On Feb 16, 2014, at 2:16 AM, Marcos Caceres  wrote:
>>
>> On Sunday, February 16, 2014, Alex Russell 
wrote:
>>>
>>> On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres  wrote:

 tl;dr: I strongly agree (and data below shows) that installable web
apps without offline capabilities are essentially useless.

 Things currently specified in the manifest are supposed to help make
these apps less useless (as I said in the original email, they by no means
give us "the dream" of installable web apps, just one little step closer) -
even if we had SW tomorrow, we would still need orientation, display mode,
start URL, etc.

 So yes, SW and manifest will converge... questions for us to decide on
is when? And if appcache can see us through this transitional period to
having SW support in browsers? I believe we can initially standardize a
limited set of functionality, while we continue to wait for SW to come into
fruition which could take another year or two.
>>>
>>>
>>> SW will becoming to chrome ASAP. We're actively implementing. Jonas or
Nikhil can probably provide more Mozilla context.
>>
>>
>> I'm also interested in the WebKit and Microsoft context. I just don't
know who to ask there. Have their been any public signals of their level of
interest in SW?
>
>
> In general I think it's a good idea and I bet many other WebKit folks do
too. We haven't yet had a chance to review thoroughly but I expect we'll
like the general principles. I personally would like to see it become an
official draft of the Working Group if it isn't already (the Publication
Status page implies not, but perhaps I have missed something). If it is
being actively implemented, it would be great to publish it as a Working
Draft also, so we can get the IPR disclosures out of the way.
>
> Regards,
> Maciej
>

Great to hear that. The standard track document is being drafted here. [1]
It'll be nicer if WebKit folks have a chance to review the ongoing work [2]
and join the iteration at this time.

[1]
http://rawgithub.com/slightlyoff/ServiceWorker/master/spec/service_worker/index.html
[2] https://github.com/slightlyoff/ServiceWorker


WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

2014-02-17 Thread Maciej Stachowiak

On Feb 16, 2014, at 2:16 AM, Marcos Caceres  wrote:

> 
> 
> On Sunday, February 16, 2014, Alex Russell  wrote:
> On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres  wrote:
> tl;dr: I strongly agree (and data below shows) that installable web apps 
> without offline capabilities are essentially useless.
> 
> Things currently specified in the manifest are supposed to help make these 
> apps less useless (as I said in the original email, they by no means give us 
> "the dream" of installable web apps, just one little step closer) - even if 
> we had SW tomorrow, we would still need orientation, display mode, start URL, 
> etc.
> 
> So yes, SW and manifest will converge... questions for us to decide on is 
> when? And if appcache can see us through this transitional period to having 
> SW support in browsers? I believe we can initially standardize a limited set 
> of functionality, while we continue to wait for SW to come into fruition 
> which could take another year or two.
> 
> SW will becoming to chrome ASAP. We're actively implementing. Jonas or Nikhil 
> can probably provide more Mozilla context.
> 
> I'm also interested in the WebKit and Microsoft context. I just don't know 
> who to ask there. Have their been any public signals of their level of 
> interest in SW? 

In general I think it's a good idea and I bet many other WebKit folks do too. 
We haven't yet had a chance to review thoroughly but I expect we'll like the 
general principles. I personally would like to see it become an official draft 
of the Working Group if it isn't already (the Publication Status page implies 
not, but perhaps I have missed something). If it is being actively implemented, 
it would be great to publish it as a Working Draft also, so we can get the IPR 
disclosures out of the way.

Regards,
Maciej



Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review

2014-02-17 Thread Kenneth Rohde Christiansen
I am fine with adding it (as CSP), but like Marcos, it would be great
to know the plans for IE and Safari regarding ServiceWorker.

Would it be an option to immediately work on L2 in parallel with L1
being moved to LC?

Kenneth

On Sun, Feb 16, 2014 at 11:16 AM, Marcos Caceres  wrote:
>
>
> On Sunday, February 16, 2014, Alex Russell  wrote:
>>
>> On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres  wrote:
>>>
>>> tl;dr: I strongly agree (and data below shows) that installable web apps
>>> without offline capabilities are essentially useless.
>>>
>>> Things currently specified in the manifest are supposed to help make
>>> these apps less useless (as I said in the original email, they by no means
>>> give us "the dream" of installable web apps, just one little step closer) -
>>> even if we had SW tomorrow, we would still need orientation, display mode,
>>> start URL, etc.
>>>
>>> So yes, SW and manifest will converge... questions for us to decide on is
>>> when? And if appcache can see us through this transitional period to having
>>> SW support in browsers? I believe we can initially standardize a limited set
>>> of functionality, while we continue to wait for SW to come into fruition
>>> which could take another year or two.
>>
>>
>> SW will becoming to chrome ASAP. We're actively implementing. Jonas or
>> Nikhil can probably provide more Mozilla context.
>
>
> I'm also interested in the WebKit and Microsoft context. I just don't know
> who to ask there. Have their been any public signals of their level of
> interest in SW?
>
>
>> My personal view is that isn't not a good user experience to offer the
>> affordance if the resulting system can't be trusted. That is to say, if we
>> plow on with V1 without a (required) offline story, I'm not sure what we've
>> really won. Happy for this to go to LC, but wouldn't recommend that Chrome
>> For Android implement.
>
>
> I think this is good feedback. I'm happy to add (or for you to add;)) SW
> support to the manifest format. At least from Moz perspective it's fine as
> we are doing SW already.
>
> Anyone object to adding SW support to V1 of the manifest spec? Anything else
> that should be prioritized for V1?
>
>
>>
>>
>>>
>>> On Saturday, February 15, 2014 at 1:37 AM, Alex Russell wrote:
>>>
>>> > I further think that the marginal utility in bookmarking something to
>>> > the homescreen (sorry, yes, I'm focusing on mobile first) is low if it
>>> > doesn't have a Service Worker / Appcache associated.
>>>
>>> Although I've not published this research yet, this is strongly backed by
>>> evidence. Nearly all applications in the top 78,000 websites that opt. into
>>> being standalone applications via "apple-mobile-web-app-capable" do not, in
>>> fact, work as standalone applications. If anyone is interested to try this
>>> for themselves, here is the raw dataset listing all the sites [1] - you will
>>> need an iPhone to test them. The data set is from Oct. 2013, but should
>>> still be relevant. Just pick some at random and "add to homescreen"; it
>>> makes for depressing viewing.
>>>
>>> There are a few exceptions (listed below) - but those are the exceptions,
>>> not the rule.
>>> > It's strictly second-class-citizen territory to have "web bookmarks"
>>> > that routinely don't do anything meaningful when offline.
>>>
>>> Yes, but there are a number of factors that contribute to this: not just
>>> offline (e.g., flexbox support is still fairly limited, dev tools still
>>> suck, cross-browser is a nightmare, even how navigation works differs across
>>> UAs!, limited orientation-locking support, etc.).
>>>
>>> However, to your point the data we have shows that about 50 sites in the
>>> top 78K declare an appcache [2], while there are 1163 sites that declare
>>> "apple-mobile-web-app-capable". So yeah, appcache, as we all know, is a bit
>>> of a failure. Some of the sites that declare it actually have it commented
>>> out... like they tried it and just gave up.
>>>
>>> Interestingly, only 10 sites in the dataset are both capable of running
>>> standalone AND declare offline:
>>>
>>> 1. forecast.io
>>> 2. timer-tab.com
>>> 3. capitalone.com
>>> 4. rachaelrayshow.com
>>> 5. delicious.com
>>> 6. forbesmiddleeast.com
>>> 7. shopfato.com.br
>>> 8. ptable.com
>>> 9 authenticjobs.com
>>>
>>> 10. swedenabroad.com
>>>
>>> So, yeah... 10 / 1163 = 0.0085... or, :_(.
>>>
>>> Anyway... do you think it's ok for us to just standardize the limited
>>> things in the manifest? We could have those at LC like in 2 weeks and then
>>> spin up V2 to have convergence with SW. Better still, the SW spec can just
>>> specify how it wants to work with manifests.
>>>
>>> [1] https://gist.github.com/marcoscaceres/7419589
>>> [2] https://gist.github.com/marcoscaceres/9018819
>>> --
>>> Marcos Caceres
>>>
>>>
>>>
>>
>



-- 
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone  +45 4294 9458 ﹆﹆﹆



Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review

2014-02-16 Thread Marcos Caceres
On Sunday, February 16, 2014, Alex Russell  wrote:

> On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres 
> 
> > wrote:
>
>> tl;dr: I strongly agree (and data below shows) that installable web apps
>> without offline capabilities are essentially useless.
>>
>> Things currently specified in the manifest are supposed to help make
>> these apps less useless (as I said in the original email, they by no means
>> give us "the dream" of installable web apps, just one little step closer) -
>> even if we had SW tomorrow, we would still need orientation, display mode,
>> start URL, etc.
>>
>> So yes, SW and manifest will converge... questions for us to decide on is
>> when? And if appcache can see us through this transitional period to having
>> SW support in browsers? I believe we can initially standardize a limited
>> set of functionality, while we continue to wait for SW to come into
>> fruition which could take another year or two.
>>
>
> SW will becoming to chrome ASAP. We're actively implementing. Jonas or
> Nikhil can probably provide more Mozilla context.
>

I'm also interested in the WebKit and Microsoft context. I just don't know
who to ask there. Have their been any public signals of their level of
interest in SW?


My personal view is that isn't not a good user experience to offer the
> affordance if the resulting system can't be trusted. That is to say, if we
> plow on with V1 without a (required) offline story, I'm not sure what we've
> really won. Happy for this to go to LC, but wouldn't recommend that Chrome
> For Android implement.
>

I think this is good feedback. I'm happy to add (or for you to add;)) SW
support to the manifest format. At least from Moz perspective it's fine as
we are doing SW already.

Anyone object to adding SW support to V1 of the manifest spec? Anything
else that should be prioritized for V1?



>
>
>> On Saturday, February 15, 2014 at 1:37 AM, Alex Russell wrote:
>>
>> > I further think that the marginal utility in bookmarking something to
>> the homescreen (sorry, yes, I'm focusing on mobile first) is low if it
>> doesn't have a Service Worker / Appcache associated.
>>
>> Although I've not published this research yet, this is strongly backed by
>> evidence. Nearly all applications in the top 78,000 websites that opt. into
>> being standalone applications via "apple-mobile-web-app-capable" do not, in
>> fact, work as standalone applications. If anyone is interested to try this
>> for themselves, here is the raw dataset listing all the sites [1] - you
>> will need an iPhone to test them. The data set is from Oct. 2013, but
>> should still be relevant. Just pick some at random and "add to homescreen";
>> it makes for depressing viewing.
>>
>> There are a few exceptions (listed below) - but those are the exceptions,
>> not the rule.
>> > It's strictly second-class-citizen territory to have "web bookmarks"
>> that routinely don't do anything meaningful when offline.
>>
>> Yes, but there are a number of factors that contribute to this: not just
>> offline (e.g., flexbox support is still fairly limited, dev tools still
>> suck, cross-browser is a nightmare, even how navigation works differs
>> across UAs!, limited orientation-locking support, etc.).
>>
>> However, to your point the data we have shows that about 50 sites in the
>> top 78K declare an appcache [2], while there are 1163 sites that declare
>> "apple-mobile-web-app-capable". So yeah, appcache, as we all know, is a bit
>> of a failure. Some of the sites that declare it actually have it commented
>> out... like they tried it and just gave up.
>>
>> Interestingly, only 10 sites in the dataset are both capable of running
>> standalone AND declare offline:
>>
>> 1. forecast.io
>> 2. timer-tab.com
>> 3. capitalone.com
>> 4. rachaelrayshow.com
>> 5. delicious.com
>> 6. forbesmiddleeast.com
>> 7. shopfato.com.br
>> 8. ptable.com
>> 9 authenticjobs.com
>>
>> 10. swedenabroad.com
>>
>> So, yeah... 10 / 1163 = 0.0085... or, :_(.
>>
>> Anyway... do you think it's ok for us to just standardize the limited
>> things in the manifest? We could have those at LC like in 2 weeks and then
>> spin up V2 to have convergence with SW. Better still, the SW spec can just
>> specify how it wants to work with manifests.
>>
>> [1] https://gist.github.com/marcoscaceres/7419589
>> [2] https://gist.github.com/marcoscaceres/9018819
>> --
>> Marcos Caceres
>>
>>
>>
>>
>


Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review

2014-02-15 Thread Alex Russell
On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres  wrote:

> tl;dr: I strongly agree (and data below shows) that installable web apps
> without offline capabilities are essentially useless.
>
> Things currently specified in the manifest are supposed to help make these
> apps less useless (as I said in the original email, they by no means give
> us "the dream" of installable web apps, just one little step closer) - even
> if we had SW tomorrow, we would still need orientation, display mode, start
> URL, etc.
>
> So yes, SW and manifest will converge... questions for us to decide on is
> when? And if appcache can see us through this transitional period to having
> SW support in browsers? I believe we can initially standardize a limited
> set of functionality, while we continue to wait for SW to come into
> fruition which could take another year or two.
>

SW will becoming to chrome ASAP. We're actively implementing. Jonas or
Nikhil can probably provide more Mozilla context.

My personal view is that isn't not a good user experience to offer the
affordance if the resulting system can't be trusted. That is to say, if we
plow on with V1 without a (required) offline story, I'm not sure what we've
really won. Happy for this to go to LC, but wouldn't recommend that Chrome
For Android implement.


> On Saturday, February 15, 2014 at 1:37 AM, Alex Russell wrote:
>
> > I further think that the marginal utility in bookmarking something to
> the homescreen (sorry, yes, I'm focusing on mobile first) is low if it
> doesn't have a Service Worker / Appcache associated.
>
> Although I've not published this research yet, this is strongly backed by
> evidence. Nearly all applications in the top 78,000 websites that opt. into
> being standalone applications via "apple-mobile-web-app-capable" do not, in
> fact, work as standalone applications. If anyone is interested to try this
> for themselves, here is the raw dataset listing all the sites [1] - you
> will need an iPhone to test them. The data set is from Oct. 2013, but
> should still be relevant. Just pick some at random and "add to homescreen";
> it makes for depressing viewing.
>
> There are a few exceptions (listed below) - but those are the exceptions,
> not the rule.
> > It's strictly second-class-citizen territory to have "web bookmarks"
> that routinely don't do anything meaningful when offline.
>
> Yes, but there are a number of factors that contribute to this: not just
> offline (e.g., flexbox support is still fairly limited, dev tools still
> suck, cross-browser is a nightmare, even how navigation works differs
> across UAs!, limited orientation-locking support, etc.).
>
> However, to your point the data we have shows that about 50 sites in the
> top 78K declare an appcache [2], while there are 1163 sites that declare
> "apple-mobile-web-app-capable". So yeah, appcache, as we all know, is a bit
> of a failure. Some of the sites that declare it actually have it commented
> out... like they tried it and just gave up.
>
> Interestingly, only 10 sites in the dataset are both capable of running
> standalone AND declare offline:
>
> 1. forecast.io
> 2. timer-tab.com
> 3. capitalone.com
> 4. rachaelrayshow.com
> 5. delicious.com
> 6. forbesmiddleeast.com
> 7. shopfato.com.br
> 8. ptable.com
> 9 authenticjobs.com
>
> 10. swedenabroad.com
>
> So, yeah... 10 / 1163 = 0.0085... or, :_(.
>
> Anyway... do you think it's ok for us to just standardize the limited
> things in the manifest? We could have those at LC like in 2 weeks and then
> spin up V2 to have convergence with SW. Better still, the SW spec can just
> specify how it wants to work with manifests.
>
> [1] https://gist.github.com/marcoscaceres/7419589
> [2] https://gist.github.com/marcoscaceres/9018819
> --
> Marcos Caceres
>
>
>
>


Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review

2014-02-15 Thread Marcos Caceres
tl;dr: I strongly agree (and data below shows) that installable web apps 
without offline capabilities are essentially useless. 

Things currently specified in the manifest are supposed to help make these apps 
less useless (as I said in the original email, they by no means give us "the 
dream" of installable web apps, just one little step closer) - even if we had 
SW tomorrow, we would still need orientation, display mode, start URL, etc. 

So yes, SW and manifest will converge... questions for us to decide on is when? 
And if appcache can see us through this transitional period to having SW 
support in browsers? I believe we can initially standardize a limited set of 
functionality, while we continue to wait for SW to come into fruition which 
could take another year or two.  

On Saturday, February 15, 2014 at 1:37 AM, Alex Russell wrote:

> I further think that the marginal utility in bookmarking something to the 
> homescreen (sorry, yes, I'm focusing on mobile first) is low if it doesn't 
> have a Service Worker / Appcache associated.

Although I've not published this research yet, this is strongly backed by 
evidence. Nearly all applications in the top 78,000 websites that opt. into 
being standalone applications via "apple-mobile-web-app-capable" do not, in 
fact, work as standalone applications. If anyone is interested to try this for 
themselves, here is the raw dataset listing all the sites [1] - you will need 
an iPhone to test them. The data set is from Oct. 2013, but should still be 
relevant. Just pick some at random and "add to homescreen"; it makes for 
depressing viewing. 

There are a few exceptions (listed below) - but those are the exceptions, not 
the rule. 
> It's strictly second-class-citizen territory to have "web bookmarks" that 
> routinely don't do anything meaningful when offline.

Yes, but there are a number of factors that contribute to this: not just 
offline (e.g., flexbox support is still fairly limited, dev tools still suck, 
cross-browser is a nightmare, even how navigation works differs across UAs!, 
limited orientation-locking support, etc.). 

However, to your point the data we have shows that about 50 sites in the top 
78K declare an appcache [2], while there are 1163 sites that declare 
"apple-mobile-web-app-capable". So yeah, appcache, as we all know, is a bit of 
a failure. Some of the sites that declare it actually have it commented out... 
like they tried it and just gave up. 

Interestingly, only 10 sites in the dataset are both capable of running 
standalone AND declare offline:

1. forecast.io
2. timer-tab.com
3. capitalone.com
4. rachaelrayshow.com
5. delicious.com
6. forbesmiddleeast.com
7. shopfato.com.br
8. ptable.com
9 authenticjobs.com

10. swedenabroad.com

So, yeah... 10 / 1163 = 0.0085... or, :_(. 

Anyway... do you think it's ok for us to just standardize the limited things in 
the manifest? We could have those at LC like in 2 weeks and then spin up V2 to 
have convergence with SW. Better still, the SW spec can just specify how it 
wants to work with manifests. 

[1] https://gist.github.com/marcoscaceres/7419589
[2] https://gist.github.com/marcoscaceres/9018819
-- 
Marcos Caceres