02:17
<sideshowbarker>
TabAtkins: Can you do a new pip release for Bikeshed? So I can get the https://github.com/tabatkins/bikeshed/pull/2134 change included
02:18
<sideshowbarker>
I do need an actual updated pip release to get that, right? Just doing bikeshed update doesn’t pull it in
02:20
<sideshowbarker>
Do you auto-release an updated pip package on some schedule? I mean at some point after there’s been an update to the sources
02:22
<TabAtkins>
No auto-release, I do it occasionally, and try to hit it a day or two after updates (partially to ensure I catch necessary changes like what happened ^_^). I'll take care of it tomorrow morning.
02:22
<sideshowbarker>
OK — thanks
02:22
<TabAtkins>
On my short list is moving the boilerplates over to being bikeshed update-able, so I don't need to release a new pip version just for that
02:22
<sideshowbarker>
oh that would be very cool
02:23
<TabAtkins>
It would also mean the boilerplates would be in sync with the other test files, and not require rebasing tests just to be updated.
02:24
<sideshowbarker>
ah yeah I guess the test rebasing thing is something that’s a bit confusing to Bikeshed code contributors
02:28
<sideshowbarker>
anyway I agreed a long time back to get the WebAppSec TR copies set up to get auto-(re)published as CRDs on every push — so I’m overdue on actually making that happen
02:29
<sideshowbarker>
(I forgot what the D in CRD stands for, but anyway it’s the thing were calling “evergreen” before and that rest of us just call Living Standards)
02:35
<sideshowbarker>
so once I have that boilerplate/webappsec/status-CRD.include file in, I can start trying to set those all up. (Tried already with the Secure Context spec — with the Status in the doc itself rather than from boilerplate — but the W3C pubrules checker didn’t seem to recognize it… The only way I’ve found to troubleshoot errors running under CI with spec-prod/pubrules (Echidna or Specberus or whatever it’s actually call) is through trial-and-error. It doesn’t log any useful debug info
06:27
<annevk>
GPHemsley: there's no comprehensive list, media and fonts are kind of a mess; aside from that it might be doable, not sure
13:26
<GPHemsley>
annevk: Where do you suppose that list would live, if we did put one together?
13:38
<Ms2ger 💉💉>
iana
13:38
Ms2ger 💉💉
🦆
15:14
<zcorpan>
"Remove Clipboard API and Events, ContentEditable, Selection API, and Input Events from the Deliverables." anyone know what will happen to these specs? https://www.w3.org/2021/08/webapps-charter-2021.html
15:20
<Ms2ger 💉💉>
As little as before, probably
17:27
<TabAtkins>
sideshowbarker: version 3.0.4 published
17:35
<Sam Sneddon [:gsnedders]>
is there any way to detect whether a dictionary member is supported in general? I don't think so, given unknown dictionary members are ignored… maybe something with a getter?
17:43
<miketayl_r>
in general seems hard... depending on what you're trying to detect support for, can you observe side effects?
18:22
<TabAtkins>
Using a getter is the only reliable way. I think known dict members are iterated over by default by the IDL marshalling? I'd have to double-check.
18:28
<Domenic>
Yep, they are, so yeah, a getter works
18:29
<Domenic>
The best trick is something like { get thingToDetect() { throw "supported"; }, get tthingAlphabeticallyAfterThingToDetect() { throw "not supported"; } }
18:29
<Domenic>
As long as the thing you want to detect is not alphabetically last, that gives a general-purpose detection mechanism with no side effects.
18:30
<TabAtkins>
Why do you need the second throw? Isn't the absence of the first throw sufficient?
18:30
<Domenic>
The second throw prevents the method from going through in browsers that don't support the API
18:30
<Domenic>
I.e. prevents side effects
18:30
<TabAtkins>
Ahhhh yes, makes sense.
18:31
<Domenic>
(This technique is beautiful and I will take no further questions.)
18:31
<Domenic>
(but more seriously this is a long-running thread: https://github.com/heycam/webidl/issues/107 )