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

---
title: >-
  Tablas de compatibilidad y repositorio de datos de compatibilidad del
  navegador (DCN)
slug: MDN/Structures/Tablas_de_compatibilidad
tags:
  - Estructuras
  - Guía
  - Meta MDN
  - compatibilidad con el navegador
  - tablas de compatibilidad
translation_of: MDN/Structures/Compatibility_tables
---
<div>{{MDNSidebar}}</div>

<p class="summary"><span class="seoSummary">MDN tiene un formato estándar para tablas de compatibilidad para nuestra documentación web abierta; es decir, documentación de tecnologías como DOM, HTML, CSS, JavaScript, SVG, etc., que se comparte en todos los navegadores.</span> Este artículo es una guía de "introducción" sobre cómo agregar y mantener la base de datos a partir de la cual se generan las tablas de compatibilidad, además de cómo integrar las tablas en artículos.</p>

<p class="summary">Para obtener documentación más avanzada, así como los últimos cambios en los procesos y los esquemas JSON utilizados para representar los datos, échale un vistazo al repositorio de datos de la <a href="https://github.com/mdn/browser-compat-data/blob/master/docs/contributing.md">guía para colaboradores</a>, así como a la <a href="https://github.com/mdn/browser-compat-data/blob/master/docs/data-guidelines.md">guía de directrices de datos</a>.</p>

<p class="summary">Si tienes preguntas o descubres problemas, compártelos con nosotros en el <a href="https://discourse.mozilla-community.org/c/mdn">foro de discusión de MDN</a>.</p>

<h2 id="Cómo_acceder_al_repositorio_de_datos">Cómo acceder al repositorio de datos</h2>

<p>Los datos se almacenan en un repositorio de GitHub; consulta <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>. Para acceder a él, necesitas tener una cuenta de GitHub, bifurcar el repositorio de compatibilidad de datos del navegador en tu propia cuenta y luego clonar tu bifurcación en tu máquina local.</p>

<h2 id="Preparándose_para_agregar_los_datos">Preparándose para agregar los datos</h2>

<p>Antes de agregar algunos datos nuevos, te debes asegurar de que tu bifurcación esté actualizada con el repositorio principal (contiene el mismo contenido), crea una nueva rama dentro de tu bifurcación para contener tus adiciones, luego ingresa esa rama en tu clon local para que puedas empezar a trabajar dentro de ella:</p>

<p>Veamos la siguiente sencilla forma de asegurarte de que tu bifurcación esté actualizada:</p>

<h3 id="Agregar_el_repositorio_principal_de_datos_de_compatibilidad_del_navegador_como_remoto">Agregar el repositorio principal de datos de compatibilidad del navegador como remoto</h3>

<p>Ve al clon local de tu bifurcación en tu terminal/línea de comandos, y agrega un control remoto que apunte al repositorio principal (<code>upstream</code>) de esa manera (solo necesitas hacer esto una vez):</p>

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

<p>Si no estás seguro de haber hecho esto, puedes verificar qué controles remotos tiene tu repositorio usando</p>

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

<h3 id="Actualiza_tu_bifurcación_con_el_contenido_del_remoto">Actualiza tu bifurcación con el contenido del remoto</h3>

<p>Ahora, siempre que desees actualizar tu bifurcación, lo puedes hacer mediante:</p>

<ol>
 <li>
  <p>Asegúrate de que estas en la rama <code>master</code>:</p>

  <pre class="brush: bash notranslate">git checkout master</pre>
 </li>
 <li>
  <p>obtén el contenido actualizado del repositorio utilizando lo siguiente:</p>

  <pre class="brush: bash notranslate">git fetch upstream</pre>
 </li>
 <li>
  <p>rebasa el contenido de tu <code>master</code> con el contenido del repositorio principal:</p>

  <pre class="brush: bash notranslate">git rebase upstream/master</pre>
 </li>
 <li>
  <p>empuja estas actualizaciones a tu bifurcación remota usando lo siguiente:</p>

  <pre class="brush: bash notranslate">git push</pre>
 </li>
