| 00:22 | <wanderview> | jyasskin: can you elaborate? |
| 00:22 | <wanderview> | "browser changes its Accept header" means the service worker manipulates Accept? |
| 05:16 | <jyasskin> | wanderview: When a page requests an image, say, it sets an Accept header of `image/png,image/svg+xml`. The SW uses cache.get(request) to cache it, and the server returns a Vary:Accept header. Then, a later browser version updates its Accept header to `image/webp,image/png,image/svg+xml`, and https://w3c.github.io/ServiceWorker/#query-cache-algorithm skips |
| 05:16 | <jyasskin> | the cache entry in the "For each f in varyHeaders" loop. |
| 05:17 | <jyasskin> | I'm not sure if there's a way to get there for entries that are cached in the 'install' step, without explicitly setting the Accept header. |
| 05:18 | <jyasskin> | s/cache.get/cache.add/ |
| 07:19 | <hsivonen> | annevk: checking just in case: Was it a deliberate decision to go with Blink and Presto (and presumably WebKit; can someone check?) and not with IE/Edge and Gecko for bogus Shift_JIS byte sequences? https://hsivonen.com/test/moz/bogus_shift_jis.htm |
| 07:21 | <hsivonen> | Indeed Edge still has the alleged IE6 behavior. I didn't bother testing with IE6, because my https setup is XP-incompatible and I no longer have a plain-http place for test cases. (Oops.) |
| 07:24 | <annevk> | hsivonen: yes, that was deliberate |
| 07:24 | <hsivonen> | annevk: OK. |
| 07:24 | <annevk> | hsivonen: I can dig up a bug number if you want |
| 07:24 | <annevk> | hsivonen: Encoding used to define the Gecko/IE behavior |
| 07:25 | <hsivonen> | annevk: I'd be curious to see if emk commented on the bug |
| 07:25 | <annevk> | Hmm, change was made in https://github.com/whatwg/encoding/commit/651f672ee988702da03f56ad8bdfda00b51a21ea |
| 07:26 | <annevk> | Going to require some more digging to find corresponding discussion |
| 07:28 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=747762 was after-the-fact discussion |
| 07:35 | <hsivonen> | annevk: thanks. commented there. |
| 07:36 | <annevk> | hsivonen: I can't find the original discussion, but it seems emk agreed in part and later I added EUDC handling back |
| 07:37 | <annevk> | hsivonen: adding that back happened in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24130 |
| 07:38 | <hsivonen> | I take it that since emk filed a counter-bug only for point #3, points #1 and #2 were indeed ok enough |
| 07:42 | <hsivonen> | This is probably the riskiest change in behavior arising from encoding_rs so far |
| 07:48 | <annevk> | I tried searching a bit more, but I can't find anything that lead to the original removal of the quirks |
| 07:50 | <annevk> | Maybe it was based on something at Opera |
| 07:51 | <annevk> | I do remember Opera's encoding engineer not liking PUA so much |
| 07:51 | <foolip> | tobie: thanks for commenting on that issue |
| 07:51 | <annevk> | I wonder what Peter's up to now |
| 07:52 | <tobie> | foolip: np. |
| 07:53 | <hsivonen> | I take it that CYRILLIC SMALL LETTER SHORT U has taken the place of a box drawing character in koi8-u after Web Platform Tests were made |
| 07:53 | <hsivonen> | rather unusual to have to edit a Web Platform Test for this stuff instead of just deleting the failure expectations :-) |
| 07:55 | <annevk> | hsivonen: almost time for https://i.imgur.com/7drHiqrh.jpg? |
| 08:06 | <hsivonen> | annevk: unfortunately, we need some kind of meme for "No" arising from key Rust features being nightly-only |
| 08:49 | <zcorpan> | So how do I go about making new DOMMatrix("matrix(1,0,0,1,0,0)") throw in workers? annevk Domenic |
| 08:49 | <zcorpan> | check if current global object is not the primary global interface? |
| 08:50 | <annevk> | zcorpan: "If current global object is not a Window object and init is a string, then throw a TypeError." |
| 08:50 | <zcorpan> | thanks |
| 08:50 | <nox> | Out of curiosity, why is this forbidden? |
| 08:53 | <zcorpan> | nox: https://github.com/w3c/fxtf-drafts/issues/122 |
| 08:55 | <nox> | Fun. |
| 08:55 | <nox> | zcorpan: Will constructors forever be specified by extended attributes btw? |
| 08:55 | <nox> | zcorpan: You need prose only because extended attributes can't themselves have extended attributes, right? |
| 08:56 | <zcorpan> | nox: yeah, webidl doesn't support this case with syntax |
| 08:56 | <nox> | zcorpan: Are there plans to make constructors not rely on extended attributes anymore? |
| 08:57 | <nox> | Just curious because in Servo I would like to be able to mark some of them as non-throwing, and I can't do that currently. |
| 08:58 | <zcorpan> | nox: there has been talk about more or less radically changing webidl sytnax, but not much progress on that lately. i guess there's a big cost to doing that |
| 08:58 | <nox> | Ok, thanks. |
| 08:59 | <nox> | hsivonen: "Key Rust features?" |
| 08:59 | <annevk> | nox: that sounds like something you should file an issue for against IDL |
| 09:00 | <nox> | annevk: Why? |
| 09:00 | <annevk> | nox: I hadn't considered the argument that since constructor is an extended attribute we can't have nice things |
| 09:00 | <nox> | annevk: IDL has no notion of whether things throw or not. |
| 09:00 | <annevk> | nox: others might not have either |
| 09:00 | <nox> | Ah. |
| 09:00 | <nox> | Will do then |
| 09:01 | <annevk> | nox: IDL should maybe have a notion about throwing at some point I think, it's nice to be able to assert things like that |
| 09:01 | <nox> | annevk: Did we ever consider having [Abstract] too btw? |
| 09:01 | <nox> | E.g. on Node, which doesn't exist on its own. |
| 09:02 | <annevk> | nox: probably worth filing an issue for if there are use cases, even if just codegen use cases |
| 09:02 | <nox> | Ok. |
| 09:02 | <annevk> | nox: I don't recall a discussion myself, just with you here |
| 09:02 | <nox> | I guess I'll do some filing today, |
| 09:02 | <nox> | when grid-template-areas parsing make me too miserable. :P |
| 09:03 | <annevk> | No small feat for a parser to do that given you worked on one for HTML |
| 09:04 | <nox> | Ah ah, true. |
| 09:05 | <nox> | Just complaining because I was having fun and short compile times in Servo's network code, until I got abducted by stylo's team. |
| 09:59 | <annevk> | Where is the last discussion on whether <link> should work like a hyperlink? https://github.com/whatwg/html/issues/2617 |
| 10:04 | <hsivonen> | nox: SIMD |
| 10:05 | <annevk> | hsivonen: so encoding_rs cannot ride the trains because it relies on Rust SIMD? |
| 10:06 | <hsivonen> | annevk: not unless we change policy, no |
| 10:07 | <annevk> | hsivonen: where did we decide on this policy? Searching for Rust SIMD yields very few emails |
| 10:07 | <hsivonen> | (I intend to propose a policy change, but I want to have concrete numbers when I do so) |
| 10:07 | <hsivonen> | annevk: the relevant policy is that Firefox uses release-channel rustc |
| 10:07 | <hsivonen> | annevk: I don't recall if it was a publicly-recorded discussion |
| 10:08 | <annevk> | Oh, SIMD is relatively new to Rust new? |
| 10:08 | <MikeSmith> | annevk: Peter at http://www.bridgetech.tv/ still maybe |
| 10:09 | <hsivonen> | annevk: no, but the person who was developing it left to Google and then the feature got limboed. The person working on it now isn't doing it as a day job. |
| 10:09 | <annevk> | MikeSmith: yeah I think so |
| 10:10 | <MikeSmith> | guess he hasn’t worked on encoding-related stuff in a long time and probably doesn’t miss it :) |
| 10:10 | <annevk> | TIL Palantir contributes to Rust |
| 10:11 | <nox> | hsivonen: I'm -1 on requiring nightly. |
| 10:11 | <nox> | We should instead push harder for simd stabilisation. |
| 10:11 | <annevk> | MikeSmith: he was a big Unicode fan, but maybe |
| 10:11 | <nox> | annevk: And serde too. |
| 10:12 | <hsivonen> | being a Unicode fan doesn't imply that on misses encodings. esp. ones other than UTF-8 :-) |
| 10:13 | <annevk> | MikeSmith: I wish Mozilla would hire him to make a Rust version of ICU |
| 10:13 | <nox> | hsivonen: Do you mean that the simd crate original author left for Google? |
| 10:14 | <hsivonen> | nox: that's my understanding. Have I understood incorrectly_ |
| 10:14 | <nox> | AFAIK you can leave for Google and still have a FOSS life, if you mean huonw he was appled away. |
| 10:14 | <hsivonen> | nox: I was mistaken, then. |
| 10:14 | <nox> | hsivonen: Just a big corp away. :) |
| 10:15 | <nox> | hsivonen: What's the relation between encoding_rs and whatwg btw? |
| 10:16 | <hsivonen> | nox: encoding_rs implements a WHATWG spec and the developer of encoding_rs has a GitHub badge when commenting on WHATWG specs. |
| 10:17 | <nox> | Ah ah ok. |
| 10:17 | <nox> | Was just curious why you people were discussing about it here. |
| 10:17 | <nox> | hsivonen: Any clue what's the status for simd in Rust currently? I stopped following this discussion a while ago. |
| 10:18 | <hsivonen> | nox: my understanding is that there was enough agreement for BurntSushi to start implementing what was discussed, and he is working on it alone |
| 10:19 | <nox> | Ok. |
| 10:19 | <hsivonen> | nox: the discussion was here, because I asked about the spec not having a particular pair of IE/Gecko quirks |
| 10:19 | <nox> | Quirks, always missing quirks. |
| 12:06 | <KiChjang> | what does "non-conforming" mean in the HTML spec? |
| 12:10 | <MikeSmith> | KiChjang: it generally means a document-conformance requirement |
| 12:10 | <KiChjang> | what does it mean for a document to conform? |
| 12:12 | <MikeSmith> | it means the document does not violate any requirements in the spec |
| 12:13 | <MikeSmith> | the document-conformance requirements are stated in order to prevent documents from using certain markup cases that have unintended bad effects |
| 12:14 | <MikeSmith> | see https://validator.w3.org/nu/about.html#why-validate for a short version |
| 12:15 | <MikeSmith> | see https://html.spec.whatwg.org/multipage/introduction.html#syntax-errors for a longer explanation |
| 12:15 | <MikeSmith> | and https://html.spec.whatwg.org/multipage/introduction.html#restrictions-on-content-models-and-on-attribute-values for yet more details |
| 12:17 | <MikeSmith> | but the shortest answer is: |
| 12:17 | <MikeSmith> | > There are some markup cases defined as errors because they are potential problems for accessibility, usability, interoperability, security, or maintainability—or because they can result in poor performance, or that might cause your scripts to fail in ways that are hard to troubleshoot. |
| 12:18 | <MikeSmith> | > Along with those, some markup cases are defined as errors because they can cause you to run into potential problems in HTML parsing and error-handling behavior—so that, say, you’d end up with some unintuitive, unexpected result in the DOM. |
| 12:42 | <annevk> | zcorpan: you closed https://github.com/whatwg/html/issues/2443 but as far as I can tell the specification doesn't do case-insensitive matching |
| 12:42 | <annevk> | zcorpan: I'm reworking the choosing a browsing context algorithm and it seems to just do string comparison |
| 12:46 | <zcorpan> | annevk: https://html.spec.whatwg.org/multipage/browsers.html#valid-browsing-context-name-or-keyword allows case-insensitive. I guess I didn't look closely at "The rules for choosing a browsing context given a browsing context name" |
| 12:47 | <annevk> | Okay, I'm going to reopen that issue and address it in my patch then |
| 12:48 | <zcorpan> | sounds good. thanks! |
| 13:21 | <wanderview> | jyasskin: yea, I guess the service worker script would have to be smart enough to re-cache in that case |
| 14:00 | <annevk> | Whoa, rewriting those rules took long |
| 16:26 | <nox> | I'm just being curious but, |
| 16:26 | <nox> | TabAtkins: any clue was grid-template-areas uses strings instead of separating each row by `/` or something? |
| 16:26 | <nox> | s/was/why/ |
| 16:28 | <TabAtkins> | Largely a historical artifact. |
| 16:31 | <nox> | TabAtkins: Curiosity satisfied, thanks. |
| 16:32 | <wanderview> | JakeA: our plan to do a different useCache setting for importScripts... is that easily applied to dependent module records? or will module workers still only check the top level script? |
| 16:34 | <tobie> | Does the HTML standard address what happens to focus when the user agent looses focus? |
| 16:37 | <tobie> | Trying to mitigate password skimming using motion sensors. Turns out that some browsers still consider you're focused in the top-level browsing context when you're actually typing your 1password code. :( |
| 16:39 | <tobie> | visibility state doesn't seem to help here either (page is still visible). |
| 16:39 | <tobie> | Is there something else I should be looking at? |
| 16:40 | <wanderview> | tobie: IntersectionObserver? |
| 16:40 | <wanderview> | or maybe that doesn't help either |
| 16:41 | <tobie> | wanderview: that tells you whether an element is in the viewport or not, right? |
| 16:41 | <wanderview> | yea, I got confused about your use case |
| 16:42 | <tobie> | wanderview: yeah, I assumed visibility state was good enough, but it's not. :( |
| 16:43 | <annevk> | Domenic: sorry, I think I'm a little tired |
| 16:49 | <annevk> | Domenic: are there no <script type=module> web-platform-tests atm? |
| 16:49 | <Domenic> | annevk: there's a decent amount, from an initial Microsoft import. There are some bugs we're discovering, both in the tests and the spec; we are trying to upstream as we implement in Chrome. |
| 16:50 | <annevk> | Domenic: interesting, I'll note that in https://bugzilla.mozilla.org/show_bug.cgi?id=1330900 as it seems our implementation didn't trigger any change in results |
| 16:51 | <Domenic> | annevk: from https://bugzilla.mozilla.org/show_bug.cgi?id=1330900#c5 it seems like they are not being run because modules are preffed off? |
| 16:51 | annevk | blames being tired |
| 16:52 | <wanderview> | Domenic: well, we can flip prefs when running WPT tests |
| 16:52 | <wanderview> | although I don't see that bug doing it |
| 16:53 | <Domenic> | Get some sleep annevk :). Sorry for my late-shifted schedule these days. |
| 17:04 | <JakeA> | wanderview: I'm having trouble bending my brain round your message… sorry if this doesn't answer your question: I expect module script static imports to behave like importScripts in regards to cache usage & byte checking |
| 17:05 | <wanderview> | JakeA: ok... I just didn't know how easy that was to do with the module spec, etc... I noticed there are different paths in SW spec for classic vs module |
| 17:07 | <JakeA> | wanderview: Yeah, it's going to take some work with the html spec I think. https://github.com/w3c/ServiceWorker/issues/908 is kinda related |
| 17:07 | <wanderview> | ah, ok |
| 20:23 | <smaug> | hmm, since pages seem to misuse Promises, somehow thinking that they are asynchronous, I wonder if there was some way to start to paint between microtasks |
| 20:24 | <smaug> | that would be quite evil, sure |
| 21:49 | <jyasskin> | I'm surprised to see that https://w3c.github.io/mediacapture-main/#overconstrainederror-object is defining a new Error subclass instead of a DOMException. Should other specs consider doing that too? |
| 21:50 | <Domenic> | jyasskin: no. The issue is they need more information fields than just name/message, apparently. |
| 21:50 | <Domenic> | We'd like to make that easier in IDL (e.g. `exception Foo : DOMException { ... }` or something) but haven't so far. |
| 21:51 | <jyasskin> | Ah, I see. |
