| 02:13 | <Hixie> | wow, you sure have a lot of tests |
| 03:49 | <Hixie> | woot, i finally found a real bug in the parser tests |
| 03:54 | <Hixie> | oh wow, no, it's a spec bug |
| 04:12 | Hixie | fixes the spec |
| 04:12 | <Hixie> | looks like validator.nu already does this per the new spec |
| 04:13 | <SamB> | cool |
| 04:13 | <SamB> | just pretend it was always this way |
| 04:34 | <Hixie> | bummo, finally got to a test that relies on the script data less than sign state |
| 04:36 | <caitp> | bummo |
| 05:44 | <Hixie> | woops, the last checkin's message is bogus |
| 05:44 | <Hixie> | damnit |
| 05:44 | <caitp> | quick, force-push |
| 05:45 | <caitp> | before it's too late! |
| 05:45 | <Hixie> | don't think svn supports that, does it? |
| 05:46 | <SamB> | Hixie: no, but I think you *can* edit the commit message |
| 05:46 | <Hixie> | yeah, using svnadmin apparently |
| 05:46 | <Hixie> | i wonder where the repo actually is... |
| 05:47 | <SamB> | could do strange things to git mirrors ... |
| 05:47 | <Hixie> | aha, here we go |
| 05:47 | <Hixie> | eh, it's the checkin message |
| 05:47 | <Hixie> | how bad could it be |
| 05:48 | <SamB> | history would diverge depending on whether or not they saw the commit with the old message |
| 05:49 | <caitp> | i'm sure svn has full support for being terrible just like git does |
| 05:52 | <Hixie> | there, history has been revised. |
| 05:52 | <Hixie> | la la la. |
| 05:55 | <Hixie> | oh great, i found a bug in my tokeniser that the tokeniser tests didn't catch |
| 05:55 | <Hixie> | oops |
| 05:55 | <Hixie> | ok well now that i've broken everything it's time for bed. nn. |
| 06:40 | <Ms2ger> | "RESOLVED: Specs that define obsolete features don't need to test those features to exit CR." |
| 07:10 | <annevk_> | foolip: apparently Hixie changed a commit message in SVN, will that have bad effects on your mirror? |
| 07:11 | <annevk> | Ms2ger: what, for real? |
| 07:14 | <Ms2ger> | Part III of the Seoul notes |
| 07:14 | <annevk> | Oh wow, this was not from the HTML WG? |
| 07:14 | <annevk> | o_O |
| 07:15 | <Ms2ger> | No, CSS |
| 07:15 | annevk | is not impressed |
| 07:16 | <Ms2ger> | You should know I don't pay attention to the HTMLWG :) |
| 07:16 | <annevk> | So is the table display model now obsolete? |
| 07:48 | <foolip> | annevk: how did he do that? |
| 07:48 | <foolip> | but more importantly, which commit? |
| 07:48 | <annevk> | foolip: the last commit I think |
| 07:49 | <foolip> | let me check |
| 07:50 | <foolip> | do you know what the old and new message was? |
| 07:51 | <annevk> | foolip: old is what http://html5.org/r/8665 has |
| 07:52 | <annevk> | foolip: http://krijnhoetmer.nl/irc-logs/whatwg/20140609#l-142 |
| 07:52 | <annevk> | Ms2ger: with Anolis, why if I have <dfn>origin</dfn> I cannot refer to an origin defined elsehwere? |
| 07:53 | <annevk> | Ms2ger: why is data-anolis-spec not stronger? |
| 07:53 | <Ms2ger> | Mm |
| 07:53 | <Ms2ger> | That's probably because those are implemented in different processes |
| 07:55 | <Ms2ger> | Try https://pastebin.mozilla.org/5378908 |
| 07:55 | <annevk> | I'll hack around it |
| 07:56 | <annevk> | I want to switch to Bikeshed at some point anyway |
| 08:05 | <foolip> | annevk: html-mirror is now in sync with svn, but you'll probably need to force update your end since it's not a fast-forward commit |
| 08:07 | <annevk> | foolip: is there a way I can always do that? |
| 08:07 | <annevk> | foolip: so I don't have to do it if it happens again |
| 08:10 | <foolip> | yeah, you could fetch and reset --hard in your script |
| 08:24 | <annevk> | foolip: I can't get it to change |
| 08:24 | <annevk> | foolip: I tried git fetch --force; git reset --hard |
| 08:25 | <annevk> | foolip: also tried git pull --force |
| 08:26 | <foolip> | annevk: try simply git fetch and git reset --hard origin/master |
| 08:26 | <foolip> | (assuming you're on the master branch) |
| 08:29 | <annevk> | foolip: that seems to have fixed it |
| 08:30 | <annevk> | foolip: should I just change my script to that then? |
| 08:30 | <annevk> | I guess if Hixie does it again I'll do that |
| 08:34 | <zcorpan> | heycam|away: doesn't webidl allow single quotes? https://dvcs.w3.org/hg/csswg/rev/aec2cc899bab |
| 08:35 | <zcorpan> | http://heycam.github.io/webidl/#prod-string |
| 08:35 | <Ms2ger> | Apparently not |
| 08:35 | <zcorpan> | oh well |
| 08:36 | <zcorpan> | i actually run a webidl checker in the build process but it's flooded with missing interface type definitions so i missed that thing |
| 08:42 | <foolip> | annevk: there's a small risk that if my mirror breaks completely, reset --hard on your end will blindly follow along, leaving the web interface also broken until someone notices |
| 08:42 | <foolip> | I don't think it's going to matter much what you do, it'll be some work either way |
| 09:02 | <annevk> | foolip: okay, left it as is for now |
| 09:09 | <zcorpan> | annevk: the css "obsolete" was in the context of features that are non-web and must not be implemented by browsers |
| 09:09 | <zcorpan> | Ms2ger: ^ |
| 09:11 | <zcorpan> | i guess it wouldn't hurt with negative tests, but OTOH i think it's fine to exit CR always |
| 09:27 | <Ms2ger> | I see |
| 09:32 | <annevk> | Maybe I'll merge XMLHttpRequest in sooner. There's a lot of potential code sharing between XMLHttpRequest and fetch() |
| 09:33 | Ms2ger | looks what fetch() looks like |
| 09:36 | <Ms2ger> | Ah, GlobalFetch, there it is |
| 09:37 | <JakeA> | annevk: response.url, what did we decide that would be for constructed responses? |
| 09:37 | <annevk> | JakeA: the empty string, underlying object would be null |
| 09:37 | <Ms2ger> | annevk, do you want to implement Promises in Servo? :) |
| 09:37 | <zcorpan> | annevk: how do you suggest i fix addListener without invoking addEventListener? |
| 09:37 | <annevk> | zcorpan: you can use the underlying concepts just as addEventListener does |
| 09:38 | <annevk> | Ms2ger: not really |
| 09:38 | <zcorpan> | annevk: ok |
| 09:38 | <Ms2ger> | Would be nice if Servo did fetch() first |
| 09:38 | <annevk> | Servo should do Fetch first |
| 09:39 | <Ms2ger> | Not it :) |
| 09:39 | <JakeA> | annevk: So, if a page's CSP wanted to prevent constructed responses, we already have ways to detect that? We'd just need a CSP step after step 8 http://fetch.spec.whatwg.org/#http-fetch |
| 09:40 | <annevk> | JakeA: yes the idea for SW / CSP is to have a new step around there |
| 09:40 | <JakeA> | cool |
| 09:41 | <annevk> | JakeA: we still need to check if we do all the correct things with regards to redirects and such |
| 09:41 | <annevk> | JakeA: also currently response.url will be overwritten by request.url so we might need some distinct flag |
| 09:41 | <annevk> | JakeA: there's a bunch of things there we need to walk through carefully |
| 09:42 | <annevk> | I haven't done that, I'm mostly working on defining the API |
| 09:43 | <JakeA> | annevk: Is there any reason to overwrite response.url with request.url if the fetch is invoked recursively? That may be a good way to preserve it for the final CSP check |
| 09:44 | <annevk> | JakeA: yes, to make sure it's correct with respect to redirects |
| 09:44 | <annevk> | JakeA: otherwise e.g. responseURL on XMLHttpRequest would be wrong |
| 09:44 | <JakeA> | gotcha |
| 10:17 | <annevk> | JakeA: http://fetch.spec.whatwg.org/#fetchbodystream |
| 10:18 | <JakeA> | annevk: wfm! |
| 10:31 | <annevk> | JakeA: the main outstanding issue now is header representation |
| 10:32 | <annevk> | JakeA: I guess I'll try to tidy up everything aside from that |
| 10:32 | <annevk> | JakeA: if you could get some people to chime in on https://github.com/slightlyoff/ServiceWorker/issues/300 that'd be great |
| 10:53 | <toydestroyer> | Hi! Anyone here from Russian Google office in Moscow? |
| 11:04 | <JakeA> | annevk: Is anyone aside from Jonas against your proposal? |
| 11:05 | <annevk> | JakeA: not sure, also unsure whether HeaderMap is still the best name if it isn't really a map |
| 11:05 | <annevk> | Maybe just Headers |
| 11:08 | <JakeA> | annevk: Headers works, or HeaderData like FormData. I prefer just Headers. |
| 11:08 | <JakeA> | annevk: I think the proposal is spot on though. I don't think we need to make it a Map |
| 11:08 | <annevk> | Should we namespace all these classes? FetchHeaders, FetchRequest? |
| 11:09 | <annevk> | At the moment some are namespaced, some are not |
| 11:14 | <JakeA> | annevk: not keen on FetchRequest etc. Should it be HTTPRequest, or is it safe to assume http for browser requests? |
| 11:14 | <JakeA> | Although HTTPHeaders is clear |
| 11:14 | <annevk> | JakeA: HTTP is wrong for fetch() |
| 11:14 | <annevk> | JakeA: fetch() takes data URLs and such too |
| 11:15 | <JakeA> | annevk: Yeah, but when I do new Response(body) I'm creating an HTTP response |
| 11:15 | <JakeA> | anyway, I'm happy with just Response |
| 11:15 | <annevk> | JakeA: I'm not sure I see it that way |
| 11:15 | <annevk> | JakeA: e.g. Fetch (the spec) creates responses for data URLs too, they look like HTTP responses, but naming them such seems wrong |
| 11:17 | <JakeA> | fair |
| 11:22 | <jgraham> | annevk: I agree with your proposal fwiw |
| 11:57 | <Domenic> | annevk: so to('blob') ignores its argument if someone has previously called to('arraybuffer')? I think throwing an error would be better? |
| 12:01 | <Domenic> | errr return a rejected promise, of course |
| 12:15 | <Domenic> | annevk: > If the given value is not in the range 200 to 599, throw a TypeError. // should be RangeError |
| 12:17 | <annevk> | Domenic: you mean it would only work once? |
| 12:18 | <annevk> | JakeA: ^^ |
| 12:18 | <annevk> | Domenic: happy b-day btw |
| 12:19 | <JakeA> | Domenic: Ohh, happy birthday! Are you allowed to drink in pubs yet? :P |
| 12:19 | <Domenic> | annevk: thanks :). and, gtg, but yes, once you consume the stream, it's all gone. can discuss more later, maybe will open an issue or something |
| 12:19 | <JakeA> | annevk: If streams can only be consumed once, then to() should reject on second calling |
| 12:43 | <annevk> | JakeA: we could make to() store the contents somewhere, but it's prolly better to just throw it away I guess |
| 12:44 | <JakeA> | annevk: throwing away sounds better. More compatible with streams and better for memory |
| 12:53 | <annevk> | fixed |
| 12:56 | <zcorpan> | mathiasbynens: you must be new here (re https://github.com/ResponsiveImagesCG/picture-element/issues/198 ) |
| 12:56 | <mathiasbynens> | zcorpan: i guess I should go see the topic ^ now? |
| 12:56 | <zcorpan> | mathiasbynens: yes :-) |
| 12:58 | <zcorpan> | mathiasbynens: so in this case i'd expect people to use <picture> and test in a browser without support for <picture> (using picturefill or so) and conclude that everything is fine |
| 12:58 | <zcorpan> | but maybe it's not much of an issue |
| 12:59 | <zcorpan> | (or they test in a browser with support for <picture> but don't test dragging) |
| 13:59 | <annevk> | Domenic: should Response.redirect() throw RangeError too? |
| 14:24 | <caitp-> | aitp |
| 14:25 | <caitp> | irc clients mang, they're not very good |
| 14:50 | <MikeSmith> | hey caitp |
| 14:52 | <caitp> | good morning MikeSmith senpai |
| 14:52 | <MikeSmith> | heh |
| 14:54 | <MikeSmith> | caitp: been meaning to ask you about https://github.com/w3c/web-platform-tests/pull/981 |
| 14:54 | <MikeSmith> | Does that need review from annevk maybe? |
| 14:55 | <MikeSmith> | oh I see Simon commented on it |
| 14:55 | <caitp> | there was an issue opened about it on fetch or xhr, I forget |
| 14:56 | <MikeSmith> | ok |
| 15:06 | <Domenic> | annevk: ya RangeError there too I think. |
| 15:06 | <Domenic> | annevk: use GitHub issues and link to them from the top :) |
| 15:07 | <annevk> | Domenic: don't really want to migrate the existing setup |
| 17:33 | <hemanth> | From v0.11.6 I'm waiting for direct proxies in node..now we are at v0.11.13 still they havn arrived..:/ but why? |
| 17:43 | <Domenic> | hemanth: nobody is working on proxies in V8. |
| 17:44 | <Domenic> | https://code.google.com/p/v8/issues/detail?id=1543 |
| 17:46 | <hemanth> | Domenic, Holy Goodness, it was reported on Jul 7, 2011! :( |
| 17:47 | <Domenic> | hemanth: implementer priorities are what they are... age of a feature doesn't really make much of a difference. |
| 17:48 | <annevk> | 2011 is nothing |
| 17:49 | <hemanth> | Why are they finding it hard to sync up!? AFAIK SpiderMonkey is the only one which is almost up to the mark... |
| 17:50 | <zewt> | people have a lot to work on? |
| 17:50 | <hemanth> | But why have Proxy.create()? Rather remove it. |
| 17:51 | <TabAtkins> | annevk: Context for "obsolete doesn't need to be tested" is some property values that we're only defining in an informative appendix as having been supported by some printers, never browsers. |
| 17:51 | <Domenic> | SpiderMonkey also seems more willing to push out mostly-compliant, but unoptimized, versions of ES6 features. |
| 17:51 | <Domenic> | hemanth: they don't have Proxy.create() unless you turn on flags |
| 17:51 | <annevk> | TabAtkins: yeah, zcorpan mentioned that, I guess that's fine |
| 17:52 | <hemanth> | Domenic, Yeah, in any case for most of the ES6 features we need to turn on the flag |
| 17:55 | <hemanth> | I can understand it's tough for all the implementer to be in sync, but atleast when they are implementing a new spec, they can try to be, right? Each time a new spec is being implemented again the same mistakes are repeated.... |
| 17:55 | <TabAtkins> | annevk: Yeah, things which need to be supported by browsers obviously need testing, even if they're obsolete and not to be used by authors. |
| 17:55 | <hemanth> | Sorry, but I'm finding it hard to understand the underlying problem. |
| 17:56 | <annevk> | hemanth: wrong channel to complain about V8 |
| 17:56 | hemanth | sits at a corner. |
| 17:57 | <hemanth> | No response at #node.js; annevk. I'm not complaining, just trying to understand... |
| 17:58 | <hemanth> | <pachet> hemanth: because proxies are evil and will cause all of your friends to stop talking to you |
| 17:58 | <hemanth> | ^ heh heh from #node.js |
| 17:58 | <annevk> | hemanth: there's no infinite resources for a project so there is some balancing between new features, improving existing features, fixing bugs, perf, security, etc. |
| 17:59 | <annevk> | hemanth: then there's been ongoing discussion on the proxy design over in TC39 over the past couple of years which will likely lower priority for implementing it, etc. |
| 17:59 | <annevk> | hemanth: age of the bug doesn't really matter, there's decade old bugs that haven't been fixed yet |
| 18:01 | <hemanth> | Thanks for the insight annevk. |
| 18:02 | hemanth | makes a note in his diary : "So it's all about implementer priorities and finite resources." |
| 18:03 | <caitp> | that's a recurring theme around here |
| 18:03 | <hemanth> | :) |
| 18:04 | <Hixie> | well "If the next token is a U+000A LINE FEED (LF) character token, then ignore that token and move on to the next one" is a huge pain in the neck... |
| 18:04 | <Ms2ger> | Indeed |
| 18:06 | <Hixie> | i guess the tree constructor just has to set a flag on the tokeniser |
| 18:15 | <hemanth> | Can anyone state an example for an exotic object? |
| 18:15 | <Hixie> | Window |
| 18:15 | <Hixie> | (right?) |
| 18:15 | <Hixie> | (or no?) |
| 18:15 | <Ms2ger> | []? |
| 18:15 | <hemanth> | Window heh heh yup, [] not sure. |
| 19:42 | <annevk> | yay, feedback from Microsoft |
| 20:00 | <annevk> | JakeA: Domenic: if to() reads all, what happens if you then store it? |
| 20:01 | <annevk> | JakeA: Domenic: there won't be anything, that seems kinda sad |
| 20:41 | <Domenic> | annevk: what do you mean, "then store it"? |
| 21:55 | <estellevw> | on http://www.w3.org/TR/html-markup/input.button.html the constraints and admonitions make it seem like list is a valid attribute. While it does not mention the list attribute as a valid attribute in the first half of the document, adding "The list attribute of the input element must refer to a datalist element." on the button type page makes it seem like it would actually do something. Does anyone know who edits these pages, and if it makes sense to bu |
| 21:55 | <estellevw> | them to remove that line? |
| 21:57 | <Domenic> | estellevw: did you see the abstract at http://www.w3.org/TR/html-markup/Overview.html ? |
| 21:58 | <estellevw> | nope. i did not. thanks |
| 22:01 | <estellevw> | wow. those pages aren't as informative as the archive. I need to do some updating. (Anyone have a time traveler I can borrow so I can find the time.) |
| 23:52 | <Hixie> | hm, that's odd |
| 23:52 | <Hixie> | my mail to es-discuss didn't make the archives? |
| 23:56 | Hixie | tries sending it again |
| 23:59 | <Hixie> | hey anyone know how we're doing with dropping mutation events? |