</ol>

<h3 id="Crea_una_nueva_rama_para_hacer_tu_trabajo">Crea una nueva rama para hacer tu trabajo</h3>

<p>A continuación, ve a tu bifurcación remota (estará en <code>https://github.com/<em>tu-nombre-de-usuario</em>/browser-compat-data</code>) y crea una nueva rama para almacenar tus cambios para esta adición de datos. Esto lo puedes hacer mediante:</p>

<ol>
 <li>Un clic en el botón "Rama: Master".</li>
 <li>Ingresa un nuevo nombre para la rama en el campo de texto "Buscar o crear una rama...".</li>
 <li>Presiona el botón resultante "Crear rama <em>nombre-de-rama</em> desde Master".</li>
</ol>

<p>Por ejemplo, si quisieras agregar datos para la API WebVR, crearías una rama llamada algo así como "webvr".</p>

<h3 id="Cambia_a_la_nueva_rama">Cambia a la nueva rama</h3>

<p>En este punto, regresa a tu terminal/línea de comando y actualiza el clon local de tu bifurcación para incluir tu nueva rama usando el siguiente comando:</p>

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

<p>Ahora cambia a tu nueva rama usando esto:</p>

<pre class="brush: bash notranslate">git checkout <em>nombre-de-rama</em></pre>

<p>¡Ahora debería estar listo para comenzar a agregar tus datos!</p>

<h2 id="Añadir_los_datos">Añadir los datos</h2>

<p>Para agregar los datos, debes crear un nuevo archivo o archivos para almacenar tus datos de compatibilidad. Los archivos que necesitas crear difieren, según la tecnología en la que estés trabajando:</p>

<ul>
 <li><strong><a href="/es/docs/Web/HTML">HTML</a>:</strong> Un archivo por elemento HTML, contenido en <a href="https://github.com/mdn/browser-compat-data/tree/master/html/elements">browser-compat-data/html/elements</a>. El archivo se debe denominar con el nombre del elemento, todo en minúsculas, p. ej. <code>div.json</code>.</li>
 <li><strong><a href="/es/docs/Web/CSS">CSS</a>:</strong>Un archivo por propiedad CSS o selector, contenido en el directorio apropiado (consulta <a href="https://github.com/mdn/browser-compat-data/tree/master/css">browser-compat-data/css</a>). El archivo debe tener el nombre de la función, todo en minúsculas, p. ej. <code>background-color.json</code> o <code>hover.json</code>.</li>
 <li><strong><a href="/es/docs/Web/JavaScript">JS</a>:</strong> Un archivo por objeto JS, contenido en <a href="https://github.com/mdn/browser-compat-data/tree/master/javascript/builtins">browser-compat-data/javascript/builtins</a>. El archivo se debe denominar con el nombre exacto del objeto, conservando la envoltura, p. ej. <code>Date.json</code> o <code>InternalError.json</code>.</li>
 <li><strong><a href="/es/docs/Web/API">APIs</a>:</strong> Un archivo por interfaz contenida en la API, ponlo en <a href="https://github.com/mdn/browser-compat-data/tree/master/api">browser-compat-data/api</a>. Cada archivo se debe denominar con el nombre exacto de la interfaz, conservando la envoltura, p. ej. La API de WebVR tiene <code>VRDisplay.json</code>, <code>VRDisplayCapabilities.json</code>, etc.</li>
</ul>

<p>Cada archivo que crees debe seguir el patrón definido en el esquema contenido en nuestro repositorio; puedes ver la <a href="https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md">descripción detallada del esquema aquí</a>.</p>

<h3 id="Estructura_básica_de_datos_de_compatibilidad">Estructura básica de datos de compatibilidad</h3>

<p>Veamos un ejemplo. Los archivos JSON de propiedades CSS, por ejemplo, necesitan la siguiente estructura básica:</p>

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

<p>Tienes el objeto <code>css</code>, dentro del cual hay un objeto <code>properties</code>. Dentro del objeto <code>properties</code>, necesitas un miembro para cada una de las características específicas para las que deseas definir los datos de compatibilidad. Cada uno de estos miembros tiene un miembro <code>__compat</code>, dentro del cual van los datos reales.</p>

<p>Los datos anteriores se encuentran en el archivo: <a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/border-width.json">border-width.json</a> compáralo con la <a href="/es/docs/Web/CSS/border-width#Browser_compatibility">tabla de soporte de <code>border-width</code> representada en MDN</a>.</p>

<p>Otros tipos de características funcionan de la misma manera, pero con diferentes nombres de objeto:</p>

<ul>
 <li>Los selectores de CSS funcionan básicamente de la misma manera que las propiedades de CSS, excepto que la estructura del objeto de nivel superior es <code>css.selectors</code> en lugar de <code>css.properties</code>. Consulta <a href="https://github.com/mdn/browser-compat-data/blob/master/css/selectors/cue.json">cue.json</a> para ver un ejemplo.</li>
 <li>Los datos HTML funcionan básicamente de la misma manera, excepto que la estructura del objeto de nivel superior es <code>html.elements</code>. Consulta <a href="https://github.com/mdn/browser-compat-data/blob/master/html/elements/article.json">article.json</a> para ver un ejemplo.</li>
 <li>La estructura del objeto de nivel superior para los objetos incorporados de JS es <code>javascript.builtins</code>; consulta <a href="https://github.com/mdn/browser-compat-data/blob/master/javascript/builtins/Array.json">Array.json</a> para ver un ejemplo.</li>
</ul>

<div>
<p>En páginas HTML, CSS y JS, normalmente solo necesitarás una función. Las interfaces de API funcionan de forma ligeramente diferente — siempre tienen varias subcaracterísticas (consulta {{anch("Sub-features", "Subcaracterísticas")}}, a continuación).</p>

<h3 id="Estructura_básica_dentro_de_una_característica">Estructura básica dentro de una característica</h3>

<p>Dentro de un miembro de función <code>__compat</code>, debes incluir los siguientes miembros:</p>

<ul>
 <li><code>mdn_url</code>: contiene la URL de la página de referencia para esta característica en MDN. Ten en cuenta que esto se debe escribir sin el directorio de configuración regional dentro, p. ej. <code>/docs/...</code> no <code>/en-US/docs/...</code>. Esto lo agrega la macro cuando los datos se colocan en la página, con fines de localización.</li>
 <li><code>support</code>: contiene miembros que representan la información de soporte del navegador para esta característica en todos los diferentes navegadores que queremos informar.</li>
 <li><code>status</code>: contiene miembros que informan sobre el estado de seguimiento de estándares de esta característica.</li>
</ul>

<p>Los nombres de los miembros del navegador se definen en el esquema (consulta <a href="https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md#browser-identifiers">identificadores del navegador</a>). Debes utilizar la lista completa de identificadores definidos actualmente. Si deseas agregar otro navegador, habla con nosotros primero, ya que esto podría tener un impacto de gran alcance y no se debe hacer sin pensarlo detenidamente.</p>

<p>En un archivo de datos de compatibilidad del navegador básico, solo necesitarás incluir "<code>version_added</code>" dentro de los miembros del identificador del navegador (cubriremos {{anch("Advanced cases", "Casos avanzados")}} más adelante). Los diferentes valores que posiblemente quieras incluir son los siguientes:</p>

<ul>
 <li>Un número de versión: Si conoces la versión exacta en la que un navegador comenzó a admitir tu característica, usa una cadena que represente el número, p. ej. <code>"47"</code>.</li>
 <li><code>true</code>: Si un navegador admite una característica, pero no conoces el número de versión exacto, utiliza el valor <code>true</code>.</li>
 <li><code>false</code>: Si un navegador no admite una característica, utiliza el valor <code>false</code>.</li>
 <li><code>null</code>: Si no sabes si un navegador admite una característica o no, utiliza el valor <code>null</code>.</li>
</ul>

<p>Dentro del miembro <code>status</code>, incluirás tres submiembros:</p>

<ul>
 <li><code>experimental</code>: Se debe establecer en <code>true</code> si la característica es <a href="/es/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">experimental</a> o <code>false</code> en caso contrario.</li>
 <li><code>standard_track</code>: Esto se debe establecer en <code>true</code> si una característica está en algún tipo de pista de estándares (comúnmente W3C/WHATWG, pero también hay otros esfuerzos de estándares como Khronos, TC39, etc.) o <code>false</code> de lo contrario.</li>
 <li><code>deprecated</code>: Se debe establecer en <code>true</code> si la característica está <a href="/es/docs/MDN/Contribute/Guidelines/Conventions_definitions#Deprecated_and_obsolete">desaprobada</a> o <code>false</code> en caso contrario.</li>
</ul>

<p>Los datos de características de <a href="/es/docs/Web/CSS/border-width#Browser_compatibility"><code>border-width</code></a> (consulta también <a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/border-width.json">border-width.json</a>) se muestra a continuación como ejemplo:</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="Agrega_una_descripción">Agrega una descripción</h4>

<p>Hay un cuarto miembro, opcional, que puede ir dentro del miembro <code>__compat</code> — <code>description</code>. Este se puede utilizar para incluir una descripción legible por humanos de la característica. Únicamente lo debes incluir si es difícil ver cuál es la característica al mirar los datos. Por ejemplo, puede que no sea tan obvio lo que es un constructor al mirar la estructura de datos, por lo que puedes incluir una descripción como esta:</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="Subcaracterísticas">Subcaracterísticas</h3>

<p>En una página donde la tabla de compatibilidad tiene más de una fila, necesitarás varias subcaracterísticas dentro de cada característica para definir la información de cada fila. Esto puede suceder, por ejemplo, cuando tienes el soporte básico para una característica almacenada en una fila, pero luego la característica también tiene una nueva propiedad o tipo de valor que se agregó mucho más tarde en la vida de la especificación y solo se admite en una par de navegadores.</p>

<p>Como ejemplo, consulta los <a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/background-color.json">datos de compatibilidad</a> y la <a href="/es/docs/Web/CSS/background-color">página MDN correspondiente</a> para la propiedad <code>background-color</code>. El soporte básico existe dentro del objeto <code>__compat</code> como se explicó anteriormente, luego tienes una fila adicional para el soporte de los navegadores para "canal alfa para valores hexadecimales", que contiene tu propio objeto <code>__compat</code>.</p>

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

<p>Para una API, tienes los dos niveles superiores definidos como <code>api.<em>nombre-de-la-interfaz</em></code>, luego un <code>__compat</code> de nivel superior para definir la compatibilidad general del navegador de la interfaz, luego una subfunción para cada uno de los métodos, propiedades y constructores contenidos dentro de la interfaz. La estructura básica se ve así:</p>

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

      ... etc.

    }
  }
}</pre>

