| 04:03 | <TimothyGu> | tobie: anything I need to fix in https://github.com/heycam/webidl/pull/405 before it can get applied? |
| 04:09 | <TimothyGu> | or shall I just wait for the ECMA-262 PR to land? |
| 04:25 | <annevk> | TabAtkins: own |
| 04:39 | <TabAtkins> | annevk: And you'd like them to get moved into the head? If so, I can provide an attr that opts into that. |
| 04:40 | <annevk> | TabAtkins: yeah, seems better for the preparser |
| 04:40 | <annevk> | TabAtkins: the earlier those URLs are found the better |
| 04:41 | <TabAtkins> | Kk, file a bug on me and I'll do it. It just has to be opt-in for safety reasons, like I said |
| 04:41 | <TabAtkins> | Preferably point to a spec that is currently generating them late |
| 05:35 | <rniwa> | annevk: fyi, another drag & drop issue: https://github.com/whatwg/html/issues/2925 |
| 05:39 | <rniwa> | oh my, Chrome & Gecko have a different behavior too :( |
| 05:54 | <MikeSmith> | hey rniwa since you’re still awake, please take a look at https://github.com/whatwg/html/pull/2907/commits/2381a269cdfade91ceb056086a494471ceff8e35 |
| 05:55 | <rniwa> | MikeSmith: it looks good but I don't have commit privilege to the repo. |
| 05:57 | <MikeSmith> | rniwa: yeah annevk can (re)review and merge it |
| 05:57 | <MikeSmith> | just wanted to make sure you think it’s an improvement |
| 05:57 | <MikeSmith> | it future-proofs it against the class of problem it’s fixing |
| 05:58 | <rniwa> | MikeSmith: sure, it looks like an improvement |
| 05:58 | <MikeSmith> | k |
| 05:58 | <MikeSmith> | thanks |
| 05:58 | <MikeSmith> | I now feel like going back into the spec and changing any remaining cases we have of hard-coded step references |
| 05:59 | <MikeSmith> | maybe I’ll do that today |
| 06:01 | <MikeSmith> | annevk: I think I asked you this before but I guess there’s a reason we’re not doing branch snapshots for HTML |
| 06:42 | <annevk> | MikeSmith: I don't think we have a good reason |
| 06:46 | <a-ja> | MikeSmith, Please leave your sense of logic at the door, thanks! |
| 06:46 | a-ja | couldn't resist |
| 06:47 | <a-ja> | MikeSmith, btw...tks for script nomodule update to validator |
| 06:48 | <a-ja> | now has 0 html validation errors....and hundreds for my css :\ |
| 06:51 | <MikeSmith> | a-ja: super 🖖 |
| 07:05 | <annevk> | o_O |
| 07:05 | <annevk> | Safari uses a different character set for base64 in data: URLs: https://bugs.webkit.org/show_bug.cgi?id=175568 |
| 07:06 | <annevk> | This really goes to demonstrate how poor testing is |
| 07:19 | <zcorpan> | should it be DOMMatrix2dInit or DOMMatrix2DInit? (there's a dictionary member called "is2D") |
| 07:25 | <annevk> | zcorpan: it's Path2D and CanvasRenderingContext2D |
| 07:25 | <annevk> | zcorpan: but also, dictionary names are not observable |
| 07:26 | <zcorpan> | yeah, but still :-) thanks |
| 07:27 | <annevk> | gotta paint the back of that fence |
| 07:40 | <a-ja> | which is preferred, bactrian or dromedary camel case? |
| 07:43 | <annevk> | a-ja: not sure if serious, but https://w3ctag.github.io/design-principles/#casing-rules |
| 07:44 | <a-ja> | wasn't serious...but reading |
| 07:44 | <a-ja> | TLDR; answer is "hybrid" |
| 07:45 | <zcorpan> | i prefer XMLHttpRequest case |
| 07:45 | <annevk> | oh my |
| 08:56 | <zcorpan> | annevk: was there an issue about changing setAttribute et al to check the attribute name according to what the html parser accepts? |
| 08:57 | <annevk> | zcorpan: there's https://github.com/whatwg/dom/pull/449 |
| 09:03 | <tobie> | TimothyGu: I was pondering just that. Going through the whole list one by one again and adding a few comments. Sorry what seemed like a trivial change ended up as a long conversation on ES functions. |
| 09:04 | <tobie> | TimothyGu: no realizing that built-in functions is a subset of both function objects and constructors. |
| 09:04 | <tobie> | TimothyGu: s/no/now/ |
| 09:06 | <tobie> | TimothyGu: i.e. these operate on a different axis; it's [[Call]] vs. [[Construct]] on one axis, and built-in vs. user land on the other. |
| 09:06 | <tobie> | TimothyGu: ES terminology is really letting us down, here. |
| 09:46 | <zcorpan> | Hmmmmmm. This worries me :-( https://github.com/w3c/web-platform-tests/pull/6418 |
| 10:19 | <Ms2ger> | tobie, sounds like you need to put a table in the spec somewhere :) |
| 10:20 | <tobie> | Ms2ger: in which spec? |
| 10:20 | <Ms2ger> | Either webidl or ES, I suppose |
| 10:22 | <tobie> | Ms2ger: I've yet to understand what the exotic stuff is |
| 10:22 | <tobie> | Ms2ger: could well be that two dimensions aren't enough to sort this whole thing out. |
| 10:23 | <annevk> | tobie: custom internal methods |
| 10:23 | <tobie> | annevk: custom internal methods are exotic? I thought they were built-in. |
| 10:23 | <annevk> | tobie: e.g., custom [[Delete]] or [[OwnPropertyKeys]] |
| 10:24 | <annevk> | tobie: if an object has custom internal methods, that makes it an exotic object |
| 10:24 | <tobie> | Oh. The object is exotic. |
| 10:25 | <annevk> | tobie: WindowProxy and Location are good examples outside ECMAScript (and anything with getters/callers) |
| 10:37 | <TimothyGu> | tobie: thanks for the review! sure, I'll address the comments soon, no worries |
| 10:39 | <tobie> | TimothyGu: well hopefully by then the ES PR will have been merged. |
| 10:59 | <annevk> | Anyone ideas of how MIME types end up getting exposed in the platform? |
| 11:00 | <annevk> | I guess when you navigate whether something downloads or not, maybe Blob.prototype.type though as I understand it that's just what you passed in, Document.prototype.contentType though that doesn't have parameters |
| 11:00 | <annevk> | Getting the Content-Type header through fetch() or XMLHttpRequest just gives you the raw value |
| 11:01 | <annevk> | For data: URLs it's a mixed bag, but Chrome and Firefox do seem to expose something there (but unclear to me if that's desired) |
| 11:03 | <annevk> | Stuff that uses https://fetch.spec.whatwg.org/#concept-header-extract-mime-type I suppose, though I'm not hopeful |
| 11:14 | <TimothyGu> | tobie: sorry, just fixed the comments :| |
| 12:39 | <TimothyGu> | annevk: wait, there are plans to drop FTP support? |
| 12:52 | <annevk> | TimothyGu: sure, suspect before HTTP |
| 13:17 | <tobie> | is HTMLAllCollection now the last interface with legacycaller? |
| 13:19 | <annevk> | tobie: that might be true, yes |
| 13:19 | <tobie> | would there be an objection to me listing these weird interfaces in notes within the WebIDL spec? |
| 13:20 | <tobie> | I've got to look them up all the time. |
| 13:20 | <tobie> | Alternatively, in an annex. |
| 13:20 | <annevk> | tobie: source comments seem definitely fine, notes probably too |
| 13:20 | <tobie> | cool |
| 13:21 | <annevk> | tobie: once ECMAScript defines HTML Document Dot All Objects or whatever they call them we might want to revisit how this gets defined |
| 13:21 | <annevk> | tobie: we could just put the legacycaller bits directly in HTML |
| 13:21 | <annevk> | (though haven't checked if that actually works out in practice, mind you) |
| 13:23 | <tobie> | annevk: I think that could work with a bit of refactoring. |
| 13:25 | <annevk> | tobie: if that means defining [[Call]] solely in HTML that would be a lot better |
| 13:26 | <tobie> | annevk: it would |
| 13:27 | <tobie> | annevk: well, the syntax should still stay in WebIDL, though. |
| 13:27 | <tobie> | annevk: unless we turn legacycaller into an extended attribute, of course. |
| 13:38 | <tobie> | annevk: how would you got about this in HTML? Just add some prose that HTMLAllCollection has an additional [[Call]] method? Or add a new extended attribute? |
| 13:38 | <annevk> | tobie: the former, just like we do for WindowProxy and Location |
| 13:39 | tobie | looks |
| 14:18 | <TimothyGu> | tobie: I'd love to remove legacycaller from IDL |
| 14:18 | <tobie> | TimothyGu: yeah, I think this plan might work |
| 14:18 | <tobie> | TimothyGu: toying with adding [[Call]] to HTML spec as we speak |
| 14:19 | <tobie> | TimothyGu: turns out there are some weird oddities; |
| 14:20 | <tobie> | TimothyGu: document.all("1") and document.all("1", "45") aren't returning the same thing, which blows my mind |
| 14:21 | <TimothyGu> | wait, why? |
| 14:21 | <botie> | wait, why are you using rawgit? |
| 14:22 | <tobie> | TimothyGu: never mind my last comment. |
| 14:22 | <TimothyGu> | you are aware of https://html.spec.whatwg.org/multipage/obsolete.html#dom-document-all right |
| 14:22 | <tobie> | TimothyGu: stupid mistake on my part due to poor eyesight |
| 14:22 | <TimothyGu> | guessing you are |
| 14:23 | <tobie> | yes |
| 14:23 | <tobie> | well, sort of. |
| 14:25 | <tobie> | TimothyGu: Was your initial comment "I'd love to remove legacycaller from IDL" to be interpreted as: (1) I'd love to see legacycaller go, (2) I'd love to do the work to remove legacycaller, or (3) both (1) and (2)? |
| 14:25 | <TimothyGu> | (3) :) |
| 14:26 | <TimothyGu> | well, more like "I'd love to see it go, and I *can* do the work if no one else wants to" :P |
| 14:27 | <tobie> | TimothyGu: sounds good. Do you mind if I work on the HTML spec PR while you rip it out of WebIDL? |
| 14:27 | <tobie> | biab |
| 14:27 | <TimothyGu> | sure! |
| 14:27 | <TimothyGu> | let me know when the HTML PR is ready |
| 14:29 | <nox> | How can we kill legacycaller given it's used? |
| 14:29 | <nox> | Oh, extended attribute. |
| 14:30 | <TimothyGu> | nox: it's only used in one place, so we can just specify its exotic behaviors *there* |
| 14:30 | <nox> | Oh, prose. :( |
| 14:34 | <annevk> | nox: there's going to be prose one way or another 😃 |
| 14:35 | <nox> | annevk: [IOnlyTolerateCamelCaseProseWithSquareBracketsAroundIt] :P |
| 14:35 | <annevk> | nox: well, since it's about a custom [[Call]] there'll be brackets |
| 14:35 | <nox> | Perfect! :D |
| 14:57 | <TimothyGu> | tobie: you might want to take care of https://github.com/heycam/webidl/issues/407 while porting [[Call]] to HTML |
| 15:34 | <smaug____> | rbyers: when Chrome coalesces mousemoves, there isn't any way to get all the mousemoves, right? |
| 15:34 | <smaug____> | I mean this one move per rAF thing |
| 15:36 | <Domenic> | annevk: probably good to ping jasnell for things like https://github.com/whatwg/url/issues/342 too |
| 15:39 | <Domenic> | smaug____: I'm pretty sure there is |
| 15:40 | <Domenic> | something like mouseEvent.getCoaelescedThingies() |
| 15:40 | <Domenic> | or maybe it's pointer events only |
| 15:40 | <Domenic> | rbyers has some demo where he uses this to make drawing prettier |
| 15:58 | <smaug____> | Domenic: getCoalescedEvents() is a pointer events thing, not mouse event |
| 16:00 | <Domenic> | Right, OK. So yeah, use pointer events, they are the future :). |
| 16:07 | <tobie> | TimothyGu: well… I guess I can just close it now. :D |
| 16:45 | <rbyers> | smaug____: Yeah coalesced events are available on pointer events only. One visualization is here BTW: https://rbyers.github.io/eventRate.html |
| 16:45 | <smaug____> | rbyers: has there been lots of regressions because of 1 mousemove per animation frame? |
| 16:46 | <rbyers> | ... but PointerEvent is a MouseEvent so our hypothesis is that it's hopefully that much of a burden to ask existing MouseEvent-based sites to use this PointerEvent API for this without upgrading all their existing event code. |
| 16:47 | <smaug____> | well, only some browsers support pointer events atm |
| 16:47 | smaug____ | wonders what https://rbyers.github.io/eventRate.html is supposed to do |
| 16:47 | <annevk> | Domenic: seems jasnell found it |
| 16:47 | <smaug____> | loaded in Chrome and if I click I see a gray dot |
| 16:48 | <smaug____> | oh, I need to mousedown and move |
| 16:49 | <rbyers> | smaug____: No regressions that we're aware of (just checked with dtapuska). It shipped in M60 and AFAIK not a single bug was filed due to it (we can trust our regression bisect to connect back to the bug): https://bugs.chromium.org/p/chromium/issues/detail?id=703344 |
| 16:54 | <smaug____> | rbyers: oh, eventRate.html behaves very differently on Windows than on Linux Chrome. |
| 16:54 | <smaug____> | I see some brown dots on windows |
| 16:54 | <rbyers> | smaug____: Yeah sorry there's no instructions on eventRate. It draws larger dots for events, smaller ones for coalesced events. |
| 16:55 | <smaug____> | I see no coalesced events on linux |
| 16:55 | <rbyers> | ... the larger blue dots should be consistent across platforms in Chrome 60+ |
| 16:55 | <smaug____> | oh, maybe if I move mouse very fast there are some |
| 16:55 | <rbyers> | Are you on Chrome 60+ |
| 16:55 | <smaug____> | yup |
| 16:55 | <smaug____> | yeah, I guess blue dots are consistent |
| 16:55 | <rbyers> | A non-graphical version with more detail is here: https://rbyers.github.io/event-timing.html |
| 16:56 | <rbyers> | Right effectively the blue dots are the events whose timing is now controlled by the browser, the red dots are the raw coalescedEvents which are really up to the OS (and leak OS impl details). |
| 16:56 | <dtapuska> | smaug____: each os already has some vsync alignment sampling... depends on your mouse at least on linux |
| 16:56 | <rbyers> | dtapuska: Windows doesn't do an vsync alignment, does it? |
| 16:58 | <dtapuska> | rbyers: it depends on the hardware and a registry setting.. same with linux |
| 17:00 | <rbyers> | ah, all the more reason for the timing exposed to the web by default to be standardized (with an explicit opt-out like getCoalescedEvents for the rare cases the site really wants it) |
| 17:04 | <rbyers> | smaug____: So are you thinking you might like to switch to vsync-aligned mousemove before shipping PointerEvents in Firefox? |
| 17:04 | <smaug____> | well, just thinking |
| 17:05 | <rbyers> | ... I don't have any fundamental objection to exposing new capabilities on MouseEvent or even TouchEvent, I just don't see much reason to prioritize it unless developers are telling us that's a blocker for them. I know several in the PEWG would prefer we NOT expose new things on TouchEvent. |
| 17:05 | <smaug____> | stone just wrote a patch to vsync-aligned mousemoves. Rather simple patch to coalesce, mostly reusing our wheel event coalescing |
| 17:05 | smaug____ | can't recall if Chrome coalesces wheel events |
| 17:06 | <smaug____> | rbyers: oh, yeah, I wouldn't want to add anything new to mouse events |
| 17:06 | <rbyers> | ... But I've been in a "let's follow Apple without proactively investing ourselves" there (as we did for stylus support: https://github.com/w3c/touch-events/pull/81) |
| 17:07 | <rbyers> | smaug____: Yes we coalesce wheel but I forget if we vsync align them yet or not. We should be. dtapuska? |
| 17:08 | <rbyers> | No coalesced mousemove events? |
| 17:09 | <rbyers> | Sorry pointermove? |
| 17:09 | <smaug____> | ah, yeah, we don't sync wheel with vsync |
| 17:09 | <smaug____> | there is the problem that too much stuff is happening around vsync time |
| 17:09 | <rbyers> | If your OS is sending mouse movement at 60hz then it may not be noticeable unless you add some jank (which is what the UI at the bottom of eventRate is for). |
| 17:10 | <rbyers> | Interesting. Our main problem has been that things happen at the wrong time causing redundant/useless work. We want to kick of ALL the per-frame work at about rAF time. |
| 17:13 | <rbyers> | Of course there's sometimes too much per-frame work to fit into a single frame, but the beast answer there is to drop main-thread frames IMHO (not try to drop some of the things like wheel/scroll without also dropping rAF). Of course compositor frames should generally continue to tick reliably at vsync. |
| 17:14 | <tobie> | TimothyGu: https://github.com/whatwg/html/pull/2932 |
| 17:16 | <dtapuska> | rbyers: we rAF align mousewheels and touchmoves |
| 17:17 | <dtapuska> | smaug___: we flush any continuous events when we get a discrete event though... 'continuous' events are mousewheel, touchmove, mousemove |
| 17:32 | <tobie> | Would a kind soul explain what's wrong with my PR so I can fix it? https://github.com/whatwg/html/pull/2932 |
| 17:51 | <tobie> | Never mind. Closed an h6 element with an h4 tag. |
| 17:52 | <tobie> | And couldn't parse the error log properly. |
| 19:34 | <Domenic> | yoav: is rel=prerender still a thing? |
| 19:35 | <yoav> | I'm not sure, tbh |
| 19:36 | <yoav> | I know that the prerender implementation in Chromium got removed |
| 19:36 | <yoav> | I know there are plans for a simpler implementation that's more mobile friendly |
| 19:37 | <yoav> | based on the no-state-prefetch project (at least that's what I last heard) |
| 19:48 | <Yuhong> | Just added a few more standards to https://en.wikipedia.org/wiki/WHATWG#Specifications |
| 19:49 | <Yuhong> | I wrote the full proposal here: https://news.ycombinator.com/item?id=14977363 |
| 19:53 | <Yuhong> | The fun thing is that W3C does at least have a culture of testing unlike the IETF. |
| 20:12 | <Domenic> | Thanks for updating Wikipedia, Yuhong! |
| 20:13 | <Domenic> | Not sure about this supposed culture of testing; we were the ones who pioneered https://blog.whatwg.org/improving-interoperability and although some W3C groups have started to adopt that as well, it's not a requirement like it is at the WHATWG |
| 20:14 | <Yuhong> | I am talking about the W3C candidate recommendation which the IETF don't have. |
| 20:16 | <Yuhong> | https://blog.whatwg.org/improving-interoperability |
| 20:16 | <Yuhong> | "Two table-related interfaces were ignored by implementers for a decade, but when finally removed from the standard it turned out that WebKit had just added them. Sorry!" |
| 20:16 | <Yuhong> | W3C require two or more implementations, not just one. |
| 20:17 | <Domenic> | "require" |
| 20:17 | <Domenic> | We also do, as per recently-clarified working mode... but we don't count emacs and lynx as implementations, as some W3C specs have. |
| 20:19 | <Domenic> | botie: tell rniwa we appreciate him muddling through the spec for datatransfer/drag and drop and welcome suggestions for clearer wording to avoid others going through his pain in the future. |
| 20:19 | <botie> | will do |
| 20:20 | <Yuhong> | Yes, I am referring to Adam Barth giving up on the IETF. |
| 20:20 | <Yuhong> | That being said, text mode browsers are still important. I wished that Ubuntu installed one by default for example. |
| 20:27 | <Yuhong> | I assume that the HTML parser itself has not changed much in a long time, right? |
| 20:28 | <JakeA> | It's updated whenever a new element is added, at least |
| 20:28 | <Domenic> | It's changed a decent bit |
| 20:28 | <JakeA> | <template> springs to mind |
| 20:28 | <Domenic> | https://github.com/whatwg/html/issues?utf8=%E2%9C%93&q=label%3A%22topic%3A%20parser%22%20 |
| 20:38 | <Yuhong> | Most of these including new elements should be easy for validators to deal with though |
| 20:40 | <Yuhong> | BTW, I am not saying that W3C is particularly good. I am suggesting a compromise. |
| 20:41 | <Yuhong> | Especially since Jeff Jaffe has been discussing with Ian Hickson on that matter. |
| 20:42 | <Domenic> | I can tell you for a fact he has not been discussing that, at least not for years. |
| 20:42 | <Yuhong> | Yea, i am talking about years ago. |
| 20:42 | <Domenic> | I don't see your "compromise" improving the world in any way. |
| 20:45 | <Yuhong> | Yes, I mean in the sense of "HTML 3.2 aims to capture recommended practice as of early '96" for example. |
| 20:48 | <Domenic> | I think you'll find nobody in the WHATWG believes that's a useful thing to capture, and thus are not interested in a compromise that promotes that kind of outdated thinking. |
| 20:49 | <Yuhong> | Yea, I am not saying that versioning HTML is particularly good either. |
| 20:52 | <Yuhong> | I think we can all agree that what W3C is doing right now is far worse though. |
| 20:53 | <Domenic> | I think it's best to not pay attention to what they're doing and just work on making the actual spec better. |
| 20:53 | <Domenic> | We have a lot of "good first bugs" you could work on :) https://github.com/whatwg/html/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+bug%22 |
| 20:53 | <Yuhong> | And it is not like that we hasn't worked on it with W3C either. |
| 20:53 | <Yuhong> | And it is not like that we hasn't worked on it with W3C before either. |
| 20:57 | <Yuhong> | I think the MIME type registry still lists W3C for text/html for example. |
| 21:06 | <Yuhong> | Of course, the full spec was probably never a good fit which was probably where the 2022 date came from. |