- From: Pine <notifications@github.com>
- Date: Tue, 01 Oct 2019 16:58:58 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/776/537278968@github.com>
Hey @runem, thanks for the writeup. To your **suggestions**, I'll have a more detailed response later — preparing for a conference and boarding plane soon. But here are some high-level notes: - I suggest starting smaller and only add fields that address real need, serve clear purpose & have no controversy/alternative design. It's always easier to add a field later, but it can hurt to change/remove a field when others are already depending on it. - I'd stay close to spec. For example adding one more field to describe a CSS property based on [CSS Value definition syntax](https://drafts.csswg.org/css-values-3/). Inventing a custom syntax and type system isn't feasible. - The design of [LSP](https://microsoft.github.io/language-server-protocol/) avoided being too strict to define every UX interaction that can happen in the LSP methods, but not too loose to give guidance for editor UI implementations. It also provided a [reference implementation](https://github.com/Microsoft/vscode-languageserver-node). I think that's a good model to learn from. Before expanding the format too much, I hope the tooling is ready. Your analyzer would help a lot. But what about a doc generator that can generate doc from the data format? Some other notes: > Experimental support in VS Code We [marked it stable](https://code.visualstudio.com/updates/v1_38#_custom-data-marked-as-stable) last month. Here's the repo: https://github.com/microsoft/vscode-custom-data The format is versioned and we plan to [roughly follow SemVer](https://github.com/microsoft/vscode-custom-data#versioning). Now the development of this custom data format is mostly driven by editor language features such as completion, hover information etc. There's no consumer generating docs from such data so we haven't considered fields that would be useful for that purpose. > describe the API of built-in HTML elements using this format. That's what we are doing already. See https://github.com/microsoft/vscode-custom-data. The `/web-data` package is published to https://www.npmjs.com/package/vscode-web-custom-data. The data is aggregated from MDN, HTML spec, WAI-ARIA spec, etc. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/776#issuecomment-537278968
Received on Tuesday, 1 October 2019 23:59:20 UTC