Samples tied to new functionality in Google Chrome.
Each sample corresponds to an entry inhttps:// chromestatus /features,and using that interface is currently the best way to browse.
Please useSAMPLE_STARTING_POINTas a starting point.
While it's possible to simply create a standard set of HTML/JS/CSS files within the new directory, you can take advantage of theJekyll-based templating system to handle most of the boilerplate. Any files that start with afront matter block will be templated, and any other files will be served verbatim.
If you're still unsure, two canonical samples that use templates are:
Follow theUsing Jekyll with Pages guide to mimic the production Jekyll environment during local development.
Once complete, please file a pull request against thegh-pagesbranch with your sample.
It's ideal when filing a pull request @-mention the relevant engineer who worked on adding the
feature into Chrome, to solicit their feedback and ensure that the sample properly describes
the functionality. The email address of the engineer who worked on a given feature can be found in
the correspondinghttps:// chromestatus /featuresentry. If you're unsure of the GitHub
username corresponding to the engineer, an alternative is to email them a link to the pull request
and ask for feedback directly.
The samples ideally should follow theGoogle JavaScript Style Guide,
and that's enforced viaESLint,using theeslint-config-google
base configuration, with a few overrides as needed.
Linting can be performed vianpm run lint(make sure tonpm installfirst).
Various IDEs offerreal-time ESLint integration, and using those integrations that can help avoid errors before anything gets checked in.
Travis CIis currently being used to verify that the Jekyll build completes successfully and that linting passes without errors.