| 20:47 | <TabAtkins> | Heads up: I just pushed the first phase of my html parser rewrite (take 2). It looks like it should be great; in particular, I got zero output changes in WHATWG specs. I did spot checks on several specs to make sure I wasn't outputting spurious new warnings, but as I don't yet have console text logged as part of tests, I'm not 100% sure about that. Please let me know if anything looks wrong. |
| 20:48 | <TabAtkins> | (It's in the new version 3.14.0) |
| 23:01 | <sideshowbarker> | Heads up: I just pushed the first phase of my html parser rewrite (take 2). It looks like it should be great; in particular, I got zero output changes in WHATWG specs. I did spot checks on several specs to make sure I wasn't outputting spurious new warnings, but as I don't yet have console text logged as part of tests, I'm not 100% sure about that. Please let me know if anything looks wrong. |
| 23:02 | <TabAtkins> | Yeah, plan for a long while has been to integrate all of Bikeshed's core parsing into one (heavily modified) parser. |
| 23:02 | <TabAtkins> | HTML, markdown, and all of bikeshed's varied shorthand syntaxes |
| 23:03 | <sideshowbarker> | Excellent |
| 23:04 | <sideshowbarker> | Optimized for performance? Or instead that's not a priority? |
| 23:05 | <TabAtkins> | Definitely not a priority at this phase, but I'm pretty confident it will be a perf benefit over the "run shitloads of regexes over the document repeatedly" process that I do today. |
| 23:06 | <TabAtkins> | But mostly it's about correctness; processing things in the distinct phases that I do today just doesn't work |
| 23:07 | <TabAtkins> | (There's a bunch of places where, say, I have to handle something before the HTML parser sees it, but I have to avoid messing with it if it shows up inside an XMP or markdown code span, etc. All my inline shorthands work only if you nest them in the order that I happen to process them. etc.) |