| 02:37 | <kochi> | annevk: great to hear that. have a safe trip! |
| 02:38 | kochi | starts working today |
| 04:52 | <tkore> | is there any plan of integrating native private class members? |
| 06:32 | <annevk> | tkore: you want #tc39 and yes, I think so |
| 08:17 | <annevk> | foolip: I keep getting "curl: (7) Failed to connect to resources.whatwg.org port 443: Connection timed out" |
| 08:17 | <annevk> | foolip: and similar such error messages |
| 08:18 | <annevk> | foolip: I wonder if Travis has some kind of limit on curl calls? |
| 08:18 | <annevk> | foolip: or maybe our server has some kind of limit we're not aware of? |
| 08:18 | <annevk> | foolip: did you end up adding CDNs? |
| 08:24 | <foolip> | annevk: no CDN yet, but it also wouldn't help when deploying, stuff still has to go to one place |
| 08:25 | <foolip> | annevk: you're seeing this in many Travis jobs? |
| 08:25 | <annevk> | foolip: I'm more worried about CDNs adding more uncertainty, so I'd prefer not adding one if we don't need it |
| 08:26 | <annevk> | foolip: I have this one whatwg/infra job I can't seem to get a good result from |
| 08:26 | <annevk> | foolip: and it's on master and blocking other PRs |
| 08:26 | annevk | restarts it again |
| 08:29 | <annevk> | foolip: seems to be either that or an internal server error, but due to the bad debugging messages I'm not sure if the internal server error was for the original curl or another one that build.sh performs |
| 09:14 | <yoav> | Is a sharedworker intercepted by a service worker on the scope from which the sharedworker is fetched? |
| 09:14 | <annevk> | yoav: yeah, that should also be the case for dedicated workers though, iirc, but browsers have issues |
| 09:15 | <yoav> | well, I'm writing Request.destination tests, my "worker" test works fine, but same test for "sharedworker" doesn't (and it seems like SW is not intercepting) |
| 09:16 | <yoav> | (but I could be wrong and it's something else entirely) |
| 09:19 | <annevk> | yoav: it might work fine due to a bug in the test and the impl ๐ |
| 09:20 | <yoav> | :) |
| 09:20 | <yoav> | console.log() from the SW spits out the request for the worker (so the SW sees it) |
| 09:20 | <annevk> | yoav: see https://github.com/whatwg/html/issues/3112 |
| 09:21 | <annevk> | yoav: currently all workers are not subresources and therefore behave the same as documents when it comes to service worker selection |
| 09:21 | <yoav> | ok, so the fact that the document sees the SW is a bug? |
| 09:21 | <annevk> | yoav: however, implementations might not do this correctly for dedicated workers and we're undecided on what is going to change |
| 09:21 | <yoav> | s/SW/dedicated worker/ |
| 09:21 | <annevk> | yoav: that's the status quo, yes |
| 09:22 | <yoav> | ok, so if I'm writing tests, I should use that, right? |
| 09:22 | <yoav> | *I should not use that |
| 09:22 | <annevk> | yoav: right, tests should be against the spec |
| 09:22 | <annevk> | yoav: you can make the test not rely on this aspect though by making the scope encompass both |
| 09:23 | <Ms2ger> | Anyone around who knows a bit about createImageBitmap? |
| 09:23 | <yoav> | annevk: ok, thanks! :) |
| 09:24 | <annevk> | Ms2ger: a bit, yes |
| 09:25 | <Ms2ger> | Because that's all you need to review https://github.com/w3c/web-platform-tests/pull/8880 ;) |
| 09:26 | <annevk> | very good |
| 09:32 | <annevk> | junov could maybe help own that |
| 09:34 | <yoav> | annevk: another question, are favicons intercepted? |
| 09:35 | <yoav> | I assume they are... |
| 09:36 | <annevk> | yoav: per spec, yes, but it only defines favicon.ico fetching as part of fetching a document |
| 09:36 | <annevk> | yoav: if a UA fetches /favicon.ico early it's not documented |
| 09:36 | <yoav> | hmm, so dynamically loading of favicons based on <link> element is not defined? |
| 09:37 | <annevk> | yoav: I'm only talking about /favicon.ico; all other icons are defined afaik |
| 09:37 | <yoav> | ok |
| 09:37 | <annevk> | yoav: and all other icons are intercepted, to be clear |
| 09:37 | <yoav> | cool |
| 09:54 | <Ms2ger> | annevk, thanks (and will try to pay more attention to var/let) |
| 10:16 | <foolip> | annevk: I'm upgrading my Mac and can't easily look now, did restarting it work? |
| 10:17 | <annevk> | foolip: no, just different errors |
| 10:18 | <annevk> | foolip: I guess I should look at the build script and see if I can add some echo statements |
| 10:43 | <annevk> | foolip: https://github.com/whatwg/whatwg.org/pull/159 |
| 10:44 | <foolip> | annevk: I see it was a 500, which is quite surprising, never seen that before. I wonder if it's really nginx that did it or if there's some intermediate thing involved here on Travis's end |
| 10:44 | <annevk> | foolip: I think the 500 came from api.csswg.org |
| 10:44 | <annevk> | foolip: I now get a 400 which indicates something is wrong Bikeshed-wise |
| 10:45 | <foolip> | annevk: oh... I saw curl in the command and curl in the failure, got confused |
| 10:45 | <foolip> | Yeah, I just restarted, now it's 400 |
| 10:46 | <annevk> | I suspect that's because we now have this WHATWG Group template |
| 10:47 | <annevk> | And you can't select an older Bikeshed to build against |
| 10:47 | <annevk> | Okay, so I think it all makes sense and probably requires Domenic to resolve as he has all the pieces in his head |
| 10:47 | <annevk> | We still could do with better error messages if Bikeshed fails |
| 10:47 | <foolip> | annevk: isn't the WHATWG group a new thing in Bikeshed, so the problem is api.csswg.org doesn't have the updated code yet? |
| 10:48 | <annevk> | I have some ideas |
| 10:48 | <annevk> | foolip: I think it now has the updated code and the problem is that whatwg/infra is not using it |
| 10:48 | <foolip> | we could just run Bikeshed on Travis, and have a place that says "master" that we could use to pin the version when needed |
| 10:48 | <annevk> | foolip: since we haven't merged the whatwg/infra PR that uses the new Bikeshed template (as all those PRs also depend on something else) |
| 10:49 | <foolip> | But, that's also stuff to maintain. |
| 10:49 | <foolip> | annevk: oh I see |
| 10:49 | <annevk> | I think the current setup is fine |
| 10:49 | <foolip> | OK, so this wasn't a problem of api.csswg.org doing the wrong thing |
| 10:49 | <annevk> | The main thing we need to improve is how the log reads (provide more context) and curl error messages |
| 10:49 | <annevk> | Well, the 500 was weird |
| 10:50 | <annevk> | And the timeouts from resources.whatwg.org were weird too |
| 10:50 | <foolip> | anyway, marquee's graphs have been looking very much the same for a week, and not under much load at all |
| 10:50 | <annevk> | Yeah I doubt it's us really |
| 10:50 | <foolip> | but there could exist bugs of course |
| 10:50 | <annevk> | I think Travis has some kind of curl limit |
| 11:58 | <smaug____> | annevk: I'm trying to parse spec's sequential focusing |
| 11:58 | <smaug____> | I'm having trouble with https://html.spec.whatwg.org/multipage/interaction.html#sequential-navigation-search-algorithm |
| 11:58 | <smaug____> | I mean to understand that |
| 11:59 | <smaug____> | selection mechanism DOM vs sequential |
| 11:59 | <smaug____> | and what actually happens there |
| 12:01 | <smaug____> | perhaps it is https://html.spec.whatwg.org/multipage/interaction.html#suitable-sequentially-focusable-area which I don't understand |
| 12:03 | <smaug____> | "Let candidate be the first suitable sequentially focusable area in the home control group following starting point" what is that first |
| 12:48 | <annevk> | Hmm, where's Ms2ger |
| 13:23 | <csarven> | Can anyone point me to what the root node that MutationObserver is listening on? I'm experiencing document.body but was under the impression that it'd be document.documentElement or something. |
| 13:25 | <csarven> | My bad.. I had the wrong target :) |
| 13:37 | <smaug____> | annevk: nm the sequential focus question. I think I managed collect the needed information scattered around the spec. Focus handling is hard (to spec and implement). |
| 13:43 | <annevk> | smaug____: sorry for totally ignoring that... when folks mention focus I tend to blur |
| 13:43 | <annevk> | (as indeed, it's way hard) |
| 14:56 | <fantasai> | Are there incoming references to Selectors besides https://dom.spec.whatwg.org/ in the DOM/JS world? |
| 14:56 | <annevk> | fantasai: HTML |
| 14:56 | <annevk> | fantasai: maybe Fullscreen API (it defines new selectors at least) |
| 14:57 | <annevk> | Seems like Fullscreen does not, but maybe should |
| 14:58 | <annevk> | fantasai: https://quirks.spec.whatwg.org/ |
| 14:59 | <annevk> | fantasai: that's probably it as far as WHATWG goes |
| 14:59 | <fantasai> | annevk: thanks! |
| 14:59 | <fantasai> | annevk: Anything on the W3C side I should be aware of? |
| 14:59 | fantasai | never knows where things live in the scripting world |
| 15:00 | <annevk> | fantasai: I'm not really sure, nothing really comes to mind though |
| 15:01 | <fantasai> | annevk: Web components maybe? Do you know where the current "you should look at this" spec lives for that? :) |
| 15:03 | <annevk> | fantasai: Web Components is DOM + HTML + some leftover bits yet to be upstreamed, and some new CSS specs |
| 15:03 | <annevk> | fantasai: of those, the HTML and CSS bits reference Selectors (HTML defines a new pseudo-class and the CSS stuff defines more) |
| 15:04 | <fantasai> | Afaik the CSS bits are in css-scoping; does anything else on the CSS side live elsewhere than the CSSWG? |
| 15:04 | <annevk> | fantasai: maybe the Selectors spec should start hosting a registry of pseudo-classes |
| 15:04 | <annevk> | fantasai: HTML defines ":defined" |
| 15:04 | <annevk> | fantasai: pretty sure that's it |
| 15:05 | <annevk> | fantasai: https://html.spec.whatwg.org/multipage/semantics-other.html#pseudo-classes |
| 15:05 | <annevk> | fantasai: https://github.com/w3c/webcomponents/issues/665 is related |
| 15:05 | <fantasai> | I think we've mostly been trying to host the definitions inline in Selectors, with references out to other specs as needed to fully define the semantics. |
| 15:05 | <fantasai> | Web components has been an exception to that, though |
| 15:05 | <annevk> | fantasai: Fullscreen too |
| 15:06 | <annevk> | fantasai: Fullscreen even extends the CSS stacking context business... |
| 15:06 | <annevk> | fantasai: (note that I'd be happy for CSS to embrace and extinguish) |
| 15:06 | <fantasai> | Yeah, I vaguely remember discussions about where that stuff should live and there was some non-technical reason for it at the point the spec was written... |
| 15:07 | <annevk> | fantasai: maybe nobody has turned Appendix E of CSS 2 into something proper yet? |
| 15:07 | <fantasai> | indeed :) |
| 15:08 | <fantasai> | Tab and I have that on the to-do list for css-position, but we haven't taken over that spec yet so it's kindof in limbo afaict |
| 15:08 | <fantasai> | I'm trying to prep a new WD of Selectors, fwiw. |
| 15:08 | <Domenic> | annevk: can I get a re-approval on https://github.com/whatwg/whatwg.org/pull/158 ? |
| 15:08 | <Domenic> | It's preventing all builds |
| 15:10 | <annevk> | Domenic: sorry, I'm pretty sure I had approved that |
| 15:10 | <Domenic> | Yeah, somehow it disappeared. |
| 15:10 | <fantasai> | but need to sort through the churn on the sections that are/were referenced by or written for other specs.. which may or may not still exist |
| 15:10 | <fantasai> | ~_ |
| 15:10 | <annevk> | Domenic: maybe because I removed the comment? Weird |
| 15:10 | <annevk> | fantasai: good times |
| 15:11 | <annevk> | fantasai: if you want to create a pseudo-class registry somewhere (maybe in the spec) I can supply PRs now and then |
| 15:11 | <annevk> | fantasai: the current situation with sometimes CSS defining things and sometimes other specs is a bit messy |
| 15:11 | <fantasai> | yeah, definitely |
| 15:11 | <fantasai> | I'll look over the HTML/Fullscreen specs and see what's a good idea to do |
| 15:11 | <annevk> | cool cool |
| 15:31 | <annevk> | Domenic: do you want me to merge some? e.g. whatwg/url? |
| 15:31 | <annevk> | Domenic: also, \o/ |
| 15:31 | <Domenic> | annevk: I can handle it. Only encoding is I guess stuck somehow. |
| 15:31 | <Domenic> | This also adds service workers to everything. |
| 15:32 | <annevk> | cool |
| 16:21 | <annevk> | Domenic: mobile requires version="1.1" in SVG? |
| 16:21 | <Domenic> | No, it was just inconsistent |
| 16:21 | <Domenic> | Should we remove them from everywhere? |
| 16:21 | <annevk> | Domenic: yes please ๐ |
| 16:21 | <Domenic> | Done |
| 16:22 | <Domenic> | annevk: https://github.com/w3c/web-platform-tests/pull/6890 is still in progress right? Several of the tests that fail with my implementation were not changed. |
| 16:23 | <annevk> | Domenic: well I thought I fixed those that were wrong |
| 16:23 | <Domenic> | All 6 of them were wrong according to the spec |
| 16:23 | <annevk> | Domenic: since you didn't implement the base64 semantics of the spec |
| 16:23 | <Domenic> | I didn't? |
| 16:23 | <annevk> | Domenic: your comments suggested you didn't |
| 16:24 | <annevk> | Domenic: I also left some questions |
| 16:24 | <Domenic> | I don't see them... |
| 16:24 | <Domenic> | I commented on things I thought were spec bugs but you said they were not spec bugs |
| 16:24 | <Domenic> | So in that case they're test bugs |
| 16:24 | <Domenic> | Since I implemented the spec |
| 16:24 | <annevk> | Domenic: ah okay, I didn't look specifically at https://github.com/w3c/web-platform-tests/pull/6890#issuecomment-350530361 |
| 16:25 | <annevk> | Domenic: I thought the next comment summarized but it touched on some other things and some same things |
| 16:25 | <annevk> | next two comments* |
| 16:25 | <Domenic> | The second comment after summarizes that |
| 16:25 | <Domenic> | It explains how the spec gets the result in each case |
| 16:25 | <Domenic> | (the result that mismatches the tests) |
| 16:26 | <annevk> | Domenic: thanks, I misread |
| 16:26 | <Domenic> | \o/ |
| 16:26 | <annevk> | Domenic: maybe I can fix in an hour, otherwise tomorrow |
| 16:26 | <Domenic> | sg |
| 16:26 | <Domenic> | I am rather sick today, just trying to distract myself with something interesting -_-. Will turn to computer games soon, probably. |
| 16:27 | <annevk> | Domenic: good idea; Switch's been a lot of fun |
| 18:45 | <TabAtkins> | Say I was, theoretically, writing up a stage-0 proposal to add seeded random numbers to JS. I feel like the best interface is a Math.seededRandom(seed) generator function, which returns an iterator of random values. Any other reasonable options? |
| 18:45 | <TabAtkins> | I kinda want to steer away from just having Math.random({seed:0}) update some global seed - far too easy for two applications to clash and mess each other up. |
| 18:45 | <mel00010> | Why trust JS devs to properly seed their random numbers? |
| 18:46 | <TabAtkins> | I'm not - if you want normal good randomess, you use the normal random APIs. This is for when you specifically need a reproducible string of random numbers. |
| 18:46 | <TabAtkins> | (Without having to explicitly stash them somewhere, because the API I want them for is stateless.) |
| 18:47 | <TabAtkins> | Specifically, the https://lab.iamvdo.me/houdini/rough-boxes Houdini demo, which currently repaints the rough borders totally differently every time the callback is called. |
| 18:48 | <TabAtkins> | The only way around that today is to have them handroll a linear congruential generator or something, which is dumb. |
| 18:48 | <mel00010> | I'm just worried some idiot dev working for a bank ends up using Math.seededRandom(0) |
| 18:48 | <mel00010> | And decides to roll their own crypto |
| 18:49 | <mel00010> | Or generate user keys with it |
| 18:49 | <TabAtkins> | That's always a possibility. |
| 18:49 | <mel00010> | Its a lot harder to pull off if you have to implement your own seeded random algorithms |
| 18:49 | <TabAtkins> | Given that they have good options (both the bad crypto of Math.random() and the better crypto of the actual crypto API), I don't think it's very important to worry about misuse of an even worse crypto. |
| 18:50 | <annevk> | TabAtkins: what is wrong with https://developer.mozilla.org/en-US/docs/Web/API/RandomSource/getRandomValues? |
| 18:50 | <TabAtkins> | @annevk What I just said - the Houdini APIs are stateless, so there's no place to stash that array. |
| 18:51 | <annevk> | TabAtkins: I guess I don't understand |
| 18:52 | <TabAtkins> | Anything that boils down to "pre-generate a list of random numbers, then re-use that list multiple times" isn't very good for the Houdini APIs. The invocations have very limited access to state data, and can't reasonably generate their own . |
| 18:52 | <TabAtkins> | Note that gRV() is *not* seeded in the way I mean, where the seed is controllable by the user. |
| 18:53 | <mel00010> | (Disclaimer: Not a JS dev) Could you just add a default parameter to Math.random like seeded=false and allow providing a seed that way? |
| 18:53 | <TabAtkins> | I addressed that up above - that means you'd be fiddling with some global random seed, which means that *two* users of seeded randomess will fight with each other. |
| 18:54 | <TabAtkins> | (And it's not clear that the global seed will actually work as intended with the Houdini APIs, where each invocation of the callback might happen in a different process with a fresh global.) |
| 18:54 | <mel00010> | I mean like this (in C++): int getRandom(bool isSeeded=false, int seed=0) |
| 18:55 | <mel00010> | If isSeeded is false, in this case, it ignores the value of seed |
| 18:56 | <TabAtkins> | Hm, that might work. (well, JS doesn't need the extra bool, the presence of the seed argument will work fine) The assumption being that you feed your previous result in as the new seed for the next invocation? |
| 18:57 | <mel00010> | Yes |
| 18:57 | <TabAtkins> | Problem is - how is that better than the more convenient seededRandom() returning an iterator of random values starting from that seed? |
| 18:57 | <TabAtkins> | There's no new functionality or protection, just an API that requires slightly more manual intervention to pull multiple out. |
| 18:57 | <mel00010> | It doesn't call out to idiot developers saying "Abuse me" as strongly |
| 18:58 | <TabAtkins> | I don't see how that's possible. `Math.random({seed: 0})` vs `Math.seededRandom(0)` seem pretty equivalent in that regard. |
| 18:59 | <mel00010> | I guess maybe trying to save idiot devs from themselves in JS is somewhat of a fools errand |
| 19:00 | <mel00010> | Math.random({seed: 0}) might require them to read the docs? |
| 19:00 | <TabAtkins> | No, it's valid. I just don't see how one is better or worse than the other in this regard, and the second has better ergonomics. |
| 19:03 | <mel00010> | My C++ instincts tell me to just overload Math.random() but IDK what the JS idiomatic approach is. |
| 19:03 | <TabAtkins> | C++ instincts are very often wrong when designing idiomatic JS apis. ^_^ |
| 19:04 | <TabAtkins> | (Those, and Java instincts, are the cause of most of the worst-designed JS APIs, imho.) |
| 19:05 | <mel00010> | I see 2 possible benefits to adding a new parameter to Math.random() |
| 19:05 | <mel00010> | 1) No new API |
| 19:06 | <annevk> | Domenic: no disagreement on step 6/7 being terrible |
| 19:06 | <annevk> | Domenic: I've been wanting to refactor that, but there's so much tied up into a knot it's rather impossible |
| 19:07 | <mel00010> | 2) Since getting a sequence of random values from a seed requires feeding the last value back into the function, it is more unlikely that someone who doesn't understand what the consequences are of fixed seeds will be able to successfully make their code work with the seed parameter. |
| 19:08 | <mel00010> | Also, is there a good way of generating seeds in JS? |
| 19:08 | <Domenic> | TabAtkins: a new method makes sense if the return type is different. And the iterator seems pretty reasonable, although perhaps too clever? Will think on it further. |
| 19:09 | <Domenic> | annevk: not sure if you saw my suggestion at https://github.com/whatwg/html/issues/3327, but that's a quick fix that would have saved me. |
| 19:10 | <annevk> | Domenic: some of that might be doable, but most of it is intertwined and not a good first bug |
| 19:10 | <annevk> | Domenic: iirc though |
| 19:11 | <Domenic> | I think you can just move stuff until after, there's really no reason why it's defined during step 5. |
| 19:11 | <annevk> | Because it references variables and such |
| 19:11 | <annevk> | Please do read it carefully before making changes ๐ |
| 21:29 | <annevk> | Apple joined the AV1 group \o/, prolly too soon, but Iโm excited |
| 21:30 | <wanderview> | annevk: what is the implication of that? |
| 21:31 | <annevk> | wanderview: that we might have royalty-free standardized video in the future |
| 22:19 | <foolip> | annevk: do you plan to rename more wpt directories to match spec shortnames? I would approve, especially for xhr. |
| 22:21 | <annevk> | foolip: it seems XHR is indeed broken nowโฆ Domenic? |
| 22:22 | <annevk> | foolip: I guess we can rename, but that one is more risky |
| 22:22 | <annevk> | foolip: and the renames are annoying due to git log not dealing with them well |
| 22:23 | <Domenic> | Oh, oops :( |
| 22:24 | <Domenic> | I say we just rename it? |
| 22:26 | <annevk> | Please grep as other stuff might depend on it |
| 22:27 | <annevk> | And thereโs def incoming README refs |
| 22:27 | <annevk> | Anyways, nn all ๐๐ค |
| 22:51 | <aklein> | TabAtkins: #tc39 is a reasonable place to ask ES library design questions |
| 22:51 | <TabAtkins> | Yeah, I was getting feedback from a different population. ^_^ |
| 22:53 | <aklein> | TabAtkins: understood. just saw your response about C++ and Java instincts though :) |
| 23:17 | <foolip> | annevk: https://github.com/w3c/web-platform-tests/pull/8937 |