From 9cebbc49c1c7b098636f4914914e7d5c3fad775c Mon Sep 17 00:00:00 2001 From: SphinxKnight Date: Thu, 11 Nov 2021 06:41:24 +0100 Subject: Prepare MDN section for Markdown conversion (#3008) * Remove summary / seoSummary * Remove hidden blocks or outdate pages in a yari world * Remove spans * Remove notranslate * Remove ids * fix notes and warnings * fix dls * Fix various errors * fix images --- .../mdn/structures/compatibility_tables/index.html | 501 --------------------- files/fr/mdn/structures/live_samples/index.html | 14 +- .../macros/commonly-used_macros/index.html | 6 +- files/fr/mdn/structures/macros/index.html | 9 +- 4 files changed, 14 insertions(+), 516 deletions(-) delete mode 100644 files/fr/mdn/structures/compatibility_tables/index.html (limited to 'files/fr/mdn/structures') diff --git a/files/fr/mdn/structures/compatibility_tables/index.html b/files/fr/mdn/structures/compatibility_tables/index.html deleted file mode 100644 index 43baa5309a..0000000000 --- a/files/fr/mdn/structures/compatibility_tables/index.html +++ /dev/null @@ -1,501 +0,0 @@ ---- -title: Tables de compatibilité -slug: MDN/Structures/Compatibility_tables -tags: - - Compatibilité - - Documentation - - Guide - - MDN - - Navigateurs -translation_of: MDN/Structures/Compatibility_tables -original_slug: MDN/Structures/Tables_de_compatibilité ---- -
{{MDNSidebar}}
{{IncludeSubnav("/en-US/docs/MDN")}}
- -

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

- -
-

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

-
- -
-

Note : Si vous avez besoin d'aide sur les étapes de ce guide, n'hésitez pas à nous contacter sur le forum de discussion MDN (en).

-
- -

Comment accéder au dépôt de données

- -

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

- -

Choisir une fonctionnalité pour y ajouter des données

- -

Tout d'abord, cherchez une fonctionnalité pour laquelle vous souhaitez ajouter des données de navigateur. Cela peut être un élément HTML, une propriété CSS, une fonctionnalité du langage JS ou une interface d'API JS, par exemple. Nous aimerions vous encourager à travailler sur les fonctionnalités de l'API, car nous avons déjà des personnes travaillant sur HTML, JS et CSS. Vous pouvez trouver le statut des fonctionnalités qui ont besoin de leurs données en ajoutant au dépôt sur notre tableur Browser Compat Data migration (migration des données des tables de compatibilité des navigateurs).

- -

Le processus d'utilisation est le suivant :

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

Préparation à l'ajout de données

- -

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

- -

Regardons un moyen simple de nous assurer que votre fourche est à jour :

- -

Ajout d'un "remote" au dépôt principal navigateur-compat-données

- -

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

- -
git remote add upstream https://github.com/mdn/browser-compat-data.git
- -

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

- -
git remote -v
- -

Mise à jour de votre branche avec le contenu du "remote"

- -

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

- -
    -
  1. -

    Vous assurant que vous êtes dans la branche maîtresse :

    - - 
          git checkout master
    -
    2. -
  2. -

    Allant chercher le contenu du dépôt à jour avec la commande suivante :

    - - 
          git fetch upstream
    -
    3. -
  3. -

    Rebasant le contenu de votre branche maîtresse avec le contenu du dépôt principal :

    - - 
          git rebase upstream/master
    -
    4. -
  4. -

    poussant ces mises à jour de votre branche distante en utilisant ce :

    - - 
        git push -f
-
    -
    5. -
- -

Création d'une nouvelle branche pour y travailler

- -

Ensuite, allez sur votre fourche distante (elle doit être à https://github.com/your-username/browser-compat-data) et créer une nouvelle branche pour stocker vos modifications pour cet ajout de données. Ceci peut être fait en:

- -
    -
  1. Cliquant sur le bouton "Branch: Master".
    2. -
  2. Saisissant le nom de votre nouvelle branche dans le champ texte "Find or create a branch...".
    3. -
  3. Cliquant sur le bouton "Create branch name-of-branch from Master" qui vient d'être généré.
    4. -
- -

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

- -

Aller sur la nouvelle branche

- -

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

- -
git pull
- -

Maintenant allez sur votre nouvelle branche en utilisant:

- -
git checkout -b name-of-branch
- -

Vous devriez maintenant être prêt à ajouter vos données!

- -

Ajouter les données

- -

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

- - - -
-

Note: Vous remarquerez que le dépôt contient aussi des données pour les Extensions de navigateurs et pour HTTP. Ces ensembles de données sont esssentiellement finis en l'état, mais il faudra peut-être ajouter d'autres fonctionnalités à l'avenir.

-
- -

Chaque fichier que vous créez doit suivre le modèle défini dans le schéma contenu dans notre dépôt; vous pouvez voir la description détaillée du schema ici.

- -

Structure basique des données de compatibilité

- -

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

- -
{
-  "css": {
-    "properties": {
-      "border-width": {
-        "__compat": {
-          ...
-        }
-      }
-    }
-  }
-}
- -

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

- -

Les données ci-dessus se trouvent dans le fichier border-width.json — comparez les à la  table de support de border-width disponible sur MDN.

- -

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

- - - -
-

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

- -

Structure de base à l'intérieur d'une fonctionnalité

- -

Dans un membre __compat, vous devez inclure les membres suivants:

- - - -

Les noms des membres pour le navigateur sont définis dans le schéma (voir Browser identifiers). Vous devez utiliser la liste complète des identifiants actuellement définis. Si vous souhaitez ajouter un navigateur, parlez-nous en d'abord, car cela pourrait avoir un impact important et ne devrait pas être fait sans une réflexion approfondie.

- -

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

- - - -

A l'intérieur du membre status, vous inclurez trois sous-membres:

- - - -

Les données pour la propriété border-width (voir aussi border-width.json) sont présentées ci-dessous à titre d'exemple:

- -
"__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
-  }
-}
- -

