| 08:41 | <Ms2ger> | annevk, <annevk> Ms2ger: remind me Monday and I'll just do it, custom elements is making good progress :-) |
| 08:41 | <annevk> | Ms2ger: come on, I'm barely awake |
| 08:41 | <annevk> | Ms2ger: but yeah, I'll make some tea and get on that |
| 08:42 | <Ms2ger> | No hurry, but you asked to be reminded :) |
| 08:42 | <annevk> | Ms2ger: yeah, thanks :-) |
| 08:44 | <hemanth> | ^_^ |
| 08:45 | <annevk> | jgraham: could we make it so that "sign in" is "clicked" as some background process? |
| 09:35 | <jgraham> | annevk: No |
| 09:36 | <jgraham> | annevk: That doesn't work if you don't have a github account or haven't used critic before (you end up on a github login page for some unknown reason) |
| 09:36 | <annevk> | jgraham: what if we XHR it? |
| 09:37 | <jgraham> | It was the original design and I spent all my time explaining to people that ending up at a github page was expected behaviour |
| 09:37 | <annevk> | <iframe>? |
| 09:39 | <jgraham> | I guess the problem with that is that a) you won't actually end up logged in until you navigate and b) you don't want to keep sending failed login attempts on every page navigation for non-signed-in users |
| 09:39 | <jgraham> | Really the only problem here is that the cookie shouldn't be a session cookie |
| 09:42 | <annevk> | jgraham: what's a session cookie? |
| 09:43 | <annevk> | jgraham: very low Max-Age? |
| 09:43 | <annevk> | Oooh, having neither Expires nor Max-Age |
| 09:44 | annevk | learned about the persistent-flag today |
| 10:11 | <hemanth> | any work around to avoid a feedback on local audio streaming with webrtc? |
| 10:13 | <hemanth> | for example http://jsfiddle.net/gazq9nwy/ gives a horrible feedback, strangely works well on headphones...did try mediaStream.getAudioStreams()[0].enabled = false; wasn't useful, also tried setting the volume level to 0.7, no use... |
| 10:18 | <annevk> | hemanth: might just be your OS being crappy |
| 10:19 | <hemanth> | annevk, might be i'm on OSX heh heh |
| 10:20 | <hemanth> | https://code.google.com/p/webrtc/source/detail?r=5159 should have fixed it...but not really |
| 10:21 | <hemanth> | Darwin Kernel Version 14.0.0 to be specific |
| 10:29 | <hemanth> | annevk, there is no feedback on your machine? |
| 11:24 | <annevk> | hsivonen: bit unclear whether to add ms932 given the lack of web pressure |
| 12:04 | <JakeA> | annevk: What's the best error for "You're not allowed to open a window right now", security or invalidState? |
| 12:05 | <Ms2ger> | Why are you not allowed? |
| 12:09 | <annevk> | JakeA: TypeError all the things :-) |
| 12:13 | <JakeA> | Ms2ger: https://html.spec.whatwg.org/multipage/browsers.html#allowed-to-show-a-popup |
| 12:14 | <JakeA> | annevk: What's the rationale there? I mean, with the fetch spec it mean you don't have a DOM dependency |
| 12:14 | <Ms2ger> | RangeError :) |
| 12:14 | <JakeA> | but this is for a spec that already has a DOM dependency |
| 12:15 | <annevk> | JakeA: unless there's a use case for branching I fail to see the point to make an effort |
| 12:15 | <annevk> | JakeA: and DOMException doesn't really match what how JavaScript designed exceptions |
| 12:16 | <annevk> | s/what// |
| 12:16 | <JakeA> | annevk: So why TypeError and not just Error? |
| 12:16 | <annevk> | JakeA: that's what awb seems to default to |
| 12:16 | <annevk> | JakeA: and sometimes RangeError |
| 12:17 | <Ms2ger> | Anyway, I guess I'd InvalidAccess |
| 12:18 | jgraham | feels like if the answer is "TypeError all the things" the question was probably "what sucks about exceptions in js?" |
| 12:26 | <caitp> | there are lots of valid answers to that question though |
| 12:31 | <annevk> | Ugh, the people suggesting self-signed certificates are fine are many |
| 13:12 | <hsivonen> | annevk: yeah, it isn't clear what the right call on the ms932 thing is. you are the editor. :-) However, if the Encoding Standard doesn't add it, it looks pretty clear that Thunderbird will. |
| 13:13 | <hsivonen> | annevk: to the extent email deliberately wants to have extra labels, I think not having them everywhere consistently is sad |
| 13:13 | <hsivonen> | email having extra encodings like UTF-7 is another story |
| 13:23 | <annevk> | hsivonen: it's weird that per https://wiki.whatwg.org/wiki/Web_Encodings#Firefox Firefox never supported that label |
| 13:24 | <annevk> | hsivonen: I guess I'll wait a bit and if there's no negative feedback I'll add it |
| 13:24 | <annevk> | Also, www-tag... |
| 13:24 | <annevk> | More people arguing for OE |
| 13:25 | <annevk> | Ugh |
| 13:32 | <gsnedders> | hsivonen: time for an Email Encodings spec? :) |
| 13:40 | <hsivonen> | annevk: the comments on the Thunderbird bug suggest that we started doing less autodetection and previously it was caught by the detector |
| 13:40 | <hsivonen> | annevk: or something |
| 13:41 | <hsivonen> | annevk: more labels is better than more autodetection |
| 13:41 | <annevk> | hsivonen: perhaps Thunderbird always used the "Universal" detector? |
| 13:41 | <hsivonen> | annevk: IIRC that was only when you attached files--not for incoming email |
| 13:41 | <hsivonen> | annevk: but yeah, there was that lurking in the code! |
| 13:42 | <annevk> | hsivonen: however, adding a label has a problem we've seen before: Content-Type:text/html; charset=shift-jis; \n\n <meta charset=utf-8> |
| 13:42 | <hsivonen> | annevk: yeah. I don't know what the right call is |
| 13:42 | <annevk> | I'll add a comment to the bug, perhaps someone can supply data |
| 13:42 | <hsivonen> | also, I'm not happy about how much time pondering about edge cases like this takes |
| 13:45 | <annevk> | hsivonen: yeah, see e.g. blink-dev thread on navigator.vendor |
| 13:45 | <annevk> | hsivonen: there's some kind of inverse graph for the core primitives of the platform |
| 13:46 | <annevk> | hsivonen: which is probably why infrastructure does not get fixed, but papered over |
| 13:56 | <duncanw> | hello all, I write a tool that generates websites, for our japanese users I’ve been trying to figure out how to handle hiragana and katakana characters in the URL path part (i.e. the filename produced by my app), I understand browsers request percent escaped UTF8, and I’m pretty sure there’s a unicode normalization step (which makes sense), but don’t know what it is |
| 13:57 | <Ms2ger> | Doesn't url.spec.whatwg.org tell you? |
| 13:57 | <annevk> | duncanw: what part of the URL are we talking about? |
| 13:57 | <duncanw> | Ms2ger: wouldn’t look like it |
| 13:57 | <duncanw> | annevk: the path part |
| 13:58 | <annevk> | duncanw: there's no Unicode normalization going on there |
| 13:58 | <duncanw> | e.g. http://something.jp/ < japanese glyphs > |
| 14:00 | <annevk> | duncanw: end of https://url.spec.whatwg.org/#path-state explains what happens to the input |
| 14:01 | <duncanw> | annevk: um, I don’t see that fragment, https://url.spec.whatwg.org/#relative-path-state perhaps? |
| 14:02 | <annevk> | duncanw: yeah, sorry |
| 14:02 | <duncanw> | kk |
| 14:04 | <duncanw> | annevk: this explains why unicode normalization is necessary, and I can only assume browsers do it before encoding the path: https://tools.ietf.org/html/rfc5198#section-3 |
| 14:05 | <annevk> | duncanw: why can you only assume? |
| 14:05 | <duncanw> | annevk: but I haven’t found anything official looking or even unofficial… perhaps I should dig in the webkit source |
| 14:05 | <annevk> | duncanw: you could just test it and see it's false? |
| 14:06 | <annevk> | duncanw: that RFC is immaterial when it comes to URLs or HTTP |
| 14:06 | <duncanw> | annevk: the RFC is irrelevant but it shows cases where something the user enters can have different code points for an identical glyph |
| 14:07 | <annevk> | duncanw: yes, that can happen |
| 14:07 | <duncanw> | annevk: and even unicode terminology considers them canonically equivalent |
| 14:07 | <annevk> | duncanw: sure |
| 14:07 | <annevk> | duncanw: you would have to implement Unicode normalization yourself though |
| 14:09 | <duncanw> | annevk: my app runs on Macs, and Cocoa has pretty good normalization… that’s not my problem, my problem is figuring out which normalization form to use. I was hoping to find something documenting exactly which one it is, if there is one. I assume it is either NFC or NFKC http://unicode.org/reports/tr15/#Norm_Forms |
| 14:09 | <annevk> | duncanw: which one what is? |
| 14:10 | <duncanw> | annevk: the unicode normalized form used by browsers |
| 14:10 | <annevk> | (if you want to avoid being thrown off bridges, use NFC) |
| 14:10 | <annevk> | duncanw: I just told you browsers don't do that |
| 14:12 | <duncanw> | annevk: well I have had an instance with german where a user entered filename had an u+umlaut, it was properly encoded as UTF8 by the browser but the file couldn’t be loaded from the server… if the browsers don’t do it then perhaps the server filesystem does |
| 14:12 | <duncanw> | annevk: I had “fixed” it by removing non-ascii characters, which clearly doesn’t work for CJK text |
| 14:13 | <annevk> | duncanw: so, you want to run Unicode normalization on the filename you get on the server side |
| 14:14 | <annevk> | duncanw: and you need to be careful since the filename might not be Unicode (if someone is tricking you or using some weird Linux variant) |
| 14:15 | <duncanw> | annevk: right, I don’t control the server so I guess I can only do normalization on the filename before sending it to the server... |
| 14:16 | <annevk> | duncanw: sure, I recommend implementing NFC or using the normalize method from ES6 (might not be implemented yet though) |
| 14:17 | <duncanw> | annevk: ok, thanks a lot for your help |
| 14:22 | <gsnedders> | browsers may do normalization on URLs entered by the user, but may just vary based on how the OS hands them the string from the input (which may or may not be normalised) |
| 14:49 | <duncanw> | gsnedders: thanks! You’ve seen this or know of browsers that do it? |
| 14:50 | <gsnedders> | duncanw: I know OSes do interesting stuff to text input. :) |
| 14:50 | <duncanw> | gsnedders: right well I guess I’m just wondering if you have a specific example that I might try to track down |
| 14:51 | <gsnedders> | duncanw: IIRC OS X does interesting stuff with composing characters as you type them, with interesting intermediatry values |
| 14:53 | <duncanw> | gsnedders: right, I write diacritics on a US keyboard layout by doing the composition (like opt-e plus e to get é), and I see something similar happening when entering japanese text |
| 15:39 | <zcorpan_> | annevk: the spec says shift-jis is a known label. is that intentional? |
| 16:10 | <annevk> | zcorpan: I confused with euc_jp |