09:52
<annevk>
littledan: if you're around, is it worth opening a dedicated issue for privilege of a type on https://github.com/tc39/proposal-module-attributes?
09:53
<annevk>
littledan: e.g., I might be okay with HTML modules if they don't import scripts
09:53
<annevk>
littledan: or perhaps HTML modules start out without script and then later get script, would they need a new type?
11:01
<littledan>
annevk: Yeah it'd be good to get discussion going. Honestly I don't have a good idea how we could handle such a transition that implies a change in privilege levels; my intuition is that a higher-privileged thing should have a new MIME type and type: value
11:01
<annevk>
littledan: yeah, that might well be easiest; I guess my main hope after thinking about it for an hour is that it's a documented concern
11:02
<annevk>
I'll file something
11:02
<littledan>
+1
11:02
<littledan>
I'm thinking to propose module attributes for Stage 2 at the upcoming TC39 meeting starting June 1st, with the idea that these kinds of decisions like that ultimately up to hosts
11:03
<littledan>
Stage 2 would mean, I guess, that we want to do in-band module attributes, and JSON modules with this syntax; there's some things mandated for hosts around that, but ultimately hosts have a lot of freedom
16:37
<benjamingr__>
Hey, I help maintain a library that aims to somewhat implement the whatwg timers spec (fake-timers that was once called lolex).
16:37
<benjamingr__>
At the moment we support `setTimeout(string, number)`, some users have asked us to not support it (because of a warning eval creates in the tooling). I think the spec does require it when it says "Apply the ToString() abstract operation to the first argument to the method, and let script source be the result.". My intuition would be to not drop the support for `setInterval/setTimeout(string)` for compatibility (it's
16:37
<benjamingr__>
a testing library) - some other users have noted that in almost all cases setTimeout(string) is a user bug.
16:37
<benjamingr__>
Do the smart folk of #whatwg have a strong opinion about what @sinonjs/fake-timers should do?
17:39
<annevk>
benjamingr__: if Node has something that disables eval or string evaluation it should prolly respect that (HTML does too), but otherwise dunno.
19:35
<benjamingr__>
Node's timers aren't compatible with the web timers spec and their semantics are slightly different in various areas. Node timers throw an error when you pass a string to them - I suspect whomever implemented them was just unaware of the ability to pass a string :] (I checked as far back as Node 0.6)
19:36
<benjamingr__>
Is the ability to pass strings to timers as an argument something that's gonna stay for good or are there plans to eventually deprecate it?
19:44
<annevk>
benjamingr__: no plans that I know of
19:50
<benjamingr__>
thanks