Ajouter une description

- -

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

- -
{
-  "api": {
-    "AbortController": {
-      "__compat": {
-        ...
-      },
-      "AbortController": {
-        "__compat": {
-          "mdn_url": "https://developer.mozilla.org/docs/Web/API/AbortController/AbortController",
-          "description": "<code>AbortController()</code> constructor",
-          "support": {
-            ...
-          }
-        }
-      }
-
-      ... etc.
-    }
-  }
-}
- -

Sub-features

- -

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

- -

As an example, see the compat data and corresponding MDN page for the background-color property. The basic support exists inside the __compat object as explained above, then you have an additional row for browsers' support for "alpha channel for hex values", which contains its own __compat object.

- -
{
-  "css": {
-    "properties": {
-      "background-color": {
-        "__compat": {
-          ...
-        },
-        "alpha_ch_for_hex": {
-          "__compat": {
-            ...
-          },
-        }
-      }
-    }
-  }
-}
- -

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

- -
{
-  "api": {
-    "VRDisplay": {
-      "__compat": {
-        ...
-      },
-      "cancelAnimationFrame": {
-        "__compat": {
-          ...
-        }
-      },
-      "capabilities": {
-        "__compat": {
-          ...
-        }
-      },
-
-      ... etc.
-
-    }
-  }
-}
- -

See VRDisplay.json for a full example.

-
- -

Adding data: Advanced cases

- -

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

- -

Including a footnote

- -

Often compat tables will include footnotes related to certain entries that explain useful details or strange behavior that developers will find useful. As an example, the Chrome Android entry for {{domxref("VRDisplay.capabilities")}} (see also VRDisplay.json)  (at the time of writing) had a footnote "Currently supported only by Google Daydream." To include this in the capabilities data, we added a "notes" submember inside the relevant "chrome_android" submember; it would look like this:

- -
"chrome_android": {
-  "version_added": true,
-  "notes": "Currently supported only by Google Daydream."
-}
- -

Including a vendor prefix

- -

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

- -
"firefox": {
-  "version_added": true,
-  "prefix": "-moz-"
-}
- -

Including browser preferences or flags

- -

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

- -

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

- - - -

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

- -
"chrome": {
-  "version_added": "50",
-  "flags": [
-    {
-      "type": "preference",
-      "name": "Enable Experimental Web Platform Features",
-      "value_to_set": "true"
-    }
-  ]
-},
- -

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

- -
"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"
-    }
-  ]
-},
- -

Including a version where support was removed

- -

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

- -
"firefox": {
-  "version_added": "35",
-  "version_removed": "47",
-},
- -

