| 08:55 | <hsivonen> | I think I saw a tweet go by saying that Chrome disabled sync XHR from onunload in the latest release. Do I recall correctly? Is it now disabled? |
| 08:56 | <annevk> | hsivonen: could be, someone did reach out about standardizing it, but that hasn't really happened yet |
| 08:56 | <hsivonen> | Twitter search doesn't find the tweet |
| 08:57 | <annevk> | hsivonen: per "[blink-dev] Intent to Implement & Ship: Disallow Sync XHR in Page Dismissal" it'll be enabled by default in M75 |
| 08:59 | <annevk> | That thread also basically ignored my question on standardization it seems |
| 08:59 | <annevk> | Ugh |
| 09:02 | <hsivonen> | annevk: thanks. must have been the intent to implement twitter account, because I couldn't find anything from @ChromiumDev or the personal accounts of folks who'd usually tweet stuff like this |
| 09:07 | <hsivonen> | annevk: no reply to bz's comment in the thread... |
| 09:14 | <hsivonen> | hmm. do Blink and WebKit support IE's event.fromElement? |
| 09:17 | <hsivonen> | at least Blink does... |
| 09:20 | <annevk> | hsivonen: tracked by https://github.com/w3c/uievents/issues/84 |
| 09:23 | <Ms2ger> | annevk, wanna review https://github.com/web-platform-tests/wpt/pull/16278 ? |
| 09:25 | <annevk> | Ms2ger: are there bugs to be filed? |
| 09:26 | <Ms2ger> | annevk, I was planning to do that after I merged the spec PR |
| 09:26 | <annevk> | Ms2ger: also, () =>, let/const, are cool, you should start using them |
| 09:30 | <Ms2ger> | Thanks |
| 10:16 | <hsivonen> | annevk: thanks |
| 12:54 | <GPHemsley> | Domenic: Does this test pass for your stuff? https://github.com/web-platform-tests/wpt/commit/8553d30dd590715a63273e90da1951b8b0b37672 |
| 12:54 | <GPHemsley> | (this commit bypassed GitHub PR review) |
| 12:59 | <annevk> | GPHemsley: that looks correct |
| 12:59 | <annevk> | fwiw |
| 13:00 | <GPHemsley> | I'm curious as to why my code failed in exactly the same way as the commit message suggests Chromium does |
| 13:01 | <GPHemsley> | there must be some commonality somewhere |
| 13:03 | <annevk> | GPHemsley: https://jsdom.github.io/whatwg-url/#url=d293Ou+/vQ==&base=YWJvdXQ6Ymxhbms= |
| 13:03 | <annevk> | GPHemsley: seems Chrome/Safari get it right at least |
| 13:05 | <GPHemsley> | annevk: I'm seeing them percent-encoded as %EF%BF%BD everywhere I'm looking |
| 13:05 | <annevk> | GPHemsley: yes, which is what the test asserts |
| 13:06 | <GPHemsley> | annevk: the test is expecting %EF%BF%BF |
| 13:06 | <annevk> | GPHemsley: oh wat |
| 13:07 | <annevk> | GPHemsley: oh, but the input is U+FFFF, not U+FFFD |
| 13:07 | <annevk> | GPHemsley: so I think that's still good |
| 13:07 | <annevk> | (my corresponding test uses U+FFFD, which is why the off-by-two) |
| 13:10 | <GPHemsley> | annevk: Unless I'm doing this wrong (which I probably am), U+FFFF is still being coerced to U+FFFD before being percent-encoded |
| 13:12 | <GPHemsley> | yeah, no, I think I'm doing it wrong |
| 13:13 | <GPHemsley> | so jsdom is handling this correctly? |
| 13:18 | <annevk> | GPHemsley: where is that coercion happening? |
| 13:18 | <GPHemsley> | annevk: It's not, I was misreading the output |
| 13:18 | <annevk> | GPHemsley: it has to happen for lone surrogates, e.g., U+D800, but not U+FFFF, afaict |
| 13:18 | <annevk> | not sure if there's coverage for lone surrogates, I'd hope so |
| 13:18 | <GPHemsley> | annevk: My code is using the replacement character for invalid characters like U+FFFF, but it seems that jsdom is not doing that |
| 13:19 | <annevk> | GPHemsley: there's nothing that says that should happen |
| 13:20 | <GPHemsley> | annevk: Yeah, I think it may be a side effect of how I'm doing UTF-8 encoding |
| 13:20 | <GPHemsley> | (this is the first time a test has failed for it) |
| 13:24 | <Domenic> | Isn't this USVString coercion? |
| 13:25 | <GPHemsley> | annevk: Am I correct in my understanding that the UTF-8 encoder in Encoding is the "non-strict" version of UTF-8? |
| 13:25 | <Domenic> | "Otherwise, d < 0xDC00 or d > 0xDFFF. Append to U a U+FFFD REPLACEMENT CHARACTER." |
| 13:25 | <Domenic> | From https://heycam.github.io/webidl/#dfn-obtain-unicode |
| 13:26 | <dtapuska> | annevk: I've got a question about SharedArrayBuffers and window.opener = null. Does the agent cluster key change at window.opener = null? |
| 13:26 | <annevk> | Domenic: it's not therefore, right? |
| 13:26 | <Domenic> | annevk: USVString coercion makes U+FFFF go to U+FFFD by my reading. This explains jsdom's output, I think. |
| 13:26 | <GPHemsley> | Domenic: Aren't we at "c < 0xD800 or c > 0xDFFF |
| 13:26 | <GPHemsley> | Append to U the Unicode character with code point c. |
| 13:26 | <GPHemsley> | "? |
| 13:27 | <annevk> | dtapuska: setting window.opener cannot affect agent clusters as you already have/had access at that point |
| 13:27 | <Domenic> | Hmm right |
| 13:27 | <annevk> | Domenic: I suggest you read again |
| 13:27 | <annevk> | Domenic: it says if it's greater than 0xDFFF, which 0xFFFF is, you use it as a code point and don't coerce |
| 13:28 | <annevk> | dtapuska: setting window.opener to null does change window name lookup a bit |
| 13:28 | <annevk> | dtapuska: defining that properly is issue 313 |
| 13:28 | <annevk> | hope that helps |
| 13:29 | <Domenic> | Debugger reveals that it gets turned into U+FFFD before it even hits the whatwg-url parser code. Something in the deserialization maybe. |
| 13:29 | <dtapuska> | annevk: ya it was just in context of implementing the Agent, etc in Chrome.. and I wondered if it should support changing at a time but it seems it doesn't need to. Everything is determined at construction time |
| 13:30 | <dtapuska> | annevk: also take a look at https://github.com/whatwg/fetch/pull/853 |
| 13:30 | <annevk> | dtapuska: right, it's very similar to a process boundary, dynamically changing it would be... |
| 13:30 | <dtapuska> | annevk: I think I've addressed the issues you raised before.. there isn't a good way to link into the RFC though |
| 13:30 | <GPHemsley> | Domenic, annevk: So now I'm confused. Is jsdom replacing or not? |
| 13:31 | <Domenic> | GPHemsley: I don't think it is, but the online viewer is broken so I can't be sure. |
| 13:31 | <GPHemsley> | also, it seems we need more tests for this |
| 13:31 | <Domenic> | I'll boot up the actual library tests |
| 13:32 | <annevk> | Domenic: I suspect you cannot get U+FFFF in your clipboard easily |
| 13:32 | <Domenic> | Well the url=d293Ou+/vQ==&base=YWJvdXQ6Ymxhbms= fragment either encodes U+FFFD or is decoded as U+FFFD |
| 13:32 | <annevk> | dtapuska: yeah, I think that's good enough |
| 13:32 | <Domenic> | I am using TextEncoder/TextDecoder |
| 13:32 | <GPHemsley> | Is there a way to view all the mentions of an externally-defined term in a spec? |
| 13:33 | <annevk> | GPHemsley: no :-( |
| 13:33 | <GPHemsley> | boo :( |
| 13:33 | <annevk> | It's becoming a bit of an issue |
| 13:33 | <Ms2ger> | There is in bikeshed |
| 13:33 | <annevk> | I guess there is some kind of dumping thing, indeed |
| 13:33 | <Ms2ger> | Click on the term in the "Terms defined by reference" section |
| 13:34 | <Domenic> | Ugh and the test file formats have changed since last I updated the tests |
| 13:34 | <Domenic> | Going to file an issue on whatwg-url and get to this later |
| 13:34 | <GPHemsley> | it seems we need more tests for strict vs. non-strict UTF-8 |
| 13:35 | <GPHemsley> | now, granted, this would be a bug in an Encoding implementation |
| 13:35 | <GPHemsley> | but it would still be useful to have for URL IMO |
| 13:35 | <Ms2ger> | Domenic, pushed a fixup for https://github.com/heycam/webidl/pull/705 ; do you want to look or should I merge straight away? |
| 13:35 | <Domenic> | Ms2ger: LGTM |
| 13:36 | <GPHemsley> | Ms2ger++ |
| 13:36 | <Ms2ger> | Thanks |
| 13:36 | Ms2ger | waves at GPHemsley |
| 13:45 | <GPHemsley> | annevk: Am I correct in my understanding that U+FFFF will UTF-8 encode as EF BF BF but that will UTF-8 decode as U+FFFD (as defined in Encoding)? |
| 13:45 | <annevk> | GPHemsley: I don't think so |
| 13:46 | <GPHemsley> | :/ |
| 13:46 | <annevk> | GPHemsley: U+FFFF roundtrips afaik |
| 13:46 | <GPHemsley> | oh |
| 13:46 | <GPHemsley> | because it's BF now |
| 13:46 | <GPHemsley> | ok |
| 13:48 | <GPHemsley> | annevk: What do you make of this text? "However, thanks to later revisions to the applicable standards, official UTF-8 is now rather stricter than that. For example, its range is much narrower (0 .. 0x10_FFFF to cover only 21 bits instead of 32 or 64 bits) and some sequences are not allowed, like those used in surrogate pairs, the 31 non-character code points 0xFDD0 .. 0xFDEF, the last two code points in any plane (0xXX_FFFE and |
| 13:48 | <GPHemsley> | 0xXX_FFFF), all non-shortest encodings, etc." |
| 13:48 | <GPHemsley> | does this seem correct? |
| 13:51 | <annevk> | GPHemsley: no |
| 13:52 | <GPHemsley> | annevk: Where is it wrong? |
| 13:52 | <annevk> | GPHemsley: after surrogate pairs |
| 13:52 | <GPHemsley> | hmm, ok |
| 13:57 | <d410> | hello |
| 13:57 | <d410> | can someone begin to explain to me why the context.commit() method of offscreen canvas was removed? |
| 13:58 | <d410> | It seems very useful, right? |
| 14:02 | <annevk> | d410: the commit log should have some pointers |
| 14:03 | <d410> | wait are we talking about commit log of github? :P |
| 14:03 | <d410> | or commit log of commit()? |
| 14:03 | <d410> | hehe |
| 14:03 | <annevk> | d410: of whatwg/html |
| 14:04 | <d410> | ok, ambiguity |
| 14:04 | <d410> | thanks |
| 14:06 | <Ms2ger> | annevk, quick editorial review at https://github.com/heycam/webidl/pull/713 , if you want :) |
| 14:33 | <annevk> | nox: https://github.com/whatwg/dom/pull/754 might be of interest |
| 14:39 | <annevk> | Domenic: do you remember if there are tests for adoptedCallback? |
| 14:40 | <Domenic> | There should be... |
| 14:40 | <annevk> | Domenic: I suspect the ordering is different between Firefox and others atm |
| 14:40 | <annevk> | Domenic: when the c-e is a child of a document fragment |
| 14:49 | <annevk> | Domenic: looks like it's already tested and somehow goes right |
| 14:57 | <annevk> | Domenic: actually, nope |
| 14:58 | <Domenic> | Yeah, testing document fragments I could easily see being omitted |
| 14:58 | <annevk> | Domenic: it's very close, but it only moves the host |
| 15:41 | <annevk> | overall though rniwa did an amazing job with custom element / shadow tree tests |
| 15:44 | <annevk> | Domenic: your poll might also need desktop/mobile caveats, at least for those voting for option 2 |
| 15:44 | <Domenic> | Hmm, you think it'd make sense to have 1 for all desktop platforms and 1 for all mobile platforms? |
| 15:45 | <annevk> | Domenic: I mean, I voted for option 1, but I wouldn't want my desktop date picker to match the one on my phone and vice versa |
| 15:45 | <Domenic> | I guess popup-based controls are a bit different |
| 15:46 | <annevk> | Domenic: on some platforms date is mixed |
| 15:46 | <annevk> | Domenic: and time is a popup on mobile and text on desktop, iirc |
| 15:47 | <Domenic> | I'm not sure the desktop control is any good though... let me check what Windows 10 does... |
| 15:47 | <Domenic> | Hmm https://usercontent.irccloud-cdn.com/file/P03TNBfo/image.png |
| 15:47 | <annevk> | heh |
| 15:48 | <Domenic> | Hmmmmmm https://usercontent.irccloud-cdn.com/file/WhZHUtdy/image.png |
| 15:48 | <annevk> | I'd prefer typing 12:30, but to each their own I suppose |
| 15:48 | <annevk> | aah, that reminds of the Windows I know and love |
| 15:48 | <Domenic> | Yeah maybe Windows 10 doesn't have its act together... curious about macOS. |
| 15:49 | <annevk> | Date & Time preference panel is definitely very different from iOS |
| 15:49 | <Domenic> | https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/date-and-time is apparently the new Windows app recommendation... which is neither of those. Such churn O_O |
| 15:50 | <annevk> | I guess the weird thing with iOS is that <input type=checkbox> isn't rendered as a switch |
| 15:50 | <Domenic> | On Android and Windows at least checkbox and switch have different uses https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/toggles#choosing-between-toggle-switch-and-check-box |
| 15:50 | <Domenic> | I admit not remembering any checkboxes on iOS |
| 15:51 | <annevk> | Ooh, immediate effect is nice |
| 15:51 | <annevk> | That does argue for having something like <input type=checkbox switch> |
| 15:51 | <annevk> | Oh well, one day |
| 15:54 | <Domenic> | My team is hopefully doing switch next quarter, but it's surprisingly complicated... http://adrianroselli.com/2019/03/under-engineered-toggles.html is a great overview of all the things to consider |
| 15:56 | <annevk> | Domenic: interesting, I guess indeterminate kinda argues for type=switch, even though backcompat is less nice |
| 15:56 | <annevk> | I guess we can make it not apply either way |
| 15:57 | <Domenic> | We're currently thinking a new element would be better to start paving away from the problematic design of everything being a single element. Especially with form-associated CE stuff it should be pretty polyfillable either way. |
| 15:57 | <annevk> | Domenic: well, except for all the focus and activation handling that isn't really covered yet? |
| 15:58 | <Domenic> | Yeah, this is the excuse to fix all that ^_^ |
| 15:58 | <Domenic> | a11y too |
| 15:58 | <annevk> | yeah, there's quite a bit more indeed |
| 15:58 | <annevk> | anyway, interesting |
| 16:03 | <gsnedders> | annevk: what's <input type=checkbox> on iOS? |
| 16:05 | <annevk> | gsnedders: macOs-style checkbox, though grey when checked |
| 17:31 | <bkardell> | domenic: "We're currently thinking a new element would be better to start paving away from the problematic design of everything being a single element. " - would this be maybe a built-in module path thing? |
| 17:40 | <Domenic> | bkardell: not sure what you mean |
| 17:42 | <bkardell> | like, 'layered api'? |
| 17:43 | <Domenic> | Still not sure what you mean :). Is there a concrete technical question? |
| 17:46 | <bkardell> | I thought the topic above was your team maybe working on a new element.. if so, would that work be done in the way I think that is described in the layered api proposals - basically, nothing magical, a custom element that might ship with the browser? or am I misunderstanding that proposal too? |
| 17:51 | <Domenic> | The hope is that the element would be 100% polyfillable, yes. |
| 17:55 | <bkardell> | yeah, I would love to follow this or even help maybe.. it seems like this idea (esp the browser potentially shipping something that you don't have to request) seems full of interesting questions and potential |
| 17:56 | <Domenic> | I mean it's just a new HTML element. Chrome hopes to implement it in JS, but that's our strategy and it might not work out. |
| 18:03 | <bkardell> | if you implement it in js, wouldn't it necessarily have a dash? |
| 18:04 | <bkardell> | I mean, it's very possible that there is a lot more sketched out and discussed here than I currently understand and this is entirely plain to you but it's not yet to me so sorry if this seems remedial somehow |
| 18:04 | <Domenic> | Yes, that's one of the trickier parts. |
| 18:04 | <Domenic> | <toggleswitch-> or <std-toggleswitch> or similar probably. |
| 18:05 | <Domenic> | Or we could discuss removing the dash restriction on custom elements. |
| 18:05 | <Domenic> | On the assumption that all future new HTML elements will be opt-in (via importing modules) |
| 18:13 | <bkardell> | right, this is where I was getting to... it seems full of interesting /important topics and challenges on where we go next - really things that have interested for a long time... |
| 18:14 | <d410> | wow innovati im not surprised you are here |
| 18:14 | <d410> | you seem to be everywhere that's web related lol |
| 18:15 | <innovati> | :3 |
| 18:15 | <d410> | see you on codesupport :) |
| 18:17 | <bkardell> | it seems like some things like 'can it have a shadow dom' is a slightly different problem in that context... maybe a better one? |
| 21:39 | <TabAtkins> | Domenic / annevk: If y'all wanna send me some pictures to add to https://drafts.csswg.org/css-forms/#examples I wouldn't mind ^_^ |
