WHATWG on 2024-03-20

00:00	<Eric Portis (he/him)>	(FF, WebKit, and Blink all agree that it doesn't, but I don't think [?] it's specified [?])
02:05	<sideshowbarker>	Jeffrey Yasskin: when someone's contributing to an open standard on behalf of their employer, it's both useful for reviewers to know that we should think of their contribution as coming from that organization, and important for the public to be able to see what organizations are influencing the standards That’s just the thing: In my case, Keio University is the organization that I was forced by the Participation requirements into stating as being my employer. But I am actually not contributing on behalf of Keio, and it would be a mistake for to interpret my contributions as being a way that Keio is attempting to influencing standards. https://github.com/w3ckeio/ is the relevant org in GitHub, and Keio didn’t create it — I myself did, personally. And I did it just to get around the Participation requirements. The thing is, as far as Keio is concerned, I am essentially just a independent contractor. My arrangement with them is just that each year, I sign a contract with them in which I confirm that the (virtual) lab I’m associated with in their bookkeeping arrangements will transfer to them enough revenue to cover my compensation and their overhead for having me on their books — and they for their part confirm that, out of the revenue I confirm will be brought in, they’ll pay out a certain amount of money to me. And that’s really it. In particular, I don’t sign away any rights of any kind to them — specifically, I don’t sign away any IPR to them. So they don’t claim any IPR on anything I do, and would never want to, and wouldn’t care to be troubled to even be asked about it.
02:07	<sideshowbarker>	And part of the reason I mention all those details is that I am hardly unique in this regard — many people nominally “employed” by universities are in circumstances that are nearly identical to mine.
02:09	<sideshowbarker>	But our current Participation requirements do not square well at all with those circumstances, and so I think they are putting an obstacle in the way of a significant number of people who might otherwise be able to contribute freely.
02:11	<sideshowbarker>	And I can really speak from experience when I say that it is likely to be extremely difficult for anybody in circumstances like mine to ever get their university “employers” to sign the Participation agreement. It took me two years and a mountain of effort and badgering and string-pulling to be able to get the agreement signed in my case.
02:14	<sideshowbarker>	And in the end, what we have is a result that’s bad, because it puts a misleading association on my contributions.
02:42	<Lurian Orsina>	Oieee
07:24	<sideshowbarker>	jarhar: About details auto-expand, and specifically about the following spec requirement: After find-in-page finishes searching for matches, the details elements and the elements with the hidden attribute in the hidden until found state should have their contents become skipped again. …In checking with current Chrome (v123 and Canary/), I notice that Chrome now doesn’t seem to close the auto-expanded details elements after I exit the find-in-page UI or after I do a different find-in-page for a different term. Is that correct? Or am I maybe somehow testing wrong? I could have sworn that in Chrome previously — back in October or so least — Chrome did close the auto-expanded details elements in the way that spec says we should. I guess it changed in the meantime? If so, why? For accessibility reasons? Regardless, if y’all made a decision to un-implement that requirement, should we also remove it from the spec?
08:45	<zcorpan>	Dominic Farolino: in chromium, does navigating a lazy iframe before it has run its lazy load resumption steps nullify the resumption steps? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/12473
14:26	<jarhar>	the details elements are always supposed to stay open after they are expanded for being the active match. this sentence is in the spec because all details elements are opened without showing that frame to the user in order to run a text search as if they are open. without this sentence, simply pressing ctrl+f would open every details element in the page without closing them again even if there are no matches
14:26	<jarhar>	it would probably be good to add a clarifying sentence to the spec
14:29	<sideshowbarker>	aha, I see now
14:29	<sideshowbarker>	thanks
20:44	<Jeffrey Yasskin>	Jeffrey Yasskin: when someone's contributing to an open standard on behalf of their employer, it's both useful for reviewers to know that we should think of their contribution as coming from that organization, and important for the public to be able to see what organizations are influencing the standards That’s just the thing: In my case, Keio University is the organization that I was forced by the Participation requirements into stating as being my employer. But I am actually not contributing on behalf of Keio, and it would be a mistake for to interpret my contributions as being a way that Keio is attempting to influencing standards. https://github.com/w3ckeio/ is the relevant org in GitHub, and Keio didn’t create it — I myself did, personally. And I did it just to get around the Participation requirements. The thing is, as far as Keio is concerned, I am essentially just a independent contractor. My arrangement with them is just that each year, I sign a contract with them in which I confirm that the (virtual) lab I’m associated with in their bookkeeping arrangements will transfer to them enough revenue to cover my compensation and their overhead for having me on their books — and they for their part confirm that, out of the revenue I confirm will be brought in, they’ll pay out a certain amount of money to me. And that’s really it. In particular, I don’t sign away any rights of any kind to them — specifically, I don’t sign away any IPR to them. So they don’t claim any IPR on anything I do, and would never want to, and wouldn’t care to be troubled to even be asked about it. For folks on https://www.w3.org/staff/, I'd expect a public association with https://github.com/w3c to be sufficient, especially now that W3C Inc. exists. But that's also not generalizable to other people employed by universities. For those folks, I think they do not "work in the field of web technologies", as defined by https://whatwg.org/ipr-policy#2101-work-in-the-field-of-web-technologies, and so they should be able to sign the individual agreement. But this is probably something the SG should clarify.
21:43	<Richard Gibson>	Is the https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values algorithm known to differ in any way from the behavior of `strtod`? aside from obvious differences like rejecting e.g. hexadecimal input, `strtod` is subject to rounding direction as configurable by `fesetround`, and it is not clear to me that the `FE_TONEAREST` default (which corresponds most closely with the HTML algorithm) guarantees "round ties to even" behavior (although https://stackoverflow.com/questions/69365468/does-c-standards-fe-tonearest-rounding-mode-guarantee-that-halfway-ties-are-rou suggests that it does, at least in later editions of the standard, https://github.com/Moddable-OpenSource/moddable/issues/944 is a concrete analogous ECMAScript example in which XS incorrectly rounds `9007199254740993` to `9007199254740994` rather than the correct even-significand `9007199254740992`)
22:09	<sideshowbarker>	Richard Gibson: Do you know if the same is true for the equivalent in the double-conversion library?
22:12	<Richard Gibson>	hmm, I don't think I know what "the double-conversion library" is
22:14	<sideshowbarker>	ah, sorry: https://github.com/google/double-conversion — it’s what Chrome and Firefox use for double parsing (and that WebKit also used until about a year ago, when it switched to using https://github.com/fastfloat/fast_float instead)
22:20	<Richard Gibson>	I don't know for sure, but https://github.com/google/double-conversion/blob/15b7e306433dd899585f92758f7776a37a9c25ff/double-conversion/string-to-double.cc#L357 and https://github.com/google/double-conversion/blob/15b7e306433dd899585f92758f7776a37a9c25ff/double-conversion/strtod.cc#L481 strongly suggest that it has the desired behavior
22:37	<sideshowbarker>	jarhar: I am only just now noticing that trying to do find-in-page on `details` contents in GitHub issue comments doesn’t work in Chrome — the details elements that have matches don’t auto-expand as expected. Do you any idea why? For example, open https://github.com/whatwg/html/pull/6242 and try a find-in-page for “web service” (which should match on the contents of the More details in the issue description). (With the WebKit patch I’m working on, those GitHub issue-comment `details` also don’t auto-expand as expected, but I’ve yet not tried debugging it to isolate the reason).