mdn / data

This repository contains general data for Web technologies

Welcome to MDN data

Note We are in the process of deprecating the mdn/data package in favor of w3c/webref. If you depend on this project, let us know in our community GitHub discussions. Thank you.

This repository contains general data for Web technologies and is maintained by the MDN team at Mozilla.

Repository contents

The data in this repository is used in MDN Web Docs to build information boxes and sidebar navigation. External tools make use of this data as well, for example, the CSSTree CSS parser.

There's a top-level directory for each broad area covered: for example, api and css. Inside each of these directories is one or more JSON files containing the data.

api

Contains data about Web APIs:

• API inheritance (interface inheritance and mixin implementations)

css

Contains data about:

• CSS at-rules
• CSS functions
• CSS properties
• CSS selectors
• CSS syntaxes
• CSS types
• CSS units

For more information, see the CSS data documentation and the Updating CSS JSON DB guide.

l10n

The l10n folder contains localization strings that are used in the various json files throughout this repository.

Problems?

If you find a problem, please file an issue.

Contributing

We're very happy to accept contributions to this data. Please familiarize yourself with the schema for the data you're editing, and send us a pull request. See the CONTRIBUTING.md document for more information.

See also

• https://github.com/mdn/browser-compat-data for compatibility data for Web technologies

data's Issues

Question regarding the license and usage of data

Following up #199, I have made a PR that uses mdn/data to enhance the data we have at vscode-css-languageservice: https://github.com/Microsoft/vscode-css-languageservice/pull/91/files. It imports JSON files from mdn/data and build a browser.ts on top of it.

Then @chriseppstein raised a good question. Does transformation of the original data count as modification?

Q11 of MPL FAQ states if I have any modification I must license the modification in MPL too. And from 1.4 and 1.10 of MPL, our case could be argued to be "modification" under this clause:

any file in Source Code Form that results from an addition to, deletion from, or modification of the contents of Covered Software; or

In this case, I think the JSON files here could be considered as "contents of Covered Software", and our use could be considered "modifications". Having part of our codebase in a copyleft license could make people uneasy to adopt it.

@wbamberg Could you consider re-license the data in MIT license or correct my understanding of the license?

Remove redundant angle brackets for type name in types.json

types.json is single dictionary where angle brackets are used for key (type name). I think it's a legacy and suggest to remove brackets.

'object-fit' should be inherited: false

Per the spec, object-fit is not inherited:
https://drafts.csswg.org/css-images-3/#the-object-fit

Make it easy to validate data about specs

The W3C community has built over time a series of tools and APIs that enable to determine a number of MDN-relevant information about specs (including title, editors and TR URLs, statuses, github repos, test suites).

