Comments (9)
It would be really nice if the indices could be autogenerated. It's one of the things I really like about Bikeshed.
from html.
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.
from html.
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 ?
from html.
@zcorpan was the original OP, so he can probably tell us.
from html.
Whatever makes it easy to find stuff in the spec. IDL index would be OK for registerProtocolHandler.
from html.
@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
from html.
@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
from html.
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?
from html.
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.
from html.
Related Issues (20)
- Sentence in 6.11.7 doesn't seem right
- Slowly removing/reducing the margin collapsing quirk. HOT 2
- Provide named character entities for invisible and ambiguous Unicode characters HOT 3
- Upcoming WHATNOT meeting on 5/2/2024 HOT 3
- Move GitHub Wiki content to README or spec/website page HOT 4
- Add `nostr` to registerProtocolHandler
- Should keyup be an activation triggering input event?
- Redundant wording in 4.8.13 The area element HOT 1
- Composable lifecycle hooks HOT 8
- 4.8.13 The area element: Inconsistency between circle state and rectangle state
- Clarify precedence of A2B tags in ICC profiles
- The `interesttarget` attribute/proposal HOT 1
- HTML parser changes for stylable `<select>` HOT 18
- event.persisted for pagereveal event HOT 4
- textarea autoheight HOT 1
- Allow DOM manipulation scripts when JavaScript is disabled HOT 2
- Prefixes and suffixes for textual `<input>`s
- Using URL as map keys is problematic without defining equality
- Meeting 1 for joint OpenUI-WHATWG/HTML-CSSWG task force on styleable form controls HOT 5
- Content model and 'what' to render for stylable `<select>` elements HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from html.