Skip to content

contributing.md

Latest commit

 

History

History
102 lines (68 loc) · 2.71 KB

contributing.md

File metadata and controls

102 lines (68 loc) · 2.71 KB

Contributing

Contributions are welcome. You can help by reporting a bug, improving the documentation, refining browser support notes, or proposing a focused pull request.

Ways to contribute

  • Report a bug or regression.
  • Suggest an improvement or a new feature.
  • Improve the docs, examples, or comparisons.
  • Refine browser support notes or progressive enhancement guidance.
  • Submit a pull request for a focused fix.

Before opening a pull request

Open an issue first if the change:

  • alters public behavior
  • introduces a new opinionated rule
  • changes the package structure or public import paths
  • affects browser support expectations

Small documentation fixes and targeted corrections can usually go straight to a pull request.

Local workflow

  1. Fork the repository.
  2. Create a dedicated branch.
  3. No dependency installation is currently required.
  4. Make your changes.
  5. If you touched src/, dist/, or public CSS entry points, rebuild the bundles:
npm run build
  1. Update the relevant docs and changelog if the public behavior changed.
  2. Open a pull request with a clear summary.

What to update when behavior changes

If your contribution changes the way browserux.css behaves in practice, please update the matching project surfaces:

  • the relevant CSS source or bundle entry
  • CHANGELOG.md
  • the matching documentation page in docs/
  • docs/browser-support.md if browser support expectations changed

If the same concept exists in French documentation, please update fr/ as well when possible.

Project expectations

  • Preserve the project's minimal, native, accessibility-first approach.
  • Prefer focused changes over large mixed pull requests.
  • Add short comments for non-obvious CSS rules.
  • Avoid changing public behavior casually in the name of normalization.
  • Treat progressive enhancement and browser support claims carefully.

Testing expectations

Before submitting a PR, test the change as far as it makes sense for the scope:

  • Chrome
  • Firefox
  • Safari
  • Edge

For documentation-only changes, no build is required. For CSS bundle changes, make sure generated bundles stay in sync.

Pull request checklist

  • The change is focused and clearly explained.
  • Public behavior changes are documented.
  • npm run build was run when needed.
  • Related docs were updated.
  • English and French docs were kept aligned when practical.
  • Manual browser checks were performed when relevant.

Need inspiration?

Good contributions often look like this:

  • tightening a browser support note
  • clarifying why a rule exists
  • improving an accessibility fallback
  • correcting a too-opinionated default
  • adding a missing integration or documentation recipe