Including multiple support points for the same browser entry

- -

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

- -

As an example, the {{cssxref("text-align-last")}} property (see also text-align-last.json) was added to Chrome in version 35, supported behind a pref.

- -

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

- -

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

- -
"chrome": [
-  {
-    "version_added": "47"
-  },
-  {
-    "version_added": "35",
-    "version_removed": "47",
-    "flags": [
-      {
-        "type": "preference",
-        "name": "Enable Experimental Web Platform Features",
-        "value_to_set": "true"
-      }
-    ]
-  }
-],
- -
-

Note: You should put the most current or important support point first in the array — this makes the data easier to read for people who just want to scan it for the latest info.

-
- -

Including an alternative name

- -

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

- -

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

- -
-

Note: The alternative name might not be an exact alias — it might have differing behaviour to the standard version.

-
- -

Let's look at an example. The {{cssxref("border-top-right-radius")}} property (see also border-top-right-radius.json) was supported in Firefox:

- - - -

To represent this in the data, we used the following JSON:

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

Pushing a change back to the main repo

- -

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

- - - -

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

- -
git add .
-git commit -m 'adding compat data for name-of-feature'
-git push
- -

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

- -

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

- -

Inserting the data into MDN pages

- -

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

- -

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

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

As an example, on the {{httpheader("Accept-Charset")}} HTTP header page, the macro call looks like this: \{{Compat("http.headers.Accept-Charset")}}. If you look at the accept-charset.json file in the repo, you'll see how this is reflected in the JSON data.

- -

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

- -
- -

{{Compat("api.VRDisplay.capabilities")}}

- -
-

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

-
diff --git a/files/fr/mdn/structures/live_samples/index.html b/files/fr/mdn/structures/live_samples/index.html index 57f7054827..c297eac680 100644 --- a/files/fr/mdn/structures/live_samples/index.html +++ b/files/fr/mdn/structures/live_samples/index.html @@ -33,9 +33,8 @@ original_slug: MDN/Structures/Exemples_live

Le cadre (ou la page) qui en résulte est protégé par un bac à sable, sécurisé, et peut techniquement faire tout ce qui fonctionne sur le Web. Bien sûr, d'un point de vue pratique, le code doit contribuer à l'intérêt de la page qui le contient ; les trucs aléatoires qui tournent sur MDN seront supprimés par la communauté des éditeurs.

-
-

Note :

-

Vous devez utiliser la macro pour présenter la sortie de l'échantillon en direct.

+
+

Note : Vous devez utiliser la macro pour présenter la sortie de l'échantillon en direct.

Chaque bloc <pre> contenant du code pour l'échantillon est doté d'une classe qui indique s'il s'agit de code HTML, CSS ou JavaScript ; ces classes sont « brush : html », « brush : css » et « brush : js ». Ces classes doivent se trouver sur les blocs de code correspondants.

@@ -69,8 +68,8 @@ original_slug: MDN/Structures/Exemples_live
page_slug

Le slug de la page contenant l'échantillon ; ceci est facultatif, et s'il n'est pas fourni, l'échantillon est tiré de la même page sur laquelle la macro est utilisée.

