| 07:43 | <Ms2ger> | Is the dom manipulation task source guaranteed to only be used in window scopes? |
| 07:54 | <annevk> | Ms2ger: I'm very skeptical that task sources are actually well organized and used |
| 10:58 | <hsivonen> | annevk: https://hsivonen.fi/rs/encoding_rs/ in case you have comments on the API |
| 11:02 | <annevk> | hsivonen: looks pretty good |
| 11:03 | <annevk> | hsivonen: I have a large backlog of standard issues so still need to solve layering between HTML and Encoding |
| 11:04 | <annevk> | hsivonen: but from your feedback that should not change much API-wise |
| 11:11 | <hsivonen> | annevk: yeah, that wouldn't change this API in practice |
| 11:12 | <annevk> | hsivonen: I like the introduction too |
| 11:15 | <annevk> | hsivonen: the one thing that is a little weird is that you stress UTF-16 is important for Gecko, but you also don't want to invest in perf there |
| 11:16 | <annevk> | hsivonen: it seems for integration with Gecko and the OS, UTF-16 perf is important, even though it's ASCII-incompatible and Web-wise uninteresting |
| 11:39 | <FND> | are there any articles on Custom Elements v1 that provide some guidance/interpretation/... on top of the spec? all I can find are v0 write-ups |
| 11:40 | <FND> | (e.g. I seem to recall there was a flag to activate v1 in Chrome, but can't seem to find it) |
| 11:47 | <annevk> | FND: http://hayato.io/2016/shadowdomv1/ |
| 11:49 | <FND> | annevk: thanks - but that doesn't seem to cover Custom Elements? |
| 11:53 | <annevk> | Doh, not sure there's an equivalent |
| 11:56 | <FND> | bummer - it seems a bit tricky to get started if you're not privy to the face-to-face discussions |
| 12:03 | <annevk> | FND: HTML Standard has examples |
| 12:04 | <annevk> | FND: most discussion is on GitHub, but no summery yet |
| 12:04 | <annevk> | FND: also don't think anyone is shipping yet |
| 12:04 | <FND> | yeah, that's fair - I wasn't really complaining, just pointing out that it feels a bit weird at the moment |
| 12:05 | <FND> | so I'll probably stick with v0 for now and port when the v1 ecosystem is a bit more advanced |
| 12:07 | <nox> | The IndexedDB spec makes me sad. |
| 12:07 | <nox> | It seems quite hand-wavy on the task queuing front. |
| 14:57 | <hsivonen> | annevk: I mean I don't want to invest in the perf of UTF-16 as a network-facing encoding |
| 14:58 | <hsivonen> | annevk: I do want to invest in the perf of UTF-16 as the in-RAM encoding |
| 14:58 | <hsivonen> | annevk: I guess I will need to clarify that |
| 14:59 | <annevk> | hsivonen: that makes sense, just adding "unless it helps the browser case" is probably sufficient |
| 14:59 | <hsivonen> | UTF-16 as a sequence of u16 needs perf. UTF-16 as a sequence of u8 doesn't |
| 15:01 | <hsivonen> | annevk: in practice, I mean that I'm not going to write an SSE2 fast path for ASCII for UTF-16BE, UTF-16LE or ISO-2022-JP |
| 15:02 | <hsivonen> | I do intend to write SSE2 acceleration from ASCII to in-RAM UTF-16 Basic Latin |
| 15:02 | <hsivonen> | which will be reusable across the ASCII-compatible encodings |
| 15:02 | <annevk> | hsivonen: do we use SIMD today? |
| 15:03 | <hsivonen> | annevk: only to accelerate ASCII to Basic Latin when decoding UTF-8 |
| 15:03 | <hsivonen> | but not for the other ASCII-compatible encodings |
| 15:04 | <hsivonen> | the old decoders aren't well-designed enough for the acceleration to generalize |
| 15:05 | <hsivonen> | which is one reason to do a full rewrite |
| 15:06 | <annevk> | hsivonen: SIMD doesn't make sense for variable-width? |
| 15:06 | <annevk> | I guess the simultaneous processing doesn't really work anymore at that point |
| 15:07 | <hsivonen> | it might, but let's start with parity with the old UTF-8 decoder, which accelerates ASCII only |
| 15:07 | <hsivonen> | there exist UTF-8 decoders that use SIMD for more, but they aren't suitably licensed, so I haven't looked at the details |
| 15:14 | <annevk> | hsivonen: https://woboq.com/blog/utf-8-processing-using-simd.html has some analysis on different strategies |
| 15:27 | <rektide> | Am I reading it right- https://notifications.spec.whatwg.org/#constructors step #2 means Notifications can not be launched from a ServiceWorker? |
| 15:28 | <rektide> | I was intending to make a small app to set a "look away from screen" reminder for myself, and was hoping I could implement the app chiefly as a service worker that pops up a notification |
| 15:58 | <annevk> | rektide: just use showNotification |
| 17:35 | <hsivonen> | annevk: IIRC that one is LGPL |
| 17:41 | <hsivonen> | annevk: also, it uses more than just SSE2 and Rust is currently bad at using intruction set extensions conditionally depending on the run-time-detected capabilities of the CPU |
| 17:43 | <annevk> | hsivonen: you can depend on 2 being available but not 4, or some such? |
| 17:50 | <annevk> | Anyway, the wins relative to iconv are pretty cool |
| 21:17 | <zcorpan> | jgraham: i'm pondering if it's possible to display passed assertions in testharness.js in the results table (maybe a new column), but i don't know if it's possible to associate an assertion with a test (other then when it throws)... other than when file_is_test is true |
| 21:41 | <zcorpan> | still could be useful for file_is_test tests |
| 22:08 | <gsnedders> | zcorpan: what's the use of that? |
| 22:09 | <gsnedders> | zcorpan: and assertions are always kinda linked to tests insofar as if they fail the test fails |
| 22:10 | <zcorpan> | gsnedders: give some confidence that the assertions have run at all (with async tests it's not obvious) |
| 22:11 | <zcorpan> | and see the order the assertions ran in, seems useful for debugging or when writing tests |
| 22:13 | <zcorpan> | also https://groups.google.com/a/chromium.org/d/msg/blink-dev/rDKsRjVYsZM/71w4_y6HBQAJ |
| 22:19 | <smaug____> | Does Edge support data: urls? |
| 22:21 | <Jayflux> | smaug____, yep I think so |
| 22:21 | <smaug____> | anyone with Edge then :) |
| 22:21 | <smaug____> | want to test something simple |
| 22:21 | <smaug____> | data:text/html,<input type="range" multiple min=0 max=24 value=0,24 step=1.0> |
| 22:21 | <smaug____> | does that multiple do anything special |
| 22:27 | <Domenic> | lol can't paste data URLs in Edge |
| 22:27 | <Domenic> | It does not |
| 22:27 | <Domenic> | I think Hixie just added that one day without implementer commitment :-/ |
| 22:43 | <Mek> | are "https://foobar.com"; and "https://foobar.com:443"; supposed to be same-origin or not? Blink thinks they are not same-origin, while chromium outside of blink thinks they are... |
| 22:44 | <Mek> | actually, never mind, they both think they are not same-origin, my bug was somewhere else |
| 22:46 | <Mek> | no, scratch that, it does have that inconsistency... |
| 22:51 | <Mek> | or maybe it doesn't matter because in practice you'll never get an explicit port in a url when the port is the default port for the scheme... |
| 22:53 | <Domenic> | I haven't checked against our URL spec reference implementation, but I believe per https://url.spec.whatwg.org/#default-port and its one reference, once parsed those two URLs are supposed to be indistinguishable, which would mean the origin check would call them equal |
| 22:57 | <Mek> | yeah, that indeed seems to be the case, thanks |