-
Notifications
You must be signed in to change notification settings - Fork 2
Web Components docs #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hey @trusktr! Thanks for filing this issue! The Docs CG just started its work yesterday! We are wondering if we should talk about Web Components in our next Community Group call. Would you be up for that? We're meeting every 2nd Tuesday, at 5pm CEST. I'm going to sent out an invite for May 6 soon. We had a few questions:
Looking forward to chat about Web Component docs either here or in the call! |
In preparation for the W3C Docs CG call on Web Components, I took a look at the survey responses from the 2024 State of HTML survey: Some survey free form responses specifically on the quality of WC docs:
From other free form responses you can derive unanswered questions that web developers have. Possibly a starting point to check in current docs if are helpful to give answers or guidance at all.
|
@tayloregivens gave a talk on Web Components: https://www.youtube.com/watch?v=dEFfqqJWLwQ. It provided me a great overview into current WC discussions. Some quotes I found interesting and that maybe hint at how people (don't) adopt WC's currently.
So, this hints that more docs are needed to get the hang of WCs and also that frameworks play a major role here. |
Brief look into the current content outlines we seem to have. It's not a lot, so the needs expressed above are probably not addressed by the current state of the docs on neither MDN or webcomponents.guide: MDN(kept relatively up-to-date)
webcomponents.guide(last updated in 2023?)
|
@Elchi3 a few years ago we tried to start a docs-and-guides effort in the WCCG. We came up with this content outline to work from: https://github.com/webcomponents-cg/docs-and-guides/blob/main/plan/outline.md |
Yesterday's Docs CG call was all about Web Components. Here are the meeting notes: Notes from yesterday's call: https://github.com/w3c-cg/webdocs/blob/main/meetings/2025-05-06.md |
Looking at the WC docs on MDN, and thinking of the context of today's call, I would say that the MDN docs are very much targeted at "implementing your own WC from scratch" and don't really acknowledge the existence of libraries, or what someone might need to know who is using a library. So for instance the main guide is https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements, which is mostly about implementing a custom element. I think it would be worth looking at these docs from the perspective of two audiences: people writing custom elements from scratch, and people using a library like Lit. And making this distinction explicit in the docs: essentially providing two separate paths for people. We could also review the Lit docs to understand where the points are that they want to reach out into library-agnostic docs.
Another separate issue is that there's no guide material on MDN about |
Another angle highlighted in yesterday's call was that guides are missing for "using a web component" in the sense of "integrating a web component coming from a third party within a page": how to define slots when you instantiate the component, how to use That part of the guide would be independent from the library that might have been used to create the web component. |
From the Lit team's point of view on this, I think it's worthwhile examining the docs from these two perspectives, but I'm less sure about two actually different paths. At least in Lit's case there isn't anything in the vanilla web components reference or concepts that we wouldn't want developers to know. For example, while Lit does implement some of the standard lifecycle callbacks for the developer, the developer should ideally still understand them and can still override and implement them themselves. One type of thing that could have some separate vanilla vs library guidance is best practices that libraries take care of for you, like using templates, batching DOM updates, implementing reactive class properties, and reflecting attributes. These are things have a little bit of opinion to them, and need glue code and patterns just above the most basic usage of the raw APIs. I do think that two paths should exist for writing vs using custom elements, especially so that component authors have common high quality docs to point their users to for fundamental platform behavior. |
We have a
docs-and-guides
channel in the WCCG discord: https://discord.gg/PZH8ucFHp2It'll be nice to coordinate on web docs. The WCCG started a docs site at https://webcomponents.guide.
The text was updated successfully, but these errors were encountered: