| 05:24 | <annevk> | Hixie: so the DOMTokenList story is I think that I did tell you about a change, but that I wanted to wait with filing bugs on HTML until someone had attempted to implement the changes we made for DOM |
| 05:25 | <annevk> | Hixie: let me dig up the trail |
| 05:27 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=20105 |
| 05:28 | <annevk> | But that's not the big one |
| 05:29 | <annevk> | Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20104#c4 is the one |
| 05:29 | <annevk> | Hixie: I did add you to the cc, but maybe that's not good enough these days? |
| 07:15 | <jgraham> | annevk: Just for you critic is now https |
| 07:16 | <annevk> | aw man, now I might have to start using it |
| 07:25 | <asmodai> | in HTML5, <label> and form controls are a 1:1 mapping, right (as opposed to HTML4's N:1 mapping)? I mean, unless I missed some part of the spec |
| 07:47 | <zcorpan> | asmodai: a form control can have 0 or more labels, a label can have 0 or 1 form control |
| 07:48 | <zcorpan> | asmodai: also see http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-lfe-labels |
| 07:52 | <jgraham> | So where's darobin hiding? |
| 07:58 | <asmodai> | zcorpan: *nod* thanks. Now I wonder why this designer thinks he can apply a <label> to a <ul> of <input "radio">s. |
| 11:19 | <hsivonen> | on Linux x86_64, my local clang opt build fails with symbol "isascii" missing when linking WebRTC STUN stuff. known problem? |
| 11:20 | <hsivonen> | apparently yes: https://bugzilla.mozilla.org/show_bug.cgi?id=860222 |
| 11:21 | <hsivonen> | doh. wrong channel. sorry. |
| 11:22 | <Ms2ger> | Yep |
| 11:25 | <jgraham> | darobin: (I have to run now, but see my email to public-test-infra) |
| 11:26 | <darobin> | jgraham: ok, just arriving now, but I'll look! |
| 11:27 | <Ms2ger> | annevk, there's some critic reviews I'd love you to have a look at ;) |
| 11:28 | <annevk> | Ms2ger: I can have a look now if you want. PointeR? |
| 11:29 | <annevk> | darobin: I setup a hook from the repo |
| 11:29 | <Ms2ger> | https://critic.hoppipolla.co.uk/r/27, 28, 29 |
| 11:29 | <darobin> | annevk: ok, great |
| 11:29 | <annevk> | darobin: is your GH account darobin too? I can add you to WHATWG |
| 11:29 | <darobin> | annevk: yes it is, ok, I'll try not to replace the logo with W3C's ;) |
| 11:29 | <annevk> | heh |
| 11:29 | <darobin> | annevk: the sync didn't work last night when I left, but it was likely a problem of MX record propagation so I need to test again now |
| 11:30 | <darobin> | in any case it'll work soon |
| 11:30 | <annevk> | k |
| 11:30 | <Ms2ger> | zcorpan, thanks for the link yesterday |
| 11:30 | <annevk> | you're added as admin |
| 11:30 | <annevk> | we don't really have groups |
| 11:30 | <Ms2ger> | Hmm |
| 11:30 | <darobin> | cool, thanks |
| 11:30 | <zcorpan> | Ms2ger: np |
| 11:30 | <Ms2ger> | Does that mean darobin gets to tweet as @WHATWG too? |
| 11:30 | <darobin> | I don't think the tweeting is handled through GitHub :) |
| 11:31 | <annevk> | Ms2ger: yeah I guess, if he wanted |
| 11:31 | <Ms2ger> | You'd be surprised |
| 11:31 | <darobin> | hehehe |
| 11:31 | <annevk> | but our policy for @WHATWG is that anyone can tweet from it as long as it's not spam so that's not a problem |
| 11:31 | <darobin> | I can tweet from @w3c as well |
| 11:32 | <darobin> | so I could wreak total havok and then move on to some other career |
| 11:32 | <annevk> | Ms2ger: lots of tests |
| 11:33 | <annevk> | Ms2ger: what kind of quality are we looking for? |
| 11:33 | <annevk> | e.g. "XMLHttpRequest L2" seems wrong for <title> |
| 11:34 | <Ms2ger> | Mainly correctness, but feel free to complain about things like that too |
| 11:45 | <annevk> | I can't do 28 I think. I wrote a lot of those tests. |
| 11:45 | <annevk> | Though they've been reviewed before. |
| 11:46 | <Ms2ger> | At Opera, or? |
| 11:46 | <annevk> | And there's some issues with the auth-related tests. |
| 11:46 | <annevk> | Ms2ger: yeah, though also by WebApps at times, it's been through a lot of iteration |
| 11:48 | <Ms2ger> | darobin, do you remember what policy we ended up with in the thread about internally-reviewed tests? |
| 11:50 | <annevk> | ooh, the <link rel=help> stuff is no good |
| 11:52 | <annevk> | dunno have someone else look at that I suppose |
| 11:53 | <annevk> | ooh man that thing generates email |
| 11:54 | <annevk> | lunch |
| 12:04 | <darobin> | Ms2ger: IIRC we said anyone could review the tests except the person who wrote them |
| 12:13 | <hsivonen> | for an interesting way of speccing things, check out the character-based limits on UTF-8 data in http://tools.ietf.org/html/rfc5389#section-15.7 |
| 12:46 | <annevk> | ooh that's the WebRTC stuff |
| 12:46 | <annevk> | I wonder why there's so much more complexity than before |
| 12:47 | Ms2ger | blames Google |
| 13:11 | <hsivonen> | annevk: a big factor in the complexity is the use of UDP and the UDP-hostility of middle boxes |
| 13:54 | <gsnedders> | Anyone got AAA swapped in? Give an example that hits the "…but the element is not in scope" case in step 4? |
| 14:46 | <darobin> | 'Since there are so many opportunities for the UA to just say "fuck it"' -- I love it when annevk gets technical |
| 14:48 | <annevk> | heh |
| 14:50 | <hsivonen> | darobin: context? |
| 14:50 | <darobin> | http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0017.html |
| 14:56 | <hsivonen> | SimonSapin: did you have a Rust impl of the Encoding Standard? |
| 14:56 | <hsivonen> | SimonSapin: someone's asking about converters on rust-dev |
| 14:57 | <SimonSapin> | hsivonen: not really, yet |
| 14:58 | <SimonSapin> | I have something very incomplete, that I wouldn’t recommend anybody uses |
| 14:58 | <gsnedders> | I'm confused, why is cover (in Python) not picking up code-coverage of html5lib.treebuilders.dom? It's definitely running! |
| 14:59 | <annevk> | hsivonen: if you're on that list can you email a pointer to the Encoding Standard? so we'll get the right thing implemented |
| 14:59 | <SimonSapin> | I’ll do it |
| 15:04 | <dglazkov> | good morning, Whatwg! |
| 15:10 | <hsivonen> | SimonSapin: thanks |
| 15:23 | <SimonSapin> | annevk, hsivonen: sent. https://mail.mozilla.org/pipermail/rust-dev/2013-April/003575.html |
| 15:24 | <annevk> | yeah I don't think we'd ever want that separate API |
| 15:25 | <annevk> | furthering bullshit encodings should be a non-goal |
| 15:26 | <SimonSapin> | annevk: My point is: if someone wants UTF-32 in a Rust libstd, unrelated to the web, is should be separated to what eg. Servo will use |
| 16:04 | <SimonSapin> | It’s unfortunate that 'green' is rgb(0, 128, 0) rather than rgb(0%, 50%, 0%) |
| 16:05 | <SimonSapin> | (128 being 0.50196%, because 100% is 255, not 256.) |
| 16:05 | <SimonSapin> | makes testing suck |
| 16:15 | <annevk> | jgraham: so what did you change in that review? |
| 16:15 | <annevk> | jgraham: I find critic so incomprehensible |
| 16:18 | <jgraham> | I marked the deleted files as reviewed |
| 16:18 | <jgraham> | If you reviewed the other files you should tick next to the ones that you reviewed (even if there were issues, as long as you finished marking all the issues) |
| 16:18 | <jgraham> | and press submit |
| 16:19 | <annevk> | tick where? |
| 16:20 | <jgraham> | https://critic.hoppipolla.co.uk/33e7bba0?review=29 under where it says "Reviewed" |
| 16:20 | <jgraham> | (to the left of the file names) |
| 16:21 | <annevk> | no effect |
| 16:23 | <annevk> | http://www.w3.org/TR/2013/WD-mediaont-api-1.0-20130411/#example-in-javascript-23 are you fucking kidding me? |
| 16:23 | <annevk> | this API is sooo bad :-( |
| 16:23 | <jgraham> | annevk: Oh, you marked yourself as a watcher on the review. To review stuff you need to be a reviewer |
| 16:23 | <annevk> | I did not do shit |
| 16:23 | <jgraham> | I added you as one for this review, but you should adjust your filters |
| 16:23 | <annevk> | I just followed some links |
| 16:24 | <jgraham> | Oh, well maybe commenting auto-adds you as a watcher |
| 16:24 | <jgraham> | Anyway you are now a reviewer |
| 16:24 | <jgraham> | For that review |
| 16:25 | <annevk> | I see, thanks |
| 16:25 | <jgraham> | To fix in general go to https://critic.hoppipolla.co.uk/home?repository=10 and click "Add Filter" at the bottom of the page. |
| 16:25 | <jgraham> | You probably want to review / |
| 16:25 | <jgraham> | (i.e. everything) |
| 16:27 | <annevk> | I have to say though, this is an interesting thing |
| 16:27 | <annevk> | Maybe at some point we can use this for specs, once we have enough people to write them |
| 16:29 | <annevk> | lol |
| 16:29 | <annevk> | "save settings" goes so fast and there's no delay on the dialog displayed |
| 16:29 | <annevk> | so it looks more like corruption than success |
| 16:50 | <jgraham> | annevk: That spec has the word "Ontology" in the introduction. That's not so much a red flag as a blaring siren, and a crush of people screaming "danger, get out while you still can" |
| 16:54 | <annevk> | but it also defines an API for getting data out of objects |
| 16:54 | <annevk> | I guess I'm wondering if this is something we want to implement |
| 16:54 | <annevk> | one browser guy |
| 16:54 | <annevk> | kinda |
| 16:55 | <TabAtkins> | I don't understand the rationale behind making this async. |
| 16:55 | <TabAtkins> | It doesn't appear that there's anything that would cause delay, I think? |
| 16:55 | <annevk> | plus a bunch of university people who by the looks of their API design never made a site |
| 16:55 | <annevk> | TabAtkins: it's IO |
| 16:55 | <annevk> | TabAtkins: so that makes sense, but it should be futures |
| 16:55 | <TabAtkins> | annevk: Ah, file IO, gotcha. |
| 16:55 | <TabAtkins> | annevk: In that case, yeah, definitely. |
| 16:55 | <TabAtkins> | Though this was written before Futures. |
| 16:56 | <annevk> | but the return value needs to be cleaned up |
| 16:56 | <annevk> | that seems much more disheartening than anything else there |
| 16:56 | <TabAtkins> | Also: awgoddammit they use, not even named class constants, but just straight-up *numbers* to identify modes in MediaResource#getSupportedModes() |
| 16:58 | <TabAtkins> | I could go through and do an API rewrite if anyone thinks it's something that might be valuable to implement. |
| 16:59 | <TabAtkins> | annevk: While you're here, let me bounce a ProgressFuture idea off of you. |
| 17:00 | <TabAtkins> | I suspect that a decent fraction of ProgressFuture users will want to use the progress events for things like showing UI (depending on exactly what it is, of course). |
| 17:00 | <annevk> | TabAtkins: so I think people have suggested better EXIF-like APIs already, I just wonder where those went; emailed webapps about it now |
| 17:00 | <TabAtkins> | This kind of thing benefits from knowing the current state of the progress at the time it registers, in addition to listening for future progress updates. |
| 17:01 | <Ms2ger> | Gecko supports media.mozGetMetadata() |
| 17:01 | <TabAtkins> | In other words, it seems like the progress updates themselves could be useful in a future-like way, where you get informed of the latest "completed" progress. |
| 17:01 | <annevk> | Ms2ger: maybe reply in that thread with a pointer? |
| 17:02 | <TabAtkins> | Idea: rather than just registering a callback with .progress(), also allow registering an object with number keys in [0,1] and callback values. ProgressFuture gains, in addition to (or instead of?) the explicit progress value, a progress number from [0,1]. |
| 17:03 | <TabAtkins> | Or, wait, I just realized the API I'm suggesting is a bad idea. |
| 17:03 | <annevk> | the progress callback will just be passed an object with the data |
| 17:04 | <annevk> | with which you can do everything |
| 17:04 | <TabAtkins> | Instead! ProgressFuture gains a progress number, from [0,1]. If you register for .progress(), it gets called immediately (next tick) with the current progress number. |
| 17:04 | <TabAtkins> | annevk: Problem with current spec is that you have to wait for the next resolver.progress() update. |
| 17:04 | <Ms2ger> | annevk, fwiw, the FormData test may be a joke, but it used to fail in Gecko :) |
| 17:05 | <annevk> | Ms2ger: Gecko is a joke :p |
| 17:05 | <annevk> | oh wait |
| 17:05 | <Ms2ger> | annevk, indeed so :) |
| 17:05 | <Ms2ger> | Do we have an easy way to test FormData? |
| 17:05 | <annevk> | TabAtkins: that seems like an impl detail |
| 17:06 | <jgraham> | annevk: Marking things as reviewed when they still have issues as a slightly non-obvious part of the critic model. "I've reviewed this" doesn't mean "I think this is OK". |
| 17:06 | <TabAtkins> | annevk: I... don't think it is? The spec seems clear so far that the future's progress callbacks are called whenever the resolver posts a progress update. |
| 17:06 | <annevk> | TabAtkins: we can spec that the first thing .progress() does is have resolver.progress() queue something (unless the future is already complete in which case that does not make much sense I think) |
| 17:06 | <TabAtkins> | Right, so that's a spec detail, not an impl detail. ^_^ |
| 17:06 | <TabAtkins> | That would work. |
| 17:06 | <jgraham> | So you don't really need to add a comment pointing out that your other comments need to be addressed; that's just the normal workflow |
| 17:07 | <TabAtkins> | And yes, if the future is complete, no progress callback. We should also just entirely turn off progress updates after it's resolved. |
| 17:07 | <annevk> | TabAtkins: with "impl" I meant we might want to make it depend on where we are using it |
| 17:07 | <TabAtkins> | annevk: Hm, I doubt there's a case where you're registering for progress updates and *don't* want to know what the current progress is. |
| 17:08 | <annevk> | I sometimes say "impl" if e.g. HTML uses URL, HTML has an impl of the URL stuff I wrote |
| 17:08 | <annevk> | TabAtkins: fair |
| 17:08 | <annevk> | TabAtkins: I'm also leaning towards the .then(success,reject,progress) model |
| 17:08 | <annevk> | but maybe starting with .progress is sufficient |
| 17:08 | <TabAtkins> | Interesting. I'm fine with the current model, given chaining. |
| 17:09 | <annevk> | with the current model you might do the wrong thing if you first do .then() |
| 17:09 | <TabAtkins> | Really? |
| 17:09 | <annevk> | there's no way to get back to the future you .then()d on |
| 17:09 | <annevk> | if you're chaining |
| 17:09 | <TabAtkins> | Oh! |
| 17:09 | <TabAtkins> | Right. |
| 17:09 | <TabAtkins> | I forgot that .then() returns a new future. |
| 17:15 | <annevk> | Ms2ger: is there any documentation on this mozGetMedia thing? |
| 17:15 | <Ms2ger> | http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/html/nsIDOMHTMLMediaElement.idl#97 |
| 17:16 | <annevk> | just found that |
| 17:16 | <annevk> | so that's sync |
| 17:17 | <annevk> | I guess we cache stuff |
| 17:17 | <annevk> | and it seems our approach is to just expose whatever if we support the storage format |
| 17:17 | <annevk> | hmm |
| 17:20 | <TabAtkins> | annevk: btw, good work on upgrading the futures spec. It's more readable now, though I think I can still contribute. |
| 17:21 | <annevk> | Can we still change fullscreen? |
| 17:22 | <TabAtkins> | annevk: Also, I'd love to define the fetching model for CSS. The thread on filter-effects has a confusing amount of detail, though. |
| 17:22 | <TabAtkins> | So, any help would be appreciated. |
| 17:22 | <annevk> | hopefully by end of Q2 http://fetch.spec.whatwg.org/ is roughly done |
| 17:22 | <TabAtkins> | So I should wait on that? |
| 17:23 | <annevk> | well the general model is in place so we can start thinking about it |
| 17:23 | <annevk> | up to you |
| 17:24 | <TabAtkins> | Ok, if I have time in the near future I'll look through it. |
| 17:24 | <annevk> | okay so Mozilla does not expose Fullscreen unprefixed |
| 17:24 | <TabAtkins> | On an unrelated note, if we change ProgressFuture as discussed here, I think that concept should be reified somewhere, as it's a useful Event alternative in some cases. |
| 17:25 | <gsnedders> | jgraham: So what is the commit policy now for html5lib? |
| 17:25 | <TabAtkins> | "that concept" being "callback called multiple times, but also called as soon as you register with the latest data". |
| 17:25 | <annevk> | WebKit is prefixed too |
| 17:25 | <TabAtkins> | In which case, going with the 3-arg .then() might be a good idea. |
| 17:25 | <annevk> | fuck yeah futures |
| 17:26 | <TabAtkins> | It may or may not ever actually complete. |
| 17:26 | <TabAtkins> | Depending on the exact usage. |
| 17:26 | <jgraham> | gsnedders: I won't cry if you make comemnt cleanups without getting review |
| 17:26 | <jgraham> | But maybe larger changes should have code review |
| 17:27 | <jgraham> | We could see how it works at least, now we have a tool that doesn't entirely suck |
| 17:28 | <annevk> | TabAtkins: yes, we'll make it part of the contract |
| 17:29 | <annevk> | TabAtkins: if you do ProgressFuture, you need to have progress data available next to having a result available |
| 17:29 | <TabAtkins> | annevk: I'm compiling a blog post of scenarios and which callback mechanism to use to solve them, so I'll put it in there. |
| 17:29 | <annevk> | TabAtkins: and at some point progress data becomes null and result becomes non-null |
| 17:30 | <TabAtkins> | Yes, for ProgressFuture that's definitely what happens. |
| 17:30 | <TabAtkins> | But I can easily see a Future that doesnt' ever complete, but only gives "progress" updates, where "progress" is just any value. |
| 17:31 | <TabAtkins> | This would let us wipe out the last events from Font Load Events, and do it *better* than the events currently do, to boot. |
| 17:31 | <annevk> | oops |
| 17:31 | <annevk> | one problem with using futures for requestFullscreen is that subdocuments would no longer be modified |
| 17:31 | <annevk> | which seems bad |
| 17:32 | <annevk> | but we could have both |
| 17:32 | <annevk> | in this case |
| 17:32 | <annevk> | and get rid of fullscreenerror |
| 17:36 | <TabAtkins> | Hixie: I didn't realize that w() had a special printing mode for when you pass in events. Nice! |
| 17:49 | <TabAtkins> | annevk: Also, are you following the monadic-promises discussion that's happening on the promises-aplus github? |
| 17:50 | <annevk> | I saw some of it come by |
| 17:56 | <TabAtkins> | You wouldn't need to add much to make it happen, and the most important bit - making a "basic" future out of a static value, with something like Future#of - is useful by itself. |
| 17:56 | <TabAtkins> | It lets you, frex, intermix a static value with other futures in the futures combinators. |
| 17:56 | <annevk> | you can already do that |
| 17:57 | <annevk> | Future.any(future, "test") works |
| 18:02 | <Ms2ger> | annevk, seriously though... How do you test FormData? |
| 18:03 | <annevk> | Ms2ger: Microsoft managed :p |
| 18:03 | <Ms2ger> | annevk, ouch :( |
| 18:03 | <annevk> | Ms2ger: you have to push it over the network basically at the moment |
| 18:03 | <annevk> | Ms2ger: apart from the IDL trickery one can do |
| 18:04 | <annevk> | Eventually it might grow to be more like URLQuery |
| 18:04 | <TabAtkins> | annevk: Hm, that means that you can't easily make a future that returns a future as its completion value, no? Because you end up having to ducktype it? |
| 18:05 | <annevk> | TabAtkins: accept() can be used if you want that |
| 18:07 | <Ms2ger> | annevk, tell me more about this IDL trickery |
| 18:07 | <annevk> | Ms2ger: the kind of tests you wrote for ProgressEvent |
| 18:08 | <TabAtkins> | annevk: You mean just doing "new Future(function(r){r.accept(<static value>);})? |
| 18:08 | <annevk> | TabAtkins: what is static value? |
| 18:08 | <TabAtkins> | annevk: Whatever value you want to upgrade into a promise. You already have it, but you want it to interact with the promise algebra. |
| 18:08 | <TabAtkins> | s/promise/future/ |
| 18:09 | <annevk> | if that value needs to be able to be a future, yes |
| 18:09 | <annevk> | I think the general pattern is using .resolve() though |
| 18:10 | <TabAtkins> | So, Future.of(<static value>) sounds like a much more convenient way to do that. ^_^ |
| 18:12 | <annevk> | could you explain the scenario though where .resolve() is not okay? |
| 18:12 | <annevk> | on www-dom perhaps |
| 18:22 | <TabAtkins> | Are you referring to the code I posted above (but with .resolve instead of .accept)? |
| 18:29 | arunranga | wonders if making Blob URLs cross origin will clean up the data: URL morass |
| 18:30 | <arunranga> | For some reason changing this in the spec feels dangerous. |
| 18:32 | <annevk> | TabAtkins: just in general I guess |
| 18:33 | <annevk> | arunranga: so what needs to happen is that we need to decide how the blob URL lifecycle works |
| 18:33 | <annevk> | arunranga: I don't think it's dangerous, as the URL is secret (unguessable) |
| 18:34 | <annevk> | arunranga: the problem is the lifecycle, but that's a problem either way :( |
| 18:57 | <arunranga> | annevk, we've struggled with lifecycle for what seems like a long time now :( seems like autoRevoke is no silver bullet |
| 19:07 | <Hixie> | annevk: ah, if you were intentionally not having me update the spec then nevermind :-) |
| 19:07 | <Hixie> | annevk: it does sound vaguely familiar now that you mention it |
| 19:07 | <Hixie> | TabAtkins: :-) |
| 19:13 | <gsnedders> | So, chardet on PyPi doesn't support Python 3 doesn't Mark having had a chapter in Dive Into Python 3 on getting it working on Python 3. Yay. |
| 19:27 | <Ms2ger> | gsnedders, ... eh? |
| 19:29 | <gsnedders> | Ms2ger: What's eh about that. Mark Pilgrim, author of chardet, wrote a chapter on porting chardet to Python 3. He never made a release of chardet supporting Python 3. |
| 19:29 | <Ms2ger> | s/doesn't/despite/, or? |
| 19:30 | <gsnedders> | Yes. |
| 19:31 | <Ms2ger> | That does make more sense |
| 19:33 | <annevk> | seems he is online, you could ask him about it |
| 19:34 | <gsnedders> | On the other hand, he has basically abandoned all of that stuff. |
| 19:35 | <annevk> | Hixie: cannot find the HTMLImageElement.src compat bug |
| 19:36 | <annevk> | Hixie: did not know about IE doing "null" either |
| 19:43 | <annevk> | Hixie: found it https://bugzilla.mozilla.org/show_bug.cgi?id=859640 |
| 20:21 | <zcorpan> | TabAtkins: the pseudo algorithm in multicol, is it supposed to be normative? |
| 20:47 | <TabAtkins> | zcorpan: Yes, but it's under heavy discussion. See recent mailing list stuff. |
| 20:51 | <zcorpan> | i think i'll wait until the edits have been made and then look at it again |
| 20:52 | <zcorpan> | i didn't read it carefully but my knee-jerk reaction was that things could be interpreted in several ways, or that the pseudo-code was ambiguous |
| 20:52 | <zcorpan> | i'm not a fan of normative pseudo-code |
| 20:58 | <TabAtkins> | The pseudo-code *is* ambiguous right now, which is the biggest part of the discussion. |
| 20:58 | <TabAtkins> | SimonSapin is trying to get it fixed. |
| 20:59 | <zcorpan> | excellent |
| 20:59 | <SimonSapin> | zcorpan: I think that the edits in the attachment here capture what we discussed: http://lists.w3.org/Archives/Public/www-style/2013Apr/0225.html |
| 21:04 | <zcorpan> | SimonSapin: ah, didn't notice the attachment. that looks better |
| 21:04 | <zcorpan> | SimonSapin: the first two lines could be removed as well? |
| 21:04 | <SimonSapin> | zcorpan: yeah I guess |
| 21:05 | <SimonSapin> | but getting this much has been hard enough :/ |
| 21:46 | <SimonSapin> | annevk: (if you read logs) not sure what to say to that: https://mail.mozilla.org/pipermail/rust-dev/2013-April/003579.html |
| 22:21 | <Hixie> | heycam: i'm assigning https://www.w3.org/Bugs/Public/show_bug.cgi?id=21591 to you, let me know if you disagree (reassign it to me and i'll do it the other way) |
| 22:22 | <heycam> | Hixie, sounds good, I'll allow string constants |
| 22:23 | heycam | 's public-script-coord folder is coming up on 1000 unread messages, so he promises to look at it next week |
| 22:23 | <heycam> | (the folder that is) |
| 22:23 | <heycam> | s/promises/futures/ |
| 22:24 | <arv> | heycam: Also, https://bugs.webkit.org/show_bug.cgi?id=114457 |
| 22:24 | heycam | looks |
| 22:26 | <Hixie> | heycam: cool, thanks. I'm also giving you https://www.w3.org/Bugs/Public/show_bug.cgi?id=21589; again, feel free to reassign it to me (request to allow trailing commas on enum definitions) |
| 22:27 | <heycam> | ok |
| 22:27 | <Hixie> | (neither is a high priority) |
| 22:29 | <Hixie> | wtf is https://www.w3.org/Bugs/Public/show_bug.cgi?id=21576 about |
| 22:29 | <Hixie> | i'm pretty sure the spec doesn't have that ID |
| 22:30 | <Hixie> | ah, an extension is to blame |