To make it easier to use these tools to verify and update the data currently used in MDN (and currently hosted in kumascript macros https://github.com/mdn/kumascript/blob/master/macros/spec2.ejs & https://github.com/mdn/kumascript/blob/master/macros/SpecName.ejs, it would be much easier if the data was kept separated from the template themselves.

I have provided pull requests to that effect: #157 and mdn/kumascript#557

This issue is raised to discuss the goals and approaches as requested.

Regular NPM releases?

This data is released on npm, but has only been released once despite frequent commits and updates to the website. Can the process for updating the website also include releasing updates to the npm package? 🙏

https://www.npmjs.com/package/mdn-data

Remove spec status from css properties

The status (standard/experimental/obsolete) is stored on the browser-compat-data entry. Duplicate information leads to difficulty to maintain coherence, especially when their value set is different.

This can be removed once CSS compat data is fully migrated, and eventual macro using it updated.

Lint sort order of data sheets

Alphabetically sorted data provides maintainability for large sheets. A linter that verifies the sort order would be nice! Maybe even with a --fixup flag that solves it for you (?).

Related
#188
#196

typo: data/api/inheritance.md - bad link

The schema link in the description document fails 404

[data](https://github.com/mdn/data/blob/master/api/inheritance.json) |
[schema](https://github.com/mdn/data/blob/master/css/inheritance.schema.json)

Perhaps s/css/api/ ?

Migration Template:SpecName

https://developer.mozilla.org/en-US/docs/Template:SpecName

border-inline-* and border-block-* shorthands have incorrect color computed property

In css/properties.json, border-inline and border-block shorthand properties have the incorrect color computed property. For example, the border-inline-start property shows:

"border-inline-start": {
    ...
    "computed": [
      "border-width",
      "border-style",
      "color"
    ],
   ...
  }

Instead of "border-inline-start-color" as the computed property, it lists "color". Similarly for border-inline-end, border-block-start, and border-block-end.

Remove HTML entities from syntaxes

For historical reasons syntaxes contain HTML entities as a replacement for symbols like <, > or &. It makes hard to read, maintain and use it in non-HTML contexts.

Suggestion is replace HTML entities to corresponding symbols.

(based on #8)

Missing entity encoding in generated HTML

Hi, just discovered that there is sometimes a missing entity encoding of for example > chars inside the HTML title description.

Example:

1. Go to: view-source:https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/getContext

And locate the "Return value" section within the wikiarticle.

2. Inside the "title" value of the A-element there is a > that is not encoded properly to >.

I tried to trace it back to root-cause by entering edit mode. Of course, in edit mode you'll only see a domxref tag:

and following the breadcrumbs ended up in nothing I could correct (AFAICS) so this may require change in code base?

Simplify syntaxes

While working on new matching approach in CSSTree I found that some syntaxes can be simplified. I wrote a script to detect some cases. Here is the output:

# mdn/atRules/@font-face "font-display"
A top level group can be omitted
Current syntax:   [ auto | block | swap | fallback | optional ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: auto | block | swap | fallback | optional
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/atRules "@import"
A single term group can be omitted and a multiplier moved to a term
Current syntax:   @import [ <string> | <url> ] [ <media-query-list> ]? ;
                                               ~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: @import [ <string> | <url> ] <media-query-list>? ;
                                               ~~~~~~~~~~~~~~~~~~~

# mdn/properties "cursor"
A top level group can be omitted
Current syntax:   [ [ <url> [ <x> <y> ]? , ]* [ auto | default | none | context-menu | help | pointer | progress | wait | cell | crosshair | text | vertical-text | alias | copy | move | no-drop | not-allowed | e-resize | n-resize | ne-resize | nw-resize | s-resize | se-resize | sw-resize | w-resize | ew-resize | ns-resize | nesw-resize | nwse-resize | col-resize | row-resize | all-scroll | zoom-in | zoom-out | grab | grabbing ] ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: [ <url> [ <x> <y> ]? , ]* [ auto | default | none | context-menu | help | pointer | progress | wait | cell | crosshair | text | vertical-text | alias | copy | move | no-drop | not-allowed | e-resize | n-resize | ne-resize | nw-resize | s-resize | se-resize | sw-resize | w-resize | ew-resize | ns-resize | nesw-resize | nwse-resize | col-resize | row-resize | all-scroll | zoom-in | zoom-out | grab | grabbing ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/properties "initial-letter-align"
A top level group can be omitted
Current syntax:   [ auto | alphabetic | hanging | ideographic ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: auto | alphabetic | hanging | ideographic
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/properties "outline"
A top level group can be omitted
Current syntax:   [ <'outline-color'> || <'outline-style'> || <'outline-width'> ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: <'outline-color'> || <'outline-style'> || <'outline-width'>
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "attr()"
A group can be omitted and a multiplier moved to a non-comma term
Current syntax:   attr( <attr-name> <type-or-unit>? [, <attr-fallback> ]? )
                                                    ~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: attr( <attr-name> <type-or-unit>? , <attr-fallback>? )
                                                    ~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "bg-position"
A top level group can be omitted
Current syntax:   [ [ left | center | right | top | bottom | <length-percentage> ] | [ left | center | right | <length-percentage> ] [ top | center | bottom | <length-percentage> ] | [ center | [ left | right ] <length-percentage>? ] && [ center | [ top | bottom ] <length-percentage>? ] ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: [ left | center | right | top | bottom | <length-percentage> ] | [ left | center | right | <length-percentage> ] [ top | center | bottom | <length-percentage> ] | [ center | [ left | right ] <length-percentage>? ] && [ center | [ top | bottom ] <length-percentage>? ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "circle()"
A single term group can be omitted and a multiplier moved to a term
Current syntax:   circle( [ <shape-radius> ]? [ at <position> ]? )
                          ~~~~~~~~~~~~~~~~~~~
Suggested syntax: circle( <shape-radius>? [ at <position> ]? )
                          ~~~~~~~~~~~~~~~

# mdn/syntaxes "common-lig-values"
A top level group can be omitted
Current syntax:   [ common-ligatures | no-common-ligatures ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: common-ligatures | no-common-ligatures
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "contextual-alt-values"
A top level group can be omitted
Current syntax:   [ contextual | no-contextual ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: contextual | no-contextual
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "contrast()"
A single term group with no multiplier can be omitted
Current syntax:   contrast( [ <number-percentage> ] )
                            ~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: contrast( <number-percentage> )
                            ~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "discretionary-lig-values"
A top level group can be omitted
Current syntax:   [ discretionary-ligatures | no-discretionary-ligatures ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: discretionary-ligatures | no-discretionary-ligatures
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "east-asian-variant-values"
A top level group can be omitted
Current syntax:   [ jis78 | jis83 | jis90 | jis04 | simplified | traditional ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: jis78 | jis83 | jis90 | jis04 | simplified | traditional
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "east-asian-width-values"
A top level group can be omitted
Current syntax:   [ full-width | proportional-width ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: full-width | proportional-width
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "fixed-repeat"
A single term group with no multiplier can be omitted
Current syntax:   repeat( [ <positive-integer> ] , [ <line-names>? <fixed-size> ]+ <line-names>? )
                          ~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: repeat( <positive-integer> , [ <line-names>? <fixed-size> ]+ <line-names>? )
                          ~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "font-variant-css21"
A top level group can be omitted
Current syntax:   [ normal | small-caps ]
                  ~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: normal | small-caps
                  ~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "historical-lig-values"
A top level group can be omitted
Current syntax:   [ historical-ligatures | no-historical-ligatures ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: historical-ligatures | no-historical-ligatures
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "matrix()"
A sequence can be rolled up
Current syntax:   matrix( <number> [, <number> ]{5} )
                          ~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: matrix( <number>#{6} )
                          ~~~~~~~~~~~~

# mdn/syntaxes "matrix3d()"
A sequence can be rolled up
Current syntax:   matrix3d( <number> [, <number> ]{15} )
                            ~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: matrix3d( <number>#{16} )
                            ~~~~~~~~~~~~~

# mdn/syntaxes "numeric-figure-values"
A top level group can be omitted
Current syntax:   [ lining-nums | oldstyle-nums ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: lining-nums | oldstyle-nums
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "numeric-fraction-values"
A top level group can be omitted
Current syntax:   [ diagonal-fractions | stacked-fractions ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: diagonal-fractions | stacked-fractions
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "numeric-spacing-values"
A top level group can be omitted
Current syntax:   [ proportional-nums | tabular-nums ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: proportional-nums | tabular-nums
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "opacity()"
A single term group with no multiplier can be omitted
Current syntax:   opacity( [ <number-percentage> ] )
                           ~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: opacity( <number-percentage> )
                           ~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "position"
A top level group can be omitted
Current syntax:   [ [ left | center | right ] || [ top | center | bottom ] | [ left | center | right | <length-percentage> ] [ top | center | bottom | <length-percentage> ]? | [ [ left | right ] <length-percentage> ] && [ [ top | bottom ] <length-percentage> ] ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: [ left | center | right ] || [ top | center | bottom ] | [ left | center | right | <length-percentage> ] [ top | center | bottom | <length-percentage> ]? | [ [ left | right ] <length-percentage> ] && [ [ top | bottom ] <length-percentage> ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "scale()"
A sequence can be rolled up
Current syntax:   scale( <number> [, <number> ]? )
                         ~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: scale( <number>#{1,2} )
                         ~~~~~~~~~~~~~~

# mdn/syntaxes "skew()"
A sequence can be rolled up
Current syntax:   skew( <angle> [, <angle> ]? )
                        ~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: skew( <angle>#{1,2} )
                        ~~~~~~~~~~~~~

# mdn/syntaxes "shadow-t"
A top level group can be omitted
Current syntax:   [ <length>{2,3} && <color>? ]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: <length>{2,3} && <color>?
                  ~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "step-timing-function"
A group can be omitted and a multiplier moved to a non-comma term
Current syntax:   step-start | step-end | steps( <integer> [, [ start | end ] ]? )
                                                           ~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: step-start | step-end | steps( <integer> , [ start | end ]? )
                                                           ~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "track-repeat"
A single term group with no multiplier can be omitted
Current syntax:   repeat( [ <positive-integer> ] , [ <line-names>? <track-size> ]+ <line-names>? )
                          ~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: repeat( <positive-integer> , [ <line-names>? <track-size> ]+ <line-names>? )
                          ~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "translate()"
A sequence can be rolled up
Current syntax:   translate( <length-percentage> [, <length-percentage> ]? )
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: translate( <length-percentage>#{1,2} )
                             ~~~~~~~~~~~~~~~~~~~~~~~~~

# mdn/syntaxes "var()"
A group can be omitted and a multiplier moved to a non-comma term
Current syntax:   var( <custom-property-name> [, <declaration-value> ]? )
                                              ~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested syntax: var( <custom-property-name> , <declaration-value>? )
                                              ~~~~~~~~~~~~~~~~~~~~~~


Total suggestions: 31
   17 × A top level group can be omitted
    2 × A single term group can be omitted and a multiplier moved to a term
    5 × A sequence can be rolled up
    4 × A single term group with no multiplier can be omitted
    3 × A group can be omitted and a multiplier moved to a non-comma term

Action plan:

• mdn/data specific syntaxes (generated by a description) can be changed quite easily
• Some syntaxes are already changed in related specs, but mdn/data contains its outdated versions – those syntaxes should be aligned to specs
• Some syntaxes are defined in that form in specs (such as matrix(), skew(), repeat(), attr() etc) – issues to related specs should be filled and syntaxes updated depending on its resolution

//cc @fantasai @tabatkins (sorry for mentioning, but I thought it might be interesting to you)

Use MDN data to power auto completion in editors through Language Server Protocol

Hello, this is Pine from VS Code team. We are looking into using MDN data to provide an always up-to-date auto completion in VS Code, for example:

The auto completion is generated by our css language server and css language service that uses Language Server Protocol.

Here is a simple explanation: Language Server Protocol is a language & editor independent protocol for enhancing code editing experience. For example rust has https://github.com/rust-lang-nursery/rls which complies with this protocol and powers editor extensions that offers auto completion in VS Code, Visual Studio, Atom, [Neo]Vim, Emacs and any LSP-compliant editors.

We are starting from css but could look into html too. I have one question though:

Where is the data for item description (such as css properties)? mdn/data and mdn/browser-compat-data don't seem to contain them. From my understanding the "short description" seem to be a part of the wiki so maybe it's hard to put them into a JSON format, but I think having this data presented to the programmers right at their editor would offer them a great experience.

Here is issue tracking this in our side: microsoft/vscode-css-languageservice#68

Extend format of css/syntaxes.json to contain additional details

css/syntaxes.json is single file storing a string as value. It prevents us to add more details about syntax, e.g. Spec it defined or what it used for.

Any additional information can be useful. Sometimes is too hard to find details about property or syntax - and no clue what it uses for.

Suggestion is extend file format to contain not only syntax but additional details too.

(based on #8)

Add SVG data

It would be helpful to have also SVG related data.

Optimizers like svgo heavily use such data, see https://github.com/svg/svgo/blob/master/plugins/_collections.js .

Some svgo plugins also define extra data:

• https://github.com/svg/svgo/blob/master/plugins/removeUselessStrokeAndFill.js
• https://github.com/svg/svgo/blob/master/plugins/removeUnusedNS.js
• https://github.com/svg/svgo/blob/master/plugins/removeUnknownsAndDefaults.js
• https://github.com/svg/svgo/blob/master/plugins/_path.js
• https://github.com/svg/svgo/blob/master/plugins/_transforms.js
• https://github.com/svg/svgo/blob/master/plugins/convertStyleToAttrs.js
• https://github.com/svg/svgo/blob/master/plugins/cleanupNumericValues.js
• https://github.com/svg/svgo/blob/master/plugins/cleanupListOfValues.js

Further interesting data for SVG: Which attributes allow color-, dimension-, number-, string-, url-values?
This avoids blindly iterating over all values and trying to match them with multiple regexps for example.

css/properties.json is incomplete

Some properties that are missing from css/properties.json:

• justify-items
• justify-self

BiquadFilterNode constructor miss the Chrome note

Hi!

BiquadFilterNode's constructor (has a note for Chromes and Operas:
"[1] Before Chrome 59, the default values were not supported. "

I missed it during my review, hence this issue, sorry @chrisdavidmills.

Missing font-feature at-rules

https://github.com/mdn/browser-compat-data/blob/master/css/at-rules/font-feature-values.json has it all, however in here we don't have it: https://github.com/mdn/data/blob/master/css/at-rules.json

Improvements on at-rule syntax description

There are some syntax description issues in css/at-rule.json:

• @charset \"<charset>\"; is quite incorrect, should be @charset <string> ;
• @counter-style has a description of block, but declaration refers to wrong types (i.e. system: <counter-system>; but system key in descriptors)
• @font-face had a problem with wrong reference like in @counter-style syntax, but I fixed it in #221
• <group-rule-body> is wrong for the block of @viewport (should be a list of descriptors)

I think we need to change the description of @counter-style, @font-face and @viewport, since those at-rules have a limited list of descriptors and block syntax can be generated from a descriptors section. The rest at-rule descriptions should be revisited too.
I can bring a PR later if there is no blockers for changes (like MDN pages).

Attribute support by tag

The div tag for example does not support the color attribute, it would be ignored by browser.
Support data would be great!

Related issue: svg/svgo#823

ruby-position and ruby-merge are wrongly marked as standard

They are experimental: https://developer.mozilla.org/en-US/docs/Web/CSS/ruby-position
Spec is in Working Draft: https://www.w3.org/TR/css-ruby-1/

I don't think they should be considered standard.

<bg-layer> and <final-layer> formal syntax differs from W3C

See: https://bugzilla.mozilla.org/show_bug.cgi?id=1428255.

The data should probably match the W3C syntax.

Incorrect status on `gap`

I found the following entry in properties.json

  "gap": {
    "syntax": "<'row-gap'> <'column-gap'>?",
    "media": "visual",
    "inherited": false,
    "animationType": [
      "row-gap",
      "column-gap"
    ],
    "percentages": "no",
    "groups": [
      "CSS Box Alignment"
    ],
    "initial": [
      "row-gap",
      "column-gap"
    ],
    "appliesto": "gridContainers",
    "computed": [
      "row-gap",
      "column-gap"
    ],
    "order": "uniqueOrder",
    "status": "standard"
  },

However, there is no MDN page that corresponds to it.

I think this might be a non-standard property pre grid-gap. I think it should be either removed or marked as non-standard with a dedicating MDN page.

Remove 'document-url' keyword from 'content' property syntax

The document-url keyword was just removed from the content property.

Sebastian

Add CSS "functions" JSON file

Can we add a JSON file for CSS functions, e.g. linear-gradient(), element(), etc?

Among other things, this would allow us to define the syntax here in this repository, instead of hard-coding it into the MDN reference pages. I think it would also be a step towards allowing functions in the "CSSRef" macro (https://github.com/mdn/kumascript/blob/master/macros/CSSRef.ejs).

Remove nonstandard display properties

Per https://drafts.csswg.org/css-display/#changes, the display-inside, display-list, and display-outside properties are no longer part of the spec. Moreover, none of them were ever implemented in browsers, so far as I'm aware.

Can we also junk/delete their respective MDN pages?

• Delete properties from mdn/data.
• Delete the respective pages on MDN.

Split css/syntaxes.json into several files

Currently css/syntaxes.json contains syntaxes for values, selectors and at-rules. The problem is each type of syntax have its own grammar.

Note that the values related to at-rules are also syntaxes, and are even shared among at-rules and properties in some cases.

I talk about syntaxes that use non CSS Values and Units Module grammar, in particular:

• an-plus-b
• feature-type
• feature-value-block
• feature-value-declaration
• general-enclosed
• keyframe-block
• mf-plain
• mf-range
• page-body
• page-margin-box
• page-margin-box-type
• pseudo-page
• var

Suggestion is split css/syntax.json into three dictionaries, e.g. css/syntax-value.json, css/syntax-atrule.json and css/syntax-selector.json. As an alternative, format of css/at-rule.json and css/selectors.json can be change to host syntaxes too. And css/at-rule.json is already contain some syntaxes with description.

(based on #8)

Add schema files for validation purposes

As part of our testing and validation before committing changes to the data, we should be using a tool such as ajv to not only validate that our JSON is structurally sound, but that it matches the schemas for each of the databases we have here.

This would go a long way toward helping to ensure that our data is properly formatted and will reduce the back-and-forth during the PR process.

CSS items should only belong to a single group

@rachelandrew is working on sorting out the MDN docs on grid/flexbox/box alignment, and pointed out that the sidebars for these items don't make sense. It seems that part of the reason for this is that some of these items are marked as belonging to multiple "groups" in the metadata. I'd like to propose that we change the data so as to only allow an item to belong to a single group.

---

CSS data contains a property groups. The docs say:

groups (array of unique strings with at least 1 entry): CSS is organized in modules like "CSS Fonts" or "CSS Animations". MDN organizes features in these groups as well — groups should contain the name of the module(s) the property is defined in.

In most cases, groups only contains a single item, but in a few cases it contains more than one. For example, break-after:

"groups": [
    "CSS Columns",
    "CSS Fragmentation",
    "CSS Regions"
]

Unfortunately the macro used to build CSS sidebars on MDN, CSSRef.efs, isn't very good at dealing with this situation, and the sidebars tend to come out incoherent. Here's the structure of the sidebar for column-gap, with annotations to show its problems:

    CSS
    CSS Reference
    CSS Columns                                  <- this menu item has no children
    CSS Box Alignment
    -> Guides
        -> Using multi-column layouts            <- this should not be under box alignment
        -> Box Alignment In Grid Layout
        -> Box Alignment in Flexbox
        -> Box Alignment in Multi-column Layout
    -> Properties
        -> break-after
        -> break-before                          <- this should not be under box alignment, but it's here because of [this](https://github.com/mdn/data/blob/master/css/properties.json#L3315)
    ...
        -> column-count                          <- neither should this
    ...
        -> column-gap (grid-column-gap)
    ...

We could fix the macro here to handle multiple group better, but I'm starting to think that we would be better to say an item can only belong to a single group. If an item can only belong to one group, then the semantics are clear: it belongs to the group (aka module) whose spec currently defines it. If its definition moves from one spec to another (as, for example, align-items moving from flexbox to box alignment) then the group changes.

We could do this in the following stages:

1. clean the data so the groups array contains only one group. This would fix the sidebars, while not breaking any client which expects groups to be an array.
2. add a new property module which is a single string, and deprecate groups.
3. update any code that uses groups, to use module instead
4. remove groups

What do you think?

1. do you think only having one "group" is a good change?
2. do you currently use groups, and if so, are you able to update?

Question: Is there any api or way i can pull in some of the data json files?

Hi,

I would like to work on a small idea i have for a electron react app that pulls in a list of css color names and displays them. I see theres a data/css/syntaxes.json file here, and wondered if this data was accessible via a rest api somewhere?

Thanks,

How to represent token types/any-value in the schema

Some of the modern CSS syntax is somewhat hard to define inside our schema. See this conversation:

#186

Essentially, we need to decide on a way to represent token types/any-value in the schema, plus any other kinds of types that can't be represented using regular CSS formal syntax.

Normalize media field values in css/properties.json

media field contains strings only, but those strings have various meanings:

• media name
• comma separated list of media names
• special value (none, noPracticalMedia, visualInContinuousMediaNoEffectInOverflowColumns)

I'm suggesting to normalize values:

• left media name strings as is or convert it to single item array
• convert comma separated lists to arrays
• apply to special values solution from #61

Validate syntaxes

Hi!

Properties and selector syntaxes make use of lower-level syntaxes.

Unless they are "basic" types (that has their own page on MDN), these lower-level syntax are defined in syntaxes.json (and so on, recursively)

It is fastidious and error-prone to be sure not to forget one of these lower-level syntaxes definition. It is also complex for the reviewers to spot them.

We should write a test, run by ci that detect this.

Write docs about the CSS schemas / how to contribute

Currently, it is quite hard to contribute CSS data if you are not already an expert in CSS specs etc. Let's write docs about what the data actually means to ease contribution and reviewing.

(SMIL / begin/end) <begin-value-list>/<syncbase-value>

The syncbase value can references to an ID,
syncbase being one of the allowed values
of a <begin-value-list> (also applies to end attribute).

What kind of primitive is this?
Is this <ID>.<Component> syntax unique to syncbase value?

Also, is there a style-equivalent to this?

Organize enums in definitions.json

This got started by @SebastianZ in #99. Enums should be in definitions.json where they are available to all schema validations and not just to properties.schema.json. We also need to update the docs.

• Groups
• animationType
• percentages
• computed
• appliesto
• order
• Update docs to mention definitions.json

`place-items` property is missing

https://developer.mozilla.org/en-US/docs/Web/CSS/place-items

Publish to npm

In the spirit of other large datasets, such as caniuse, it would be really great to publish this data to npm as well. By doing so it would mean versioning the data so that any breaking changes could be handled in a developer's own time, rather than relying on the latest master branch from GitHub.

`image-resolution` is not `status: standard` yet

I cannot find existing MDN pages for it, but here is the spec: https://www.w3.org/TR/css-images-4/

It's still a working draft, which means this property should not be marked as standard.

CSS seems to be missing "speak"

Here's where the CSS standard is defined:

https://www.w3.org/TR/CSS21/aural.html#speaking-props

It's missing the following:

.foo{
  speak: none;
  speak: normal;
  speak: spell-out
}

Include MDN link in data

People using mdn/data to embed content in different applications might want to include a link to the docs page for the thing. To enable that we should include a link to the MDN page for the thing.

Note that browser-compat-data already does this via the mdn_url property: https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data.schema.json#L111-L115. I can't see any reason not to do exactly the same thing.

Acceptance criteria

• For all items in properties.json, selectors.json, atrules.json and types.json, if they have a corresponding MDN page, the item contains a link to the MDN page.

• Schemas and documentation are updated.

Suggestions on css/syntaxes.json

Currently css/syntaxes.json contains various types of syntaxes. Most of them are for values, rest are for at-rules and others. I believe those syntaxes should be stored in diferent dictionaries or have a special marker, since those syntaxes using diferrent grammar.

As we know this data was originally used on MDN. That's why some symbols like <, >, & and others were escaped (for safety inject to HTML documents I guess). Some syntaxes has <var> in their definition. It's verbose and doesn't need in non-HTML context. Mostly it can be automatically excaped when needed.

Probably format should be extended to store additional infomation about syntax as reference to spec, standart or not, etc.

Suggestions:

• split css/syntaxes.json into values syntaxes and something else (or move it to appropriate dictionary, e.g. to css/at-rules.json), or just remove non-value syntaxes away
• remove html-excaping from syntaxes (and from other fields, if possible, and in every files)
• extend dictionary format to store additional info

Parser for the value definition syntax?

The data contains a lot of syntax values not expanded into JSON which I guess is in value definition syntax. Is there a parser for this syntax available, either by MDN or otherwise?

Is color-adjust standardized?

I only found this page: https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-print-color-adjust

However the data says:

  "color-adjust": {
    "syntax": "economy | exact",
    "media": "visual",
    "inherited": true,
    "animationType": "discrete",
    "percentages": "no",
    "groups": [
      "CSS Color"
    ],
    "initial": "economy",
    "appliesto": "allElements",
    "computed": "asSpecified",
    "order": "perGrammar",
    "status": "standard"
  }

Can we have a MDN page for color-adjust, if it's standardized?

Many syntaxes removed / reverted to older versions

b021178 removed and reverted many syntaxes.

This change needs to be reverted.

Sebastian

Distinguish between simple and complex initial values in data/css/properties.json

In data/css/properties.json, the initial value can be:

1. A simple value, like 0, 0% 0%, none, or auto. This used to be wrapped like <code>0</code>
2. A key into l10n/css.json, like noneButOverriddenInUserAgentCSS or noPracticalInitialValue.
3. A list of strings, which are each one of the above. In practice, all current lists appear to be lists of literals.

I've proposed mdn/kumascript#162 to distinguish between cases 1 and 2, but it would be better to have a clearer signal in the data. Some straw man suggestions:

Different Keys for literal vs. prose initial values. Advantage - unambiguous. Disadvantage - users must update.

"align-self": {
    "initialLiteral": "auto"
},
"all": {
    "initialProse": "noPracticalInitialValue"
},
"animation": {
   "initialLiteral": [
      "animation-name",
      "animation-duration",
      "animation-timing-function",
      "animation-delay",
      "animation-iteration-count",
      "animation-direction",
      "animation-fill-mode",
      "animation-play-state"
    ]
}

Prefix for prose value, none for literals. Advantage - same key, quick check for literal vs prose. Disadvantage - pick a universal prefix, users must process to get prose key.

"align-self": {
    "initial": "auto"
},
"all": {
    "initial": "_prose_:noPracticalInitialValue"
},
"animation": {
   "initial": [
      "animation-name",
      "animation-duration",
      "animation-timing-function",
      "animation-delay",
      "animation-iteration-count",
      "animation-direction",
      "animation-fill-mode",
      "animation-play-state"
    ]
}

Initial objects instead of strings. Advantage - unambiguous, allows for future expansion, mixing literals and prose. Disadvantage - detect object vs list, overly wordy.

"align-self": {
    "initial": {
       "value": "auto",
       "type": "literal"
   }
},
"all": {
    "initial": {
       "value": "noPracticalInitialValue",
       "type": "prose"
   }
},
"animation": {
   "initial": [
          {"value": "animation-name", "type": "literal"},,
          {"value": "animation-duration", "type": "literal"},,
          {"value": "animation-timing-function", "type": "literal"},,
          {"value": "animation-delay", "type": "literal"},,
          {"value": "animation-iteration-count", "type": "literal"},,
          {"value": "animation-direction", "type": "literal"},,
          {"value": "animation-fill-mode", "type": "literal"},,
          {"value": "animation-play-state", "type": "literal"},
    ]
}

Consider using shepard (Bikeshed tool) to generate CSS data automatically

This was previously requested in bug 1189440.

The idea is to read the data defined in the CSS specifications to update the JSONs automatically using a tool called shepard:

https://api.csswg.org/shepherd/

Note from @teoli2003:

A priori this is a good idea (it could allow us to have the info before we create a CSS property page and remove the sync need to update CSSData), but we should consider several aspects:

• performance
• can we get all the info needed from it.
• do we need a way to override it (place we diverge from the standard)
• how to deal with pseudo-elements, descriptors, pseudo-classes...

But this is interesting.

Sebastian

Animation type of 'tab-size' is "length"

The animation type of the tab-size property has changed to "length". Though in the data it is marked as "discrete".

Sebastian

Bad value in `data/properties.json` for `border-image-outset`

Article border-image-outset displays a bad value as the "initial value". Article border-image displays the same bad value as initial value for "border-image-outset".

The bad value displayed is "0s". The correct value from "CSS Backgrounds and Borders Module Level 3" is "0". The reference section is 6.4. Edge Overhang: the border-image-outset property.

Both articles use the same macro to generate the displayed block, simply inserting {{cssinfo}}. The problem value can be found at

data/css/properties.json

Line 1714 in 9daccf9

"initial": "0s",

The value "0s" is found elsewhere describing 4 properties related to 'delay's or 'duration's, which may be where the mistaken copy-n-paste came from and an explanation for the spurious 's' (for seconds in those other places).

(I'd generate a PR but at the moment I am unable to test the results - it would be a 'blind' untested PR)