| 00:03 | <TabAtkins> | MikeSmith: plinss says the issue is fixed |
| 00:03 | <MikeSmith> | TabAtkins: oh cool |
| 00:03 | MikeSmith | takes a look |
| 00:06 | <MikeSmith> | TabAtkins: curl https://api.csswg.org/bikeshed/ -F url=https://raw.githubusercontent.com/w3c/ServiceWorker/246340fce702bab2cce35b046f090606389b279a/docs/index.bs -F output=err |
| 00:07 | <MikeSmith> | still gives the error: |
| 00:07 | <MikeSmith> | LINK ERROR: No 'attr-value' refs found for 'serviceworker' with for='link/rel'. |
| 00:07 | <MikeSmith> | <a data-link-type="attr-value" data-lt="serviceworker" data-link-for="link/rel">serviceworker</a> |
| 00:07 | <MikeSmith> | I guess there’s some latency in updating? |
| 00:08 | <TabAtkins> | Should have been fixed yesterday. :/ |
| 00:10 | <TabAtkins> | debugging now |
| 00:11 | <MikeSmith> | k |
| 00:23 | <MikeSmith> | TabAtkins: btw another question: When I ref that was not failing before is failing now, is there same way I can debug that to know what it *used* to resolve to? |
| 00:23 | <Krinkle> | annevk: Seems lists.whatwg.org isn't working, forced HTTPS in my browser, but only responds to HTTP. This means confirmation links for moderation, subscribe and unsubscribe don't work. |
| 00:23 | <Krinkle> | Tricked clicking the link by curl'ing the url instead. |
| 00:23 | <TabAtkins> | MikeSmith: Not really; you need a historical version of the linking database, basically. |
| 00:24 | <MikeSmith> | OK yeah I figured but wanted to confirm |
| 00:24 | <Krinkle> | (I don't know how maintains this, feel free anyone else to reply :) ) |
| 00:24 | <MikeSmith> | TabAtkins: the specific failure is this: |
| 00:24 | <MikeSmith> | LINK ERROR: No 'dfn' refs found for 'the worker's documents'. |
| 00:24 | <MikeSmith> | <a data-link-type="dfn" data-lt="the worker’s Documents">the worker’s Documents</a> |
| 00:25 | <MikeSmith> | TabAtkins: pretty sure that used to resolve to something in HTML, but in looking through the HTML changelog I find nothing that has changed it |
| 00:25 | <MikeSmith> | anyway, will look some more |
| 00:25 | <MikeSmith> | Krinkle: known issue |
| 00:26 | <MikeSmith> | Krinkle: cannot remember the details of the cause, but lists.whatwg.org has not worked since we moved to HTTPS, ever |
| 00:26 | <MikeSmith> | so links to all the old indexed e-mail messages from those archives are broken |
| 00:27 | <MikeSmith> | but we have a mirror at https://lists.w3.org/Archives/Public/public-whatwg-archive/ |
| 00:27 | <MikeSmith> | ah you’re asking about just the Web-based subscribe UI |
| 00:28 | <MikeSmith> | I have not tried to used that. I wonder if others have been able to, but I would think not, given the underlying issue |
| 00:43 | <Krinkle> | MikeSmith: Yeah, the problem is people can't unsubscribe anymore. |
| 00:43 | <TabAtkins> | hehehe |
| 00:46 | <MikeSmith> | Krinkle: There’s no fix that I’m aware of. Well other than moving the hosting. I think it’s been year or maybe even two since Dreamhost told Ian they would be fixing it soon or something like that |
| 00:47 | <MikeSmith> | or however long it’s been it was moved to HTTPS |
| 00:50 | <TabAtkins> | MikeSmith: I mean, you can at least remove them manually from the DB? |
| 00:52 | <MikeSmith> | subcribers? |
| 00:52 | <MikeSmith> | maybe Ian can |
| 00:52 | <MikeSmith> | or maybe annevk has admin access to it now, I dunno |
| 01:52 | <MikeSmith> | Krinkle: so yeah I’m told the only way to unsubscribe from the list is by e-mail to the unsubscribe-whatwg⊙wo (or whatever) address, which I think is shown in the footer of every messsage |
| 01:54 | <Krinkle> | MikeSmith: "whatwg-unsubscribe⊙wo" actually, and not in the footer anymore for some time (config setting in Mailman). |
| 01:54 | <Krinkle> | MikeSmith: And then you get a confirmation mail with a link that doesn't work :) |
| 01:54 | <Krinkle> | unless you know how to bypass HSTS |
| 01:54 | <Krinkle> | (e.g. via curl) |
| 01:54 | <MikeSmith> | oh :( |
| 01:54 | <Krinkle> | https://whatwg.org/mailing-list#specs |
| 01:55 | <Krinkle> | the link is HTTP but Chrome enforces it to HTTPS because whatwg.org has HTSTS with *. subdomains enforced |
| 01:55 | <MikeSmith> | Krinkle: what happens if you just reply to the confirmation e-mail? |
| 01:56 | <MikeSmith> | that is what those instructions say to do |
| 01:56 | <MikeSmith> | oh |
| 01:56 | <MikeSmith> | > Please disregard the suggestion that you follow links to a Web site; due to a limitation of our hosting provider, that site is currently unavailable.) |
| 01:57 | <MikeSmith> | so the instructions explicitly say to not follow links to the Web site |
| 01:57 | <Krinkle> | MikeSmith: https://gist.github.com/Krinkle/ce71cff47fcf2a7fb6b923518c185347 |
| 01:57 | <Krinkle> | I don't see that instruction. |
| 01:58 | <Krinkle> | Ah, on the website for subscribing |
| 01:58 | <Krinkle> | yeah good point |
| 01:58 | <MikeSmith> | yeah |
| 01:58 | <Krinkle> | I didn't see that |
| 01:58 | <MikeSmith> | yeah we should put it in bold I guess |
| 01:58 | <Krinkle> | Mailmail also has a config option to change the tetx phrasing in these e-mail so we could omit the link in general and say something else there |
| 01:58 | <MikeSmith> | I did not notice it either at first |
| 01:59 | <Krinkle> | Configurable for each individual email list even |
| 01:59 | <MikeSmith> | maybe e-mail Ian about that |
| 02:00 | <MikeSmith> | if you can tell him exactly where it can be changed I reckon he would be happy to change it |
| 02:00 | <MikeSmith> | and provide some suggested text |
| 02:05 | <Krinkle> | k, I'll try to do that later today or tomorrow. Thanks |
| 02:06 | <MikeSmith> | cheers |
| 06:00 | <zcorpan> | foolip: how does https://html.spec.whatwg.org/#dom-texttrack-inbandmetadatatrackdispatchtype relate to the new <audio> metadata proposal? |
| 06:13 | <MikeSmith> | TabAtkins: I see the xref thing got fixed |
| 06:13 | <MikeSmith> | https://rawgit.com/w3c/ServiceWorker/fcf2835093c4e4caf213d56e1d28f3c5c06c7aaa/docs/index.html#link-type-serviceworker |
| 06:14 | <TabAtkins> | Yeah. |
| 06:14 | <TabAtkins> | plinss's fix wasn't spread to all of his parsers. ^_^ |
| 06:14 | <MikeSmith> | the link at contains the keyword "_serviceworker_" |
| 06:14 | <MikeSmith> | ah cool |
| 06:14 | <MikeSmith> | thanks much |
| 06:14 | <MikeSmith> | and thanks to plinss too |
| 06:14 | <MikeSmith> | TabAtkins: btw I wonder if I can attend the CSS WG f2f tomorrow? |
| 06:15 | <MikeSmith> | is the room big enough? |
| 06:15 | <TabAtkins> | Ask Rossen/astearns. (They'll say yes.) |
| 06:15 | <MikeSmith> | k |
| 06:15 | <TabAtkins> | Yes, it is (as an observer) |
| 06:15 | <MikeSmith> | which building y’all in? |
| 06:15 | <MikeSmith> | East? North? |
| 06:16 | <MikeSmith> | Old building? Or newer one? |
| 06:16 | <MikeSmith> | astearns: OK if I attend tomorrow? |
| 06:16 | <astearns> | yes |
| 06:16 | <MikeSmith> | yay |
| 06:16 | astearns | damn, proved tab right |
| 06:16 | <MikeSmith> | thanks |
| 06:16 | <TabAtkins> | Today is East (6 on the website map), but I know we'll be in a different building at some point; dunno if it's tomorrow or Friday. |
| 06:17 | <MikeSmith> | haha |
| 06:17 | <MikeSmith> | TabAtkins: ok, thanks |
| 06:32 | <astearns> | MikeSmith: tomorrow we're in "Faculty Research Building A and B room" |
| 06:34 | <MikeSmith> | astearns: ah OK thanks yeah that building’s close by |
| 06:34 | <MikeSmith> | though I can’t remember that we ever had a meeting in that building before |
| 08:11 | <smaug> | how stable https://html.spec.whatwg.org/multipage/forms.html#attr-fe-autocomplete-section might be? |
| 08:13 | <annevk> | smaug: Chrome implemented it at some point I think |
| 08:13 | <annevk> | smaug: we haven't touched it since Ian maintained it |
| 08:13 | <smaug> | ok |
| 08:14 | <smaug> | section-* feels a bit odd, but ok fine, if it has been implemented |
| 08:14 | <annevk> | smaug: oh, I thought you meant autocomplete in general, I don't know for sure about section-, though I suspect it's the same |
| 08:15 | annevk | misread the URL |
| 08:21 | <annevk> | SimonSapin: be sure to not use CSSString for things that need to be USVString, such as URLs |
| 08:22 | <SimonSapin> | annevk: I think the only URLs in CSSOM are inside url("…") inside CSS syntax |
| 08:22 | <annevk> | SimonSapin: there's no API for those? |
| 08:22 | <annevk> | SimonSapin: and I'd imagine there's CSSImportRule and some things around CSSStyleSheet that would be affected |
| 08:23 | <SimonSapin> | oh right, forgot about that one. CSSImportRule currently has: readonly attribute DOMString href; |
| 08:24 | <SimonSapin> | Stylesheet also has href |
| 08:24 | <TabAtkins> | We can change that I think. |
| 08:24 | <annevk> | It's sorta fine since it's readonly, but better to be specific |
| 08:24 | <SimonSapin> | USVString for href? |
| 08:24 | <annevk> | (That is to say, you can use any for readonly attribute and it would still be the same.) |
| 08:25 | <annevk> | SimonSapin: yes |
| 08:26 | <SimonSapin> | stylesheet.insertRule("@import url('\uD800');", 0) can sneak surrogates in there |
| 08:26 | <SimonSapin> | same as document.write("<a href='\uD800'>") though |
| 08:48 | <zcorpan> | SimonSapin: annevk: are DOMString and USVString https://heycam.github.io/webidl/#dfn-distinguishable ? (or can they be?) |
| 08:49 | <annevk> | zcorpan: ah, interesting point, I guess you can't typedef them after all |
| 08:49 | <zcorpan> | I guess webidl should have a string-like category there |
| 08:50 | <zcorpan> | can typedef to DOMString and say in prose that USVString instead is also conforming |
| 08:51 | <TabAtkins> | SimonSapin: *Can* you smuggle that in? Per Syntax, you have to do a "decode"; that'll get rid of the surrogate, no? |
| 08:52 | <SimonSapin> | TabAtkins: only in https://drafts.csswg.org/css-syntax/#input-byte-stream when starting with bytes, so not in CSSOM |
| 08:52 | <zcorpan> | TabAtkins: syntax parse entry points can be called with a string (for cssom) |
| 08:53 | <annevk> | The URL parser expects scalar values so you better remove lone surrogates before you invoke that |
| 08:53 | <SimonSapin> | https://drafts.csswg.org/css-syntax/#tokenization says its input is code points |
| 08:54 | <TabAtkins> | Yeah, per spec you totes can't call any of the parsing algos with a bytestream. |
| 08:55 | <SimonSapin> | annevk: looks like https://drafts.csswg.org/css-values/#urls doesn’t have an imperative algorithm that explicitly invokes the URL parser |
| 08:55 | <TabAtkins> | (Yeah, it doesn't yet; I have a 2-year-old issue on me to do that.) |
| 09:02 | <SimonSapin> | annevk: so I can’t typedef CSSOMString? |
| 09:03 | <annevk> | SimonSapin: nope, I was wrong |
| 09:04 | <annevk> | SimonSapin: you can typedef it to DOMString and add some text that implementations can also use USVString |
| 09:04 | <TabAtkins> | (Or vice versa - plan for the future.) |
| 09:04 | <annevk> | SimonSapin: but you cannot do (DOMString or USVString) |
| 09:05 | <annevk> | TabAtkins: yeah, I'm all on board with this UTF-8 Rust train, but it seems like it would be a hit everywhere else unless specifically optimized |
| 09:06 | <annevk> | I'm still a little worried about that with the encoder/decoder/URL standards, whether I made the right choice to enforce input to be scalar values, but sufficiently smart implementations can optimize, as hsivonen demonstrated |
| 10:30 | <annevk> | MikeSmith: when I use file upload on https://checker.html5.org/ without a file extension it seems to default to XML, though a) it doesn't tell me it's doing this and b) there's no way to override it |
| 10:35 | <annevk> | WHATWG's working mode, finally in HTML: https://github.com/whatwg/whatwg.org/pull/25 |
| 11:51 | <MikeSmith> | annevk: try the checker again now |
| 11:52 | <annevk> | foolip: I addressed your agent feedback, I hope |
| 11:53 | <annevk> | MikeSmith: cool |
| 11:53 | <annevk> | MikeSmith: the other thing I needed but that's rather esoteric I guess is overriding the charset |
| 11:53 | <MikeSmith> | annevk: for that there’s a query param |
| 11:53 | <MikeSmith> | gimme a second to find the name |
| 11:54 | <annevk> | MikeSmith: nah it's fine, I don't need it anymore I think |
| 11:54 | <MikeSmith> | OK |
| 12:59 | <nox> | annevk: In case you wonder, |
| 12:59 | <JakeA> | Domenic: Is the intent for <script type="module"> to omit credentials for same-origin scripts? |
| 12:59 | <nox> | that ticket on the URL standard about # in userinfo and whatnot stemmed from https://github.com/servo/rust-url/pull/293#issuecomment-295035947. |
| 13:01 | <annevk> | nox: yeah I saw |
| 13:01 | <annevk> | nox: I wonder what SimonSapin thought the ambiguity was |
| 13:01 | <annevk> | nox: I hope he didn't just try to make it somebody else their problem |
| 13:02 | nox | says nothing. |
| 13:12 | <JakeA> | Domenic: seems a bit weird to have to set crossorigin to cause modules to send cookies to my own origin |
| 13:42 | <JakeA> | Domenic: Looks like this change happened in https://github.com/whatwg/html/pull/607, but the comment suggests it was a non-normative change |
| 13:43 | <JakeA> | fwiw Safari appears to implement this as spec'd |
| 13:44 | <annevk> | JakeA: I'm pretty sure it's not changed there and was always like this |
| 13:45 | <annevk> | JakeA: Domenic and I did discuss that maybe it should change and I believe dherman still wants crossorigin=use-credentials to not be supported at all, though not sure how strongly he feels about that |
| 13:45 | <annevk> | JakeA: that's also how fetch() works by default |
| 13:47 | <JakeA> | annevk: You're right, the CORS setting was converted into a credentials mode before that PR |
| 13:49 | <JakeA> | annevk: I'm ok with the fetch default (although it catches people out a lot), but it feels weird that crossorigin implies sending cookies to the same origin |
| 13:50 | <annevk> | Maybe we should do away with "omit" and just use "same-origin" for credentials all the time |
| 13:50 | <annevk> | Unless folks optin to "include" obv |
| 13:50 | <JakeA> | <script type="module" src="blah.js"> - no credentials |
| 13:50 | <JakeA> | <script type="module" src="blah.js" crossorigin> - with credentials |
| 13:51 | <annevk> | JakeA: hmm yeah |
| 13:51 | <JakeA> | But I don't want to rock the boat too much. I'd rather have modules than not :D |
| 13:52 | <annevk> | JakeA: file an issue? This seems like a fix that can be made post-shipping too |
| 13:52 | <JakeA> | Shall do |
| 13:52 | <annevk> | JakeA: removing credentials is hard, but adding is okay (opposite of exceptions) |
| 14:07 | <JakeA> | annevk: Domenic: https://github.com/whatwg/html/issues/2557 |
| 14:19 | <wanderview> | JakeA: that module behavior is unlike other tags that have a crossorigin attribute, right? they all use same-origin credentials mode by default, right? |
| 14:19 | <wanderview> | mostly because they existed before fetch spec I guess |
| 14:20 | <wanderview> | ^mostly^maybe |
| 14:22 | <JakeA> | wanderview: most APIs are no-cors with credentials, and crossorigin makes it CORS same-origin credentials, and crossorigin=use-credentials makes it CORS with credentials |
| 14:23 | <wanderview> | ah, ok |
| 14:23 | <wanderview> | JakeA: thanks, sorry for my confusions |
| 14:23 | <wanderview> | confusion |
| 14:23 | <JakeA> | it is pretty confusing :D |
| 14:23 | <wanderview> | I guess modules are just "different" |
| 14:31 | <annevk> | I think it's mostly my fault |
| 14:32 | <annevk> | Arguably "omit" is a better default and we had this idea that by default fetch() would be minimal, but we have changed quite a bit of that since then, but not revisited that |
| 14:33 | <annevk> | We should probably still expose "omit" for the extra-paranoid, but it shouldn't be the default I think |
| 14:33 | <wanderview> | I wonder if it would help or hurt if you could just encode the RequestInit values into attributes on tags |
| 14:33 | <wanderview> | then people could just be explicit |
| 14:34 | <annevk> | wanderview: there's been proposals for that, main question was how that would work in detail and what all the interactions with existing attributes would be |
| 14:34 | <wanderview> | <script type="module" requestinit="{ mode=same-origin credentials=same-origin }"> |
| 14:34 | <wanderview> | or something |
| 14:34 | <wanderview> | I dunno... could also be an admission of "we can't make good defaults, punt it to the web devs to figure out" |
| 14:35 | <wanderview> | or interpreted as that |
| 14:36 | <annevk> | Hah, they've already got plenty of data for that |
| 14:54 | <Domenic> | JakeA: type crossorigin=anonymous, not crossorigin="", and maybe it's clearer |
| 16:13 | <annevk> | Domenic: is the latter really non-conforming? Seems like a bug |
| 16:16 | <Domenic> | Hmm yeah I might be confused, "The empty string is also a valid keyword" |
| 17:44 | <annevk> | Domenic: set theory grmlb |
| 18:29 | <annevk> | JakeA: do you know about H/2 header compression? |
| 18:29 | <annevk> | JakeA: if the cookie is the same for each request, does it become smaller? |
| 18:34 | <JakeA> | annevk: hmm, I don't know. I didn't realise the compression was across requests, but it makes sense |
| 18:34 | <annevk> | JakeA: I'm not a 100% sure on this |
| 18:35 | <annevk> | JakeA: I haven't studied H/2 as much as I probably should |
| 18:36 | <gsnedders> | annevk: it should only be transmitted once, iirc |
| 19:19 | <annevk> | Domenic: thoughts on https://github.com/whatwg/html/pull/2521#discussion_r112269700? |
| 19:36 | <aklein> | Domenic: speaking of CORS and modules...I'm looking at https://github.com/w3c/web-platform-tests/blob/master/html/semantics/scripting-1/the-script-element/module/crossorigin.html and it doesn't look quite right to me |
| 19:37 | <aklein> | Domenic: in particular the "NoCORS"/"WithCORS" bits seem backwards at first glance |
| 19:37 | <aklein> | since "NoCORS" is paired with "different", while "WithCORS" is paired with "same" |
| 19:38 | <aklein> | I would have expected it to be the other way around, that NoCORS would only work with "same" origin |
| 19:49 | <mmn> | annevk: Thanks for merging my wpt. I'd be interested in your thoughts on https://bugzilla.mozilla.org/show_bug.cgi?id=1340477#c8 regarding whether browsers should pretend to do something useful with autocomplete tokens that they don't actually do anything with. |
| 19:50 | <mmn> | Supporting feature detection is usually The Right Way™ but my use cases aren't particularly strong |
| 19:54 | <annevk> | mmn: you mean not reflect tokens we do not support? Sounds reasonable |
| 19:54 | <annevk> | mmn: if something else, needinfo me and I'll get to it tomorrow |
| 19:55 | <mmn> | yeah, that's what I mean |
| 19:55 | <mmn> | return the default "on" or "off" in those cases (depending on the form's @autocomplete) |
| 19:56 | <Domenic> | aklein: will look at the test in a bit, but in general the terminology is a bit confusing. "No CORS" means "don't respect CORS restrictions". |
| 20:13 | <Domenic> | aklein: the tests seem OK to me from this perspective |
| 20:13 | <Domenic> | although confusingly named |
| 20:23 | <aklein> | Domenic: ah, interesting |
| 20:24 | <aklein> | Domenic: what do "different" and "same" mean? |
| 20:24 | <Domenic> | aklein: also not great... I guess, "CORS-same-origin" and "CORS-different-origin"? |
| 20:24 | <aklein> | and actually I didn't understand your first thing. the test description says "Error in CORS-different-origin script" |
| 20:25 | <Domenic> | https://html.spec.whatwg.org/#cors-same-origin |
| 20:25 | <aklein> | also confusing about this test is that "Error" means "we ran the script" |
| 20:26 | <aklein> | "different" == "cross" here? |
| 20:26 | <Domenic> | Although I think that response's type should be "error", not "opaque", so CORS-cross-origin isn't accurate (much less CORS-different-origin) |
| 20:27 | <Domenic> | I would support editing the test for clarity so that NoCORS/CORS-different-origin -> "missing CORS headers" and WithCORS/CORS-same-origin -> "has correct CORS headers" |
| 20:28 | <aklein> | but for the "different" case, shouldn't these be "Blocked script download"? |
| 20:28 | <Domenic> | Hmm then what is the difference between "NoCORS" vs. "BlockedMissingHeader" yeah |
| 20:28 | <aklein> | that is, tests 1 and 5 |
| 20:30 | <Domenic> | aklein: yes, these tests seem wrong, OK. |
| 20:30 | <Domenic> | From the spec's point of view https://github.com/w3c/web-platform-tests/blob/master/html/semantics/scripting-1/the-script-element/module/crossorigin-root-missingheader.sub.html and https://github.com/w3c/web-platform-tests/blob/master/html/semantics/scripting-1/the-script-element/module/crossorigin-root-different.sub.html should be identical |
| 20:30 | <aklein> | confusing _and_ wrong, good |
| 20:30 | <aklein> | yeah, that looks right to me |
| 20:40 | <aklein> | Domenic: happy to make a PR, do you think we should just remove those cases for now? I'm sorta curious if Edge "passes" this test, though |
| 20:41 | <Domenic> | aklein: I think we should change them to fail |
| 20:41 | <Domenic> | I am also curious |
| 20:41 | <zcorpan> | sad that the output of location.hash doesn't work as input to decodeURIComponent |
| 20:56 | <Domenic> | decodeURIComponent is known to be pretty broken |
| 20:57 | <Domenic> | I guess the URL API is the answer in theory |
| 21:49 | <jyasskin> | annevk: An HTTP2 stream can choose whether to cache or not-cache a header value for future use within that stream. Not-caching is designed to protect against CRIME-like attacks (http://httpwg.org/specs/rfc7541.html#rfc.section.7.1), and cookies in particular might be something we'd want to not-cache because of that. However, I haven't checked whether Chrome |
| 21:49 | <jyasskin> | stores cookies into the HPACK dynamic table. |