| 02:50 | <tantek> | from the archives: 5 years ago - "XML for Dummies" - http://flickr.com/photos/tantek/487522534/ |
| 02:53 | <zewt> | who else is xml for? |
| 02:53 | <zewt> | (bam) |
| 07:36 | <annevk> | oh yes |
| 07:36 | <annevk> | yay hober |
| 07:38 | <Ms2ger> | Hrm |
| 07:38 | <Ms2ger> | One advantage to the previous D3E editors was that I didn't have to review so many changes... |
| 07:49 | <annevk> | I wish we'd be working on the UI Events spec already |
| 08:28 | <smaug____> | annevk: how is that link relevant? |
| 08:28 | <smaug____> | I was talking about setAttributeNS |
| 08:30 | <annevk> | sure once you use that all bets are off |
| 08:31 | <annevk> | but for HTML you can just use setAttribute to modify existing namespaced attributes |
| 08:32 | <smaug____> | you can, but you don't have to |
| 08:33 | <smaug____> | which is a problem |
| 08:33 | <smaug____> | so if you use setAttributeNS and filter is for name, attribute handling gets trickier |
| 08:33 | <smaug____> | I think we should focus on non-namespaced attributes, and get them work better |
| 08:34 | <smaug____> | and in that case namespace is null, and localname == name |
| 08:34 | <annevk> | how would they work better? |
| 08:35 | smaug____ | could point annevk to sicking's bugzilla comment :) |
| 08:36 | <annevk> | the scenario where you only care about non-namespaced attributes and yet lots of namespaced attributes are mutated seems pretty alien to me |
| 08:37 | <annevk> | and especially combined with the fact that'd you use the same attribute name in the non-namespace and a namespace |
| 08:38 | <annevk> | xlink:value doesn't exist btw |
| 08:38 | <smaug____> | xlink:href does |
| 08:38 | <Ms2ger> | xlink :( |
| 08:39 | <smaug____> | indeed |
| 08:39 | <annevk> | smaug____: yeah and when used in a non-namespaced context such as HTML it'll be prefixed |
| 08:39 | <annevk> | and then you can filter href, xlink:href and it's all cool |
| 08:40 | <annevk> | using your scheme observing link mutations in a HTML document that has some SVG becomes much harder |
| 08:40 | <smaug____> | annevk: why is it prefixed? |
| 08:40 | <smaug____> | if you use setAttributeNS |
| 08:40 | <annevk> | because it has to be to work in HTML |
| 08:40 | <annevk> | setAttributeNS doesn't change the prefix |
| 08:41 | <smaug____> | if you do htmlelement.setAttributeNS("xlinkns", "href", "http://foobar.com";); |
| 08:42 | <annevk> | why optimize for unlikely scenarios? |
| 08:43 | <smaug____> | er |
| 08:43 | <smaug____> | optimize for the common scenario |
| 08:43 | <smaug____> | where attributes don't have namespace |
| 08:44 | <annevk> | right, and namespaced attributes have a fixed prefix |
| 08:44 | <smaug____> | namespaced attributes don't have a fixed prefix |
| 08:44 | <smaug____> | they have fixed prefix only for parsing purposes |
| 08:44 | <smaug____> | but you can create attributes also other ways |
| 08:45 | <smaug____> | and this API is about mutations, so it is expected that those other ways are used |
| 08:46 | <annevk> | setting an XLink attribute on an HTML element seems highly unlikely |
| 08:46 | <smaug____> | yes |
| 08:46 | <smaug____> | but setting it on an svg element isn't that unlikely |
| 08:46 | <annevk> | right, and there you want to observe it... |
| 08:48 | <smaug____> | so you can't use filters |
| 08:48 | <smaug____> | because namespaced aren't fixed |
| 08:48 | <smaug____> | er, namespaces |
| 08:51 | <smaug____> | er, namespace prefixes :) |
| 09:01 | <annevk> | only if there's no such attribute with the same local name and namespace yet |
| 09:08 | <annevk> | hahaha |
| 09:09 | <annevk> | example.com is our number two most referenced URL |
| 10:12 | <Ms2ger> | zewt++ |
| 12:02 | <Ms2ger> | The "bathtub" approach? |
| 13:23 | <zewt> | postincrement me, will you |
| 13:59 | <Ms2ger> | ++zewt |
| 16:43 | <wycats> | I'm looking at the html5lib tokenizer tests, and they claim that tokenizing just plain "\u000B" is a parse error. The only place I can see reference to 000B is in the entity parsing algorithm. I don't see any reason for plain "\u000B" to enter the entity parsing algorithm. Why is it a parse error? |
| 16:43 | <wycats> | Hixie: ^ |
| 16:48 | <Ms2ger> | I'm not sure if those parts of the tests are reliable |
| 16:50 | <Ms2ger> | Ah, but it is a tree builder err |
| 16:50 | <Ms2ger> | or |
| 16:51 | <Ms2ger> | wycats, ^ |
| 16:51 | <wycats> | Ms2ger: hm |
| 16:51 | <wycats> | where? |
| 16:51 | <wycats> | I couldn't find it |
| 16:51 | <Ms2ger> | http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#the-initial-insertion-mode |
| 16:52 | <Ms2ger> | Any non-space character before the doctype is a parse error |
| 16:52 | <wycats> | hm |
| 16:53 | <wycats> | this complicates the order in which I am writing the parser |
| 16:53 | <wycats> | I have to get the tree builder involved now |
| 16:53 | <wycats> | maybe I should just strip out parse errors from the tests for now? |
| 16:54 | <Ms2ger> | Well, AIUI, you can't write a standalone tokenizer |
| 17:06 | <Hixie> | wycats: i assume you mean a string consisting of just a single U+000B? |
| 17:06 | <Hixie> | wycats: that's an error for multiple reasons, including lack of DOCTYPE |
| 17:13 | <Philip`> | wycats: The html5lib tokenizer tests are meant to run without a tree constructor, including the parse errors |
| 17:14 | <wycats> | Hixie: it shouldn't be a tokenizer error, though |
| 17:14 | <wycats> | but Ms2ger is correct |
| 17:15 | <Hixie> | the spec doesn't distinguish between tokenizer errors and tree errors |
| 17:15 | <wycats> | on the other hand Philip` seems to be saying something different |
| 17:15 | <Hixie> | there's just parse errors |
| 17:15 | <wycats> | Hixie: I understand |
| 17:15 | <wycats> | my question is largely about the html5lib tests, and I would leave it at that except that Philip` seems to have some info about the tokenizer tests being designed to run without a tree constructor |
| 17:16 | <Hixie> | ah, i am not the right person to ask about those tests specifically :-) |
| 17:19 | <Philip`> | wycats: "Preprocessing the input stream" says it's a parse error |
| 17:19 | <wycats> | Hixie: no problem |
| 17:19 | <wycats> | Philip`: lemme look |
| 17:19 | <Philip`> | (along with many other characters) |
| 17:20 | <wycats> | aha! |
| 17:20 | <wycats> | the same characters that are parse errors in a character reference |
| 17:20 | <Philip`> | and html5lib treats the input stream as part of the tokenizer |
| 17:20 | <wycats> | Philip`: cool |
| 17:20 | <Philip`> | hence it being in the tokenizer tests |
| 17:21 | <wycats> | Philip`: if you're interested, what I'm working on is a browser polyfill for the HTML5 parser |
| 17:21 | <wycats> | mostly just for fun |
| 17:21 | <wycats> | there's a node-based one, but it's pretty tied up with node's streaming semantics |
| 17:21 | <wycats> | and I'm trying to stick closer to the spec for now, just for educational purposes |
| 17:25 | <Hixie> | annevk: every member in HTML has to change somehow, because I currently check for infinity/nan myself for every member. |
| 17:28 | <Ms2ger> | Only I always have to point out to people that you do :) |
| 17:31 | <Hixie> | it's not clear to me that moving it to a different spec is going to make that better ;-) |
| 17:31 | <wycats> | Philip`: so if I follow the preprocessing rules, that should be enough for the tests? |
| 17:33 | <Ms2ger> | I think the fact that WebIDL used to allow passing through NaN/Infinity, but you caught it somewhere between WebIDL and your algorithms made it particularly hard |
| 17:44 | <Philip`> | wycats: Yeah, preprocessing plus tokenizing should be enough for the tests |
| 17:45 | <Philip`> | though if you don't closely follow the spec then number/position of parse errors may change |
| 17:46 | <Philip`> | (I think validator.nu doesn't match parse errors precisely) |
| 17:46 | <wycats> | Philip`: my setup should guarantee the proper position of the parse errors |
| 17:47 | <wycats> | here's an example of a state definition: https://gist.github.com/2330820 |
| 17:47 | <wycats> | token is the current token, next is the character that was just consumed |
| 17:47 | <wycats> | tokens is the token stream |
| 17:47 | <wycats> | errorState emits a parse error and switches states |
| 17:48 | <wycats> | as you can see, it's pretty close to the spec text, so the parse error positions should be exact |
| 17:49 | <wycats> | Philip`: is it expected to get two parse errors for character references containing the illegal characters? |
| 17:49 | <wycats> | once due to the preprocessing and once due to http://www.w3.org/TR/html5/tokenization.html#tokenizing-character-references |
| 17:50 | <Hixie> | sweet kittens did you really just reference the TR/ page version of the spec |
| 18:08 | <zewt> | awooga awooga |
| 20:01 | <Philip`> | wycats: I'm not quite sure what case you meant |
| 20:52 | <annevk> | Hixie: yeah have these generic rules at the top of the spec that are only overridden for canvas |
| 20:53 | <annevk> | Hixie: the new double aligns with those restrictions in throwing for Nan/Infinity |
| 20:53 | <annevk> | s/yeah/you/ ... |
| 20:53 | <Hixie> | yup |
| 21:13 | <wycats> | Philip`: ahh... the case I was looking at was &#..., which won't be invalid in the preprocessing phase |
| 21:13 | <wycats> | because it's just a number there |
| 21:14 | <annevk> | wycats: what are you writing the parser in? |
| 21:18 | <Philip`> | wycats: Indeed |
| 21:21 | <wycats> | annevk: JS |
| 21:22 | <wycats> | so far I'm probably 70% done with the tokenizer |
| 21:22 | <wycats> | I'm missing doctype, script, and entities in attribute values |
| 21:22 | <wycats> | annevk: specifically, browser-friendly JS |
| 21:23 | <wycats> | there's something written in node, but it makes heavy use of Node's streaming stuff |
| 21:23 | <wycats> | I also wanted the code to somewhat resemble the spec for pedagogical reasons |
| 21:23 | <annevk> | wycats: did you have a look at flanagan's code? |
| 21:23 | <wycats> | annevk: I googled hard and didn't find anything |
| 21:24 | <wycats> | link please |
| 21:24 | <annevk> | wycats: http://www.davidflanagan.com/2011/10/html-parsing-wi.html |
| 21:24 | <annevk> | wycats: https://github.com/andreasgal/dom.js/blob/master/src/impl/HTMLParser.js |
| 21:25 | <wycats> | I hope my code will not end up to be 250k |
| 21:25 | <wycats> | but unknown |
| 21:25 | <wycats> | maybe it will |
| 21:25 | <annevk> | probably a lot of it is the named character references |
| 21:25 | <wycats> | hm bigger problem |
| 21:26 | <wycats> | it seems to heavily use ES5 features |
| 21:26 | <wycats> | https://github.com/andreasgal/dom.js/blob/master/src/impl/HTMLParser.js#L155 |
| 21:26 | <wycats> | half the point of what I'm doing is as a polyfill for browsers without HTML5 parsers |
| 21:26 | <wycats> | so I can't use new features |
| 21:26 | <annevk> | kk |
| 21:26 | <wycats> | :/ |
| 21:26 | <wycats> | too bad |
| 21:26 | <annevk> | anyway, you might be able to borrow some |
| 21:26 | <gsnedders> | How are you getting the original HTML to reparse? |
| 21:27 | <wycats> | gsnedders: it's for things like innerHTML |
| 21:27 | <wycats> | where you have the string already |
| 21:27 | <wycats> | and you want a document fragment |
| 21:27 | <wycats> | if all goes well, I'll also be able to prototype the context-free parser stuff |
| 21:28 | <wycats> | the stuff from the <template> discussion |