@atlaskit/ads-mcp 0.17.4 → 0.18.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +16 -0
- package/dist/cjs/tools/get-all-tokens/index.js +7 -3
- package/dist/cjs/tools/get-guidelines/guidelines-structured-content.codegen.js +3 -3
- package/dist/cjs/tools/get-lint-rules/lint-rules-structured-content.codegen.js +2 -6
- package/dist/es2019/tools/get-all-tokens/index.js +6 -2
- package/dist/es2019/tools/get-guidelines/guidelines-structured-content.codegen.js +3 -3
- package/dist/es2019/tools/get-lint-rules/lint-rules-structured-content.codegen.js +2 -6
- package/dist/esm/tools/get-all-tokens/index.js +6 -2
- package/dist/esm/tools/get-guidelines/guidelines-structured-content.codegen.js +3 -3
- package/dist/esm/tools/get-lint-rules/lint-rules-structured-content.codegen.js +2 -6
- package/dist/types/tools/get-guidelines/guidelines-structured-content.codegen.d.ts +1 -1
- package/dist/types/tools/get-lint-rules/lint-rules-structured-content.codegen.d.ts +1 -1
- package/dist/types-ts4.5/tools/get-guidelines/guidelines-structured-content.codegen.d.ts +1 -1
- package/dist/types-ts4.5/tools/get-lint-rules/lint-rules-structured-content.codegen.d.ts +1 -1
- package/package.json +4 -4
- package/dist/cjs/tools/get-all-tokens/tokens.js +0 -18
- package/dist/es2019/tools/get-all-tokens/tokens.js +0 -13
- package/dist/esm/tools/get-all-tokens/tokens.js +0 -13
- package/dist/types/tools/get-all-tokens/tokens.d.ts +0 -7
- package/dist/types-ts4.5/tools/get-all-tokens/tokens.d.ts +0 -7
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,21 @@
|
|
|
1
1
|
# @atlaskit/ads-mcp
|
|
2
2
|
|
|
3
|
+
## 0.18.0
|
|
4
|
+
|
|
5
|
+
### Minor Changes
|
|
6
|
+
|
|
7
|
+
- [`44a9ad271ff5d`](https://bitbucket.org/atlassian/atlassian-frontend-monorepo/commits/44a9ad271ff5d) -
|
|
8
|
+
[ux] Update ADS Structured content. Now includes guidelines, lint rules, components, Icon lab
|
|
9
|
+
|
|
10
|
+
## 0.17.5
|
|
11
|
+
|
|
12
|
+
### Patch Changes
|
|
13
|
+
|
|
14
|
+
- [`0daada0469ab8`](https://bitbucket.org/atlassian/atlassian-frontend-monorepo/commits/0daada0469ab8) -
|
|
15
|
+
Remove `no-legacy-icons` from lint rules structured content. The rule no longer exists following
|
|
16
|
+
the removal of `@atlaskit/icon/glyph` legacy icons.
|
|
17
|
+
- Updated dependencies
|
|
18
|
+
|
|
3
19
|
## 0.17.4
|
|
4
20
|
|
|
5
21
|
### Patch Changes
|
|
@@ -8,8 +8,8 @@ exports.listGetAllTokensTool = exports.getAllTokensTool = void 0;
|
|
|
8
8
|
var _regenerator = _interopRequireDefault(require("@babel/runtime/regenerator"));
|
|
9
9
|
var _asyncToGenerator2 = _interopRequireDefault(require("@babel/runtime/helpers/asyncToGenerator"));
|
|
10
10
|
var _zod = require("zod");
|
|
11
|
+
var _tokenMetadata = require("@atlaskit/tokens/token-metadata");
|
|
11
12
|
var _helpers = require("../../helpers");
|
|
12
|
-
var _tokens = require("./tokens");
|
|
13
13
|
/* eslint-disable-next-line import/extensions -- MCP SDK requires .js extensions for ESM imports */
|
|
14
14
|
|
|
15
15
|
var inputSchema = _zod.z.object({});
|
|
@@ -31,12 +31,16 @@ var getAllTokensTool = exports.getAllTokensTool = /*#__PURE__*/function () {
|
|
|
31
31
|
while (1) switch (_context.prev = _context.next) {
|
|
32
32
|
case 0:
|
|
33
33
|
return _context.abrupt("return", {
|
|
34
|
-
content:
|
|
34
|
+
content: _tokenMetadata.tokens.map(function (token) {
|
|
35
35
|
return {
|
|
36
36
|
// NOTE: Ideally one day the MCP would support structured content…
|
|
37
37
|
// eg. `type: 'object', data: token`
|
|
38
38
|
type: 'text',
|
|
39
|
-
text: JSON.stringify(
|
|
39
|
+
text: JSON.stringify({
|
|
40
|
+
name: token.name,
|
|
41
|
+
exampleValue: token.exampleValue,
|
|
42
|
+
usageGuidelines: token.usageGuidelines
|
|
43
|
+
}, null, 2)
|
|
40
44
|
};
|
|
41
45
|
})
|
|
42
46
|
});
|
|
@@ -9,7 +9,7 @@ exports.guidelinesStructuredContent = void 0;
|
|
|
9
9
|
*
|
|
10
10
|
* Structured content for content guidelines from design-system-docs foundations content.
|
|
11
11
|
*
|
|
12
|
-
* @codegen <<SignedSource::
|
|
12
|
+
* @codegen <<SignedSource::172be2830ddae4adfd4b9c4a11d5b54a>>
|
|
13
13
|
* @codegenCommand yarn build structured-docs
|
|
14
14
|
*/
|
|
15
15
|
|
|
@@ -35,7 +35,7 @@ var guidelinesStructuredContent = exports.guidelinesStructuredContent = [{
|
|
|
35
35
|
content: "import {\n\tBrandAndNeutralChartTokensTable,\n\tCategoricalChartTokensTable,\n\tSemanticChartTokensTable,\n} from '@af/design-system-docs-ui';\n\nData visualization is the representation of information in pictorial or graphical format, such as\ncharts, graphs, maps, and diagrams. These visuals aid in the communication of complex data so that\ninsights can be more easily drawn.\n\nBecause color can affect our perception of information, the appropriate use of color is critical in\nmaking a data visualization successful.\n\n## Applying color to data visualizations\n\nColor in Atlassian apps experiences are applied using\n[design tokens](https://atlassian.design/tokens/design-tokens). For data visualization, chart color\ntokens are available to ensure appropriate color contrasts can be met. Use chart tokens for lines,\nbars or other UI representing the data. For elements of the chart interface such as axes and text,\nuse border and text tokens.\n\n<img\n\tsrc={dataVisPageAnalyticsLight}\n\talt=\"In this chart example, the title and legend text uses `color.text`, the chart grid lines uses `color.border`, the threshold line uses `color.chart.neutral`, the line representing chart data uses `color.chart.brand`, and the tick labels uses `color.text.subtle`.\"\n/>\n\n- **Title**: `color.text`\n- **Tick label**: `color.text.subtle`\n- **Threshold or reference line**: `color.chart.neutral`\n- **Legend**: `color.text`\n- **Gridline**: `color.border`\n- **Mark**: `color.chart.brand`\n\n## Types of chart colors\n\n- [Single-color charts](https://atlassian.design/foundations/color/data-visualization-color#single-color-charts)\n- [Categorical](https://atlassian.design/foundations/color/data-visualization-color#categorical)\n- [Status and severity](https://atlassian.design/foundations/color/data-visualization-color#status-and-severity)\n- [Custom charts](https://atlassian.design/foundations/color/data-visualization-color#custom-charts)\n\nSequential and divergent chart colors are not currently supported.\n\n### Single-color charts\n\nFor data visualization requiring only one color, use `color.chart.brand` as the default color\nchoice. This ensures all data visualization embodies our brand's visual language.\n\nIf the data represents status or severity, use the appropriate\n[status or severity color token](https://atlassian.design/foundations/color/data-visualization-color#status-and-severity)\ninstead.\n\nTo highlight one piece of data from a data set, use `color.chart.neutral` for the less important\ninformation so that the important data can stand out.\n\n<img\n\tsrc={dataVisPageAnalyticsLight}\n\talt=\"Bar chart showing unit test coverage over time. Today is highlighted in blue.\"\n/>\n\n<BrandAndNeutralChartTokensTable />\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: dataVisColorRoleDo, alt: '' }}>\n\t\tUse a single color as the default for data visualizations. Only add more colors when needing to\n\t\tdifferentiate between data categories.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: dataVisColorRoleDont, alt: '' }}>\n\t\tDon't use more than one color in your data visualization if the additional colors don't serve\n\t\tany communication purpose.\n\t</DoDont>\n</DoDontGrid>\n\n### Categorical\n\nUse categorical chart colors when you need to differentiate two or more unrelated data categories\nfrom each other.\n\n<img\n\tsrc={dataVisCategoricalChartLight}\n\talt=\"Line chart using categorical colors to represent different conversion rates.\"\n/>\n\nFollow the same sequence as the numbers in the token names. This ensures each color is visually\ndistinct from its neighbors across all color deficiencies. If the display order can't be controlled\n(in line charts for example), provide\n[additional visual indicators](https://atlassian.design/foundations/color/data-visualization-color#dont-rely-on-color-alone).\n\n<CategoricalChartTokensTable />\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: dataVisCategoricalDo, alt: '' }}>\n\t\tLimit the number of colors presented in your data visualization to 5-6 by grouping additional\n\t\tcategories together.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: dataVisCategoricalDont, alt: '' }}>\n\t\tAvoid using more than 5-6 colors in a data visualization. Too many colors can hinder\n\t\tcomprehension.\n\t</DoDont>\n</DoDontGrid>\n\n### Status and severity\n\nThese chart colors use established color associations for status and severity, such as in progress,\nat risk, or high priority. Use these when you want to reinforce meaning through color in your data\nvisualization.\n\nIf more than one set of data exists for a given color association, use bold emphasis to represent\nthe more extreme value. For example, High priority and Highest priority both use danger tokens, but\nHighest uses `color.chart.danger.bold`.\n\nIt's important to note that status and severity colors may be hard for users with color deficiencies\nto tell apart. For this reason, use other\n[visual indicators](https://atlassian.design/foundations/color/data-visualization-color#dont-rely-on-color-alone)\nor consider\n[categorical colors](https://atlassian.design/foundations/color/data-visualization-color#categorical)\nas a better option.\n\n<img src={dataVisStatusSeverityLight} alt=\"Chart representing breakdown by priority.\" />\n\n<SemanticChartTokensTable />\n\n### Custom charts\n\nA generic set of chart color tokens is available to support data visualization experiences where end\nusers can choose their own colors.\n\nThey can also be used to build custom categorical color schemes, although our predefined\n[categorical tokens](https://atlassian.design/foundations/color/data-visualization-color#categorical)\nare recommended for better accessibility and consistency.\n\nThese tokens are available in every hue with three emphasis levels. See all custom chart tokens in\nour [design token reference list](https://atlassian.design/components/tokens/all-tokens#color-chart)\nor get guidance on\n[color picker swatches](https://atlassian.design/foundations/color/color-picker-swatches).\n\n<img src={dataVisCustomChartColorsLight} alt=\"Editing colors on a custom chart in Confluence.\" />\n\n## Interacting with chart data\n\nData visualization often allows users to drill into data by hovering or selecting a data point. Use\nchart hovered tokens to provide visual feedback for these interactions.\n\nAn alternative approach is to fade out data that isn't being interacted with. Use our\n`opacity.disabled` token for this implementation.\n\n<img\n\tsrc={dataVisChartDataLight}\n\talt=\"Two segmented bar chart examples. In the first example, hovering on one of the segments changes its shade. In the second example, hovering on one of the segments applies opacity to everything except the element being hovered on.\"\n/>\n\n## All chart color tokens\n\nFor the full list of chart design tokens and their values, see our\n[design token reference list](https://atlassian.design/components/tokens/all-tokens#color-chart).\nEvery token comes with a description to help you ensure you're using the correct one.\n\n## Chart color accessibility\n\nOur chart colors meet WCAG AA 3:1 contrast ratios when used on any of our\n[elevation surfaces](https://atlassian.design/foundations/elevation#types-of-elevations)\n([WCAG 1.4.11](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html)).\n\nThe following sections provide more guidance to help you achieve better accessibility.\n\n### Apply a border or space between adjacent colors\n\nWhile these chart colors pass 3:1 contrast ratios against surfaces, they don't against each other.\nFor this reason, apply a space or border (`color.border.inverse`) as a visual separator between data\nelements.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: dataVisAdjacentColorDoLight, alt: '' }}>\n\t\tApply a visual separator between chart colors.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: dataVisAdjacentColorDontLight, alt: '' }}>\n\t\tDon't place chart colors adjacent to each other.\n\t</DoDont>\n</DoDontGrid>\n\n### Don't place text on chart colors\n\nOur chart colors don't support accessible pairings with text, which need at least a 4.5:1 contrast.\nConsider placing text next to the chart element instead.\n\nFor use cases where text is an essential feature (for example, calendar events), consider using our\nother [color tokens](https://atlassian.design/foundations/color) instead.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: dataVisTextChartsDo, alt: '' }}>\n\t\tPosition text nearby chart data.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: dataVisTextChartsDont, alt: '' }}>\n\t\tDon't apply text over chart colors.\n\t</DoDont>\n</DoDontGrid>\n\n### Don't rely on color alone\n\nAvoid using just color to communicate meaning in your data visualization. Incorporate other visual\nindicators such as shapes, line texture, patterns, or direct labels to support users in making sense\nof the data. [Highcharts](https://www.highcharts.com/demo) provide some good examples of these\naccessible chart experiences.\n\nAdditionally, providing the data in alternative formats, such as tables and text-based descriptions,\nwill ensure all users can access the data in their preferred format.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: dataVisLineChartDo, alt: '' }}>\n\t\tIncorporate visual indicators other than color into your data visualization.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: dataVisLineChartDont, alt: '' }}>\n\t\tDon't rely on color alone to communicate meaning in your data visualization.\n\t</DoDont>\n</DoDontGrid>\n\n## Data visualization in dark mode\n\nChart color tokens currently support two color themes: light and dark. Each token maps to a\ndifferent value for each theme so their appearance differs depending on which theme is being used.\n\n- To learn the basics of tokens and themes, go to\n [design tokens](https://atlassian.design/tokens/design-tokens).\n- For detailed mappings from light to dark colors, see\n [picking colors for dark mode](https://atlassian.design/foundations/color/color-palette#picking-colors-for-dark-mode).\n Note that if you are using design tokens, you shouldn't have to map your own values.",
|
|
36
36
|
keywords: ['data visualization', 'charts', 'graphs', 'color coding', 'data colors']
|
|
37
37
|
}, {
|
|
38
|
-
content: '<SectionMessage title="">\n\tDate and time formatting is tied to a person’s locale and account settings. Because of this, what a customer sees could be different from the guidelines on this page.\n</SectionMessage>\n\n## Date and time for internationalization\n\nEach programming language has an i18n (internationalization) library that automatically localizes time and date strings based on a user’s locale settings/preferences. Time and date strings should never be localized manually by a designer, engineer, or translator.\n\nThe Product Internationalization team is responsible for creating app UI content in non-English languages by localizing externalized code strings provided by our Product Engineers.\n\nEngineers must:\n- Ensure date and time references/strings are not hardcoded \n- Reference the programming i18n library API, which will automatically format time and date strings as per a customer’s detected or selected locale.\n\n## Date formats\n\nAtlassian uses US date formatting (for example: January 12, 2028).\n\nWhen you’re handing designs over to engineers, you need to specify which date format length is needed. The i18n library API will use this information to format the date accordingly. Date and time formats should not be hardcoded.\n\nThere are 4 [date format lengths](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-date-formats): full, long, medium, and short.\n\n### Full date\n\nThe full date format is weekday, month, day, year.\n\n<DoDontGrid>\n\t<DoDont type="do">Sunday, August 14, 2028</DoDont>\n</DoDontGrid>\n\n### Long date\n\nA long date format is month, day, year\n\n<DoDontGrid>\n\t<DoDont type="do">November 8, 2008</DoDont>\n</DoDontGrid>\n\n### Medium date\n\nThe medium date format is abbreviated month, day, year. Only use this format when space is limited.\n\n<DoDontGrid>\n\t<DoDont type="do">Sep 26, 1952</DoDont>\n</DoDontGrid>\n\n#### Abbreviating months and days\n\nIf you need to abbreviate months or days, use the first 3 letters of the month or day.\n\n|Month abbreviation| Month in full| | Day abbreviation| Day in full|\n|------|-------|------|-------|------|\n|Jan | January| |Mon | Monday|\n|Feb | February| |Tue | Tuesday|\n|Mar| March| |Wed | Wednesday|\n|Apr | April| |Thu | Thursday|\n|May | May| |Fri | Friday|\n|Jun | June| |Sat | Saturday|\n|Jul | July| |Sun | Sunday|\n|Aug | August| | | |\n|Sep | September| | | |\n|Oct | October| | | |\n|Nov | November| | | |\nDec | December| | | |\n\n### Short date\n\nShort format dates are written in digits.\n\nIn most cases, avoid short format dates as different countries use the date in a different order, which can cause confusion and effect readability and usability. In the US, 10-8-2026 is October 8, 2026, but in Australia and the UK, it’s August 10, 2026.\n\nHowever, short format dates might be suitable for situations like data storage, sorting or filtering, or data export/import. If using, use the ISO 8601 international standard for numerical date format, which is YYYY-MM-DD.\n\n## Ordinal numbers\n\nDon’t use ordinal numbers (1st, 2nd, 3rd, and so on) in dates.\n\n## Date ranges\n\nIf you have a date range, use ‘to’ and not hyphens. For example: ‘2020 to 2024’. Hyphens are read out by screen readers as ‘hyphen’, which can lead to confusion.\n\nAn exception is financial years, which use a hyphen without spaces on either side. For example: FY2008-09\n\nUse ‘and’ if a range is preceded by ‘between’. For example: He was in Paris between 2025 and 2026.\n\n<DoDontGrid>\n\t<DoDont type="do">2014 to 2015</DoDont>\n\t<DoDont type="dont">2014-15</DoDont>\n</DoDontGrid>\n\n## Time formats\n\nShow time in digits for precision and to give a clearer expression of time.\n\nSpecify to engineers which time format length is needed. The i18n library API will then format the time according to a customer’s account settings. Make sure time is not hardcoded.\n\nUse a colon (:) to separate the hours and minutes (though this might change depending on a user’s locale and account settings).\n\nLike dates, there are 4 [time format lengths](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-time-formats): full, long, medium, and short.\n\n### Full time\n\nThe full time format is hour, minutes, seconds, and time zone spelt out.\n\n<DoDontGrid>\n\t<DoDont type="do">3:30:10 p.m. Pacific Standard Time</DoDont>\n</DoDontGrid>\n\n### Long time\n\nThe long time format is hour, minutes, seconds, and the time zone initials.\n\n<DoDontGrid>\n\t<DoDont type="do">11:18:30 p.m. PST</DoDont>\n</DoDontGrid>\n\n### Medium time\n\nThe medium time format is hour, minutes, and seconds.\n\n<DoDontGrid>\n\t<DoDont type="do">8:50:28 a.m.</DoDont>\n</DoDontGrid>\n\n### Short time\n\nThe short time format is hour and minutes.\n\n<DoDontGrid>\n\t<DoDont type="do">2:40 p.m.</DoDont>\n</DoDontGrid>\n\n### 24-hour time\n\nThe 24-hour format is useful for more serious communications, for example in the case of outages and security comms. The use of the 24-hour format is mostly system-driven by the i18n library API.\n\nThis format numbers hours from 00:00 hours (midnight) to 23:59 and uses 4 digits: the first 2 digits are the hours and the next 2 digits are the minutes. Use a colon (:) to separate the hours and minutes, though this might change depending on someone\'s account settings.\n\n## Writing time\n\n### Duration and timestamps\n\nWhen writing timestamps, labels on graphs, or durations, avoid using zeros before the hour. For example: 5:29. not 05:29. Use a colon between the hours and minutes with no spaces on either side.\n\n### Using a.m. and p.m.\n\nFormat time using ‘a.m.’ and ‘p.m.’ when creating content like blogs, manuals, and instructions.\n- Lowercase ‘a.m.’ and ‘p.m.’\n- Use periods between the letters\n- Add a space between the time and the ‘a.m.’ or ‘p.m.’. For example: 6:30 a.m. (not 6:30a.m.)\n\n### Time range\n\n- If you have a time range that’s entirely in the morning or evening, use \'a.m.\' or \'p.m.\' only once. For example: 6:30 to 10 p.m.\n- If the time range goes from the morning into the evening (or vice versa), use both. For example: 10 a.m. to 2 p.m.\n\n### Noon, midday, and midnight\n\nWhere suitable, use ‘noon’, ‘midday’ or ‘midnight’ instead of ‘12 am’ or ‘12 pm’ as it makes it easier for people to differentiate between these times.\n\n### Avoid using ‘fortnightly ‘or ‘bi’ for months and years\n\nAvoid using ‘fortnightly’ and the prefix ‘bi’ to mean either 2 or twice, as these terms can be confusing.\n\nInstead of:\n- **Fortnightly**: write ‘every 2 weeks’\n- **Bimonthly**: write ‘twice a month’ or ‘every 2 months’\n- **Biannual**: write ‘twice a year’ or ‘every 2 years’.\n\n<DoDontGrid>\n\t<DoDont type="do">Your sprint will repeat every 2 weeks.</DoDont>\n\t<DoDont type="dont">Your sprint will repeat fortnightly.</DoDont>\n</DoDontGrid>\n\n## Date and time formats\n\nThere are also full, long, medium, and short format lengths when combining date and time.\n\n### Full date and time\n\n<DoDontGrid>\n\t<DoDont type="do">Wednesday, June 12, 2024 at 6:25:59 p.m. Eastern Standard Time</DoDont>\n</DoDontGrid>\n\n### Long date and time\n\n<DoDontGrid>\n\t<DoDont type="do">April 25, 2027 at 9:05:32 p.m. PST</DoDont>\n</DoDontGrid>\n\n### Medium date and time\n\n<DoDontGrid>\n\t<DoDont type="do">Sep 5, 1999, 1:25:59 a.m.</DoDont>\n</DoDontGrid>\n\n### Short date and time\n\n<DoDontGrid>\n\t<DoDont type="do">2028-10-22, 6:25 p.m. </DoDont>\n</DoDontGrid>\n\n## Relative date and time\n\nIn some cases, like when the exact date is less important, the easiest way to describe something that happened very recently is using the ‘ago’ format.\n\nFor future and past events, use approximate time by rounding down to the largest or most recent date or time.\n\nYou should always provide a way for people to see the actual timestamp, usually via a tooltip.\n\n### Past\n\n| Description | Display | Display when limited space |\n| --------------------------- | ---------------------------- | ------------------------------ |\n| Within the last few seconds | just now | now |\n| Within the last minute | a minute ago | 1 m |\n| Within 59 minutes | x minutes ago | X m |\n| 60 minutes ago | 1 hour ago | 1 h |\n| x hours ago | x hours ago | X h |\n| 1 day ago | yesterday | 1 d |\n| 1 day ago (with time) | yesterday at 5:05 pm | n/a |\n| 2 days ago < 7 days | x days ago | Use the truncated date (Aug 8) |\n| 7 days ago | 1 week ago | Use the truncated date (Aug 8) |\n| > 7 days ago | Date stamp: "August 8, 2018" | Use the truncated date (Aug 8) |\n\n### Future\n\n| Description | Display | Display when limited space |\n| ----------------------------- | ---------------------------- | ------------------------------ |\n| Within the next few seconds | shortly | now |\n| In the next minute | In 1 minute | in 1 m |\n| In the next 60 minutes | In x minutes | in X m |\n| In 60 minutes | In 1 hour | in 1 hr |\n| In x hours | In x hours | in X hr |\n| In 1 day (by date, not hours) | tomorrow | Use the truncated date (Aug 8) |\n| In 2 to 7 days | In x days | |\n| In 7 days | In 1 week | |\n| In > 7 days | Date stamp: "August 8, 2018" | |\n| > 7 days ago | Date stamp: "August 8, 2018" | |\n\n## Style and punctuation\n\nStyle and punctuation for dates and time can change depending on locale and is determined by the i18n library API.\n\n### Capitalization\n\n- Months and days in English are proper nouns and start with a capital letter.\n- Specific days or periods in history are all proper nouns, so should be capitalized. For example: New Year’s Day, Renaissance, Cold War.\n- Use capital letters for all institutional holidays, religious days, and public events. For example: Ramadan, Yom Kippur, Good Friday, Martin Luther King Jr. Day.\n\n### Apostrophes\n\n- Avoid using apostrophes in UI copy and in developer and support documentation.\n- In more casual writing, you can use an apostrophe to stand in for the missing numerals in the year, such as \'the \'70s’.\n\n## Resources\n\n- [Int.DateTimeFormat constructor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat#try_it) - a JavaScript library that devs can use and where designers can check formatting of date and time.\n- [Date formats](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-date-formats)\n- [Time formats](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-time-formats)',
|
|
38
|
+
content: '<SectionMessage title="">\n\tDate and time formatting is tied to a person’s locale and account settings. Because of this, what\n\ta customer sees could be different from the guidelines on this page.\n</SectionMessage>\n\n## Date and time for internationalization\n\nEach programming language has an i18n (internationalization) library that automatically localizes\ntime and date strings based on a user’s locale settings/preferences. Time and date strings should\nnever be localized manually by a designer, engineer, or translator.\n\nThe Product Internationalization team is responsible for creating app UI content in non-English\nlanguages by localizing externalized code strings provided by our Product Engineers.\n\nEngineers must:\n\n- Ensure date and time references/strings are not hardcoded \n- Reference the programming i18n library API, which will automatically format time and date strings\n as per a customer’s detected or selected locale.\n\n## Date formats\n\nAtlassian uses US date formatting (for example: January 12, 2028).\n\nWhen you’re handing designs over to engineers, you need to specify which date format length is\nneeded. The i18n library API will use this information to format the date accordingly. Date and time\nformats should not be hardcoded.\n\nThere are 4\n[date format lengths](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-date-formats):\nfull, long, medium, and short.\n\n### Full date\n\nThe full date format is weekday, month, day, year.\n\n<DoDontGrid>\n\t<DoDont type="do">Sunday, August 14, 2028</DoDont>\n</DoDontGrid>\n\n### Long date\n\nA long date format is month, day, year\n\n<DoDontGrid>\n\t<DoDont type="do">November 8, 2008</DoDont>\n</DoDontGrid>\n\n### Medium date\n\nThe medium date format is abbreviated month, day, year. Only use this format when space is limited.\n\n<DoDontGrid>\n\t<DoDont type="do">Sep 26, 1952</DoDont>\n</DoDontGrid>\n\n#### Abbreviating months and days\n\nIf you need to abbreviate months or days, use the first 3 letters of the month or day.\n\n| Month abbreviation | Month in full | | Day abbreviation | Day in full |\n| ------------------ | ------------- | --- | ---------------- | ----------- |\n| Jan | January | | Mon | Monday |\n| Feb | February | | Tue | Tuesday |\n| Mar | March | | Wed | Wednesday |\n| Apr | April | | Thu | Thursday |\n| May | May | | Fri | Friday |\n| Jun | June | | Sat | Saturday |\n| Jul | July | | Sun | Sunday |\n| Aug | August | | | |\n| Sep | September | | | |\n| Oct | October | | | |\n| Nov | November | | | |\n| Dec | December | | | |\n\n### Short date\n\nShort format dates are written in digits.\n\nIn most cases, avoid short format dates as different countries use the date in a different order,\nwhich can cause confusion and effect readability and usability. In the US, 10-8-2026 is October 8,\n2026, but in Australia and the UK, it’s August 10, 2026.\n\nHowever, short format dates might be suitable for situations like data storage, sorting or\nfiltering, or data export/import. If using, use the ISO 8601 international standard for numerical\ndate format, which is YYYY-MM-DD.\n\n## Ordinal numbers\n\nDon’t use ordinal numbers (1st, 2nd, 3rd, and so on) in dates.\n\n## Date ranges\n\nIf you have a date range, use ‘to’ and not hyphens. For example: ‘2020 to 2024’. Hyphens are read\nout by screen readers as ‘hyphen’, which can lead to confusion.\n\nAn exception is financial years, which use a hyphen without spaces on either side. For example:\nFY2008-09\n\nUse ‘and’ if a range is preceded by ‘between’. For example: He was in Paris between 2025 and 2026.\n\n<DoDontGrid>\n\t<DoDont type="do">2014 to 2015</DoDont>\n\t<DoDont type="dont">2014-15</DoDont>\n</DoDontGrid>\n\n## Time formats\n\nShow time in digits for precision and to give a clearer expression of time.\n\nSpecify to engineers which time format length is needed. The i18n library API will then format the\ntime according to a customer’s account settings. Make sure time is not hardcoded.\n\nUse a colon (:) to separate the hours and minutes (though this might change depending on a user’s\nlocale and account settings).\n\nLike dates, there are 4\n[time format lengths](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-time-formats):\nfull, long, medium, and short.\n\n### Full time\n\nThe full time format is hour, minutes, seconds, and time zone spelt out.\n\n<DoDontGrid>\n\t<DoDont type="do">3:30:10 p.m. Pacific Standard Time</DoDont>\n</DoDontGrid>\n\n### Long time\n\nThe long time format is hour, minutes, seconds, and the time zone initials.\n\n<DoDontGrid>\n\t<DoDont type="do">11:18:30 p.m. PST</DoDont>\n</DoDontGrid>\n\n### Medium time\n\nThe medium time format is hour, minutes, and seconds.\n\n<DoDontGrid>\n\t<DoDont type="do">8:50:28 a.m.</DoDont>\n</DoDontGrid>\n\n### Short time\n\nThe short time format is hour and minutes.\n\n<DoDontGrid>\n\t<DoDont type="do">2:40 p.m.</DoDont>\n</DoDontGrid>\n\n### 24-hour time\n\nThe 24-hour format is useful for more serious communications, for example in the case of outages and\nsecurity comms. The use of the 24-hour format is mostly system-driven by the i18n library API.\n\nThis format numbers hours from 00:00 hours (midnight) to 23:59 and uses 4 digits: the first 2 digits\nare the hours and the next 2 digits are the minutes. Use a colon (:) to separate the hours and\nminutes, though this might change depending on someone\'s account settings.\n\n## Writing time\n\n### Duration and timestamps\n\nWhen writing timestamps, labels on graphs, or durations, avoid using zeros before the hour. For\nexample: 5:29. not 05:29. Use a colon between the hours and minutes with no spaces on either side.\n\n### Using a.m. and p.m.\n\nFormat time using ‘a.m.’ and ‘p.m.’ when creating content like blogs, manuals, and instructions.\n\n- Lowercase ‘a.m.’ and ‘p.m.’\n- Use periods between the letters\n- Add a space between the time and the ‘a.m.’ or ‘p.m.’. For example: 6:30 a.m. (not 6:30a.m.)\n\n### Time range\n\n- If you have a time range that’s entirely in the morning or evening, use \'a.m.\' or \'p.m.\' only\n once. For example: 6:30 to 10 p.m.\n- If the time range goes from the morning into the evening (or vice versa), use both. For example:\n 10 a.m. to 2 p.m.\n\n### Noon, midday, and midnight\n\nWhere suitable, use ‘noon’, ‘midday’ or ‘midnight’ instead of ‘12 am’ or ‘12 pm’ as it makes it\neasier for people to differentiate between these times.\n\n### Avoid using ‘fortnightly ‘or ‘bi’ for months and years\n\nAvoid using ‘fortnightly’ and the prefix ‘bi’ to mean either 2 or twice, as these terms can be\nconfusing.\n\nInstead of:\n\n- **Fortnightly**: write ‘every 2 weeks’\n- **Bimonthly**: write ‘twice a month’ or ‘every 2 months’\n- **Biannual**: write ‘twice a year’ or ‘every 2 years’.\n\n<DoDontGrid>\n\t<DoDont type="do">Your sprint will repeat every 2 weeks.</DoDont>\n\t<DoDont type="dont">Your sprint will repeat fortnightly.</DoDont>\n</DoDontGrid>\n\n## Date and time formats\n\nThere are also full, long, medium, and short format lengths when combining date and time.\n\n### Full date and time\n\n<DoDontGrid>\n\t<DoDont type="do">Wednesday, June 12, 2024 at 6:25:59 p.m. Eastern Standard Time</DoDont>\n</DoDontGrid>\n\n### Long date and time\n\n<DoDontGrid>\n\t<DoDont type="do">April 25, 2027 at 9:05:32 p.m. PST</DoDont>\n</DoDontGrid>\n\n### Medium date and time\n\n<DoDontGrid>\n\t<DoDont type="do">Sep 5, 1999, 1:25:59 a.m.</DoDont>\n</DoDontGrid>\n\n### Short date and time\n\n<DoDontGrid>\n\t<DoDont type="do">2028-10-22, 6:25 p.m. </DoDont>\n</DoDontGrid>\n\n## Relative date and time\n\nIn some cases, like when the exact date is less important, the easiest way to describe something\nthat happened very recently is using the ‘ago’ format.\n\nFor future and past events, use approximate time by rounding down to the largest or most recent date\nor time.\n\nYou should always provide a way for people to see the actual timestamp, usually via a tooltip.\n\n### Past\n\n| Description | Display | Display when limited space |\n| --------------------------- | ---------------------------- | ------------------------------ |\n| Within the last few seconds | just now | now |\n| Within the last minute | a minute ago | 1 m |\n| Within 59 minutes | x minutes ago | X m |\n| 60 minutes ago | 1 hour ago | 1 h |\n| x hours ago | x hours ago | X h |\n| 1 day ago | yesterday | 1 d |\n| 1 day ago (with time) | yesterday at 5:05 pm | n/a |\n| 2 days ago < 7 days | x days ago | Use the truncated date (Aug 8) |\n| 7 days ago | 1 week ago | Use the truncated date (Aug 8) |\n| > 7 days ago | Date stamp: "August 8, 2018" | Use the truncated date (Aug 8) |\n\n### Future\n\n| Description | Display | Display when limited space |\n| ----------------------------- | ---------------------------- | ------------------------------ |\n| Within the next few seconds | shortly | now |\n| In the next minute | In 1 minute | in 1 m |\n| In the next 60 minutes | In x minutes | in X m |\n| In 60 minutes | In 1 hour | in 1 hr |\n| In x hours | In x hours | in X hr |\n| In 1 day (by date, not hours) | tomorrow | Use the truncated date (Aug 8) |\n| In 2 to 7 days | In x days | |\n| In 7 days | In 1 week | |\n| In > 7 days | Date stamp: "August 8, 2018" | |\n| > 7 days ago | Date stamp: "August 8, 2018" | |\n\n## Style and punctuation\n\nStyle and punctuation for dates and time can change depending on locale and is determined by the\ni18n library API.\n\n### Capitalization\n\n- Months and days in English are proper nouns and start with a capital letter.\n- Specific days or periods in history are all proper nouns, so should be capitalized. For example:\n New Year’s Day, Renaissance, Cold War.\n- Use capital letters for all institutional holidays, religious days, and public events. For\n example: Ramadan, Yom Kippur, Good Friday, Martin Luther King Jr. Day.\n\n### Apostrophes\n\n- Avoid using apostrophes in UI copy and in developer and support documentation.\n- In more casual writing, you can use an apostrophe to stand in for the missing numerals in the\n year, such as \'the \'70s’.\n\n## Resources\n\n- [Int.DateTimeFormat constructor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat#try_it) -\n a JavaScript library that devs can use and where designers can check formatting of date and time.\n- [Date formats](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-date-formats)\n- [Time formats](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-time-formats)',
|
|
39
39
|
keywords: ['date', 'time', 'formatting', 'localization', 'datetime', 'content']
|
|
40
40
|
}, {
|
|
41
41
|
content: 'People care about how apps talk to them. YouTube, GitHub, and Slack all have a distinct voice, tone,\nand personality.\n\nApps engage us, manage to make us feel at home, capture our attention, and earn our loyalty.\n\nPoor messaging contributes to a poor user experience, which leads to dissatisfaction. On the other\nhand, good copy reflects our apps\' voice (personality) and enables us to build a better relationship\nwith our audience.\n\nIn short, good messaging may not be the reason people stay with our apps, but bad messaging could be\nthe reason they decide to leave.\n\n## Choose a message type\n\nUse different types of messages to guide people through their tasks. Each message type has a\nconsistent visual and writing style to help people know what to expect.\n\nUse these guidelines to choose and write the types of messages:\n\n- [Information message](https://atlassian.design/foundations/content/designing-messages/info-messages)\n — provides additional information to motivate people.\n- [Error message](https://atlassian.design/foundations/content/designing-messages/error-messages) —\n alerts people of a problem that has occurred and informs them what to do next.\n- [Success message](https://atlassian.design/foundations/content/designing-messages/success-messages)\n — celebrates success along with the people using our apps.\n- [Warning message](https://atlassian.design/foundations/content/designing-messages/warning-messages)\n — gives advanced notice of a potential change that may result in loss of data or an error state.\n- [Feature discovery](https://atlassian.design/foundations/content/designing-messages/feature-discovery)\n — lets people know about a new feature.\n\n## Select the right component\n\nUse the table to identify the right component for your content.\n\nFor example:\n\n- If you want to highlight a new feature to a user, consider a spotlight card, benefits modal, or\n empty state.\n- If you want to tell someone they\'ve accomplished a task, consider a flag.\n\n| Component | Information message | Success message | Warning message | Error message | Feature discovery |\n| --------------------------------------------- | ------------------- | --------------- | --------------- | ------------- | ----------------- |\n| **Empty state** | Yes | Yes | | | Yes |\n| **Banner** | Yes | | Yes | Yes | |\n| **Flag** | Yes | Yes | Yes | Yes | |\n| **Section message** | Yes | | Yes | Yes | |\n| **Inline message** | Yes | Yes | Yes | Yes | |\n| **Modal dialog** | Yes | | Yes | | |\n| **Benefits modal** | | | | | Yes |\n| **Onboarding (spotlight) and spotlight card** | | | | | Yes |\n\n### Empty state\n\nUse empty states to show when there is nothing to display in a view, for example, when a board has\nno tasks, someone clears their inbox, or a search returns no results.\n\nRead guidance on writing effective\n[empty state messages](https://atlassian.design/foundations/content/designing-messages/empty-state).\n\n<img\n\tsrc={messagesEmptyState}\n\talt="Empty state encouraging an admin to add people to a Jira project space."\n/>\n\nAn empty state can appear as a full-screen message or within panels, tables, and other containers.\n\n[Usage guidance for empty state component](https://atlassian.design/components/empty-state/usage).\n\n### Banner\n\nUse banners only for critical system-level messaging for example, warnings about loss of data or\nfunctionality.\n\n<img src={messagesBanner} alt="Banner message example with a red error message." />\n\nBanners appear at the top of the screen and shift the content below them.\n\n[Usage guidance for banner component](https://atlassian.design/components/banner/usage).\n\n### Flag\n\nUse flags for confirmations, alerts, and acknowledgments that require minimal user interaction.\n\n<img\n\tsrc={messagesFlag}\n\talt="Example of a flag message with a green tick icon, the heading \'You are now connected\', and the text describing a group the user is added to."\n/>\n\nFlags are event-driven messages that appear by overlaying content at the bottom left of the screen,\nemerging from the navigation sidebar.\n\n[Usage guidance for flag component](https://atlassian.design/components/flag/usage).\n\n### Section message\n\nUse section messages to alert the user of something that has happened in a specific section of the\nscreen.\n\n<img\n\tsrc={messagesSectionMessages}\n\talt="Example of a section message showing green tick icon, the heading Merged pull request, details of the pull request, and links to the hash and user name, and the time it happened."\n/>\n\nSection messages appear above the affected area (for example, work items in Jira).\n\n[Usage guidance for section message component](https://atlassian.design/components/section-message/usage).\n\n### Inline message\n\nUse inline messages to alert people to a required action or important information.\n\n<img\n\tsrc={messagesInlineDialog}\n\talt="Example of a cursor on a yellow caution icon triggering an inline dialog message."\n/>\n\nInline messages consist of an icon, message, and sometimes secondary text. People can interact with\nthe icon, title, or secondary text to reveal the full inline message.\n\n[Usage guidance for inline message component](https://atlassian.design/components/inline-message/usage).\n\n### Modal dialog\n\nUse modal dialogs to present a short-term task the user needs to perform.\n\n<img\n\tsrc={messagesModal}\n\talt="A modal that presents a task and a dropdown menu, with a clear action."\n/>\n\nModal dialogs display content in a layer above the page.\n\n[Usage guidance for modal dialog component](https://atlassian.design/components/modal-dialog/usage).\n\n### Benefits modal\n\nBenefits modals explain the value of a significant new feature or experience change.\n\nRead guidance on writing effective\n[feature discovery messages](https://atlassian.design/foundations/content/designing-messages/feature-discovery).\n\n<img\n\tsrc={messagesBenefitsModal}\n\talt="A modal for a Jira update that includes the key elements of a benefits modal."\n/>\n\nA benefits modal focuses a person\'s attention on a large or impactful update.\n\n[Usage guidance for benefits modal component](https://atlassian.design/components/onboarding/benefits-modal/usage).\n\n### Onboarding (spotlight) and spotlight card\n\nAn onboarding spotlight introduces new features to users through focused messages or multi-step\ntours. A spotlight card is for onboarding messages that need a more flexible layout, or don\'t\nrequire a dialog.\n\nRead guidance on writing effective\n[feature discovery messages](https://atlassian.design/foundations/content/designing-messages/feature-discovery).\n\n<img\n\tsrc={messagesOnboarding}\n\talt="An example of a spotlight pulse expanded into a spotlight component that encourages people to try the new feature."\n/>\n\n[Usage guidance for onboarding (spotlight) component](https://atlassian.design/components/onboarding/usage)\nand [spotlight card component](https://atlassian.design/components/onboarding/spotlight-card/usage).\n\n## Set the appearance (color and icon)\n\nMessages use colors and icons to help indicate content and urgency.\n\nMake sure you use the right\n[color role for your situation](https://atlassian.design/foundations/color#color-roles). For\nexample, yellow typically implies a warning, while green can imply success.\n\n<img\n\tsrc={colorRolesAndIcons}\n\talt="Icons showing different icons and colors we use in messages. Informative messages use a blue circle icon with an i inside, success is a green check icon, warning is a yelowish triangle icon with an exclamation mark, danger is a red diamond icon with an exclamation mark, and discovery or new is a purple circle with a question mark inside."\n/>\n\nReview [guidelines on using icons](https://atlassian.design/foundations/iconography) and\n[usage guidance for the icon component](https://atlassian.design/components/icon/usage).',
|
|
@@ -59,7 +59,7 @@ var guidelinesStructuredContent = exports.guidelinesStructuredContent = [{
|
|
|
59
59
|
content: "A warning message, different from error messages, appears **before** someone takes an action to\nindicate a significant change or potential loss of data. It draws their attention to a potential\nproblem that may or may not require an action on the user’s part.\n\nWhen crafting warning messages, remember that most people scan text instead of reading everything.\nMake every word count and avoid irrelevant details.\n\n## Writing best practices\n\n### Titles\n\n- Titles are optional depending on the component you choose.\n- Include an informative, scannable title. People should understand what’s happening by reading the\n title on its own.\n- Avoid explaining what to do.\n- Limit titles to three to four words where possible, excluding “an”, “a”, or “the”. The character\n count will depend on the component you choose.\n- Write in sentence case with appropriate punctuation.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: warningMessagesTitlesDo, alt: '' }}>\n\t\tYour bill may increase\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: warningMessagesTitlesDont, alt: '' }}>\n\t\tTime to pay up!\n\t</DoDont>\n</DoDontGrid>\n\nBy giving people this warning before they add extra members to their team you’re giving them a\nchance to reconsider their options after having all the information. Avoid using a wink in instances\nwhere there could be a problem for people.\n\n### Body copy\n\n- Include: the reason for the warning and the potential problem, how someone should act, and what\n happens if they don’t act.\n- If you don’t know the reason for a warning, don’t make one up – just say that something’s gone\n wrong and offer a solution for what they can do.\n- Avoid repeating content from the title.\n- Keep messages to 1 to 2 sentences.\n- Avoid people having to look in another location for more information. If this can't be avoided,\n use a link to support content.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: warningMessagesBodyDo, alt: '' }}>\n\t\tWe’re running into some difficulties\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: warningMessagesBodyDont, alt: '' }}>\n\t\tYou’ve lost connection\n\t</DoDont>\n</DoDontGrid>\n\nUse “we’re” instead of “you’re” to avoid blaming people for issues in the app.\n\n### Call to action (CTA)\n\n- When a warning message invokes a choice, use imperative verbs such as “Save”, “Remove”, or\n “Create”, in the CTA to describe what action people will be making instead of vague terms such as\n “Done”.\n- An option to dismiss or cancel lets people feel reassured that they can opt-out.\n- Limit your CTA to 1 or 2 words.\n\n## Voice and tone\n\nYou want to leave people feeling informed, supported and reassured. Convey the correct level of\nurgency and make sure they understand how to respond. Follow the\n[Atlassian voice and tone principles](https://atlassian.design/foundations/content/voice-tone) to\nbuild your message:\n\n### Inform to build trust\n\nInform, but don't alarm. If the warning comes before an action, clearly communicate what will happen\nif the action is taken.\n\n### Encourage them along the path\n\nGive clear, concise advice on which path to take and describe and provide alternatives if possible.\n\n### Satisfy by meeting expectations\n\nUse language that sounds and feels human, is natural and accessible. Explains the situation clearly\nand without assuming they have any advanced knowledge.\n\n## Patterns and UX strategies\n\nConsider the context in which the message appears. The type of warning message required will change\ndepending on the risk, consequences, and immediacy of the problem.\n\n### Raise awareness\n\nWarning messages make people aware of a condition or potential problem, even if they don't have to\ntake immediate action.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: warningMessagesAwarenessDo, alt: '' }}>\n\t\tPayment details needed\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: warningMessagesAwarenessDont, alt: '' }}>\n\t\tWe’re going to close your account\n\t</DoDont>\n</DoDontGrid>\n\nThis message describes the condition or problem, the implications and their importance, and offers a\nbutton to dismiss the message.\n\n### Highlight an imminent problem\n\nThis is when someone needs to act immediately to prevent an issue.\n\nHere the message describes what people need to do, explains the condition and why it’s important,\nand offers a button for each of the options.\n\nIt's important to give people a timeline in which to make a certain change. You don’t want to create\npanic and rush people into making changes.\n\n### Confirm a risky action\n\nThis message should ask people whether they want to proceed, explain any reasons why they may not\nwish to proceed, and offer commit buttons for proceeding or canceling an action. You should also\ninform them whether any actions they take can be easily undone.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: warningMessagesConfirmDo, alt: '' }}>\n\t\tConfirm a risky action\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: warningMessagesConfirmDont, alt: '' }}>\n\t\tRisky action\n\t</DoDont>\n</DoDontGrid>\n\n## Related components\n\nUse warning messages in the following components:\n\n- [Banner](https://atlassian.design/components/banner/examples)\n- [Flag](https://atlassian.design/components/flag/examples)\n- [Inline message](https://atlassian.design/components/inline-message/examples)\n- [Modal dialog](https://atlassian.design/components/modal-dialog/examples)\n- [Section message](https://atlassian.design/components/section-message/)\n\n## Accessibility\n\n- Use alternative text for illustrations and symbols in your messages\n- Avoid jargon and use simple language\n- Make links as descriptive as possible\n- Make text easily scannable to highlight key information.",
|
|
60
60
|
keywords: ['warning messages', 'warnings', 'content', 'designing messages']
|
|
61
61
|
}, {
|
|
62
|
-
content: '<SectionMessage title="">\n\tThese guidelines are for UI and app content. For broader guidance on inclusive language, view Brand’s{\' \'}\n\t<Link href="https://go.atlassian.com/inclusive-language-guide">\n\t\tInclusive Language Guidelines (Atlassians only)\n\t</Link>\n</SectionMessage>\n\n## Design principles for inclusive language\n\nInclusive language isn’t about following a list of good and bad words. It’s about taking an approach that avoids assumptions and stereotypes, and treats people with respect.\n\n### Make content easy to understand\n\nUse plain language. Simple wording is more inclusive and helps people complete their tasks faster and with higher success rates.\n\nDon’t use [metaphors, idioms](#avoid-metaphors-and-idioms), or jargon.\n\n### Use person-first language when you can’t ask\n\nWhen you can’t ask someone their preference, use person-first language. It centers around the person, rather than their difference. For example: ‘people with disabilities’ rather than ‘disabled people’.\n\nHowever, some people prefer to use identity-first language to represent themselves, such as many people in the Deaf community, so it’s best to ask whenever possible.\n\n### Don’t make assumptions about abilities\n\nDon’t use phrasing that makes assumptions about how people experience your app.\n\nFor example, by making claims about how easy an experience is, it’s less precise and can exclude people based on their abilities.\n\n<DoDontGrid>\n\t<DoDont type="do">Set up your new project in a few steps.</DoDont>\n\t<DoDont type="dont"> It’s easy to set up a new project.</DoDont>\n</DoDontGrid>\n\n### Avoid metaphors and idioms\n\nMetaphors and idioms are non-literal phrases used in regular speech.\n- Metaphors are when people compare something to something else (such as ‘they were like a fish out of water’)\n- Idioms are phrases where the meaning isn’t conveyed by any of the words (such as ‘between a rock and a hard place’).\n\nThey can be confusing for our global audience, hard to accurately translate, and create an unnecessary barrier to comprehension. All this can be avoided by being accurate and literal.\n\n<DoDontGrid>\n\t<DoDont type="do">Automation helps teams create work items faster.</DoDont>\n\t<DoDont type="dont"> Automation makes creating work items a piece of cake.</DoDont>\n\t<DoDont type="do">Confluence has many useful features.</DoDont>\n\t<DoDont type="dont"> Confluence has more features than you can poke a stick at.</DoDont>\n</DoDontGrid>\n\n## How to describe people\n\n### Be clear\n\nWhen you need to describe a group of people, use clear language that aligns with how people describe themselves, such as whether they use [person-first or identity-first language](#use-person-first-language-when-you-can’t-ask).\n\nYou can also reduce inaccurate assumptions or stereotypes by improving the way you describe people’s differences. For example:\n\n| Good | Better | Reason |\n| ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Alternative text helps people with visual disabilities interact with images. | Alternative text helps people who use assistive technology interact with images. | Not all people who use assistive technologies like screen readers have visual disabilities. Using the ‘better’ definition is more inclusive and more accurate. |\n| This project was done in consultation with people of Indigenous backgrounds. | This project was done in consultation with First Nations Australians. | Use specific terms when referring to racial and ethnic groups. Vague terms don\'t acknowledge the different experiences of racial and ethnic communities. |\n\n### Don’t change words used to describe people\n\nAvoiding describing people’s differences can reinforce the prejudices of society.\n\nDescribing race, ethnicity, disability, age, class, gender, and sexuality isn’t a negative thing, unless these descriptions are being used in discriminatory ways. For example, it can be ok to use the phrase ‘people of color’ if you don’t have enough information to be more specific.\n\nDon’t modify phrases to make differences sound positive. Words like ‘differently abled’ or ‘handi-capable’ are patronizing and don’t fit with the diversity of human experiences.\n\n## Words related to disabilities can still be inclusive\n\nDesigners avoid some words related to disabilities because they’re trying to be inclusive. Some words like ‘watch’ and ‘see’ aren\'t microaggressions because words that relate to disabilities aren’t negative words.\n\nYou should avoid using them in a negative context, but you can use them if they help make things clear.\n\n| Words | Reason |\n| ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| View, watch, see | People who are blind or have low vision aren’t excluded by these words. They still ‘view’ a list of items, only in a different way. Where it makes sense, avoid these words. But you don’t need to remove them if they’re accurate. |\n| Enabled, disabled | ‘Disabled’ isn\'t an offensive word. It reflects when people are limited by their environment and society. Avoid associating the word disabled with negative states. Wherever you can, alternatives to ‘disabled’ like ‘turned off’ or ‘unavailable’ are better. |\n\n## Techniques for inclusive experiences\n\n### Use they/them pronouns and gender-neutral language\n\n- When referring to a person, use the pronouns they tell you to use.\n- If you don’t know the person or group of people, use they/them pronouns. This makes our apps more gender inclusive and easier to read.\n\n<DoDontGrid>\n\t<DoDont type="do">Ask your project admin to enable editing permissions on their account.</DoDont>\n\t<DoDont type="dont"> Ask your project admin to enable editing permissions on his or her account.</DoDont>\n</DoDontGrid>\n\n\n### Make alt text concise and consistent\n\n- If images provide information, always include alternative text (‘alt text’) so people using assistive technologies can access it.\n- When you’re writing alternative text, consider how it will change the experience for a person using a screen reader. Is it accurate? Is it too wordy? Is it informative enough?\n- If you’re using the same visuals in multiple places, use the same alt text every time it appears. And if elements are repetitive, like iconography, be concise so the experience isn’t annoying for people using assistive technology.\n\n\n### Write accurate content, links, and labels\nUse accurate, descriptive language for content and links, as it reduces cognitive load and improves the experience for people who don’t use assistive technology.\n\nDon’t deliberately keep visual labels short and hide the descriptive information behind an aria-label.\n\n| Example | Alternative | Reason |\n| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Ask Rovo about a topic within your company’s knowledge base. [Learn more](https://www.atlassian.com/software/rovo). | Ask Rovo about a topic within your company’s knowledge base. [About Rovo](https://www.atlassian.com/software/rovo). | Accurate, descriptive links reduce people’s cognitive load.\n| Atlassian Intelligence is great for speeding up your work and improving productivity. | Use Atlassian Intelligence to find answers, get summaries, and generate content. | Don’t use vague promotional language. Describing new features with accuracy builds trust and helps people make informed decisions. |\n| Step 1 | Create project (step 1 of 3) | Describe tasks accurately so people know where they are in their workflow. |\n<br></br>\n\n<SectionMessage title="">\n\tFor examples of descriptive links, read {\' \'}\n\t<Link href="https://go.atlassian.com/learn-more-alt">\n\t\tAlternatives to \'learn more\' (Atlassians only)\n\t</Link>\n</SectionMessage>\n\n### Gather form information thoughtfully\n\n- When gathering data about people, avoid pre-defined categories. They often don’t reflect the diversity of our world and can prevent people from using software if there isn’t an option for them.\n- Don’t ask for more information than necessary. Detailed personal information often isn’t relevant to our apps, so ask how or if you really need people to identify or group themselves before building this into a form.\n- If you need to collect information about people’s identities, give them the option to not answer or to give a self-defined answer.\n- Avoid setting any particular group of people as the default option. This implies that other groups are not the norm or not common, or forces some people to navigate and configure fields more than others.\n- When gathering information about names, use a ‘Full name’ field instead of separating names by first name, last name, and salutation.\n\n## Additional resources\n\nLanguage is changing all the time, so we don’t maintain a list of terms to use or avoid. Instead, use resources like:\n- [APA Inclusive Language Guide](https://www.apa.org/about/apa/equity-diversity-inclusion/language-guidelines)\n- [Australian Government Style Manual](https://www.stylemanual.gov.au/accessible-and-inclusive-content/inclusive-language)',
|
|
62
|
+
content: '<SectionMessage title="">\n\tThese guidelines are for UI and app content. For broader guidance on inclusive language, view\n\tBrand’s{\' \'}\n\t<Link href="https://go.atlassian.com/inclusive-language-guide">\n\t\tInclusive Language Guidelines (Atlassians only)\n\t</Link>\n</SectionMessage>\n\n## Design principles for inclusive language\n\nInclusive language isn’t about following a list of good and bad words. It’s about taking an approach\nthat avoids assumptions and stereotypes, and treats people with respect.\n\n### Make content easy to understand\n\nUse plain language. Simple wording is more inclusive and helps people complete their tasks faster\nand with higher success rates.\n\nDon’t use [metaphors, idioms](#avoid-metaphors-and-idioms), or jargon.\n\n### Use person-first language when you can’t ask\n\nWhen you can’t ask someone their preference, use person-first language. It centers around the\nperson, rather than their difference. For example: ‘people with disabilities’ rather than ‘disabled\npeople’.\n\nHowever, some people prefer to use identity-first language to represent themselves, such as many\npeople in the Deaf community, so it’s best to ask whenever possible.\n\n### Don’t make assumptions about abilities\n\nDon’t use phrasing that makes assumptions about how people experience your app.\n\nFor example, by making claims about how easy an experience is, it’s less precise and can exclude\npeople based on their abilities.\n\n<DoDontGrid>\n\t<DoDont type="do">Set up your new project in a few steps.</DoDont>\n\t<DoDont type="dont"> It’s easy to set up a new project.</DoDont>\n</DoDontGrid>\n\n### Avoid metaphors and idioms\n\nMetaphors and idioms are non-literal phrases used in regular speech.\n\n- Metaphors are when people compare something to something else (such as ‘they were like a fish out\n of water’)\n- Idioms are phrases where the meaning isn’t conveyed by any of the words (such as ‘between a rock\n and a hard place’).\n\nThey can be confusing for our global audience, hard to accurately translate, and create an\nunnecessary barrier to comprehension. All this can be avoided by being accurate and literal.\n\n<DoDontGrid>\n\t<DoDont type="do">Automation helps teams create work items faster.</DoDont>\n\t<DoDont type="dont"> Automation makes creating work items a piece of cake.</DoDont>\n\t<DoDont type="do">Confluence has many useful features.</DoDont>\n\t<DoDont type="dont"> Confluence has more features than you can poke a stick at.</DoDont>\n</DoDontGrid>\n\n## How to describe people\n\n### Be clear\n\nWhen you need to describe a group of people, use clear language that aligns with how people describe\nthemselves, such as whether they use\n[person-first or identity-first language](#use-person-first-language-when-you-can’t-ask).\n\nYou can also reduce inaccurate assumptions or stereotypes by improving the way you describe people’s\ndifferences. For example:\n\n| Good | Better | Reason |\n| ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Alternative text helps people with visual disabilities interact with images. | Alternative text helps people who use assistive technology interact with images. | Not all people who use assistive technologies like screen readers have visual disabilities. Using the ‘better’ definition is more inclusive and more accurate. |\n| This project was done in consultation with people of Indigenous backgrounds. | This project was done in consultation with First Nations Australians. | Use specific terms when referring to racial and ethnic groups. Vague terms don\'t acknowledge the different experiences of racial and ethnic communities. |\n\n### Don’t change words used to describe people\n\nAvoiding describing people’s differences can reinforce the prejudices of society.\n\nDescribing race, ethnicity, disability, age, class, gender, and sexuality isn’t a negative thing,\nunless these descriptions are being used in discriminatory ways. For example, it can be ok to use\nthe phrase ‘people of color’ if you don’t have enough information to be more specific.\n\nDon’t modify phrases to make differences sound positive. Words like ‘differently abled’ or\n‘handi-capable’ are patronizing and don’t fit with the diversity of human experiences.\n\n## Words related to disabilities can still be inclusive\n\nDesigners avoid some words related to disabilities because they’re trying to be inclusive. Some\nwords like ‘watch’ and ‘see’ aren\'t microaggressions because words that relate to disabilities\naren’t negative words.\n\nYou should avoid using them in a negative context, but you can use them if they help make things\nclear.\n\n| Words | Reason |\n| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| View, watch, see | People who are blind or have low vision aren’t excluded by these words. They still ‘view’ a list of items, only in a different way. Where it makes sense, avoid these words. But you don’t need to remove them if they’re accurate. |\n| Enabled, disabled | ‘Disabled’ isn\'t an offensive word. It reflects when people are limited by their environment and society. Avoid associating the word disabled with negative states. Wherever you can, alternatives to ‘disabled’ like ‘turned off’ or ‘unavailable’ are better. |\n\n## Techniques for inclusive experiences\n\n### Use they/them pronouns and gender-neutral language\n\n- When referring to a person, use the pronouns they tell you to use.\n- If you don’t know the person or group of people, use they/them pronouns. This makes our apps more\n gender inclusive and easier to read.\n\n<DoDontGrid>\n\t<DoDont type="do">Ask your project admin to enable editing permissions on their account.</DoDont>\n\t<DoDont type="dont">\n\t\t{\' \'}\n\t\tAsk your project admin to enable editing permissions on his or her account.\n\t</DoDont>\n</DoDontGrid>\n\n### Make alt text concise and consistent\n\n- If images provide information, always include alternative text (‘alt text’) so people using\n assistive technologies can access it.\n- When you’re writing alternative text, consider how it will change the experience for a person\n using a screen reader. Is it accurate? Is it too wordy? Is it informative enough?\n- If you’re using the same visuals in multiple places, use the same alt text every time it appears.\n And if elements are repetitive, like iconography, be concise so the experience isn’t annoying for\n people using assistive technology.\n\n### Write accurate content, links, and labels\n\nUse accurate, descriptive language for content and links, as it reduces cognitive load and improves\nthe experience for people who don’t use assistive technology.\n\nDon’t deliberately keep visual labels short and hide the descriptive information behind an\naria-label.\n\n| Example | Alternative | Reason |\n| ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |\n| Ask Rovo about a topic within your company’s knowledge base. [Learn more](https://www.atlassian.com/software/rovo). | Ask Rovo about a topic within your company’s knowledge base. [About Rovo](https://www.atlassian.com/software/rovo). | Accurate, descriptive links reduce people’s cognitive load. |\n| Atlassian Intelligence is great for speeding up your work and improving productivity. | Use Atlassian Intelligence to find answers, get summaries, and generate content. | Don’t use vague promotional language. Describing new features with accuracy builds trust and helps people make informed decisions. |\n| Step 1 | Create project (step 1 of 3) | Describe tasks accurately so people know where they are in their workflow. |\n\n<br></br>\n\n<SectionMessage title="">\n\tFor examples of descriptive links, read{\' \'}\n\t<Link href="https://go.atlassian.com/learn-more-alt">\n\t\tAlternatives to \'learn more\' (Atlassians only)\n\t</Link>\n</SectionMessage>\n\n### Gather form information thoughtfully\n\n- When gathering data about people, avoid pre-defined categories. They often don’t reflect the\n diversity of our world and can prevent people from using software if there isn’t an option for\n them.\n- Don’t ask for more information than necessary. Detailed personal information often isn’t relevant\n to our apps, so ask how or if you really need people to identify or group themselves before\n building this into a form.\n- If you need to collect information about people’s identities, give them the option to not answer\n or to give a self-defined answer.\n- Avoid setting any particular group of people as the default option. This implies that other groups\n are not the norm or not common, or forces some people to navigate and configure fields more than\n others.\n- When gathering information about names, use a ‘Full name’ field instead of separating names by\n first name, last name, and salutation.\n\n## Additional resources\n\nLanguage is changing all the time, so we don’t maintain a list of terms to use or avoid. Instead,\nuse resources like:\n\n- [APA Inclusive Language Guide](https://www.apa.org/about/apa/equity-diversity-inclusion/language-guidelines)\n- [Australian Government Style Manual](https://www.stylemanual.gov.au/accessible-and-inclusive-content/inclusive-language)',
|
|
63
63
|
keywords: ['inclusive writing', 'inclusion', 'accessibility', 'content', 'language']
|
|
64
64
|
}, {
|
|
65
65
|
content: '<SectionMessage title="Atlassian vocabulary">\n\tFor specific vocabulary and to view our internal word list and glossary, head to{\' \'}\n\t<Link href="https://go.atlassian.com/vocab">go/vocab (Atlassians only)</Link>.\n</SectionMessage>\n\n## Style and formatting\n\n### Abbreviations\n\n- Use the full name of features and apps in customer-facing copy.\n- Don’t use \'e.g.\', ‘i.e.’, ‘etc.’, or \'&\' as they\'re not localization friendly and can be confusing\n for users of assistive technologies.\n\n<DoDontGrid>\n\t<DoDont type="do">Ask the experts at Jira Service Desk.</DoDont>\n\t<DoDont type="dont"> Ask the experts at JSD.</DoDont>\n\t<DoDont type="do">Use an input component. For example, a button or a select.</DoDont>\n\t<DoDont type="dont"> Use an input component, e.g. a button or a select etc.</DoDont>\n</DoDontGrid>\n\n#### Plural abbreviations\n\nDon’t use an apostrophe for plural abbreviations.\n\n<DoDontGrid>\n\t<DoDont type="do">1990s, DVDs</DoDont>\n\t<DoDont type="dont"> 1990’s, DVD’s</DoDont>\n</DoDontGrid>\n\n### Articles (a, an, the)\n\nAvoid articles in buttons, labels, and action-based headings in the UI.\n\n<DoDontGrid>\n\t<DoDont type="do">Create password</DoDont>\n\t<DoDont type="dont"> Create a password</DoDont>\n</DoDontGrid>\n\n### Bold\n\nUse bold text to draw the reader’s eye to key phrases and statements in your content, though don\'t\nover do it.\n\n- For in-app copy or help articles, use bold when referring to static UI elements like menu items,\n buttons, or headings.\n- If bold is needed but the UI doesn’t support it — for example in a UI message or a flag where the\n title is already bold — you can use [italics](#italics).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tGo to <b>General configuration</b> then <b>User macros</b>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tGo to the <b>settings page and select Configuration</b>.\n\t</DoDont>\n</DoDontGrid>\n\n### Capitalization\n\n- Use sentence case in all titles, headings, menu items, labels, and buttons.\n- Capitalize proper nouns in headings, such as names of people, companies, or apps.\n\n<DoDontGrid>\n\t<DoDont type="do">Create work item</DoDont>\n\t<DoDont type="dont">Create Work Item</DoDont>\n\t<DoDont type="do">Add permissions for Arni Karan</DoDont>\n\t<DoDont type="dont">Add permissions for arni karan</DoDont>\n</DoDontGrid>\n\n### Contractions (shortened words)\n\n- Use contractions, where possible, as they convey a conversational, friendly tone.\n- Use curly apostrophes in UI copy\n - On a Mac: **option** + **shift** + **]**\n - On Windows: **Control** + **\'** (or **alt** + **0146**)\n\n<DoDontGrid>\n\t<DoDont type="do">We can’t load this page.</DoDont>\n\t<DoDont type="dont">We cannot load this page.</DoDont>\n</DoDontGrid>\n\n### Date and time\n\nView [date and time guidelines](https://atlassian.design/foundations/content/date-time).\n\n### Gender (he, she, they)\n\n- If known, use the pronouns a customer provides. If you don’t know, avoid gendered pronouns\n wherever possible.\n- If it’s not possible, use ’they’ or ’their’ rather than ‘his/her’ or ’he/she’.\n\n<DoDontGrid>\n\t<DoDont type="do">Ask your admin to add you.</DoDont>\n\t<DoDont type="dont">Ask your admin if she can add you.</DoDont>\n\t<DoDont type="do">Add permissions to their account.</DoDont>\n\t<DoDont type="dont">Add permissions to her account.</DoDont>\n</DoDontGrid>\n\n### Headings and titles\n\n- Use sentence case. Only capitalize the first word of a sentence, proper nouns, and trademarked\n names (for example: apps, countries, people\'s names).\n- Don’t use bold or italics.\n- Don\'t use periods.\n- Reconsider using question marks. Preferably rephrase the heading so it’s a statement.\n- Phrase UI and documentation headings with an action verb.\n- Avoid gerunds (the ‘ing’ form of verbs) in UI copy.\n\n<DoDontGrid>\n\t<DoDont type="do">Organize your to-do list with Trello</DoDont>\n\t<DoDont type="dont">\n\t\tWant to Organize <em>Your</em> To-Do List With Trello?\n\t</DoDont>\n\t<DoDont type="do">Add a page to your project</DoDont>\n\t<DoDont type="dont">Adding a page to your project</DoDont>\n</DoDontGrid>\n\n#### Articles in headings\n\n- Articles (a, an, the) aren’t always needed in UI headings.\n- They\'re better suited to more conversational sections, like product marketing copy and empty\n states, as they make these sections more approachable and improve understanding.\n\n<DoDontGrid>\n\t<DoDont type="do">Create work item</DoDont>\n\t<DoDont type="dont">Create a work item</DoDont>\n</DoDontGrid>\n\n### Italics\n\nIn apps, use italics sparingly as it can be difficult to read. Don’t use italics in hyperlinks.\n\nItalics can be used for:\n\n- UI elements that might change, like a field name or user input.\n- For emphasis if the UI doesn’t support bold. For example, in a flag or UI message.\n\n### Lists\n\nUse lists to draw the reader’s eye and make items easier to scan and follow. Try to limit lists to 6\nitems or less. If there are more items, make multiple lists.\n\n#### Bulleted list\n\n- Use to list options or when the order of the items doesn’t matter.\n- Phrase each item in a parallel way.\n- Don’t use commas or periods at the end of each item.\n\n##### Fragmented sentences\n\nIf your list has fragmented sentences, use a lowercase letter for each item and don’t use a period\nat the end of the list. Use a lead-in sentence with a colon before the items.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tDue to security concerns, all employees are required to:\n\t\t<ul>\n\t\t\t<li>wear an identification tag</li>\n\t\t\t<li>use their security pass to enter or leave an office before 7 a.m. and after 6 p.m.</li>\n\t\t\t<li>alert security if a suspicious package is found</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tDue to security concerns, all employees are required to;\n\t\t<ul>\n\t\t\t<li>Wear an identification tag in the building,</li>\n\t\t\t<li>\n\t\t\t\tYou must use your identification tag to enter an office before 7 a.m. and exit after 6 p.m.,\n\t\t\t\tand\n\t\t\t</li>\n\t\t\t<li>If a suspicious package is found, alert security.</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n##### Complete sentences\n\nFor lists with complete sentences, start an item with a capital letter and end it with a period.\nDon’t use a lead-in sentence with a colon.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tAtlassian has updated security requirements for employees.\n\t\t<p></p>\n\t\t<ul>\n\t\t\t<li>Always wear your identification tag when working in an office.</li>\n\t\t\t<li>\n\t\t\t\tUse your identification tag to enter an office before 7 am and when you leave after 6 pm.\n\t\t\t</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tAtlassian has updated security requirements for employees:\n\t\t<ul>\n\t\t\t<li>always wear your identification tag when working in an office</li>\n\t\t\t<li>\n\t\t\t\tuse your identification tag to enter an office before 7 am and when you leave after 6 pm.\n\t\t\t</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n#### Numbered lists\n\nUse numbered lists for tasks or lists where the order of the items matters. Capitalize the first\nword of each item and end the item with a period.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tTo add a new user macro:\n\t\t<ol>\n\t\t\t<li>\n\t\t\t\tGo to <b>Settings</b> then <b>General configuration</b> then <b>User macros</b>.\n\t\t\t</li>\n\t\t\t<li>\n\t\t\t\tChoose <b>Create a user macro</b>.\n\t\t\t</li>\n\t\t\t<li>Enter the macro details.</li>\n\t\t</ol>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tTo add a new user macro -\n\t\t<ol>\n\t\t\t<li>\n\t\t\t\tgo to <b>Settings</b> then <b>General configuration</b> then <b>User macros</b>\n\t\t\t</li>\n\t\t\t<li>\n\t\t\t\tchoose <b>Create a user macro</b>\n\t\t\t</li>\n\t\t\t<li>enter the macro details.</li>\n\t\t</ol>\n\t</DoDont>\n</DoDontGrid>\n\n### Monospaced text\n\nUse `monospaced font` for names of a file or directory. It’s mostly used in attributes, strings, and\nadministrator and developer docs.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tThe location of the Home directory is stored in a configuration file called\n\t\t<code>confluence-init.properties</code>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tThe location of the Home directory is stored in a configuration file called{\' \'}\n\t\t<b>confluence-init.properties</b>.\n\t</DoDont>\n</DoDontGrid>\n\n### Numbers\n\nUse digits rather than words in most cases.\n\n**Exceptions**:\n\n- If a number starts a sentence, write it out.\n- In common expressions, write the number out. For example: _It’s one thing after another_.\n- When writing long-form or formal content, write out numbers one to nine.\n- Write out the numbers ‘zero’ and ‘one’ if it could be confused for the letters L, I, or O.\n\n<DoDontGrid>\n\t<DoDont type="do">Your password should be a minimum of 8 characters. </DoDont>\n\t<DoDont type="dont">Your password should be a minimum of eight characters.</DoDont>\n\t<DoDont type="do">Loom is one of the best apps for sharing information in a personal way.</DoDont>\n\t<DoDont type="dont">Loom is 1 of the best apps for sharing information in a personal way.</DoDont>\n</DoDontGrid>\n\n#### Number ranges\n\nUse ’to’ and not hyphens in number ranges, except if space is limited, like in a table or mobile\napp.\n\n<DoDontGrid>\n\t<DoDont type="do">View rows 1 to 4 in the table.</DoDont>\n\t<DoDont type="dont">View rows 1-4 in the table.</DoDont>\n</DoDontGrid>\n\n#### Numbers \'out of\'\n\nUse ‘of’ rather than a forward slash ( / ) to show a number out of another number.\n\n<DoDontGrid>\n\t<DoDont type="do">Step 1 of 2</DoDont>\n\t<DoDont type="dont">Step 1/2</DoDont>\n</DoDontGrid>\n\n#### Numbers from 1,000\n\nUse a comma to indicate the thousand in a number.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>4,500</li>\n\t\t\t<li>10,000</li>\n\t\t\t<li>1,250,000</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>4500</li>\n\t\t\t<li>10000</li>\n\t\t\t<li>1250000</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Spelling words\n\nUse US English in UI copy and code. Check spellings in\n[Merriam-Webster online dictionary](https://www.merriam-webster.com/).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>color</li>\n\t\t\t<li>organization</li>\n\t\t\t<li>labeled</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>colour</li>\n\t\t\t<li>organisation</li>\n\t\t\t<li>labelled</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Truncation\n\nEllipses (…) are used to show that text has been cut off — or truncated — when a message doesn’t fit\nin a given space.\n\n- Avoid truncation whenever possible: shorten UI messages or wrap the text.\n- Test your designs using multiple screen widths and magnification levels to ensure it doesn’t\n truncate.\n- If truncation can’t be avoided, for example in user-generated content or icon buttons, use a\n [tooltip](https://atlassian.design/components/tooltip/examples) to display the full text for\n accessibility and usability.\n- In ADS components that truncate, the ellipsis appears without any space next to the last visible\n character (for example: Work in pro…).\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: truncationDo, alt: \'\' }}>\n\t\tShorten or wrap messages.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: truncationDont, alt: \'\' }}>\n\t\tDon’t truncate unless it can’t be avoided.\n\t</DoDont>\n</DoDontGrid>\n\n### UI elements\n\n- Use sentence case, even if the UI element doesn’t use it.\n- Use bold to emphasize the UI element in a step.\n- If the UI element has an icon, bold both the name and the icon.\n- Avoid using a > symbol where possible, as it is read out as “greater than” by assistive\n technologies, leading to confusion. Use ‘then’ instead.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tGo to <b>More</b>, then <b>Link work item</b>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tGo to <b>More</b> > <b>Link Work Item</b>.\n\t</DoDont>\n</DoDontGrid>\n\n## Grammar\n\n### Active voice\n\nUse active voice whenever possible as it improves readability and reflects Atlassian’s\n[voice and tone](https://atlassian.design/foundations/content/voice-tone).\n\nActive voice:\n\n- puts the emphasis on the person or thing doing an action.\n- makes content shorter, clearer, friendlier, and more conversational.\n\n<DoDontGrid>\n\t<DoDont type="do">Administrators control access to Atlassian Cloud applications.</DoDont>\n\t<DoDont type="dont">\n\t\tAccess to Atlassian Cloud applications is controlled by administrators.\n\t</DoDont>\n</DoDontGrid>\n\n### Pronouns (you, your, we)\n\n- Minimize the use of pronouns.\n- Most of the time they can be avoided. However, when advising a user, indicating that something in\n the UI is theirs, or in error messages, you can use ‘you’ or ’your’ or ’we’ for a friendlier tone.\n\n<DoDontGrid>\n\t<DoDont type="do">Get access to your work items here.</DoDont>\n\t<DoDont type="dont">Get access to the work items here.</DoDont>\n\t<DoDont type="do">Your projects</DoDont>\n\t<DoDont type="dont">My projects</DoDont>\n\t<DoDont type="do">We couldn\'t load your page</DoDont>\n\t<DoDont type="dont">The page couldn\'t be loaded </DoDont>\n</DoDontGrid>\n\n### Tense\n\n**Present tense** helps make instructions and messages in the UI clear and engaging.\n\n<DoDontGrid>\n\t<DoDont type="do">We can’t load work item DSP-32113.</DoDont>\n\t<DoDont type="dont">We couldn’t load work item DSP-32113.</DoDont>\n\t<DoDont type="do">Validation is required.</DoDont>\n\t<DoDont type="dont">Validation will be required.</DoDont>\n</DoDontGrid>\n\n**Past tense** can be used to communicate a completed action, like in error message headings and\nsuccess flags, or where there could be confusion.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>Upload failed</li>\n\t\t\t<li>File created</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>Upload fail</li>\n\t\t\t<li>File create</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n## Punctuation\n\n### Apostrophes (\')\n\n- Use an apostrophe to show possession. The apostrophe is placed before the ‘s’ for singular terms\n and after the ‘s’ for plurals.\n- If a word ends in an ‘s’ and is singular, add an ‘s after the ‘s’.\n- Use a curly apostrophe for better readability and to differentiate from code.\n - On a Mac: **option** + **shift ** + **]**\n - On Windows: **Control** + **\'** (or **alt** + **0146**)\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>A week’s time</li>\n\t\t\t<li>Three weeks’ time</li>\n\t\t\t<li>James’s work items</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>A weeks time</li>\n\t\t\t<li>Three week\'s time</li>\n\t\t\t<li>James\' work items</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Colons (:)\n\n- Use colons to introduce a bulleted list or series of steps.\n- Don’t use colons at the end of headings.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tA password should have:\n\t\t<ul>\n\t\t\t<li>12 characters or more </li>\n\t\t\t<li>at least one symbol and one number</li>\n\t\t\t<li>a mix of capital and lowercase letters</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<p>\n\t\t\t<b>Turn on two-factor authentication:</b>\n\t\t</p>\n\t\t<p>Keep your account safe with an extra layer of security.</p>\n\t</DoDont>\n</DoDontGrid>\n\n### Commas (,)\n\nUse an Oxford (or ‘serial’) comma to offset the final item in a list.\n\n<DoDontGrid>\n\t<DoDont type="do">Jira, Confluence, Loom, and Bitbucket are all Atlassian apps.</DoDont>\n\t<DoDont type="dont">Jira, Confluence, Loom and Bitbucket are all Atlassian apps. </DoDont>\n</DoDontGrid>\n\n### Dashes (—) and hyphens (-)\n\n#### Dashes\n\n- Use dashes in UI content sparingly. If using, use a spaced em dash.\n- In long-form content, use them sparingly to show an abrupt change in a sentence — like this. If\n the break happens in the middle of a sentence — ike this — use spaced em dashes on either side of\n the phrase.\n- If possible, rewrite the sentence or make 2 sentences to avoid a dash. Clear, concise sentences\n are better for readability and accessibility.\n- Don\'t use a dash or hyphen for ranges of numbers. Use \'to\' instead.\n- When adding the space, use non-breaking spaces (**option** + **shift** + **space**) to avoid the\n dash shifting to a new line.\n- To make an em dash:\n - On a Mac: **option** + **shift** + **hyphen**\n - On Windows: **Control** + **Alt** + **-** (or **Alt** + **0151**)\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tJira Service Management belongs to Jira\'s family of apps. They’re all built on the same platform\n\t\tand share the same site URL.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tJira Service Management belongs to Jira\'s family of apps — they’re all built on the same\n\t\tplatform and share the same site URL.\n\t</DoDont>\n\t<DoDont type="do">50 to 100</DoDont>\n\t<DoDont type="dont">50—100</DoDont>\n</DoDontGrid>\n\n#### Hyphens\n\n- If a noun is described by 2 or more words, use a hyphen to join those words together so they act\n as a compound adjective (or compound modifier).\n- **Exceptions**: don’t add a hyphen after the word ‘very’ or adverbs ending in -ly.\n- For specific hyphenated word guidance, check\n [Vocabulary (Atlassians only)](https://hello.atlassian.net/wiki/spaces/AV/pages/1686830783/Atlassian+global+vocabulary+list).\n- Use a hyphen when not doing so could cause confusion or ambiguity. Consult the\n [Merriam-Webster dictionary](https://www.merriam-webster.com/) if you’re not sure.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>system-wide update</li>\n\t\t\t<li>character-counter logic</li>\n\t\t\t<li>widely communicated update</li>\n\t\t\t<li>very cold drink</li>\n\t\t\t<li>autocorrect</li>\n\t\t\t<li>coworker</li>\n\t\t\t<li>preexisting</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>system wide update</li>\n\t\t\t<li>character counter logic</li>\n\t\t\t<li>widely-communicated update</li>\n\t\t\t<li>very-cold drink</li>\n\t\t\t<li>auto-correct</li>\n\t\t\t<li>co-worker</li>\n\t\t\t<li>pre-existing</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>re-sign the document</li>\n\t\t\t<li>re-create the page</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>resign the document</li>\n\t\t\t<li>recreate the page</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Ellipses ( … )\n\n- Don’t put spaces in between the periods in an ellipsis.\n- Use the symbol for the ellipsis rather than a string of periods:\n - On a Mac: **Option** + **;**\n - On Windows: **Ctrl** + **Alt** + **.** (or **Alt** + **0133**)\n\n#### Truncation\n\nEllipses can be used to show that text has been cut off — or truncated — when a message doesn’t fit\nin a given space. View [truncation guidance](#truncation).\n\n#### Quotes\n\n- When using an ellipsis to omit part of a long quote, include spaces on either side of the ellipsis\n ( … ).\n- For example: “From medicine and space travel to disaster response … our products help teams all\n over the planet advance humanity through the power of software.” Atlassian: Discover our story.\n\n### Exclamation marks (!)\n\n- Avoid exclamation marks in UI copy and minimize their use in product marketing copy.\n- They can be considered for exciting or new things, but ask yourself if it’s really that exciting\n or if one is needed. Don’t use more than one exclamation mark per page.\n\n<DoDontGrid>\n\t<DoDont type="do">Project is complete.</DoDont>\n\t<DoDont type="dont">Project is complete!</DoDont>\n</DoDontGrid>\n\n### Periods (.)\n\n- Use a period (full stop) at the end of complete sentences, including in helper text, messages, and\n notifications.\n- Don’t use periods in headers, titles, tooltips, field descriptions, and menu names, even if they\n are full sentences. While long content is discouraged, an exception is if these elements contain\n more than 1 sentence.\n- Only use periods in a bulleted list if the item is a complete sentence. Don’t add a period at the\n end of a list of fragments.\n- Add only one space after a period (full stop).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<p>\n\t\t\t<b>Accessibility principles</b>\n\t\t</p>\n\t\t<p>Our principles cover the main requirements to design and build accessible experiences.</p>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<p>\n\t\t\t<b>Accessibility principles.</b>\n\t\t</p>\n\t\t<p>Our principles cover the main requirements to design and build accessible experiences.</p>\n\t</DoDont>\n</DoDontGrid>\n\nIf a link ends a sentence, include a period but don’t hyperlink it.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tAtlassian’s work is guided by{\' \'}\n\t\t<a href="https://www.atlassian.com/company/values">5 core values</a>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tAtlassian’s work is guided by{\' \'}\n\t\t<a href="https://www.atlassian.com/company/values">5 core values.</a>\n\t</DoDont>\n</DoDontGrid>\n\n### Quotation marks (‘’ | “”)\n\nIn the UI, use:\n\n- single curly quotes, unless you\'re writing in code or there’s a semantic reason to use straight\n quotes.\n\nIn body copy and long-form content, such as documentation and marketing, use:\n\n- double quotes (”“) for speech and direct quotes. Don’t use italics.\n- single quotes (‘’) to draw attention to a word you’re defining.\n\n<DoDontGrid>\n\t<DoDont type="do">“We have big things planned for the coming year,” said Mike.</DoDont>\n\t<DoDont type="dont">‘We have big things planned for the coming year,’ said Mike.</DoDont>\n\t<DoDont type="do">They tried to avoid talking about the ‘big’ secret.</DoDont>\n\t<DoDont type="dont">They tried to avoid talking about the “big“ secret.</DoDont>\n</DoDontGrid>\n\n#### Emphasis\n\nDon’t use quotation marks to emphasize UI elements, page titles, and other objects. Instead use\n[bold](#bold).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tGo to <b>Settings</b>.\n\t</DoDont>\n\t<DoDont type="dont">Go to ‘Settings’.</DoDont>\n</DoDontGrid>\n\n#### Shortcuts\n\n##### Mac\n\n- Double quotes:\n - opening marks: **option** + **[**\n - closing marks: **option** + **shift** + **[**\n- Single quotes:\n - opening marks: **option** + **]**\n - closing marks: **option** + **shift** + **]**\n\n##### Windows\n\n- Double quotes:\n - opening marks: **Alt** + **0147**\n - closing marks: **Alt** + **0148**\n- Single quotes:\n - opening marks: **Alt** + **0145**\n - closing marks: **Alt** + **0146**',
|
|
@@ -9,7 +9,7 @@ exports.lintRulesMcpStructuredContent = void 0;
|
|
|
9
9
|
*
|
|
10
10
|
* Structured content for MCP (JSON) for ESLint rule docs from constellation.
|
|
11
11
|
*
|
|
12
|
-
* @codegen <<SignedSource::
|
|
12
|
+
* @codegen <<SignedSource::4d483a032c59ed6a5c19bb250c87cb6b>>
|
|
13
13
|
* @codegenCommand yarn build structured-docs
|
|
14
14
|
*/
|
|
15
15
|
/* eslint-disable no-template-curly-in-string */
|
|
@@ -51,7 +51,7 @@ var lintRulesMcpStructuredContent = exports.lintRulesMcpStructuredContent = [{
|
|
|
51
51
|
ruleName: 'icon-label',
|
|
52
52
|
description: 'Icon labels are used to describe what the icon is so the visually impaired can be described what the'
|
|
53
53
|
}, {
|
|
54
|
-
content: '{"ruleName":"index","description":"---","content":"---\\norder: 0\\n---\\n\\nThis plugin contains rules that should be used when working with the\\n[Atlassian Design System](https://atlassian.design).\\n\\n## Rules\\n\\n<!-- START_RULE_TABLE_CODEGEN -->\\n<!-- @codegenCommand yarn workspace @atlaskit/eslint-plugin-design-system codegen -->\\n\\n| Rule | Description | Recommended | Fixable | Suggestions |\\n| ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------- | ----------- |\\n| <a href=\\"/components/eslint-plugin-design-system/consistent-css-prop-usage/usage\\">consistent-css-prop-usage</a> | Ensures consistency with `css` and `xcss` prop usages | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/enforce-inline-styles-in-select/usage\\">enforce-inline-styles-in-select</a> | Disallow unsupported CSS selectors in styles prop for @atlaskit/select and require inline styles only | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/ensure-avatar-tag-avatar-props/usage\\">ensure-avatar-tag-avatar-props</a> | Ensures AvatarTag avatar prop does not include controlled props (size, borderColor, appearance) which are managed internally. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/ensure-design-token-usage/usage\\">ensure-design-token-usage</a> | Enforces usage of design tokens rather than hard-coded values. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/ensure-design-token-usage-preview/usage\\">ensure-design-token-usage/preview</a> | Enforces usage of pre-release design tokens rather than hard-coded values. | | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/ensure-icon-color/usage\\">ensure-icon-color</a> | Enforces that upcoming icon components have a color prop set, to enable a migration of the default value. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/ensure-proper-xcss-usage/usage\\">ensure-proper-xcss-usage</a> | Enforces proper xcss usage: migrate from xcss() to cssMap() and use cssMap objects with specific keys. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/icon-label/usage\\">icon-label</a> | Enforces accessible usage of icon labels when composed with Atlassian Design System components. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/lozenge-badge-tag-labelling-system-migration/usage\\">lozenge-badge-tag-labelling-system-migration</a> | Helps migrate Lozenge isBold prop, Badge appearance values, and SimpleTag/RemovableTag components as part of the Labelling System Phase 1 migration. | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-banned-imports/usage\\">no-banned-imports</a> | Disallow importing banned modules. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-boolean-autofocus-on-modal-dialog/usage\\">no-boolean-autofocus-on-modal-dialog</a> | Encourages makers to not use boolean values for `autoFocus` on Atlassian Design System\'s modal dialog component. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-css-tagged-template-expression/usage\\">no-css-tagged-template-expression</a> | Disallows any `css` tagged template expressions that originate from Emotion, Styled Components or Compiled | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-custom-icons/usage\\">no-custom-icons</a> | Enforces custom glyph icons are used. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-dark-theme-vr-tests/usage\\">no-dark-theme-vr-tests</a> | Disallow using dark colorScheme in VR tests. | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-deprecated-apis/usage\\">no-deprecated-apis</a> | Disallow using deprecated APIs. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-deprecated-design-token-usage/usage\\">no-deprecated-design-token-usage</a> | Disallow using deprecated design tokens. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-deprecated-imports/usage\\">no-deprecated-imports</a> | Disallow importing deprecated modules. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-direct-use-of-web-platform-drag-and-drop/usage\\">no-direct-use-of-web-platform-drag-and-drop</a> | Disallow using direct use of native drag and drop (please use Pragmatic drag and drop) | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-emotion-primitives/usage\\">no-emotion-primitives</a> | Ensures usage of Compiled Primitives import instead of Emotion entrypoint. | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-empty-styled-expression/usage\\">no-empty-styled-expression</a> | Forbids any styled expression to be used when passing empty arguments to styled.div() (or other JSX elements). | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-exported-css/usage\\">no-exported-css</a> | Forbid exporting `css` function calls. Exporting `css` function calls can result in unexpected behaviour at runtime, and is not statically analysable. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-exported-keyframes/usage\\">no-exported-keyframes</a> | Forbid exporting `keyframes` function calls. Exporting `css` function calls can result in unexpected behaviour at runtime, and is not statically analysable. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-anchor/usage\\">no-html-anchor</a> | Discourage direct usage of HTML anchor elements in favor of Atlassian Design System link components. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-button/usage\\">no-html-button</a> | Discourage direct usage of HTML button elements in favor of Atlassian Design System button components. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-checkbox/usage\\">no-html-checkbox</a> | Discourage direct usage of HTML checkbox elements in favor of the Atlassian Design System checkbox component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-code/usage\\">no-html-code</a> | Discourage direct usage of HTML code elements in favor of the Atlassian Design System code component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-heading/usage\\">no-html-heading</a> | Discourage direct usage of HTML heading elements in favor of Atlassian Design System heading components. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-image/usage\\">no-html-image</a> | Discourage direct usage of HTML image elements in favor of the Atlassian Design System image component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-radio/usage\\">no-html-radio</a> | Discourage direct usage of HTML radio elements in favor of the Atlassian Design System radio component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-range/usage\\">no-html-range</a> | Discourage direct usage of HTML range elements in favor of the Atlassian Design System range component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-select/usage\\">no-html-select</a> | Discourage direct usage of HTML select elements in favor of the Atlassian Design System select component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-text-input/usage\\">no-html-text-input</a> | Discourage direct usage of HTML text input elements in favor of the Atlassian Design System textfield component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-textarea/usage\\">no-html-textarea</a> | Discourage direct usage of HTML textarea elements in favor of the Atlassian Design System textarea component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-icon-spacing-prop/usage\\">no-icon-spacing-prop</a> | Disallows usage of the deprecated spacing prop on new icons. Use Flex with cssMap for spacing instead. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-invalid-css-map/usage\\">no-invalid-css-map</a> | Checks the validity of a CSS map created through cssMap. This is intended to be used alongside TypeScript\'s type-checking. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-keyframes-tagged-template-expression/usage\\">no-keyframes-tagged-template-expression</a> | Disallows any `keyframe` tagged template expressions that originate from Emotion, Styled Components or Compiled | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-legacy-icons/usage\\">no-legacy-icons</a> | Enforces no legacy icons are used. | | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-margin/usage\\">no-margin</a> | Disallow using the margin CSS property. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-nested-styles/usage\\">no-nested-styles</a> | Disallows use of nested styles in `css` functions. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-physical-properties/usage\\">no-physical-properties</a> | Disallow physical properties and values in `css` and `cssMap` function calls. | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-placeholder/usage\\">no-placeholder</a> | Placeholders should not be used. If information should be given to the user about the proper type or formatting of a value, this should be included using a helper message that is associated to the input instead. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-separator-with-list-elements/usage\\">no-separator-with-list-elements</a> | Warn when the `separator` prop is used with `as=\\"li\\"`, `as=\\"ol\\"`, or `as=\\"dl\\"` in the Inline component. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-styled-tagged-template-expression/usage\\">no-styled-tagged-template-expression</a> | Disallows any `styled` tagged template expressions that originate from Emotion, Styled Components or Compiled | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-to-match-snapshot/usage\\">no-to-match-snapshot</a> | Disallow using toMatchSnapshot() in favor of toMatchInlineSnapshot(). See https://hello.atlassian.net/wiki/spaces/DST/pages/6105892000/DSTRFC-038+-+Removal+of+.toMatchSnapshot for rationale. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-unsafe-design-token-usage/usage\\">no-unsafe-design-token-usage</a> | Enforces design token usage is statically and locally analyzable. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-unsafe-inline-snapshot/usage\\">no-unsafe-inline-snapshot</a> | Enforce guardrails on toMatchInlineSnapshot usage: snapshots must not exceed 100 lines and must not contain internal implementation details like className or style attributes. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-unsafe-style-overrides/usage\\">no-unsafe-style-overrides</a> | Discourage usage of unsafe style overrides used against the Atlassian Design System. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-unsupported-drag-and-drop-libraries/usage\\">no-unsupported-drag-and-drop-libraries</a> | Disallow importing unsupported drag and drop modules. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-unused-css-map/usage\\">no-unused-css-map</a> | Detects unused styles in cssMap objects to help keep code clean. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/prefer-primitives/usage\\">prefer-primitives</a> | Increase awareness of primitive components via code hints. Strictly used for education purposes and discoverability. To enforce usage please refer to the `use-primitives` rule. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/use-button-group-label/usage\\">use-button-group-label</a> | Ensures button groups are described to assistive technology by a direct label or by another element. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-character-counter-field/usage\\">use-character-counter-field</a> | Suggests using CharacterCounterField or CharacterCounter when Textfield or Textarea components have maxLength or minLength props. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/use-correct-field/usage\\">use-correct-field</a> | Ensure makers use appropriate field component for their respective form elements. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-cx-function-in-xcss/usage\\">use-cx-function-in-xcss</a> | Enforces cx function use to combine styles in xcss. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-datetime-picker-calendar-button/usage\\">use-datetime-picker-calendar-button</a> | Encourages makers to use calendar button in Atlassian Design System\'s date picker and datetime picker components. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-drawer-label/usage\\">use-drawer-label</a> | Encourages to provide accessible name for Atlassian Design System Drawer component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-field-message-wrapper/usage\\">use-field-message-wrapper</a> | Encourage use of message wrapper component when using form message components. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-heading/usage\\">use-heading</a> | Encourage the usage of heading components. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-heading-level-in-spotlight-card/usage\\">use-heading-level-in-spotlight-card</a> | Inform developers of eventual requirement of `headingLevel` prop in `SpotlightCard` component. The heading level should be the appropriate level according to the surrounding context. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/use-href-in-link-item/usage\\">use-href-in-link-item</a> | Inform developers of eventual requirement of `href` prop in `LinkItem` component. Elements with a `link` role require an `href` attribute for users to properly navigate, particularly those using assistive technologies. If no valid `href` is required for your use case, consider using a `ButtonItem` instead. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-latest-xcss-syntax/usage\\">use-latest-xcss-syntax</a> | Enforces usage of space design tokens rather than hard-coded values in xcss. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/use-latest-xcss-syntax-typography/usage\\">use-latest-xcss-syntax-typography</a> | Prohibits use of unsafe styling properties in xcss. Please use Text/Heading primitives instead. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/use-menu-section-title/usage\\">use-menu-section-title</a> | Encourages makers to provide accessible title for Atlassian Design System Menu Section component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-modal-dialog-close-button/usage\\">use-modal-dialog-close-button</a> | Encourages makers to use close button in Atlassian Design System\'s modal dialog component. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-onboarding-spotlight-label/usage\\">use-onboarding-spotlight-label</a> | Ensures onboarding spotlight dialogs are described to assistive technology by a direct label or by another element. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-popup-label/usage\\">use-popup-label</a> | Encourages to provide accessible name for Atlassian Design System Popup component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-primitives/usage\\">use-primitives</a> | Encourage the usage of primitives components. | | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-primitives-text/usage\\">use-primitives-text</a> | Encourage the usage of text components. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-should-render-to-parent/usage\\">use-should-render-to-parent</a> | Encourages makers to use the `shouldRenderToParent` where possible in Atlassian Design System `Popup` and `DropdownMenu` components. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-simple-field/usage\\">use-simple-field</a> | Encourage use of simple field for better developer experience and accessibility. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-simple-form/usage\\">use-simple-form</a> | Encourage use of simple form for better developer experience and accessibility. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-spotlight-package/usage\\">use-spotlight-package</a> | Discourage the use of @atlaskit/onboarding in favor of @atlaskit/spotlight. | | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-tag-group-label/usage\\">use-tag-group-label</a> | Ensures tag groups are described to assistive technology by a direct label or by another element. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-tokens-shape/usage\\">use-tokens-shape</a> | Enforces usage of shape design tokens rather than hard-coded values. | | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-tokens-space/usage\\">use-tokens-space</a> | Enforces usage of space design tokens rather than hard-coded values. | | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-tokens-typography/usage\\">use-tokens-typography</a> | Enforces usage of design tokens for typography properties rather than hard-coded values. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-visually-hidden/usage\\">use-visually-hidden</a> | Enforce usage of the visually hidden component. | Yes | Yes | |\\n\\n<!-- END_RULE_TABLE_CODEGEN -->\\n\\n\\n## Props\\n\\nUse the recommended config to get reasonable defaults recommended by the Atlassian Design System:\\n\\n```diff\\nmodule.exports = {\\n extends: [\\n+ \'plugin:@atlaskit/design-system/recommended\',\\n ],\\n};\\n```\\n\\nWe don\'t recommended maintaining your own configuration. If you do not use our config you will need\\nto specify individual rules and configuration. Add the plugin to your `eslint.config.cjs` file.\\n\\n```diff\\nmodule.exports = {\\n plugins: [\\n+ \'@atlaskit/design-system\',\\n ],\\n};\\n```\\n\\nEnable the rules that you would like to use.\\n\\n```diff\\nmodule.exports = {\\n rules: [\\n+ \'@atlaskit/design-system/no-deprecated-apis\': \'error\',\\n ],\\n};\\n```\\n"}',
|
|
54
|
+
content: '{"ruleName":"index","description":"---","content":"---\\norder: 0\\n---\\n\\nThis plugin contains rules that should be used when working with the\\n[Atlassian Design System](https://atlassian.design).\\n\\n## Rules\\n\\n<!-- START_RULE_TABLE_CODEGEN -->\\n<!-- @codegenCommand yarn workspace @atlaskit/eslint-plugin-design-system codegen -->\\n\\n| Rule | Description | Recommended | Fixable | Suggestions |\\n| ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------- | ----------- |\\n| <a href=\\"/components/eslint-plugin-design-system/consistent-css-prop-usage/usage\\">consistent-css-prop-usage</a> | Ensures consistency with `css` and `xcss` prop usages | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/enforce-inline-styles-in-select/usage\\">enforce-inline-styles-in-select</a> | Disallow unsupported CSS selectors in styles prop for @atlaskit/select and require inline styles only | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/ensure-avatar-tag-avatar-props/usage\\">ensure-avatar-tag-avatar-props</a> | Ensures AvatarTag avatar prop does not include controlled props (size, borderColor, appearance) which are managed internally. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/ensure-design-token-usage/usage\\">ensure-design-token-usage</a> | Enforces usage of design tokens rather than hard-coded values. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/ensure-design-token-usage-preview/usage\\">ensure-design-token-usage/preview</a> | Enforces usage of pre-release design tokens rather than hard-coded values. | | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/ensure-icon-color/usage\\">ensure-icon-color</a> | Enforces that upcoming icon components have a color prop set, to enable a migration of the default value. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/ensure-proper-xcss-usage/usage\\">ensure-proper-xcss-usage</a> | Enforces proper xcss usage: migrate from xcss() to cssMap() and use cssMap objects with specific keys. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/icon-label/usage\\">icon-label</a> | Enforces accessible usage of icon labels when composed with Atlassian Design System components. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/lozenge-badge-tag-labelling-system-migration/usage\\">lozenge-badge-tag-labelling-system-migration</a> | Helps migrate Lozenge isBold prop, Badge appearance values, and SimpleTag/RemovableTag components as part of the Labelling System Phase 1 migration. | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-banned-imports/usage\\">no-banned-imports</a> | Disallow importing banned modules. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-boolean-autofocus-on-modal-dialog/usage\\">no-boolean-autofocus-on-modal-dialog</a> | Encourages makers to not use boolean values for `autoFocus` on Atlassian Design System\'s modal dialog component. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-css-tagged-template-expression/usage\\">no-css-tagged-template-expression</a> | Disallows any `css` tagged template expressions that originate from Emotion, Styled Components or Compiled | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-custom-icons/usage\\">no-custom-icons</a> | Enforces custom glyph icons are used. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-dark-theme-vr-tests/usage\\">no-dark-theme-vr-tests</a> | Disallow using dark colorScheme in VR tests. | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-deprecated-apis/usage\\">no-deprecated-apis</a> | Disallow using deprecated APIs. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-deprecated-design-token-usage/usage\\">no-deprecated-design-token-usage</a> | Disallow using deprecated design tokens. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-deprecated-imports/usage\\">no-deprecated-imports</a> | Disallow importing deprecated modules. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-direct-use-of-web-platform-drag-and-drop/usage\\">no-direct-use-of-web-platform-drag-and-drop</a> | Disallow using direct use of native drag and drop (please use Pragmatic drag and drop) | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-emotion-primitives/usage\\">no-emotion-primitives</a> | Ensures usage of Compiled Primitives import instead of Emotion entrypoint. | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-empty-styled-expression/usage\\">no-empty-styled-expression</a> | Forbids any styled expression to be used when passing empty arguments to styled.div() (or other JSX elements). | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-exported-css/usage\\">no-exported-css</a> | Forbid exporting `css` function calls. Exporting `css` function calls can result in unexpected behaviour at runtime, and is not statically analysable. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-exported-keyframes/usage\\">no-exported-keyframes</a> | Forbid exporting `keyframes` function calls. Exporting `css` function calls can result in unexpected behaviour at runtime, and is not statically analysable. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-anchor/usage\\">no-html-anchor</a> | Discourage direct usage of HTML anchor elements in favor of Atlassian Design System link components. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-button/usage\\">no-html-button</a> | Discourage direct usage of HTML button elements in favor of Atlassian Design System button components. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-checkbox/usage\\">no-html-checkbox</a> | Discourage direct usage of HTML checkbox elements in favor of the Atlassian Design System checkbox component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-code/usage\\">no-html-code</a> | Discourage direct usage of HTML code elements in favor of the Atlassian Design System code component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-heading/usage\\">no-html-heading</a> | Discourage direct usage of HTML heading elements in favor of Atlassian Design System heading components. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-image/usage\\">no-html-image</a> | Discourage direct usage of HTML image elements in favor of the Atlassian Design System image component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-radio/usage\\">no-html-radio</a> | Discourage direct usage of HTML radio elements in favor of the Atlassian Design System radio component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-range/usage\\">no-html-range</a> | Discourage direct usage of HTML range elements in favor of the Atlassian Design System range component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-select/usage\\">no-html-select</a> | Discourage direct usage of HTML select elements in favor of the Atlassian Design System select component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-text-input/usage\\">no-html-text-input</a> | Discourage direct usage of HTML text input elements in favor of the Atlassian Design System textfield component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-html-textarea/usage\\">no-html-textarea</a> | Discourage direct usage of HTML textarea elements in favor of the Atlassian Design System textarea component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-icon-spacing-prop/usage\\">no-icon-spacing-prop</a> | Disallows usage of the deprecated spacing prop on new icons. Use Flex with cssMap for spacing instead. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/no-invalid-css-map/usage\\">no-invalid-css-map</a> | Checks the validity of a CSS map created through cssMap. This is intended to be used alongside TypeScript\'s type-checking. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-keyframes-tagged-template-expression/usage\\">no-keyframes-tagged-template-expression</a> | Disallows any `keyframe` tagged template expressions that originate from Emotion, Styled Components or Compiled | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-margin/usage\\">no-margin</a> | Disallow using the margin CSS property. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-nested-styles/usage\\">no-nested-styles</a> | Disallows use of nested styles in `css` functions. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-physical-properties/usage\\">no-physical-properties</a> | Disallow physical properties and values in `css` and `cssMap` function calls. | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-placeholder/usage\\">no-placeholder</a> | Placeholders should not be used. If information should be given to the user about the proper type or formatting of a value, this should be included using a helper message that is associated to the input instead. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-separator-with-list-elements/usage\\">no-separator-with-list-elements</a> | Warn when the `separator` prop is used with `as=\\"li\\"`, `as=\\"ol\\"`, or `as=\\"dl\\"` in the Inline component. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-styled-tagged-template-expression/usage\\">no-styled-tagged-template-expression</a> | Disallows any `styled` tagged template expressions that originate from Emotion, Styled Components or Compiled | | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-to-match-snapshot/usage\\">no-to-match-snapshot</a> | Disallow using toMatchSnapshot() in favor of toMatchInlineSnapshot(). See https://hello.atlassian.net/wiki/spaces/DST/pages/6105892000/DSTRFC-038+-+Removal+of+.toMatchSnapshot for rationale. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-unsafe-design-token-usage/usage\\">no-unsafe-design-token-usage</a> | Enforces design token usage is statically and locally analyzable. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-unsafe-inline-snapshot/usage\\">no-unsafe-inline-snapshot</a> | Enforce guardrails on toMatchInlineSnapshot usage: snapshots must not exceed 100 lines and must not contain internal implementation details like className or style attributes. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-unsafe-style-overrides/usage\\">no-unsafe-style-overrides</a> | Discourage usage of unsafe style overrides used against the Atlassian Design System. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-unsupported-drag-and-drop-libraries/usage\\">no-unsupported-drag-and-drop-libraries</a> | Disallow importing unsupported drag and drop modules. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/no-unused-css-map/usage\\">no-unused-css-map</a> | Detects unused styles in cssMap objects to help keep code clean. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/prefer-primitives/usage\\">prefer-primitives</a> | Increase awareness of primitive components via code hints. Strictly used for education purposes and discoverability. To enforce usage please refer to the `use-primitives` rule. | | | |\\n| <a href=\\"/components/eslint-plugin-design-system/use-button-group-label/usage\\">use-button-group-label</a> | Ensures button groups are described to assistive technology by a direct label or by another element. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-character-counter-field/usage\\">use-character-counter-field</a> | Suggests using CharacterCounterField or CharacterCounter when Textfield or Textarea components have maxLength or minLength props. | Yes | | |\\n| <a href=\\"/components/eslint-plugin-design-system/use-correct-field/usage\\">use-correct-field</a> | Ensure makers use appropriate field component for their respective form elements. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-cx-function-in-xcss/usage\\">use-cx-function-in-xcss</a> | Enforces cx function use to combine styles in xcss. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-datetime-picker-calendar-button/usage\\">use-datetime-picker-calendar-button</a> | Encourages makers to use calendar button in Atlassian Design System\'s date picker and datetime picker components. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-drawer-label/usage\\">use-drawer-label</a> | Encourages to provide accessible name for Atlassian Design System Drawer component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-field-message-wrapper/usage\\">use-field-message-wrapper</a> | Encourage use of message wrapper component when using form message components. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-heading/usage\\">use-heading</a> | Encourage the usage of heading components. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-heading-level-in-spotlight-card/usage\\">use-heading-level-in-spotlight-card</a> | Inform developers of eventual requirement of `headingLevel` prop in `SpotlightCard` component. The heading level should be the appropriate level according to the surrounding context. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/use-href-in-link-item/usage\\">use-href-in-link-item</a> | Inform developers of eventual requirement of `href` prop in `LinkItem` component. Elements with a `link` role require an `href` attribute for users to properly navigate, particularly those using assistive technologies. If no valid `href` is required for your use case, consider using a `ButtonItem` instead. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-latest-xcss-syntax/usage\\">use-latest-xcss-syntax</a> | Enforces usage of space design tokens rather than hard-coded values in xcss. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/use-latest-xcss-syntax-typography/usage\\">use-latest-xcss-syntax-typography</a> | Prohibits use of unsafe styling properties in xcss. Please use Text/Heading primitives instead. | Yes | Yes | |\\n| <a href=\\"/components/eslint-plugin-design-system/use-menu-section-title/usage\\">use-menu-section-title</a> | Encourages makers to provide accessible title for Atlassian Design System Menu Section component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-modal-dialog-close-button/usage\\">use-modal-dialog-close-button</a> | Encourages makers to use close button in Atlassian Design System\'s modal dialog component. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-onboarding-spotlight-label/usage\\">use-onboarding-spotlight-label</a> | Ensures onboarding spotlight dialogs are described to assistive technology by a direct label or by another element. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-popup-label/usage\\">use-popup-label</a> | Encourages to provide accessible name for Atlassian Design System Popup component. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-primitives/usage\\">use-primitives</a> | Encourage the usage of primitives components. | | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-primitives-text/usage\\">use-primitives-text</a> | Encourage the usage of text components. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-should-render-to-parent/usage\\">use-should-render-to-parent</a> | Encourages makers to use the `shouldRenderToParent` where possible in Atlassian Design System `Popup` and `DropdownMenu` components. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-simple-field/usage\\">use-simple-field</a> | Encourage use of simple field for better developer experience and accessibility. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-simple-form/usage\\">use-simple-form</a> | Encourage use of simple form for better developer experience and accessibility. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-spotlight-package/usage\\">use-spotlight-package</a> | Discourage the use of @atlaskit/onboarding in favor of @atlaskit/spotlight. | | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-tag-group-label/usage\\">use-tag-group-label</a> | Ensures tag groups are described to assistive technology by a direct label or by another element. | Yes | | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-tokens-shape/usage\\">use-tokens-shape</a> | Enforces usage of shape design tokens rather than hard-coded values. | | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-tokens-space/usage\\">use-tokens-space</a> | Enforces usage of space design tokens rather than hard-coded values. | | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-tokens-typography/usage\\">use-tokens-typography</a> | Enforces usage of design tokens for typography properties rather than hard-coded values. | Yes | Yes | Yes |\\n| <a href=\\"/components/eslint-plugin-design-system/use-visually-hidden/usage\\">use-visually-hidden</a> | Enforce usage of the visually hidden component. | Yes | Yes | |\\n\\n<!-- END_RULE_TABLE_CODEGEN -->\\n\\n\\n## Props\\n\\nUse the recommended config to get reasonable defaults recommended by the Atlassian Design System:\\n\\n```diff\\nmodule.exports = {\\n extends: [\\n+ \'plugin:@atlaskit/design-system/recommended\',\\n ],\\n};\\n```\\n\\nWe don\'t recommended maintaining your own configuration. If you do not use our config you will need\\nto specify individual rules and configuration. Add the plugin to your `eslint.config.cjs` file.\\n\\n```diff\\nmodule.exports = {\\n plugins: [\\n+ \'@atlaskit/design-system\',\\n ],\\n};\\n```\\n\\nEnable the rules that you would like to use.\\n\\n```diff\\nmodule.exports = {\\n rules: [\\n+ \'@atlaskit/design-system/no-deprecated-apis\': \'error\',\\n ],\\n};\\n```\\n"}',
|
|
55
55
|
ruleName: 'index',
|
|
56
56
|
description: '---'
|
|
57
57
|
}, {
|
|
@@ -178,10 +178,6 @@ var lintRulesMcpStructuredContent = exports.lintRulesMcpStructuredContent = [{
|
|
|
178
178
|
content: '{"ruleName":"no-keyframes-tagged-template-expression","description":"Disallows any `keyframes` tagged template expressions that originate from a CSS-in-JS library,","content":"# no-keyframes-tagged-template-expression\\n\\nDisallows any `keyframes` tagged template expressions that originate from a CSS-in-JS library,\\nincluding `@atlaskit/css`, `@compiled/react`, Emotion, and `styled-components`.\\n\\nTagged template expressions are difficult to parse correctly (which can lead to more frequent build\\nfailures or invalid CSS generation), have limited type safety, and lack syntax highlighting. These\\nproblems can be avoided by using the preferred call expression syntax instead.\\n\\nThank you to the\\n[Compiled team for their rule](https://github.com/atlassian-labs/compiled/tree/master/packages/eslint-plugin/src/rules/no-keyframes-tagged-template-expression)\\nfrom which this was ported.\\n\\nThe `--fix` option on the command line automatically fixes problems reported by this rule.\\n\\n## Examples\\n\\n### Incorrect\\n\\n```js\\nimport { keyframes } from \'@compiled/react\';\\n\\nkeyframes`to { opacity: 0 }`;\\n\\nconst fadeOut = keyframes`\\n from {\\n opacity: 1;\\n }\\n to {\\n opacity: 0;\\n }\\n`;\\n```\\n\\n### Correct\\n\\n```js\\nimport { keyframes } from \'@compiled/react\';\\n\\nkeyframes({ to: { opacity: 0 } });\\n\\nconst fadeOut = keyframes({\\n\\tfrom: {\\n\\t\\topacity: 1,\\n\\t},\\n\\tto: {\\n\\t\\topacity: 0,\\n\\t},\\n});\\n```\\n\\n## Options\\n\\n### importSources\\n\\nBy default, this rule will check `keyframes` usages from:\\n\\n- `@atlaskit/css`\\n- `@atlaskit/primitives`\\n- `@compiled/react`\\n- `@emotion/react`\\n- `@emotion/core`\\n- `@emotion/styled`\\n- `styled-components`\\n\\nTo change this list of libraries, you can define a custom set of `importSources`, which accepts an\\narray of package names (strings).\\n\\n```tsx\\n// [{ importSources: [\'other-lib\'] }]\\n\\nimport { keyframes } from \'other-lib\';\\n\\n// Invalid!\\nexport const animation = keyframes``;\\n```\\n\\n## Limitations\\n\\n- Comments are not fixable\\n"}',
|
|
179
179
|
ruleName: 'no-keyframes-tagged-template-expression',
|
|
180
180
|
description: 'Disallows any `keyframes` tagged template expressions that originate from a CSS-in-JS library,'
|
|
181
|
-
}, {
|
|
182
|
-
content: '{"ruleName":"no-legacy-icons","description":"Icons are being updated with new designs, a simplified set of available icons and sizes, as well as","content":"# no-legacy-icons\\n\\nIcons are being updated with new designs, a simplified set of available icons and sizes, as well as\\nmore consistent padding and spacing.\\n\\nThe new icon components allows your components to align with the new visual language - either by\\ndefault, or when enabled via a feature flag.\\n\\n## Examples\\n\\nThis rule identifies usages of legacy icons from `@atlaskit/icon/glyph` that aren\'t yet migrated to\\nthe new icon API. Legacy icons are only permitted when passed into a new \\"core\\" or \\"utility\\" icon\\nfrom `@atlaskit/icon`, `@atlaskit/icon-lab` or `@atlassian/icon-private`, via the\\n`LEGACY_fallbackIcon` prop.\\n\\n### Incorrect\\n\\n```js\\nimport ActivityIcon from \'@atlaskit/icon/glyph/activity\'\\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ legacy icon import\\n\\nimport { IconButton } from \'@atlaskit/button/new\'\\n\\n<ActivityIcon label=\\"Activity\\">\\n^^^^^^^^^^^^^^^^^^^^^^^ legacy icon\\n\\n<IconButton icon={ActivityIcon} label=\\"Activity\\"/>\\n ^^^^^^^^^^^^^ legacy icon\\n```\\n\\n### Correct\\n\\n```js\\nimport AddIcon from \'@atlaskit/icon/core/add\';\\nimport { IconButton } from \'@atlaskit/button/new\';\\n\\n<AddIcon label=\\"\\" />;\\n<IconButton\\n\\ticon={(iconProps) => <AddIcon LEGACY_fallbackIcon={AddIconLegacy} {...iconProps} />}\\n\\tlabel=\\"Add to Cart\\"\\n/>;\\n```\\n\\n## Options\\n\\nThis rule comes with options to configure which errors display and in what detail - as well as how\\nicons should be migrated.\\n\\n### shouldErrorForAutoMigration\\n\\nEnables/disables errors for icons that are able to be automatically migrated. Defaults to `true`.\\n\\n### shouldErrorForManualMigration\\n\\nEnables/disables errors for icons that cannot be be automatically migrated and need manual review.\\nDefaults to `true`.\\n\\n### shouldUseSafeMigrationMode\\n\\nWhen `true`, the autofixer will only attempt to migrate icons that are visually similar. Defaults to\\n`false`.\\n\\n### shouldUseMigrationPath\\n\\nWhen `true`, the autofixer will use feature flagged migration entry-points,\\n`@atlaskit/icon/core/migration/`. Defaults to `true`.\\n\\n### quiet\\n\\nWhen `true`, the rule will only provide one error per icon usage, stating if the icon can be\\nautomatically migrated or not\\n"}',
|
|
183
|
-
ruleName: 'no-legacy-icons',
|
|
184
|
-
description: 'Icons are being updated with new designs, a simplified set of available icons and sizes, as well as'
|
|
185
181
|
}, {
|
|
186
182
|
content: '{"ruleName":"no-margin","description":"Using margins to define spacing results in components that can\'t be readily reused in other contexts","content":"# no-margin\\n\\nUsing margins to define spacing results in components that can\'t be readily reused in other contexts\\nbreaking the composition model. Instead defining spacing in parents with flex and grid using the\\n`gap` property will result in more resilient experiences.\\n\\n## Examples\\n\\nThis rule will mark all margin use as violations.\\n\\n### Incorrect\\n\\n```tsx\\ncss({ margin: \'10px\' });\\n```\\n\\n### Correct\\n\\n```tsx\\ncss({ gap: token(\'spacing.100\') });\\n```\\n"}',
|
|
187
183
|
ruleName: 'no-margin',
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
/* eslint-disable-next-line import/extensions -- MCP SDK requires .js extensions for ESM imports */
|
|
2
2
|
|
|
3
3
|
import { z } from 'zod';
|
|
4
|
+
import { tokens } from '@atlaskit/tokens/token-metadata';
|
|
4
5
|
import { zodToJsonSchema } from '../../helpers';
|
|
5
|
-
import { tokens } from './tokens';
|
|
6
6
|
const inputSchema = z.object({});
|
|
7
7
|
export const listGetAllTokensTool = {
|
|
8
8
|
name: 'ads_get_all_tokens',
|
|
@@ -21,6 +21,10 @@ export const getAllTokensTool = async () => ({
|
|
|
21
21
|
// NOTE: Ideally one day the MCP would support structured content…
|
|
22
22
|
// eg. `type: 'object', data: token`
|
|
23
23
|
type: 'text',
|
|
24
|
-
text: JSON.stringify(
|
|
24
|
+
text: JSON.stringify({
|
|
25
|
+
name: token.name,
|
|
26
|
+
exampleValue: token.exampleValue,
|
|
27
|
+
usageGuidelines: token.usageGuidelines
|
|
28
|
+
}, null, 2)
|
|
25
29
|
}))
|
|
26
30
|
});
|