Add an index of methods and IDL attributes about html

[mikewest]

It would be really nice if the indices could be autogenerated. It's one of the things I really like about Bikeshed.

[annevk]

Yeah, I think wattsi has an open issue on that for IDL. The other things might be trickier given the custom descriptions, but should be possible too.

[domenic]

The OP sounds kind of like it is looking for a flat list of some sort. Is that what we want? Or do we want something more like Bikeshed's IDL index, see e.g. https://url.spec.whatwg.org/#idl-index ?

[annevk]

@zcorpan was the original OP, so he can probably tell us.

[zcorpan]

Whatever makes it easy to find stuff in the spec. IDL index would be OK for registerProtocolHandler.

[sideshowbarker]

@dontcallmedom recently created https://github.com/dontcallmedom/webidlpedia, a tool that generates a master index from all IDL blocks from multiple specs. Output from it is at https://dontcallmedom.github.io/webidlpedia/

It should be pretty easy to modify that to generate an index for just the HTML spec.

Incidentally, @tidoust created a related tool, https://github.com/tidoust/reffy, that collects other info about IDL from specs and generates a report about all problems found. Output from that is at https://github.com/tidoust/reffy/wiki/Report-per-anomaly-%2820160711%29

[sideshowbarker]

@dontcallmedom recently created https://github.com/dontcallmedom/webidlpedia,

d’oh re-reading the issue description here now I see it says “index of methods and IDL attributes”, which @dontcallmedom’s tool doesn’t (yet) generate

[domenic]

That tool is OK, although it uses the wrong HTML spec which causes a lot of confusion and spurious errors. The issue is that it uses Node.js, and we've so far resisted adding further runtimes to the build pipeline. If we could use Node.js, I'd be able to knock out a ton of the build/Wattsi feature requests, as I'm very familiar with that environment.

It seems like the "correct" thing is to add this to Wattsi, which already has all the relevant information in-memory as it does all the IDL processing. But maybe we should give up on that plan and just allow Node.js usage, despite it being inefficient to duplicate the DOM and IDL processing in two separate pipeline stages?

[sideshowbarker]

The issue is that it uses Node.js, and we've so far resisted adding further runtimes to the build pipeline.

True but we already have a dependency on perl (though I know our plan has been to replace all the cases of perl dependencies with native code in wattsi itself).

If we could use Node.js, I'd be able to knock out a ton of the build/Wattsi feature requests, as I'm very familiar with that environment.

IMHO adding a dependency on Node.js would at least make us no worse off than having perl dependency. And if we have enhancements we are blocked right now on not having among us enough competency to implement in perl or pascal but that we do in Node.js, then IMHO adding a dependency on Node.js would be a net win—especially if it also allows us to replace the perl dependencies completely, so that we would still be depending on one other runtime (it would just be Node.js instead of perl).

But maybe we should give up on that plan and just allow Node.js usage, despite it being inefficient to duplicate the DOM and IDL processing in two separate pipeline stages?

Yeah it seems like that might be the most pragmatic choice to make at this point.