What I implemented in Gecko is that a type "contains restricted floats" if any of the following conditions hold:

1)  It is "float" or "double".
2)  It is a nullable type where the underlying type contains restricted floats.
3)  It's a union type where one of the union members contains restricted floats.
4)  It's a sequence type where the element type contains restricted floats.

and allowed [LenientFloat] on operations that return void and have an argument hat contains restricted floats or on writable attributes whose type contains restricted floats.

I'm really not sure that this needs to go into the WebIDL spec. It seems to me that using prose is a quite acceptable solution in this case.

What we do internally in Gecko can be something completely different of course as long as the behavior matches that of the IDL+prose

Using prose is actually a terrible solution for this in practice.  When implementing a canvas method right now, you have to end up looking at three completely different places (the IDL, the prose for the method, and a second prose location that's in a totally different place and says that all methods that don't say otherwise have a certain behavior) to figure out what the behavior should be.  And when speccing a canvas method you have to be aware of this bit of action-at-a-distance prose....

One other note.  There is an observable difference between the spec as written right now and what Gecko is doing with [LenientFloat].  In particular, consider this testcase:

  ctx.moveTo(NaN, { valueOf: { throw "HAHA"; } });

In Gecko's current implementation, and in the obvious way of defining [LenientFloat], this call will be a no-op.  Per spec as written right now, this call will throw, because the check for NaN on the first argument is done after converting all the arguments.

I could probably change Gecko to do the thing current prose says to do in this sort of edge case, but that would make it harder to optimize calls to such methods from the JIT...

In https://github.com/whatwg/html/pull/1790 we made the infinity/NaN handling for canvas methods unambiguous and explicit in HTML, with Boris's participation. Given that we don't want to do this kind of handling again, I don't think this is necessary anymore. Boris, please reopen if you disagree.

That seems fine, since we changed from using action-at-a-distance prose to prose in the relevant methods.

Gecko will continue using [LenientFloat] in its IDL to save on mental overhead, but I changed its behavior to be black-box indentical to the new prose in HTML.