{"id":240,"date":"2012-02-28T18:44:41","date_gmt":"2012-02-28T17:44:41","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/eric-meyer-intervista-tantek-celik\/"},"modified":"2012-02-28T18:44:41","modified_gmt":"2012-02-28T17:44:41","slug":"eric-meyer-intervista-tantek-celik","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/eric-meyer-intervista-tantek-celik\/","title":{"rendered":"La delicata questione del vendor prefix: Eric Meyer di ALA intervista Tantek \u00c7elik"},"content":{"rendered":"
\n

Eric Meyer di A List Apart, mago dei CSS e fan dei vendor prefix<\/a>, intervista Tantek \u00c7elik, web standard lead di Mozilla sul controverso piano di Mozilla per supportare le propriet\u00e0 con il prefisso -webkit-<\/code>. Tantek ha fatto esplodere l’attuale crisi nella Terra dei Web Standard durante un public meeting del W3C CSS Working Group, in quale cha notato la predominanza di siti mobile WebKit-only, che quindi creano una monocoltura del browser. Tantek ha discusso la soluzione di Mozilla, consistente nel far s\u00ec che Firefox Mobile finga di esser come WebKit e facendogli supportare alcune propriet\u00e0 CSS -webkit-<\/code>, che ha accesso molti animi nella comunit\u00e0 degli standard, specialmente quando i rappresentati di Opera e Microsoft sono stati immediatamente d’accordo sul problema e hanno annunciato piani simili a quello di Mozilla. La seguente discussione \u00e8 avvenuta via EtherPad, messaggistica istantanea, e-mail e telefonate.\u2013 Ed.<\/em><\/p>\n

Cominciamo dall’inizio. Che cosa stanno pianificando di fare esattamente i team di Mozilla, Opera e Internet Explorer?<\/strong><\/p>\n

Non posso parlare per i team di Internet Explorer e di Opera, ma Mozilla sta attualmente analizzando i siti web mobile per un paio di comportamenti problematici: siti che fanno browser sniffing cercando una stringa per lo user agent WebKit e mandando di conseguenza solo contenuto mobile \u201chigh fidelity\u201d e siti che usano solo o principalmente propriet\u00e0 con il prefisso -webkit-<\/code><\/p>\n

Basandoci sulle nostre analisi, stiamo pianificando di implementare una stringa UA per Firefox Mobile che passi questo UA-sniffing, ironicamente, in maniera simile al modo in cui WebKit aggiunse \u201clike Gecko\u201d alla sua stringa UA quando venne lanciato Safari, e implementando delle propriet\u00e0 specifiche con il prefisso produttore -webkit-<\/code>, caso-per-caso, quando ci\u00f2 \u00e8 giustificato dai dati raccolti.<\/p>\n

Non mapperete semplicemente in maniera universale -webkit-<\/code> con -moz-<\/code>? Il piano \u00e8 di supportare solo un limitato sottoinsieme di tutte le propriet\u00e0 -webkit-<\/code>?<\/strong><\/p>\n

Esattamente. Il nostro obiettivo qui \u00e8 di minimizzare il numero di propriet\u00e0 con altri prefissi produttori che dobbiamo supportare a quelle che sono giustificate dai dati e che faranno una differenza per gli utenti web di Firefox Mobile. I dati che abbiamo raccolto finora non giustificano un supporto globale di tutte le propriet\u00e0 -webkit-<\/code>.<\/p>\n

In aggiunta, stiamo considerando di supportare solo la versione con il prefisso -webkit-<\/code> di una propriet\u00e0 se e\/o quando supportiamo anche la versione senza prefisso. Questo dar\u00e0 ai web developer un’opzione basata sugli standard piuttosto che usare le propriet\u00e0 con il prefisso.<\/p>\n

Ma al momento, non sappiamo di quali propriet\u00e0 si tratta. O lo sappiamo?<\/strong><\/p>\n

Non abbiamo una lista specifica al momento. Siamo molto cauti riguardo a questo aspetto e stiamo scrutinando i nostri dati di conseguenza per essere sicuri di avere una giustificazione guidata dai dati, che supportiamo solo quello per cui i dati giustificano il supporto, ed efficacemente, il che implica essere sicuri che aggiungere un tale supporto faccia davvero la differenza per gli utenti di Firefox Mobile.<\/p>\n

Immagino che tale lista cambier\u00e0 con il tempo. Sembra che generer\u00e0 ancora pi\u00f9 confusione per i developers, dal momento che supporterete il prefisso -webkit-<\/code> per alcune propriet\u00e0 ma non per altre. Come vi aspettate che rimangano aggiornati gli sviluppatori con chi supporta i prefissi di chi e su quali propriet\u00e0?<\/strong><\/p>\n

Non si \u00e8 mai pensato che le propriet\u00e0 con i prefissi dei produttori fossero qualcosa da cui dovessero dipendere gli sviluppatori. Avevano, e hanno, lo scopo di implementazioni sperimentali e di tecnologie in fase di sviluppo da iterazioni delle working draft di CSS nel processo di standardizzazione. Mi aspetto che gli sviluppatori rimangano aggiornati con le propriet\u00e0 senza prefissi e con le implementazioni che li supportano. Questo \u00e8 quello da cui possono dipendere gli sviluppatori.<\/p>\n

Questo non sembra tuttavia realistico. Se gli sviluppatori si bloccano su quello da cui possono dipendere (le propriet\u00e0 senza prefisso), non ci troveremmo in questa situazione.<\/strong><\/p>\n

Infatti, gli sviluppatori che si fissano sulle cose da cui pensavano di poter dipendere sono il motivo per cui siamo<\/em> in questa situazione. Alcune propriet\u00e0 con i prefissi sono state presentate come se si potesse dipendere da loro e poi supportate come tali senza nessun avanzamento adeguato negli standard.<\/p>\n

Mozilla manterr\u00e0 una lista di quali prefissi sono supportati su quali propriet\u00e0?<\/strong><\/p>\n

Mozilla continuer\u00e0 a documentare quali propriet\u00e0 sono supportate da Firefox, con qualunque prefisso, su developer.mozilla.org<\/a>.<\/p>\n

Ok, quindi questo \u00e8 quello<\/em> che pensate di fare, ma parliamo del perch\u00e9<\/em> pensate di farlo. Qual \u00e8 l’obiettivo del vostro piano?<\/strong><\/p>\n

L’obiettivo di Mozilla \u00e8 di aprire la parte specifica di WebKit del web ad altri produttori nello stesso modo in cui, anni fa, Mozilla e Opera hanno dovuto avere un atteggiamento pratico riguardo quali tecnologie proprietarie di IE o IE-only supportare. Abbiamo sollevato il problema sia di una monocoltura WebKit del mobile web sia dell’insufficienza dell’evangelizzazione da combattere, nonostante i numerosi evangelisti di Mozilla, Opera e Microsoft stiano lavorando con i web developer per pubblicare contenuti basati sugli standard web e cross-browser.<\/p>\n

Con cos\u00ec tante persone che evangelizzano la cosa giusta, perch\u00e9 \u00e8 insufficiente?<\/strong><\/p>\n

Negli scorsi dieci anni e pi\u00f9, l’evangelizzazione degli standard web \u00e8 stata piuttosto efficace, facendo prendere coscienza e adottando HTML+CSS validi, il progressive enhancement, scripting non intrusivo, i microformat, etc. Tuttavia, nonostante gli sforzi di evangelizzazione di Mozilla e di altri durante lo scorso anno, il mobile web specifico per WebKit \u00e8 cresciuto pi\u00f9 rapidamente di quanto non potessimo evangelizzare, specialmente in contrasto con l’evangelizzazione specifica di WebKit, sia implicita che esplicita.<\/p>\n

Penso che sia giusto chiederci: cosa \u00e8 andato storto, come siamo finiti con una monocoltura WebKit nel mobile web nonostante ci sia stata almeno un po’ di evengelizzazione nella direzione opposta, quella degli standard? Non sono sicuro che si sia trattato di un’unica ragione, penso ci siano stati diversi fattori che anno contribuito e che insieme hanno creato le condizioni per la comparsa ed il rafforzamento di questa particolare monocoltura.<\/p>\n

Per prima cosa, le innovazioni in WebKit hanno contribuito all’innalzarsi delle aspettative di quello che era possibile sulla piattaforma web, che, per essere chiari, era e tuttora \u00e8 una buona cosa, poich\u00e9 l’avanzamento del potenziale della piattaforma dell’open web \u00e8 un obiettivo che tutti condividiamo.<\/p>\n

In secondo luogo, l’adozione estesa di WebKit in iPhone, Android e BlackBerry. Questo avrebbe dovuto essere un avvertimento: ossia, quando pi\u00f9 produttori usano tutti una singola implementazione, \u00e8 molto probabile che emerga una monocoltura.<\/p>\n

Terzo, abbiamo visto una forte evangelizzazione delle feature -webkit-<\/code> da parte di Apple e Google, in special modo come parte delle presentazioni e dei siti che dimostrano le capacit\u00e0 di \u201cHTML5\u201d. Alcuni di questi siti \u201cHTML5\u201d sono stati successivamente aggiornati con dei prefissi specifici per il produttore per feature CSS sperimentali (per dimostrazioni e programmazione ancora pi\u00f9 cross-browser). Comunque, risuona ancora oggi l’eco del messaggio implicito delle prime versioni WebKit-only<\/p>\n

Quarto, ci sono stati anni di presentazioni in quasi tutte le conferenze sul web design\/development in cui i presentatori, bramosi di discutere e dimostrare le ultime novit\u00e0, hanno mostrato siti e codice creato con le propriet\u00e0 con il prefisso -webkit-<\/code>. Ci\u00f2 ha incoraggiato implicitamente, quando non esplicitamente, di avere come obiettivo e di utilizzare codice primariamente o esclusivamente solo per WebKit, specialmente per i siti mobile.<\/p>\n

Infine, tutto quello che ho citato qui sopra \u00e8 stato esacerbato dal tempo che ci ha messo il CSS working group per standardizzare alcune di queste innovative propriet\u00e0 con il prefisso -webkit-<\/code>, cos\u00ec che tutti i browser engine, incluso WebKit, potessero supportarle senza prefissi e fornissero ai web developers un’opzione basata sugli standard da cui dipendere.<\/p>\n

Hai detto che state facendo tutto questo per gli utenti di Firefox Mobile. Quindi, questo piano \u00e8 solo per il vostro prodotto mobile e non per il browser desktop?<\/strong><\/p>\n

La stringa UA per Firefox Mobile \u00e8 gi\u00e0 diversa da quella di Firefox Desktop, quindi, s\u00ec, la parte di cui ho parlato prima \u00e8 specifica del prodotto mobile. Per quel che concerne l’implementazione di particolari propriet\u00e0 -webkit, stiamo attualmente ponderando l'opzione di supportarle solo nel mobile, limitando cos\u00ec l'esposizione, rispetto a fornire una piattaforma consistente Firefox\/Gecko da cui possano dipendere gli sviluppatori web.<\/code><\/p>\n

Dal momento che l’obiettivo qui \u00e8 quello di fornire un’esperienza consistente per tutti gli utenti mobile, sembra piuttosto probabile che alla fine deciderete di fornire un’esperienza consistente a tutti gli utenti Firefox, no? Pertanto, di conseguenza questa strategia si espander\u00e0 dal mobile al desktop.<\/strong><\/p>\n

Il problema che abbiamo trovato \u00e8 specifico per i siti mobile che sono stati programmati solo per WebKit. Dal momento che c’\u00e8 moltissima variet\u00e0 di browser sul desktop, c’\u00e8 molto meno codice WebKit in quest’area. Qui entra in gioco il requisito dell’efficacia: se qualcosa in effetti non aiuta l’utente, non c’\u00e8 motivo di implementarla. Quindi, potremmo implementarlo attraverso le piattaforme Firefox, ma ha molto meno senso se farlo non rende migliore l’esperienza desktop per gli utenti. Tuttavia, dobbiamo ancora considerare l’impatto sugli sviluppatori e questo potrebbe essere sufficiente. Potremmo provare le cose nelle beta build per avere del feedback.<\/p>\n

Sulla stessa linea, non sembra qualcosa che rimarr\u00e0 limitato a poche propriet\u00e0 qua e l\u00e0. Sembra che una volta aperta la porta, alla fine arriverete al punto di trattare -webkit-<\/code> come se fosse un vostro prefisso. Oppure, anche se non lo fa Mozilla, allora Opera e Microsoft lo faranno ad un certo punto e di conseguenza, sarete costretti a seguirli. Vero o no?<\/strong><\/p>\n

Penso che dipenda dal fatto se si riuscir\u00e0 ad aprire la monocoltura mobile di WebKit oppure no. La storia ha mostrato che Mozilla ed altri hanno avuto successo aprendo la monocoltura web di IE con implementazioni limitate di alcune feature IE-only, come innerHTML<\/code> e XMLHttpRequest<\/code>, entrambe i quali sono stati successivamente standardizzati con il W3C. Non c’\u00e8 stata nessuna implementazione generale di feature IE-only in Firefox. Mozilla ha un passato solido di implementazioni di feature per la compatibilit\u00e0 web sui cui si \u00e8 riflettuto molto e con un approccio pragmatico caso-per-caso.<\/p>\n

Ma supponi che, ad esempio, Opera vada avanti e supporti universalmente -webkit-<\/code> per ragioni simili a quelle di quando per un certo tempo la loro stringa UA di default aveva come valore Internet Explorer. Questo non forzerebbe Mozilla a seguire lo stesso percorso? E, in caso contrario, perch\u00e9 no?<\/strong><\/p>\n

Se un altro mobile browser supportasse -webkit-<\/code> in maniera totale, non vedo come questo potrebbe avere un impatto sulla situazione, dal momento che il browser engine dominante, WebKit, supporta gi\u00e0 -webkit-<\/code> globalmente?<\/p>\n

Peter-Paul Koch ha affermato piuttosto energeticamente<\/a> che \u201cnon c’\u00e8 un unico WebKit.\u201d La vedete in maniera diversa, ovviamente.<\/strong><\/p>\n

Non importa se Peter-Paul Koch dice che \u201cnon c’\u00e8 alcun WebKit\u201d, quello che importa \u00e8 quello che credono i web developer e agire come se ci fosse un WebKit: stanno programmando e consegnando siti mobile di conseguenza, facendo lo sniffing della stringa UA di WebKit ed usando solo le propriet\u00e0 -webkit-<\/code>. Questo effetto \u00e8 misurabile. Negarlo non lo fa cambiare.<\/p>\n

E facendo cos\u00ec gli sviluppatori stanno dando un’esperienza ridotta o, nei casi peggiori, compromessa agli utenti di browser non-WebKit come Mozilla, Opera ed Explorer.<\/strong><\/p>\n

Esatto. Stiamo vedendo delle esperienze di livello inferiore o \u201cfeature-phone\u201d ultra-minimalistiche e ridotte funzionalit\u00e0 mandate dai siti mobile ai browser mobile non-WebKit.<\/p>\n

In almeno alcuni di questi casi, supportate pienamente quello che stanno facendo, tranne l’averlo nascosto dietro i prefissi -webkit-<\/code>?<\/strong><\/p>\n

S\u00ec. Le attuali versioni di Firefox supportano le versioni con il prefisso -moz-<\/code> dei gradienti, delle transform, delle animazioni, etc. di CSS3. Stiamo lavorando attivamente con il CSS Working Group per far avanzare rapidamente le rispettive specifiche e per eliminare i vendor prefix dalle feature stabili. In questo modo possiamo tutti aiutare a far avanzare la piattaforma web con gli standard piuttosto che con una manciata di vendor prefix.<\/p>\n

Quanto spesso non funziona completamente un sito? Se un sito \u00e8 diverso ma pur sempre funzionante, \u00e8 quello che ci si aspetta gi\u00e0 sul web. Sembra che la vostra vera obiezione sia che il rendering del vostro browser sia meno elegante, non che gli utenti non possano accedere ad un sito. Questa \u00e8 davvero una minaccia per l’adozione e l’uso di browser non-WebKit? <\/strong><\/p>\n

Sono spesso malfunzionanti<\/a>. Questi siti mobile abbassati di livello sono diversi e significativamente meno funzionanti. Quando gli utenti vedono un’esperienza sostanzialmente peggiore in un browser diverso nello stesso sito sullo stesso dispositivo, danno la colpa al browser, non al sito e nemmeno al device.<\/p>\n

La promessa dei prefissi del produttore era che le implementazioni avrebbero potuto essere testate e i problemi avrebbero potuto essere corretti prima che il comportamento fosse formalizzato. Ha funzionato particolarmente bene con la sintassi per il gradiente, ad esempio, per cui sono state provate sintassi totalmente incompatibili e alla fine \u00e8 stata trovata una sintassi unificata. Questo piano sembra metta in pericolo questa capacit\u00e0, ossia, una volta che produttori cominciano a supportare i rispettivi prefissi, potremmo evitare i prefissi tutti insieme. \u00c8 una conclusione ragionevole?<\/strong><\/p>\n

A volte ci aspetta che le tecnologie siano perfette, senza nessun difetto o irregolarit\u00e0. Ovviamente, tali aspettative non hanno basi nell’esperienza quindi non \u00e8 chiaro da dove derivino. Il vendor prefix di CSS non sono diversi: hanno in effetti avuto un certo successo, molti browser hanno sperimentato con iterazioni di svariate feature per anni, standardizzando alla fine quelle che funzionano.<\/p>\n

In particolare, Mozilla ha un’eccellente storia alle spalle di pioniere nel provare le cose per primo con un prefisso -moz-<\/code> e, una volta standardizzata, includere la versione standard della propriet\u00e0, senza prefisso, e abbandonare quella sperimentale con il prefisso -moz-<\/code>. A volte, ci sono stati anche problemi lungo il percorso: ad esempio, quanto tempo ci ha messo la propriet\u00e0 border-radius<\/code> prima diventare standard, ossia adesso. Tuttavia, con la monocoltura WebKit per il mobile web \u00e8 probabilmente la prima volta che vediamo un problema serio con i vendor prefix. Dobbiamo rinunciare ai vendor prefix adesso, nonostante i loro imperfetti ma impressionanti precedenti?<\/p>\n

Ci sono state iniziative per rimpiazzare i vendor prefix con dei prefissi \u201cuniversali\u201d, come -x-<\/code> o -beta-<\/code>. Qual \u00e8 la vostra opinione in merito?<\/strong><\/p>\n

L’esperienza ha mostrato che, negli altri standard in cui si \u00e8 utilizzato un prefisso beta o sperimentale come -x-<\/code>, tutti finiscono con il supportarli<\/em> per sempre oltre alla versione senza prefisso. Ad esempio, controllate gli header della vostra email: troverete molti header X-*<\/code>. Oppure il fatto che i browser offrono il supporto per image\/x-png<\/code> oltre che image\/png<\/code> per le immagini PNG.<\/p>\n

Al contrario, con i vendor prefix di CSS, Mozilla ha mostrato che \u00e8 possibile lasciar perdere le propriet\u00e0 con il prefisso -moz-<\/code> e far progredire il web. Credo che almeno un altro produttore di browser sia stato in grado di dismettere il supporto delle propriet\u00e0 con il prefisso del produttore dopo aver rilasciato le versioni standard senza prefisso.<\/p>\n

Perch\u00e9 i prefissi \u201cuniversali\u201d non sono stati dismessi allo stesso modo dei vendor prefix? Qual \u00e8 la differenza?<\/strong><\/p>\n

I prefissi universali hanno man mano cominciato a essere visti come affidabili tra tutti i browser e pertanto gli effetti della rete hanno rinforzato il loro uso e il supporto \u00e8 migliorato: forse \u00e8 diventato sufficientemente buono da richiedere di supportarli indefinitamente per la compatibilit\u00e0, come i gi\u00e0 citati header X-*<\/code> delle mail e i content type.<\/p>\n

C’\u00e8 un rischio simile quando pi\u00f9 browser supportano le propriet\u00e0 con il prefisso -webkit-<\/code>. Questo rischio potrebbe essere mitigato e forse addirittura superato se pi\u00f9 browser supportassero le equivalenti propriet\u00e0 senza prefisso e potremmo incoraggiare gli sviluppatori web ad usare queste invece delle altre, progredendo. Tuttavia, questo non sistemerebbe i siti mobile specifici per WebKit che sono gi\u00e0 stati rilasciati.<\/p>\n

Quindi, ci stiamo concentrando a risolvere il problema adesso, rischiando di creare un problema simile in futuro. Non state solo allontanando il momento della sofferenza?<\/strong><\/p>\n

\u00c8 sicuramente un problema complesso con molte variabili e molti attori. La combinazione di mettere delle patch ai problemi passati e di mettere nelle condizioni di creare un percorso affidabile per lo sviluppo futuro fornisce un buon equilibrio per l’aiuto degli utenti e degli sviluppatori. Stiamo basando il nostro approccio sullo studio e sulla raccolta di dati e ci aspettiamo di evolvere ed iterare in questo modo.<\/p>\n

Nessun approccio \u00e8 immune dai rischi, ma non fare assolutamente alcunch\u00e9 o far finta che non ci siano problemi \u00e8 pi\u00f9 rischioso perch\u00e9 lascia solo che peggiori la monocoltura WebKit del mobile web. L’ultima volta che c’\u00e8 stata una monocoltura nel web, ha fatto rallentare l’open web per anni.<\/p>\n

Daniel Glazman, co-chair del CSS Working Group, ha emesso una call for action<\/a> in risposta al tuo piano. Avete suggerimenti riguardanti quello che potremmo fare per migliorare la situazione?<\/strong><\/p>\n

Come web developer, ci sono alcune cose chiave che possiamo fare.<\/p>\n

Per prima cosa, non usiamo pi\u00f9<\/em> l’UA-sniffing ed il content-serving specifici di \u201cWebKit\u201d, specialmente sul mobile.<\/p>\n

Secondo, non usiamo pi\u00f9<\/em> solo le propriet\u00e0 con il prefisso -webkit-<\/code> e usiamo o una propriet\u00e0 senza prefisso dove \u00e8 standardizzata o \u201cstabile\u201d per il Working Group, oppure, se non \u00e8 stabile, usiamo le propriet\u00e0 con tutti i vendor prefix dove sono stati annunciati o dove \u00e8 gi\u00e0 stato rilasciato il supporto.<\/p>\n

Terzo, aiutiamo ad evangelizzare le correzioni per tutti i siti che vedete che fanno<\/em> UA-sniffing specifico per WebKit e\/o usano solo le propriet\u00e0 con il prefisso -webkit-<\/code>. In maniera simile, aiutiamo ad evangelizzare le correzioni per tutti i siti webdev che promuovono, anche implicitamente, l’uso del WebKit UA-sniffing e\/o l’uso delle propriet\u00e0 con il solo prefisso -webkit-<\/code>.<\/p>\n

Ancora pi\u00f9 importante, impostate un buon esempio: usate innanzitutto gli standard web nei vostri siti, articoli e presentazioni. Quando discutete o dimostrate delle features sperimentali o degli standard-in-progress, sia in un browser o in molti, siate schietti con gli avvertimenti e rendete evidente che un brillante oggi pu\u00f2 significare un oscuro domani.<\/p>\n

Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Durante una riunione pubblica del W3C CSS Working Group, il web standards lead di Mozilla Tantek \u00c7elik ha fatto esplodere una crisi nella Terra degli Standard Web quando si \u00e8 lamentato degli sviluppatori che non hanno capito ed abusano dei vendor prefix supportando solo quello di WebKit, creando cos\u00ec un panorama di monocoltura di browser. La soluzione che propone Tantek, far finta che Mozilla sia WebKit, ha infiammato molti animi nella comunit\u00e0 degli standard, specialmente quando i rappresentanti di Opera e Microsoft sono stati immediatamente d’accordo riguardo tale questione e hanno annunciato dei piani simili a quelli di Mozilla. Per andare alla radice della nuova enorme confusione, il nostro Eric Meyer intervista, in esclusiva per A List Apart, Tantek sul controverso piano di Mozilla di supportare le propriet\u00e0 con il prefisso -webkit-.<\/p>\n","protected":false},"author":818,"featured_media":7000646,"comment_status":"open","ping_status":"open","template":"","categories":[242,244,247,60,257],"tags":[],"coauthors":[304,353],"class_list":["post-240","article","type-article","status-publish","has-post-thumbnail","hentry","category-browser","category-css","category-html","category-numero-45-28-febbraio-2012","category-stato-del-web"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/240","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=240"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000646"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=240"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=240"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=240"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=240"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}