| 00:36 | <gsnedders> | Lachy: Happy b'day! |
| 01:10 | <wahnfrieden> | hi |
| 01:10 | <wahnfrieden> | is there any demo site to see how html5lib sanitizes HTML? |
| 01:13 | <karlcow> | wahnfrieden: As far as I know last time I looked at html5lib, there were doing parsing only and not serialization/sanitization |
| 01:21 | <wahnfrieden> | they are doing a whitelist sanitization tokenizer |
| 02:17 | <Hixie> | dimich: in theory the spec already says what encoding to use for the query part |
| 02:17 | <Hixie> | dimich: see the url part of html5 (somewhere in section 2 iirc) |
| 02:18 | dimich | looking... |
| 02:20 | <dimich> | so it says the encoding should match the encoding of the document or script (in case of the Worker) |
| 02:21 | Hixie | looks |
| 02:21 | <dimich> | If I read it correctly :-) 2.5.1 and further |
| 02:22 | <Hixie> | it says to use the "script's character encoding" |
| 02:22 | <Hixie> | which is set by the "Create a script" algorithm |
| 02:22 | <Hixie> | which in the case of a worker is invoked in step 3 of section 2.5's algorithm |
| 02:22 | <Hixie> | and is always set to utf-8 |
| 02:23 | <Hixie> | so in the worker case i guess the answer is always utf-8 |
| 02:27 | <dimich> | Hixie: sorry, I'm not sure I follow. Lets say we load a Worker and it has a http header that sets charset. |
| 02:27 | <dimich> | So we decode the script using that encoding. Doesn't it become a "script' |
| 02:27 | <dimich> | s encoding"? |
| 02:28 | <dimich> | so when this script tries to open XHR (for example) shouldn't we encode that url with that encoding? |
| 02:29 | <dimich> | I guess I'm looking for "create a script" algorithm... |
| 02:29 | <dimich> | ah, ok, I see it now. |
| 02:30 | <dimich> | in a worker spec, "Set the script's character encoding to UTF-8. (This is just used for encoding non-ASCII characters in the query component of URLs.)" |
| 02:30 | <dimich> | So basically all URLs inside scripts should be encoded UTF8 |
| 02:30 | <dimich> | Thanks! |
| 03:44 | <olliej> | Hixie: ping? |
| 04:12 | <Hixie> | olliej: here vaguely |
| 04:12 | <Hixie> | hm, dimich left while i was at dinner, d'oh |
| 04:15 | <olliej> | Hixie: sorry, back |
| 04:16 | <olliej> | Hixie: looking at importScripts ( http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries ) |
| 04:17 | <olliej> | Hixie: it implies that importScripts(sources) does for (source in sources) { script = loadSource(source); if (network error) throw; execute(script) } |
| 04:18 | <Hixie> | olliej: right |
| 04:18 | <olliej> | Hixie: but the behaviour exhibited by firefox is for (source in sources) { scripts.append(loadSource(source)); if (network error) throw; } for (script in scripts) execute(script) |
| 04:18 | <olliej> | Hixie: so if any script fails to load, none are run |
| 04:18 | <Hixie> | olliej: file a bug |
| 04:18 | <Hixie> | either on them or on me :-) |
| 04:18 | <olliej> | Hixie: on moz or the spec |
| 04:18 | <olliej> | hehe |
| 04:18 | <Hixie> | i don't really care either way |
| 04:18 | <olliej> | which mailing list are workers discussed on? |
| 04:18 | <Hixie> | whatwg or public-webapps |
| 04:35 | <olliej> | Hixie: emailed |
| 04:35 | <olliej> | Hixie: honestly not sure what the best approach is, so i've just asked for other people to comment |
| 04:46 | <Hixie> | k |
| 04:47 | <wahnfrieden> | html5 will never happen. |
| 04:47 | <wahnfrieden> | IE6 will always be the lowest common denominator |
| 04:48 | <olliej> | wahnfrieden: i saw one stat that said firefox has more marketshare than ie6 now |
| 04:48 | <olliej> | wahnfrieden: and ie is the only browser with shrinking marketshare |
| 04:49 | <Hixie> | html4 will never happen either |
| 04:49 | <Hixie> | IE2 will always be the lowest common denominator |
| 04:50 | <Hixie> | (also, lots of part of html5 can have shims written for them that work around their limitations in ie6) |
| 04:50 | <Hixie> | (that was part of the plan from the very start) |
| 04:51 | <wahnfrieden> | heh |
| 04:51 | <wahnfrieden> | i like operating only in a scholars world |
| 04:51 | <wahnfrieden> | i can utterly ignore IE |
| 04:52 | <olliej> | i also ignore ie entirely |
| 05:38 | <Hixie> | dimich: i should probably make it clearer that "the script's encoding" doesn't necessarily mean the encoding of the actual script file |
| 05:38 | <Hixie> | dimich: i'll file a bug |
| 05:39 | <dimich> | Hixie: Yeah, that could be a good idea. I was thinking all along that the encoding used to decode the actual script is the same one but apparently not. |
| 06:18 | <Lachy> | I revised the description of the DOCTYPE http://dev.w3.org/html5/html-author/#doctype-declaration |
| 06:19 | <Lachy> | I've attempted to use a new interactive technique to illustrate the case insensitivity |
| 06:19 | <Lachy> | if you hover over the highlighted parts of the doctype where it discusses case sensitivity, it shows the alternative cases |
| 07:19 | <olliej> | yo dbaron |
| 07:19 | <dbaron> | hi |
| 16:04 | gsnedders | wonders how a U+0010 got into his CV |
| 16:10 | hsivonen | is angry at Apple for glossy screens |
| 18:00 | <karlcow> | https://www.ohloh.net/p/html5lib |
| 18:01 | <karlcow> | $ 605,355 |
| 18:01 | <sayrer> | hmm |
| 18:01 | <sayrer> | http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=978 |
| 18:03 | <Philip`> | "reducing its complexity" - that sounds incompatible with the idea of "don't break the web", because people rely on all the complexity |
| 18:04 | <annevk> | tags "javascript" |
| 18:04 | <sayrer> | I think it is difficult to dismiss it out of hand without seeing a proposal |
| 18:04 | <annevk> | I think that's exactly why it's easy to dismiss it out of hand |
| 18:05 | <Philip`> | It's easy to dismiss it until such a time as a more concrete proposal exists, and then it would be bad to dismiss it out of hand |
| 18:05 | <sayrer> | should be interesting |
| 18:05 | <annevk> | he has done a proposal before actually |
| 18:05 | <Philip`> | Based on the lack of any other information, I'd assume it's based on the ideas in http://www.crockford.com/html/ |
| 18:06 | <annevk> | that's the one |
| 18:06 | <sayrer> | he was comparing it to ES3.1 |
| 18:06 | <sayrer> | which is mostly compatible |
| 18:06 | <sayrer> | unlike that html proposal of his |
| 18:07 | <sayrer> | although some have called ES3.1 a "nothing burger" |
| 18:07 | <sayrer> | :) |
| 18:07 | <gsnedders> | Compatibility? Peh! We should just use an XML parser for text/html! |
| 18:07 | <Philip`> | Does ES3.1 attempt "to simplify, streamline, and generalize, increasing the system's expressive power while reducing its complexity"? |
| 18:07 | <Philip`> | (I have no idea what ES3.1 does, so it's not a rhetorical question :-) ) |
| 18:09 | <Philip`> | I'd assume a nothing burger is a bun, and buns are often nice by themselves |
| 18:09 | <sayrer> | I don't think it reduced complexity much |
| 18:09 | <Dashiva> | I haven't been following the list lately, but last I can recall es3.1 was "the parts of es4 that we like" |
| 18:09 | <sayrer> | but it did add some good features |
| 18:10 | <Philip`> | Dashiva: Is that a different "we" to the people who presumably liked things enough to put them in ES4? |
| 18:10 | <sayrer> | the ideas were basically the same |
| 18:10 | <Dashiva> | Yeah. The main point was supposed to be that it both adds and changes, it's not a strict fix-only rev. |
| 18:10 | <sayrer> | yeah |
| 18:10 | <sayrer> | also it breaks |
| 18:11 | <sayrer> | for instance it adds window.JSON |
| 18:11 | <annevk> | and still doesn't define e.g. Date parsing :/ |
| 18:11 | <gsnedders> | Peh! Why do you want to parse dates? |
| 18:11 | <sayrer> | it added ISO8061 style dates |
| 18:11 | <Dashiva> | It's also a bit hard to apply es semantics to html development. In the es case, they rely on e.g. computer science research on static analysis of certain structures |
| 18:12 | <sayrer> | not really |
| 18:12 | <Dashiva> | In HTML, research usually means going it alone |
| 18:12 | <Dashiva> | And isn't that what we want to avoid in the first place? |
| 18:13 | <annevk> | anyway, i don't really follow his analogy |
| 18:13 | <annevk> | compared to es4 HTML5 is actually being implemented and parts that aren't will be removed |
| 18:16 | <sayrer> | well, if Microsoft shows up next to him, things get interesting |
| 18:16 | <Philip`> | Maybe part of the difference is that JS already lets you write programs that do anything you want, so new versions can just slowly make it nicer to do certain things, whereas HTML is fundamentally incapable of almost everything and so the most useful thing you can do is add features, and if you don't add features then people won't be happy |
| 18:17 | <sayrer> | that's not a very good description of ES3.1, actually |
| 18:17 | <sayrer> | it adds a bunch of introspection capabilities that were previously only available to the VMs themselves |
| 18:19 | <annevk> | it'll only ever get interesting if it gets further than rethoric |
| 18:21 | <Dashiva> | I wonder how close his 4.2 vision is to sayrer's thing. What's it called again? |
| 18:21 | <Philip`> | As far as I'm aware (which isn't far) you could still kind of hack things together using explicit functions to make scripts with similar functionality in pre-ES3.1 - it's different to e.g. <canvas> or offline web applications which let you do things that are fundamentally impossible with HTML4 |
| 18:21 | <sayrer> | Philip`, one example would be that you define properties on Objects that don't appear in for...in loops |
| 18:22 | <sayrer> | you can define |
| 18:22 | <Philip`> | You can hack things together with hasOwnProperty to make scripts that work like that |
| 18:22 | <Philip`> | It's not very elegant but people seem to put up with it |
| 18:23 | <sayrer> | I don't think you can emulate that |
| 18:23 | <Dashiva> | And you could do canvas with positioned divs, one per pixel... |
| 18:23 | <sayrer> | especially if you want to write library code, e.g. adding stuff to an array |
| 18:23 | <sayrer> | and not break your users' for...in loops |
| 18:25 | <Philip`> | Dashiva: Well, you could if you're writing a 16x16 version of Wolfenstein 3D, but anything more practical is impossible |
| 18:25 | <Philip`> | so there's some implicit requirement on practicality in my use of "fundamentally impossible" |
| 18:25 | <Philip`> | which probably invalidates my argument, but oh well |
| 18:26 | <Dashiva> | Part of it. Some of the new stuff is 100% sugar, of course. |
| 18:27 | <Philip`> | sayrer: Hmm, the libraries could just provide standalone functions instead of trying to add themselves to Object and then I guess it'd be emulating the functionality (though not the syntax) |
| 18:29 | <sayrer> | it's interesting to me that lots of people say HTML5 should be smaller, but then go into toxic shock when someone proposing making something smaller |
| 18:30 | <sayrer> | I wonder if crockford's proposal will be smaller than mine |
| 18:30 | Philip` | doesn't care how big HTML5 is since he is happy to just ignore most of it |
| 18:31 | <sayrer> | I got to the same place, actually :) |
| 18:32 | <Philip`> | I suppose I'm indirectly affected by it spreading the resources of browser developers more widely, but that's a long-term issue and I don't care about the long-term because it's less fun than looking at what works today |
| 18:33 | <Dashiva> | <sayrer> it's interesting to me that lots of people say HTML5 should be smaller, but then go into toxic shock when someone proposing making something smaller |
| 18:33 | <Dashiva> | I don't understand the last part |
| 18:33 | gsnedders | passes Dashiva a copy of English5 |
| 18:33 | <Philip`> | s/proposing/proposes/ ? |
| 18:33 | <sayrer> | yeah, bit of a typo there, sorry |
| 18:34 | <Dashiva> | Aha. I was wondering if the last part of the sentence was missing. |
| 18:34 | <sayrer> | implementation defined |
| 19:11 | <ehird> | http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=978 <— *yawn* |
| 19:11 | <jcranmer> | ehird: you mean |
| 19:11 | <jcranmer> | 13:06 < sayrer> http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=978 |
| 19:11 | <ehird> | i am not yet telepathic into the past :-) |
| 19:15 | <Philip`> | ehird: I find http://krijnhoetmer.nl/irc-logs/whatwg/ less stressful than telepathy |
| 19:16 | <ehird> | Philip`: i can never load logs from there, I keep getting 499 telepathy not possible :( |
| 19:16 | <Philip`> | Then again, trying to read all the IRC logs for this channel is quite likely to drive you crazy |
| 20:55 | <gsnedders> | This whole writing a CV thing sucks. |
| 20:55 | <eighty4> | :) |
| 20:55 | <eighty4> | I know how it feels |
| 21:07 | <gsnedders> | Hmmm… |
| 21:08 | <gsnedders> | What can I say about participation in WHATWG? |
| 21:08 | <eighty4> | that you do? |
| 21:08 | gsnedders | slaps eighty4 around a lill' |
| 21:09 | <eighty4> | I'm still not sure what whatwg is |
| 21:09 | gsnedders | points at the topic |
| 21:09 | gsnedders | points at the FAQ |
| 21:09 | gsnedders | still wants to rename that section to "What's WHAT?" |
| 21:11 | <eighty4> | oh. That would involve reading |
| 21:11 | <eighty4> | I'll do it when I need to know what whatwg is :) |
| 21:18 | gsnedders | pokes Philip` |
| 21:19 | <Philip`> | Ouch |
| 21:19 | <gsnedders> | Philip`: Is "automatable" in the OED? |
| 21:20 | <gsnedders> | Sorry, you're the first person I can think of with access to it :P |
| 21:23 | <Philip`> | It's not explicitly listed as far as I can see, but I didn't think the OED ever listed that kind of word form |
| 21:24 | <gsnedders> | Philip`: How about automate? |
| 21:25 | <Philip`> | Automate is in there |
| 21:25 | <Philip`> | (twice) |
| 21:25 | <gsnedders> | Philip`: Of what etymology? Latin? |
| 21:26 | <gsnedders> | Actually, French I'll guess? |
| 21:26 | gsnedders | stops questioning Philip` |
| 21:28 | <Philip`> | [Back-formation f. next or f. AUTOMATION; cf. AUTOMATE n. and a.] |
| 21:28 | <gsnedders> | k, thx |
| 21:29 | <gsnedders> | Thus it should be fine to use -able |
| 21:30 | <Philip`> | It'd be fine to use it in any case - the language police aren't going to arrest you for making up a new word |
| 21:30 | gsnedders | is listening to And The Mouse Police Never Sleeps by Jethro Tull from Heavy Horses |
| 21:31 | <olliej> | sicking: ping? |
| 21:32 | olliej | wishes he knew what importScripts is meant to be doing |
| 21:33 | <olliej> | yo sayrer |
| 21:33 | <sayrer> | olliej yo |
| 21:33 | <olliej> | sayrer: i'm beginning to hate importScripts |
| 21:34 | <sayrer> | what has it done? |
| 21:34 | <olliej> | sayrer: do you follow the whatwg mailing list? |
| 21:34 | <sayrer> | nope |
| 21:35 | <sayrer> | but I'll look at the importScripts traffic |
| 21:35 | <olliej> | sayrer: basically the spec says importScripts does one thing, mozilla does another |
| 21:35 | <sayrer> | we have some time to fix it. did we do it on purpose? |
| 21:35 | <olliej> | sayrer: and both models make sense from certain points of view |
| 21:35 | <olliej> | sayrer: sicking filed a bug |
| 21:35 | <olliej> | and ben turner said it was deliberate |
| 21:36 | <olliej> | sayrer: so i have no idea wth i should be doing in webkit :D |
| 21:36 | <sayrer> | hmm, puzzling |
| 21:36 | <olliej> | sayrer: makes writing the test case even more fun |
| 21:37 | <sayrer> | could you use ours? |
| 21:37 | <olliej> | i'm 90% i can match your model exactly |
| 21:37 | <sayrer> | http://mxr.mozilla.org/mozilla-central/search?string=importScripts |
| 21:37 | <olliej> | sayrer: oh |
| 21:37 | <olliej> | your test cases? |
| 21:37 | <sayrer> | yeah, I thought that's what you meant |
| 21:38 | <sayrer> | http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/test/Makefile.in#50 |
| 21:39 | <sayrer> | did you see that browsertests.org page? |
| 21:39 | <sayrer> | we fail each other's tests, pretty much |
| 21:39 | <sayrer> | depressing! |
| 21:39 | <olliej> | sayrer: sadness |
| 21:40 | <sayrer> | though maybe a lot of them are superficial bugs |
| 21:40 | <sayrer> | like we had some failing because our emulation of your harness was printing differently |
| 21:40 | <olliej> | sayrer: i would hope so, but there are icky things in drt |
| 21:41 | <olliej> | (for most of the pure layout tests anyway) |
| 21:41 | <olliej> | sayrer: what's worrying is that there appear to be some tests that everyone fails O_o |
| 21:42 | <sayrer> | that made me laugh some |
| 21:42 | <sayrer> | we have some tests we only pass on mac, though |
| 21:43 | <olliej> | ditto |
| 21:44 | <sayrer> | bz's post reminded me we should stop trying so hard on function definitions at parse time |
| 21:44 | <sayrer> | hrmph |
| 21:44 | <sayrer> | so much to do |
| 21:45 | <sayrer> | can't say I have an opinion on this importScripts thing |
| 21:45 | <olliej> | :-/ |
| 21:45 | <olliej> | oh well |
| 21:45 | <olliej> | i'm just implementing the current moz model |
| 21:45 | <sayrer> | would be interested to hear what the chrome guys want |
| 21:45 | <olliej> | i currently have #if 1 ... #else ... #endif |
| 21:45 | <olliej> | sayrer: why? |
| 21:45 | <sayrer> | just more opinions |
| 21:45 | <olliej> | sayrer: they will just get what i implement |
| 21:45 | <olliej> | ehhehe |
| 21:46 | <sayrer> | haha |
| 21:46 | <olliej> | v8 cannot run more than once per process -- they actually have to run workers in separate processes |
| 21:46 | <olliej> | which seems excessively heavy weight, but there you go |
| 21:47 | <olliej> | mean while jsc has to continue to support some of the most horrific threading semantics i have ever encountered |
| 21:47 | olliej | beats head on desk |
| 21:47 | <sayrer> | we've managed to get the worst of both worlds |
| 21:47 | <sayrer> | join the club |
| 21:48 | <olliej> | A single JSC context is not thread safe -- eg. you can't have too threads using the same js context concurrently |
| 21:48 | <olliej> | but you can have JS execution on a single context switch from thread to thread |
| 21:49 | <gsnedders> | olliej: So you basically have a lock on execution? |
| 21:49 | <olliej> | or thread A can execute js which can call a native function which then calls back into JS again |
| 21:49 | <olliej> | but calls back into JS on a different thread |
| 21:49 | <olliej> | gsnedders: that would be nice, but the above semantic results in that being pain |
| 21:51 | <olliej> | so much pain |
| 21:51 | Philip` | has a multithreaded application that embeds SpiderMonkey, and deals with threading issues mostly by sticking his head in the sand and hoping it's not going to break, which seems to be a fine strategy so far |
| 21:51 | <olliej> | in the pre-workers world i believe we did just do a global lock on entry to jsc |
| 21:51 | <gsnedders> | "You should worry 'bout the day/That the pain it goes away" |
| 21:51 | <sayrer> | spidermonkey is usually decent by the release |
| 21:51 | <olliej> | Philip`: mostly that works for jsc as well, it's just when people do insane things |
| 21:52 | <sayrer> | there are server embedders that stress it pretty hard |
| 21:52 | <sayrer> | Firefox doesn't really |
| 21:52 | <gsnedders> | olliej: But where's the fun in life without doing insane things? :D |
| 21:52 | <olliej> | sayrer: people keep telling me the TM has stability issues, but i really haven't seen any problems with it -- is it a platform specific issues or something? |
| 21:52 | <olliej> | gsnedders: oh we have plenty of insane clients |
| 21:52 | <sayrer> | we have more blockers than I would like |
| 21:53 | <Philip`> | I think I currently have two totally separate JSRuntimes that each run in separate threads and never communicate, so presumably it's avoiding pretty much all of the complicated synchronisation issues |
| 21:53 | <olliej> | sayrer: ick |
| 21:53 | <sayrer> | I never hit them in my daily browsing, though |
| 21:53 | <olliej> | sayrer: ah right |
| 21:53 | <sayrer> | we had quite a subtle, awful bug fixed two weeks ago |
| 21:53 | <olliej> | sayrer: so it's icky edge cases basically? |
| 21:53 | <sayrer> | yeah |
| 21:54 | <sayrer> | the tracing approach is somewhat prone to that, since it violates DRY to an extent |
| 21:54 | <olliej> | DRY? |
| 21:55 | <sayrer> | Don't Repeat Yourself |
| 21:55 | <olliej> | ah |
| 21:55 | <olliej> | :D |
| 21:55 | <olliej> | sayrer: but i bet you don't have some of the bugs we get -- we had one client that used a cache of common native object wrappers |
| 21:56 | <sayrer> | we have all sorts of insane stuff like that. in the browser, because we let extension use the JSAPI |
| 21:56 | <olliej> | sayrer: and it would lazily create these wrapper with logic that basically did: ctx=createContext(); object=createObject(ctx); deleteContext(ctx); store(object) |
| 21:56 | <olliej> | sayrer: ah ha |
| 21:57 | <olliej> | sayrer: i was not aware you directly exposed api like that |
| 21:57 | <gsnedders> | Peh! Who needs context!? |
| 21:57 | gsnedders | is useless |
| 22:54 | <olliej> | sayrer: hmmm, jonas said he'd file a bug, but i can't find it in b.m.o -- any idea what he may have filed it as? |
| 22:56 | <sayrer> | olliej, don't see one |
| 22:56 | <olliej> | neither |
| 22:57 | olliej | just implements firefox behaviour for now |