Skip to content

Data guidelines: add mini style guide for notes - #30762

Open
ddbeck wants to merge 1 commit into
mdn:mainfrom
ddbeck:data-guidelines-add-mini-style-guide-for-notes/zrxolvszooqt
Open

ddbeck wants to merge 1 commit into
mdn:mainfrom
ddbeck:data-guidelines-add-mini-style-guide-for-notes/zrxolvszooqt

Conversation

@ddbeck

@ddbeck ddbeck commented Oct 6, 2026

Copy link
Copy Markdown
Contributor

Summary

This adds a miniature style guide for writing maintainable notes.

Test results and supporting details

None. This is just vibes: the four things that I think make the biggest difference to writing high-quality notes in BCD. I'm open to suggestions here, though I'd like to keep it short.

Related issues

Too various to count, but see BCD v6.0.29 notes audit for extensive discussion of notes quality.

@github-actions github-actions Bot added the docs Issue or pull request concerning project documentation. label Oct 6, 2026
@ddbeck
ddbeck force-pushed the data-guidelines-add-mini-style-guide-for-notes/zrxolvszooqt branch from 8b7df90 to 989c3f6 Compare October 6, 2026 10:44
@github-actions github-actions Bot added the size:m Pull request changing 25-100 lines of code. label Oct 6, 2026
@github-actions

github-actions Bot commented Oct 6, 2026 •

Copy link
Copy Markdown
Contributor

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

@ddbeck
ddbeck force-pushed the data-guidelines-add-mini-style-guide-for-notes/zrxolvszooqt branch from 989c3f6 to 1c1f552 Compare October 6, 2026 10:47

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's also link this to the index.

Notes are the least structured part of browser compat data and the most likely to become stale and outdated.
Help make the notes easier to maintain by following these style rules:

- Be specific.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Should we be bold for readability? (applies to all four)

Suggested change
- Be specific.
- **Be specific.**

- Be specific.
Avoid shorthands like _supports_, _unsupported_, or _works_.
Instead, describe the browser behavior or how it differs from expectations.
For example, write "The method always throws a `TypeError` exception."

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I vaguely remember you preferring to call out the method:

Suggested change
For example, write "The method always throws a `TypeError` exception."
For example, write "The `example()` method always throws a `TypeError` exception."

Comment on lines +31 to +32
For example, write "Before version 59, the method always throws…" or "In flex layouts, the `auto` value has no effect."
Do not write, "The method always throws in versions 59 and earlier" or "The `auto` value has no effect in flex layouts."

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a good idea to name the browser, rather than just talking about "versions". Otherwise it's easy to miss if a note was accidentally added to the wrong browser.

Suggested change
For example, write "Before version 59, the method always throws…" or "In flex layouts, the `auto` value has no effect."
Do not write, "The method always throws in versions 59 and earlier" or "The `auto` value has no effect in flex layouts."
For example, write "Before Chrome 59, the method always throws…" or "In flex layouts, the `auto` value has no effect."
Do not write, "The method always throws in Chrome 59 and earlier" or "The `auto` value has no effect in flex layouts."

Comment on lines +34 to +36
- Cite your sources.
If a note summarizes a relevant browser bug, release notes text, or other authority, then link to it at the end of the note.
For example, write "See [bug 1234](#)."

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this also mention when to use impl_url, for example with partial_implementation: true and a single note!?

If a note summarizes a relevant browser bug, release notes text, or other authority, then link to it at the end of the note.
For example, write "See [bug 1234](#)."

- Prefer the present tense, even for notes on past behavior.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Isn't it more than a preference?

Suggested change
- Prefer the present tense, even for notes on past behavior.
- Use the present tense, even for notes on past behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Issue or pull request concerning project documentation. size:m Pull request changing 25-100 lines of code.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants