| 01:04 | <dekiss> | zewt :)) |
| 01:05 | <dekiss> | <zewt> webgl is definitely not the "future of the web", it's a useful feature but just that |
| 01:05 | <dekiss> | webgl is part of the future of the web yes |
| 01:05 | <dekiss> | big part |
| 01:06 | <dekiss> | future websites will be in 3d |
| 01:06 | <dekiss> | it is very funny how when finally whole world have optic internet network connection webgl will demand graphic cards not bandwidth :DDDD |
| 01:07 | <dekiss> | the only reason today website are not in 3d is lack of browser support for webgl for mobiles ie opera etc. and becasue he computers today are not coming with graphic cards when this will change in the next 5-6 years webgl will dominate and most of the website will be in 3d |
| 01:08 | <dekiss> | websites* |
| 01:10 | <zewt> | (the fact that 3d has nothing to do with most websites might be a bit of a factor as well) |
| 01:12 | <dekiss> | hahah |
| 01:12 | <dekiss> | zewt you have a point |
| 01:13 | <dekiss> | ok most of the websites will want at least of the shiny webgl cookie on their website |
| 01:13 | <dekiss> | ok most of the websites will want at least small piece* of the shiny webgl cookie on their website |
| 01:13 | <dekiss> | zewt ok we disagree on this topic lets move on :) |
| 01:25 | <gavinc> | based on recent job fairs and interviews it is the future of every single Look at me! Look at me! demo project |
| 01:32 | <dekiss> | gavin um which demo? |
| 14:25 | smaug____ | wonders if http://html5.org/tools/web-apps-tracker?from=8353&to=8354 is actually web compatible |
| 14:25 | <smaug____> | er, not that one |
| 14:25 | <smaug____> | but the one which added resize to <video> |
| 14:27 | <smaug____> | I don't see why that all was changed |
| 14:27 | smaug____ | could be missing some email |
| 16:09 | <zewt> | http://www.elementcase.com/iPhone-5-s/136.htm for as much as they charge for their products, they sure didn't spend much on their <title> |
| 16:09 | <jgraham> | In what sense is gecko the only browser with a bfcache? I thought this was something that everyone had? How does gecko differ from wat presto ha[s|d] and what blink has? |
| 16:09 | <zewt> | webkit doesn't have anything at all like firefox's bfcache, as far as I understand what bfcache is |
| 16:17 | <jgraham> | Oh. But Opera did it first, right? |
| 16:21 | <Ms2ger> | Land on the moon? |
| 16:23 | <jgraham> | Opera landed on the moon so long ago that the O-logo branding they left behind is often mistaken for craters |
| 16:47 | <jwalden> | zewt: bfcache definitely was in webkit before Gecko, we added it (and brendan pushed on us to land it without delaying long enough to have a reasonably clean implementation) because they had it already |
| 16:47 | <jwalden> | bz is still bitter about that |
| 16:47 | <jwalden> | but perhaps it was always going to be fugly, because docshell |
| 16:48 | <zewt> | jwalden: i never see it, then, but maybe i'm thinking of something else |
| 16:48 | <zewt> | firefox keeps the previous page (or pages) in each tab alive, so browser back goes back immediately; chrome always reloads the page |
| 16:48 | <zewt> | or at least visibly rerenders |
| 16:50 | jwalden | consults https://bugzilla.mozilla.org/show_bug.cgi?id=blazinglyfastback |
| 16:51 | <zewt> | maybe chrome turns it off in more cases, which gives me the impression that it doesn't have it? |
| 16:51 | <jwalden> | maybe? |
| 16:52 | <jwalden> | these days I think pages have a lot more onload/ununload/onbeforeunload handlers or whichever, and those handlers disable bfcache |
| 16:55 | <zewt> | err, if it disables it if there's an onload handler then yeah it wouldn't work for most sites |
| 16:55 | <zewt> | firefox doesn't do that |
| 16:55 | <zewt> | (on a quick test) |
| 16:59 | <jgraham> | It should just be unload handlers |
| 17:00 | <smaug____> | jwalden: bfcache was in Gecko before webkit |
| 17:00 | <zewt> | chrome does seem to have bfcache for simple pages and then turn it off if i add an onload |
| 17:01 | <zewt> | (but every site in the world has an onload) |
| 17:01 | <jgraham> | jwalden: That bug doesn't mention webkit (and iirc predates webkit being a serious engine) |
| 17:01 | <jgraham> | It does mention Opera however |
| 17:01 | <jgraham> | I am pretty sure that this really is a case where Opera did it first |
| 17:02 | <zewt> | it does seem like an opera-y thing |
| 17:02 | <jgraham> | But it would be really surprising if WebKit/Blink don't do this given what a noise they make about perf. |
| 17:13 | <jwalden> | hum |
| 17:14 | <jwalden> | I really don't remember it not being a webkit thing at the time, strange |
| 17:30 | <dekiss> | can I put img element in h2? |
| 17:36 | <dekiss> | I guess I can? |
| 17:36 | <dekiss> | at least validator says so |
| 17:37 | <toss2> | interesting |
| 18:04 | <Ms2ger> | Sure, why not? |
| 20:51 | <matjas> | annevk: https://github.com/jwerle/libutf8 — “A whatwg compliant UTF8 encoding and decoding library based on http://encoding.spec.whatwg.org/” |
| 21:00 | <matjas> | so http://encoding.spec.whatwg.org/#utf-8 allows lone surrogates, that’s unexpected |
| 21:12 | <annevk-cloud> | matjas: the encoder you mean? It expects scalar values |
| 21:13 | <annevk-cloud> | Going to be fixed at some point |
| 21:14 | <matjas> | annevk: where does it say that? what happens in case a lone surrogate is part of the input for the encoder |
| 21:14 | <annevk-cloud> | Many choices as to how |
| 21:14 | <matjas> | ah ok, not yet in the spec |
| 21:15 | <annevk-cloud> | Invalid input at the moment, like passing bytes where strings are expected |
| 21:19 | <matjas> | oh, so it does say it’s invalid input atm? where? |
| 21:26 | <matjas> | in that case https://github.com/jwerle/libutf8/blob/5941ddcbfd86b69cc3b8519aba62619b0dcf63b1/test/decode.c#L180-L185 is incorrect |