github-elements: the index that holds GitHub's 17 web components together

A list, not a library

The first thing to settle is what this repository is not. There is no bundled component here, no build output, and no entry point you would import. The tracked files make that obvious:

CODEOWNERS
LICENSE
README.md
bower.json
generate.js
package.json
readme.head.md
readme.tail.md

Two files called `readme.head.md` and `readme.tail.md` sit either side of a script that the package manifest wires up:

  "scripts": {
    "generate": "node generate.js"
  },

Read together, those files say what the repository does. `generate.js` produces the README from a head file, a tail file and whatever it knows about the member repositories, which is why every entry in the README follows the same three line shape: a heading linking to the element's own repository, one sentence describing it, then a Repository link beside an Example link. The README is generated output, and the generation is the product.

The package manifest confirms the framing. The name is `github-elements`, the description is GitHub's Web Component collection, and it is marked `"private": true` with `"main": ""`, which is the shape of a package that is never published and never consumed.

Every dependency is pinned at the wildcard

All seventeen dependencies are declared as `"*"`, one per element, which means the manifest expresses membership and nothing else. There is no lockfile in the tree and no version anywhere in the manifest, so nothing here tells you which release of `@github/auto-check-element` was current when the index was last built.

That choice is defensible for a catalogue and would be indefensible for a library. An index that pinned versions would go stale in a different way, the moment a member repository cut a release, and the index exists to answer what exists rather than what to install. Combined with the private flag and the empty entry point, the three decisions are consistent: this package is a list of pointers.

The practical consequence is that you should never add `github-elements` to your own manifest expecting a component to arrive. Install `@github/tab-container-element` or whichever element you actually want, from its own repository, and pin a real version there.

Reading the list as a catalogue of solved problems

The README describes seventeen elements in one line each, and the value of the page is in what that list covers. The input elements are the densest cluster. `auto-check-element` validates its value against a server endpoint, `remote-input-element` sends its value to a server endpoint and renders the response body, and `auto-complete-element` fills input values from server search results. Three different shapes of talking to a server from a form control.

Then there is the set that solves interaction problems in ways that are genuinely hard to get right by hand. `details-dialog-element` is a modal dialog opened with `<details>`, `details-menu-element` is a menu opened the same way, `tab-container-element` is described as an accessible tab container with keyboard support, and `task-lists-element` handles drag and drop for task list items. The accessibility claim on the tab container is the one worth checking against your own requirements, since it is the only element in the list whose description promises behaviour rather than structure.

The rest cover rendering and editing. `clipboard-copy-element` copies element text or input values to the clipboard, `file-attachment-element` handles attachment by drag and drop or file input, `filter-input-element` displays elements in a subtree matching filter text, `g-emoji-element` backports native emoji characters to browsers that lack them by swapping in fallback images, `image-crop-element` crops a square image and returns x, y, width and height, `include-fragment-element` is a client-side includes tag, `markdown-toolbar-element` adds formatting buttons to text inputs, `text-expander-element` expands text snippets from a suggestion menu as you type, and `typing-effect-element` shows text as though it were being typed.

The last two are worth a note of caution. A typing effect and a text expander are novelty behaviours, and the fact that they sit in the same list as `auto-check-element` tells you the collection reflects what the GitHub teams have built rather than a curated standard.

Two repositories overlap, and the page cross-links them

github/relative-time-element` is listed in this catalogue as web component extensions to the standard <time> element, and it also has a repository of its own with its own README, its own package manifest and its own examples. That is the clearest illustration of how the index works: it is a superset view, and the per-element repository is where the detail lives.

The Example links all point at GitHub Pages sites served from the individual element repositories, one per element, each under an examples path. So the reading order the repository implies is the README for the map, the element repository for the API, and the examples site for the markup. Nothing in the index tells you how to import an element, because that answer belongs to the element's own documentation.

If you are evaluating one of these components, the README line is a starting point rather than a specification. The description of `image-crop-element` promising x, y, width and height tells you the shape of the output and nothing about the events, attributes or browser support, all of which live one hop away.

Licence, topics and the absence of releases

The repository is MIT licensed and carries two topics, `element-collection` and `web-components`, which together tell you how a reader is expected to find it. There is a `CODEOWNERS` file, which for a catalogue like this is the mechanism that decides who is allowed to add an entry.

There is also a `bower.json` at the root, a leftover from the era when this kind of browser component was distributed through Bower rather than npm. Its presence alongside a modern ES module manifest, where the package type is set to module, is a fair signal about the repository's age. The index is still being maintained, with the last push on 2026-09-14, but the file list carries history from an older distribution model.

The release list is empty. There are no tagged versions of `github-elements` at all, which follows from the design: an index that points at other repositories has nothing to version. If you were waiting for a version bump to know an element had changed, this repository will never tell you, and the per-element repositories are the only place that information e

Editorial conclusion

github-elements is worth reading as a map and not worth installing. The list tells you which problems GitHub already solved with custom elements, from a server-validated input to a client-side includes tag and an accessible tab container, and each entry links to a repository with its own examples. The dependency wildcard is the concrete reason the whole package is marked private with an empty `main` field, which confirms it is a catalogue rather than a distributable library. Pick the individual element you need from this page, install that package directly, and ignore this repository in your dependency tree.

Frequently asked questions

Official sources

1. github/github-elements on GitHub
2. Issues
3. License: MIT
4. Project website
5. README