2020-11-01 [17:51:46.0000] I think I'm going to take a break from writing my DOM API. I've been super busy, and also I want to work on a program of mine that haa actual users. 2020-11-02 [18:29:10.0000] TIL about rel="feed" (from above) [18:29:25.0000] I wonder if that ever got meaningful adoption or if it was too little too late [18:29:46.0000] might be a good excuse for me to finally figure out how to use http archive [18:30:50.0000] though not sure dom attributes and/or or specifically is indexed by it [18:34:48.0000] seems not, based on the mysql schema file [02:49:15.0000] Let's say I have a select element with options [02:49:31.0000] And there is an option with [02:49:49.0000] What would that mean, is this an error, or what is the value? [02:50:36.0000] croraf: pretty sure the HTML Standard covers that in detail, but I forgot what it says exactly [03:45:19.0000] annevk, https://html.spec.whatwg.org/#attr-option-value I check this. What does that mean [03:45:54.0000] Oh I see now. [03:46:03.0000] "The value attribute provides a value for element. The value of an option element is the value of the value content attribute, if there is one, or, if there is not, the value of the element's text IDL attribute." [03:46:49.0000] So if I set the value attribute it is used as the value. If I don't the text (the content) is used instead. [03:50:42.0000] Now, in the case I asked for, the value attribute is present but without being assigned to anything. [04:12:17.0000] it is an empty string [04:49:41.0000] ondras, thanks, have you tried it, or how do you know? [04:49:54.0000] are any attributes defined without the value set to empty string? [04:53:27.0000] I tried, and it indeed seems to be an empty string. I guess for any attribute without the value being set it is implicitly set to "" [04:55:28.0000] the spec tells that as well [04:57:55.0000] https://html.spec.whatwg.org/#attributes-2 [04:58:01.0000] The value is implicitly the empty string. [05:01:18.0000] ondras, cool, ty very much [11:56:39.0000] Do we know of any context in which scripts can execute in an HTML context in a modern brower (specifically Safari 14), but document.head is undefined by means other than e.g. something explicitly corrupting the document variable? [11:57:19.0000] I thought head and body exist implicitly always as of HTML5 and thus these can't be undefined, or at least head can't be undefined from a script executing async, linked from inside [12:07:02.0000] Krinkle: it wouldn't be undefined but null, if a script removes the , or if you're in an XML doc without a head [12:07:56.0000] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8649 [12:24:37.0000] The only ways I can think of to get undefined are: (1) `document` is not actually a `Document` somehow, which probably falls into your excluded category; (2) situations involving detached browsing contexts where browsers often seem to violate the spec (e.g. `const d = iframe.contentDocument; iframe.remove(); d.head` might give undefined sometimes, especially in Safari. 2020-11-03 [19:56:38.0000] zcorpan: Domenic: Thanks, that helps :) - downstream ticket is https://phabricator.wikimedia.org/T266708 [19:56:45.0000] (: TypeError: document.head.appendChild is not a function) [19:57:03.0000] Received regularly albeit at a low frequency on en.wikipedia.org from Mobile Safari [20:00:35.0000] document not being Document seems unlikely given the diversity of clients, but given we do support greasemoney-style user scripts within the platform, that might still be a possibility. I'll see if I can find reports from users without a login session to rule that out. [20:01:41.0000] iframes might be it, we don't do that in our own code afaik, I can't imagine why, but again it's possible a user script might do that as a hacky way to accomplish some legacy thing without using the API through some kind of headless simulation of a user action for an automated/assisted editor workflow. [22:13:44.0000] Might also wanna check when WebKit added document.head support [04:59:03.0000] TIL: Safari is intolerant of https://hsivonen.com/test/ . It's OK with nginx serving flat files, it's OK with nginx proxying Jetty. Not OK with nginx proxying Apache. [05:11:26.0000] Surely it's not the server but something particular in the response? [05:11:51.0000] Anyway, I'd recommend filing a bug as they probably want to address that [15:27:43.0000] https://stackoverflow.com/questions/64671178/scroll-event-not-fired-in-chrome-when-document-hidden-is-true-any-workarounds [15:28:05.0000] > The scroll event is never fired by Chrome when the page is hidden, despite the page is actually scrolling. That looks like something they implemented to reduce cpu and network usage for pages that are not visible. [15:28:20.0000] is that behavior spec-conforming? 2020-11-04 [16:10:13.0000] MikeSmith: hmm. yes. https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering - rendering is skipped, and scroll events happen from there [17:39:26.0000] zcorpan: thanks [03:48:45.0000] annevk: AFAICT, it's all responses that are proxied by nginx from Apache as opposed to being served by nginx directly or proxied by nginx from Jetty. [03:52:00.0000] hsivonen: yeah, but that's all fairly high-level, no? Surely there's detail that Safari trips over that it would always trip over, regardless of which server did it [03:52:12.0000] a detail, even [04:12:26.0000] There has to be some detail, but Safari does not surface it to me. Filed https://bugs.webkit.org/show_bug.cgi?id=218560 [04:12:54.0000] This interferes with interoperability testing. [07:03:02.0000] hsivonen: https://stackoverflow.com/questions/51266188/nsposixerrordomain100-error-on-safari-when-try-to-open-https [07:46:43.0000] Which links https://megamorf.gitlab.io/2019/08/27/safari-nsposixerrordomain-100-error-with-nginx-and-apache/ [07:47:28.0000] Ah, Safari is actually conforming and other browsers are more like "whatever" [07:47:51.0000] I guess H/2 didn't get the test suite it deserved [08:20:11.0000] zcorpan: Thanks. That resolved the issue. [08:20:30.0000] Not the best error message from Safari... [08:25:23.0000] Also seems like a bad idea for nginx to pass on headers that are hop-specific. [08:42:58.0000] I guess even for H/2 the HTTP WG is still not following the practice of going back and updating their specs to align with how they actually ended up getting implemented [08:49:14.0000] if the possibility that Safari is going to end up being non-conforming in the same way as other UAs seems more likely than that other UAs will change to become more strictly conforming, then I would naively think the group would be considering to change the spec [10:19:12.0000] annevk: are you going to take up maintainership of the CSP spec? because if so I have a bunch of issues I would like to see addressed :D [10:19:26.0000] Bakkot: nope [10:19:31.0000] alas [10:19:35.0000] Bakkot: I just happen to have commit access [10:32:45.0000] TabAtkins: somehow I borked my Bikeshed installation, it complains about html5lib being the wrong version and to do the pip3 install thing, but that gives success... [10:33:19.0000] TabAtkins: this was after pulling the most recent 30 or so commits [10:36:12.0000] Hm, usually this means your Bikeshed executable is pointing to some different path. If you run `type bikeshed`, do you get a hashed path? [10:36:41.0000] "bikeshed is hashed (/usr/local/bin/bikeshed)" [10:37:56.0000] try deleting, then running the pip install again? [10:43:42.0000] TabAtkins: thanks, I have it working now [10:44:41.0000] cool. that's a really annoying problem that several people have run into, where bash caches an executable and you can't update it to the newer thing [10:44:42.0000] Bakkot: want to review https://github.com/w3c/webappsec-csp/pull/445 though? :-) [10:44:52.0000] i don't understand how i can avoid it :( [10:46:32.0000] I guess the only suggestion I have is to maybe document it, but I wouldn't have found it [10:47:01.0000] Maybe the follow-up suggestion would be to put that in the pip3 install command suggestion [11:21:50.0000] annevk: I'm not familiar enough with bikeshed to review that one, I'm afraid [11:21:54.0000] also I'm not a maintainer or anything [11:22:34.0000] I might just merge it unless Domenic feels curious [11:22:59.0000] That way I can update Fetch tomorrow [15:00:43.0000] Wow, still finding interop bugs in the foundations of event dispatch in 2020? https://github.com/jsdom/jsdom/issues/3070 [15:43:55.0000] MikeSmith/hsivonen: The HTTPWG may just not know about the issue. They're starting an http2bis effort, described at https://lists.w3.org/Archives/Public/ietf-http-wg/2020OctDec/0064.html. I'll raise the question there. [15:44:29.0000] jyasskin: cool, thanks [15:47:14.0000] https://github.com/httpwg/http2-spec/issues/789 [15:49:03.0000] Outside of an update cycle, an errata is probably the right feedback mechanism. [15:49:27.0000] Or just an email, I guess. 2020-11-05 [21:07:26.0000] Domenic: I suspect that’s fallout from shadow trees and that Chrome/Fx still haven’t fixed their bug but will double check later [23:01:07.0000] jyasskin: thanks [00:24:40.0000] https://bz.apache.org/bugzilla/show_bug.cgi?id=59311#c9 reminds me of Apache-sent text/plain for binary file vs. browsers, therefore, not treating text/plain as authoritative [00:27:23.0000] /me sighs [01:45:11.0000] /me sees https://bugs.webkit.org/show_bug.cgi?id=212069 [01:45:21.0000] Does WebKit support cross-origin isolation? [01:46:54.0000] https://bugs.webkit.org/show_bug.cgi?id=215407 [01:51:05.0000] thanks zcorpan, left a comment on the first bug [01:53:37.0000] 👍 [02:29:12.0000] is it possible for the root element to somehow not take up the entire viewport (through non-default styles)? [02:30:03.0000] mathiasbynens: I think by default it doesn't do that [02:30:07.0000] mathiasbynens: just give it a border [02:30:57.0000] (background and overflow might be confusing here, but they end up applying to the viewport instead when set on the root + special behavior for HTML's body element) [02:33:42.0000] oh my this renders differently on Chrome vs. Firefox [02:33:43.0000] data:text/html,