From 30feb96f6084a2fb976a24ac01c1f4a054611b62 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:47:54 +0100 Subject: unslug it: move --- files/it/mdn/at_ten/index.html | 41 ++ files/it/mdn/community/index.html | 49 -- .../creating_and_editing_pages/index.html | 110 ----- .../howto/create_an_mdn_account/index.html | 49 -- .../howto/create_and_edit_pages/index.html | 110 +++++ .../contribute/howto/delete_my_profile/index.html | 24 - .../howto/do_a_technical_review/index.html | 50 --- .../howto/do_an_editorial_review/index.html | 46 -- .../index.html | 57 --- files/it/mdn/editor/index.html | 9 - .../guidelines/conventions_definitions/index.html | 34 ++ files/it/mdn/guidelines/macros/index.html | 42 -- .../it/mdn/guidelines/migliore_pratica/index.html | 34 -- .../mdn/structures/compatibility_tables/index.html | 496 +++++++++++++++++++++ files/it/mdn/structures/macros/index.html | 42 ++ .../tabelle_compatibilit\303\240/index.html" | 496 --------------------- 16 files changed, 723 insertions(+), 966 deletions(-) create mode 100644 files/it/mdn/at_ten/index.html delete mode 100644 files/it/mdn/community/index.html delete mode 100644 files/it/mdn/contribute/creating_and_editing_pages/index.html delete mode 100644 files/it/mdn/contribute/howto/create_an_mdn_account/index.html create mode 100644 files/it/mdn/contribute/howto/create_and_edit_pages/index.html delete mode 100644 files/it/mdn/contribute/howto/delete_my_profile/index.html delete mode 100644 files/it/mdn/contribute/howto/do_a_technical_review/index.html delete mode 100644 files/it/mdn/contribute/howto/do_an_editorial_review/index.html delete mode 100644 files/it/mdn/contribute/howto/impostare_il_riassunto_di_una_pagina/index.html delete mode 100644 files/it/mdn/editor/index.html create mode 100644 files/it/mdn/guidelines/conventions_definitions/index.html delete mode 100644 files/it/mdn/guidelines/macros/index.html delete mode 100644 files/it/mdn/guidelines/migliore_pratica/index.html create mode 100644 files/it/mdn/structures/compatibility_tables/index.html create mode 100644 files/it/mdn/structures/macros/index.html delete mode 100644 "files/it/mdn/structures/tabelle_compatibilit\303\240/index.html" (limited to 'files/it/mdn') diff --git a/files/it/mdn/at_ten/index.html b/files/it/mdn/at_ten/index.html new file mode 100644 index 0000000000..ab7c64d1ad --- /dev/null +++ b/files/it/mdn/at_ten/index.html @@ -0,0 +1,41 @@ +--- +title: 10 anni di MDN +slug: MDN_at_ten +tags: + - History + - Landing + - MDN Meta +translation_of: MDN_at_ten +--- +

Celebra 10 anni di documentazione Web.

+ +
+
+

La storia di MDN

+ +

All'inizio del 2005 una piccola squadra di idealisti si unì per creare una nuova raccolta di risorse per gli sviluppatori web che fosse gratuita e costruita dalla comunità. Dalla loro idea tanto brillante quanto anticonformista crebbe il Mozilla Developer Network che conosciamo oggi, ovvero la principale fonte di risorse per tutte le tecnologie web aperte. Dieci anni più tardi la nostra comunità globale è più grande che mai e continuiamo ancora a creare documentazione, codice d'esempio, risorse relative a tutte le tecnologie web open, incluse CSS, HTML e Javascript, e tutti gli strumenti che rendono l'open Web all'avanguardia.

+ +

Scopri di più about the history

+ + +

Collaborare a MDN

+ +

Da dieci anni la community di MDN sta documentando l'open Web. Dalla correzione di semplici errori di battitura fino ad arrivare allo sviluppo di API completamente nuove, tutti hanno qualcosa da offrire e non esistono contributi troppo piccoli o troppo grandi. MDN annovera oltre 90.000 pagine scritte o tradotte da membri della nostra fantastica comunità di Mozillians. Anche tu puoi diventare uno di loro, anzi, uno di noi.

+ +

Scopri di più about contributing

+ +

 

+ +

 

+
+ +
{{TenthCampaignQuote}}
+ +

Vedi anche

+ +
    +
  1. 10 anni di MDN
    2. +
  2. La storia di MDN
    3. +
  3. Contribuire a MDN
    4. +
+
diff --git a/files/it/mdn/community/index.html b/files/it/mdn/community/index.html deleted file mode 100644 index 14a121baca..0000000000 --- a/files/it/mdn/community/index.html +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Join the MDN community -slug: MDN/Community -translation_of: MDN/Community ---- -
{{MDNSidebar}}
- -

{{IncludeSubnav("/it-IT/docs/MDN")}}

- -
-

