| 04:19 | <annevk> | Domenic: CSP implications |
| 04:41 | <MikeSmith> | I guess github needs a way to add a comment when assigning a review |
| 04:42 | <MikeSmith> | though I guess we can always just manually add a separate comment |
| 05:31 | <gsnedders> | So, how dead is TPAC going to be if nobody from Europe or the Middle East shows up? I imagine it'll still be pretty busy given the number of local people… |
| 06:19 | <hsivonen> | annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=563283 says that other browsers supported the precombining the sound marks when encoding half-width Katakana to ISO-2022-JP |
| 06:20 | <hsivonen> | annevk: so other browsers changed, too, in the last 7 years? |
| 07:00 | <annevk> | hsivonen: I think it might be that he was seeing something else |
| 07:00 | <hsivonen> | annevk: ok |
| 07:00 | <annevk> | hsivonen: Safari performs some flavor of Unicode normalization |
| 07:00 | <annevk> | hsivonen: for form submission |
| 07:00 | <annevk> | hsivonen: I think Chrome removed that post-fork, but not immediately |
| 07:01 | <hsivonen> | it would be interesting to know if HFS+ is to blame for Safari doing that |
| 07:01 | <hsivonen> | i.e. to protect the non-Mac world from copied and pasted HFS+ file names |
| 07:02 | <gsnedders> | or the OS doing that to all text fields? |
| 07:02 | <annevk> | hsivonen: https://bugs.webkit.org/show_bug.cgi?id=159891 has information on it |
| 07:02 | <hsivonen> | there was a bad time in 2003, 2004 or so when Preview was exporting decomposed text to the clipboard for a while |
| 07:03 | <annevk> | hsivonen: does NFC do the same thing that bug is talking about? |
| 07:03 | <annevk> | hsivonen: if not, I don't know what's going on |
| 07:06 | <hsivonen> | not sure. I guess it's time to test |
| 07:08 | <hsivonen> | annevk: NFKC roughly does |
| 07:08 | <hsivonen> | but not NFC |
| 07:09 | <hsivonen> | hmm. let's have another look at the test case |
| 07:10 | <hsivonen> | the Mozilla test case tests input that needs NFKC, not NFC, to combine the sound marks |
| 07:11 | <annevk> | Hmm, maybe ap was wrong |
| 07:27 | <hsivonen> | annevk: IE10 on Windows 7 does the NFKC thing for half-width Katakana |
| 07:29 | <annevk> | hsivonen: so Edge has a different encoder? Or different test from mine? |
| 07:30 | <hsivonen> | annevk: Edge (Anniversary Update) also does the NFKC thing |
| 07:31 | <hsivonen> | I tested https://hsivonen.com/test/moz/iso-2022-jp-form-submission.htm with U+FF76 U+FF9E |
| 07:32 | <annevk> | hsivonen: what about https://dump.testsuite.org/encoding/iso-2022-jp/encode.html? |
| 07:32 | <hsivonen> | I didn't test what happens with decomposed full-width Katakana |
| 07:32 | <hsivonen> | let's see |
| 07:35 | <hsivonen> | I get a mangled query string in Edge |
| 07:36 | <hsivonen> | mangled query in IE11 on Windows 7, too |
| 07:38 | <hsivonen> | but if I look at what the query should be if it hadn't lost its escape characters, it seems like it didn't to the NFKC thing |
| 07:38 | <hsivonen> | so, yeah, difference in MS browsers between form and query |
| 07:38 | <hsivonen> | hooray |
| 07:38 | <hsivonen> | let's test full-width katakana then |
| 07:41 | <hsivonen> | no NFKC for full-width in IE11 for Windows 7 |
| 07:41 | <hsivonen> | so, uconv wasn't alone but really matches Microsoft for form submission |
| 07:43 | <hsivonen> | now I feel bad about regressing this |
| 07:43 | <hsivonen> | although it annoys me that all this time goes into the least useful (on the Web) encoder |
| 07:46 | <hsivonen> | so: Microsoft and uconv both precombine the sound marks to their bases as in NFKC but map lone sound marks to their non-combining versions (unlike NFKC) |
| 07:56 | <tobie> | gsnedders: I'm kind of surprised you draw the line at "can't use my laptop on the flight." |
| 08:40 | <nox> | Isn't the expansion of radial-gradient() wrong in https://drafts.csswg.org/css-images-3/#radial-gradients? |
| 08:41 | <nox> | AFAICT, the expansion says that everything before colour stops can be omitted, that doesn't seem to reflect the rest of the spec. |
| 08:42 | <annevk> | hsivonen: it's still unclear to me how this changed in Chrome and Safari |
| 08:42 | <annevk> | hsivonen: was ap wrong and are they actually doing NFKC or NFKD or some such? |
| 08:43 | <annevk> | hsivonen: I guess I can try to test Safari TP with your form thingy |
| 08:46 | <annevk> | hsivonen: with your test and "ｶﾞ" as input I still get 4 bytes in Chrome and Safari and 2 bytes in Firefox |
| 08:47 | <annevk> | hsivonen: so it's not clear we really regressed much |
| 08:51 | <hsivonen> | annevk: so Safari doesn't combine them. OK. |
| 08:52 | <annevk> | hsivonen: just to be totally safe, the output I get is QUERY_STRING = q=%1B%24B%25%2B%21%2B%1B%28B |
| 08:53 | <annevk> | From which I determined %25%2B%21%2B to be the four relevant bytes |
| 08:53 | <hsivonen> | ok |
| 08:55 | <hsivonen> | is the way the gb18030 decoder emits an ASCII character for the second byte in a 4-byte GB18030 sequence that decodes to a null code point a new thing in the spec or a pre-existing browser behavior |
| 08:55 | <hsivonen> | in a stream of bytes that could by their values be part of multiple 4-byte sequences, it changes how the 4-byte sequences align to bytes |
| 08:59 | <annevk> | hsivonen: you mean it should maybe emit ASCII U+FFFD ASCII instead? |
| 09:00 | <annevk> | hsivonen: I think that might be new, it's part of making sure you cannot mask ASCII characters used in parser operations |
| 09:00 | <hsivonen> | annevk: if it's new, it might have undesirable side effects |
| 09:00 | <annevk> | (at least sound like it, it's too long ago that I actually know for sure) |
| 09:00 | <hsivonen> | I guess it's time for cross-browser testing |
| 09:13 | <hsivonen> | I'm going to consider this a spec bug |
| 09:15 | annevk | hopes it's easy to fix |
| 09:32 | <hsivonen> | annevk: I proposed an easy fix that masks an ASCII byte but only when it is known to be surrounded by non-ASCII bytes: https://github.com/whatwg/encoding/issues/110 |
| 09:34 | <annevk> | hsivonen: but if N is non-ASCII then attribute="i amN"Nbroken" |
| 09:34 | <annevk> | hsivonen: maybe not a problem here because the ASCII range is rather limited, iirc, but still |
| 09:35 | <hsivonen> | the ASCII bytes are always ASCII digits |
| 09:36 | <hsivonen> | well, I suppose if you emit two errors at a time, I can build some more state into the decoder and make the error emission happen separately |
| 09:36 | <hsivonen> | in any case, it seems that the decoder getting misaligned in a way that doesn't happen in current impls is bad |
| 09:38 | <annevk> | hsivonen: yeah, not matching impls is bad; masking ASCII digits makes me a little uncomfortable since it's an exception to a rule, but probably okay... |
| 10:10 | <hsivonen> | so, it looks like the euc-kr decoder in uconv composes Hangul Compatibility Jamo into Hangul Syllables |
| 10:10 | <hsivonen> | does any other browser do *that* |
| 10:11 | <annevk> | hsivonen: is https://hsivonen.com/test/moz/gb18030-alignment.htm 8 bytes? |
| 10:11 | <annevk> | hsivonen: or 16? |
| 10:11 | <hsivonen> | annevk: 16 |
| 10:12 | <annevk> | hsivonen: so browsers just eat all ASCII digits atm |
| 10:12 | <hsivonen> | right |
| 10:13 | <annevk> | hsivonen: did you test ASCII but not ASCII digit in the fourth place there? |
| 10:13 | <hsivonen> | annevk: I didn't |
| 10:13 | <hsivonen> | seems indeed relevant to test |
| 10:16 | <hsivonen> | uconv seems to bake \u3164\u3131\u314f\u3138 into \uAC07, but NFKC says \u1160\uac00\u1104 |
| 10:18 | <annevk> | hsivonen: I'll create a test for that then |
| 10:28 | <annevk> | hsivonen: seems that's interoperable at least |
| 10:29 | <annevk> | hsivonen: if you're not worried about consuming ASCII digits I'd suggest we just consume them all |
| 10:37 | <hsivonen> | annevk: works for me |
| 10:38 | <hsivonen> | annevk: https://hsivonen.com/test/moz/compatibility-jamo.htm Firefox differs from IE and Chromium. What does Safari do? |
| 10:38 | <annevk> | Output is 갇 and ㅤㄱㅏㄷ |
| 10:39 | <hsivonen> | annevk: thanks |
| 10:39 | <hsivonen> | so same as Chromium and IE |
| 10:39 | <annevk> | Rendering is different between Safari and IRCCloud running in Firefox though |
| 10:39 | <nox> | Is <positive-integer> defined in any CSS spec? |
| 10:41 | <hsivonen> | annevk: do you mean Safari renders the compatibility jamo as a syllable block? |
| 10:41 | <annevk> | https://irccloud.mozilla.com/file/RII3aZeG/Safari%20TP.png |
| 10:42 | <annevk> | hsivonen: ^ |
| 10:42 | <hsivonen> | annevk: wow. what's that first glyph on the last row? |
| 10:42 | <hsivonen> | anyway, it seems that the spec is fine here and uconv has unnecessary complexity |
| 10:43 | <annevk> | hsivonen: right, that's the one that was bugging me |
| 10:44 | <hsivonen> | IE, Chromium, Firefox and irssi render the first code point as a space |
| 10:45 | <annevk> | hsivonen: it's U+3164 HANGUL FILLER |
| 10:45 | <hsivonen> | Unicode.org doesn't provide a glyph for it |
| 10:45 | <annevk> | hsivonen: in Safari's DOM inspector it doesn't render either |
| 10:45 | <hsivonen> | annevk: yes. it's a control for marking the start of a syllable block |
| 10:46 | <hsivonen> | the glyph resembles HANGUL LETTER SSANGHIEUH |
| 10:47 | <hsivonen> | anyway, probably not something I need to care about |
| 11:10 | <hsivonen> | TIL: https://www.iana.org/assignments/charset-reg/CP50220 |
| 11:11 | <hsivonen> | references the whatwg wiki! |
| 11:13 | <annevk> | hsivonen: I think that happened back when I was trying to turn IANA into The Thing |
| 11:16 | <annevk> | hsivonen: realized there's another interesting case |
| 11:16 | <annevk> | hsivonen: the fourth byte is neither a digit nor ascii |
| 11:16 | <annevk> | hsivonen: Firefox ends up with an extra U+FFFD, Chrome and Safari do not |
| 11:18 | <annevk> | hsivonen: although it's not entirely clear to me how Firefox does it like that, hmm |
| 11:18 | <annevk> | oh maybe that has more to do with Firefox's two byte error handling |
| 12:09 | <hsivonen> | trivia: previously, the maximal length of a byte sequence corresponding to a single U+FFFD was 3 bytes. this spec change makes it 4 bytes |
| 12:09 | <hsivonen> | (previously per spec that is) |
| 12:11 | <annevk> | hsivonen: even in UTF-8? |
| 12:11 | <annevk> | I guess so |
| 12:12 | <annevk> | Good question for a pub quiz |
| 12:13 | <hsivonen> | annevk: even in UTF-8, indeed |
| 12:14 | hsivonen | updates documentation in 4 places where this fact is stated |
| 12:16 | <annevk> | hsivonen: I suspect I'll land the fix Monday to give everyone some time to comment in case we overlooked something |
| 12:24 | <hsivonen> | annevk: ok |
| 12:37 | <zcorpan_> | Domenic: I'm happy that I managed to use serialize/deserialize correctly. It seemed intimidating at first but was actually pretty straight-forward |
| 13:14 | <Domenic> | Now I kind of want to put that testimonial in the spec |
| 13:16 | <Domenic> | Good times https://github.com/w3c/webrtc-pc/pull/1108#issuecomment-300694559 |
| 13:19 | <annevk> | o_O |
| 13:20 | <tobie> | :D |
| 13:22 | <annevk> | Domenic: you should open an issue against them on behalf of Chrome, saying you can't both implement their requirements and say, SharedArrayBuffer, as you don't know what the intersection looks like |
| 13:23 | <Domenic> | Commented at https://github.com/w3c/webrtc-pc/pull/1171 |
| 14:14 | <tobie> | Domenic: comments on merged pulls are easy to ignore. |
| 14:22 | <annevk> | Domenic: with out-of-process iframe elements (and therefore distinct event loops), how does Chrome prevent duplicate alert()s? |
| 14:35 | <Domenic> | annevk: no real idea... @avidrissman on GitHub knows I am sure, as he's overhauling Chrome's alert() handling |
| 16:17 | <gsnedders> | tobie: risk of theft/damage is way more of a concern than using a laptop in flight imo |
| 16:17 | <annevk> | Domenic: I would love @whatwg/navigate with all the relevant engineers, but maybe too many problems right now to bother lots of people with |
| 16:18 | <gsnedders> | tobie: I had previously basically agreed to continue to go to meetings arranged prior to November |
| 17:00 | <TabAtkins> | nox: It's not in https://drafts.csswg.org/indexes/#types so I guess not. What spec did you find it in? |
| 17:01 | <TabAtkins> | nox: No, the r-g() grammar is right. What makes you think the initial part can't be omitted? |
| 17:58 | <nox> | TabAtkins: The previous grammar in the spec. |
| 17:58 | <nox> | Err, no, I'm saying it can't, but the expanded grammar says it does. |
| 17:58 | <nox> | https://drafts.csswg.org/css-images-3/#radial-gradients |
| 17:58 | <nox> | "[ <ending-shape> || <size> ]? [ at <position> ]? ," |
| 17:58 | <TabAtkins> | Yeah, both parts are optional. |
| 17:59 | <nox> | becomes in note below: |
| 17:59 | <nox> | https://irccloud.mozilla.com/pastebin/t05NdVBb/ |
| 17:59 | <nox> | TabAtkins: If both parts are optional, why is there a mandatory comma? |
| 18:00 | <TabAtkins> | There's not - https://drafts.csswg.org/css-values/#comb-comma |
| 18:00 | <nox> | :O TIL |
| 18:00 | <nox> | TabAtkins: Thanks. |
| 18:00 | <TabAtkins> | np |
| 18:00 | <TabAtkins> | What about the <positive-integer> thing? |
| 18:24 | <TabAtkins> | (The optional-comma thing in CSS grammars isn't well-known, and it's only about 2 years old anyway, but by golly does it make certain types of grammars much simpler to write.) |
| 18:24 | <TabAtkins> | (I find that the occasional confusion from someone not knowing about it is well worth the simplification and increased comprehensibility of the resulting grammars.) |
| 18:48 | <Domenic> | Has anyone else had trouble testing shared workers, where it seems like the request to the worker file is just not being made? |
| 18:49 | <Domenic> | I guess I should ask the testing channel |