<p>Consulta <a href="https://github.com/mdn/browser-compat-data/blob/master/api/VRDisplay.json">VRDisplay.json</a> para ver un ejemplo completo.</p>
</div>

<h2 id="Agregar_datos_casos_avanzados">Agregar datos: casos avanzados</h2>

<p>Hay algunas características avanzadas que querrás incluir en los datos de compatibilidad del navegador. El objetivo de esta sección es enumerar los más comunes, proporcionando un ejemplo de cada uno para mostrar cómo los puedes implementar en tus propios datos de compatibilidad.</p>

<h3 id="Incluyendo_una_nota_a_pie_de_página">Incluyendo una nota a pie de página</h3>

<p>A menudo, las tablas de compatibilidad incluirán notas a pie de página relacionadas con ciertas entradas que explican detalles útiles o comportamientos extraños que los desarrolladores encontrarán útiles. Como ejemplo, la entrada de Chrome para Android para {{domxref("VRDisplay.capabilities")}} (consulta también <a href="https://github.com/mdn/browser-compat-data/blob/master/api/VRDisplay.json">VRDisplay.json</a>) (en el momento de escribir este artículo) tenía una nota al pie de página "Actualmente solo es compatible con Google Daydream". Para incluir esto en los datos de capacidades, agregamos un submiembro "<code>notes</code>" dentro del submiembro "chrome_android" relevante; se vería así:</p>

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