-
- Attention : Pour afficher un échantillon en direct d'une page contenant du code dans une page cible différente, la page contenant du code doit elle-même utiliser la macro EmbedLiveSample pour intégrer un échantillon en direct dans sa propre page. Sinon, si la page contenant le code n'utilise pas elle-même la macro EmbedLiveSample sa propre page, l'échantillon vivant ne s'affichera pas du tout sur la page cible. (Voir Le ticket Yari #2243.) +
+

Attention : Pour afficher un échantillon en direct d'une page contenant du code dans une page cible différente, la page contenant du code doit elle-même utiliser la macro EmbedLiveSample pour intégrer un échantillon en direct dans sa propre page. Sinon, si la page contenant le code n'utilise pas elle-même la macro EmbedLiveSample sa propre page, l'échantillon vivant ne s'affichera pas du tout sur la page cible. (Voir Le ticket Yari #2243.)

@@ -100,9 +99,8 @@ original_slug: MDN/Structures/Exemples_live

Chaque morceau de code doit se trouver dans un bloc <pre>, avec un bloc distinct pour chaque langue, correctement marqué quant à sa langue. La plupart du temps, cela a déjà été fait, mais il est toujours utile de revérifier pour s'assurer que chaque morceau de code est configuré avec la bonne syntaxe. Ceci est fait avec une classe sur l'élément <pre> de brush:language-type, où language-type est le type de langage que le bloc contient, par exemple html, css, ou js.

-
-

Note :

-

Vous pouvez avoir plus d'un bloc pour chaque langue ; ils sont tous concaténés ensemble. Vous pouvez ainsi avoir un morceau de code, suivi d'une explication de son fonctionnement, puis un autre morceau, et ainsi de suite. Il est ainsi encore plus facile de produire des didacticiels et autres qui utilisent des échantillons en direct entrecoupés de texte explicatif.

+
+

Note : Vous pouvez avoir plus d'un bloc pour chaque langue ; ils sont tous concaténés ensemble. Vous pouvez ainsi avoir un morceau de code, suivi d'une explication de son fonctionnement, puis un autre morceau, et ainsi de suite. Il est ainsi encore plus facile de produire des didacticiels et autres qui utilisent des échantillons en direct entrecoupés de texte explicatif.

Assurez-vous donc que les blocs <pre> de votre code HTML, CSS et/ou JavaScript sont chacun configurés correctement pour la coloration syntaxique de ce langage, et vous êtes prêt à partir.

diff --git a/files/fr/mdn/structures/macros/commonly-used_macros/index.html b/files/fr/mdn/structures/macros/commonly-used_macros/index.html index 71fcc8672d..4aaeb81c61 100644 --- a/files/fr/mdn/structures/macros/commonly-used_macros/index.html +++ b/files/fr/mdn/structures/macros/commonly-used_macros/index.html @@ -5,7 +5,7 @@ translation_of: MDN/Structures/Macros/Commonly-used_macros ---
{{MDNSidebar}}
-

Cette page présente un grand nombre de macros à usage général créées pour une utilisation avec MDN. Pour avoir des informations sur l'utilisation de ces macros, voir Utilisation des macros et Utiliser les liens macros . Voir les autres macros pour avoir des informations sur les macros qui sont rarement utilisées, ou utilisées dans des contextes spécifiques, ou obsolètes. Il y a aussi une liste complète de toutes les macros MDN.

+

Cette page présente un grand nombre de macros à usage général créées pour une utilisation avec MDN. Pour avoir des informations sur l'utilisation de ces macros, voir Utilisation des macros et Utiliser les liens macros . Voir les autres macros pour avoir des informations sur les macros qui sont rarement utilisées, ou utilisées dans des contextes spécifiques, ou obsolètes. Il y a aussi une liste complète de toutes les macros MDN.

Voir aussi le Guide style CSS pour l'utilisation des styles disponibles.

@@ -13,7 +13,7 @@ translation_of: MDN/Structures/Macros/Commonly-used_macros

Création d'un lien hypertexte unique

-

En général, vous ne devez pas utiliser des macros pour créer des liens arbitraires. Utilisez le Lien dans l'interface de l'éditeur pour créer des liens.

+

En général, vous ne devez pas utiliser des macros pour créer des liens arbitraires. Utilisez le Lien dans l'interface de l'éditeur pour créer des liens.

  • La macro {{TemplateLink("Glossary")}} crée un lien vers une entrée du glossaire MDN. Cette macro accepte un paramètre obligatoire et deux optionnels: @@ -40,7 +40,7 @@ translation_of: MDN/Structures/Macros/Commonly-used_macros
    • {{TemplateLink("cssxref")}} links to a page in the CSS Reference. Example: \{{cssxref("cursor")}}, results in: {{ cssxref("cursor") }}.
      • -
    • {{TemplateLink("domxref")}} links to pages in the DOM reference; if you include parentheses at the end, the template knows to display the link to look like a function name. For example, \{{domxref("document.getElementsByName()")}} results in {{ domxref("document.getElementsByName()") }} while \{\{domxref("Node")\}\} results in {{ domxref("Node") }}.
      • +
    • {{TemplateLink("domxref")}} links to pages in the DOM reference; if you include parentheses at the end, the template knows to display the link to look like a function name. For example, \{{domxref("document.getElementsByName()")}} results in {{ domxref("document.getElementsByName()") }} while \{\{domxref("Node")\}\} results in {{ domxref("Node") }}.
    • {{TemplateLink("event")}} links to pages in the DOM Event reference, for example: \{{event("change")}} results in {{event("change")}}.
    • {{TemplateLink("HTMLElement")}} links to an HTML element in the HTML Reference.
    • {{TemplateLink("htmlattrxref")}} links to an HTML attribute, either a global attribute description if you only specify the attribute name or an attribute associated with a specific element if you specify an attribute name and an element name. For example, \{\{htmlattrxref("lang")\}\} will create this link: {{htmlattrxref("lang")}}.  \{\{htmlattrxref("type","input")\}\} will create this link: {{htmlattrxref("type","input")}}.
      • diff --git a/files/fr/mdn/structures/macros/index.html b/files/fr/mdn/structures/macros/index.html index 19060b70d8..448d6a4649 100644 --- a/files/fr/mdn/structures/macros/index.html +++ b/files/fr/mdn/structures/macros/index.html @@ -3,19 +3,20 @@ title: Macros slug: MDN/Structures/Macros translation_of: MDN/Structures/Macros --- -
      {{MDNSidebar}}

      La plate-forme Kuma sur laquelle MDN travail, fournit un système de macro, KumaScript, ce qui permet de faire une grande variété de choses automatiquement. Cet article fournit des informations sur la façon d'invoquer les macros MDN dans les articles.

      +
      {{MDNSidebar}}
      +

      La plate-forme Kuma sur laquelle MDN travail, fournit un système de macro, KumaScript, ce qui permet de faire une grande variété de choses automatiquement. Cet article fournit des informations sur la façon d'invoquer les macros MDN dans les articles.

      Le Guide KumaScript offre un regard en profondeur sur la façon d'utiliser des macros MDN, cette section est plus qu'un bref aperçu. Si vous avez déjà lu la section ci-dessus sur {{SectionOnPage ("/docs/fr/projet:MDN/Contribuer/Editor_guide/Links", "Utiliser les liens macros")}}, vous êtes un peu familiers avec le concept.

      Comment les macros sont-elle mises en œuvre

      -

      Macros sur MDN sont mis en œuvre en utilisant le serveur exécuté JavaScript code, interprété à l'aide de Node.js. En plus de cela, nous avons un certain nombre de bibliothèques, que nous avons mis en place pour fournir des services et des fonctionnalités orientées wiki, les macros interagissent avec la plate-forme wiki et avec son contenu. Si vous voulez en apprendre davantage, consultez le guide KumaScript; le KumaScript reference fournit des détails sur les bibliothèques et autres API KumaScript que nous avons mis en œuvre.

      +

      Macros sur MDN sont mis en œuvre en utilisant le serveur exécuté JavaScript code, interprété à l'aide de Node.js. En plus de cela, nous avons un certain nombre de bibliothèques, que nous avons mis en place pour fournir des services et des fonctionnalités orientées wiki, les macros interagissent avec la plate-forme wiki et avec son contenu. Si vous voulez en apprendre davantage, consultez le guide KumaScript; le KumaScript reference fournit des détails sur les bibliothèques et autres API KumaScript que nous avons mis en œuvre.

      Utiliser une macro dans le contenu

      Pour réellement utiliser une macro, vous placez simplement l'appel à la macro dans une paire de doubles acolades, avec ses paramètres, le cas échéant, entre parenthèses:

      -
      \{{macroname(parameter-list)}}
      +
      \{{macroname(parameter-list)}}

      Quelques notes sur les appels de macro:

      @@ -30,7 +31,7 @@ translation_of: MDN/Structures/Macros

      Les macros sont mis en cache; pour tout ensemble de valeurs d'entrée (les paramètres et les valeurs environnementales telles que l'URL pour laquelle la macro a été exécutée), les résultats sont stockés et réutilisés. Cela signifie que la macro est que effectivement parcourue que lorsque les entrées changent.

      -

      Remarque:. Vous pouvez forcer toutes les macros d'une page à être réévalué avec un shift-reload.

      +

      Note : Vous pouvez forcer toutes les macros d'une page à être réévalué avec un shift-reload.

      Les macros peuvent être aussi simple que d'insérer un plus grand bloc de texte ou d'échange dans le contenu d'une autre partie du MDN, ou aussi complexe que la construction de tout un index du contenu en cherchant dans des parties du site, coiffer la sortie, et en ajoutant des liens.

      -- cgit v1.2.3-54-g00ecf