path: root/files/fr/mdn/structures/compatibility_tables/index.html

---
title: Tables de compatibilité
slug: MDN/Structures/Compatibility_tables
tags:
  - Compatibilité
  - Documentation
  - Guide
  - MDN
  - Navigateurs
translation_of: MDN/Structures/Compatibility_tables
original_slug: MDN/Structures/Tables_de_compatibilité
---
<div>{{MDNSidebar}}</div><div>{{IncludeSubnav("/en-US/docs/MDN")}}</div>

<p class="summary">MDN a un format standard pour les tables de compatibilité de notre documentation du web ouvert ; c'est-à-dire la documentation de technologies comme le DOM, HTML, CSS, JavaScript, SVG etc. partagées par tous les navigateurs. Cet article explique comment utiliser nos fonctionnalités pour ajouter des données de compatibilité aux pages MDN.</p>

<div class="warning">
<p><strong>Important </strong>: <strong><em>La façon dont les données sont générées a changé</em></strong>. Historiquement, nos tables ont été insérées sur la page et les données ont été renseignées manuellement. Ceci est inefficace, rend la maintenance difficile et rend les données inflexibles. Par conséquent, nous migrons les données de notre navigateur pour les stocker dans un référentiel de données (voir <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>) et générer les tables par programme.<br>
 <br>
 Dans ce guide, nous documentons la nouvelle façon d'ajouter des données aux tables de compatibilité pour MDN, mais nous avons conservé la documentation à l'ancienne, car vous pourrez voir des tables manuelles sur MDN pendant un moment. Si vous avez besoin de la documentation ancienne, voyez notre article <a href="https://developer.mozilla.org/fr/docs/MDN/Contribute/Structures/Old_compatibility_tables">Anciennes tables de compatibilité</a>.</p>
</div>

<div class="note">
<p><strong>Note </strong>: Si vous avez besoin d'aide sur les étapes de ce guide, n'hésitez pas à nous contacter sur le <a href="https://discourse.mozilla-community.org/c/mdn">forum de discussion MDN</a> (en).</p>
</div>

<h2 id="Comment_accéder_au_dépôt_de_données">Comment accéder au dépôt de données</h2>

<p>Les données sont stockées dans un dépôt de GitHub — voir <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>. Pour y accéder, vous devez obtenir un compte GitHub, réaliser une branche du browser-compat-data sur votre propre compte, puis cloner votre branche sur votre machine locale.</p>

<h2 id="Choisir_une_fonctionnalité_pour_y_ajouter_des_données">Choisir une fonctionnalité pour y ajouter des données</h2>

<p>Tout d'abord, cherchez une fonctionnalité pour laquelle vous souhaitez ajouter des données de navigateur. Cela peut être un élément HTML, une propriété CSS, une fonctionnalité du langage JS ou une interface d'API JS, par exemple. Nous aimerions vous encourager à travailler sur les fonctionnalités de l'API, car nous avons déjà des personnes travaillant sur HTML, JS et CSS. Vous pouvez trouver le statut des fonctionnalités qui ont besoin de leurs données en ajoutant au dépôt sur notre tableur <a href="https://docs.google.com/spreadsheets/d/1ivgyPBr9Lj3Wvj5kyndT1rgGbX-pGggrxuMtrgcOmjM/edit#gid=926663640">Browser Compat Data migration</a> (<em>migration des données des tables de compatibilité des navigateurs</em>).</p>

<p>Le processus d'utilisation est le suivant :</p>

