| 03:34 | <GPHemsley> | annevk: I just noticed https://bugzilla.mozilla.org/show_bug.cgi?id=500713 has been waiting on a needinfo from me since last year re mimesniff. You wanna take it? |
| 08:01 | <annevk> | GPHemsley: done |
| 08:02 | <annevk> | GPHemsley: that is, I replied and cleared the flag for you |
| 10:15 | <MikeSmith> | annevk: if you have a minute to look at http://stackoverflow.com/questions/42131714/cors-access-control-max-age-works-for-same-origin-or-just-same-request-url please post a comment if I got anything wrong, or another answer even |
| 10:15 | <MikeSmith> | or if you have a place to cite in the spec for that |
| 10:16 | <MikeSmith> | I couldn’t see a specific dfn or other anchor to cite, so other than saying “Read through the spec” don’t know what else to point to |
| 10:18 | <zcorpan> | hsivonen: can you take a look at https://github.com/whatwg/html/pull/2319 ? |
| 10:19 | <annevk> | MikeSmith: that looks good, but it's slightly more complicated |
| 10:19 | <annevk> | MikeSmith: it's per-URL and per-originating-origin |
| 10:20 | <annevk> | MikeSmith: https://fetch.spec.whatwg.org/#concept-cache-match is the reference |
| 10:20 | <annevk> | MikeSmith: again, roughly |
| 10:34 | <MikeSmith> | annevk: OK thanks |
| 11:34 | <MikeSmith> | nox: https://github.com/whatwg/url/pull/228#issuecomment-278617035 |
| 11:35 | <MikeSmith> | nox: and https://github.com/whatwg/url/pull/228#discussion_r100102850 |
| 11:35 | <nox> | I suggest calling a valid URL a crispy dark baguette, |
| 11:35 | <nox> | and a non-conforming one underbaked garbage. |
| 11:36 | <MikeSmith> | ❤️ like |
| 11:45 | <annevk> | heh |
| 12:36 | <zcorpan> | BenjaminSchaaf: the EOF thing is tested by /webvtt/webvtt-file-format-parsing/webvtt-file-parsing/support/signature-space.vtt at least, correct? |
| 15:02 | <Domenic> | zcorpan_: sorry I caused conflicts with your <menuitem> PR |
| 15:03 | <zcorpan_> | Domenic: 😡 😆 should be easy enough to resolve |
| 15:09 | <zcorpan_> | but i'll wait for hsivonen's review |
| 15:10 | <zcorpan_> | then i can squash and then resolve conflicts |
| 15:14 | <annevk> | zcorpan_: FWIW, I have a slight preference for doing reviews based on non-conflicted code |
| 15:15 | <annevk> | zcorpan_: chance for missing a typo increases if you edit after |
| 15:15 | <zcorpan_> | annevk: yeah, true |
| 15:16 | <zcorpan_> | annevk: but also becomes harder to review if i squash and then rebase. i suppose i can rebase without squashing though |
| 15:17 | <annevk> | zcorpan_: that's what I tend to do, not ideal either of course |
| 17:12 | <annevk> | MikeSmith: is there a canonical explanation for why "validator" is wrong? |
| 17:12 | <annevk> | MikeSmith: I haven't really internalized the rationale and that seems to be affecting how I name things |
| 17:18 | <MikeSmith> | annevk: It is not canonicaly wrong so there canonical explanation. And in other contexts I think there is nothing wrong with it, but in the specific context of checking HTML documents I quit using it because it triggers assumptions from people about what the checker should do for them. |
| 17:19 | <MikeSmith> | in the context of checking HTML documents, people see it as meaning, e.g., they should be able to get a badge that says “Your document is valid HTML5” |
| 17:20 | <MikeSmith> | that is, it tends to cause people to see the purpose of checking your HTML to be just to get a binary pass/fail |
| 17:20 | <MikeSmith> | instead of the purpose of the checker being to help you find unintended mistakes |
| 17:21 | <MikeSmith> | and sometimes people intentionally use markup that causes the checker to emit an error or warning, but they know what they are doing and why |
| 17:22 | <MikeSmith> | so that’s the reason I added the message-filtering feature, to let people suppress checker errors and warnings they do not find useful |
| 17:23 | <MikeSmith> | and if they are using that feature, it is wrong for the checker to emit a message saying, Your document is valid HTML |
| 17:23 | <MikeSmith> | so instead I have the checker say, There were no errors or warnings to report. |
| 17:24 | <MikeSmith> | that is, to give control back to user about whether the document has errors as far as they are concerned |
| 17:25 | <annevk> | MikeSmith: okay, I guess that's reasonable and way more nuanced than things were in my head |
| 17:26 | <MikeSmith> | OK |
| 17:26 | <annevk> | MikeSmith: thanks for the help thus far |
| 17:26 | <MikeSmith> | thank you for caring about this stuff |
| 17:26 | <MikeSmith> | words are important |
| 17:27 | <MikeSmith> | oh man branch name annevk/url-ß |
| 17:27 | <MikeSmith> | that reminds me of something that zcorpan would do |
| 17:28 | <annevk> | MikeSmith: I now want to try it everywhere |
| 17:28 | <MikeSmith> | intentionally, to see what it would break |
| 17:28 | <MikeSmith> | haha yup |
| 17:30 | <jgraham> | Yeah, so expecting unix command line environments to have sane unicode setups is a little optimistic |
| 17:31 | <MikeSmith> | I think travis does at least |
| 17:32 | <MikeSmith> | but if you mean every wpt user having a sane unicode setup I guess these days if they don’t they are gonna run into lots of other problems |
| 17:33 | <MikeSmith> | I have long go lost patience with Python2 on this |
| 17:33 | <MikeSmith> | I never run into annoying problems with Python except for this unicode thing |
| 17:34 | <MikeSmith> | with python I run into few other problemsーthings just workーand when I do run into problems it always otherwise turns out to be my fault |
| 17:35 | <MikeSmith> | but this unicode thing is python’s fault |
| 17:49 | <jgraham> | MikeSmith: It seems like this might be much easier to debug if you can try to reproduce locally |
| 17:54 | <annevk> | jgraham: let me know if your recommendation is to submit again with an ASCII branch |
| 17:54 | <annevk> | name |
| 17:57 | <annevk> | tobie: PR preview seems to work for whatwg/url |
| 17:57 | <annevk> | tobie: pretty nice |
| 17:58 | <tobie> | Yeah. Fixed the auth today. |
| 18:00 | <annevk> | tobie: what's the diff between "Diff w/ current ED | Diff w/ base" |
| 18:01 | <annevk> | tobie: oh I see master vs branch point |
| 18:02 | <tobie> | Happy to reword those. |
| 18:03 | <annevk> | tobie: Is there a term for branch point? |
| 18:04 | <annevk> | tobie: it would be nice if Preview could point to https://url.spec.whatwg.org/branch-snapshots/annevk/concept-relations/ instead |
| 18:05 | <annevk> | tobie: I'd name the first "Diff with Standard" and I'm not quite sure what the use of the second is |
| 18:05 | <annevk> | tobie: it seems you'd only ever want to review against master |
| 18:12 | <annevk> | tobie: the HTML diffing is amazing |
| 18:12 | <tobie> | annevk: it's keyboard navigable, btw. :) |
| 18:12 | <annevk> | tobie: though I did find that diff with current ED doesn't seem to rebase |
| 18:13 | <annevk> | tobie: so it instead acted as if the PR would revert changes made on master |
| 18:13 | <annevk> | (I rebased myself locally now so it's no longer visible there) |
| 18:14 | <tobie> | 19:12 <annevk> tobie: though I did find that diff with current ED doesn't seem to rebase <-- not sure what you mean. |
| 18:15 | <annevk> | tobie: on master I had changed "terminate these steps" to "return" |
| 18:15 | <annevk> | tobie: the diff for the PR with current ED suggested that would change back to "terminate these steps" |
| 18:15 | <annevk> | tobie: which is not what GitHub would actually do for squash/rebase |
| 18:16 | <ajeffrey_> | Another question about origin equality... |
| 18:16 | <ajeffrey_> | in step 4 of https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-open, which equality is intended? |
| 18:16 | <ajeffrey_> | same-origin-domain? |
| 18:16 | <annevk> | tobie: so the diff is different from GitHub's diff, basically |
| 18:17 | <annevk> | ajeffrey_: there's an open bug on that by jeisinger (also a PR) |
| 18:17 | <tobie> | annevk: oh, no. It's because it got stale I guess. |
| 18:17 | <ajeffrey_> | annevk: ah (goes and searches) |
| 18:17 | <tobie> | That's the issue with caching. :( |
| 18:18 | <tobie> | annevk: need to figure out something. |
| 18:19 | <ajeffrey_> | annevk: that would be https://github.com/whatwg/html/pull/2288 then? |
| 18:19 | <ajeffrey_> | annevk: thanks! |
| 18:23 | <smaug> | https://wicg.github.io/IntersectionObserver/#calculate-intersection-rect-algo step 3 doesn't make sense, right? container is a containing block, but intersection root is a node |
| 18:23 | <smaug> | or am I missing something here? |
| 21:39 | <Mek> | is there something similar to the "unloading document cleanup steps" but for workers? (context: currently as spec'ed blob URLs are revoked when the document that created them is unloaded. but the spec doesn't say anything about blob URLs created by workers...) |
| 22:18 | <ajeffrey_> | And yet another dumb question... |
| 22:18 | <ajeffrey_> | https://html.spec.whatwg.org/multipage/browsers.html#dom-history-go says "if delta is zero, the user agent must act as if the location.reload()", |
| 22:18 | <ajeffrey_> | does that include the same-origin-domain check at https://html.spec.whatwg.org/multipage/browsers.html#dom-location-reload? |
| 22:40 | <ajeffrey_> | annevk: ^ |
| 23:43 | <tobie> | annevk: You should now get the right diffs in pr-preview + link to the branch when it exists. |
| 23:45 | <tobie> | annevk: I still need to fix the z-index of the HTML diff so the UI shows up above the warning on WHATWG specs, |
| 23:45 | <tobie> | annevk: like this: https://s3.amazonaws.com/pr-preview/heycam/webidl/3834774..tobie:interface-objs:7dfd134.html |
| 23:45 | <tobie> | annevk: (bottom right corner and "j" and "k" keys) |