| 06:18 | <domfarolino> | annevk: Often I slowly click "resolve conversation" as I knock out individual review items on a PR locally. This is staggered due to interrupting homework or other things. If that ends up kicking off like 20 emails/notifs, lmk and I won't do that lol |
| 08:47 | <annevk> | domfarolino: I don't get email from GitHub, I only see it if it's reflected in /notifications |
| 08:51 | <annevk> | Domenic: I published Quirks as it seems you forgot that |
| 08:56 | <nox> | annevk: I think Chrome and the spec disagree about <link rel="modulepreload">, and they are the only major browser to implement that right? |
| 08:58 | <nox> | When inserting <link rel="modulepreload" href="data:text/html,"> in a document, shouldn't step 12 of https://html.spec.whatwg.org/multipage/links.html#link-type-modulepreload%3Afetch-and-process-the-linked-resource-2 immediately fire an error event? |
| 08:58 | <nox> | Is it just a case of the spec being wrong? Step 3 fires an error event too but it does so by queuing a task, is it just missing that piece in step 12 and 13? |
| 09:00 | <annevk> | nox: fetch a module script is a weird in parallel-like algorithm |
| 09:00 | <annevk> | nox: step 12 happens from a task |
| 09:00 | <annevk> | nox: it's on the list of things Domenic wants to refactor |
| 09:00 | <nox> | annevk: I feel like the weirdness sho-- ok |
| 09:00 | <nox> | If that's something to refactor I have nothing more to say then. :) |
| 09:01 | <annevk> | nox: Firefox might also support that btw |
| 09:01 | <annevk> | nox: but load/error events should never be sync ideally |
| 09:02 | <nox> | annevk: MDN said it doesn't but the support table was gigantic so maybe I didn't read it correctly, shrug anyway, if the events are not sync I can't observe them from a script being inserted at the same time so I don't care. |
| 09:02 | <nox> | annevk: FYI https://github.com/whatwg/html/pull/4354#issuecomment-463693419 :) |
| 09:06 | <nox> | annevk: "<meta http-equiv> — How do I even observe those from JS?" I should be able to observe http-equiv="default-style" right? |
| 09:09 | <annevk> | nox: yeah, I guess that should flip the disabled nature of a style sheet which you can observe synchronously |
| 09:09 | <nox> | Nice |
| 09:10 | <annevk> | nox: I guess modulepreload you could detect in theory if the script removes it? Unless removing is specified to have an effect as well |
| 09:11 | <nox> | annevk: Ah right, if it's removed before it's handled, no event should be fired? |
| 09:13 | <nox> | annevk: Nah the event should still be fired I think. |
| 09:13 | <nox> | It's not like the spec says "if it's not connected anymore by this point, just don't do anything anymore". |
| 09:14 | <annevk> | nox: yeah, but if they use some common code path and nobody tested for it, but I'm not going to block your stuff on testing for this |
| 09:15 | <nox> | annevk: Thanks. 😂 |
| 09:16 | <nox> | How come there is no emoji for "wipe sweat off forehead" |
| 10:06 | <zcorpan> | annevk: loading the quirks spec RD fails to load the stylesheet... |
| 10:06 | <zcorpan> | The FetchEvent for "https://resources.whatwg.org/spec.css"; resulted in a network error response: an "opaque" response was used for a request whose type is not no-cors |
| 10:06 | <zcorpan> | spec.css:1 Failed to load resource: net::ERR_FAILED |
| 10:07 | <annevk> | zcorpan: I thought RDs did not have style sheets |
| 10:07 | <annevk> | I guess it does |
| 10:08 | <zcorpan> | <link crossorigin href="https://resources.whatwg.org/spec.css"; rel="stylesheet"> |
| 10:08 | <zcorpan> | <link crossorigin href="https://resources.whatwg.org/review-draft.css"; rel="stylesheet"> |
| 10:09 | <annevk> | zcorpan: ah, if you clear the service worker it'll work |
| 10:10 | <annevk> | zcorpan: it seems we forgot to clear the cache when we updated the service worker to use CORS for all the things |
| 10:11 | <annevk> | Caching is hard... |
| 10:11 | <annevk> | Or cache invalidation, rather |
| 10:12 | <zcorpan> | annevk: hmm ok. does the serviceworker need a new version or something? |
| 10:14 | <annevk> | zcorpan: maybe, it does seem like the cache key was updated since this change, not sure what's going on |
| 10:15 | <annevk> | zcorpan: no, that seems to be automatically generated based on whatever the latest version of the backing script is |
| 10:19 | <annevk> | zcorpan: I see what the problem is, we match() against all caches, including prior caches |
| 10:20 | <annevk> | I am surprised Mr. Service Worker didn't notice that! |
| 10:21 | annevk | attempts to write a patch |
| 10:29 | <nox> | annevk: All browsers handle meta after script, good thing I tested for that. |
| 10:31 | <annevk> | zcorpan: https://github.com/whatwg/whatwg.org/pull/239 |
| 10:44 | <annevk> | foolip: zcorpan: if around, could you stamp https://github.com/whatwg/html/pull/4366? |
| 10:44 | <annevk> | foolip: zcorpan: (I'll merge) |
| 10:48 | <zcorpan> | annevk: reviewed |
| 10:49 | <zcorpan> | annevk: this is supposed to prune old cache entries, right? |
| 10:49 | <zcorpan> | return Promise.all(keys.filter(key => key !== cacheKey).map(key => caches.delete(key))); |
| 10:50 | <annevk> | zcorpan: yes and it will, but it races with returning a response I think |
| 10:50 | <zcorpan> | ok |
| 11:21 | <bblfish> | Hi, I am doing research on languages and semantics. I noticed that the HTML5 standard speaks about meaning, and was wondering if there was some kind of formal semantics for it that I could refer to... |
| 11:30 | <annevk> | bblfish: example of formal semantics? |
| 11:32 | <bblfish> | annevk: I guess it could be something topological. I thought I had seen something about areas of rectangles somewhere... |
| 11:32 | <bblfish> | perhaps it is just informal, which is also fine for my needs |
| 11:39 | <bblfish> | "Because HTML conveys meaning, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole page, but with the headings in bold." |
| 11:41 | <bblfish> | That passage is quite nice. |
| 11:42 | <bblfish> | It looks like it is quite recent, as I don't see that passage in the html5.3 on w3c |
| 11:43 | <bblfish> | I got the passage from https://html.spec.whatwg.org/#semantics-2 |
| 11:44 | <bblfish> | btw, I have to write my thesis in LaTeX, and was wondering how I could site that in bibtex... (academia stuff ...) |
| 11:46 | <nox> | annevk: I think I found yet another edge case. |
| 11:48 | <nox> | annevk: Make an empty script. Insert a script and two text nodes in empty script. Make the inserted script replace the second text node by itself. |
| 11:48 | <nox> | (or a different text node, that's not important here) |
| 11:49 | <nox> | Wait no, it's not a problem anymore with deferredStepsQueue, nice. |
| 11:49 | <nox> | And the HTML spec does absolutely nothing when nodes are removed from a script element, so it's doubly not a problem, disregard me. |
| 12:02 | <annevk> | bblfish: I don’t really know, sorry |
| 12:02 | <annevk> | nox: 👍🏻🎉 |
| 12:15 | <annevk> | nox: so <meta http-equiv=default-style> is queued as well? I guess we need to test removal then? |
| 12:18 | <nox> | Mmh? |
| 12:18 | <nox> | annevk: Damn my comment is confusing. |
| 12:20 | <nox> | annevk: No the test passes everywhere it seems. |
| 12:20 | <nox> | I just wrote the opposite of what I wanted to say, I think. |
| 12:21 | <nox> | annevk: I will double check when I’m back from lunch. |
| 12:22 | <nox> | Just realised I didn’t even push the damn test ugh |
| 13:57 | <nox> | annevk: So yes, it's queued. |
| 13:58 | <nox> | annevk: Fixed my comment https://github.com/whatwg/html/pull/4354#issuecomment-465078124 |
| 13:58 | <nox> | Safari obviously handles it after script, given it inserts nodes from fragments one by one. |
| 13:58 | <nox> | And I pushed the WPT test. |
| 13:58 | <annevk> | nox: but if you have a script after the meta it'll execute after the style sheet change? |
| 13:59 | <nox> | annevk: Let me quickly check that. |
| 14:00 | <nox> | annevk: …no except in Safari, omg this is so bad |
| 14:01 | <annevk> | so it's from a task, possibly async in some browsers |
| 14:01 | <nox> | annevk: Not exactly. |
| 14:01 | <annevk> | It has to be one or the other, no? |
| 14:01 | <nox> | annevk: If I comment https://github.com/web-platform-tests/wpt/blob/9c8d1abc1f409bd01799cac2409367f5a5a4248c/dom/nodes/Node-appendChild-script-and-default-style-meta-from-fragment.html#L25 |
| 14:02 | <nox> | Never mind I checked the wrong thing when I commented that. |
| 14:02 | <nox> | Let me check what .display says after the entire appendChild call. |
| 14:03 | <nox> | annevk: Ok yes, it's a queued task in Firefox |
| 14:03 | <nox> | and in Chrome too. |
| 14:12 | <nox> | annevk: Wait no, |
| 14:12 | <nox> | annevk: I'm not even sure Firefox supports http-equiv="default-style" now… |
| 14:15 | <bblfish> | Ah yes, I was thinking that the css box model could be thought of as a model for html. |
| 14:17 | <annevk> | nox: hmm https://software.hixie.ch/utilities/js/live-dom-viewer/saved/6654 and https://software.hixie.ch/utilities/js/live-dom-viewer/saved/6655 suggest it does to me |
| 14:17 | <nox> | Mmh… |
| 14:18 | <nox> | Wtf am I doing wrong then… |
| 14:18 | <annevk> | nox: contrast with https://software.hixie.ch/utilities/js/live-dom-viewer/saved/6657 |
| 14:18 | <annevk> | nox: there might be some issues here with dynamic updates |
| 14:19 | <annevk> | nox: if I start playing with the <meta> element in that textarea some browsers persist the http-equiv stuff (though maybe that's how it should be) |
| 14:19 | <annevk> | zcorpan: testing blur() does nothing means something else has to do something |
| 14:19 | <annevk> | zcorpan: it means focus() has to result in something being focused |
| 14:21 | <nox> | annevk: That's so weird. |
| 14:21 | <nox> | annevk: If I open my test in Firefox, I can read "hello". |
| 14:22 | <nox> | annevk: Oh. I have a clue. |
| 14:23 | <nox> | Or not. |
| 14:24 | <nox> | annevk: "data:text/css,#div{display:none}" 😂 |
| 14:26 | <annevk> | nox: that # wants to be escaped |
| 14:26 | <nox> | Yep |
| 14:26 | <nox> | annevk: That's a bug in Safari too. |
| 14:27 | <annevk> | Oh, I thought only Chrome had that bug |
| 14:27 | <annevk> | That's too bad, though Chrome is close with regards to fixing it |
| 14:27 | <nox> | annevk: Chrome doesn't have that bug anymore AFAICT. |
| 14:28 | <nox> | annevk: I.e. if I don't escape '#', the div is never display:none. |
| 14:28 | <nox> | annevk: Next problem, |
| 14:29 | <annevk> | ok |
| 14:29 | <nox> | https://irccloud.mozilla.com/pastebin/v4cya5CY/ |
| 14:29 | <nox> | if it's a queued task, shouldn't the task run between the two tests, and my last assertion about .display be ok? |
| 14:29 | <nox> | s/the two tests/the two scripts/ |
| 14:29 | <annevk> | nox: script's are not queued as tasks |
| 14:30 | <nox> | annevk: I know that, but doesn't the loop run queued tasks between scripts or whatever? |
| 14:30 | <annevk> | nox: well, I guess the parser queues, but the priority could be different |
| 14:30 | <nox> | Ok |
| 14:31 | <annevk> | nox: not sure what a reliable signal would be tbh |
| 14:31 | <nox> | annevk: So, should I file a different HTML issue about making <meta http-equiv=default-style> queue a task? |
| 14:32 | <annevk> | nox: yeah, though maybe not be that certain about the solution, since the queueing might have to be in whatever it calls |
| 14:32 | <annevk> | (thanks!) |
| 14:33 | <nox> | annevk: I will file one about how the change doesn't happen immediately and the spec implies it does, that's enough right? |
| 14:34 | <annevk> | nox: aye |
| 14:35 | <nox> | I removed the test from my PR, and will file the issue and add a link to it to my summarising comment. |
| 14:35 | <annevk> | tusen takk |
| 14:40 | <nox> | annevk: MFW I try to reproduce our discovery in Live DOM Viewer but the last browser I tested it is Safari and I keep tweaking my sample in it, the only browser which does observe the change immediately… |
| 14:41 | <annevk> | nox: sorry, I should have given you glitch.com examples |
| 14:41 | <nox> | Nah it's ok. |
| 14:41 | <nox> | Now my changes don't apply anymore at all in Firefox when I add the meta element, this is confusing. |
| 14:41 | <annevk> | nox: I think glitch.com is the way forward as there are far fewer surprises there; Live DOM Viewer has quite a few downsides |
| 14:42 | <annevk> | Only downside with Glitch I've run into is that it creates a named window if you click on the preview link (for arguably good reasons) |
| 14:43 | <nox> | annevk: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=6660 |
| 14:43 | <nox> | Am I going crazy? |
| 14:44 | <Ms2ger> | Probs |
| 14:45 | <nox> | I made a standalone HTML file and the background never goes green. |
| 14:48 | <nox> | https://irccloud.mozilla.com/pastebin/SWQcGNQX/annevk.html |
| 14:49 | <nox> | This writes rgb green in Safari and Chrome, so the thing doesn't actually happen through a queued task AFAICT. |
| 14:50 | <annevk> | nox: sounds correct |
| 14:51 | <annevk> | nox: perhaps Firefox only supports this if it comes from the parser? |
| 14:51 | <nox> | annevk: Which is the worst. |
| 14:51 | <nox> | annevk: Yeah probs. |
| 14:51 | <nox> | annevk: Ok, I checked the thing I was scared of, and it doesn't happen, yay. |
| 14:52 | <nox> | https://irccloud.mozilla.com/pastebin/sodX8QU2/chrome.html |
| 14:52 | <nox> | I thought this was failing in Chrome, |
| 14:52 | <nox> | which would mean the switch happened after all scripts, which would mean we would need a second queue somehow. |
| 14:52 | <annevk> | nox: filing follow-ups on these seems fine, since I think the general model for <script>, <style>, and <iframe> et al is sound and it seems like the remainder can be slotted into that if needed |
| 14:52 | <nox> | But it passes, so just disregard that. |
| 14:53 | <annevk> | nox: though focus handling might be good to test |
| 14:53 | <nox> | annevk: I didn't find any behaviour to observe for focus. |
| 14:56 | <nox> | annevk: I'm still quite confident you can merge the DOM part, all the different behaviours I found can be implemented in terms of deferredStepsQueue. |
| 14:58 | <zcorpan> | annevk: you can test win.onblur = t.unreached_func(); win.blur(); frame.remove(); win.blur(); |
| 15:00 | <annevk> | nox: I can get Chrome to fire onblur while a script invokes remove() on a focused element, but no other browser |
| 15:00 | <annevk> | fire blur* |
| 15:00 | <annevk> | nox: FWIW, the reason I haven't merged that is because it seems cleaner to also fix dependencies at the same time |
| 15:01 | <annevk> | nox: not because I think it's wrong or some such |
| 15:01 | <nox> | annevk: Ack |
| 15:02 | <nox> | annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=1528982 |
| 15:06 | <nox> | annevk: Link me to your onblur sample please. |
| 15:06 | <nox> | I will try to make it a WPT test. |
| 15:07 | <annevk> | nox: https://wistful-notify.glitch.me/ |
| 15:07 | <nox> | zcorpan: We are trying to test focus/blur as part of insertions with scripts. |
| 15:07 | <annevk> | nox: I'm not sure what we want to do here though |
| 15:07 | <annevk> | nox: not firing blur at all might be great? |
| 15:07 | <annevk> | nox: zcorpan's comment was about some unrelated changes I'm making |
| 15:07 | <nox> | annevk: No clue. :D |
| 15:08 | <nox> | annevk: Hah, ok. |
| 15:10 | <annevk> | zcorpan: so my main problem is that it's not sufficient to make the feature a no-op |
| 15:10 | <annevk> | zcorpan: since a browser could bail out if it's not focused |
| 15:11 | <annevk> | zcorpan: then if we start testing focusing it, it'll turn out that that doesn't work in all browsers, at which point... |
| 15:11 | <annevk> | zcorpan: seems good for a follow-up? |
| 15:12 | <zcorpan> | annevk: i don't understand what "a browser could bail out if it's not focused" means, but follow-up sounds good |
| 15:12 | <nox> | annevk: Why would blur not be emitted in Firefox? |
| 15:12 | <nox> | fired* |
| 15:12 | <annevk> | zcorpan: I mean that unless there's a reliable way to focus a window and we use that way before invoking blur(), we might well end up testing only a very early return in the blur() implementation |
| 15:13 | <annevk> | nox: I'm not very familiar with focus/blur |
| 15:13 | <annevk> | nox: and even less with edge case focus/blur |
| 15:13 | <nox> | :D |
| 15:16 | <zcorpan> | annevk: i see. yeah, if firefox or some other browser does something it would be good to exercise that something. as far as i can tell from chromium it's literally no-op |
| 15:18 | <nox> | annevk: Re: filing follow-ups: it's not like my PR can be merged until someone from Chrome chimes in and discusses with bz about which behaviour should be specified. |
| 15:18 | <nox> | So far, no one on the Chrome side of things commented in any of the three PRs. :( |
| 15:21 | <annevk> | nox: did I copy tkent? |
| 15:22 | <nox> | I don't think so. |
| 15:22 | <nox> | bz may have. Let me find his comment. |
| 15:24 | <annevk> | nox: you did |
| 15:24 | <nox> | Hah! |
| 15:40 | <nox> | annevk: Fun for the whole family https://bugzilla.mozilla.org/show_bug.cgi?id=1528982#c1 |
| 15:42 | <annevk> | nox: if it involved dinosaurs, maybe |
| 15:42 | <nox> | Hah |
| 16:43 | <domfarolino> | annevk: I believe everything has now been addressed for image{srcset,sizes} PR. Thanks for the reviews |
| 18:52 | <annevk> | domfarolino: I can look tomorrow I suspect |
| 18:52 | <annevk> | domfarolino: feel free to ping me again if I don’t |
| 18:55 | <domfarolino> | 👍 |
| 23:33 | <Nepose> | Hi, if I can ask (and if there is anyone at this hour ;) ) because I'm just thinking now about it - what does W3C specifications and namespaces actually mean, especially for HTML5.x when you are making a web standard in fact? |