<ol>
 <li>Allez-y et choisissez une fonctionnalité qui n'est pas déjà travaillée ou complète. Inscrivez votre nom dans la colonne "Who" (<em>qui</em>), de préférence avec votre nom d'utilisateur MDN afin que nous puissions trouver votre adresse e-mail et vous contacter si nécessaire.</li>
 <li>Si la fonctionnalité sur laquelle vous souhaitez travailler n'est pas déjà répertoriée dans la feuille de calcul, ajoutez-y des lignes à un emplacement approprié, en copiant le format qui s'y trouve déjà. Vous devez également utiliser la même granularité (par exemple, par élément pour HTML, par propriété ou sélecteur pour CSS, par objet pour JS, par interface pour API).</li>
 <li>Une fois que vous avez commencé à ajouter des données, mettez le statut "In progres" (<em>En cours</em>).</li>
 <li>Une fois que vous avez ajouté les données et soumis une demande d'extraction au dépôt principal, attribuez le statut "PR done".</li>
 <li>Au fur et à mesure que vos données sont fusionnées au rapport, ajoutées au paquet npm, mettez à jour le statut si nécessaire.</li>
 <li>Une fois que vous avez mis à jour les pages de documentation pour votre fonctionnalité afin d'utiliser la nouvelle macro pour générer dynamiquement la table de données appropriée sur chaque page, définissez l'état sur "Article mis à jour". À ce stade, vous avez terminé.</li>
</ol>

<h2 id="Préparation_à_lajout_de_données">Préparation à l'ajout de données</h2>

<p>Avant d'ajouter de nouvelles données, vous devez vous assurer que votre branche est à jour avec le dépôt principal (le même contenu), créer une nouvelle branche dans votre embranchement pour contenir vos ajouts, puis récupérer cette branche dans votre clone local pour pouvoir commencer à y travailler :</p>

<p>Regardons un moyen simple de nous assurer que votre fourche est à jour :</p>

<h3 id="Ajout_dun_remote_au_dépôt_principal_navigateur-compat-données">Ajout d'un "remote" au dépôt principal navigateur-compat-données</h3>

<p>Accédez à votre clone local de la branche dans votre terminal / ligne de commande, et ajoutez un"remote" pointant vers le dépôt principal (en amont) comme ceci (vous n'avez besoin de le faire qu'une seule fois):</p>

<pre class="brush: bash notranslate">git remote add upstream https://github.com/mdn/browser-compat-data.git</pre>

<p>Si vous n'êtes pas sûr d'y être parvenu, vous pouvez vérifier quels "remotes" votre dépôt utilise.</p>

<pre class="brush: bash notranslate">git remote -v</pre>

<h3 id="Mise_à_jour_de_votre_branche_avec_le_contenu_du_remote">Mise à jour de votre branche avec le contenu du "remote"</h3>

<p>Maintenant, chaque fois que vous voulez mettre à jour votre branche, vous pouvez le faire en :</p>

<ol>
 <li>
  <p>Vous assurant que vous êtes dans la branche maîtresse :</p>

  <pre class="brush: bash notranslate">      <code class="language-bash">git checkout master</code></pre>
 </li>
 <li>
  <p>Allant chercher le contenu du dépôt à jour avec la commande suivante :</p>

  <pre class="brush: bash notranslate">      <code class="language-bash">git fetch upstream</code></pre>
 </li>
 <li>
  <p>Rebasant le contenu de votre branche maîtresse avec le contenu du dépôt principal :</p>

  <pre class="brush: bash notranslate">      <code class="language-bash">git rebase upstream/master</code>    </pre>
 </li>
 <li>
  <p>poussant ces mises à jour de votre branche distante en utilisant ce :</p>

  <pre class="brush: bash notranslate">    <code class="language-bash">git push -f</code>
</pre>
 </li>
</ol>

<h3 id="Création_dune_nouvelle_branche_pour_y_travailler">Création d'une nouvelle branche pour y travailler</h3>

