freenode :: #whatwg

19 Apr 2017
00:03TabAtkinsMikeSmith: plinss says the issue is fixed
00:03MikeSmithTabAtkins: oh cool
00:03* MikeSmith takes a look
00:06MikeSmithTabAtkins: curl https://api.csswg.org/bikeshed/ -F url=https://raw.githubusercontent.com/w3c/ServiceWorker/246340fce702bab2cce35b046f090606389b279a/docs/index.bs -F output=err
00:07MikeSmithstill gives the error:
00:07MikeSmithLINK ERROR: No 'attr-value' refs found for 'serviceworker' with for='link/rel'.
00:07MikeSmith<a data-link-type=&quot;attr-value&quot; data-lt=&quot;serviceworker&quot; data-link-for=&quot;link/rel&quot;>serviceworker</a>
00:07MikeSmithI guess theres some latency in updating?
00:08TabAtkinsShould have been fixed yesterday. :/
00:10TabAtkinsdebugging now
00:11MikeSmithk
00:23MikeSmithTabAtkins: 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:23Krinkleannevk: Seems lists.whatwg.org isn&#39;t working, forced HTTPS in my browser, but only responds to HTTP. This means confirmation links for moderation, subscribe and unsubscribe don&#39;t work.
00:23KrinkleTricked clicking the link by curl&#39;ing the url instead.
00:23TabAtkinsMikeSmith: Not really; you need a historical version of the linking database, basically.
00:24MikeSmithOK yeah I figured but wanted to confirm
00:24Krinkle(I don&#39;t know how maintains this, feel free anyone else to reply :) )
00:24MikeSmithTabAtkins: the specific failure is this:
00:24MikeSmithLINK ERROR: No &#39;dfn&#39; refs found for &#39;the worker&#39;s documents&#39;.
00:24MikeSmith<a data-link-type=&quot;dfn&quot; data-lt=&quot;the workers Documents&quot;>the workers Documents</a>
00:25MikeSmithTabAtkins: 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:25MikeSmithanyway, will look some more
00:25MikeSmithKrinkle: known issue
00:26MikeSmithKrinkle: cannot remember the details of the cause, but lists.whatwg.org has not worked since we moved to HTTPS, ever
00:26MikeSmithso links to all the old indexed e-mail messages from those archives are broken
00:27MikeSmithbut we have a mirror at https://lists.w3.org/Archives/Public/public-whatwg-archive/
00:27MikeSmithah youre asking about just the Web-based subscribe UI
00:28MikeSmithI have not tried to used that. I wonder if others have been able to, but I would think not, given the underlying issue
00:43KrinkleMikeSmith: Yeah, the problem is people can&#39;t unsubscribe anymore.
00:43TabAtkinshehehe
00:46MikeSmithKrinkle: Theres no fix that Im aware of. Well other than moving the hosting. I think its been year or maybe even two since Dreamhost told Ian they would be fixing it soon or something like that
00:47MikeSmithor however long its been it was moved to HTTPS
00:50TabAtkinsMikeSmith: I mean, you can at least remove them manually from the DB?
00:52MikeSmithsubcribers?
00:52MikeSmithmaybe Ian can
00:52MikeSmithor maybe annevk has admin access to it now, I dunno
01:52MikeSmithKrinkle: so yeah Im told the only way to unsubscribe from the list is by e-mail to the unsubscribe-whatwg@whatwg.org (or whatever) address, which I think is shown in the footer of every messsage
01:54KrinkleMikeSmith: &quot;whatwg-unsubscribe@whatwg.org&quot; actually, and not in the footer anymore for some time (config setting in Mailman).
01:54KrinkleMikeSmith: And then you get a confirmation mail with a link that doesn&#39;t work :)
01:54Krinkleunless you know how to bypass HSTS
01:54Krinkle(e.g. via curl)
01:54MikeSmithoh :(
01:54Krinklehttps://whatwg.org/mailing-list#specs
01:55Krinklethe link is HTTP but Chrome enforces it to HTTPS because whatwg.org has HTSTS with *. subdomains enforced
01:55MikeSmithKrinkle: what happens if you just reply to the confirmation e-mail?
01:56MikeSmiththat is what those instructions say to do
01:56MikeSmithoh
01:56MikeSmith> 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:57MikeSmithso the instructions explicitly say to not follow links to the Web site
01:57KrinkleMikeSmith: https://gist.github.com/Krinkle/ce71cff47fcf2a7fb6b923518c185347
01:57KrinkleI don&#39;t see that instruction.
01:58KrinkleAh, on the website for subscribing
01:58Krinkleyeah good point
01:58MikeSmithyeah
01:58KrinkleI didn&#39;t see that
01:58MikeSmithyeah we should put it in bold I guess
01:58KrinkleMailmail 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:58MikeSmithI did not notice it either at first
01:59KrinkleConfigurable for each individual email list even
01:59MikeSmithmaybe e-mail Ian about that
02:00MikeSmithif you can tell him exactly where it can be changed I reckon he would be happy to change it
02:00MikeSmithand provide some suggested text
02:05Krinklek, I&#39;ll try to do that later today or tomorrow. Thanks
02:06MikeSmithcheers
06:00zcorpanfoolip: how does https://html.spec.whatwg.org/#dom-texttrack-inbandmetadatatrackdispatchtype relate to the new <audio> metadata proposal?
06:13MikeSmithTabAtkins: I see the xref thing got fixed
06:13MikeSmithhttps://rawgit.com/w3c/ServiceWorker/fcf2835093c4e4caf213d56e1d28f3c5c06c7aaa/docs/index.html#link-type-serviceworker
06:14TabAtkinsYeah.
06:14TabAtkinsplinss&#39;s fix wasn&#39;t spread to all of his parsers. ^_^
06:14MikeSmiththe link at contains the keyword &quot;_serviceworker_&quot;
06:14MikeSmithah cool
06:14MikeSmiththanks much
06:14MikeSmithand thanks to plinss too
06:14MikeSmithTabAtkins: btw I wonder if I can attend the CSS WG f2f tomorrow?
06:15MikeSmithis the room big enough?
06:15TabAtkinsAsk Rossen/astearns. (They&#39;ll say yes.)
06:15MikeSmithk
06:15TabAtkinsYes, it is (as an observer)
06:15MikeSmithwhich building yall in?
06:15MikeSmithEast? North?
06:16MikeSmithOld building? Or newer one?
06:16MikeSmithastearns: OK if I attend tomorrow?
06:16astearnsyes
06:16MikeSmithyay
06:16* astearns damn, proved tab right
06:16MikeSmiththanks
06:16TabAtkinsToday is East (6 on the website map), but I know we&#39;ll be in a different building at some point; dunno if it&#39;s tomorrow or Friday.
06:17MikeSmithhaha
06:17MikeSmithTabAtkins: ok, thanks
06:32astearnsMikeSmith: tomorrow we&#39;re in &quot;Faculty Research Building A and B room&quot;
06:34MikeSmithastearns: ah OK thanks yeah that buildings close by
06:34MikeSmiththough I cant remember that we ever had a meeting in that building before
08:11smaughow stable https://html.spec.whatwg.org/multipage/forms.html#attr-fe-autocomplete-section might be?
08:13annevksmaug: Chrome implemented it at some point I think
08:13annevksmaug: we haven&#39;t touched it since Ian maintained it
08:13smaugok
08:14smaugsection-* feels a bit odd, but ok fine, if it has been implemented
08:14annevksmaug: oh, I thought you meant autocomplete in general, I don&#39;t know for sure about section-, though I suspect it&#39;s the same
08:15* annevk misread the URL
08:21annevkSimonSapin: be sure to not use CSSString for things that need to be USVString, such as URLs
08:22SimonSapinannevk: I think the only URLs in CSSOM are inside url(&quot;&quot;) inside CSS syntax
08:22annevkSimonSapin: there&#39;s no API for those?
08:22annevkSimonSapin: and I&#39;d imagine there&#39;s CSSImportRule and some things around CSSStyleSheet that would be affected
08:23SimonSapinoh right, forgot about that one. CSSImportRule currently has: readonly attribute DOMString href;
08:24SimonSapinStylesheet also has href
08:24TabAtkinsWe can change that I think.
08:24annevkIt&#39;s sorta fine since it&#39;s readonly, but better to be specific
08:24SimonSapinUSVString for href?
08:24annevk(That is to say, you can use any for readonly attribute and it would still be the same.)
08:25annevkSimonSapin: yes
08:26SimonSapinstylesheet.insertRule(&quot;@import url(&#39;\uD800&#39;);&quot;, 0) can sneak surrogates in there
08:26SimonSapinsame as document.write(&quot;<a href=&#39;\uD800&#39;>&quot;) though
08:48zcorpanSimonSapin: annevk: are DOMString and USVString https://heycam.github.io/webidl/#dfn-distinguishable ? (or can they be?)
08:49annevkzcorpan: ah, interesting point, I guess you can&#39;t typedef them after all
08:49zcorpanI guess webidl should have a string-like category there
08:50zcorpancan typedef to DOMString and say in prose that USVString instead is also conforming
08:51TabAtkinsSimonSapin: *Can* you smuggle that in? Per Syntax, you have to do a &quot;decode&quot;; that&#39;ll get rid of the surrogate, no?
08:52SimonSapinTabAtkins: only in https://drafts.csswg.org/css-syntax/#input-byte-stream when starting with bytes, so not in CSSOM
08:52zcorpanTabAtkins: syntax parse entry points can be called with a string (for cssom)
08:53annevkThe URL parser expects scalar values so you better remove lone surrogates before you invoke that
08:53SimonSapinhttps://drafts.csswg.org/css-syntax/#tokenization says its input is code points
08:54TabAtkinsYeah, per spec you totes can&#39;t call any of the parsing algos with a bytestream.
08:55SimonSapinannevk: looks like https://drafts.csswg.org/css-values/#urls doesnt have an imperative algorithm that explicitly invokes the URL parser
08:55TabAtkins(Yeah, it doesn&#39;t yet; I have a 2-year-old issue on me to do that.)
09:02SimonSapinannevk: so I cant typedef CSSOMString?
09:03annevkSimonSapin: nope, I was wrong
09:04annevkSimonSapin: you can typedef it to DOMString and add some text that implementations can also use USVString
09:04TabAtkins(Or vice versa - plan for the future.)
09:04annevkSimonSapin: but you cannot do (DOMString or USVString)
09:05annevkTabAtkins: yeah, I&#39;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:06annevkI&#39;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:30annevkMikeSmith: when I use file upload on https://checker.html5.org/ without a file extension it seems to default to XML, though a) it doesn&#39;t tell me it&#39;s doing this and b) there&#39;s no way to override it
10:35annevkWHATWG&#39;s working mode, finally in HTML: https://github.com/whatwg/whatwg.org/pull/25
11:51MikeSmithannevk: try the checker again now
11:52annevkfoolip: I addressed your agent feedback, I hope
11:53annevkMikeSmith: cool
11:53annevkMikeSmith: the other thing I needed but that&#39;s rather esoteric I guess is overriding the charset
11:53MikeSmithannevk: for that theres a query param
11:53MikeSmithgimme a second to find the name
11:54annevkMikeSmith: nah it&#39;s fine, I don&#39;t need it anymore I think
11:54MikeSmithOK
12:59noxannevk: In case you wonder,
12:59JakeADomenic: Is the intent for <script type=&quot;module&quot;> to omit credentials for same-origin scripts?
12:59noxthat ticket on the URL standard about # in userinfo and whatnot stemmed from https://github.com/servo/rust-url/pull/293#issuecomment-295035947.
13:01annevknox: yeah I saw
13:01annevknox: I wonder what SimonSapin thought the ambiguity was
13:01annevknox: I hope he didn&#39;t just try to make it somebody else their problem
13:02* nox says nothing.
13:12JakeADomenic: seems a bit weird to have to set crossorigin to cause modules to send cookies to my own origin
13:42JakeADomenic: Looks like this change happened in https://github.com/whatwg/html/pull/607, but the comment suggests it was a non-normative change
13:43JakeAfwiw Safari appears to implement this as spec&#39;d
13:44annevkJakeA: I&#39;m pretty sure it&#39;s not changed there and was always like this
13:45annevkJakeA: 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:45annevkJakeA: that&#39;s also how fetch() works by default
13:47JakeAannevk: You&#39;re right, the CORS setting was converted into a credentials mode before that PR
13:49JakeAannevk: I&#39;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:50annevkMaybe we should do away with &quot;omit&quot; and just use &quot;same-origin&quot; for credentials all the time
13:50annevkUnless folks optin to &quot;include&quot; obv
13:50JakeA<script type=&quot;module&quot; src=&quot;blah.js&quot;> - no credentials
13:50JakeA<script type=&quot;module&quot; src=&quot;blah.js&quot; crossorigin> - with credentials
13:51annevkJakeA: hmm yeah
13:51JakeABut I don&#39;t want to rock the boat too much. I&#39;d rather have modules than not :D
13:52annevkJakeA: file an issue? This seems like a fix that can be made post-shipping too
13:52JakeAShall do
13:52annevkJakeA: removing credentials is hard, but adding is okay (opposite of exceptions)
14:07JakeAannevk: Domenic: https://github.com/whatwg/html/issues/2557
14:19wanderviewJakeA: that module behavior is unlike other tags that have a crossorigin attribute, right? they all use same-origin credentials mode by default, right?
14:19wanderviewmostly because they existed before fetch spec I guess
14:20wanderview^mostly^maybe
14:22JakeAwanderview: 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:23wanderviewah, ok
14:23wanderviewJakeA: thanks, sorry for my confusions
14:23wanderviewconfusion
14:23JakeAit is pretty confusing :D
14:23wanderviewI guess modules are just &quot;different&quot;
14:31annevkI think it&#39;s mostly my fault
14:32annevkArguably &quot;omit&quot; 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:33annevkWe should probably still expose &quot;omit&quot; for the extra-paranoid, but it shouldn&#39;t be the default I think
14:33wanderviewI wonder if it would help or hurt if you could just encode the RequestInit values into attributes on tags
14:33wanderviewthen people could just be explicit
14:34annevkwanderview: there&#39;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:34wanderview<script type=&quot;module&quot; requestinit=&quot;{ mode=same-origin credentials=same-origin }&quot;>
14:34wanderviewor something
14:34wanderviewI dunno... could also be an admission of &quot;we can&#39;t make good defaults, punt it to the web devs to figure out&quot;
14:35wanderviewor interpreted as that
14:36annevkHah, they&#39;ve already got plenty of data for that
14:54DomenicJakeA: type crossorigin=anonymous, not crossorigin=&quot;&quot;, and maybe it&#39;s clearer
16:13annevkDomenic: is the latter really non-conforming? Seems like a bug
16:16DomenicHmm yeah I might be confused, &quot;The empty string is also a valid keyword&quot;
17:44annevkDomenic: set theory grmlb
18:29annevkJakeA: do you know about H/2 header compression?
18:29annevkJakeA: if the cookie is the same for each request, does it become smaller?
18:34JakeAannevk: hmm, I don&#39;t know. I didn&#39;t realise the compression was across requests, but it makes sense
18:34annevkJakeA: I&#39;m not a 100% sure on this
18:35annevkJakeA: I haven&#39;t studied H/2 as much as I probably should
18:36gsneddersannevk: it should only be transmitted once, iirc
19:19annevkDomenic: thoughts on https://github.com/whatwg/html/pull/2521#discussion_r112269700?
19:36akleinDomenic: speaking of CORS and modules...I&#39;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&#39;t look quite right to me
19:37akleinDomenic: in particular the &quot;NoCORS&quot;/&quot;WithCORS&quot; bits seem backwards at first glance
19:37akleinsince &quot;NoCORS&quot; is paired with &quot;different&quot;, while &quot;WithCORS&quot; is paired with &quot;same&quot;
19:38akleinI would have expected it to be the other way around, that NoCORS would only work with &quot;same&quot; origin
19:49mmnannevk: Thanks for merging my wpt. I&#39;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&#39;t actually do anything with.
19:50mmnSupporting feature detection is usually The Right Way but my use cases aren&#39;t particularly strong
19:54annevkmmn: you mean not reflect tokens we do not support? Sounds reasonable
19:54annevkmmn: if something else, needinfo me and I&#39;ll get to it tomorrow
19:55mmnyeah, that&#39;s what I mean
19:55mmnreturn the default &quot;on&quot; or &quot;off&quot; in those cases (depending on the form&#39;s @autocomplete)
19:56Domenicaklein: will look at the test in a bit, but in general the terminology is a bit confusing. &quot;No CORS&quot; means &quot;don&#39;t respect CORS restrictions&quot;.
20:13Domenicaklein: the tests seem OK to me from this perspective
20:13Domenicalthough confusingly named
20:23akleinDomenic: ah, interesting
20:24akleinDomenic: what do &quot;different&quot; and &quot;same&quot; mean?
20:24Domenicaklein: also not great... I guess, &quot;CORS-same-origin&quot; and &quot;CORS-different-origin&quot;?
20:24akleinand actually I didn&#39;t understand your first thing. the test description says &quot;Error in CORS-different-origin script&quot;
20:25Domenichttps://html.spec.whatwg.org/#cors-same-origin
20:25akleinalso confusing about this test is that &quot;Error&quot; means &quot;we ran the script&quot;
20:26aklein&quot;different&quot; == &quot;cross&quot; here?
20:26DomenicAlthough I think that response&#39;s type should be &quot;error&quot;, not &quot;opaque&quot;, so CORS-cross-origin isn&#39;t accurate (much less CORS-different-origin)
20:27DomenicI would support editing the test for clarity so that NoCORS/CORS-different-origin -> &quot;missing CORS headers&quot; and WithCORS/CORS-same-origin -> &quot;has correct CORS headers&quot;
20:28akleinbut for the &quot;different&quot; case, shouldn&#39;t these be &quot;Blocked script download&quot;?
20:28DomenicHmm then what is the difference between &quot;NoCORS&quot; vs. &quot;BlockedMissingHeader&quot; yeah
20:28akleinthat is, tests 1 and 5
20:30Domenicaklein: yes, these tests seem wrong, OK.
20:30DomenicFrom the spec&#39;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:30akleinconfusing _and_ wrong, good
20:30akleinyeah, that looks right to me
20:40akleinDomenic: happy to make a PR, do you think we should just remove those cases for now? I&#39;m sorta curious if Edge &quot;passes&quot; this test, though
20:41Domenicaklein: I think we should change them to fail
20:41DomenicI am also curious
20:41zcorpansad that the output of location.hash doesn&#39;t work as input to decodeURIComponent
20:56DomenicdecodeURIComponent is known to be pretty broken
20:57DomenicI guess the URL API is the answer in theory
21:49jyasskinannevk: 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&#39;d want to not-cache because of that. However, I haven&#39;t checked whether Chrome
21:49jyasskinstores cookies into the HPACK dynamic table.
20 Apr 2017
No messages
   
Last message: 156 days and 17 hours ago