| 01:00 | <cabanier> | promises promises |
| 01:02 | <terinjokes> | i have a joke about promises |
| 07:15 | <hober> | Hixie_: just do it a sensible way and if that doesn't match the API fashion of the month, so be it |
| 07:17 | <TabAtkins> | hober: That's a great way to get implementors to willfully violate the spec, which is exactly what they've publicly said they'd do if Hixie did try and do a hack around WebIDL. |
| 07:28 | <annevk> | If that happens Hixie_ will change the spec, so nobody loses? |
| 07:29 | <hober> | annevk: indeed |
| 07:39 | <TabAtkins> | Well, Hixie loses, because he has to edit twice, and implementors lose, because they have to violate the spec in an undefined way to get sane behavior; forcing implementors to violate the spec because the author doesn't agree with everyone else also just generally lowers respect without any benefit. |
| 08:09 | <annevk> | http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html is this still the case? |
| 09:36 | <Ms2ger> | annevk, http://wiki.whatwg.org/wiki/TR_strikes_again |
| 09:41 | <astearns> | the fullscreen/dialog entry on that page doesn't specify a particular problem, as far as I can tell |
| 09:42 | <annevk> | astearns: I think what it's trying to state is that it's very hard to determine what the latest state of a particular piece of layout is |
| 09:42 | <annevk> | astearns: e.g. if I were to implement a new box creation algorithm, where do I look? |
| 09:43 | <annevk> | astearns: or if I implemented stacking contexts, how do I learn about http://fullscreen.spec.whatwg.org/#new-stacking-layer |
| 09:43 | <annevk> | astearns: CSS is still a rather monkey patched landscape |
| 09:44 | <astearns> | that's a fair point, but the other links are to specific instances of harm, not general difficulties that might someday result in a problem |
| 09:45 | <astearns> | and your point is more about CSS modularization than TR publication |
| 09:48 | <annevk> | I don't disagree, I didn't create that page |
| 09:49 | <annevk> | It could perhaps be reframed a bit better |
| 09:49 | <annevk> | Perhaps we should turn it into a page like http://wiki.whatwg.org/wiki/IETF |
| 09:49 | <annevk> | Ms2ger: ^ |
| 10:32 | hsivonen | hopes setting .innerHTML on annotation-xml doesn't depend on the attributes of the annotation-xml node |
| 10:32 | hsivonen | goes read the spec |
| 10:40 | <hsivonen> | sigh. innerHTML now depends on the attributes of the context node |
| 10:40 | <hsivonen> | hooray for annotation-xml |
| 10:45 | <annevk> | Can't we just drop support for annotation-xml? |
| 11:15 | <ondras> | sooo |
| 11:15 | <ondras> | <input> elements inside a shadow dom |
| 11:15 | <ondras> | are they considered when submitting a form? |
| 11:16 | <hsivonen> | annevk: I think that would be a bit drastic and rather bait-and-switchy towards the math folks |
| 11:44 | <TabAtkins> | ondras: They are not, afaik. |
| 11:49 | <ondras> | TabAtkins: okay |
| 11:52 | <zcorpan> | hsivonen: can we make the spec more stupid for innerHTML on annotation-xml? is there a use case for innerHTML on annotation-xml that needs to look at the attribute? |
| 12:00 | <hsivonen> | zcorpan: I don't know |
| 12:00 | <hsivonen> | zcorpan: in principle, if you ever set innerHTML on annotation-xml, it would be weird for it to behave differently from a full-doc parse |
| 12:23 | <zcorpan> | hsivonen: that's already the case for foreign stuff due to break-out tags |
| 12:23 | <zcorpan> | hsivonen: but i agree with the principle |
| 12:58 | <Ms2ger> | zcorpan, do you know about the websocket tests? |
| 12:59 | <Ms2ger> | Or jgraham |
| 12:59 | <zcorpan> | Ms2ger: yeah |
| 13:01 | <Ms2ger> | /websockets/interfaces/WebSocket/close/006.html fails with a lot of complaining dumped to the console running wptserve |
| 13:05 | <zcorpan> | Ms2ger: the console complains because the test is closing the connection before it is established |
| 13:05 | <zcorpan> | Ms2ger: presto passes the test with complaining in the console |
| 13:07 | <zcorpan> | Ms2ger: i guess gecko fails because it sync fires a close event when calling close() |
| 13:07 | <Ms2ger> | Might be |
| 13:07 | <zcorpan> | or something |
| 13:07 | <Ms2ger> | Blink fails too |
| 13:08 | <Ms2ger> | Different way, though, maybe |
| 13:08 | <zcorpan> | blink seems to set readyState to CLOSED immediately |
| 13:08 | <Ms2ger> | Yep |
| 13:09 | <Ms2ger> | Oh, no |
| 13:09 | <Ms2ger> | Gecko has closed/fired the close even before the timeout |
| 13:11 | <Ms2ger> | So I guess I'll file a bug on Gecko |
| 13:12 | <hsivonen> | so Web Sockets without TLS had some deployability problems. What caused those to be resolved with a long process with delays instead of the HTTP/2 approach of hiding everything inside TLS? |
| 13:12 | <hsivonen> | (just wondering about what were all the things that went wrong with Web Sockets) |
| 13:13 | <hsivonen> | (and whether the thing that caused delays could have been avoided with a TLS-only policy) |
| 13:13 | <hsivonen> | or did the concerns that lead to long delays apply to wss, too? |
| 13:15 | <zcorpan> | hsivonen: what delays do you mean? |
| 13:16 | <zcorpan> | hsivonen: was it intermediaries hanging on to the response until it thinks it has a full response or some such? |
| 13:17 | <hsivonen> | zcorpan: delays in the process of getting the spec done |
| 13:20 | <zcorpan> | hsivonen: ah. so what deployability problem do you mean? |
| 13:20 | <zcorpan> | hsivonen: i recall there being different success rates on different ports |
| 13:20 | <Ms2ger> | zcorpan, (r? https://critic.hoppipolla.co.uk/r/2542 https://critic.hoppipolla.co.uk/r/2556) |
| 13:22 | <hsivonen> | zcorpan: didn't some intermediaries mess up the upgrade? |
| 13:26 | <zcorpan> | hsivonen: i don't recall the details |
| 13:28 | <zcorpan> | Ms2ger: https://critic.hoppipolla.co.uk/r/2542 was 100% 1 issue |
| 13:29 | <Ms2ger> | Dammit |
| 13:29 | <Ms2ger> | The dashboard really needs to distinguish those |
| 13:35 | <annevk> | hsivonen: fair, though perhaps a usage survey could help make our case? |
| 13:35 | <annevk> | hsivonen: though I guess once you write the code to pass around some extra state, it's not too bad either way |
| 13:36 | <annevk> | hsivonen: I think Hixie_ thought requiring TLS was too hard on authors |
| 13:36 | <annevk> | hsivonen: but don't take my word for it |
| 13:37 | <annevk> | hsivonen: that was before http://tools.ietf.org/html/rfc7258 and therefore before everyone opened their eyes to what some had been saying for a long time |
| 13:41 | <annevk> | es-discuss is somewhat bad at not feeding trolls. And worse at not answering actual feedback. Wrong S/N ratio :-/ |
| 13:45 | <zenparsing> | annevk yeah - i think it used to be better a couple of years ago |
| 13:46 | <zenparsing> | partly it's the release cycle - features for ES6 are either done, or so late that no one really wants to debate them |
| 13:47 | <zenparsing> | but i've noticed that ES7 features aren't really being discussed there, which might be a bad sign |
| 14:45 | <zcorpan> | at least csswg doesn't subscribe to forking whatwg specs |
| 14:55 | <Hixie_> | hober: APIs being inconsistent is even worse than being bad, IMHO. |
| 14:56 | <Hixie_> | hober: but it definitely does make me reluctant about using promises in general |
| 14:57 | <caitp> | bad apis and inconsistent apis are equally bad |
| 14:57 | <Hixie_> | not imho |
| 14:58 | <Hixie_> | a bad api that's consistent is easier to use than a variety of good apis all of which have different philosophies |
| 14:59 | <caitp> | the point is, you don't want to come up with bad apis, you want to come up with good apis which are adopted |
| 14:59 | <caitp> | being bad isn't going to help adoption |
| 15:00 | <Hixie_> | adopted by whom? implements or authors? |
| 15:00 | <Ms2ger> | The Promise fanclub |
| 15:01 | <zenparsing> | Hixie_ i'm sympathetic to your position wrt promise-returning functions throwing, but... |
| 15:01 | <zenparsing> | Hixie_ in the end, as users move to async functions, it will matter less and less |
| 15:02 | <Hixie_> | or more and more :-) |
| 15:02 | <caitp> | in the fuuuuuuuuture |
| 15:03 | <zenparsing> | less and less: async function f() { await gimmePromise(x) } doesn't really matter if gimmePromise throws or rejects |
| 15:05 | <caitp> | from a programme correctness standpoint, you do want the early error, otherwise there's a chance you might not notice |
| 15:06 | <Hixie_> | zenparsing: i think that behaviour for async is dumb too |
| 15:07 | <Hixie_> | zenparsing: i fully expect authors to never check for these error conditions, which is going to lead to all kinds of bugs when their rejection handlers get called for reasons unrelated to what they're expecting |
| 15:07 | <Hixie_> | just like they never check them today, except today it's fine because it just aborts script execution |
| 15:10 | <caitp> | but even if async did make it better, who knows when a platform with the async sugar will exist, why design for a hypothetical future platform |
| 15:17 | <zenparsing> | Hixie_ once async functions are in, manually wiring up rejection handlers will be the exception i think |
| 15:47 | <annevk> | hsivonen: https://twitter.com/sleevi_/status/509723775349182464 |
| 16:16 | <annevk> | Wut. Twitter is serving me JSON |
| 16:16 | <annevk> | "Something is technically wrong." no shit |
| 16:16 | <annevk> | This is why you don't do content negotiation |
| 16:20 | <jgraham> | annevk: Sounds like an improvement |
| 16:50 | <annevk> | I wonder there's a jabber folder with mimesniff.spec.whatwg.org in it on my WHATWG DreamHost account |
| 16:52 | <Ms2ger> | What's jabber? |
| 17:06 | <annevk> | Is there a way to set a default user for a remote host with SSH? |
| 17:07 | <annevk> | Or enable another user by playing with the .ssh directory? |
| 17:21 | <JonathanNeal> | Sorry I’m late to the party, but does Microsoft’s touch events spec cover pressure? Is it Apple Watch ready? |
| 17:26 | <caitp> | the big questions |
| 17:31 | <annevk> | JonathanNeal: you mean pointer events? |
| 17:31 | <JonathanNeal> | pointer events, yes. |
| 17:31 | <JonathanNeal> | caitp: thoughts? |
| 17:31 | <annevk> | JonathanNeal: https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#widl-PointerEventInit-pressure |
| 17:32 | <annevk> | (I don't actually know, but searching for pressure in that draft...) |
| 17:34 | <JonathanNeal> | annevk: wow, i didn’t think it would be so obvious! I’m sorry I made you google that for me. |
| 17:35 | annevk | finds http://stackoverflow.com/questions/10197559/ssh-configuration-override-the-default-username |
| 17:36 | <JonathanNeal> | This confirms that Pointer Events is a brilliant spec. Is Chrome still set to ignore it? Sorry if I missed how that resolved. |
| 17:41 | <JonathanNeal> | ^ https://code.google.com/p/chromium/issues/detail?id=162757 |
| 19:24 | <mounir> | annevk: ping |
| 19:25 | <mounir> | foolip: ping |
| 19:33 | <caitp> | wow, blink's svg rendering works really nicely compared to geckos, when dynamically inserting hundreds of paths |
| 19:33 | <caitp> | good job on the jank-free side of things :> |
| 19:43 | <annevk> | mounir: email or ask and wait until tomorrow |
| 19:47 | <mounir> | annevk: I can wait :) |
| 19:58 | <smaug____> | caitp: yup, we have some very well known perf bugs |
| 19:58 | <smaug____> | in svg |
| 19:58 | <smaug____> | unfortunately |
| 19:58 | <caitp> | not a criticism, I am just impressed with the blink behaviour here |
| 20:00 | <smaug____> | it is a fair criticism. |
| 20:01 | <smaug____> | caitp: if you have a minimal testcase, feel free to file a bug ;) |
| 20:03 | <jmrenner_> | Hey does anyone know why a cross-domain XHR with withCredentials false still requires CORS headers? |
| 20:47 | <odinho> | caitp: I know that at least one of presto's SVG experts (fs) has been working a lot on SVG in blink since Opera moved to chromium. Though I'd guess many of the remove-jank low level changes are most responsible for any recent smoothness changes. |
| 22:14 | <smaug____> | I don't have account to modify http://wiki.whatwg.org/wiki/TR_strikes_again, but it could say there is a constant flow of questions on IRC regarding obsolete TR/ specs, and one needs to all the time (daily or weekly) point to the up-to-date specs. |
| 22:16 | <smaug____> | one case from today http://logs.glob.uno/?c=content#c239087 |
| 23:29 | <Domenic> | Oh Glenn Adams. |
| 23:37 | <smaug____> | indeed |
| 23:44 | <jamesr_> | Delivery to the following recipient failed permanently: |
| 23:44 | <jamesr_> | public-w3cprocess⊙wo |
| 23:44 | <jamesr_> | oh noes! guess that post won't happen |
| 23:44 | jamesr_ | will survive |