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 ) |