| 00:04 | <heycam> | annevk, Domenic_, anything I need to change in IDL? |
| 00:04 | <Domenic_> | heycam: It sounds like Promise.cast will get renamed to Promise.resolve |
| 00:04 | <heycam> | Domenic_, ok |
| 00:04 | <heycam> | Domenic_, in the next ES6 draft I guess? |
| 00:05 | <Domenic_> | heycam: yeah |
| 00:05 | <heycam> | Domenic_, ok cool |
| 01:30 | <dominiquenf> | good evening |
| 08:42 | <zcorpan> | is http://www.khronos.org/registry/typedarray/specs/latest/ the current spec for typed arrays or has it moved to ES land? |
| 08:43 | zcorpan | finds https://people.mozilla.org/~jorendorff/es6-draft.html#sec-typedarray-objects |
| 09:02 | <zcorpan> | yoav: yeah so long as the black-box observable behavior is equivalent it can be implemented in any way |
| 09:02 | <yoav> | zcorpan: I agree in 100% |
| 09:04 | <zcorpan> | yoav: what do you think this should do? <!doctype html><div id=x><script>x.remove();</script><img src=foo onload=alert(1)> |
| 09:04 | <zcorpan> | yoav: (the img will be inserted into the removed div by the parser) |
| 09:05 | <yoav> | I think that the src should be triggered as soon as the img is inserted (even if the div is removed) |
| 09:05 | <yoav> | The only reason we need to wait, is to see if the parent is picture |
| 09:05 | <yoav> | But I completely agree that this area should be well specified, and currently it isn't |
| 09:07 | <zcorpan> | ok, then it's different to "inserted to the document" |
| 09:07 | <zcorpan> | i'm pondering if i should take a stab at specifying this |
| 09:11 | <yoav> | zcorpan: If you're willing, it'd be highly appreciated |
| 09:13 | <zcorpan> | yoav: do i get any chocolate? :-) |
| 09:14 | <yoav> | zcorpan: I'll see what I can do :) |
| 09:15 | <zcorpan> | hehe |
| 09:16 | <Ms2ger> | Dammit |
| 09:48 | <yoav> | zcorpan: The plot thickens... |
| 09:54 | <zcorpan> | yoav: btw downloading immediately in the script case is wrong per spec already even without <picture>, since there's crossorigin and srcset. the spec requires to await a stable state |
| 09:56 | <yoav> | zcorpan: HTMLImageElement can tell if it *already* contains such attributes when 'src' is encountered |
| 09:56 | <yoav> | It cannot tell what it parent is |
| 09:56 | <yoav> | I don't know how "stable state" is defined |
| 09:57 | <zcorpan> | yoav: it basically means to let the script finish |
| 09:57 | <yoav> | OK |
| 09:57 | <zcorpan> | yoav: so that it doesn't matter in which order you set src and crossorigin in a script |
| 09:58 | <yoav> | I think that in practice it does... |
| 09:58 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data step 8 |
| 09:58 | <zcorpan> | if it does it's a bug |
| 09:58 | <yoav> | Interesting |
| 09:58 | <yoav> | Can you comment that on the blink-dev discussion? |
| 09:59 | <zcorpan> | sure |
| 09:59 | <yoav> | Practically, it means that an HTML parser script just has to add the image to its parent before terminating |
| 10:02 | <zcorpan> | the spec says to await a stable state for the html parser case too, which means to wait until the parser yeilds to the event loop, however that's not technically necessary i think since the html parser sets all attributes at the same time as creating the element (this might not match impl reality though) |
| 10:03 | <yoav> | zcorpan: Yeah, current parser (at least Blink/WebKit) sets all the attributes upon creation |
| 10:34 | <hsivonen> | annevk-cloud: FYI: https://groups.google.com/forum/#!topic/mozilla.dev.l10n/PH7tF9m8vUY (encouraging a UTF-8 default for outgoing email) |
| 10:43 | <MikeSmith> | hsivonen: about Client Hints, was wondering why you were asking earlier if howcome had an opinion on it. You think he'd not be favorable? |
| 10:43 | <Ms2ger> | CH CH |
| 10:44 | <Ms2ger> | Client Hints Considered Harmful |
| 10:51 | <hsivonen> | MikeSmith: When I read about CSS Regions Considered Harmful, some of the arguments seemed applicable to Client Hints. |
| 10:53 | <MikeSmith> | ah ok |
| 10:57 | <zcorpan> | hsivonen: which arguments? problem #2 ? |
| 11:07 | <hsivonen> | zcorpan: yes |
| 11:09 | <zcorpan> | from what i understand, CH doesn't intend to solve art direction but leaves that to <picture>. however if the user zooms it seems reasonable that the browser should reload the image, dunno what the I-D says about that |
| 11:11 | <hsivonen> | zcorpan: and if you use CH on HTML resources, does it mean a reasonable browser becomes Netscape 4.x when resizing the window (includes rotation on mobile)? |
| 11:12 | <zcorpan> | does CH apply to any resource? i was under the impression it was only for <img> requests (though i haven't read the spec) |
| 11:12 | <hsivonen> | when I argued it was about images, karl said it's not just about images |
| 11:12 | <hsivonen> | I don't recall anything in the spec restricting it to images |
| 11:12 | <zcorpan> | hsivonen: the DPR doesn't change when you resize the window though |
| 11:13 | <hsivonen> | also, sicking argued for a non-image case |
| 11:13 | <hsivonen> | zcorpan: width does |
| 11:39 | <zcorpan> | hsivonen: how? |
| 11:43 | <hsivonen> | zcorpan: resizing the window changes the width of the view port |
| 11:43 | <zcorpan> | hsivonen: the width of the viewport doesn't affect DPR |
| 11:44 | <hsivonen> | zcorpan: DPR isn't the only kind of client hint |
| 11:44 | <hsivonen> | zcorpan: there's another one for width |
| 11:44 | <zcorpan> | ah, ok |
| 11:44 | <hsivonen> | zcorpan: though the spec isn't really clear on the width of what exactly |
| 11:45 | <hsivonen> | see https://bugzilla.mozilla.org/show_bug.cgi?id=935216#c20 |
| 11:48 | <zcorpan> | the width hint seems like a bad idea to me |
| 11:49 | <hsivonen> | zcorpan: both client hints seem like bad ideas to me |
| 14:00 | <zcorpan> | jgraham: why doesn't test(function(t) { }) have the test object as the argument (t is undefined)? |
| 14:15 | <jgraham> | zcorpan: I don't think there's any particular reason. |
| 14:15 | <jgraham> | It's not really clear what the use case is, I guess |
| 14:15 | <zcorpan> | t.add_cleanup |
| 14:15 | <jgraham> | Oh, yeah so I guess with that there is a use case |
| 14:17 | <jgraham> | zcorpan: Want to make a patch? You just need to change the call to test_obj.step() in function test(){} to look like the one in function async_test(){} |
| 14:17 | <jgraham> | i.e. add tet_obj, test_obj as arrguments |
| 14:17 | <zcorpan> | yeah sure, but will have to wait until monday |
| 14:17 | <jgraham> | although I am slightly worried that will make the this object different |
| 14:18 | <jgraham> | Dunno if undefined, this_obj would be a better bet |
| 14:20 | <zcorpan> | is that a problem for async_test? what is this_obj here? |
| 14:21 | <zcorpan> | isn't test_obj the this object for both test and async_test now? |
| 14:22 | <jgraham> | I think in test() it's the global |
| 14:23 | <jgraham> | Oh, no |
| 14:23 | <jgraham> | the code is just strange |
| 14:23 | <jgraham> | OK, patch should be quite sae then |
| 14:23 | <jgraham> | *dafe |
| 14:23 | <jgraham> | *safe |
| 14:23 | <jgraham> | Christ |
| 14:24 | <zcorpan> | why does async_test run step with three arguments? the function only takes two arguments? |
| 14:25 | <zcorpan> | oh wait |
| 14:25 | <zcorpan> | nm |
| 14:26 | <zcorpan> | yeah so it's just adding ", test_obj, test_obj" |
| 14:26 | <jgraham> | Yeah, the first argument is the callback, the second is the this to use and any remaining arguments are the parameters to pass to the callback |
| 14:33 | zcorpan | *poof* |
| 15:17 | <mathiasbynens> | https://twitter.com/RobbertAtWork/status/429271270052872193 — “<svg> elements in <template> won't work: they're parsed in the HTML namespace. We're gonna need XML to do this template thing properly.” |
| 15:25 | <MikeSmith> | oh boy |
| 15:27 | <MikeSmith> | well that seems intead like a very good argument for us to change to parsing all SVG using the HTML parser instead of the XML parser |
| 15:27 | <stockwell> | I'd like to help by writing some test cases. What's the process for doing that? |
| 15:28 | <MikeSmith> | stockwell: https://github.com/w3c/web-platform-tests/blob/master/README.md#contributing |
| 15:29 | <stockwell> | <MikeSmith> thank you |
| 15:33 | <gsnedders> | Is there any ETA for ES6 being basically done? |
| 16:04 | <Domenic_> | gsnedders: http://esdiscuss.org/topic/es6-timetable-and-current-status |
| 16:07 | <gsnedders> | Domenic_: Braw. |
| 16:08 | gsnedders | remembers this is #whatwg and en-gb is probably better than sco. |
| 16:08 | <gsnedders> | so, uh, thanks. |
| 16:09 | <Domenic_> | np :P |
| 16:18 | <MikeSmith> | Domenic_: so what was the recent big change to Promises? the .cast -> .resolve change? |
| 16:19 | <Domenic_> | MikeSmith: yeah. "big" was overstating it from an API perspective |
| 16:19 | <MikeSmith> | ah OK |
| 16:19 | <Domenic_> | it is kind of big behind the scenes because some planned ES7 changes that some people wanted were decided against. |
| 16:19 | <MikeSmith> | oh |
| 16:19 | <Domenic_> | which allows simplification of the internal model |
| 16:19 | <Domenic_> | (fairly drastic simplication) |
| 16:19 | <MikeSmith> | aha |
| 16:20 | <Domenic_> | but from an actual consumer POV the only change is that .cast becomes .resolve and resolve dies |
| 16:20 | <MikeSmith> | well the behind-the-scenes change sounds like a very good thing |
| 16:21 | <MikeSmith> | because simpler usually being better |
| 16:21 | <MikeSmith> | and drastically simpler especially so |
| 16:28 | <Domenic_> | indeed, i am quite happy |
| 16:29 | <MikeSmith> | cool |
| 16:30 | <MikeSmith> | jgraham: somebody should come up with a way we can track data about test cases that have resulted in spec bugs being found |
| 16:32 | <MikeSmith> | (in context of https://critic.hoppipolla.co.uk/showcomment?chain=1646 -- see the last comment from Ms2ger) |
| 16:32 | <MikeSmith> | (and bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=24404) |
| 16:33 | <jgraham> | MikeSmith: Yeah. We should track many things that we can't / don't |
| 16:34 | <MikeSmith> | yeah I know |
| 16:34 | <jgraham> | But I agree that makes the list |
| 16:34 | <MikeSmith> | that's why I was suggesting assigning it to the "somebody", who seems to have infinite time |
| 16:34 | <jgraham> | :) |
| 16:34 | <MikeSmith> | yay |
| 17:29 | <reyre> | foolip: ping |
| 17:43 | <annevk> | Man, for a moment I thought the microtask discussion was over |
| 17:52 | <annevk> | I wish I could answer the range question without doing a bunch of research |
| 17:53 | <Hixie> | hsivonen: you around? |
| 17:54 | <Hixie> | hsivonen: haven't heard your opinion of the UI proposals in my registry e-mail, would love to have your feedback |
| 18:05 | <dglazkov> | good morning, Whatwg! |
| 18:18 | <Hixie> | why do dictionaries have constructors? |
| 18:33 | <MikeSmith> | Hixie: I'd also like to hear what hsivonen is thinking on that |
| 18:34 | <MikeSmith> | in the mean time I will try to write up a reply myself this weekend |
| 18:35 | <annevk-cloud> | Hixie: they do? Sounds weird, although they can be returned they do not have exposed names |
| 18:35 | <Hixie> | if they have a constructor the name is exposed |
| 18:35 | <Domenic_> | are there examples of ones with constructors? seems bad |
| 18:37 | <Hixie> | well i assume there was some use case... |
| 18:37 | <Hixie> | i'm just curious what it was |
| 19:43 | <MikeSmith> | somebody recommended a good IRC client for OSX here the other day |
| 19:43 | <MikeSmith> | a newer one, not Colloquy |
| 19:43 | <MikeSmith> | I didn't pay attention at the time because I didn't care because I just irssi and screen |
| 19:44 | <MikeSmith> | but now I'm trying to help somebody get set up with IRC so now I care, so maybe can somebody remind me what the name was? |
| 19:45 | <MikeSmith> | Textual? |
| 20:04 | <Ms2ger> | Hixie, I thought the constructors for dictionaries was for points or something, but http://dev.w3.org/fxtf/geometry/ has those as interfaces |
| 20:55 | <sicking> | Hixie: shouldn't BroadcastChannel inherit EventTarget? |
| 21:24 | <Hixie> | sicking: sounds plausible |
| 21:25 | <sicking> | Hixie: event dispatch won't work otherwise |
| 21:25 | <Hixie> | sicking: fixed, reload in a minute or so |
| 21:25 | <sicking> | thanks |
| 21:25 | <Hixie> | np, thanks for catching it |
| 21:42 | <annevk> | MikeSmith: LimeChat is nice |
| 21:42 | <MikeSmith> | annevk: OK thanks |
| 21:43 | <MikeSmith> | I think Textual is based on LimeChat originally |
| 21:43 | <Domenic_> | still a big fan of irccloud |
| 21:44 | jgraham | doesn't understand why you would move off irssi |
| 21:44 | <jgraham> | Oh,for someone else |
| 21:45 | <jgraham> | Fair enough |
| 21:47 | <Hixie> | i'm likely to work on the web focus model refactoring soon so if people have comments on my proposal, now's the time https://www.w3.org/Bugs/Public/show_bug.cgi?id=23475 |
| 23:27 | <Hixie> | jgraham: the bug thing still seems out of date? |
| 23:29 | <Hixie> | jgraham: yeah, i get a 500 when i do an update request |
| 23:46 | <annevk> | I might have comments on how focus works a couple of years from now |
| 23:46 | <Hixie> | heh |
| 23:46 | <annevk> | When I have time to learn about UI events :-P |
| 23:46 | <Hixie> | hopefully it'll be a solved issue by then. |
| 23:46 | <Hixie> | the focus part, that is |
| 23:46 | <Hixie> | UI events won't be |