<h3 id="Incluyendo_un_prefijo_de_proveedor">Incluyendo un prefijo de proveedor</h3>

<p>Si una característica es compatible con un prefijo de proveedor en uno o más navegadores, querrás dejarlo en claro en los datos de compatibilidad del navegador. imagina que tienes una característica que es compatible con un prefijo <code>-moz-</code> en Firefox. Para especificar esto en los datos de compatibilidad, debes agregar un submiembro "<code>prefix</code>" dentro del submiembro "firefox" relevante. Y se vería así:</p>

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

<h3 id="Incluyendo_preferencias_o_banderas_del_navegador">Incluyendo preferencias o banderas del navegador</h3>

<p>Algunas características pueden ser compatibles con un navegador, pero son experimentales y están desactivadas de forma predeterminada. Si un usuario quiere jugar con esta característica, debe activarla usando una preferencia/bandera.</p>

<p>Para representar esto en los datos de compatibilidad, debes agregar el submiembro "<code>flags</code>" dentro del submiembro del identificador del navegador relevante. El valor de "<code>flags</code>" es un arreglo de objetos, cada uno de los cuales contiene tres miembros:</p>

<ul>
 <li><code>type</code>: Qué tipo de bandera o preferencia es. El valor más común es "<code>preference</code>", que se establece dentro del navegador (por ejemplo, usando <code>about: config</code> en Firefox, o <code>chrome://flags</code> en Chrome), pero a veces también puedes usar un valor de "<code>compile_flag</code>", que es un conjunto de preferencias cuando se construye la compilación del navegador.</li>
 <li><code>name</code>: Esta es una cadena que representa el nombre de la preferencia que necesita tener un valor establecido. Por ejemplo, "Habilitar funciones experimentales de la plataforma web" es una preferencia que existe en Chrome, que se encuentra en <code>chrome://flags</code>.</li>
 <li><code>value_to_set</code>: Esta es una cadena que representa el valor que se debe establecer en la preferencia, por ejemplo, "<code>true</code>".</li>
</ul>

<p>Entonces, para agregar una preferencia/bandera al soporte de Chrome para una característica, harías algo como esto:</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>Si una característica está detrás de dos o más banderas, puedes agregar objetos adicionales al arreglo "<code>flags</code>", como en este caso, por ejemplo:</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="Incluyendo_una_versión_donde_se_eliminó_el_soporte">Incluyendo una versión donde se eliminó el soporte</h3>

<p>A veces, una característica se agregará en una determinada versión del navegador, pero luego se eliminará nuevamente cuando la característica esté obsoleta. Esto se puede representar fácilmente usando el submiembro "<code>version_removed</code>", que toma como valor una cadena que representa el número de versión en el que se eliminó. Por ejemplo:</p>

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

<h3 id="Incluyendo_múltiples_puntos_de_soporte_para_la_misma_entrada_del_navegador">Incluyendo múltiples puntos de soporte para la misma entrada del navegador</h3>

<p>A veces, querrás agregar varios puntos de datos de soporte para el mismo navegador dentro de la misma característica.</p>

<p>Como ejemplo, la propiedad {{cssxref("text-align-last")}} (ve también <a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/text-align-last.json">text-align-last.json</a>) se agregó a Chrome en la versión 35, compatible con una pref.</p>

<p>El soporte mencionado anteriormente se eliminó en la versión 47; también en la versión 47, se agregó soporte para <code>text-align-last</code> habilitado de manera predeterminada.</p>

<p>Para incluir estos dos puntos de datos, puedes hacer que el valor del submiembro "<code>chrome</code>" sea un arreglo que contenga dos objetos de información de soporte, en lugar de un solo objeto de información de soporte:</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="blockIndicator note">
<p><strong>Nota</strong> Debes colocar el punto de soporte más actual o importante primero en el arreglo — esto hace que los datos sean más fáciles de leer para las personas que solo desean escanearlos para obtener la información más reciente.</p>
</div>

<h3 id="Incluyendo_un_nombre_alternativo">Incluyendo un nombre alternativo</h3>

<p>Ocasionalmente, los navegadores admitirán una característica con un nombre diferente al definido en su especificación. Esto se podría deber, por ejemplo, a que un navegador agregó soporte experimental para una característica antes, y luego el nombre cambió antes de que se estabilizara la especificación.</p>

<p>Para incluir un caso de este tipo en los datos de compatibilidad del navegador, puedes incluir un punto de información de soporte que especifique el nombre alternativo dentro de un miembro "<code>alternative_name</code>".</p>

<div class="blockIndicator note">
<p><strong>Nota</strong> Es posible que el nombre alternativo no sea un alias exacto — posiblemente tenga un comportamiento diferente al de la versión estándar.</p>
</div>

<p>Veamos un ejemplo. La propiedad {{cssxref("border-top-right-radius")}} (consulta también <a href="https://github.com/mdn/browser-compat-data/blob/2a0cc3f6bb17aa4345441bed47a059dffd847793/css/properties/border-top-right-radius.json">border-top-right-radius.json</a>) era compatible con Firefox:</p>

<ul>
 <li>Desde la versión 4 en adelante con el nombre estándar <code>border-top-right-radius</code>.</li>
 <li>A partir de la versión 49 con un prefijo <code>-webkit-</code>, por motivos de compatibilidad con el navegador.</li>
 <li>Desde la versión 1 en adelante con el nombre alternativo <code>-moz-border-radius-topright</code>. La compatibilidad con este alias se eliminó en la versión 12.</li>
</ul>

<p>Para representar esto en los datos, usamos el siguiente JSON:</p>

<pre class="brush: json notranslate">"firefox": [
  {
    "version_added": "4",
    "notes": "Antes de Firefox 50.0, los estilos de borde de las esquinas redondeadas siempre se representaban como si <code>border-style</code> fuera sólido. Esto se ha solucionado en Firefox 50.0."
  },
  {
    "prefix": "-webkit-",
    "version_added": "49",
    "notes": "De Firefox 44 a 48, el prefijo <code>-webkit-</code> estaba disponible con la preferencia <code>layout.css.prefixes.webkit</code>. A partir de Firefox 49, la preferencia predeterminada es &lt;code&gt;true&lt;/code&gt;."
  },
  {
    "alternative_name": "-moz-border-radius-topright",
    "version_added": "1",
    "version_removed": "12"
  }
],</pre>

<h2 id="Empujar_un_cambio_de_nuevo_al_repositorio_principal">Empujar un cambio de nuevo al repositorio principal</h2>

<p>Una vez que hayas terminado de agregar tus datos de compatibilidad, primero debes probarlos usando los siguientes comandos:</p>

<ul>
 <li><code>npm run lint</code> — prueba todos los datos de compatibilidad para asegurarse de que el JSON sea válido y esté escrito en el estilo correcto, por ejemplo, sangría correcta, sin comas, etc. Imprimirá una larga lista de nombres de archivos y resultados de pruebas; si se encuentra un error, el linter arrojará un error en el archivo en el que se encuentra, brindándote útil información de depuración como número de línea, mensaje de error, etc.</li>
 <li><code>npm run show-errors</code> — valida el JSON con el esquema de datos y resalta errores como el uso de números de versión de navegador no válidos.</li>
</ul>

<p>Si se ve bien, debes confirmarlo y volver a colocarlo en tu bifurcación remota en GitHub. Lo puedes hacer fácilmente en tu terminal con comandos como estos:</p>

<pre class="brush: bash notranslate">git add .
git commit -m 'adding compat data for <em>nombre-de-la-característica</em>'
git push</pre>

<p>Ahora ve a tu bifurcación remota (es decir, <code>https://github.com/<em>tu-nombre-de-usuario</em>/browser-compat-data</code>) y deberías ver información sobre tu inserción en la parte superior de la lista de archivos (debajo de "Tus ramas enviadas recientemente"). Puedes crear una solicitud de extracción (iniciando el proceso de enviarla al repositorio principal) presionando el botón "Comparar y solicitud de extracción" y luego siguiendo las sencillas instrucciones en la siguiente pantalla.</p>

<p>En este punto, solo tienes que esperar. Un revisor examinará tu solicitud de extracción y la fusionará con el repositorio principal, O solicitará que realices cambios. Si se necesitan cambios, realiza los cambios y envíalos nuevamente hasta que se acepte la SE.</p>

<h2 id="Insertar_los_datos_en_páginas_MDN">Insertar los datos en páginas MDN</h2>

<p>Una vez que tus nuevos datos se hayan incluido en el repositorio principal, puedes comenzar a generar dinámicamente tablas de compatibilidad del navegador basadas en esos datos en las páginas MDN usando la macro {{TemplateLink("Compat")}}. Esta toma un solo parámetro, la notación de puntos requerida para recorrer los datos JSON y encontrar el objeto que representa la característica para la que deseas generar la tabla de compatibilidad.</p>

<p>Por encima de la llamada a la macro, para ayudar a otros colaboradores a encontrar su camino, debes agregar un texto oculto que solo sea visible a los colaboradores de MDN en el modo de edición:</p>

<pre class="brush: html notranslate">&lt;div class="hidden"&gt;
La tabla de compatibilidad de esta página se genera a partir de datos estructurados.
Si deseas contribuir con los datos, consulta
&lt;a href="https://github.com/mdn/browser-compat-data"&gt;https://github.com/mdn/browser-compat-data&lt;/a&gt;
y envíanos una solicitud de extracción.
&lt;/div&gt;</pre>

<p>Por ejemplo, en la página de encabezado HTTP {{HTTPHeader("Accept-Charset")}}, la llamada a la macro se ve así: <code>\{{Compat("http.headers.Accept-Charset")}}</code>. Si observas el <a href="https://github.com/mdn/browser-compat-data/blob/master/http/headers/accept-charset.json">accept-charset.json</a> en el repositorio, verás cómo esto se refleja en los datos JSON.</p>

<p>Otro ejemplo, la tabla de compatibilidad para la propiedad {{domxref("VRDisplay.capabilities")}} se genera usando <code>\{{Compat("api.VRDisplay.capabilities")}}</code>. La llamada a la macro genera la siguiente tabla (y el correspondiente conjunto de notas):</p>

<hr>
<div class="hidden">La tabla de compatibilidad de esta página se genera a partir de datos estructurados. Si deseas contribuir con los datos, consulta <a class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíanos una solicitud de extracción.</div>

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

<div class="blockIndicator note">
<p><strong>Nota</strong> Los nombres de archivo a menudo coinciden con las etiquetas dadas a las interfaces dentro de las estructuras JSON, pero no siempre es así. Cuando las llamadas a macro generan las tablas, recorren todos los archivos hasta encontrar el JSON relevante para usar, por lo que los nombres de archivo no son críticos. Dicho esto, siempre debes nombrarlos de la manera más intuitiva posible.</p>
</div>