Keep running into issues where browser engineers write spec IDL that violates the IDL spec in whatever ways their binding implementation does not enforce. If we're lucky a second implementor, with a binding implementation with different holes, tries to implement before it ships
-
Show this thread
-
Replying to @really_bz @bz_moz
is there a way to fix this? If I understand what you mean it's wrong in their spec before in their implementation, right? Auto-idl validator service or something?
2 replies 0 retweets 0 likes -
Replying to @briankardell @bz_moz
Spec generators should check webidl correctness, imo.
@tabatkins does bikeshed do this?1 reply 0 retweets 0 likes -
That would be ideal, yes. That said, unless the spec generators are parsing all the IDL for all specs together they can't do all possible correctness checks, because some of the IDL correctness checks are pretty non-local. The one that led to my tweet is local, though.
1 reply 0 retweets 1 like -
-
My impression from https://tabatkins.github.io/bikeshed/#idl is that bikeshed explicitly aims for a quite permissive IDL parser that does not flag most errors. Is that not correct?
2 replies 0 retweets 1 like -
Replying to @really_bz @bz_moz and
Not correct, I'm happy to catch obvious local errors. I don't want *strict* compliance with grammar, such that, say, unknown extended attributes cause parsing errors, but am open to getting stricter in general.
1 reply 0 retweets 0 likes
Great. I can certainly file the issues I run into.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.