<p>Ensuite, allez sur votre fourche distante (elle doit être à <code>https://github.com/<em>your-username</em>/browser-compat-data</code>) et créer une nouvelle branche <span class="short_text" id="result_box" lang="fr"><span>pour stocker vos modifications pour cet ajout de données</span></span>. Ceci peut être fait en:</p>

<ol>
 <li>Cliquant sur le bouton "Branch: Master".</li>
 <li>Saisissant le nom de votre nouvelle branche dans le champ texte "Find or create a branch...".</li>
 <li>Cliquant sur le bouton "Create branch <em>name-of-branch</em> from Master" qui vient d'être généré.</li>
</ol>

<p>Par exemple, si vous vouliez ajouter des données pour l'API WebVR, vous devriez créer une branche nommée "webvr".</p>

<h3 id="Aller_sur_la_nouvelle_branche">Aller sur la nouvelle branche</h3>

<p>A ce stade, retournez dans votre terminal / ligne de commande, et mettez à jour la copie de votre fourche locale pour inclure votre nouvelle branche en utilisant la commande suivante:</p>

<pre class="brush: bash notranslate">git pull</pre>

<p>Maintenant allez sur votre nouvelle branche en utilisant:</p>

<pre class="brush: bash notranslate">git checkout <em>-b name-of-branch</em></pre>

<p>Vous devriez maintenant être prêt à ajouter vos données!</p>

<h2 id="Ajouter_les_données">Ajouter les données</h2>

<p>Pour ajouter les données, vous devez créer un ou des nouveaux fichiers pour y stocker les données de compatibilité. Les fichiers que vous devez créer diffèrent, selon la technologie sur laquelle vous travaillez:</p>

<ul>
 <li>HTML: Un fichier par élément HTML, contenu dans <a href="https://github.com/mdn/browser-compat-data/tree/master/html/elements">browser-compat-data/html/elements</a>. Le fichier doit être nommé avec le nom de l'élément, tout en minuscules, ex. <code>div.json</code>.</li>
 <li>CSS: Un fichier par propriété ou sélecteur CSS, contenu dans le répertoire approprié (voir <a href="https://github.com/mdn/browser-compat-data/tree/master/css">browser-compat-data/css</a>). Le fichier doit être nommé avec le nom de la fonctionnalité, tout en minuscules, ex. <code>background-color.json</code>, ou <code>hover.json</code>.</li>
 <li>JS: Un fichier par objet JS, contenu dans <a href="https://github.com/mdn/browser-compat-data/tree/master/javascript/builtins">browser-compat-data/javascript/builtins</a>. Le fichier doit être nommé avec le nom de l'objet, en respectant la casse, ex. <code>Date.json</code> ou <code>InternalError.json</code>.</li>
 <li>APIs: un fichier par interface contenu dans l'API, mis dans <a href="https://github.com/mdn/browser-compat-data/tree/master/api">browser-compat-data/api</a>. Chaque fichier doit être nommé avec le nom exact de l'interface, en respectant la casse, ex. L'API WebVR a <code>VRDisplay.json</code>, <code>VRDisplayCapabilities.json</code>, etc.</li>
</ul>

<div class="note">
<p><strong>Note</strong>: Vous remarquerez que le dépôt contient aussi des données pour les <a href="/fr/Add-ons/WebExtensions">Extensions de navigateurs</a> et pour <a href="/fr/docs/Web/HTTP">HTTP</a>. <span id="result_box" lang="fr"><span>Ces ensembles de données sont esssentiellement finis en l'état, mais il faudra peut-être ajouter d'autres fonctionnalités à l'avenir.</span></span></p>
</div>

<p>Chaque fichier que vous créez doit suivre le modèle défini dans le schéma contenu dans notre dépôt; vous pouvez voir la <a href="https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md">description détaillée du schema ici</a>.</p>

<h3 id="Structure_basique_des_données_de_compatibilité">Structure basique des données de compatibilité</h3>

<p>Prenons un exemple. Les fichiers JSON de propriété CSS ont par exemple besoin de la structure de base suivante:</p>

<pre class="brush: json notranslate">{
  "css": {
    "properties": {
      "border-width": {
        "__compat": {
          ...
        }
      }
    }
  }
}</pre>

<p>Vous avez l'objet <code>css</code>, à l'intérieur duquel vous avez l'objet <code>properties</code>. A l'intérieur de l'objet <code>properties</code>, vous avez besoin d'un membre pour chacunes des fonctionnalités  dont vous voulez définir les données. Chacun de ces membres a un membre <code>__compat</code>, à l'intérieur duquel les données vont.</p>

<p>Les données ci-dessus se trouvent dans le fichier <a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/border-width.json">border-width.json</a> — <span id="result_box" lang="fr"><span>comparez les à la </span></span> <a href="/fr/docs/Web/CSS/border-width#Compatibilit%C3%A9_des_navigateurs">table de support de border-width disponible sur MDN</a>.</p>

<p>D'autres types de fonctionnalités fonctionnent sur le même principe, mais avec des noms d'objets différents:</p>

<ul>
 <li>Les sélecteurs CSS fonctionnent essentiellement de la même manière que les proprités CSS, sauf que la structure de l'objet de plus haut niveau est <code>css.selectors</code> à la place de <code>css.properties</code>. Voir <a href="https://github.com/mdn/browser-compat-data/blob/master/css/selectors/cue.json">cue.json</a> pour un exemple.</li>
 <li>Les données HTML fonctionnent essentiellement de la même manière, sauf que la structure de l'objet de plus haut niveau est <code>html.elements</code>. Voir <code>article.json</code> pour un exemple.</li>
 <li>La structure d'objet de plus haut niveau pour les objets intégrés JS est <code>javascript.builtins</code>; voir <a href="https://github.com/mdn/browser-compat-data/blob/master/javascript/builtins/Array.json">Array.json</a> pour un exemple.</li>
</ul>

<div>
<p>Dans les pages HTML, CSS, et JS, vous n'avez normalement besoin que d'une seule fonctionnalité. Les interfaces d'API fonctionnent légèrement différement — elles ont toujours de multiples sous caractéristiques (voir {{anch("Sub-features")}}, ci-dessous).</p>

<h3 id="Structure_de_base_à_lintérieur_dune_fonctionnalité">Structure de base à l'intérieur d'une fonctionnalité</h3>

<p>Dans un membre <code>__compat</code>, vous devez inclure les membres suivants:</p>

<ul>
 <li><code>mdn_url</code>: Contient l'URL de la page de référence pour cette fonctionnalité sur MDN. Notez qu'elle doit être écrit sans le répertoire de la locale, ex. <code>/docs/...</code> et non <code>/docs/en-US/...</code> (ou autre). Il est ajouté par une macro lorsque les données sont mises sur la page, à des fins de localisation.</li>
 <li><code>support</code>: <span id="result_box" lang="fr"><span>Contient des membres indiquant les informations de support du navigateur pour cette fonctionnalité, dans les différents navigateurs que nous souhaitons indiquer.</span></span></li>
 <li><code>status</code>: Contient des membres indiquant l'état de suivi des normes pour cette fonctionnalité.</li>
</ul>

<p>Les noms des membres pour le navigateur sont définis dans le schéma (voir <a href="https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md#browser-identifiers">Browser identifiers</a>). Vous devez utiliser la liste complète des identifiants actuellement définis. Si vous souhaitez ajouter un navigateur, parlez-nous en d'abord, <span id="result_box" lang="fr"><span>car cela pourrait avoir un impact important et ne devrait pas être fait sans une réflexion approfondie.</span></span></p>

<p>Dans un fichier de base de compatibilité de navigateur, vous n'avez qu'à inclure "version_added" dans les membres de l'identifiant de navigateur (nous reviendrons plus tard sur {{anch("Advanced cases")}}). <span id="result_box" lang="fr"><span>Les différentes valeurs que vous pouvez inclure sont les suivantes:</span></span></p>

<ul>
 <li>Un numéro de version: Si vous connaissez la version exacte à partir de laquelle le navigateur supporte cette fonctionnalité, utilisez une chaîne de caractères représentant ce nombre, ex. "47".</li>
 <li><code>true</code>: Si un navigateur supporte la fonctionnalité mais que vous ne connaissez pas la version exacte, utilisez la valeur <code>true</code>. Ceci équivaut à l'appel de la macro  <code>\{{CompatVersionUnknown}}</code> dans les anciennes tables manuelles.</li>
 <li><code>false</code>: Si un navigateur ne supporte pas la fonctionnalité, utilisez la valeur <code>false</code>. Ceci équivaut à l'appel de la macro <code>\{{CompatNo}}</code> dans les anciennes tables manuelles.</li>
 <li><code>null</code>: Si vous ne savez pas si un navigateur supporte ou non une fonctionnalité, utilisez la valeur <code>null</code>. Ceci équivaut à l'appel de la macro <code>\{{CompatUnknown}}</code> dans les anciennes tables manuelles.</li>
</ul>

<p>A l'intérieur du membre <code>status</code>, vous inclurez trois sous-membres:</p>

<ul>
 <li> "experimental": Ceci doit être mis à <code>true</code> si la fonctionnalité est <a href="/en-US/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">expérimentale</a>, ou <code>false</code> dans les autres cas.</li>
 <li>"standard_track": Ceci doit être mis à <code>true</code> si la fonctionnalité est en cours de standardisation (le plus souvent W3C/WHATWG, mais il y a aussi d'autres efforts de standardisation tels que Khronos, TC39, etc.) ou <code>false</code> dans les autres cas.</li>
 <li>"deprecated": Ceci doit être mis à <code>true</code> si la fonctionnalité est <a href="/en-US/docs/MDN/Contribute/Guidelines/Conventions_definitions#Deprecated_and_obsolete">dépréciée</a>, ou <code>false</code> dans les autres cas.</li>
</ul>

<p>Les données pour la propriété <a href="/fr/docs/Web/CSS/border-width#Compatibilité des navigateurs">border-width</a> (voir aussi <a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/border-width.json">border-width.json</a>) sont présentées ci-dessous à titre d'exemple:</p>

<pre class="brush: json notranslate">"__compat": {
  "mdn_url": "https://developer.mozilla.org/docs/Web/CSS/border-width",
  "support": {
    "chrome": {
      "version_added": "1"
    },
    "webview_android": {
      "version_added": "2"
    },
    "edge": {
      "version_added": true
    },
    "edge_mobile": {
      "version_added": true
    },
    "firefox": {
      "version_added": "1"
    },
    "firefox_android": {
      "version_added": "1"
    },
    "ie": {
      "version_added": "4"
    },
    "ie_mobile": {
      "version_added": "6"
    },
    "opera": {
      "version_added": "3.5"
    },
    "opera_android": {
      "version_added": "11"
    },
    "safari": {
      "version_added": "1"
    },
    "safari_ios": {
      "version_added": "3"
    }
  },
  "status": {
    "experimental": false,
    "standard_track": true,
    "deprecated": false
  }
}</pre>

<h4 id="Ajouter_une_description">Ajouter une description</h4>

<p>Il y a un quatrième membre, optionnel, qui peut être placé à l'intérieur du membre __compat — <code>description</code>. Ceci peut être utilisé pour inclure une description, compréhensible par les humains, de cette fonctionnalité. Vous ne devez l'inclure que s'il est difficile de voir de quoi il s'agit en ne regardant que les données. Par exemple, il peut ne pas être évident qu'il s'agit d'un constructeur en ne regardant que la structure des données, vous pouvez donc ajouter une description comme:</p>

<pre class="brush: json notranslate">{
  "api": {
    "AbortController": {
      "__compat": {
        ...
      },
      "AbortController": {
        "__compat": {
          "mdn_url": "https://developer.mozilla.org/docs/Web/API/AbortController/AbortController",
          "description": "&lt;code&gt;AbortController()&lt;/code&gt; constructor",
          "support": {
            ...
          }
        }
      }

      ... etc.
    }
  }
}</pre>

<h3 id="Sub-features">Sub-features</h3>

<p>In a page where the compat table has more than one row, you'll need multiple subfeatures inside each feature to define the information for each row. This can happen, for example, when you've got the basic support for a feature stored in one row, but then the feature also has a new property or value type that was addded much later in the specification's life and is only supported in a couple of browsers.</p>

<p>As an example, see the <a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/background-color.json">compat data</a> and <a href="/en-US/docs/Web/CSS/background-color">corresponding MDN page</a> for the <code>background-color</code> property. The basic support exists inside the <code>__compat</code> object as explained above, then you have an additional row for browsers' support for "alpha channel for hex values", which contains its own <code>__compat</code> object.</p>

<pre class="brush: json notranslate">{
  "css": {
    "properties": {
      "background-color": {
        "__compat": {
          ...
        },
        "alpha_ch_for_hex": {
          "__compat": {
            ...
          },
        }
      }
    }
  }
}</pre>

<p>For an API, you've got the top two levels defined as <code>api.<em>name-of-the-interface</em></code>, then a top-level <code>__compat</code> section to define the overall browser compatibility of the interface, then a sub-feature for each of the methods, properties, and constructors contained inside the interface. The basic structure looks like this:</p>

<pre class="brush: json notranslate">{
  "api": {
    "VRDisplay": {
      "__compat": {
        ...
      },
      "cancelAnimationFrame": {
        "__compat": {
          ...
        }
      },
      "capabilities": {
        "__compat": {
          ...
        }
      },

      ... etc.

    }
  }
}</pre>

<p>See <a href="https://github.com/mdn/browser-compat-data/blob/master/api/VRDisplay.json">VRDisplay.json</a> for a full example.</p>
</div>

<h2 id="Adding_data_Advanced_cases">Adding data: Advanced cases</h2>

<p>There are some advanced features that you'll want to include in browser compat data. The aim of this section is to list the most common ones, providing an example of each to show how you can implement them in your own compat data.</p>

<h3 id="Including_a_footnote">Including a footnote</h3>

<p>Often compat tables will include footnotes related to certain entries that explain useful details or strange behavior that developers will find useful. As an example, the Chrome Android entry for {{domxref("VRDisplay.capabilities")}} (see also <a href="https://github.com/mdn/browser-compat-data/blob/master/api/VRDisplay.json">VRDisplay.json</a>)  (at the time of writing) had a footnote "<span class="pl-s">Currently supported only by Google Daydream." To include this in the capabilities data, we added a "notes" submember inside the relevant "chrome_android" submember; it would look like this:</span></p>

<pre class="brush: json notranslate">"chrome_android": {
  "version_added": true,
  "notes": "Currently supported only by Google Daydream."
}</pre>

<h3 id="Including_a_vendor_prefix">Including a vendor prefix</h3>

<p>If a feature is supported behind a vendor prefix in one or more browsers, you'll want to make that clear in the browser compat data. imagine you had a feature that was supported with a <code>-moz-</code> prefix in Firefox. To specify this in the compat data, you'd need to add a "prefix" submember inside the relevant "firefox" submember. It would look something like this:</p>

<pre class="brush: json notranslate">"firefox": {
  "version_added": true,
  "prefix": "-moz-"
}</pre>

<h3 id="Including_browser_preferences_or_flags">Including browser preferences or flags</h3>

<p>Some features may be supported in a browser, but they are experimental and turned off by default. If a user wants to play with this feature they need to turn it on using a preference/flag.</p>

<p>To represent this in the compat data, you need to add the "flags" submember inside the relevant browser identifier submember. The value of "flags" is an array of objects each of which contains of three members:</p>

<ul>
 <li>"type": The type of flag or pref this is. The most common value is "preference", which is set inside the browser (for example, using <code>about:config</code> in Firefox, or <code>chrome://flags</code> in Chrome), but you might also sometimes use a value of <span class="pl-s"><span class="pl-pds">"</span>compile_flag<span class="pl-pds">", which is a preference set when the browser build is compiled.</span></span></li>
 <li>"name": This is a string representing the name of the preference that needs to have a value set on it. For example, "Enable Experimental Web Platform Features" is a preference that exists in Chrome, found in <code>chrome://flags</code>.</li>
 <li>"value_to_set": This is a string representing the value that needs to be set on the preference, for example "true".</li>
</ul>

<p>So to add a preference/flag to the Chrome support for a feature, you'd do something like this:</p>

<pre class="brush: json notranslate">"chrome": {
  "version_added": "50",
  "flags": [
    {
      "type": "preference",
      "name": "Enable Experimental Web Platform Features",
      "value_to_set": "true"
    }
  ]
},</pre>

<p>If a feature is behind two or more flags, you can add additional objects to the "flags" array, like in this case, for example:</p>

<pre class="brush: json notranslate">"firefox": {
  "version_added": "57",
  "flags": [
    {
      "type": "preference",
      "name": "dom.streams.enabled",
      "value_to_set": "true"
    },
    {
      "type": "preference",
      "name": "javascript.options.streams",
      "value_to_set": "true"
    }
  ]
},</pre>

<h3 id="Including_a_version_where_support_was_removed">Including a version where support was removed</h3>

<p>Sometimes a feature will be added in a certain browser version, but then removed again as the feature is deprecated. This can be easily represented using the "version_removed" submember, which takes as its value a string representing the version number it was removed on. For example:</p>

<pre class="brush: json notranslate">"firefox": {
  "version_added": "35",
  "version_removed": "47",
},</pre>

<h3 id="Including_multiple_support_points_for_the_same_browser_entry">Including multiple support points for the same browser entry</h3>

<p>Sometimes you'll want to add multiple support data points for the same browser inside the same feature.</p>

<p>As an example, the {{cssxref("text-align-last")}} property (see also <a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/text-align-last.json">text-align-last.json</a>) was added to Chrome in version 35, supported behind a pref.</p>

<p>The support mentioned above was then removed in version 47; also in version 47, support was added for <code>text-align-last</code> enabled by default.</p>

<p>To include both of these data points, you can make the value of the "chrome" submember an array containing two support information objects, rather than just a single support information object:</p>

<pre class="brush: json notranslate">"chrome": [
  {
    "version_added": "47"
  },
  {
    "version_added": "35",
    "version_removed": "47",
    "flags": [
      {
        "type": "preference",
        "name": "Enable Experimental Web Platform Features",
        "value_to_set": "true"
      }
    ]
  }
],</pre>

<div class="note">
<p><strong>Note</strong>: You should put the most current or important support point first in the array — this makes the data easier to read for people who just want to scan it for the latest info.</p>
</div>

<h3 id="Including_an_alternative_name">Including an alternative name</h3>

<p>Occasionally browsers will support a feature under a different name to the name defined in its specification. This might be for example because a browser added experimental support for a feature early, and then the name changed before the spec stabilized.</p>

<p>To include such a case in the browser compat data, you can include a support information point that specifies the alternative name inside an "alternative_name" member.</p>

<div class="note">
<p><strong>Note</strong>: The alternative name might not be an exact alias — it might have differing behaviour to the standard version.</p>
</div>

<p>Let's look at an example. The {{cssxref("border-top-right-radius")}} property (see also <a href="https://github.com/mdn/browser-compat-data/blob/2a0cc3f6bb17aa4345441bed47a059dffd847793/css/properties/border-top-right-radius.json">border-top-right-radius.json</a>) was supported in Firefox:</p>

<ul>
 <li>From version 4 onwards with the standard name <code>border-top-right-radius</code>.</li>
 <li>From version 49 onwards with a <code>-webkit-</code> prefix, for browser compatibility purposes.</li>
 <li>From version 1 onwards with the alternative name <code>-moz-border-radius-topright</code>. Support for this alias was removed in version 12.</li>
</ul>

<p>To represent this in the data, we used the following JSON:</p>

<pre class="brush: json notranslate">"firefox": [
  {
    "version_added": "4",
    "notes": "Prior to Firefox 50.0, border styles of rounded corners were always rendered as if &lt;code&gt;border-style&lt;/code&gt; was solid. This has been fixed in Firefox 50.0."
  },
  {
    "prefix": "-webkit-",
    "version_added": "49",
    "notes": "From Firefox 44 to 48, the &lt;code&gt;-webkit-&lt;/code&gt; prefix was available with the &lt;code&gt;layout.css.prefixes.webkit&lt;/code&gt; preference. Starting with Firefox 49, the preference defaults to &lt;code&gt;true&lt;/code&gt;."
  },
  {
    "alternative_name": "-moz-border-radius-topright",
    "version_added": "1",
    "version_removed": "12"
  }
],</pre>

<h2 id="Pushing_a_change_back_to_the_main_repo">Pushing a change back to the main repo</h2>

<p>Once you are finished with adding your compat data, you should first test it using the following commands:</p>

<ul>
 <li><code>npm run lint</code> — tests all the compat data to make sure the JSON is valid, and is written in the correct style, for example correct indentation, no missing commas, etc. It will print out a long list of file names and test results; if an error is found, the linter will throw an error on the file it is found in, giving you useful debugging info like line number, error message, etc.</li>
 <li><code>npm run show-errors</code> — validates the JSON against the data schema, and highlights errors such as invalid browser version numbers being used.</li>
 <li><code>npm run render 'dotted.path.to.feature'</code> — allows you to preview the markup for the compat table for a data file in the repo. As an example, <code>npm run render 'css.properties.background'</code> shows the table markup for the {{cssxref("background")}} property.</li>
</ul>

<p>If it is looking OK, you then need to commit it and push it back up to your remote fork on GitHub. You can do this easily with terminal commands like this:</p>

<pre class="brush: bash notranslate">git add .
git commit -m 'adding compat data for name-of-feature'
git push</pre>

<p>Now go to your remote fork (i.e. <code>https://github.com/<em>your-username</em>/browser-compat-data</code>) and you should see information about your push at the top of the files list (under "Your recently pushed branches"). You can create a pull request (starting the process of pushing this to the main repo) by pressing the "Compare &amp; pull request" button, then following the simple prompts on the subsequent screen.</p>

<p>At this point, you just need to wait. A reviewer will review your pull request, and merge it with the main repo, OR request that you make changes. If changes are needed, make the changes and submit again until the PR is accepted.</p>

<h2 id="Inserting_the_data_into_MDN_pages">Inserting the data into MDN pages</h2>

<p>Once your new data has been included in the main repo, you can start dynamically generating browser compat tables based on that data on MDN pages using the \{{Compat}} macro. This takes a single parameter, the dot notation required to walk down the JSON data and find the object representing the feature you want to generate the compat table for.</p>

<p>Above the macro call, to help other contributors finding their way, you should add a hidden text that is only visible in MDN contributors in edit mode:</p>

<pre class="brush: html notranslate">&lt;div class="hidden"&gt;
&lt;p&gt;The compatibility table on this page is generated from structured data.
If you'd like to contribute to the data, please check out
&lt;a href="https://github.com/mdn/browser-compat-data"&gt;https://github.com/mdn/browser-compat-data&lt;/a&gt;
and send us a pull request.&lt;/p&gt;
&lt;/div&gt;</pre>

<p>As an example, on the {{httpheader("Accept-Charset")}} HTTP header page, the macro call looks like this: \{{Compat("http.headers.Accept-Charset")}}. If you look at the <a href="https://github.com/mdn/browser-compat-data/blob/master/http/headers/accept-charset.json">accept-charset.json</a> file in the repo, you'll see how this is reflected in the JSON data.</p>

<p>As another example, The compat table for the {{domxref("VRDisplay.capabilities")}} property is generated using \{{Compat("api.VRDisplay.capabilities")}}. The macro call generates the following table (and corresponding set of notes):</p>

<hr>

<p>{{Compat("api.VRDisplay.capabilities")}}</p>

<div class="note">
<p><strong>Note</strong>: The filenames often match the labels given to the interfaces inside the JSON structures, but it is not always the case. When the macro calls generate the tables, they walk through all the files until they find the relevant JSON to use, so the filenames are not critical. Saying that, you should always name them as intuitively as possible.</p>
</div>