Do you know of any cases where https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-integers would give different results than parseInt(x, 10)? I'd rather reuse that than reimplement the whole algorithm ourselves. It looks like the whitespace trimming is a bit different, parseInt() can return a -0, and parseInt() will ignore trailing garbage, but we could just take care of those cases ourselves? Tests for the changes would be a good idea here.

Also the first couple of commits could be their own independent PR.

We could just adapt the whitespace trimming part of 24d5364 to use with parsing integers, yes. I'm more interested in comments on the approach right now than treating this as something to be merged directly. :)

I'm more interested in comments on the approach right now than treating this as something to be merged directly. :)

I guess I gave those over in #2790 (comment), oops.

Do you think it's worth proceeding by trying to merge a v1 without enumerated attribute support? I'd be hesitant to do that in the HTML Standard, but for jsdom it's a definite improvement over our current situation, so I'd be fine with that here. Still, it'd be awesome if we could figure out enumerated attributes too.

Otherwise, hmm. I wonder if we should abstract the code we see repeated here a few times for URL handling. E.g. in jsdom (not webidl2js), a util like getURLStringFromAttribute(this, "src") or getURLStringFromAttribute(this, "src", { disallowEmpty: true })

Updated for the latest webidl2js change. Most of the concerns raised in #2790 should now be fixed (with the exception of state-related stuff, which we'll punt into the future for now).