MDN (l'abbreviazione sta per Mozilla Developer Network) è più di un wiki: è una comunità di sviluppatore che lavorano insieme per rendere MDN una risorsa eccezionale per gli sviluppatori che usano le tecnologie web di tipo open.

-
- -

Ci fa piacere se contribuisci a MDN, ma ci piacerebbe ancora di più se tu partecipassi alla community di MDN. Ecco come puoi connetterti, in tre facili passi:

- -
    -
  1. Crea un account MDN.
    2. -
  2. Unisciti a una conversazione.
    3. -
  3. Segui ciò che avviene.
    4. -
- -

Come lavora la community

- -

Quelli che seguono sono articoli aggiuntivi per descrivere la community di MDN.

- -
-
-
-
Regole della Community
-
Ci sono alcuni ruoli nella community di MDN che hanno specifiche responsabilità.
-
Sprint di documentazione
-
Questa è una guida per organizzare uno sprint documentale. Contiene consigli e trucchi forniti da chi ne ha organizzati, per fare in modo che anche tu ne possa organizzarne uno.
-
Segui cosa succede
-
MDN ti viene proposto dalla community del Mozilla Developer Network. Questi sono alcuni modi che utilizziamo per condividere le informazioni circa ciò che facciamo.
-
- -
-
-
- -
-
-
Conversazioni nella community di MDN
-
Il "lavoro" di MDN avviene sul sito MDN, ma la "community" appare anche in discussioni (di tipo asincrono) e chat e meeting (di tipo sincrono).
-
Lavorare nella community
-
Una parte interessante nel contribuire alla documentazione di MDN a qualsiasi livello  è capire come lavorare come parte della community di MDN. Questo articolo offre consigli per aiutarti a gestire la maggior parte delle interazioni sia con altri autori che con team di sviluppo.
-
-
-
diff --git a/files/it/mdn/contribute/creating_and_editing_pages/index.html b/files/it/mdn/contribute/creating_and_editing_pages/index.html deleted file mode 100644 index 2ffa7888a4..0000000000 --- a/files/it/mdn/contribute/creating_and_editing_pages/index.html +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: 'creare., edizione paginaCreazione e modifica delle pagine' -slug: MDN/Contribute/Creating_and_editing_pages -translation_of: MDN/Contribute/Howto/Create_and_edit_pages ---- -
{{MDNSidebar}}

Modificare e creare una pagina sono le due attività più comuni per la maggior parte dei  COLLABORATORI MDN.  Questo articolo spiega come eseguire queste due operazioni.

- -

Modificare una pagina esistente

- -

E' facile modificare-

- - - -

Anteprima delle modifiche

- -

Per osservare le tue modifiche-

- - - -

Attenzione! L'anteprima di una pagina non salva i tuoi cambiamenti, quindi ricorda di non chiudere la finestra in cui stai modificando.

- -

Commenti di correzione

- -

Dopo aver visualizzato i cambiamenti, vorrai salvare la tua revisione. Prima di salvare, verfica i commenti di correzione nella finestra sotto la sezione del titolo e lascia un commento per informare gli altri collaboratori sul perchè hai effettuato qualche cambiamento. Per esempio, potresti aver aggiunto una nuova sezione, cambiato qualche parole per rendere la terminologia più appropriata, riscritto un paragrafo per renderlo più chiaro, oppure rimosso informazioni ridondanti.

- -

Tags

- -

Puoi aggiungere o rimuovere etichette che descrivono il contenuto della pagina e funzioni sotto la sezione di modifica della pagina. Visita Come taggare in modo appropriato una pagina per avere informazioni su quali etichette applicare.

- -

Revisione necessaria?

- -

Se un esperto o un collaboratore esperto dovrebbe controllare le tue modifiche, puoi richiedere una revisione tecnica (per codice, API o tecnologie), una revisione editoriale (per forma, grammatica e contenuto), oppure una revisione della rappresentazione (per il codice KumaScript) facendo una spunta nel box prima di salvare.

- -

Allegare file

- -

Se volessi allegare un file ad una pagina esistente per aggiungere un'illustrazione oppure ulteriori chiarimenti, puoi farlo a fondo pagina.

- -

Salvare, scartare o continuare a modificare

- -

Quando hai terminato di modificare e sei soddisfatto dell'anteprima, puoi salvare il tuo lavoro e i tuoi commenti cliccando "Salva cambiamenti" (in verde) a destra del titolo della pagina. Se cambi idea, puoi scartare le tue modifiche cliccando su "Scarta cambiamenti" (in rosso) a destra del titolo della pagina.

- -

Premendo invio nel campo commenti di revisione equivale a cliccare "Salva e continua a modificare".

- -

Creare una nuova pagina

- -

Se non sai dove inserire un nuovo articolo, non preoccuparti! Mettilo ovunque, noi lo troveremo e lo sposteremo nel posto giusto o lo aggiungeremo ad un contenuto esistente se è più sensato. Inoltre non preoccuparti di renderlo perfetto. Abbiamo aiutanti gnomi che saranno felici di migliorare il tuo contenuto.

- -

Ci sono alcuni modi di creare una nuova pagina:

- - - -

Collegamento da una pagina esistente

- -
    -
  1. Inserisci il nome della nuova pagina ovunque abbia senso nel testo di una pagina esistente.
    2. -
  2. Evidenzia il nome e clicca l'icona Link () nella barra degli strumenti di modifica. La finestra di dialogo "Update Link" si apre, con il testo evidenziato nel campo "Link To".
    3. -
  3. "/en-US/docs/"  viene inserito di default all'inizio del campo URL. Inserisci il nome della pagina dopo "/en-US/docs/". (Il nome della pagina non deve essere lo stesso del link.)
    4. -
  4. Clicca OK per creare e inserire il link.
    5. -
- -

Se la pagina non esiste ancora il link viene visualizzato in rosso. Se la pagina esiste già, il link viene visualizzato in blu. Se vuoi creare una nuova pagina, ma il titolo della pagina che vuoi utilizzare esiste già controlla prima se non sia meglio aiutare a modificare e migliorare la pagina esistente. Altrimenti pensa a un titolo diverso per la tua nuova pagina e creane uno. Fai riferimento alla guida per nominare le pagine per linee guida.

- -

Per aggiungere un contenuto alla tua nuova pagina clicca nel link in rosso che hai appena creato (dopo aver salvato e chiuso l'editor). La nuova pagina si apre nella modalità di modifica così che potrai cominciare a scrivere. Fai riferimento alla sezione Modificare una pagina esistente di questo articolo sull'utilizzo della modalità di modifica.

- - - -

Per creare una nuova pagina senza link da altre pagine, inserisci un nome unico per la pagina nel campo URL del tuo browser. Per esempio, se inserisci:

- -
https://developer.mozilla.org/en-US/docs/FooBar
- -

MDN crea una nuova pagina con il titolo "FooBar" e apre l'editor così che tu possa aggiungere il contenuto nella nuova pagina. Vedi la sezione Modificare una pagina esistente di questo articolo per sapere come usare la modalità editor.

- -

Sottopagina di una pagina esistente

- -

Per creare una pagina che sia sotto una pagina esistente nella gerarchia della pagina:

- -
    -
  1. In una pagina "padre", clicca sulla voce di menu Advanced (l'icona ingranaggio nella toolbar) e clicca New sub-page. Un editor sarà aperto per la creazione di un nuovo documento.
    2. -
  2. Digita il titolo del documento nel campo Title.
    3. -
  3. Cambia il campo Slug se necessario (per esempio, se il titolo è molto lungo e tu vuoi una URL più breve). Questo campo è automaticamente riempito dall'editor, sostituendo con i caratteri undescores gli spazi nel titolo. In questo caso, puoi cambiare solo l'ultima parte della URL del documento.
    4. -
  4. Nel campo TOC, seleziona il livello di heading che vuoi che venga automaticamente visualizzato nella tabella dei contenuti per la pagina, oppure "No table of contents" se la pagina non ne contiene uno.
    5. -
  5. Scrivi il contenuto della pagina nel pannello dell'editor e salva le modifiche. Vedi la sezione Modificare una pagina esistente di questo articolo per sapere come usare la modalità editor.
    6. -
- -

Clonare una pagina esistente

- -

Se esiste una pagina di cui vuoi usare il formato per una nuova, puoi "clonare" la pagina e quindi le modificare il contenuto.

- -
    -
  1. Sulla pagina originale, clicca sulla voce di menu Advanced  (l'icona ingranaggio della toolbar) e clicca Clone this page. Un editor si editor si aprirà per creare un nuovo documento.
    2. -
  2. Cambia il Title della pagina come appropriato per il nuovo contenuto. Il campo Slug sarà modificato automaticamente quando cambierai il campo Title.
    3. -
  3. Se necessario, cambia la parte del path del campo Slug,  per inserire il nuovo documento una diversa parte della gerarchia del documento (nella maggior parte dei casi non è necessario, poiché la pagina clonata ha un contenuto simile all'originale, e perciò  dovrebbe essere posizionata nello stesso posto).
    4. -
  4. Nel campo TOC, seleziona il livello di heading che vuoi che sia automaticamente visualizzato nella tabella dei contenuti della pagina o "No table of contents" se la pagina non ne necessita uno.
    5. -
  5. Scrivi il contenuto di una pagina nel pannello di editor e salva le modifiche. Vedi la sezione Modificare una pagina esistemte di questo articolo per conoscere come usare la modalità editor.
    6. -
- -

 

diff --git a/files/it/mdn/contribute/howto/create_an_mdn_account/index.html b/files/it/mdn/contribute/howto/create_an_mdn_account/index.html deleted file mode 100644 index c6759dc479..0000000000 --- a/files/it/mdn/contribute/howto/create_an_mdn_account/index.html +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Come creare un account su MDN -slug: MDN/Contribute/Howto/Create_an_MDN_account -tags: - - Documentazione - - Guide - - MDN - - Principianti - - Sviluppatori -translation_of: MDN/Contribute/Howto/Create_an_MDN_account ---- -
{{MDNSidebar}}
- -

Per apportare qualsiasi modifica ai contenuti di MDN hai bisogno di un profilo MDN. Tranquillo, non hai bisogno di un profilo MDN se vuoi solo leggere e cercare in MDN! Questa semplice guida ti aiuta a creare un profilo MDN.

- -
-
-

Perché MDN ha bisogno del mio indirizzo email?
-
- Il tuo indirizzo email serve per recuperare l'account, oppure se gli amministratori di MDN hanno la necessità di contattarti in merito al tuo account o alla tua attività sul sito.
-
- Inoltre hai la possibilità di registrarti per ricevere le notifiche (come quando una certa pagina è cambiata) e messaggi (ad esempio, se decidici di unirti al nostro gruppo di beta testing, potresti ricevere email in merito alle nuove funzionalità che hanno bisogno di essere controllate).
-
- Il tuo indirizzo email non verrà mai visualizzato su MDN e sarà usato solo in accordo alla nostra informativa sulla privacy.

- -
Se fai login tramite Github ed usi un indirizzo email "noreply" su Github, non riceverai i messaggi da MDN (comprese le notifiche quando ti registri alle pagine.)
-
-
- -
    -
  1. In cima ad ogni pagina su MDN trovi un pulsante con etichetta Accedi. Muovi il mouse sul pulsante (o fai tap sullo stesso se usi un dispositivo mobile) per visualizzare una lista dei servizi di autenticazione che usiamo per accedere a MDN.
    2. -
  2. -

    Seleziona il servizio che vuoi usare per accedere. Attualmente è disponibile solo GitHub. Nota che se usi GitHub, un link al tuo profilo GitHub verrà incluso nella tua pagina pubblica del profilo MDN.

    -
    3. -
  3. -

    Segui le richieste di GitHub per collegare il tuo account a MDN.

    -
    4. -
  4. Quando il servizio di autenticazione ti riporta su MDN, ti verrà chiesto da MDN di inserire un nome utente ed un indirizzo email. Il tuo nome utente sarà visualizzato pubblicamente per identificare il lavoro che hai svolto. Non usare il tuo indirizzo email come nome utente.
    5. -
  5. Fai click su Crea nuovo profilo.
    6. -
  6. Se l'indirizzo email che hai indicato al punto 4 non è lo stesso che usi con il servizio di autenticazione, controlla la tua email e fai click sul link nell'email di conferma che ti abbiamo inviato.
    7. -
- -

Fatto! Ora hai un account MDN e puoi immediatamente modificare le pagine!

- -

Puoi fare click sul tuo nome in cima ad ogni pagina MDN per vedere il tuo profilo pubblico. Da lì puoi fare click su Modifica per fare modifiche od aggiunte al tuo profilo.

- -
-

I nuovi nomi utenti non possono contenere spazi o il carattere "@". Ricordati che il tuo nome utente sarà visualizzato pubblicamente per identificare il lavoro che hai svolto!

-
diff --git a/files/it/mdn/contribute/howto/create_and_edit_pages/index.html b/files/it/mdn/contribute/howto/create_and_edit_pages/index.html new file mode 100644 index 0000000000..2ffa7888a4 --- /dev/null +++ b/files/it/mdn/contribute/howto/create_and_edit_pages/index.html @@ -0,0 +1,110 @@ +--- +title: 'creare., edizione paginaCreazione e modifica delle pagine' +slug: MDN/Contribute/Creating_and_editing_pages +translation_of: MDN/Contribute/Howto/Create_and_edit_pages +--- +
{{MDNSidebar}}

Modificare e creare una pagina sono le due attività più comuni per la maggior parte dei  COLLABORATORI MDN.  Questo articolo spiega come eseguire queste due operazioni.

+ +

Modificare una pagina esistente

+ +

E' facile modificare-

+ + + +

Anteprima delle modifiche

+ +

Per osservare le tue modifiche-

+ + + +

Attenzione! L'anteprima di una pagina non salva i tuoi cambiamenti, quindi ricorda di non chiudere la finestra in cui stai modificando.

+ +

Commenti di correzione

+ +

Dopo aver visualizzato i cambiamenti, vorrai salvare la tua revisione. Prima di salvare, verfica i commenti di correzione nella finestra sotto la sezione del titolo e lascia un commento per informare gli altri collaboratori sul perchè hai effettuato qualche cambiamento. Per esempio, potresti aver aggiunto una nuova sezione, cambiato qualche parole per rendere la terminologia più appropriata, riscritto un paragrafo per renderlo più chiaro, oppure rimosso informazioni ridondanti.

+ +

Tags

+ +

Puoi aggiungere o rimuovere etichette che descrivono il contenuto della pagina e funzioni sotto la sezione di modifica della pagina. Visita Come taggare in modo appropriato una pagina per avere informazioni su quali etichette applicare.

+ +

Revisione necessaria?

+ +

Se un esperto o un collaboratore esperto dovrebbe controllare le tue modifiche, puoi richiedere una revisione tecnica (per codice, API o tecnologie), una revisione editoriale (per forma, grammatica e contenuto), oppure una revisione della rappresentazione (per il codice KumaScript) facendo una spunta nel box prima di salvare.

+ +

Allegare file

+ +

Se volessi allegare un file ad una pagina esistente per aggiungere un'illustrazione oppure ulteriori chiarimenti, puoi farlo a fondo pagina.

+ +

Salvare, scartare o continuare a modificare

+ +

Quando hai terminato di modificare e sei soddisfatto dell'anteprima, puoi salvare il tuo lavoro e i tuoi commenti cliccando "Salva cambiamenti" (in verde) a destra del titolo della pagina. Se cambi idea, puoi scartare le tue modifiche cliccando su "Scarta cambiamenti" (in rosso) a destra del titolo della pagina.

+ +

Premendo invio nel campo commenti di revisione equivale a cliccare "Salva e continua a modificare".

+ +

Creare una nuova pagina

+ +

Se non sai dove inserire un nuovo articolo, non preoccuparti! Mettilo ovunque, noi lo troveremo e lo sposteremo nel posto giusto o lo aggiungeremo ad un contenuto esistente se è più sensato. Inoltre non preoccuparti di renderlo perfetto. Abbiamo aiutanti gnomi che saranno felici di migliorare il tuo contenuto.

+ +

Ci sono alcuni modi di creare una nuova pagina:

+ + + +

Collegamento da una pagina esistente

+ +
    +
  1. Inserisci il nome della nuova pagina ovunque abbia senso nel testo di una pagina esistente.
    2. +
  2. Evidenzia il nome e clicca l'icona Link () nella barra degli strumenti di modifica. La finestra di dialogo "Update Link" si apre, con il testo evidenziato nel campo "Link To".
    3. +
  3. "/en-US/docs/"  viene inserito di default all'inizio del campo URL. Inserisci il nome della pagina dopo "/en-US/docs/". (Il nome della pagina non deve essere lo stesso del link.)
    4. +
  4. Clicca OK per creare e inserire il link.
    5. +
+ +

Se la pagina non esiste ancora il link viene visualizzato in rosso. Se la pagina esiste già, il link viene visualizzato in blu. Se vuoi creare una nuova pagina, ma il titolo della pagina che vuoi utilizzare esiste già controlla prima se non sia meglio aiutare a modificare e migliorare la pagina esistente. Altrimenti pensa a un titolo diverso per la tua nuova pagina e creane uno. Fai riferimento alla guida per nominare le pagine per linee guida.

+ +

Per aggiungere un contenuto alla tua nuova pagina clicca nel link in rosso che hai appena creato (dopo aver salvato e chiuso l'editor). La nuova pagina si apre nella modalità di modifica così che potrai cominciare a scrivere. Fai riferimento alla sezione Modificare una pagina esistente di questo articolo sull'utilizzo della modalità di modifica.

+ + + +

Per creare una nuova pagina senza link da altre pagine, inserisci un nome unico per la pagina nel campo URL del tuo browser. Per esempio, se inserisci:

+ +
https://developer.mozilla.org/en-US/docs/FooBar
+ +

MDN crea una nuova pagina con il titolo "FooBar" e apre l'editor così che tu possa aggiungere il contenuto nella nuova pagina. Vedi la sezione Modificare una pagina esistente di questo articolo per sapere come usare la modalità editor.

+ +

Sottopagina di una pagina esistente

+ +

Per creare una pagina che sia sotto una pagina esistente nella gerarchia della pagina:

+ +
    +
  1. In una pagina "padre", clicca sulla voce di menu Advanced (l'icona ingranaggio nella toolbar) e clicca New sub-page. Un editor sarà aperto per la creazione di un nuovo documento.
    2. +
  2. Digita il titolo del documento nel campo Title.
    3. +
  3. Cambia il campo Slug se necessario (per esempio, se il titolo è molto lungo e tu vuoi una URL più breve). Questo campo è automaticamente riempito dall'editor, sostituendo con i caratteri undescores gli spazi nel titolo. In questo caso, puoi cambiare solo l'ultima parte della URL del documento.
    4. +
  4. Nel campo TOC, seleziona il livello di heading che vuoi che venga automaticamente visualizzato nella tabella dei contenuti per la pagina, oppure "No table of contents" se la pagina non ne contiene uno.
    5. +
  5. Scrivi il contenuto della pagina nel pannello dell'editor e salva le modifiche. Vedi la sezione Modificare una pagina esistente di questo articolo per sapere come usare la modalità editor.
    6. +
+ +

Clonare una pagina esistente

+ +

Se esiste una pagina di cui vuoi usare il formato per una nuova, puoi "clonare" la pagina e quindi le modificare il contenuto.

+ +
    +
  1. Sulla pagina originale, clicca sulla voce di menu Advanced  (l'icona ingranaggio della toolbar) e clicca Clone this page. Un editor si editor si aprirà per creare un nuovo documento.
    2. +
  2. Cambia il Title della pagina come appropriato per il nuovo contenuto. Il campo Slug sarà modificato automaticamente quando cambierai il campo Title.
    3. +
  3. Se necessario, cambia la parte del path del campo Slug,  per inserire il nuovo documento una diversa parte della gerarchia del documento (nella maggior parte dei casi non è necessario, poiché la pagina clonata ha un contenuto simile all'originale, e perciò  dovrebbe essere posizionata nello stesso posto).
    4. +
  4. Nel campo TOC, seleziona il livello di heading che vuoi che sia automaticamente visualizzato nella tabella dei contenuti della pagina o "No table of contents" se la pagina non ne necessita uno.
    5. +
  5. Scrivi il contenuto di una pagina nel pannello di editor e salva le modifiche. Vedi la sezione Modificare una pagina esistemte di questo articolo per conoscere come usare la modalità editor.
    6. +
+ +

 

diff --git a/files/it/mdn/contribute/howto/delete_my_profile/index.html b/files/it/mdn/contribute/howto/delete_my_profile/index.html deleted file mode 100644 index 182bc6a241..0000000000 --- a/files/it/mdn/contribute/howto/delete_my_profile/index.html +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Come rimuovere il mio profilo -slug: MDN/Contribute/Howto/Delete_my_profile -translation_of: MDN/Contribute/Howto/Delete_my_profile ---- -
{{MDNSidebar}}
- -

Nel caso decidessi di non voler più far parte di MDN, puoi richiedere la cancellazione del tuo profilo. Ciò nonostante, non possiamo cancellare alcuna tua revisione (modifiche alle pagine), e la nostra licenza del contenuto prevede che le tue modifiche abbiano una fonte. Se hai fatto delle modifiche, dovrai decidere di volerle attribuire al tuo nome utente, o ri-attribuirle ad "Anonimo".

- -
    -
  1. Dopo aver eseguito l'accesso su MDN, clicca sul tuo profilo nella barra di navigazione in alto visibile in qualsiasi pagina. Si aprirà la tua pagina di profilo, mostrando tutte le informazioni su ciò a cui hai contribuito. Annota se le revisioni sono elencate in Attività Documenti Recenti.
    2. -
  2. Clicca su Modifica. Si apirà il modulo Modifica il tuo profilo.
    3. -
  3. Scorri fino alla fine del modulo e fai clic sul link "Elimina il tuo account". Si aprirà il modulo "Elimina il tuo profilo".
    4. -
  4. Seleziona una delle seguenti opzioni: -
      -
    • Non ho fatto alcuna modifica, cancella il mio account. Scegli questa opzione se non c'era alcun elemento in Attività Documenti Recenti.
      • -
    • Mantieni il mio nome utente come fonte per le mie modifiche, cancella il mio indirizzo email e sospendi il mio account, in modo che non possa più eseguire l'accesso.  Se scegli questa opzione, il tuo profilo verrà associato con le tue modifiche, ma non sarai più in grado di accedere a MDN. La tua pagina del profilo continuerà ad esistere, ma le informazioni personali verranno rimosse.
      • -
    • Cambia la fonte delle mie modifiche in "Anonimo", e cancella il mio account. Se scegli questa opzione, tutte le modifiche da te eseguite verranno attribuite ad "Anonimo". Il tuo account e pagina del profilo verranno rimosse. Non ci sarà più alcuna associazione tra te e le tue modifiche.
      • -
    -
    5. -
  5. Fai clic su Segnala un Bug per Chiudere il tuo Account. Questa azione creerà un nuovo caso nel sistema di tracciamento dei problemi Bugzilla per la tua richiesta di cancellazione dell'account, con i campi Riepilogo e Descrizione precompilati in base al tuo nome utente e all'opzione che hai scelto. Questo passaggio è necessario perché un essere umano esaminerà la tua richiesta ed eseguirà le azioni necessarie.
    6. -
  6. Devi accedere a Bugzilla per inviare la richiesta. Se non hai un account Bugzilla, dovrai crearne uno.
    7. -
  7. Fare clic su Invia bug per inviare la richiesta. Quando la tua richiesta è stata gestita, riceverai una notifica da Bugzilla all'indirizzo email che hai utilizzato per accedere a Bugzilla.
    8. -
diff --git a/files/it/mdn/contribute/howto/do_a_technical_review/index.html b/files/it/mdn/contribute/howto/do_a_technical_review/index.html deleted file mode 100644 index 31f0885a09..0000000000 --- a/files/it/mdn/contribute/howto/do_a_technical_review/index.html +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Come effettuare una revisione tecnica -slug: MDN/Contribute/Howto/Do_a_technical_review -translation_of: MDN/Contribute/Howto/Do_a_technical_review ---- -
{{MDNSidebar}}

La revisione tecnica consiste nel controllo dell'accuratezza tecnica e della completezza di un articolo e, se necessario, nella sua correzione. Se chi scrive un articolo desidera che qualcun altro verifichi il contenuto tecnico di un articolo, può segnalarlo attivando l'opzione "Revisione tecnica" durante la modifica di una pagina. A volte chi scrive contatta un ingegnere specifico affinché effettui la revisione tecnica, ma chiunque abbia esperienza tecnica può farlo.

-

Questo articolo spiega come effettuare una revisione tecnica, permettendo così di mantenere corretto il contenuto di MDN.

- - - - - - - - - - - - - - - - - - - -
In cosa consiste?Revisionare e correggere gli articoli per assicurarsi che siano tecnicamente corretti e completi
Dove è necessaria?In articoli specifici che sono contrassegnati per essere sottoposti a una revisione tecnica.
Cosa hai bisogno di sapere per completare l'operazione? -
    -
  • Conoscenza da esperto sull'argomento dell'articolo che stai revisionando.
    • -
  • Capacità di modificare un articolo wiki su MDN.
    • -
-
Quali sono i passi necessari? -
    -
  1. Scegli un articolo da revisionare -
      -
    1. Visita l'elenco delle pagine che necessitano di revisioni tecniche. Questo contiene tutte le pagine per le quali è stata richiesta una revisione tecnica.
      2. -
    2. Scegli una pagina che tratta di un argomento con cui hai familiarità.
      3. -
    3. Fai clic sul link dell'articolo per caricare la pagina.
      4. -
    -
    2. -
  2. Al termine del caricamento della pagina, fai clic sul pulsante MODIFICA in alto a sinistra; verrà aperto l'editor di MDN. Non esitare a cambiare pagina se la prima che hai scelto non ti è congeniale.
    3. -
  3. Man mano che leggi l'articolo, sistema qualsiasi informazione errata e aggiungi le parti importanti mancanti.
    4. -
  4. Inserisci un Commento per la revisione nell'apposito campo in fondo alla pagina, ad esempio 'Revisione tecnica completata'. Se hai corretto qualche informazione, includi le modifiche effettuate nel commento, ad esempio 'Revisione tecnica: corrette le descrizioni dei parametri'.
    5. -
  5. Fai clic sul pulsante SALVA MODIFICHE.
    6. -
  6. Alla chiusura dell'editor, quando l'articolo a cui sono state apportate le correzioni verrà visualizzato sullo schermo, spunta la voce Tecnica a lato (nel riquadro Sono state richieste le seguenti revisioni) e fai clic su CARICA REVISIONE.
    7. -
  7. Congratulazioni! Hai concluso la revisione!
    8. -
-
-


-  

diff --git a/files/it/mdn/contribute/howto/do_an_editorial_review/index.html b/files/it/mdn/contribute/howto/do_an_editorial_review/index.html deleted file mode 100644 index 7bfc4bf759..0000000000 --- a/files/it/mdn/contribute/howto/do_an_editorial_review/index.html +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Come effettuare una revisione editoriale -slug: MDN/Contribute/Howto/Do_an_editorial_review -translation_of: MDN/Contribute/Howto/Do_an_editorial_review ---- -
{{MDNSidebar}}

Una revisione editoriale consiste nel sistemare errori di digitazione, grammatica, utilizzo, ortografia in un articolo. Non tutti i collaboratori sono traduttori esperti, ma data la loro conoscenza hanno scritto articoli estremamente utili, che necessitano di revisioni e correzioni; questo è lo scopo della revisione editoriale.

-

Questo articolo descrive come eseguire una revisione editoriale, così da accertarsi che il contenuto di MDN sia accurato.

- - - - - - - - - - - - - - - - - - - -
In che cosa consiste?In una revisione e correzione di articoli per i quali è richiesta una revisione editoriale.
Quando è necessaria?In articoli specifici che sono contrassegnati per essere sottoposti a una revisione editoriale.
Cosa hai bisogno di sapere per completare l'operazione?Ti serve avere una buona conoscenza della grammatica e del lessico della lingua in questione.
Quali sono i passi necessari? -
    -
  1. Scegli un articolo da revisionare: -
      -
    1. Visita l'elenco delle pagine che necessitano di revisione editoriale. Questo contiene tutte le pagine per le quali è stata richiesta una revisione editoriale.
      2. -
    2. Scegli una pagina che possiede un titolo nella lingua in questione e il cui indirizzo non inizia con Template:.
      3. -
    3. Fai clic sul collegamento per caricare la pagina.
      4. -
    -
    2. -
  2. Al termine del caricamento della pagina, fai clic sul pulsante MODIFICA in alto a sinistra; verrà aperto l'editor di MDN. Non esitare a cambiare pagina se la prima che hai scelto non ti è congeniale.
    3. -
  3. Correggi tutti gli errori di digitazione, grammatica, utilizzo che trovi.
    4. -
  4. Inserisci un Commento per la revisione nell'apposito campo in fondo alla pagina, ad esempio 'Revisione editoriale completata: sistemati errori digitazione, grammatica e ortografia'.
    5. -
  5. Fai clic sul pulsante SALVA MODIFICHE.
    6. -
  6. Alla chiusura dell'editor, quando l'articolo a cui sono state apportate le correzioni verrà visualizzato sullo schermo, spunta la voce Editoriale a lato (nel riquadro Sono state richieste le seguenti revisioni) e fai clic su CARICA REVISIONE.
    7. -
  7. -

    Congratulazioni! Hai concluso la revisione!

    -
    8. -
-
-

 

diff --git a/files/it/mdn/contribute/howto/impostare_il_riassunto_di_una_pagina/index.html b/files/it/mdn/contribute/howto/impostare_il_riassunto_di_una_pagina/index.html deleted file mode 100644 index ba8df38979..0000000000 --- a/files/it/mdn/contribute/howto/impostare_il_riassunto_di_una_pagina/index.html +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Come impostare il riassunto di una pagina -slug: MDN/Contribute/Howto/impostare_il_riassunto_di_una_pagina -tags: - - Community - - Documentazione - - Guida - - MDN - - Riassunto Pagina -translation_of: MDN/Contribute/Howto/Set_the_summary_for_a_page ---- -
{{MDNSidebar}}

Il riassunto di una pagina di MDN è definito in modo da essere utilizzabile in vari ambiti, tra cui i risultati dei motori di ricerca, in altre pagine di MDN, come ad esempio nelle landing pages relative a diversi argomenti, e nei tooltips. Deve essere quindi un testo che conservi il proprio significato sia nel contesto della propria pagina, sia quando si trova in contesti differenti, privato dei contenuti della pagina di origine.

-

Un riassunto può essere identificato esplicitamente all'interno della pagina. In caso contrario, si utilizza in genere la prima frase, il che non sempre si rivela la scelta più adatta per raggiungere lo scopo prefissato.

- - - - - - - - - - - - - - - - - - - -
Qual è il tuo compito?Evidenziare la parte di testo all' interno della pagina che, a tuo parere, dovrebbe essere utilizzata come riassunto della pagina nei vari contesti; questo compito richiede talvolta la scrittura di un testo appropriato, là dove ve ne sia necessità.
Dove c'è bisogno del tuo intervento?In quelle pagine che non hanno riassunto o ne presentano uno di scarsa qualità.
Di cosa hai bisogno per portare a termine la tua missione?Conoscenza dell' editor testi di MDN; buone capacità di scrittura in lingua inglese; sufficiente familiarità con l'argomento della pagina in questione, al fine di poterne scrivere un valido riassunto.
Le tappe del tuo lavoro: -
    -
  1. Scegli una pagina di cui fare il riassunto: -
      -
    1. Nella pagina MDN documentation status, sotto Sections, seleziona l'argomento che meglio conosci (ad esempio HTML):
      -
      2. -
    2. Nella pagina dello stato di documentazione dell'argomento scelto, clicca sulla casella Pages della tabella Summary. Si aprirà un indice di tutte le pagine di quell'argomento; nella colonna di sinistra troverai i links delle pagine, in quella di destra i tags e i riassunti:
      -
      3. -
    3. Scegli una pagina senza riassunto o con un riassunto mediocre:
      -
      4. -
    4. Clicca il link per aprire quella pagina.
      5. -
    -
    2. -
  2. Clicca su Edit per aprire la pagina nell'editor testi di MDN.
    3. -
  3. Cerca una o due frasi adatte per un riassunto, o, all'occorrenza, creane di nuove o modificane di esistenti allo scopo di creare un buon riassunto.
    4. -
  4. Seleziona il testo da utilizzare come riassunto
    5. -
  5. Nello Styles widget della barra degli strumenti di editor, seleziona SEO Summary. (Si crea così un elemento {{HTMLElement("span")}} nella page source con class="seoSummary" attorno al testo prescelto.) -

    -
    6. -
  6. Salva le modifiche con un commento di revisione del tipo "riassunto pagina".
    7. -
-
-

 

-

 

-

 

diff --git a/files/it/mdn/editor/index.html b/files/it/mdn/editor/index.html deleted file mode 100644 index 856ef1fc2d..0000000000 --- a/files/it/mdn/editor/index.html +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Guida all'editor di MDN -slug: MDN/Editor -translation_of: MDN/Editor ---- -
{{MDNSidebar}}

L'editor WYSIWYG (what-you-see-is-what-you-get, ciò che vedi è ciò che ottieni) messo a disposizione dal wiki del Mozilla Developer Network semplifica la creazione di nuovi contenuti. La guida all'editor di MDN fornisce alcune informazioni sull'utilizzo dell'editor e su alcune caratteristiche utili che possono migliorare la tua produttività.

-

La guida di stile di MDN fornisce alcune informazioni sulla formattazione e lo stile da applicare ai contenuti, comprese le regole di grammatica che preferiamo vengano utilizzate.

-

{{LandingPageListSubpages}}

-

{{EditorGuideQuicklinks}}

diff --git a/files/it/mdn/guidelines/conventions_definitions/index.html b/files/it/mdn/guidelines/conventions_definitions/index.html new file mode 100644 index 0000000000..2aadc92c27 --- /dev/null +++ b/files/it/mdn/guidelines/conventions_definitions/index.html @@ -0,0 +1,34 @@ +--- +title: Migliore pratica +slug: MDN/Guidelines/Migliore_pratica +tags: + - Guida + - MDN Meta + - linee guida +translation_of: MDN/Guidelines/Conventions_definitions +--- +
{{MDNSidebar}}

Quest'articolo descrive i metodi raccomandati di lavoro con il contenuto su MDN. Queste linee guida descrivono i metodi preferiti per fare tutto ciò che porta ad un miglior risultato, o offrire un consiglio nel decidere tra diversi metodi nel fare cose simili.

+ +

Copiare il contenuto

+ +

A volte, avrai la necessità di utilizzare lo stesso testo su più pagine (oppure utilizzare il modello di una pagina per un'altra). Hai tre opzioni:

+ + diff --git a/files/it/mdn/guidelines/macros/index.html b/files/it/mdn/guidelines/macros/index.html deleted file mode 100644 index a09cf37e30..0000000000 --- a/files/it/mdn/guidelines/macros/index.html +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Using macros on MDN -slug: MDN/Guidelines/Macros -tags: - - italino tags -translation_of: MDN/Structures/Macros ---- -
{{MDNSidebar}}

The Kuma platform on which MDN runs provides a powerful macro system, KumaScript, which makes it possible to do a wide variety of things automatically. This article provides information on how to invoke MDN's macros within articles.

- -

The KumaScript guide provides an in-depth look at how to use macros on MDN, so this section is more of a brief overview. If you've already read the section above on {{SectionOnPage("/en-US/docs/Project:MDN/Contributing/Editor_guide/Links", "Using link macros")}}, you're already at least a little bit familiar with the concept.

- -

How macros are implemented

- -

Macros on MDN are implemented using server-executed JavaScript code, interpreted using Node.js. On top of that we have a number of libraries we've implemented that provide wiki-oriented services and features to let macros interact with the wiki platform and its contents. If you're interested in learning more, see the KumaScript guide; the KumaScript reference provides details on the libraries and other KumaScript APIs we've implemented.

- -

Using a macro in content

- -

To actually use a macro, you simply enclose the call to the macro in a pair of double-braces, with its parameters, if any, enclosed in parentheses; that is:

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

A few notes about macro calls:

- - - -

Macros are heavily cached; for any set of input values (both parameters and environmental values such as the URL for which the macro was run), the results are stored and reused. This means that the macro is only actually run when the inputs change.

- -
-

Note: You can force all the macros on a page to be re-evaluated by force-refreshing the page in your browser (that is, a shift-reload).

-
- -

Macros can be as simple as just inserting a larger block of text or swapping in contents from another part of MDN, or as complex as building an entire index of content by searching through parts of the site, styling the output, and adding links.

- -

You can read up on our most commonly-used macros on the Custom macros page; also, there's a complete list of all macros here. Most macros have documentation built into them, as comments at the top.

- -

{{EditorGuideQuicklinks}}

diff --git a/files/it/mdn/guidelines/migliore_pratica/index.html b/files/it/mdn/guidelines/migliore_pratica/index.html deleted file mode 100644 index 2aadc92c27..0000000000 --- a/files/it/mdn/guidelines/migliore_pratica/index.html +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Migliore pratica -slug: MDN/Guidelines/Migliore_pratica -tags: - - Guida - - MDN Meta - - linee guida -translation_of: MDN/Guidelines/Conventions_definitions ---- -
{{MDNSidebar}}

Quest'articolo descrive i metodi raccomandati di lavoro con il contenuto su MDN. Queste linee guida descrivono i metodi preferiti per fare tutto ciò che porta ad un miglior risultato, o offrire un consiglio nel decidere tra diversi metodi nel fare cose simili.

- -

Copiare il contenuto

- -

A volte, avrai la necessità di utilizzare lo stesso testo su più pagine (oppure utilizzare il modello di una pagina per un'altra). Hai tre opzioni:

- - diff --git a/files/it/mdn/structures/compatibility_tables/index.html b/files/it/mdn/structures/compatibility_tables/index.html new file mode 100644 index 0000000000..81ee695696 --- /dev/null +++ b/files/it/mdn/structures/compatibility_tables/index.html @@ -0,0 +1,496 @@ +--- +title: Tabelle di compatibilità +slug: MDN/Structures/Tabelle_compatibilità +translation_of: MDN/Structures/Compatibility_tables +--- +
{{MDNSidebar}}
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

MDN ha un formato standard di tabelle di compatibilità per la nostra documentazione web open; in altre parole, la documentazione di tecnologie come DOM, HTML, CSS, JavaScript, SVG, ecc., che viene condivisa attraverso tutti i browsers. Questo articolo spiega come usare le nostre funzionalità per aggiungere dati di compatibilità alle pagine MDN.

+ +
+

Importante: Il modo in cui i dati sono generati è cambiato. Storicamente le nostre tabelle erano inserite sulla pagina e i dati inseriti manualmente.   Questo è inefficiente, rende la manutenzione difficile e rende i dati inflessibili. Per questo, stiamo cambiando i dati di compatibilità per browser al fine di essere immagazzinati in una repository dati (vedi https://github.com/mdn/browser-compat-data) generando le tabelle programmaticamente.
+
+ In questa guida, documentiamo il nuovo metodo per aggiungere dati di compatibilità in MDN, mantenendo tuttavia, la documentazione sul vecchio metodo, poiché saranno ancora presenti per un po' le tabelle popolate manualmente su MDN. Se hai bisogno di vedere la vecchia documentazione, controlla il nostro articolo Old compatibility tables.

+
+ +
+

Nota: Se hai bisogno di aiuto con un qualsiasi step di questa guida, puoi contattarci al MDN discussion forum.

+
+ +

Come accedere alla repository dati

+ +

I dati sono conservati in un repository GitHub — vedi https://github.com/mdn/browser-compat-data. Per accedervi, hai bisogno di un account GitHub, fare un fork del repository browser-compat-data attraverso il tuo account, infine clonare il fork localmente sulla tua macchina.

+ +

Choosing a feature to add data for

+ +

First of all, find a feature that you want to add browser-compat-data for. This could be an HTML element, CSS property, JS language feature or JS API interface, for example. We would like to encourage you to work on API features, as we already have people working on HTML, JS, and CSS. You can find the status of features that need their data adding to the repo on our Browser Compat Data migration spreadsheet.

+ +

The process for using this is as follows:

+ +
    +
  1. Go ahead and choose a feature that is not already being worked on or complete. Put your name in the "Who" column, preferably along with your MDN username so we can find your email address and contact you if we need to.
    2. +
  2. If the feature you want to work on is not already listed in the spreadsheet, add rows for it in an appropriate place, copying the format that is already there. You should also use the same granularity (e.g. per element for HTML, per property or selector for CSS, per object for JS, per interface for APIs).
    3. +
  3. Once you've started work on adding the data, put the status to "In progress".
    4. +
  4. Once you've added the data and submitted a pull request to the main repo, put the status to "PR done".
    5. +
  5. As your data is merged to the repo, then added to the npm package, update the status as necessary.
    6. +
  6. Once you've updated the documentation page(s) for your feature to use the new macro to dynamically generate the appropriate data table on each page, set the status to "Article updated". At this point, you are done.
    7. +
+ +

Preparing to add the data

+ +

Before adding some new data, you should make sure that your fork is up-to-date with the main repo (it contains the same content), create a new branch inside your fork to contain your additions, then pull that branch into your local clone so you can start working inside it:

+ +

Let's look at a simple way to make sure your fork is to-to-date is as follows:

+ +

Adding the main browser-compat-data repo as a remote

+ +

Go to your local clone of your fork in your terminal/command line, and add a remote pointing to the main (upstream) repo like so (you only need to do this once):

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

If you are unsure whether you've done this, you can check what remotes your repo has using

+ +
git remote -v
+ +

Updating your fork with the remote's content

+ +

Now, whenever you want to update your fork, you can do so by:

+ +
    +
  1. +

    Making sure you are in the master branch:

    + + 
    git checkout master
    +
    2. +
  2. +

    fetching the up-to-date repo contents using the following:

    + + 
    git fetch upstream
    +
    3. +
  3. +

    rebasing the contents of your master with the main repo's contents:

    + + 
    git rebase upstream/master
    +
    4. +
  4. +

    pushing these updates back to your remote fork using this:

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

Creating a new branch to do your work in

+ +

Next, go to your remote fork (it will be at https://github.com/your-username/browser-compat-data) and create a new branch to store your changes for this data addition. This can be done by:

+ +
    +
  1. Clicking on the "Branch: Master" button.
    2. +
  2. Entering a new branch name into the "Find or create a branch..." text field.
    3. +
  3. Pressing the resulting "Create branch name-of-branch from Master" button.
    4. +
+ +

For example, if you were wanting to add data for the WebVR API, you'd create a branch called something like "webvr".

+ +

Switching to the new branch

+ +

At this point, go back to your terminal/command line, and update your fork's local clone to include your new branch using the following command:

+ +
git pull
+ +

Now switch to your new branch using this:

+ +
git checkout name-of-branch
+ +

You should now be ready to start adding your data!

+ +

Adding the data

+ +

To add the data, you need to create a new file or files to store your compat data in. The files you need to create differ, depending on what technology you are working on:

+ + + +
+

Note: You'll notice that the repo also contains data for Browser Extensions and HTTP. These data sets are basically finished as they stand, but more features may need to be added in the future.

+
+ +

Each file you create has to follow the pattern defined in the schema contained within our repo; you can see the detailed schema description here.

+ +

Basic compat data structure

+ +

Let's look at an example. CSS property JSON files for example need the following basic structure:

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

You have the css object, inside of which is a properties object. Inside the properties object, you need one member for each of the specific features you want to define the compat data for. Each of these members has a __compat member, inside of which the actual data goes.

+ +

The above data is found in the border-width.json file — compare this to the rendered border-width support table on MDN.

+ +

Other types of features work in the same way, but with different object names:

+ + + +
+

In HTML, CSS, and JS pages, you'll normally only need one feature. API interfaces work slightly differently — they always have multiple sub-features (see {{anch("Sub-features")}}, below).

+ +

Basic structure inside a feature

+ +

Inside a feature __compat member, you need to include the following members:

+ + + +

The names of the browser members are defined in the schema (see Browser identifiers). You should use the full list of currently defined identifiers. If you wish to add another browser, talk to us first, as this could have a wide-ranging impact and should not be done without careful thought.

+ +

In a basic browser compat data file, you'll only need to include "version_added" inside the browser identifier members (we'll cover {{anch("Advanced cases")}} later on). The different values you might want to include are as follows:

+ + + +

Inside the status member, you'll include three submembers:

+ + + +

The feature data for border-width (also see border-width.json) is shown below as an example:

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

Adding a description

+ +

There is a fourth, optional, member that can go inside the __compat member — description. This can be used to include a human-readable description of the feature. You should only include this if it is hard to see what the feature is from glancing at the data. For example, it might not be that obvious what a constructor is from looking at the data structure, so you can include a description like so:

+ +
{
+  "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/it/mdn/structures/macros/index.html b/files/it/mdn/structures/macros/index.html new file mode 100644 index 0000000000..a09cf37e30 --- /dev/null +++ b/files/it/mdn/structures/macros/index.html @@ -0,0 +1,42 @@ +--- +title: Using macros on MDN +slug: MDN/Guidelines/Macros +tags: + - italino tags +translation_of: MDN/Structures/Macros +--- +
{{MDNSidebar}}

The Kuma platform on which MDN runs provides a powerful macro system, KumaScript, which makes it possible to do a wide variety of things automatically. This article provides information on how to invoke MDN's macros within articles.

+ +

The KumaScript guide provides an in-depth look at how to use macros on MDN, so this section is more of a brief overview. If you've already read the section above on {{SectionOnPage("/en-US/docs/Project:MDN/Contributing/Editor_guide/Links", "Using link macros")}}, you're already at least a little bit familiar with the concept.

+ +

How macros are implemented

+ +

Macros on MDN are implemented using server-executed JavaScript code, interpreted using Node.js. On top of that we have a number of libraries we've implemented that provide wiki-oriented services and features to let macros interact with the wiki platform and its contents. If you're interested in learning more, see the KumaScript guide; the KumaScript reference provides details on the libraries and other KumaScript APIs we've implemented.

+ +

Using a macro in content

+ +

To actually use a macro, you simply enclose the call to the macro in a pair of double-braces, with its parameters, if any, enclosed in parentheses; that is:

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

A few notes about macro calls:

+ + + +

Macros are heavily cached; for any set of input values (both parameters and environmental values such as the URL for which the macro was run), the results are stored and reused. This means that the macro is only actually run when the inputs change.

+ +
+

Note: You can force all the macros on a page to be re-evaluated by force-refreshing the page in your browser (that is, a shift-reload).

+
+ +

Macros can be as simple as just inserting a larger block of text or swapping in contents from another part of MDN, or as complex as building an entire index of content by searching through parts of the site, styling the output, and adding links.

+ +

You can read up on our most commonly-used macros on the Custom macros page; also, there's a complete list of all macros here. Most macros have documentation built into them, as comments at the top.

+ +

{{EditorGuideQuicklinks}}

diff --git "a/files/it/mdn/structures/tabelle_compatibilit\303\240/index.html" "b/files/it/mdn/structures/tabelle_compatibilit\303\240/index.html" deleted file mode 100644 index 81ee695696..0000000000 --- "a/files/it/mdn/structures/tabelle_compatibilit\303\240/index.html" +++ /dev/null @@ -1,496 +0,0 @@ ---- -title: Tabelle di compatibilità -slug: MDN/Structures/Tabelle_compatibilità -translation_of: MDN/Structures/Compatibility_tables ---- -
{{MDNSidebar}}
{{IncludeSubnav("/en-US/docs/MDN")}}
- -

MDN ha un formato standard di tabelle di compatibilità per la nostra documentazione web open; in altre parole, la documentazione di tecnologie come DOM, HTML, CSS, JavaScript, SVG, ecc., che viene condivisa attraverso tutti i browsers. Questo articolo spiega come usare le nostre funzionalità per aggiungere dati di compatibilità alle pagine MDN.

- -
-

Importante: Il modo in cui i dati sono generati è cambiato. Storicamente le nostre tabelle erano inserite sulla pagina e i dati inseriti manualmente.   Questo è inefficiente, rende la manutenzione difficile e rende i dati inflessibili. Per questo, stiamo cambiando i dati di compatibilità per browser al fine di essere immagazzinati in una repository dati (vedi https://github.com/mdn/browser-compat-data) generando le tabelle programmaticamente.
-
- In questa guida, documentiamo il nuovo metodo per aggiungere dati di compatibilità in MDN, mantenendo tuttavia, la documentazione sul vecchio metodo, poiché saranno ancora presenti per un po' le tabelle popolate manualmente su MDN. Se hai bisogno di vedere la vecchia documentazione, controlla il nostro articolo Old compatibility tables.

-
- -
-

Nota: Se hai bisogno di aiuto con un qualsiasi step di questa guida, puoi contattarci al MDN discussion forum.

-
- -

Come accedere alla repository dati

- -

I dati sono conservati in un repository GitHub — vedi https://github.com/mdn/browser-compat-data. Per accedervi, hai bisogno di un account GitHub, fare un fork del repository browser-compat-data attraverso il tuo account, infine clonare il fork localmente sulla tua macchina.

- -

Choosing a feature to add data for

- -

First of all, find a feature that you want to add browser-compat-data for. This could be an HTML element, CSS property, JS language feature or JS API interface, for example. We would like to encourage you to work on API features, as we already have people working on HTML, JS, and CSS. You can find the status of features that need their data adding to the repo on our Browser Compat Data migration spreadsheet.

- -

The process for using this is as follows:

- -
    -
  1. Go ahead and choose a feature that is not already being worked on or complete. Put your name in the "Who" column, preferably along with your MDN username so we can find your email address and contact you if we need to.
    2. -
  2. If the feature you want to work on is not already listed in the spreadsheet, add rows for it in an appropriate place, copying the format that is already there. You should also use the same granularity (e.g. per element for HTML, per property or selector for CSS, per object for JS, per interface for APIs).
    3. -
  3. Once you've started work on adding the data, put the status to "In progress".
    4. -
  4. Once you've added the data and submitted a pull request to the main repo, put the status to "PR done".
    5. -
  5. As your data is merged to the repo, then added to the npm package, update the status as necessary.
    6. -
  6. Once you've updated the documentation page(s) for your feature to use the new macro to dynamically generate the appropriate data table on each page, set the status to "Article updated". At this point, you are done.
    7. -
- -

Preparing to add the data

- -

Before adding some new data, you should make sure that your fork is up-to-date with the main repo (it contains the same content), create a new branch inside your fork to contain your additions, then pull that branch into your local clone so you can start working inside it:

- -

Let's look at a simple way to make sure your fork is to-to-date is as follows:

- -

Adding the main browser-compat-data repo as a remote

- -

Go to your local clone of your fork in your terminal/command line, and add a remote pointing to the main (upstream) repo like so (you only need to do this once):

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

If you are unsure whether you've done this, you can check what remotes your repo has using

- -
git remote -v
- -

Updating your fork with the remote's content

- -

Now, whenever you want to update your fork, you can do so by:

- -
    -
  1. -

    Making sure you are in the master branch:

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

    fetching the up-to-date repo contents using the following:

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

    rebasing the contents of your master with the main repo's contents:

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

    pushing these updates back to your remote fork using this:

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

Creating a new branch to do your work in

- -

Next, go to your remote fork (it will be at https://github.com/your-username/browser-compat-data) and create a new branch to store your changes for this data addition. This can be done by:

- -
    -
  1. Clicking on the "Branch: Master" button.
    2. -
  2. Entering a new branch name into the "Find or create a branch..." text field.
    3. -
  3. Pressing the resulting "Create branch name-of-branch from Master" button.
    4. -
- -

For example, if you were wanting to add data for the WebVR API, you'd create a branch called something like "webvr".

- -

Switching to the new branch

- -

At this point, go back to your terminal/command line, and update your fork's local clone to include your new branch using the following command:

- -
git pull
- -

Now switch to your new branch using this:

- -
git checkout name-of-branch
- -

You should now be ready to start adding your data!

- -

Adding the data

- -

To add the data, you need to create a new file or files to store your compat data in. The files you need to create differ, depending on what technology you are working on:

- - - -
-

Note: You'll notice that the repo also contains data for Browser Extensions and HTTP. These data sets are basically finished as they stand, but more features may need to be added in the future.

-
- -

Each file you create has to follow the pattern defined in the schema contained within our repo; you can see the detailed schema description here.

- -

Basic compat data structure

- -

Let's look at an example. CSS property JSON files for example need the following basic structure:

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

You have the css object, inside of which is a properties object. Inside the properties object, you need one member for each of the specific features you want to define the compat data for. Each of these members has a __compat member, inside of which the actual data goes.

- -

The above data is found in the border-width.json file — compare this to the rendered border-width support table on MDN.

- -

Other types of features work in the same way, but with different object names:

- - - -
-

In HTML, CSS, and JS pages, you'll normally only need one feature. API interfaces work slightly differently — they always have multiple sub-features (see {{anch("Sub-features")}}, below).

- -

Basic structure inside a feature

- -

Inside a feature __compat member, you need to include the following members:

- - - -

The names of the browser members are defined in the schema (see Browser identifiers). You should use the full list of currently defined identifiers. If you wish to add another browser, talk to us first, as this could have a wide-ranging impact and should not be done without careful thought.

- -

In a basic browser compat data file, you'll only need to include "version_added" inside the browser identifier members (we'll cover {{anch("Advanced cases")}} later on). The different values you might want to include are as follows:

- - - -

Inside the status member, you'll include three submembers:

- - - -

The feature data for border-width (also see border-width.json) is shown below as an example:

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

Adding a description

- -

There is a fourth, optional, member that can go inside the __compat member — description. This can be used to include a human-readable description of the feature. You should only include this if it is hard to see what the feature is from glancing at the data. For example, it might not be that obvious what a constructor is from looking at the data structure, so you can include a description like so:

- -
{
-  "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.

-
-- cgit v1.2.3-54-g00ecf