diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index c024915e998242..df904b8d21d8ed 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -87,4 +87,6 @@ /.github/ @mdn/core-dev /* @mdn/core-dev /*.md @mdn/core-dev @mdn/core-yari-content +/CONTRIBUTING.md @mdn/core-yari-content +/PEERS_GUIDELINES.md @mdn/core-yari-content /.prettierignore diff --git a/.github/ISSUE_TEMPLATE/page-report-fr.yml b/.github/ISSUE_TEMPLATE/page-report-fr.yml index 531f93181e39c1..156bf9ccc6af30 100644 --- a/.github/ISSUE_TEMPLATE/page-report-fr.yml +++ b/.github/ISSUE_TEMPLATE/page-report-fr.yml @@ -1,62 +1,62 @@ name: "[via des pages MDN uniquement // fr]" -description: Issue filed via le lien "Report a problem with this content on GitHub" sur des pages MDN. +description: Tickets rapportés via le lien "Report a problem with this content on GitHub" sur des pages MDN. labels: ["l10n-fr", "needs triage"] body: - type: markdown attributes: value: | - ### Before you start + ### Avant toute chose - **Want to change this page yourself?** This content is open source! - ↩ Go back and use the _Edit on GitHub_ link on the page. + **Vous souhaitez éditer cette page vous-même ?** Le contenu est open source ! + ↩ Revenez sur la page et cliquez sur le lien _Edit on GitHub_ en bas de la page. - **Is your issue about the browser compatibility table?** - ↩ Go back and use the _Report problems with this compatibility data on GitHub_ link on the page. + **Est-ce que le problème porte sur le tableau de compatibilité des navigateurs ?** + ↩ Revenez sur la page et cliquez sur le lien _Report problems with this compatibility data on GitHub_ en bas de la page. - **Need help with a browser?** - 🙋 To get help with [Firefox](https://support.mozilla.org/en-US/kb/file-bug-report-or-feature-request-mozilla), [Chrome](https://support.google.com/chrome/answer/95315?hl=en-GB&ref_topic=7439544), [Safari](https://www.apple.com/feedback/safari.html), or another browser, check the browser's support site. + **Vous avez besoin d'aide avec votre navigateur ?** + Consultez le site d'aide du navigateur (https://support.mozilla.org/fr/products/firefox pour Firefox, https://support.apple.com/fr-fr/safari pour Safari, https://support.google.com/chrome/?hl=fr#topic=7439538 pour Chrome, https://support.microsoft.com/fr-fr/microsoft-edge pour Edge). --- - type: input id: mdn-url attributes: - label: MDN URL - description: Set automatically. Do not modify. + label: URL MDN + description: Cette information est ajoutée automatiquement. Veuillez ne pas la modifier. validations: required: true - type: input id: section attributes: - label: What specific section or headline is this issue about? + label: Sur quelle section/titre porte ce problème ? - type: textarea id: problem attributes: - label: What information was incorrect, unhelpful, or incomplete? + label: Quelle information était incorrecte, inutile ou incomplète ? validations: required: true - type: textarea id: expected attributes: - label: What did you expect to see? + label: Que vous attendiez-vous à voir ? validations: required: true - type: textarea id: references attributes: - label: Do you have any supporting links, references, or citations? - description: Link to information that helps us confirm your issue. + label: Avez-vous des liens, références ou citations sur ce sujet ? + description: Des liens vers des informations qui pourront nous aider à confirmer le problème. - type: textarea id: more-info attributes: - label: Do you have anything more you want to share? - description: For example, steps to reproduce a bug, screenshots, screen recordings, or sample code + label: Souhaitez-vous ajouter autre chose ? + description: Cela peut être des étapes de reproduction du bogue, des captures ou enregistrements d'écran, un fragment de code. - type: markdown attributes: value: | --- - You're finished! The following fields are prefilled. Please click **Submit new issue**. + Et voilà, c'est terminé ! Les champs suivants sont remplis automatiquement. Vous pouvez cliquer sur **Submit new issue**. - type: textarea id: metadata attributes: - label: MDN metadata - description: Set automatically. Do not modify. + label: Métadonnées MDN + description: Remplies automatiquement. Ne pas modifier. diff --git a/docs/ko/README.md b/docs/ko/README.md index d06b264419e848..028c83edd5b9b5 100644 --- a/docs/ko/README.md +++ b/docs/ko/README.md @@ -42,10 +42,6 @@ PR 생성시에 한국 리뷰어들은 라운드 로빈 방식으로 배정이 - [ko-locale 현황판](https://github.com/mdn/translated-content/projects/2) -### 파일 확장자 - -현재 translated-content 저장소는 `.html`과 `.md` 두 개의 확장자로 문서 편집을 할 수 있습니다. **(자세한 내용은 [자주 묻는 질문](./faq.md) 5번을 참고해주세요.)** - 첫 기여자분들을 위해 다음 [issue 827](https://github.com/mdn/translated-content/issues/827)에 기여 방법을 작성했습니다. 참고해주세요. ## yari 빠른 사용법 diff --git a/files/es/learn/html/multimedia_and_embedding/video_and_audio_content/index.md b/files/es/learn/html/multimedia_and_embedding/video_and_audio_content/index.md index 11e93e09f755b7..137b8b6bc871a4 100644 --- a/files/es/learn/html/multimedia_and_embedding/video_and_audio_content/index.md +++ b/files/es/learn/html/multimedia_and_embedding/video_and_audio_content/index.md @@ -153,7 +153,7 @@ Esto nos dará un resultado que se parece a esto: Las nuevas características son: - [`width`](/es/docs/Web/HTML/Element/video#width) y [`height`](/es/docs/Web/HTML/Element/video#height) - - : Puede controlar el tamanño con estos atributos o con [CSS](/es/docs/Glossary/CSS). En ambos casos, los vídeos mantienen su relación **anchura - altura nativa**. Si la relación de aspecto no se mantiene con los tamañis establecidos, el vídeo crecerá para rellenar el espacio horizontalmente y el el espacio sin rellenar sólo recibirá un color de fondo sólido de forma predeterminada. + - : Puede controlar el tamanño con estos atributos o con [CSS](/es/docs/Glossary/CSS). En ambos casos, los vídeos mantienen su relación **anchura - altura nativa**. Si la relación de aspecto no se mantiene con los tamaños establecidos, el vídeo crecerá para rellenar el espacio horizontalmente y el el espacio sin rellenar sólo recibirá un color de fondo sólido de forma predeterminada. - [`autoplay`](/es/docs/Web/HTML/Element/video#autoplay) - : Hace que el audio o el vídeo empiece a reproducirse de inmediato, mientras se carga el resto de la página. Le aconsejamos que no utilice vídeo (o audio) de reproducción automática en sus sitios, ya que los usuarios pueden encontralo molesto. - [`loop`](/es/docs/Web/HTML/Element/video#loop) diff --git a/files/es/mdn/writing_guidelines/experimental_deprecated_obsolete/index.md b/files/es/mdn/writing_guidelines/experimental_deprecated_obsolete/index.md index 275121f6bbead7..04ce87dc14b10a 100644 --- a/files/es/mdn/writing_guidelines/experimental_deprecated_obsolete/index.md +++ b/files/es/mdn/writing_guidelines/experimental_deprecated_obsolete/index.md @@ -1,164 +1,120 @@ --- -title: MDN convenciones y definiciones +title: Experimental, desaprobado y obsoleto slug: MDN/Writing_guidelines/Experimental_deprecated_obsolete +l10n: + sourceCommit: 8d0cbeacdc1872f7e4d966177151585c58fb879e --- {{MDNSidebar}} -Este artículo define algunas convenciones y definiciones que se usan comúnmente en MDN, que pueden no ser obvias para algunas personas cuando las encuentran en la documentación. +Estos términos se asocian comúnmente con tecnologías y especificaciones y se utilizan en MDN Web Docs para etiquetar el estado de una tecnología. Para la definición de estos términos, MDN Web Docs se alinea con el repositorio [Browser Compatibility Data (BCD)](https://github.com/mdn/browser-compat-data/blob/main/schemas/compat-data-schema.md#status-information). +Estos términos se describen a continuación en el contexto de su uso en MDN Web Docs. -## Definiciones +## Experimental -### Desaprobado y obsoleto +Cuando una tecnología se describe como experimental en MDN Web Docs, significa que la tecnología es emergente e inmadura y actualmente está _en proceso_ de ser añadida a la plataforma web (o de ser considerada para su adición). +Marcar una tecnología como experimental indica que los lectores deben pensar cuidadosamente antes de usar esa tecnología en cualquier tipo de proyecto en producción (es decir, un proyecto que no sea solo una demostración o un experimento). Se [anima a los lectores a probar funciones experimentales](https://github.com/mdn/browser-compat-data/blob/main/schemas/compat-data-schema.md#status-information) y proporcionar comentarios a los proveedores de navegadores y autores de estándares. -**Desaprobado** y **obsoleto** son términos comunes asociados con tecnologías y especificaciones, pero ¿qué significan? +Para una tecnología marcada como **experimental**, se aplican una o más de las siguientes condiciones: -- Desaprobado - - En MDN, el término **desaprobado** se usa para marcar una API o tecnología que ya no se recomienda, pero que aún está implementada y puede funcionar. Recientemente, la hemos actualizado a la definición utilizada en nuestro [proyecto de datos de compatibilidad del navegador](https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md#status-information), que esa "característica ya no se recomienda. Es posible que se elimine en el futuro o que solo se conserve por motivos de compatibilidad. Evita el uso de esta funcionalidad." -- Obsoleto - - En MDN, el término **obsoleto** se utiliza para marcar una API o tecnología que no solo ya no se recomienda, sino que ya no se implementa en los navegadores. Sin embargo, esto fue confuso — es similar a desaprobado, y la distinción no es muy útil (aún no debes usarlo en un sitio de producción). Por lo tanto, ya no la usamos, y cualquier instancia con la que te encuentres se debe eliminar/reemplazar por desaprobada. +- Se implementa y habilita de forma predeterminada en la compilación de la versión de **solo un** motor de renderizado de los navegadores principales modernos. +- Solo se admite a través de cambios de configuración como preferencias o parámetros, independientemente del número de motores de renderizado admitidos. +- Es probable que su especificación definitiva cambie significativamente en formas incompatibles con versiones anteriores (es decir, puede romper el código existente que se basa en la característica). -### Experimental +> **Nota:** Una función que solo se publica en un motor de renderizado se sigue considerando experimental, incluso si está disponible en compilaciones de vista previa de otros motores de renderizado (o estableciendo una preferencia o indicador). -**Experimental** puede significar diferentes cosas según el contexto en el que lo escuches o lo leas. Cuando una tecnología se describe como experimental en MDN, significa que la tecnología es incipiente e inmadura, y actualmente está en proceso de ser agregada a la plataforma web (o considerada para agregarla). +El estado **experimental** de una tecnología puede caducar si se cumple una o más de las siguientes condiciones: -Uno o ambos de estos serán ciertos: +- Es compatible de forma predeterminada en **dos o más** de los principales motores de renderizado de los navegadores. +- Es compatible de forma predeterminada con un único motor de renderizado de navegador durante dos o más años y no sufre cambios importantes. +- Es poco probable que su especificación definitiva cambie de manera que rompa la compatibilidad. -- Está implementado y habilitado de forma predeterminada en menos de dos de los principales navegadores modernos. -- Su especificación definitoria no es estable y es probable que cambie significativamente. Por lo tanto, su sintaxis y comportamiento están sujetos a cambios en futuras versiones de navegadores a medida que cambie la especificación. +Para ver ejemplos de estas condiciones, consulte la documentación de [bandera experimental](https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines/index.md#setting-experimental) de BCD. -Si una o ambas de estas definiciones es cierta, entonces debes pensar detenidamente antes de comenzar a usar esa tecnología en cualquier tipo de proyecto de producción (es decir, no solo en una demostración o experimento). Consulta también la definición de experimental en nuestro [proyecto de datos de compatibilidad del navegador](https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md#status-information). +Usualmente, si una tecnología es soportada a través de varios de los navegadores principales, la especificación será estable, pero este no es siempre el caso. +Por otro lado, algunas tecnologías pueden tener una especificación estable, pero no tienen soporte nativo en los navegadores. [IMSC](/es/docs/Related/IMSC), por ejemplo, se utiliza mediante un polyfill de JavaScript. -Por el contrario, un elemento ya no es experimental cuando: +Una característica o tecnología que forma parte de una especificación activa o un proceso de estandarización y no está marcada como **obsoleta** se dice que está en **vía de estandarización**. -- Está implementado en dos o más navegadores principales; o -- Su especificación definitoria es estable y es poco probable que cambie. +## Desaprobada -El _or_ es importante aquí — por lo general, si una tecnología es compatible con varios navegadores importantes, la especificación será estable, pero no siempre es así. Y algunas tecnologías tendrán una especificación estable y se usarán bien, pero no tendrán soporte nativo en los navegadores ([IMSC](/es/docs/Related/IMSC), por ejemplo). +El término **desaprobado** en MDN Web Docs se utiliza para marcar una API o tecnología que ya no se recomienda. Una API o tecnología obsoleta podría eliminarse en el futuro o podría conservarse solo por motivos de compatibilidad y seguir funcionando. Recomendamos evitar el uso de las funcionalidades marcadas como desaprobadas. -### Páginas archivadas +Para más información en la definición de **desaprobado**, vea la [la bandera desaprobado](https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines/index.md#encuadre-deprecated) de la documentación de BCD. -Las páginas archivadas son páginas que se almacenan en el [Archivo de contenido obsoleto](/es/docs/Archive) de MDN. Estas páginas contienen información lo suficientemente desactualizada como para que ya no sea directamente útil para nadie. +## Obsoleto -Por lo general, estas se refieren a proyectos de Mozilla que han sido descontinuados y ya no se debe confiar en ellos. Pero no las eliminamos simplemente porque forman un registro histórico útil, y algunos de los patrones o ideas contenidos en ellos podrían ser útiles para trabajos futuros. Un buen ejemplo es el [proyecto B2G (Firefox OS)](/es/docs/Archive/B2G_OS). +En MDN Web Docs, el término **obsoleto** se usaba históricamente para indicar una API o tecnología que ya no solo ya no se recomienda, sino que ya no se implementa en los navegadores. +Debido a que la distinción entre **obsoleto** y **desaprobado** no es muy útil, ya no usamos el término **obsoleto** en MDN Web Docs. -#### ¿Cuándo se debe archivar una página? +> **Nota:** Si te encuentras con algún caso de **obsoleto**, debes eliminarlo o reemplazarlo con el término **desaprobado**. -Una página se debe archivar si se ajusta a la descripción anterior. Para archivar una página, debes utilizar la "función Mover página" (_Avanzado > Mover este artículo_) para mover la página al árbol de páginas de archivo (/es/docs/Archive). Es posible que no tengas los permisos para usar esta función, y antes de comenzar a archivar páginas, primero debas discutirlo con la comunidad MDN; habla con nosotros en nuestro [Foro de discusión](https://discourse.mozilla.org/c/mdn). +## Pautas para eliminar contenido -### Páginas eliminadas +A veces, durante el desarrollo de una nueva especificación o en el transcurso de la evolución de los estándares, como en HTML, se agregan nuevos elementos, métodos, propiedades, etc., a la especificación, se mantienen allí durante un tiempo y luego se eliminan. A veces esto sucede muy rápidamente, y a veces estos nuevos elementos permanecen en la especificación durante meses o incluso años antes de ser eliminados. Esto puede hacer que sea difícil decidir cómo manejar la eliminación del elemento de la especificación. -Las páginas eliminadas son páginas que se eliminaron explícitamente de MDN — consulta, por ejemplo, la interfaz [`SharedKeyframeList`](/es/docs/Web/API/SharedKeyframeList) y el constructor [`SharedKeyframeList()`](/es/docs/Web/API/SharedKeyframeList/SharedKeyframeList). Estas páginas contienen información que ya no es útil de ninguna manera y/o puede ser incorrecta hasta el punto en que mantenerla disponible puede ser confuso o malo para la gente. +Aquí hay algunas pautas para ayudarlo a decidir qué hacer cuando se elimina algo de la especificación. -Estas pueden ser: +> **Nota:** A los efectos de esta discusión, la palabra "elemento" se utiliza para referirse a cualquier cosa que pueda ser parte de una especificación: un elemento o un atributo de un elemento, una interfaz o cualquier método individual, una propiedad u otro miembro de una interfaz, y así sucesivamente. -- Páginas de referencia para funciones de API que se eliminaron de la especificación antes de que se implementaran en cualquier navegador. -- Artículos que cubren técnicas que luego se demostró que eran malas prácticas y fueron reemplazadas por mejores técnicas. -- Artículos que contienen información que luego fue reemplazada por otros artículos de mejor calidad. -- Artículos que contienen contenido inapropiado para MDN. -- Traducciones antiguas, desactualizadas y difíciles de arreglar, lo que significa que la versión en inglés es preferible y comenzar una nueva traducción sería una opción más fácil. +### Si el elemento nunca se implementó -#### ¿Cuándo se debe eliminar una página? +Si el elemento _nunca_ fue implementado en una versión de _cualquier_ navegador, ni siquiera detrás de una preferencia o un parámetro, elimine cualquier referencia al elemento de la documentación. -Se debe eliminar una página si se ajusta a la descripción anterior. Para eliminar una página, debes utilizar la función "Eliminar esta página" (_Avanzado> Eliminar esta página_) para eliminar la página. Probablemente no tengas los permisos para usar esta función, y cuando pienses en eliminar páginas, primero debes discutirlo con la comunidad de MDN; habla con nosotros en nuestro [Foro de discusión](https://discourse.mozilla.org/c/mdn). +- Si el artículo tiene alguna página de documentación que describa solo ese artículo (como {{domxref("RTCPeerConnection.close()")}}), elimina esa página. + Si el elemento eliminado es una interfaz, esto significa eliminar también cualquier subpágina que describa las propiedades y los métodos en esa interfaz. +- Elimine el elemento de cualquier lista de propiedades, atributos, métodos, etc. Para los métodos de una interfaz, por ejemplo, esto significa eliminarla de la sección "Métodos" en la página de descripción general de la interfaz. +- Busque en el texto de la página de resumen de esa interfaz, elemento, etc., cualquier referencia al elemento eliminado. Elimine esas referencias, asegurándose de no dejar problemas gramaticales extraños u otros problemas con el texto. Esto puede significar no solo eliminar palabras, sino reescribir una oración o párrafo para que tenga más sentido. También puede significar eliminar secciones enteras de contenido si la descripción del uso del artículo es larga. +- Del mismo modo, busca cualquier discusión sobre el tema en las guías y tutoriales sobre la API o tecnología relevante. Elimine esas referencias, asegurándose de no dejar problemas gramaticales extraños u otros problemas con el texto. Esto puede significar no solo eliminar palabras, sino reescribir una oración o párrafo para que tenga más sentido. También puede significar eliminar secciones enteras de contenido si la descripción del uso del artículo es larga. +- Busque en MDN Web Docs referencias al elemento eliminado, en caso de que haya discusiones en otro lugar. Es poco probable que los haya, ya que si nunca se implementó, es poco probable que se discuta ampliamente. Elimina esas menciones también. +- Si los archivos JSON en el [repositorio de datos de compatibilidad del navegador](https://github.com/mdn/browser-compat-data) contienen datos de los elementos eliminados, elimine esos objetos del código JSON y envíe una solicitud de revisión con ese cambio, explicando el motivo en el mensaje de confirmación y la descripción. Tenga cuidado de no romper la sintaxis JSON mientras lo hace. -### Cuando documentar nuevas tecnologías +### Si el elemento se implementó en un navegador detrás de un argumento -En MDN, buscamos constantemente documentar nuevas tecnologías de estándares web según corresponda. Intentamos lograr un equilibrio entre publicar la documentación lo suficientemente temprano para que los desarrolladores puedan aprender sobre las nuevas funciones tan pronto como lo necesiten y publicarla lo suficientemente tarde para que la tecnología sea madura y estable para que los documentos no necesiten actualizaciones constantes o rápida eliminación. +Si el elemento se implementó en cualquier versión de lanzamiento de uno o más navegadores pero _solo_ detrás de una preferencia o un argumento, no lo elimine de la documentación de inmediato. En su lugar, marca el artículo como **desaprobado** de la siguiente manera: -En general, nuestra definición de lo más temprano que consideraremos para documentar una nueva tecnología es: +- Si el artículo tiene alguna página de documentación que describa solo ese artículo (como {{domxref ("RTCPeerConnection.close()")}}), agrega la macro [`deprecated_header`](https://github.com/mdn/yari/blob/main/kumascript/macros/Deprecated_Header.ejs) a la parte superior de la página y agrega la siguiente entrada de metadato `status:`: -_"Cuando la función está en una pista de estándares y se implementa en algún lugar."_ + ```yaml + status: + - deprecated + ``` -Definitivamente deberías considerar documentar una nueva tecnología si: +- En la página de descripción general del elemento, interfaz o API, busca la lista de elementos que incluye el elemento que se ha eliminado de la especificación y agrega la macro [`deprecated_inline`](https://github.com/mdn/yari/blob/main/kumascript/macros/Deprecated_Inline.ejs) después del nombre del elemento en esa lista. +- Buscar en el texto informativo de la página de resumen de esa interfaz, elemento, etc., cualquier referencia al elemento eliminado. Agregue cuadros de advertencia en los lugares apropiados con texto como "\[item] se ha eliminado de la especificación y se eliminará pronto de los navegadores. Consulta \[enlace a página] para obtener una nueva forma de hacerlo." +- Del mismo modo, busca cualquier discusión sobre el tema en las guías y tutoriales sobre la API o tecnología relevante. Añade advertencias similares. +- Busque en MDN Web Docs referencias al elemento eliminado, en caso de que haya discusiones en otro lugar. Añade mensajes de advertencia similares allí también. +- En algún momento en el futuro, se puede tomar la decisión de eliminar el artículo de la documentación; normalmente no lo hacemos, pero si el artículo estaba especialmente inutilizado o no era interesante, podemos decidir hacerlo. +- Actualizar cualquier entrada relevante en el [Repositorio de datos de compatibilidad del navegador](https://github.com/mdn/browser-compat-data) para reflejar la obsolescencia de los artículos afectados. -- Se especifica en un documento de especificación publicado bajo una organización de estándares confiable (como W3C, WHATWG, Khronos, IETF, etc.), que ha alcanzado un nivel razonable de estabilidad (por ejemplo, un borrador de trabajo del W3C o una recomendación candidata, o la especificación está buscando ser bastante estable a juzgar por el flujo de asuntos presentados en su contra). -- Se implementa de manera consistente en al menos un navegador, y otros desarrolladores de navegadores muestran signos de interés (como un boleto activo o un proceso de "intención de implementar" en vigor). +### Si el elemento se implementó en un navegador sin un parámetro -Deberías tener más cuidado al documentar una nueva tecnología (pero deberías considerarla si tiene sentido) si: +Si el elemento se implementó en una o más compilaciones de versiones de navegadores sin requerir una preferencia o un parámetro, marque el elemento como **desaprobado**, de la siguiente manera: -- No tiene una especificación, o la especificación es una nota aproximada que parece estar sujeta a cambios. -- Uno o cero navegadores lo implementan actualmente, y los navegadores que no lo admiten no muestran signos de interés en implementarlo (puedes evaluar esto preguntando a los ingenieros que trabajan en esos navegadores, buscando rastreadores de errores del navegador y listas de correo, etc.). +- Si el artículo tiene alguna página de documentación que describa solo ese artículo (como {{domxref ("RTCPeerConnection.close()")}}), agrega la macro [`deprecated_header`](https://github.com/mdn/yari/blob/main/kumascript/macros/Deprecated_Header.ejs) a la parte superior de la página y agrega la siguiente entrada de metadato `status:`: -No debes considerar documentar una nueva tecnología si: + ```yaml + status: + - deprecated + ``` -- No es una tecnología expuesta a la web y/o es completamente propietaria. -- Ya muestra signos de estar obsoleto o reemplazado por una característica similar. +- En la página de descripción general del elemento, interfaz o API, busca la lista de elementos que incluye el elemento que se ha eliminado de la especificación y agrega la macro [`deprecated_inline`](https://github.com/mdn/yari/blob/main/kumascript/macros/Deprecated_Inline.ejs) después del nombre del elemento en esa lista. +- Buscar en el texto informativo de la página de resumen de esa interfaz, elemento, etc., cualquier referencia al elemento eliminado. Agregue mensajes de advertencia en los lugares apropiados con texto como "\[item] ha sido eliminado de la especificación y está desaprobado. Es posible que se elimine de los navegadores en el futuro, por lo que no debes usarlo. Consulta \[enlace a página] para obtener una nueva forma de hacerlo." +- Del mismo modo, busca cualquier discusión sobre el tema en las guías y tutoriales sobre la API o tecnología relevante. Añade advertencias similares. +- Busque en MDN Web Docs referencias al elemento eliminado, en caso de que haya discusiones en otro lugar. Añade mensajes de advertencia similares allí también. +- Es poco probable que estos artículos se eliminen de la documentación en el corto plazo, si es que se eliminan alguna vez. +- Actualizar cualquier entrada relevante en el [Repositorio de datos de compatibilidad del navegador](https://github.com/mdn/browser-compat-data) para reflejar la caducidad de los artículos afectados. -## Convenciones +Utilice el sentido común con la redacción de los mensajes de advertencia y otros cambios en el texto sugeridos en las pautas anteriores. +Diferentes elementos requerirán una redacción y un manejo diferente de la situación. +En caso de duda, no dudes en pedir consejo en las [salas de chat de MDN Web Docs](/es/docs/MDN/Community/Communication_channels#chat_rooms). -### Cuando se elimina algo de la especificación +## Pautas para documentar un conflicto de especificaciones -A veces, durante el desarrollo de una nueva especificación, o en el transcurso de la evolución de los estándares como HTML, se agregan nuevos elementos, métodos, propiedades, etc. a la especificación, permanecen allí por un tiempo y luego se eliminan nuevamente. A veces, esto sucede muy rápido y, a veces, estos nuevos elementos permanecen en la especificación durante meses o incluso años antes de ser eliminados. Esto puede hacer que sea complicado decidir cómo manejar la eliminación del artículo de la especificación. Aquí hay algunas pautas que te ayudarán a decidir qué hacer. +A veces, pero rara vez, puede haber un conflicto entre diferentes versiones de especificaciones (generalmente W3C versus WHATWG). Por ejemplo, una versión puede tener una función que aparece como obsoleta, mientras que la otra no. +En tales casos, considere cuál es la realidad, es decir, considere qué están haciendo realmente los navegadores y escriba una nota "importante" para resumir ese último estado. +Por ejemplo, a partir de enero de 2019, el atributo global [`inputmode`](/es/docs/Web/HTML/Global_attributes/inputmode) tiene un conflicto, que se resumió así: -> **Nota:** Para los propósitos de esta discusión, la palabra "elemento" se usa para significar cualquier cosa que pueda ser parte de una especificación: un elemento o un atributo de un elemento, una interfaz o cualquier método individual, propiedad u otro miembro de una interfaz, etcétera. - -- Si el elemento _nunca_ se implementó en una versión de lanzamiento de _cualquier_ navegador, incluso detrás de una preferencia o marca, simplemente elimina cualquier referencia al elemento de la documentación. - - - Si el elemento tiene páginas de documentación que describen solo ese elemento (como {{domxref("RTCPeerConnection.close()")}}), elimina esa página. Si el elemento eliminado es una interfaz, esto significa eliminar también las subpáginas que describen las propiedades y los métodos de esa interfaz. - - Elimina el elemento de cualquier lista de propiedades, atributos, métodos, etc. Para los métodos de una interfaz, eso significa eliminarlo de la sección "Métodos" en la página de descripción general de la interfaz, por ejemplo. - - Busca en el texto de la página de descripción general para esa interfaz, elemento, etc., cualquier referencia al elemento eliminado. Elimina esas referencias, asegurándote de no dejar extraños problemas gramaticales u otros problemas con el texto. Esto puede significar no solo borrar palabras, sino reescribir una oración o párrafo para que tenga más sentido. También puede significar eliminar secciones enteras de contenido si la descripción del uso del elemento es extensa. - - Del mismo modo, busca cualquier discusión sobre el tema en las guías y tutoriales sobre la API o tecnología relevante. Elimina esas referencias, asegurándote de no dejar extraños problemas gramaticales u otros problemas con el texto. Esto puede significar no solo borrar palabras, sino reescribir una oración o párrafo para que tenga más sentido. También puede significar eliminar secciones enteras de contenido si la descripción del uso del elemento es extensa. - - Busca en MDN referencias al elemento eliminado, en caso de que haya discusiones en otro lugar. Es poco probable que las haya, ya que si nunca se implementó, es poco probable que se discuta ampliamente. Elimina también esas menciones. - - Si el [repositorio de datos de compatibilidad del navegador](https://github.com/mdn/browser-compat-data) contienen datos de los elementos eliminados, elimina esos objetos del código JSON y envía una SE con ese cambio, explicando por qué en el mensaje de confirmación y la descripción de la SE. Ten cuidado de no romper la sintaxis JSON mientras haces esto. - -- Si el elemento se implementó en cualquier versión de lanzamiento de uno o más navegadores, pero _solo_ detrás de una preferencia o marca, no elimines el elemento de la documentación inmediatamente. En su lugar, marca el artículo como obsoleto de la siguiente manera: - - - Si el elemento tiene páginas de documentación que describen solo ese elemento (como {{domxref("RTCPeerConnection.close()")}}), agrega la macro [`deprecated_header`](https://github.com/mdn/yari/tree/main/kumascript/macros/deprecated_header.ejs) en la parte superior de la página y agrega la etiqueta `Deprecated` a la lista de etiquetas de la página. - - En la página de descripción general del elemento, la interfaz o la API, busca la lista de elementos que incluyan el elemento que se ha eliminado de la especificación y agrega la macro [`deprecated_inline`](https://github.com/mdn/yari/tree/main/kumascript/macros/deprecated_inline.ejs) después del nombre del elemento en esa lista. - - Busca en el texto informativo de la página de descripción general de esa interfaz, elemento, etc., cualquier referencia al elemento eliminado. Agrega cuadros de advertencia en los lugares apropiados con texto del tipo "\[lo que sea] se ha eliminado de la especificación y pronto se eliminará de los navegadores. Consulta \[enlace a la página] para conocer una nueva forma de hacer esto." - - Del mismo modo, busca cualquier discusión sobre el tema en las guías y tutoriales sobre la API o tecnología relevante. Agrega advertencias similares. - - Busca en MDN referencias al elemento eliminado, en caso de que haya discusiones en otro lugar. Agrega también cuadros de advertencia similares allí. - - En algún momento en el futuro, se puede tomar la decisión de eliminar el elemento de la documentación; Normalmente no hacemos esto, pero si el artículo no se utilizó o no fue interesante, podemos decidir hacerlo. - - Actualiza cualquier entrada relevante en el [repositorio de datos de compatibilidad del navegador](https://github.com/mdn/browser-compat-data) para reflejar la obsolescencia de los elementos afectados. - -- Si el elemento se implementó en una o más versiones de publicaciones de navegadores, sin que sea necesario cambiar una preferencia o una marca, marca el elemento como obsoleto, de la siguiente manera: - - - Si el elemento tiene páginas de documentación que describen solo ese elemento (como {{domxref("RTCPeerConnection.close()")}}), agrega la macro [`deprecated_header`](https://github.com/mdn/yari/tree/main/kumascript/macros/deprecated_header.ejs) en la parte superior de la página y agrega la etiqueta `Deprecated` a la lista de etiquetas de la página. - - En la página de descripción general del elemento, la interfaz o la API, busca la lista de elementos que incluyan el elemento que se ha eliminado de la especificación y agrega la macro [`deprecated_inline`](https://github.com/mdn/yari/tree/main/kumascript/macros/deprecated_inline.ejs) después del nombre del elemento en esa lista. - - Busca en el texto informativo de la página de descripción general de esa interfaz, elemento, etc., cualquier referencia al elemento eliminado. Agrega recuadros de advertencia en los lugares apropiados con texto del tipo "\[lo que sea] se ha eliminado de la especificación y está obsoleto. Es posible que se elimine de los navegadores en el futuro, por lo que no debes usarlo. Consulta \[enlace a la página] para conocer una nueva forma de hacer esto." - - Del mismo modo, busca cualquier discusión sobre el tema en las guías y tutoriales sobre la API o tecnología relevante. Agrega advertencias similares. - - Busca en MDN referencias al elemento eliminado, en caso de que haya discusiones en otro lugar. Agrega también cuadros de advertencia similares allí. - - Es poco probable que estos elementos se eliminen de la documentación pronto, si es que alguna vez lo hacen. Sin embargo, es posible que parte o todo el material se mueva a la sección [Archivo](/es/docs/Archive) del sitio. - - Actualiza todas las entradas relevantes en el [repositorio de datos de compatibilidad del navegador](https://github.com/mdn/browser-compat-data) para reflejar la obsolescencia de los elementos afectados. - -Utiliza el sentido común con la redacción de los mensajes de advertencia y otros cambios en el texto sugeridos por las pautas anteriores. Los diferentes elementos requerirán una redacción y un manejo diferentes de la situación. En caso de duda, no dudes en pedir consejo en la [sala del chat de Docs Web de MDN](https://chat.mozilla.org/#/room/#mdn:mozilla.org) en [Matrix](https://wiki.mozilla.org/Matrix), o en el [foro de debate de Docs Web de MDN](https://discourse.mozilla.org/c/mdn). - -### Copiar contenido dentro de MDN - -A veces, necesitas reutilizar el mismo texto en varias páginas (o deseas usar el contenido de una página como plantilla para otra página). Tienes tres opciones: - -- Si deseas copiar una página completa: - - 1. Mientras visualizas la página que deseas copiar, en el menú **Avanzado** (engrane), elige [**Clona esta página**](/es/docs/MDN/Contribute/Creating_and_editing_pages#Clone_of_an_existing_page). Esto abre la interfaz de usuario del editor para una nueva página, con el contenido de la página clonada ya poblada. - 2. Introduce un **título** y un **`slug`** nuevo para la página clonada. - 3. Edita el contenido de la página según sea necesario y guárdalo como usualmente lo haces. - -- Si deseas copiar solo una parte de una página, **no solo visites la página y la copies**. Esto introduce bits adicionales de HTML no deseados en la página destino, y alguien tendrá que limpiar eso, tú u otro editor. Nadie quiere eso. Para copiar parte de una página MDN a otra página: - - 1. En la página fuente, haz clic en el botón **Editar** en la página de fuente. - 2. **Copia el contenido que deseas reutilizar desde la interfaz de usuario del editor.** - 3. Haz clic en **Descartar** para salir de la interfaz de usuario del editor de esa página. - 4. Abre la interfaz de usuario del editor de la página donde deseas pegar. - 5. Pega el contenido del portapapeles. - - > **Nota:** Chrome generalmente no incluye las clases aplicadas al contenido al copiar y pegar documentos en nuestro editor. Debes revisar el contenido después de hacer esto y volver a aplicar los estilos perdidos. Checa las tablas, cuadros de sintaxis, resaltado de sintaxis y secciones ocultas de contenido en particular. - -- A veces, literalmente, deseas utilizar el mismo contenido en muchas páginas. En este caso, es mejor que coloques el contenido en una página y luego uses la macro [`Page`](https://github.com/mdn/yari/tree/main/kumascript/macros/Page.ejs) para trasladar el material de una página a otra. De esta forma, siempre que se actualice el texto de la página fuente, la página de destino también se actualizará (es decir, esto sucederá en una actualización forzada o cuando la página destino pase por una reconstrucción programada). - -#### Copiar contenido de otro lugar - -A menudo, hay contenido útil sobre un tema en algún lugar de la web además de MDN. Sin embargo, copiar dicho contenido puede plantear dificultades, tanto legales como técnicas. - -En el nivel técnico, los motores de búsqueda suelen penalizar a un sitio en su clasificación por reproducir contenido disponible en otros lugares. Por lo tanto, es preferible tener contenido original en MDN, para mejorar la clasificación del contenido de MDN en los motores de búsqueda. Puedes vincular al contenido existente de MDN. - -A nivel legal, debes estar autorizado para contribuir con el contenido, y debes tener licencia y atribución de una manera que sea compatible con [licencia de MDN](/es/docs/MDN/About#Copyrights_and_licenses). - -- **Si creaste el contenido existente** (para tus propios fines y no como trabajo por encargo) y estás dispuesto a contribuir a MDN con la licencia de MDN, este es el caso más fácil y estás libre de contribuir con el contenido. -- **Si los derechos de autor del contenido pertenecen a otra persona**, debes tener licencia y atribuir de manera compatible con la licencia de MDN. A menudo, no es fácil para alguien que no es abogado determinar qué licencias son compatibles. Para estar seguro, comunícate con un miembro del [equipo de personal de MDN](https://wiki.mozilla.org/MDN#Staff_Team), quien puede consultar al equipo legal de Mozilla para obtener orientación si es necesario . - -#### Cómo comunicar un conflicto de especificaciones - -Ten en cuenta que a veces (pero rara vez) hay un conflicto entre diferentes versiones de especificaciones (generalmente W3C versus WHATWG), p. ej. una versión puede tener una característica listada como obsoleta, mientras que la otra no. En tales casos, considera cuál es la realidad, es decir, qué están haciendo los navegadores, y escribe una nota "importante" para resumir ese último estado. Por ejemplo, a enero de 2019, el atributo global [`inputmode`](/es/docs/Web/HTML/Global_attributes/inputmode) tiene un conflicto, que se resumió al igual que: - -> **Advertencia:** **Conflicto de especificaciones**: La [lista de especificaciones de WHATWG `inputmode`](https://html.spec.whatwg.org/multipage/interaction.html#attr-inputmode), y los navegadores modernos están trabajando para admitirlo. Sin embargo, la [especificación W3C HTML 5.2](https://www.w3.org/TR/html52/index.html#contents) ya no la incluye (es decir, la marca como desaprobada). Debes considerar que la definición del WHATWG es correcta, hasta que se logre un consenso. +> **Advertencia:** Conflicto de especificación: La especificación WHATWG enumera [`inputmode`](https://html.spec.whatwg.org/multipage/interaction.html#attr-inputmode) y los navegadores modernos están trabajando para soportarlo. +> La [especificación HTML 5.2 del W3C](https://html.spec.whatwg.org/multipage/index.html#contents), sin embargo, ya no la enumera (es decir, la marca como obsoleta). +> Debe considerar la definición de WHATWG como correcta, hasta que se llegue a un consenso. diff --git a/files/es/mdn/writing_guidelines/howto/json_structured_data/index.md b/files/es/mdn/writing_guidelines/howto/json_structured_data/index.md new file mode 100644 index 00000000000000..bda0def8c43c1b --- /dev/null +++ b/files/es/mdn/writing_guidelines/howto/json_structured_data/index.md @@ -0,0 +1,124 @@ +--- +title: Cómo usar datos estructurados +slug: MDN/Writing_guidelines/Howto/JSON_Structured_data +l10n: + sourceCommit: 0c163056cfe83fba519b757f15d2e20f83eddaff +--- + +{{MDNSidebar}} + +MDN almacena los datos en estructuras bien definidas cuando es posible. Esta información se centraliza y se puede actualizar una vez, mientras se utiliza en numerosos lugares. + +Existen varios de estos archivos, y este documento describe su propósito, estructura y proceso de mantenimiento. + +## GroupData: agrupación lógica de API + +`GroupData` es un archivo JSON que recopila información sobre las API web. La agrupación de APIs es algo difusa: cualquier interfaz, método o propiedad puede formar parte de varias APIs. El conjunto de API agrupadas bajo un nombre es una convención utilizada para comunicar sobre una característica, sin ninguna aplicación técnica. + +Sin embargo, MDN necesita esta información para crear menus laterales coherentes de Web-API (como con la macro `\{{APIRef}}`) con las páginas de referencia, guías y artículos generales adecuados. + +GroupData hace exactamente eso: para cada API, enumera las interfaces, propiedades, métodos, guías y páginas de descripción general. En el pasado, también enumeraba diccionarios y devoluciones de llamada. Pero ese uso, aunque todavía es compatible, está obsoleto y se eliminará en el futuro. + +### Estructura de GroupData + +> **Advertencia:** Las páginas inexistentes enumeradas en este archivo se ignoran. + +Una entrada en `GroupData.json` tiene la siguiente estructura: + +```json +"Nombre_de_API": { + "overview": ["nombre de la página de descripción general"], + "guides": [ + "nombre_de_guia_1", + (…) + ], + "interfaces": [ + "nombre_de_interfaz_1", + (…) + ], + "methods": [ + "nombre_de_metodo_adicional_1", + (…) + ], + "properties": [ + "nombre_de_propiedad_adicional_1", + (…) + ], + "events": [ + "nombre_de_propiedad_adicional_1", + (…) + ] +} +``` + +…donde: + +- `"Nombre_de_API"` + - : Esta clave es un ID utilizado por macros de menu lateral como `\{{APIRef("Nombre_de_API")}}` y el nombre que se muestra en el menu lateral. Elígelo sabiamente. + > **Advertencia:** Si desea cambiar el nombre que se muestra en el menu lateral, debe editar todas las páginas que lo muestran. +- `"overview"` + - : Esta es una lista que contiene una página: la página de resumen, utilizada como enlace para el texto `"Nombre_de_API"`. El valor es el _titulo de la página_, y la página debe estar en el directorio `web/api/`. +- `"guides"` + - : Esta es una lista de guías para mostrar en el menu lateral, en el orden dado. Los valores son _rutas a la página_, comenzando con `/docs/`. +- `"interfaces"` + - : Enumera las interfaces que forman parte de la API. +- `"methods"` + - : Enumera los métodos que forman parte de la API. + > **Nota:** Los métodos de las interfaces enumeradas en `"interfaces"` **no deben** estar enumerados allí. Se añaden automáticamente al menu lateral si la etiqueta `Method` está en el encabezado YAML de esa página. +- `"properties"` + - : Enumera los métodos en otras interfaces que forman parte de la API, como `navigator.xr` (una propiedad que la API de WebXR agrega al objeto `navigator`) + > **Nota:** Las propiedades de las interfaces enumeradas en `"interfaces"` **no deben** estar enumeradas allí. Se añaden automáticamente a la barra lateral si la etiqueta `Property` está en el encabezado YAML de esa página. +- `"events"` + - : Enumera los eventos de otras interfaces que forman parte de la API. Los valores son el _título de las páginas_ (que debe residir en `Web/Events`) + > **Nota:** Los eventos dirigidos a las interfaces enumeradas en `"interfaces"` **no deben** estar enumerados allí. Se añaden automáticamente al menu lateral si la etiqueta `Event` (¡singular!) está en el encabezado YAML de esa página. + +Hay otras dos claves, `"dictionaries"` y `"callbacks"`, que funcionan con el mismo principio. Como ya no documentamos estas entidades en sus propias páginas, su uso está obsoleto y no se les debe añadir ninguna entrada nueva (y las eliminamos poco a poco). + +> **Nota:** Además, ninguna de las claves es obligatoria; es una buena práctica (y lo haremos cumplir) agregar las no obsoletas con una lista vacía en lugar de omitirlas. Muestra que la ausencia de valor es una elección consciente. + +### Proceso de actualización para GroupData + +Este archivo debe actualizarse en el mismo PR donde se producen los cambios que afectan al menu lateral. De esta forma, el menu lateral estará siempre actualizado. Los revisores no deben fusionar las solicitudes de incorporacion que no las adopten. + +Para probar sus cambios, verifique que el menu lateral en los archivos de su PR muestre todas las entradas correctamente. + +El archivo `GroupData.json` se encuentra [aquí](https://github.com/mdn/content/blob/main/files/jsondata/GroupData.json) en GitHub. + +## InterfaceData: herencia de la interfaz de grabación + +> **Nota:** Esperamos generar este archivo automáticamente a partir de los datos disponibles a través de w3c/webref en el futuro. + +`InterfaceData` describe la jerarquía de las interfaces. Enumera la herencia. En el pasado, también enumeraba los mixins implementados por cada interfaz; pero ese uso está obsoleto, y eliminamos los mixins de este archivo al mismo ritmo que se actualiza MDN. + +Estos datos de herencia se utilizan al crear menus laterales de API y por el `\{{InheritanceDiagram}}` en las páginas de la interfaz. + +### Estructura de InterfaceData + +Una entrada en `InterfaceData.json` tiene la siguiente estructura: + +```json +"Nombre_de_la_interfaz": { + "inh": "Nombre_de_la_interfaz_padre", + "impl": [] +} +``` + +> **Nota:** Como los mixins están obsoletos, `"impl"` debe ser una lista vacía para todas las interfaces nuevas. + +El valor de `"Nombre_de_la_interfaz_padre"` no es una lista sino una sola entrada, obligatoria; no debemos enumerar ninguna interfaz que no herede de otra. + +### Proceso de actualización para InterfaceData + +El mismo PR que añade una nueva interfaz que hereda de otra debe actualizar este archivo. Los revisores no deben fusionar las solicitudes de incorporacion que no lo hacen. + +Para probar sus cambios, verifique que los menus laterales de cada interfaz que editó en su PR muestren la herencia correctamente. + +El archivo `InterfaceData.json` se encuentra [aquí](https://github.com/mdn/content/blob/main/files/jsondata/InterfaceData.json) en GitHub. + +## SpecData: Información de especificación + +> **Advertencia:** El archivo `SpecData.json` ya no se mantiene. La información de especificación canónica se almacena en w3c/browser-spec y en la clave `spec_url` de características en mdn/browser-compat-data. + +Las macros `\{{SpecName}}` y `\{{Spec2}}` que estamos eliminando utilizan el archivo `SpecData.json`. No aceptamos más contribuciones al archivo `SpecData.json`; en su lugar, intente insertar una tabla de especificaciones, utilizando la macro `\{{Specifications}}`, o intente codificar el enlace (bueno) a la especificación. Tenga en cuenta que la mayoría de las veces, mencionar o vincular a una especificación fuera de la sección _Especificaciones_ es un signo de algo que no está debidamente documentado en MDN. + +El archivo `SpecData.json` se encuentra [aquí](https://github.com/mdn/content/blob/main/files/jsondata/SpecData.json) en GitHub. diff --git a/files/es/mdn/writing_guidelines/page_structures/page_types/css_module_landing_page_template/index.md b/files/es/mdn/writing_guidelines/page_structures/page_types/css_module_landing_page_template/index.md new file mode 100644 index 00000000000000..2823b36c11d6c4 --- /dev/null +++ b/files/es/mdn/writing_guidelines/page_structures/page_types/css_module_landing_page_template/index.md @@ -0,0 +1,122 @@ +--- +title: Plantilla de página de destino del módulo CSS +slug: MDN/Writing_guidelines/Page_structures/Page_types/CSS_module_landing_page_template +l10n: + sourceCommit: bfdfe970004b21218ef4ab6a4274d4fb29c4742b +--- + +{{MDNSidebar}} + +> **Nota:** _Recuerde eliminar este bloque de notas antes de publicar._ +> +> --- +> +> **Metadatos de la página:** +> +> La parte superior de la página se utiliza para definir "metadatos de página". +> Los valores deben actualizarse adecuadamente para el módulo en particular. +> +> ```md +> --- +> title: NombreDelModulo CSS +> slug: Web/CSS/CSS_NameOfTheModule +> page-type: css-module +> spec-urls: +> - url1 +> - url2 +> --- +> ``` +> +> - **title** +> - : El valor `title` se muestra en la parte superior de la página. +> Este es el nombre del módulo seguido del texto "CSS". +> Por ejemplo, el título de la página de inicio del módulo [grid layout](/es/docs/Web/CSS/CSS_grid_layout) es _Diseño de cuadrícula de CSS_. +> - **slug** +> - : El valor `slug` es el final de la ruta de la URL después de `https://developer.mozilla.org/es/docs/`. +> Esto se formateará como `Web/CSS/CSS_NameOfTheModule`. +> Por ejemplo, el `slug` para la página de inicio del módulo [grid layout](/es/docs/Web/CSS/CSS_grid_layout) es `Web/CSS/CSS_grid_layout`. +> - **page-type** +> - : El valor `page-type` para las páginas de destino del módulo CSS es `css-module` (solo para contenido en ingles). +> - **spec-urls** +> +> - : El valor `spec-urls` es una URL de la especificación. En caso de que haya más de una versión de la especificación que sea relevante, preséntelas en una lista con viñetas. Por ejemplo, el valor de la clave `spec-urls` para la página de inicio del módulo [filter effects](/es/docs/Web/CSS/CSS_filter_effects) es (solo para contenido en ingles): +> +> ```plain +> - `https://drafts.fxtf.org/filter-effects-2/` +> - `https://drafts.fxtf.org/filter-effects-1/` +> ``` +> +> --- +> +> **Macros al principio de la pagina** +> +> La macro llamada `\{{CSSRef}}` aparece en la parte superior de la sección de contenido (inmediatamente debajo de los metadatos). +> Esta macro debe estar presente en cada página de destino del módulo CSS. Genera una barra lateral CSS adecuada, dependiendo de las etiquetas incluidas en la página. +> Elimine la macro `\{{MDNSidebar}}` cuando utilice esta plantilla. +> +> --- +> +> _Recuerde eliminar este bloque de notas antes de publicar._ + +Comience el contenido de la página con un párrafo introductorio, que nombra el módulo y dice lo que hace. +Idealmente, esto debería ser una o dos oraciones cortas. + +## NombreDelModulo en acción + +En esta sección, incluya un ejemplo interactivo del módulo que ayude a demostrar la utilidad o el poder de varias propiedades proporcionadas por este módulo. El propósito de esta sección es demostrar algunos casos de uso y crear interés y curiosidad en la mente de los lectores que aprenden sobre este módulo. + +Proporcione una breve descripción de cómo los lectores pueden interactuar con el ejemplo. No entres en muchos detalles para explicar el ejemplo y no incluyas fragmentos de código. Añade un enlace al código fuente del ejemplo en el repositorio [`css-examples`](https://github.com/mdn/css-examples/tree/main/modules). Por ejemplo, para el ejemplo interactivo del módulo de efectos de filtro, diría: +"Para ver el código de este ejemplo, [ver el código fuente en GitHub](https://github.com/mdn/css-examples/blob/main/modules/filters.html)." + +## Referencia + +Cree las subsecciones relevantes para enumerar las propiedades, funciones, tipos de datos, etc. relacionados. + +### Propiedades + +Lista de todas las propiedades abreviadas y completas proporcionadas por el módulo. + +### Reglas arroba + +Lista de reglas de arroba CSS proporcionada por el módulo. Omita esta sección si no hay reglas de arroba CSS relevantes para este módulo. + +### Funciones + +Lista de funciones CSS proporcionadas por el módulo. Omita esta sección si no hay funciones CSS relevantes para este módulo. + +### Tipos de datos + +Lista de tipos de datos CSS proporcionados por el módulo. Omita esta sección si no hay tipos de datos CSS relevantes para este módulo. + +### Eventos + +Lista de eventos de API proporcionados por el módulo. Omita esta sección si no hay eventos relevantes para este módulo. + +### Interfaces + +Enumere la API relacionada y las interfaces proporcionadas por el módulo. Omita esta sección si no hay interfaces API relevantes para este módulo. + +## Guías + +- EnlaceAGuia1 + - : Descripción de la guía en una o dos frases. +- EnlaceAGuia2 + - : Descripción de la guía en una o dos frases. + +## Conceptos relacionados + +Enumere todas las demás propiedades, tipos de datos o términos del glosario que puedan ser relevantes o estar relacionados con este módulo. + +Especificaciones + +`\{{Specifications}}` + +_Para usar esta macro, elimine las comillas inveritdas y la barra invertida en el archivo de markdown._ + +Vease también + +Incluya enlaces a páginas de referencia y guías relacionadas con la propiedad actual. Consulta la sección [Vease también](/es/docs/MDN/Writing_guidelines/Writing_style_guide#see_also_section) en nuestra _Guía de estilo de escritura_ para obtener más consejos e instrucciones. + +- enlace1 +- enlace2 +- enlace_externo (año) diff --git a/files/es/mdn/writing_guidelines/what_we_write/index.md b/files/es/mdn/writing_guidelines/what_we_write/index.md new file mode 100644 index 00000000000000..b327fd7a685db3 --- /dev/null +++ b/files/es/mdn/writing_guidelines/what_we_write/index.md @@ -0,0 +1,131 @@ +--- +title: Lo que escribimos +slug: MDN/Writing_guidelines/What_we_write +l10n: + sourceCommit: 5cc673ab34acfb189832b22f85a44c6527e4a5ea +--- + +{{MDNSidebar}} + +MDN Web Docs contiene documentación _neutral al navegador_ que permite a los desarrolladores web escribir código _agnostico al navegador_. En este artículo, encontrarás información sobre si un tema o tipo de contenido determinado debe incluirse en MDN Web Docs. + +## Políticas editoriales + +Esta sección describe las políticas establecidas por el personal de Mozilla MDN para controlar el contenido de MDN Web Docs. Se espera que todos los colaboradores de MDN Web Docs cumplan con estas políticas. + +### Relevancia + +Todo el contenido de MDN Web Docs debe ser relevante para la sección de tecnología en la que aparece. El spam (publicidad comercial) y otros contenidos irrelevantes nunca serán aceptados en el sitio. Los colaboradores que sigan intentando enviar spam pueden ser expulsados de MDN a discreción del personal de Mozilla MDN. + +Los enlaces salientes a sitios comerciales que sean relevantes para el tema desde el que se enlazan se evaluarán caso por caso. Su valor para ayudar a los desarrolladores web debe superar el beneficio comercial del sitio vinculado. + +### Neutralidad + +Los artículos en MDN Web Docs deben mantener un [punto de vista neutral](https://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view), informando sobre las variaciones del navegador sin sesgo editorial. No se aceptan comentarios despectivos sobre ningún navegador o agente de usuario. + +### Estandarización + +Las tecnologías web que se documentarán en MDN Web Docs deben estar en una pista estándar y deben ser implementadas por al menos un motor de renderizado. Las variaciones en el soporte del navegador se documentan en la sección [Compatibilidad con los navegadores](/es/docs/MDN/Writing_guidelines/Page_structures/Compatibility_tables) de un artículo. + +## Sugerir contenido + +Si desea sugerir contenido para MDN Web Docs, asegúrese de leer esta página antes de enviarlo para asegurarse de que lo que está sugiriendo sea apropiado. + +Para nuevas páginas o guías de referencia, abre un [nuevo _issue_](https://github.com/mdn/mdn/issues/new/choose) que describa qué contenido sugieres y por qué (sé lo más explícito posible). + +Para sugerir proyectos más grandes que involucren nuevas secciones de contenido, consulte la página [Criterios de inclusión](/es/docs/MDN/Writing_guidelines/What_we_write/Criteria_for_inclusion), que también describe el proceso de solicitud. + +## Temas que pertenecen a MDN Web Docs + +En general, si se trata de una tecnología web abierta, la documentamos en MDN Web Docs. Esto incluye cualquier característica que pueda ser utilizada por los desarrolladores web para crear sitios web y aplicaciones, ahora y en un futuro próximo. + +Si una función es implementada por varios navegadores y aceptada como estándar o está avanzando hacia la estandarización, entonces sí, definitivamente la documentamos aquí. Si una función sigue siendo muy experimental y no se implementa en varios navegadores y/o puede cambiar, entonces sigue siendo adecuada para su inclusión, pero es posible que no se considere una prioridad para que el equipo de redacción trabaje en ella. + +En otras palabras, las tecnologías web que se documentarán en MDN Web Docs deben cumplir los siguientes criterios: + +- Estar en una pista estándar. +- Estar especificado en una especificación publicada por un organismo de normalización fiable. +- Ser implementado por al menos un motor de renderizado. +- Se lanzará en una versión de navegador estable. + +Nuestro objetivo principal es escribir sobre las siguientes tecnologías web front-end: + +- [HTML](/es/docs/Web/HTML) +- [CSS](/es/docs/Web/CSS) +- [JavaScript](/es/docs/Web/JavaScript) +- [APIs Web](/es/docs/Web/API) +- [HTTP](/es/docs/Web/HTTP) + +También documentamos algunos temas más amplios, como [SVG](/es/docs/Web/SVG), [XML](/es/docs/Web/XML), [WebAssembly](/es/docs/WebAssembly) y [Accesibilidad](/es/docs/Learn/Accessibility). Además, proporcionamos extensas [guías de aprendizaje](/es/docs/Learn) para estas tecnologías y también un [glosario](/es/docs/Glossary). + +> **Nota:** Las tecnologías de backend generalmente tienen su propia documentación en otro lugar que MDN Web Docs no intenta reemplazar, aunque [tenemos algunas excepciones](/es/docs/Learn/Server-side). + +Todo el contenido de MDN Web Docs debe ser relevante para la sección de tecnología en la que aparece. Se espera que los colaboradores sigan estas [pautas de escritura de MDN](/es/docs/MDN/Writing_guidelines) para el estilo de escritura, las muestras de código y otros temas. + +Para obtener más detalles sobre los criterios para documentar o no una tecnología en MDN Web Docs, consulte la página [Criterios de inclusión](/es/docs/MDN/Writing_guidelines/What_we_write/Criteria_for_inclusion). + +### Cuando documentamos una nueva tecnología + +En MDN Web Docs, buscamos constantemente documentar las nuevas tecnologías de estándares web según corresponda. +Tratamos de encontrar un equilibrio entre publicar la documentación lo suficientemente pronto para que los desarrolladores puedan conocer las nuevas funciones tan pronto como lo necesiten y publicarla lo suficientemente tarde para que la tecnología esté madura y estable para que la documentación no necesite actualizaciones constantes o eliminación rápida. + +En general, nuestra definición de lo más pronto que consideraremos documentar una nueva tecnología es: _Cuando la función está en una pista de estándares y se implementa en algún lugar._ + +Consideramos documentar una nueva tecnología si: + +- Está especificada en un documento de especificación publicado bajo una organización de estándares confiable (como W3C, WHATWG, Khronos, IETF, etc.) y ha alcanzado un nivel razonable de estabilidad (por ejemplo, un borrador de trabajo del W3C o una recomendación candidata o cuando la especificación se ve bastante estable a juzgar por el flujo de problemas presentados en su contra). +- Está implementada consistentemente en al menos un navegador, con otros desarrolladores de navegadores mostrando signos de interés (como un ticket activo o un proceso de "intención de implementar" está en efecto). + +No documentamos una nueva tecnología si: + +- No tiene una especificación o la especificación es una nota aproximada que parece susceptible de cambiar. +- Uno o ningún navegador lo han implementado actualmente y los navegadores no compatibles no muestran signos de interés en implementarlo. Puede medir esto preguntando a los ingenieros que trabajan en esos navegadores y mirando los rastreadores de errores del navegador y las listas de correo, etc. +- No es una tecnología expuesta en la web y/o es completamente propietaria. +- Ya está mostrando signos de ser obsoleta o reemplazada por una función similar. + +## Temas que no pertenecen a MDN Web Docs + +En general, cualquier cosa que no sea un estándar web abierto no pertenece a MDN Web Docs. El spam (publicidad comercial) y otros contenidos irrelevantes nunca serán aceptados en el sitio. Los colaboradores que sigan intentando enviar spam pueden ser expulsados de MDN a discreción del personal de Mozilla MDN. + +Algunos ejemplos de temas inapropiados para MDN Web Docs son: + +- Tecnología que no está expuesta a la web y es específica de un navegador. +- Tecnología no relacionada con la web. +- Documentación para usuarios finales. Para los productos Mozilla, por ejemplo, dicha documentación pertenece al [sitio de soporte de Mozilla](https://support.mozilla.org). +- Enlaces externos de autoenlace o autopromoción. Consulta estas pautas en nuestra [guía de estilo de escritura](/es/docs/MDN/Writing_guidelines/Writing_style_guide#external_links) antes de añadir un enlace externo. + +### Cuando eliminamos documentación + +Las páginas se eliminan de MDN Web Docs si ya no contienen información que es útil de alguna manera, están lo suficientemente desactualizadas o pueden ser incorrectas hasta el punto de que mantenerlas puede ser engañoso. + +Los siguientes ejemplos describen situaciones en las que se pueden eliminar páginas/contenido: + +- Los artículos contienen información sobre funciones que no se implementaron en todos los navegadores y que luego se retiraron (generalmente funciones experimentales, como la funcionalidad con prefijo). +- Las páginas de referencia describen características que se eliminaron de la especificación antes de implementarse en cualquier navegador. +- Los artículos cubren técnicas que luego se demostró que eran malas prácticas y fueron reemplazadas por mejores técnicas. +- Los artículos contienen información que luego fue reemplazada por otros artículos de mejor calidad. +- Los artículos contienen contenido inapropiado para MDN Web Docs. +- Las secciones de MDN Web Docs no se centran en tecnologías web abiertas y son una carga de mantenimiento. + +Para obtener más información sobre _cómo_ eliminar documentos, consulta la guía [Crear, mover y eliminar páginas](/es/docs/MDN/Writing_guidelines/Howto/Creating_moving_deleting). + +## Tipos de documentos permitidos en MDN Web Docs + +En general, nuestra documentación se clasifica en las siguientes categorías: + +- Referencias +- Guías +- Glosarios +- Aprender/Tutoriales + +En general, MDN Web Docs es para la documentation de _productos_, no para documentation de _proyectos_ o _procesos_. Entonces, si el documento trata sobre "cómo usar una cosa" o "cómo funciona una cosa" (donde, la "cosa" está en una de las categorías de temas mencionadas anteriormente), entonces puede ir a MDN Web Docs. + +Si un documento trata sobre "quién está trabajando en el desarrollo de una cosa" o "planes para desarrollar una cosa", entonces no debería ir en MDN Web Docs. + +Estos son algunos ejemplos de tipos de documentos que no deberían colocarse en MDN Web Docs: + +- Documentos de planificación +- Documentos de diseño +- Propuestas de proyectos +- Especificaciones o normas +- Material promocional, publicidad o información personal diff --git a/files/es/web/api/node/removechild/index.md b/files/es/web/api/node/removechild/index.md index 855ed6653a1d41..ff21049e1a1722 100644 --- a/files/es/web/api/node/removechild/index.md +++ b/files/es/web/api/node/removechild/index.md @@ -1,98 +1,123 @@ --- -title: Node.removeChild() +title: "Node: Método removeChild()" +short-title: removeChild() slug: Web/API/Node/removeChild +l10n: + sourceCommit: 56c76424a5edb45f6716ac4ee48861dac8e7ae38 --- -{{APIRef ( "DOM")}} +{{APIRef("DOM")}} -El método **`Node.removeChild()`** elimina un nodo hijo del DOM y puede devolver el nodo eliminado. +El método **`removeChild()`** de la interfaz {{domxref("Node")}} elimina un nodo hijo del DOM y devuelve el nodo eliminado. -## Sintaxis - -``` -var antiguoHijo = elemento.removeChild(child); -O -elemento.removeChild(child); -``` +> **Nota:** Mientras se mantenga una referencia sobre el elemento hijo eliminado, seguirá existiendo en la memoria, pero ya no forma parte del DOM. Todavía se puede reutilizar más adelante en el código. +> +> Si el valor devuelto de `removeChild()` no se almacena y no se guarda ninguna otra referencia, se [eliminará automáticamente](/es/docs/Web/JavaScript/Memory_management) de la memoria al cabo de un breve tiempo. -- `child` es el nodo hijo a eliminar del DOM. -- `elemento` es el nodo padre de `hijo`.(ver nota mas abajo) -- `antiguoHijo` tiene una referencia al hijo eliminado. `antiguoHijo === child`. +A diferencia de {{domxref("Node.cloneNode()")}}, el valor devuelto conserva los objetos `EventListener` asociados con él. -El hijo(child) eliminado aún existe en memoria pero ya no es parte del DOM. Con la primera forma de sintaxis mostrada, se puede reutilizar el nodo eliminado más tarde en el código, por medio de la referencia al objeto `antiguoHijo`. Sin embargo, en la segunda forma, la referencia a `antiguoHijo` se pierde, y suponiendo que el código no mantenga una referencia a ese objeto en alguna otra parte, inmediatamente será inutilizable e irrecuperable y será [eliminada automáticamente](/es/docs/Web/JavaScript/Gestion_de_Memoria)de memoria después de poco tiempo. - -Si hijo(`child)` no es en realidad hijo del nodo `elemento`, el método lanza una excepción. Esto también sucederá si `child` es en realidad hijo de `elemento` al momento de llamar al método, pero fue eliminado por un controlador(manejador) de eventos(event handler) invocado en el curso de tratar de eliminar el elemento. (e.g. blur). +## Sintaxis -Por lo tanto el método removeChild(child) lanza una excepción de 2 casos diferentes: +```js-nolint +removeChild(child) +``` -1\. Si child es un hijo del elemento y por lo tanto existe en el DOM, pero se retiró el método lanza la siguiente excepción: +### Parámetros -`Uncaught NotFoundError: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node`. +- `child` + - : Un {{domxref("Node")}} que es el nodo hijo que se eliminará del DOM. -2\. Si `child` no existe en el DOM de la página, el método emite la siguiente excepción: +### Excepción -`Uncaught TypeError: Failed to execute 'removeChild' on 'Node': parameter 1 is not of type 'Node'.` +- `NotFoundError` {{domxref("DOMException")}} + - : Se lanza si `child` no es un hijo del nodo. +- {{jsxref("TypeError")}} + - : Se lanza si `child` es `null`. ## Ejemplos -```html - -
-``` +### Ejemplos simples -```js - -// El método lanza la excepción correspondiente al (caso 2) -var top = document.getElementById("top"); -var nested = document.getElementById("nested"); -var garbage = top.removeChild(nested); -``` +Dado este HTML: ```html - -
-
+
+
``` +Para eliminar un elemento específico cuando se conoce su nodo principal: + ```js - -// Eliminando un elemento específico cuando se conoce su nodo padre -var d = document.getElementById("top"); -var d_nested = document.getElementById("anidados"); -var throwawayNode = d.removeChild(d_nested); +const parent = document.getElementById("parent"); +const child = document.getElementById("child"); +const throwawayNode = parent.removeChild(child); ``` +Para eliminar un elemento específico sin tener que especificar su nodo principal: + ```js - -// Eliminando un elemento específico utilizando la propiedad parentNode, que siempre hace referencia al nodo padre de un nodo (nodoHijo.parentNode.). -nodo var = document.getElementById("anidados"); +const node = document.getElementById("child"); if (node.parentNode) { - node.parentNode.removeChild(nodo); + node.parentNode.removeChild(node); } ``` +Para eliminar todos los hijos de un elemento: + ```js - -// Eliminando todos los hijos de un elemento -elemento var = document.getElementById("top"); +const element = document.getElementById("idOfParent"); while (element.firstChild) { element.removeChild(element.firstChild); } ``` -## Notas +### Causar un TypeError + +```html + +
+``` + +```js +const parent = document.getElementById("parent"); +const child = document.getElementById("child"); + +// Arroja Uncaught TypeError +const garbage = parent.removeChild(child); +``` + +### Causar un NotFoundError + +```html + +
+
+
+``` + +```js +const parent = document.getElementById("parent"); +const child = document.getElementById("child"); + +// Esta primera llamada elimina correctamente el nodo. +const garbage = parent.removeChild(child); + +// Arroja NotFoundError +garbage = parent.removeChild(child); +``` + +## Especificaciones -**`removeChild()`** se debe invocar sobre el nodo padre del nodo que se va a eliminar. +{{Specifications}} -## Especificación +## Compatibilidad con navegadores -- [DOM Nivel 1 Core: removeChild](http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#method-removeChild) -- [DOM Nivel 2 Core: removeChild](http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1734834066) -- [DOM Nivel 3 Core: removeChild](http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1734834066) +{{Compat}} -## Vea también +## Véase también -- {{Domxref ( "Node.replaceChild")}} -- {{Domxref ( "Node.parentNode")}} -- {{Domxref ( "ChildNode.remove")}} +- {{domxref("Node.replaceChild()")}} +- {{domxref("Node.parentNode")}} +- {{domxref("Element.remove()")}} +- {{domxref("Node.cloneNode()")}} diff --git a/files/es/web/http/headers/strict-transport-security/index.md b/files/es/web/http/headers/strict-transport-security/index.md index 24174b146baf4e..fd44344cb2145c 100644 --- a/files/es/web/http/headers/strict-transport-security/index.md +++ b/files/es/web/http/headers/strict-transport-security/index.md @@ -36,7 +36,7 @@ Esto habilita el potencial ataque man-in-the-middle, donde el redireccionamiento El encabezado HTTP Strict Transport Security permite a un sitio web informar al navegador que nunca cargue el sitio usando HTTP y que debe automáticamente convertir todos los intentos de acceso HTTP a HTTPS. -> **Nota:** El encabezado `Strict-Transport-Security` es **ignorado** por el navegador cuando el sitio es accedido usando HTTP; esto es porque un atacante podría interceptar las conexines HTTP e inyectar el encabezado o removerlo. Cuando el sitio es accedido a través de HTTPS con un certificado sin errores, el navegador sabe que el sitio es capaz de usar HTTPS y cumple con lo indicado en el encabezado `Strict-Transport-Security`. +> **Nota:** El encabezado `Strict-Transport-Security` es **ignorado** por el navegador cuando el sitio es accedido usando HTTP; esto es porque un atacante podría interceptar las conexiones HTTP e inyectar el encabezado o removerlo. Cuando el sitio es accedido a través de HTTPS con un certificado sin errores, el navegador sabe que el sitio es capaz de usar HTTPS y cumple con lo indicado en el encabezado `Strict-Transport-Security`. ### Un escenario de ejemplo diff --git a/files/es/web/http/overview/index.md b/files/es/web/http/overview/index.md index b141b6ac063595..f43a18caa7ecd1 100644 --- a/files/es/web/http/overview/index.md +++ b/files/es/web/http/overview/index.md @@ -146,7 +146,7 @@ Un ejemplo de repuesta: ![](http_response.png) -Las respuestas están formadas por los siguentes campos: +Las respuestas están formadas por los siguientes campos: - La versión del protocolo HTTP que están usando. - Un código de estado, indicando si la petición ha sido exitosa, o no, y debido a que. @@ -156,6 +156,6 @@ Las respuestas están formadas por los siguentes campos: ## Conclusión -El protocólo HTTP es un protocolo ampliable y fácil de usar. Su estructura cliente-servidor, junto con la capacidad para usar cabeceras, permite a este protocolo evolucionar con las nuevas y futuras aplicaciones en Internet. +El protocolo HTTP es un protocolo ampliable y fácil de usar. Su estructura cliente-servidor, junto con la capacidad para usar cabeceras, permite a este protocolo evolucionar con las nuevas y futuras aplicaciones en Internet. Aunque la versión del protocolo HTTP/2 añade algo de complejidad, al utilizar un formato en binario, esto aumenta su rendimiento, y la estructura y semantica de los mensajes es la misma desde la versión HTTP/1.0. El flujo de comunicaciones en una sesión es sencillo y puede ser fácilmente estudiado e investigado con un simple [monitor de mensajes HTTP](/es/docs/Tools/Network_Monitor). diff --git a/files/fr/learn/accessibility/wai-aria_basics/index.md b/files/fr/learn/accessibility/wai-aria_basics/index.md index b20dda9a308995..aabe5a52cbbb91 100644 --- a/files/fr/learn/accessibility/wai-aria_basics/index.md +++ b/files/fr/learn/accessibility/wai-aria_basics/index.md @@ -1,203 +1,202 @@ --- title: Les bases de WAI-ARIA slug: Learn/Accessibility/WAI-ARIA_basics +l10n: + sourceCommit: ebd38013d2af33dd860b50cee59802661aa3c966 --- {{LearnSidebar}}{{PreviousMenuNext("Learn/Accessibility/CSS_and_JavaScript","Learn/Accessibility/Multimedia", "Learn/Accessibility")}} -Après l'article précédent, il peut être difficile de créer des contrôles UI complexes impliquant du code HTML non sémantique et du contenu dynamique mis à jour par JavaScript. WAI-ARIA est une technologie qui peut aider à résoudre de tels problèmes en ajoutant une sémantique supplémentaire que les navigateurs et les technologies d'assistance peuvent reconnaître et utiliser pour informer les utilisateurs de ce qui se passe. Nous montrerons ici comment l'utiliser au niveau de base pour améliorer l'accessibilité. +Nous avons vu dans l'article précédent qu'il pouvait être difficile de créer des contrôles d'interface complexes à l'aide de HTML non-sémantique et dont le contenu est géré en JavaScript. WAI-ARIA est une technologie qui aide à résoudre ces problèmes en ajoutant une couche sémantique supplémentaire qui peut être utilisée par les navigateurs et les outils d'assistance pour indiquer à la personne ce dont il s'agit. Dans cet article, nous verrons comment l'utiliser à un premier niveau pour améliorer l'accessibilité. - +
- + - +
Prerequis:Prérequis : - Connaissances informatiques de base, une compréhension de base de HTML, - CSS et JavaScript, une compréhension des - articles précédents du cours. + Notions de base en informatique, compréhension élémentaire de HTML, CSS et JavaScript, compréhension des articles précédent de ce module.
Objectif :Objectifs : - Se familiariser avec WAI-ARIA et savoir comment l'utiliser pour fournir - une sémantique supplémentaire utile afin d'améliorer l'accessibilité, le - cas échéant. + Se familiariser avec WAI-ARIA et apprendre comment il peut être utilisé pour fournir une couche sémantique complémentaire utile, permettant d'améliorer l'accessibilité aux endroits nécessaires.
-## Qu'est WAI-ARIA? +## Qu'est-ce que WAI-ARIA ? -Commençons par regarder ce que WAI-ARIA est , et ce qu'il peut faire pour nous. +Commençons par définir ce qu'est WAI-ARIA et par voir ce qu'il peut apporter. -### Un nouvel ensemble de problèmes +### Une nouvelle classe de problème -Car les applications web ont commencé à devenir plus complexes et dynamiques, un nouvel ensemble de fonctionnalités d'accessibilité et de problèmes ont commencé à apparaître. +Dès lors que les applications web ont gagné en complexité et en dynamisme, certains problèmes et certaines fonctionnalités d'accessibilité sont apparus. -Par exemple, HTML5 a introduit un certain nombre d'éléments sémantiques pour définir des fonctionnalités de page communes ({{htmlelement("nav")}}, {{htmlelement("footer")}}, etc.) Avant de les utiliser, les développeurs utilisaient simplement {{htmlelement("div")}} s avec des identifiants ou des classes, par exemple `
` , mais ils posaient problème, car il n'existait pas de moyen facile de trouver facilement une fonctionnalité de page spécifique telle que la navigation principale par programmation. . +HTML a par exemple introduit différents éléments sémantiques pour les composants génériques d'une page ([`