From josh.m.sharpe at gmail.com Tue Feb 7 18:21:06 2012 From: josh.m.sharpe at gmail.com (Josh Sharpe) Date: Tue, 7 Feb 2012 21:21:06 -0500 Subject: [html5] app manifest & 404/500 pages Message-ID: I have a manifest that looks somethin like this: CACHE MANIFEST # e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a /a/application.js /a/application.css NETWORK: * FALLBACK: / /offline The issue is that my /404.html and /500.html pages (that are obviously served up with a response code of 404 and 500) are triggering the fallback. They both act just as if the server is offline. My question is twofold: 1) Why does /404.html trigger the fallback when /events doesn't? 2) How can I allow /404.html and /500.html to not trigger the fallback while still allowing / to trigger it. For what it's worth, I've already tried this: NETWORK: * /404.html /500.html ... however since those pages are served w/ a non-200 response code, it triggers the app cache error callback and the cache isn't saved. Thanks! Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Wed Feb 8 12:30:24 2012 From: ian at hixie.ch (Ian Hickson) Date: Wed, 8 Feb 2012 20:30:24 +0000 (UTC) Subject: [html5] app manifest & 404/500 pages In-Reply-To: References: Message-ID: On Tue, 7 Feb 2012, Josh Sharpe wrote: > > I have a manifest that looks somethin like this: > > CACHE MANIFEST > # e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a > /a/application.js > /a/application.css > > NETWORK: > * > > FALLBACK: > / /offline > > The issue is that my /404.html and /500.html pages (that > are obviously served up with a response code of 404 and 500) are triggering > the fallback. They both act just as if the server is offline. This is intentional. A server responding with an error code or redirect is how we determine whether the server is offline or not. (In practice, people are rarely "offline", so much as just in a very bad network situation or on wifi with a captive portal, where all traffic to your site gets redirected. That's why we use this mechanism.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From josh.m.sharpe at gmail.com Wed Feb 8 13:20:35 2012 From: josh.m.sharpe at gmail.com (Josh Sharpe) Date: Wed, 8 Feb 2012 16:20:35 -0500 Subject: [html5] app manifest & 404/500 pages In-Reply-To: References: Message-ID: There must be some altnative or a best-practice that I'm missing here. Based on your response I can only conclude that I either 1) Don't respond, ever, with 400+ error codes 2) Don't use the FALLBACK directive with "/ /foo" Maybe there's some workaround? Btw, the FALLBACK example that I'm using is basically the last one described here: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#some-sample-manifests On Wed, Feb 8, 2012 at 3:30 PM, Ian Hickson wrote: > On Tue, 7 Feb 2012, Josh Sharpe wrote: > > > > I have a manifest that looks somethin like this: > > > > CACHE MANIFEST > > # e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a > > /a/application.js > > /a/application.css > > > > NETWORK: > > * > > > > FALLBACK: > > / /offline > > > > The issue is that my /404.html and /500.html pages (that > > are obviously served up with a response code of 404 and 500) are > triggering > > the fallback. They both act just as if the server is offline. > > This is intentional. A server responding with an error code or redirect is > how we determine whether the server is offline or not. > > (In practice, people are rarely "offline", so much as just in a very bad > network situation or on wifi with a captive portal, where all traffic to > your site gets redirected. That's why we use this mechanism.) > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Wed Feb 8 14:29:36 2012 From: ian at hixie.ch (Ian Hickson) Date: Wed, 8 Feb 2012 22:29:36 +0000 (UTC) Subject: [html5] app manifest & 404/500 pages In-Reply-To: References: Message-ID: On Wed, 8 Feb 2012, Josh Sharpe wrote: > > There must be some altnative or a best-practice that I'm missing here. > > Based on your response I can only conclude that I either > 1) Don't respond, ever, with 400+ error codes You can respond with 4xx and 5xx codes, sure. This should never be an issue. You'll only ever respond with a 4xx code in the case of a client-side error, which should never happen, and you'll only ever respond with 5xx codes in the case of a server-side error, in which case you might as well be offline. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From josh.m.sharpe at gmail.com Fri Feb 10 17:13:09 2012 From: josh.m.sharpe at gmail.com (Josh Sharpe) Date: Fri, 10 Feb 2012 19:13:09 -0600 Subject: [html5] app manifest & 404/500 pages In-Reply-To: References: Message-ID: None of this solves the problem at hand though.... To restate it: My manifest has an OFFLINE section of "/ /offline" Once that manifest has been loaded, and cached successfully and the user is still online, my 404 and 500 pages are broken. Instead of showing the content of those pages, the browser is rendering the cached version of /offline The only solution I can figure out right now is to have those pages respond with 200, which is just wrong. I'm sorry if I've missed your proposed solution. Would you mind elaborating once more? Thanks! Josh On Wed, Feb 8, 2012 at 4:29 PM, Ian Hickson wrote: > On Wed, 8 Feb 2012, Josh Sharpe wrote: > > > > There must be some altnative or a best-practice that I'm missing here. > > > > Based on your response I can only conclude that I either > > 1) Don't respond, ever, with 400+ error codes > > You can respond with 4xx and 5xx codes, sure. This should never be an > issue. You'll only ever respond with a 4xx code in the case of a > client-side error, which should never happen, and you'll only ever respond > with 5xx codes in the case of a server-side error, in which case you might > as well be offline. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Fri Feb 10 21:30:47 2012 From: ian at hixie.ch (Ian Hickson) Date: Sat, 11 Feb 2012 05:30:47 +0000 (UTC) Subject: [html5] app manifest & 404/500 pages In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Josh Sharpe wrote: > > None of this solves the problem at hand though.... > > To restate it: > > My manifest has an OFFLINE section of "/ /offline" > > Once that manifest has been loaded, and cached successfully and the user is > still online, my 404 and 500 pages are broken. I don't see the problem. You should presumably never be sending back a 404, since the user will never request a page you don't have unless you have a broken link or something, and you should never ever send back a 500 unless your server is in fact offline (or broken, which amounts to the same thing). Generally speaking, by the way, having your entire site in the FALLBACK section under one entry is probably not what you want. The FALLBACK section is supposed to just be for files that you would want to have cached but that you don't cache because there's too many of them (e.g. photos on Flickr). The fallback page is supposed to be able to generate the page from the local database, if the data is available. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From josh.m.sharpe at gmail.com Sat Feb 11 12:20:18 2012 From: josh.m.sharpe at gmail.com (Josh Sharpe) Date: Sat, 11 Feb 2012 14:20:18 -0600 Subject: [html5] app manifest & 404/500 pages In-Reply-To: References: Message-ID: > I don't see the problem. You should presumably never be sending back a > 404, since the user will never request a page you don't have unless you > have a broken link or something, and you should never ever send back a 500 > unless your server is in fact offline (or broken, which amounts to the > same thing). > Yes, of course the app shouldn't be making a habit out of returning 404 and 500 pages. That doesn't mean it won't ever happen and shouldn't be accommodated for. Pages get removed, google has stale links, other sites have link backs, users type the wrong thing into the URL bar.... > Generally speaking, by the way, having your entire site in the FALLBACK > section under one entry is probably not what you want. The FALLBACK > section is supposed to just be for files that you would want to have > cached but that you don't cache because there's too many of them (e.g. > photos on Flickr). The fallback page is supposed to be able to generate > the page from the local database, if the data is available. > I'm using a derivative of an example given by current living standard. See section 6.3.3.1 (last example) http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#some-sample-manifests ... as far as I can tell that example is going to break all existing error pages and is probably not something that should be in the standard unless there's a workaround for the issue. > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cabdulqadirsalad at gmail.com Sun Feb 12 12:03:57 2012 From: cabdulqadirsalad at gmail.com (Cabdulqadir salad) Date: Sun, 12 Feb 2012 23:03:57 +0300 Subject: [html5] I want to get update androud market Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From org.whatwg at sagar.org Mon Feb 13 17:35:43 2012 From: org.whatwg at sagar.org (Rik Sagar) Date: Mon, 13 Feb 2012 17:35:43 -0800 Subject: [html5] app manifest & 404/500 pages In-Reply-To: References: Message-ID: Hi Ian, I'm don't see the "rarely offline" notion as a good argument for the behavior described. IMHO if a server is responding with an error it's not appropriate for the client to interpret that as "I'm offline". I also don't think the captive portal argument is valid. If I hit a captive portal I don't get an error, I get a splash page with a login button. I'm not sure if I get a 3xx page first, I imagine I should. And in that case, I really need to see that page (rather than cached copy of the real site). Otherwise how will I accept the portals TOS and get connected to the Internet? Rik. Rik Sagar, San Jose, CA 95124 Visit : http://sagar.org/ +1-408-799-4589 (mobile) 0113-815-1583 (from UK) On Sat, Feb 11, 2012 at 12:20 PM, Josh Sharpe wrote: > > >> I don't see the problem. You should presumably never be sending back a >> 404, since the user will never request a page you don't have unless you >> have a broken link or something, and you should never ever send back a 500 >> unless your server is in fact offline (or broken, which amounts to the >> same thing). >> > > Yes, of course the app shouldn't be making a habit out of returning 404 > and 500 pages. That doesn't mean it won't ever happen and shouldn't > be accommodated for. Pages get removed, google has stale links, other > sites have link backs, users type the wrong thing into the URL bar.... > > >> Generally speaking, by the way, having your entire site in the FALLBACK >> section under one entry is probably not what you want. The FALLBACK >> section is supposed to just be for files that you would want to have >> cached but that you don't cache because there's too many of them (e.g. >> photos on Flickr). The fallback page is supposed to be able to generate >> the page from the local database, if the data is available. >> > > I'm using a derivative of an example given by current living standard. > > See section 6.3.3.1 (last example) > > http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#some-sample-manifests > > ... as far as I can tell that example is going to break all existing error > pages and is probably not something that should be in the standard unless > there's a workaround for the issue. > > > >> -- >> Ian Hickson U+1047E )\._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >> > > > _______________________________________________ > Help mailing list > Help at lists.whatwg.org > http://lists.whatwg.org/listinfo.cgi/help-whatwg.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.m.sharpe at gmail.com Thu Feb 16 09:57:17 2012 From: josh.m.sharpe at gmail.com (Josh Sharpe) Date: Thu, 16 Feb 2012 12:57:17 -0500 Subject: [html5] app manifest & 404/500 pages In-Reply-To: References: Message-ID: Any thoughts on a work around for this? Right now I think I'm stuck with making my error pages return status codes of 200. On Mon, Feb 13, 2012 at 8:35 PM, Rik Sagar wrote: > > Hi Ian, > > I'm don't see the "rarely offline" notion as a good argument for the > behavior described. IMHO if a server is responding with an error it's not > appropriate for the client to interpret that as "I'm offline". > > I also don't think the captive portal argument is valid. If I hit a > captive portal I don't get an error, I get a splash page with a login > button. I'm not sure if I get a 3xx page first, I imagine I should. And > in that case, I really need to see that page (rather than cached copy of > the real site). Otherwise how will I accept the portals TOS and get > connected to the Internet? > > Rik. > > > > > Rik Sagar, San Jose, CA 95124 > Visit : http://sagar.org/ > > +1-408-799-4589 (mobile) > 0113-815-1583 (from UK) > > > On Sat, Feb 11, 2012 at 12:20 PM, Josh Sharpe wrote: > >> >> >>> I don't see the problem. You should presumably never be sending back a >>> 404, since the user will never request a page you don't have unless you >>> have a broken link or something, and you should never ever send back a >>> 500 >>> unless your server is in fact offline (or broken, which amounts to the >>> same thing). >>> >> >> Yes, of course the app shouldn't be making a habit out of returning 404 >> and 500 pages. That doesn't mean it won't ever happen and shouldn't >> be accommodated for. Pages get removed, google has stale links, other >> sites have link backs, users type the wrong thing into the URL bar.... >> >> >>> Generally speaking, by the way, having your entire site in the FALLBACK >>> section under one entry is probably not what you want. The FALLBACK >>> section is supposed to just be for files that you would want to have >>> cached but that you don't cache because there's too many of them (e.g. >>> photos on Flickr). The fallback page is supposed to be able to generate >>> the page from the local database, if the data is available. >>> >> >> I'm using a derivative of an example given by current living standard. >> >> See section 6.3.3.1 (last example) >> >> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#some-sample-manifests >> >> ... as far as I can tell that example is going to break all existing >> error pages and is probably not something that should be in the standard >> unless there's a workaround for the issue. >> >> >> >>> -- >>> Ian Hickson U+1047E )\._.,--....,'``. fL >>> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >>> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >>> >> >> >> _______________________________________________ >> Help mailing list >> Help at lists.whatwg.org >> http://lists.whatwg.org/listinfo.cgi/help-whatwg.org >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertc at boogdesign.com Mon Feb 20 03:05:34 2012 From: robertc at boogdesign.com (Rob Crowther) Date: Mon, 20 Feb 2012 11:05:34 +0000 Subject: [html5] app manifest & 404/500 pages In-Reply-To: References: Message-ID: <4F4228FE.9070504@boogdesign.com> On 14/02/2012 01:35, Rik Sagar wrote: > I'm don't see the "rarely offline" notion as a good argument for the > behavior described. IMHO if a server is responding with an error it's > not appropriate for the client to interpret that as "I'm offline". > If the server is responding with an error for static content what are you expecting the client to be able to do about it? Rob From jay at peepo.com Fri Feb 24 08:25:40 2012 From: jay at peepo.com (jonathan chetwynd) Date: Fri, 24 Feb 2012 16:25:40 +0000 Subject: [html5] Magic lantern show: timing events to streaming audio? Message-ID: is there a simple easy to use method and specification for connecting and timing events to streaming audio? The Magic Lantern show** has an ancient and venerable history, one that web standards have been slow to emulate. Dave Raggett's Slidy provides the slideshow in HTML5, but not the audio... kind regards Jonathan Chetwynd ~:" jay at peepo.com http://www.peepo.com +44 (0) 20 7978 1764 **I once had a portable 35mm half frame projector with 2 track audio casette. One track had an audible beep that moved the projector on one slide. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at peepo.com Fri Feb 24 09:27:37 2012 From: jay at peepo.com (jonathan chetwynd) Date: Fri, 24 Feb 2012 17:27:37 +0000 Subject: [html5] Magic lantern show: timing events to streaming audio? Message-ID: <2277361F-5AC6-4A18-9823-4406BDBD00E0@peepo.com> is there a simple easy to use method and specification for connecting and timing events to streaming audio? The Magic Lantern show** has an ancient and venerable history, one that web standards have been slow to emulate. Dave Raggett's Slidy provides the slideshow in HTML5, but not the audio... kind regards Jonathan Chetwynd ~:" jay at peepo.com http://www.peepo.com +44 (0) 20 7978 1764 **I once had a portable 35mm half frame projector with 2 track audio casette. One track had an audible beep that moved the projector on one slide. -------------- next part -------------- An HTML attachment was scrubbed... URL: From newstanoor at gmail.com Mon Feb 27 03:37:27 2012 From: newstanoor at gmail.com (TD) Date: Mon, 27 Feb 2012 12:37:27 +0100 Subject: [html5] Basic question on some html5 tags Message-ID: Hi every body, although I'm an experienced web developer, I'm new at html5 and I'm trying to improve my skills in it. I have discovered the following tags: header and footer. While I understand that these tags help to structure the content of our pages - which is always a good thing -, I don't really understand their usefulness. Is it for accessiblity reasons: is it used by some special software? Is it for seo reasons: is our content better referenced if we use it? Are there some other reasons that make it really useful and enough important to give up old way of structuring code:(