Contributions to this repository are intended to become part of the World Wide Web Consortium's (W3C) HTML Recommendation, and are governed by the W3C Patent Policy and Software and Document License.
Before making your first contribution, you should read the documentation on editing conventions and the source documents. You may also want to read how the spec is built.
Editorial improvements are welcome, just make a Pull Request (PR)! You may encounter a warning about Intellectual Property Rights (IPR) commitments if you are not a member of the W3C Web Platform Working Group (WebPlat WG), but this will be handled by the WebPlat WG editorial team. Specific concerns about IPR and the W3C may be found in the Intellectual Rights FAQ.
Your concern might already be known. Before beginning work, check the issue tracker to see if there are any existing discussions about the issue. If you want to help but are unsure how to begin, some issues are marked as good first issues or help wanted. These might be good places to start.
Proposals for new elements are best discussed on the WICG Discourse.
To make substantive contributions, changes that clarify or update conformance requirements, you must either participate in the W3C Web Platform Working Group or make a non-member patent licensing commitment. This is because the W3C Patent Policy depends on granting licenses for the essential claims needed to implement the spec. A list of previous substantive contributions can be found on the issue tracker.
If your contribution includes the work of others, please see [Contributing Documentation](https://github.com/w3c/html/blob/master/docs/contributing-documentation.md for further guidance).
For substantive changes, a corresponding web-platform-tests PR is highly appreciated. The W3C defines a normative change as edits that affect the formal part of the Recommendation, rules that everyone must follow. Non-substantive changes affect supplementary information and guidance for these rules.
Typically, both PRs will be merged at the same time. Note that a test change that contradicts the spec should not be merged before the corresponding spec change. If testing is not practical, please explain why and if appropriate file an issue to follow up later. Add the type:untestable or type:missing-coverage label as appropriate.
It may help to familiarize yourself with the specific language used by the W3C HTML Recommendation. A full Index of terms used by the specification is available, as well as a Manual of Style.