| 01:15 | <zewt> | not sure whether to be amazed that webgl people are actually arguing for polling with a straight face, or thankful that somebody involved is actually bothering to ask us for help |
| 01:17 | <Hixie> | you know "us" includes webgl people, right? :-) |
| 01:17 | <zewt> | yep :) |
| 01:18 | <zewt> | (i don't mind if somebody who thinks polling is acceptable on the web platform knows how insane I think that is) |
| 01:54 | <gman2> | I'm the one pushing for callbacks. Unfortunately the majority of WebGL peeps come from C land. So please help convince them (with logic not snark) why it must be callbacks, not polling. |
| 01:55 | <Hixie> | zewt: ^ |
| 01:56 | <zewt> | gman2: already made my attempt :) |
| 02:00 | <zewt> | what I wish is that the people arguing for WebGL being different from the rest would spend the effort of asking why the platform is as it is, instead of just assuming conventions are wrong and should be ignored |
| 02:01 | <zewt> | some sort of fallacy of intuition--people experienced in C, whose intuition in C is probably usually right, moving to JavaScript and expecting their intuition to still work without the experience to back it |
| 02:01 | <zewt> | (and I wouldn't claim to be immune from this myself, of course) |
| 02:06 | <gman2> | There's more to it than just "make it like C". There's also the politics. It's much easier to get several browser vendors to agree to implement an existing standard (OpenGL ES) than to make a new one and argue over it for years |
| 02:07 | <zewt> | i don't buy that; opengl es is a *C* standard, and it should be no harder to get people to implement a competently-designed and specced JavaScript binding |
| 02:07 | <zewt> | (of course, the spec can be written in terms of dispatch to C entry points in GLES) |
| 02:08 | <gman2> | The proof's in the pudding. Post your design. Once you start changing the API you make it harder to port existing code. You also open up the "well if we changed that why not this too?" I know one guy that wants to make it stateless. I'd luuuuuuuuuv that. But I have no hope it's going to happen |
| 02:08 | <zewt> | "port"? there's no such thing as a "port" from C to JavaScript; that's a rewrite |
| 02:09 | <zewt> | and the binding layer is the simplest part of the whole thing (the complex parts are things like rendering details, which you *do* want to get as unchanged as possible from GLES, and the canvas binding details, which GLES doesn't help at all with) |
| 02:11 | <zewt> | anyway, we're stuck with the webgl we have today; the point is that a polling API would be the same sort of mistake |
| 02:12 | <zewt> | it sounds like the real, immediate problem with the polling/callback thing is simply a matter of education, which is why I posted the sample code I did; it shows that event-based APIs are no harder to use |
| 02:15 | <gman2> | Just fyi, some of the objections to callback vs polling are coming from members of Google Maps Team. (not all of them,). The point being they aren't noob JS people. They're arguably writing one of the more complex web apps out there. |
| 02:16 | <zewt> | all that does is lower my opinion of Google a bit further |
| 02:18 | <gman2> | Just fyi, the next WebGL is planned to require a different context string. So there is a chance to change anything you'd like to see changed. Join the list and present your thoughts |
| 02:19 | <zewt> | i was very active on the list for quite a while; i found it a bit too frustrating, so decided to take a break |
| 02:19 | <Hixie> | zewt: pro tip, btw, you'll be able to convince more people if you don't (even slightly, implicitly, or in their absence) insult them... (not that i'm good at taking that advice myself, but i'm just putting it out there) |
| 02:19 | <zewt> | (also the idea of "the next WebGL" sounds a bit un-Web to me) |
| 02:19 | <Hixie> | gman2: browsers are going to have to support two webgls? |
| 02:20 | <zewt> | Hixie: i try; but i hit my quota quickly with particularly-nuts things |
| 02:20 | <zewt> | Hixie: which, by the way, is another of the many reasons I don't want your job :) |
| 02:22 | <zewt> | gman2: if anybody can explain any possible downside to an API like HTMLImageElement's .complete and onload, I'm listening--but I can't even contrive one |
| 02:22 | <gman2> | Hixie: The current plan is the new one is a superset of the old. But you get it by requesting "webgl2.0" or something. So at the moment it would be backward compatible. You could take your webgl 1.0 code, ask for a webgl 2.0 context and it would just work. But, it doesn't have to stay that way. There's no reason it has to stay backward compatible. People could ask for a 1.0 context and there apps would keep working. |
| 02:22 | <zewt> | (that is, compared to a polling interface--not talking about the weird details of <img>, of course) |
| 02:23 | <Hixie> | gman2: .complete is a disaster, mostly because it can change while script is running. but that's orthogonal. |
| 02:23 | <Hixie> | gman2: there are _lots_ of reasons it should stay backwards compatible and that we should only have one webgl |
| 02:23 | <zewt> | gman2: remember, .complete *does* allow polling if you really want to do that--but it gives an event, too |
| 02:25 | <gman2> | zewt: Yea, I gave that example that if you only have callbacks and you want polling you just make the callback set some flag and then poll the flag. All though with true polling you could exit a hard loop. Without it you can't |
| 02:25 | <zewt> | gman2: define "true polling" in this context, since I'm not sure what it means |
| 02:26 | <zewt> | (or, I hope it doesn't mean what I think it means :) |
| 02:26 | <gman2> | "true polling" means this loop exits while(!complete()); |
| 02:26 | <zewt> | :| |
| 02:26 | <gman2> | I know |
| 02:26 | <Hixie> | "peg the cpu" isn't a good coding technique :-) |
| 02:26 | <zewt> | that's not just a bad idea, that's catastrophic |
| 02:29 | <zewt> | every api on the platform (web-compatibility aside, eg. .complete) should be designed to guarantee that that never works, to make sure nobody ever does it |
| 02:34 | <zewt> | (if people want to write synchronous code, they need to wait for worker support) |
| 02:34 | <Hixie> | even in a worker, i wouldn't want anyone to rely on polling, that'll just peg the cpu |
| 02:35 | <zewt> | Hixie: right, but you can expose real synchronous APIs |
| 05:21 | <MikeSmith> | Hixie: ok, about the outline bug, I read your latest comment and went back and re-implemented it per spec |
| 05:21 | <MikeSmith> | and for your first case I'm now getting output that matches what you described in your earlier comment |
| 05:22 | <MikeSmith> | and without breaking the expected behavior for the other two cases that I was already conforming to |
| 05:23 | <MikeSmith> | I'll push the change to http://qa-dev.w3.org:8888/ |
| 05:25 | <MikeSmith> | so now the validator will have the only conforming implementation and people who compare results with the other outline tools are going to file bugs against the validator saying it doesn't match what those other tools produce :-) |
| 05:34 | <MikeSmith> | Hixie: now pushed to http://qa-dev.w3.org:8888/ |
| 05:35 | <MikeSmith> | would be nice to have some other test cases |
| 05:54 | <Hixie> | MikeSmith: cool |
| 05:56 | <Hixie> | MikeSmith: should i add something like "adding the implied headings is not a no-op! :-)" to the spec, or do you think the spec's output is suboptimal? |
| 05:59 | <MikeSmith> | heh :) no, I don't think "adding the implied headings is not a no-op!" is needed. And after considering the output, I think the spec's output it quite rational. |
| 05:59 | <MikeSmith> | really my mistake was that I looked at other implementations and assumed I must have made a mistake since my output didn't match those |
| 06:00 | <Hixie> | how many other implementations are there? |
| 06:00 | <Hixie> | i'm concerned that none of them matched the spec |
| 06:00 | <MikeSmith> | I can see now that I actually pretty much had it right to begin with, but then I changed it after looking at others |
| 06:00 | <Hixie> | implies the spec is broken in some sense |
| 06:01 | <MikeSmith> | Hixie: maybe. Or maybe it's because they all tried to match the behavior of the first implementation |
| 06:01 | <Hixie> | heh |
| 06:01 | <Hixie> | could be |
| 06:01 | <MikeSmith> | which I maybe gsnedders was the first |
| 06:01 | <Hixie> | maybe the examples i mentioned in that bug would be useful in the spec then |
| 06:01 | <MikeSmith> | yeah yeah |
| 06:01 | <MikeSmith> | for sure |
| 06:02 | <MikeSmith> | good idea |
| 06:02 | <MikeSmith> | that would help |
| 06:02 | <MikeSmith> | I guess I should also write some tests and contribute them to the test suite |
| 06:03 | <MikeSmith> | anyway, there are 3 other implementations I know of |
| 06:03 | <MikeSmith> | lemme get some URLs |
| 06:03 | <Hixie> | just names is fine |
| 06:03 | <Hixie> | not planning on looking them up |
| 06:03 | <Hixie> | just curious what they are |
| 06:05 | <MikeSmith> | well, there's gsnedders one, then there is "h5o" which is a Chrome extension/bookmarklet thing, and then .. one more |
| 06:05 | MikeSmith | looks for the name |
| 06:06 | <MikeSmith> | just called "HTML5 Outliner" from hoyois on github |
| 06:07 | <Hixie> | k |
| 06:10 | <MikeSmith> | Hixie: anyway, thanks for your patience in your responses in the bug |
| 06:10 | <Hixie> | hey np |
| 06:10 | <Hixie> | that's my job |
| 06:11 | <Hixie> | i wonder what the best markup is to describe a document outline |
| 06:11 | <Hixie> | nested <ol>s is the most obvious choice |
| 06:12 | <MikeSmith> | yeah that's what I use for the "Show outline" output for the validator |
| 06:19 | <MikeSmith> | Hixie: btw I just found and tried a fourth implementation, an Opera extension, and it matches the non-spec-conforming behavior of the other three (for the <section>a<section>b</section><h2>C</h2>c</section> |
| 06:19 | <MikeSmith> | case) |
| 06:19 | <Hixie> | man |
| 06:20 | <Hixie> | i wonder if it's a lost cause |
| 06:20 | <MikeSmith> | as far as I know, these really are all independent implementations |
| 06:20 | <Hixie> | seems so weird to consider C the heading of b in that example |
| 06:20 | <MikeSmith> | yeah, it seems weird to me now as well |
| 06:20 | <Hixie> | i guess i'll try these examples in the spec and see if that helps, first |
| 06:20 | <MikeSmith> | ok |
| 06:22 | <Hixie> | btw when i submit a text field upload, the text field on the results page doesn't have my input in it |
| 06:22 | <Hixie> | which makes it hard to iterate |
| 06:22 | <Hixie> | (on the validator) |
| 06:22 | <MikeSmith> | oh |
| 06:23 | <MikeSmith> | that's not intentional -- it's supposed to copy it back in |
| 06:23 | <MikeSmith> | so that's maybe a regression I introduced somehow recently |
| 06:25 | <MikeSmith> | Hixie: oh I think it only copies it if you have the "Show source" option set |
| 06:26 | <Hixie> | aah |
| 06:27 | <MikeSmith> | that is by design because what we actually do is, we copy the source from the "Show source" output back into the textarea, on the client side |
| 06:27 | <Hixie> | i just wanted to play with the outliner :-) |
| 06:28 | <Hixie> | <body><section><h1>A</h1><h1>B</h1></section></body> |
| 06:28 | <Hixie> | ...gives me an implied heading for the <section> for some reason |
| 06:28 | <MikeSmith> | hmm yeah |
| 06:28 | <MikeSmith> | that's a bug |
| 06:30 | <MikeSmith> | but if you do <body><h1>h1</h1><section><h1>A</h1><h1>B</h1></section></body> there's no bug |
| 06:30 | <Hixie> | odd |
| 06:30 | <MikeSmith> | I guess probably just due to me not re-initializing something |
| 06:30 | MikeSmith | checks |
| 06:32 | <MikeSmith> | yeah, that's all it was |
| 06:33 | <MikeSmith> | Hixie: thanks for catching that :) |
| 06:33 | <Hixie> | it was one of the examples i'm adding :-) |
| 06:34 | <MikeSmith> | fixed in my working directory and will push it to qa-dev in a minute |
| 06:34 | <MikeSmith> | sloppy coding man |
| 06:34 | <MikeSmith> | sometimes surprised any of my code works at all |
| 06:34 | <Hixie> | i know the feeling |
| 07:00 | <Hixie> | MikeSmith: http://qa-dev.w3.org:8888/ seems to be down |
| 07:03 | <Hixie> | MikeSmith: http://www.whatwg.org/specs/web-apps/current-work/#sample-outlines |
| 07:15 | <MikeSmith> | Hixie: thanks |
| 07:15 | MikeSmith | reads |
| 07:15 | <MikeSmith> | Hixie: I just restarted http://qa-dev.w3.org:8888/ to push the fix I made |
| 07:16 | <MikeSmith> | should be working now |
| 07:17 | <MikeSmith> | Hixie: btw I see now that the Opera extension is not an independent implementation -- it says "This extension is a port of the bookmarklet at http://code.google.com/p/h5o/"; |
| 07:22 | <MikeSmith> | Hixie: I read all of http://qa-dev.w3.org:8888/ |
| 07:22 | <MikeSmith> | looks great man |
| 07:22 | <MikeSmith> | big thanks |
| 07:22 | <JonathanNeal> | Did TabAtkins ever come around? |
| 07:23 | <MikeSmith> | JonathanNeal: not in the last 4 hours, no |
| 07:23 | <JonathanNeal> | k |
| 07:26 | <MikeSmith> | Hixie: btw I guess if you tested http://qa-dev.w3.org:8888/ you know for the outline it just drops subheadings on the floor. I guess I could without enough have it do something like your "Additional Commentary — Because not all this is necessarily true — Ok it's almost certainly not true" example instead. But as long as it's conforming to just do the laziest possible thing of just dropping them on the floor, I prefer doing that. :-) |
| 07:27 | <MikeSmith> | JonathanNeal: nice blog post, btw. about MQ stuff |
| 07:27 | <MikeSmith> | s/could without enough/could without too much trouble/ |
| 07:28 | <JonathanNeal> | Thanks for reading it. Let me know if you have any ideas yourself or other feedback to improve the conversation. |
| 07:35 | <MikeSmith> | Hixie: also btw I guess you can see that for the validator outline rather than styling with numbers I just stole your Live DOM Viewer tree-view styling. |
| 09:07 | <Ms2ger> | !summon zcorpan |
| 09:09 | <Ms2ger> | "40% of Gmail's storage is signature files and attached logo images." |
| 09:09 | <jgraham> | Ms2ger: glwt |
| 09:10 | <Ms2ger> | jgraham, hmm? |
| 09:10 | <jgraham> | Summoning zcorpan |
| 09:10 | <Ms2ger> | Alright, you then |
| 09:10 | <jgraham> | Dammit |
| 09:10 | <Ms2ger> | Do you know if there's a test for https://www.w3.org/Bugs/Public/show_bug.cgi?id=17195 in the test suite? :) |
| 09:11 | <jgraham> | MikeSmith: FWIW I had an outline implementation before gsnedders. But it got deleted at some point (I *think*, but I'm not sure, that gsnedders' implementation is independent) |
| 09:14 | <jgraham> | Ms2ger: I strongly suspect there isn't |
| 09:14 | <jgraham> | But I don't know |
| 09:14 | <Ms2ger> | You want to add one? :) |
| 09:14 | <jgraham> | I want you to add one :p |
| 09:15 | <Ms2ger> | But I don't want to add one :) |
| 09:15 | <jgraham> | Seems like Hixie already wrote a test, it just needs to be testharnessified |
| 09:22 | <Ms2ger> | Hrm |
| 09:23 | <Ms2ger> | jgraham, https://github.com/w3c/html-testsuite/blob/master/old-tests/submission/Opera/microdata/001.html#L1340 |
| 09:24 | <Ms2ger> | AFAICT, the last two assertions there are wrong |
| 09:27 | <jgraham> | about dateTime and textContent? |
| 09:27 | jgraham | notes he didn't write these tests |
| 09:28 | <jgraham> | (not because I never write wrong tests; I do, but because I'm not that familiar with them) |
| 09:32 | <Ms2ger> | Setting itemValue should set datetime, not textContent, I think |
| 09:32 | <Ms2ger> | And I'm asking you because you're the closest to a zcorpan I can find here :) |
| 09:33 | <MikeSmith> | jgraham: I hope your outline-algorithm implementation actually followed the spec. After working on this, I've gone from being a skeptic about the outline-algorithm logic to being a true believer. |
| 09:33 | <MikeSmith> | I'm a convert |
| 09:33 | <jgraham> | He didn't write the tests eitehr :) |
| 09:33 | jgraham | checks the spec |
| 09:34 | <MikeSmith> | maybe I changed do to Stockholm Syndrome but I don't care |
| 09:34 | <nickshanks> | morning users |
| 09:35 | <MikeSmith> | nickshanks: howdy |
| 09:36 | <Ms2ger> | jgraham, got anyone else to pester? odinho? :) |
| 09:36 | <odinho> | Nooooo |
| 09:36 | <jgraham> | He didn't write them either :) |
| 09:36 | <jgraham> | Ms2ger: I tend to agree that it should set the attribute rather than the textContent |
| 09:37 | <jgraham> | Although it isn't really clear how one "acts as if" an attribute was reflected |
| 09:37 | <Ms2ger> | "on setting, must set the content attribute to the specified literal value", presumably |
| 09:38 | <jgraham> | Presumably |
| 09:50 | <nickshanks> | where can i find a "changes from HTML 5.0" document/appendix to HTML 5.1? |
| 09:56 | <Ms2ger> | jgraham, so could you find someone to fix the test? :) |
| 09:56 | <jgraham> | Ms2ger: Hi, I have a test that needs fixing |
| 09:57 | <Ms2ger> | I hate you |
| 09:59 | <jgraham> | Ms2ger: I guess I can fix it |
| 09:59 | <Ms2ger> | That would be great :) |
| 10:23 | <MikeSmith> | nickshanks: there isn't one |
| 10:23 | <jgraham> | Ms2ger: Pull request sent |
| 10:24 | <Ms2ger> | Merged, thanks |
| 10:24 | <MikeSmith> | nickshanks: and most people here aren't involved with HTML 5.0 and HTML 5.1. The better IRC place to ask is #html-wg on irc.w3.org |
| 10:34 | <Ms2ger> | Hmm, darobin merged some of my tests, excellent |
| 10:53 | <Ms2ger> | Didn't Hixie move to the URL standard yet? |
| 10:55 | <MikeSmith> | not yet I don't think, no |
| 11:00 | <annevk> | Ms2ger: no, open bug |
| 11:00 | <Ms2ger> | I see |
| 11:00 | <annevk> | Ms2ger: Encoding Standard is in |
| 11:00 | <Ms2ger> | \o/ |
| 11:02 | <MikeSmith> | annevk: is the appcache meeting today? |
| 11:05 | <darobin> | MikeSmith: yeah |
| 11:05 | <annevk> | MikeSmith: it's in #appcache |
| 11:09 | <gsnedders> | jgraham: My outline impl had nothing to do with yours. |
| 11:09 | <Ms2ger> | jgraham, and can you find someone to clear out the tests that don't match the spec anymore from http://w3c-test.org/html-testsuite/master/old-tests/submission/Opera/timeelement/001.html ? |
| 11:09 | Ms2ger | looks at odinho |
| 11:22 | <MikeSmith> | so I wonder who's going to be the first smartass to try to draw some conclusion from the fact that the % of WebKit commits from Apple and Google engineers are roughly the same in http://bitergia.com/public/reports/webkit/2013_01/ while there's almost four times as many Google authors committing as there are Apple authors committing |
| 11:23 | Ms2ger | tries to understand what MikeSmith is saying |
| 11:23 | <gsnedders> | Words. |
| 11:24 | <Ms2ger> | Applers are four times more productive than Googlers? |
| 11:26 | <karlcow> | There are more lords (reviewers) at Apple than peasants (committers) too |
| 11:27 | <MikeSmith> | I distrust data |
| 11:28 | <MikeSmith> | I think we need some experts to weigh in on this so that I be told what I should properly be thinking of it |
| 11:29 | <karlcow> | sir dada tuttsi |
| 11:38 | <odinho> | MikeSmith: Well, Apple has core webkit people who work on webkit code/stuff. Google people work on the full browser, and go down to webkit everytime they feel like it? |
| 11:52 | <Ms2ger> | jgraham, I'll have a look at the time test myself |
| 11:53 | <odinho> | Ms2ger: Sorry, little time atm. Can't jump on everything that would be nice to do. |
| 11:53 | <Ms2ger> | Don't we all? :) |
| 12:21 | <jgraham> | Ms2ger: Thanks |
| 12:23 | <Ms2ger> | Np |
| 12:24 | <jgraham> | All this talk of Apple, and now I want a tart tartin |
| 13:07 | <karlcow> | jgraham: tatin but yes +1 to that ;) |
| 13:08 | <karlcow> | https://fr.wikipedia.org/wiki/Tarte_Tatin |
| 13:10 | <jgraham> | karlcow: I can't even spell in English. What hope do I have in strange foreign tounges? |
| 13:10 | <karlcow> | :D |
| 13:11 | <karlcow> | I gave up myself a long time ago on that. I have been exposed far too late on foreign languages. First time ever at school at 12 for German, then 14 for English. It shows. |
| 14:45 | <zewt> | hmm, sort of weird that the URL interface can't distinguish between http://foo.com and http://foo.com# and http://foo.com?, even though it seems like the interface allows it |
| 14:45 | <zewt> | (s/can't/doesn't/) |
| 15:04 | jgraham | grumbles about appcache discussions happening in a private repository |
| 15:09 | <nickshanks> | jgraham, just ask for permission. i did. :) |
| 15:10 | <cwilso> | and jgraham, that's a temporal anomaly. It will be resolved shortly. |
| 15:24 | <jgraham> | cwilso: Well, please ping me when someone clicks the "make this repo public" button |
| 15:25 | <cwilso> | jgraham: will do. |
| 15:26 | <jgraham> | Thanks |
| 17:10 | <GPHemsley> | MikeSmith, hsivonen: I don't remember who's in charge of the various validators, but they seem to treat all tags within <option> as stray end tags, even when they're start tags |
| 17:12 | <MikeSmith> | GPHemsley: pretty sure that's not the case for http://validator.nu/ or http://validator.w3.org/nu/ |
| 17:12 | <MikeSmith> | which are the only ones I work on |
| 17:13 | <GPHemsley> | MikeSmith: Oh, it indeed is the case. :) |
| 17:14 | <GPHemsley> | http://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.govtrack.us%2F |
| 17:14 | <MikeSmith> | ok if so that's due to the validator having a parser that follows the spec |
| 17:14 | <GPHemsley> | Hixie: Oh, so this is your fault? ;) |
| 17:16 | <MikeSmith> | that message may just be a copy/paste error in the htmlparser code |
| 17:16 | <GPHemsley> | ah, much simpler |
| 17:17 | <GPHemsley> | If so, though, it's carried over from the old one to the new one |
| 17:17 | <GPHemsley> | (nu one) |
| 17:18 | <MikeSmith> | hmm no, because the error message from "View source" in Firefox says "Stray start tag" as expected. |
| 17:19 | <GPHemsley> | eesh, view source is 7 lines?? >_< |
| 17:19 | <GPHemsley> | (and only because a <dl> apparently gets special formatting) |
| 17:21 | <MikeSmith> | hmm weird that there's this difference between the messages from Firefox and the validator |
| 17:22 | <MikeSmith> | because it's the same parser and those messages come straight from the parser code, not the validator code |
| 17:24 | <GPHemsley> | yay obscure bugs |
| 17:40 | <dglazkov> | good morning, Whatwg! |
| 18:16 | <JonathanNeal> | yay |
| 18:24 | <JonathanNeal> | Hixie: it's pretty impressive how much documentation is out there that gets : and :: wrong. Oh, and do they have syntax names (outside of colon and doublecolon)? |
| 18:47 | <Hixie> | JonathanNeal: "pseudo-class" and "pseudo-element", probably. the main problem i think is that we changed the syntax after most of the pesudo-elements used ':', so it's very confusing. |
| 18:48 | <JonathanNeal> | Yea, I just came across a lot of posts about css3 using the css2 understanding. |
| 19:34 | <gsnedders> | 16 failures in both Py2 and Py3 in one codebase. |
| 19:34 | <gsnedders> | jgraham: ^^ |
| 20:36 | <zewt> | gar |
| 20:40 | <zewt> | ios safari sends onscroll continually while the user is dragging to scroll, but in a -webkit-overflow-scrolling: touch box, it stops sending scroll if the user flings to scroll until it completely finishes scrolling :| |
| 20:40 | <zewt> | making it very hard to tell if scrollTop can be changed without colliding with native scrolling |
| 20:50 | <zewt> | guess a workaround is to unset webkitOverflowScrolling, flush style and reset touch before changing scrollTop, which kills any fling-scroll that's in progress |
| 22:18 | <gsnedders> | jgraham: FWIW, I now have all of Python (2/3) in one git repo, and another with tests. |
| 22:24 | <gsnedders> | https://github.com/gsnedders/html5lib-tests is the current attempt |
| 23:11 | <annevk> | Hixie: so fwiw, data:// would not fail to parse as a URL, it would fail at the data: handler level |
| 23:11 | <annevk> | Hixie: that's the tentative plan anyway |
| 23:14 | <Hixie> | ah ok |