| 03:35 | <zewt> | gah |
| 03:35 | <zewt> | does amazon use sync xhr? heh |
| 03:36 | <zewt> | tethering on my phone and having chrome freeze randomly searching on amazon |
| 05:49 | <smartie2> | >> "check ecma" |
| 11:51 | <jgraham> | Taggnostr: I can't imagine that making a Python 3 port of tml5lib would take more than a day or two. Maybe "make a Python 3 port and an API that acts a a drop-in replacement for HTMLParser" would be more reasonable. Well I imagine that adding that would also be pretty trivial, but enabling the parser to work with a streaming API for minimal memory consumption would be a little harder. Still seems like it would be ~10 days work including learning all |
| 11:52 | <gsnedders> | (note that possibly for streaming you may have to buffer the whole document) |
| 11:52 | <gsnedders> | (as nodes can be moved and inserted earlier in the tree) |
| 11:57 | <jgraham> | Well looking at it, it seems that HTMLParser doesn't tell you where nodes were inserted |
| 12:00 | <jgraham> | So the only thing that you need the treebuilder for is to handle things like <script><div></script> and <sircle/><svg><circle/> |
| 12:00 | <jgraham> | s/sircle/circle/ |
| 12:02 | <jgraham> | It is prety tempting to just hook into the tokenizer, ignore the treebuilder and say that it is an application-level concern to realise that if you just saw a <script>, a <div> tag is actually text |
| 12:05 | <gsnedders> | jgraham: But the treebuilder changes tokenizer state. |
| 12:06 | <jgraham> | gsnedders: I know |
| 12:06 | gsnedders | blames foreign content :( |
| 12:06 | <jgraham> | But the existing implementation seems to be horribly broken |
| 12:06 | <jgraham> | <script><div> -> 1 start tag |
| 12:06 | <jgraham> | <xmp><div> -> 2 start tags |
| 12:08 | <jgraham> | It seems quite possible to just find all the special cases that the existing implementation knows about, hardcode them in to the HTMLParser api, use that to change the tokenizer state, and accept that there are probably some corner cases where everything will break |
| 12:10 | <jgraham> | So far the list of special cases seems to be "script", "style" |
| 12:11 | <jgraham> | In fact that is exactly the list of special cases |
| 12:12 | <StoneCypher> | those two tags can't contain markup |
| 12:12 | <StoneCypher> | so that's not actually broken |
| 12:12 | <StoneCypher> | that's correct |
| 12:12 | <StoneCypher> | there are others too |
| 12:12 | <StoneCypher> | <object>, <embed> |
| 12:12 | <StoneCypher> | et cetera |
| 12:12 | <StoneCypher> | anything that contains <!cdata[[ |
| 12:12 | <StoneCypher> | or whatever it is |
| 12:14 | <jgraham> | StoneCypher: Right, script and style switching the tokenizer state is right. What's wrong is e.g. xmp *not* doing it |
| 12:14 | <bga> | oh somebody uses xml islands |
| 12:15 | <StoneCypher> | bga: not since like 2004 |
| 12:15 | <StoneCypher> | bga: i mean, back in the dark ages, sure |
| 12:15 | <StoneCypher> | jgraham: ah. (i don't actually know what xmp does_) |
| 12:16 | <StoneCypher> | jgraham: sorry if i misunderstood :) |
| 12:16 | <bga> | StoneCypher but https://developer.mozilla.org/en/Using_XML_Data_Islands_in_Mozilla |
| 12:23 | <StoneCypher> | wow. |
| 12:23 | <StoneCypher> | so xml islands are back-ish, as a legit standard now? |
| 12:24 | <StoneCypher> | eenteresting. |
| 12:24 | <StoneCypher> | i bet the microformats people adore this. |
| 12:59 | <jgraham> | gsnedders, Taggnostr: Something like https://gist.github.com/1808356 |
| 12:59 | <jgraham> | Not production quality ofc, but more or less does the same as HTMLParser, but using the html5lib tokenizer |
| 13:07 | <jgraham> | (the hard part would be making the incremental feeding work) |
| 22:03 | <yuhong> | BTW, it is interesting that Ian Hickson and Chris Wilson works at the same company now. |