![](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2014\/04\/n91.jpg\")
Nei primi anni ’90, ogni pagina era un artigianale lavoro fatto con amore. Purtroppo, chiunque gestisse un grosso sito alla fine si sarebbe scontrato contro un muro: scrivere montagne di HTML personalizzato che avviluppasse contenuto di valore con markup standardizzato, con modifiche rozze del design e con altre cose difficili da mantenere.<\/p>\n
Ben presto, i grandi siti abbandonarono interamente le pagine scritte a mano. La sostanza di una pagina venne memorizzata in un database e poi passata attraverso dei template HTML per “avvolgerla” in elementi di design quali i footer, le sidebar e i banner ads. Al giorno d’oggi anche elementi come il nome di un libro, la foto della copertina o la biografia dell’autore vengono separati dalla parte HMTL relativa al design e memorizzati come “chunk” individuali. I creatori di contenuti non combattono pi\u00f9 con canvas HTML vuoti ma riempiono semplicemente delle form di input, lasciando che i template del CMS sistemino gli elementi a seconda delle esigenze.<\/p>\n
Questo approccio “fields-and-templates” funziona molto bene per quel contenuto che segue dei pattern prevedibili, come le pagine con le informazioni di un prodotto, le photo gallery e i podcast. \u00c8 alla base del sistema di successo \u201cCreate Once, Publish Everywhere<\/a>\u201d (“Crea una volta, pubblica ovunque”) di NPR ed \u00e8 difficile trovare un CMS o un tool di web publishing che non offra un qualche<\/em> modo per modellare diversi tipi di contenuto.<\/p>\n Il Team Chunk, per\u00f2, ha una debolezza mortale: quanto il testo narrativo \u00e8 mischiato a dei media embedded, a dei call-out complessi o ad altro materiale ricco, i template strutturati cominciano ad avere dei problemi a tenere il passo.<\/p>\n Ne \u00e8 un esempio perfetto MSNBC.com: come parte del suo redesign del 2013, il canale di news via cavo mise pi\u00f9 enfasi sulla copertura di news approfondite e “web first”. Il design includeva molti moduli riutilizzabili che potevano essere posizionati su pagine gestite via template: video con playlist che li accompagnano, photo gallery, widget per le votazioni e teaser per gli articoli correlati. Quella standardizzazione port\u00f2 con s\u00e9 tutti i benefici della modellazione del contenuto di un CMS: rese il design pi\u00f9 consistente, semplific\u00f2 il processo di riutilizzo degli elementi “rich media” in storie diverse e fece s\u00ec che le regole CSS responsive rimanessero gestibili.<\/p>\n Sfortunatamente, i reporter e gli editor insistettero che questo metodo avrebbe paralizzato il loro lavoro: avevano bisogno di mischiare pi\u00f9 video, una gallery e una votazione o vari teaser da articoli collegati tra loro, in punti specifici di ciascun articolo<\/em>. Creare questi elementi in campi separati del CMS o in pezzi autonomi di contenuto avrebbe<\/em> reso pi\u00f9 semplice il loro salvataggio e il loro rimescolamento. Tuttavia, fare affidamento su template CMS basati su regole per mostrarli avrebbe anche rotto le loro connessione alle frasi, ai paragrafi e alle sezioni specifiche che avrebbero dovuto migliorare.<\/p>\n Questo \u00e8 il modo in cui il markup complesso si fa strada nel campo body di un articolo. Ben presto, si aggiungeranno dei tool WYSIWYG per aiutare gli editori con limitate conoscenze di HTML. Prima che qualcuno si renda conto di cosa sta succedendo, esplode l’uso di markup orientato alla presentazione. Si rompono i layout mobile e il compito gi\u00e0 arduo del riutilizzo di contenuto cross-channel diventa ancora pi\u00f9 difficile.<\/p>\n C’\u00e8 un problema comune in un blog post con dei tweet “embedded”, in una recensione comparativa che illustra ciascun prodotto con una photo gallery e in una storia che richiama del materiale a supporto da un articolo precedente: l’approccio “fields-and-templates” non funziona per queste piccole sacche della struttura.<\/p>\n<\/div>\n Se siete cresciuti durante le WYSIWYG Wars, quando strumenti come Adobe PageMill e la feature “Save to Web” di Microsoft Word spruzzavano in internet markup terrificante, potreste pensare che un markup HTML pi\u00f9 pulito sia la risposta a questo problema. Uccidi quegli attributi style inutili, assicurati che i tag Il markup pulito e semantico \u00e8 importante, ma non risolver\u00e0 problemi strutturali complessi come il bisogno della MSNBC di inserire widget nel testo della narrazione. Abbiamo degli elementi stacanovisti come Immaginate di voler inserire una semplice photo gallery in un articolo. Il suo markup potrebbe essere pulito e semanticamente corretto, ma il fatto che la galleria abbia un titolo, tre foto, un link ad una pagina dedicata e una caption? Queste<\/em> sono le decisioni di design che potrebbero cambiare in futuro e noi dobbiamo separarle dalla mappatura del markup del nostro contenuto in HTML.<\/p>\n Il problema, comunque, non \u00e8 ristretto all’industria editoriale: il mio team, recentemente, ha incontrato delle sfide simili durante la realizzazione di un portale di una compagnia di assicurazioni sanitarie per il suo dipartimento Risorse Umane (HR). La maggior parte del contenuto sul sito da 50.000 pagine includeva istruzioni step-by-step complesse, step speciali per tipi specifici di impiegati o call-out appropriati per lavoratori di un certo stato ma non di un altro. Anche con un editor WYSIWYG, le strutture HTML necessarie erano troppo complesse da creare per gli utenti aziendali del sito.<\/p>\n Il punto centrale del problema \u00e8 un disaccoppiamento del vocabolario. Sebbene l’HTML standard sia sufficientemente ricco perch\u00e9 un designer possa rappresentarci<\/em> del contenuto complesso, non \u00e8 sufficientemente preciso per descrivere e memorizzare<\/em> il contenuto in maniera indipendente dalla presentazione. Questo \u00e8 il motivo per cui gli strumenti WYSIWYG possono peggiorare il problema: piuttosto che schermare i creatori di contenuto dalla complessit\u00e0 del markup, rendono pi\u00f9 semplice descrivere il contenuto usando il vocabolario sbagliato.<\/p>\n Ora, nel tentativo di combinare i requisiti di un design multi-device con narrazioni complesse e arricchite da contenuti multimediali, ci scontriamo contro il muro. L’approccio a pezzi, “fields-and-template” che abbiamo sviluppato non ci salver\u00e0 dal disaccoppiamento tra il nostro contenuto e i tool descrittivi di HTML.<\/p>\n<\/div>\n Sebbene i campi e i template siano riusciti a dominare i tool di web publishing, il mondo XML ha passato gli ultimi 15 anni circa a sviluppare un approccio alternativo. Piuttosto che suddividere il contenuto in campi per riassemblarlo in seguito, la comunit\u00e0 di XML adotta documenti fluidi basati sul markup<\/a>. Per catturare una struttura significativa ed evitare i trabocchetti della presentazione “browser-specific” di HTML, definiscono delle collezioni di tag di markup con uno scopo preciso per diversi progetti e applicazioni. \u00c8 un approccio versatile che ha incrociato il suo percorso con quello del mondo dell’editoria web: lo standard XHTML \u00e8 solo HTML definito come uno schema XML.<\/p>\n Lo standard Darwin Information Typing Architecture, meglio noto come DITA, \u00e8 un esempio maturo di questo approccio. Sviluppato da IBM e annunciato nel 2001, DITA fu creato dalla community della documentazione tecnica. Nel lontano 2005, Adobe lo us\u00f2 per memorizzare e gestire i manuali dei software della Creative Suite<\/a>, pi\u00f9 di 100.000 pagine con illustrazioni, cross-reference e metadati complessi, il tutto in 14 lingue. Sia l’edizione cartacea sia quella online furono generate dallo stesso insieme di files DITA.<\/p>\n Il cuore di DITA \u00e8 un famiglia di Schema XML standard che definiscono un ricco vocabolario di elementi del contenuto. I tag compatibili con HTML come Una volta che questi documenti semanticamente precisi sono stati creati, \u00e8 necessario uno step di trasformazione per trasformare il contenuto strutturato nell’output finale. Un tool per il web publishing potrebbe leggere una directory di files DITA XML, sostituire gli elementi segnaposto con il testo cui fanno riferimento, espandere i tag personalizzati in markup HTML con degli stili, togliere il testo destinato specificatamente ai manuali stampati e cos\u00ec via.<\/p>\n Questo approccio non \u00e8 privo di svantaggi. Gestire grandi collezioni di articoli e documenti correlati richiede che gli utenti che ne fanno l’editing capiscano le sfumature delle relazioni specifiche e il modo in cui influenzano il prodotto finale. Sebbene il pi\u00f9 semplice schema DITA sia simile a HTML, altre variazioni aggiungono centinaia di tag e propriet\u00e0 “special-purpose”.<\/p>\n Nel pi\u00f9 ampio mondo del web publishing, potrebbe essere necessaria pi\u00f9 personalizzazione per ottenere gli stessi benefici. Sebbene il contenuto semanticamente ricco sia pi\u00f9 pulito e pi\u00f9 semplice da ridestinare, creare dei tool editoriali e dei processi di pubblicazione usabili sulle basi di DITA pu\u00f2<\/em> essere tanto scoraggiante quanto realizzare un complesso sito web multicanale.<\/p>\n<\/div>\n La buona notizia \u00e8 che non dobbiamo<\/em> convertire tutti i nostri progetti in XML per imparare dalla saggezza accumulata da queste comunit\u00e0. Nonostante le “toolchain” che sono state create attorno a questi approcci vadano strette agli strumenti e ai workflow dell’odierno maturo sviluppo web, possiamo usare i loro principi<\/em> nei nostri progetti.<\/p>\n Quando nel testo della narrazione appaiono delle complesse strutture di markup, riducetele all’osso. Sostituite i complessi stili con dei tag personalizzati che descrivano il loro significato preciso, come Elementi pi\u00f9 complicati del campo body, come le gallerie con pi\u00f9 immagini o gli inserimenti di media pieni di metadati, dovrebbero<\/em> essere suddivisi in campi di contenuto separati. Se devono essere riutilizzati tra pi\u00f9 pezzi di contenuto, rendeteli item di contenuto indipendenti in un CMS. Invece di fare affidamento su template basati su regole per posizionarli, comunque, usate dei segnaposto come Questo approccio fa diventare un articolo o un post una specie di manifesto, con i campi della narrazione come “Body” e “Riassunto” che fungono da poliziotti del traffico per la collezione di elementi supportati propriamente separati. In seguito, nell’output, possono essere rimessi insieme.<\/p>\n Gli editor e i creatori che lavorano con contenuto complesso hanno bisogno di strumenti per manipolare il vocabolario nativo del contenuto, non il design visuale finale o le sfumature specifiche del browser di HTML. Recentemente, Wikipedia ha presentato per la prima volta un assistive editing tool che aiuta i nuovi utenti a navigare nella complessit\u00e0 del contenuto del sito. Offre un insieme limitato di strumenti di formattazione, ma d\u00e0 agli editor l’accesso con un click agli standard del markup specifico di Wikipedia, come le citazioni inline, il testo boilerplate e le call per le revisioni editoriali.<\/p>\n Questi tipi di decisioni non sono universali: sono create su misura per le peculiarit\u00e0 del contenuto di uno specifico progetto. Disabilitare tutti i trag HTML tranne quelli proprio di base e aggiungere pulsanti “one-click” per gli elementi custom di un sito pu\u00f2 trasformare un editor WYSIWYG comune in uno strumento “structure-friendly”. \u00c8 anche il modo migliore per evitare il disordine nel markup derivante dal cliccare pulsanti finch\u00e9 non sembra giusto.<\/p>\n Quando viene il momento di pubblicare il contenuto, possiamo trasformare questi tag e segnaposto personalizzati nel formato finale di destinazione. Se il design cambia, devono solo essere fatte delle modifiche nel codice o nei template che trasformano il markup, non in ogni singolo pezzo di contenuto<\/em> in cui appaiono le strutture.<\/p>\n Inoltre, si possono applicare trasformazioni diverse agli elementi personalizzati a seconda del contesto. L’elemento Questo processing non deve per forza avvenire lato server. Tool client-side come jQuery<\/a> e AngularJS<\/a> possono essere usati per applicare dei comportamenti complessi basandosi su attributi personalizzati, assegnando stile ed interazione con elementi custom, sostituire i segnaposto con markup standard o fare “lazy-load” di media adeguati alle esigenze di un device.<\/p>\n<\/div>\n Questa triade di tecniche (uso di elementi e propriet\u00e0 custom che rappresentino il significato del contenuto, trasformarlo in HTML in output ed assicurarsi che i tool di editing condividano lo stesso vocabolario) ha gi\u00e0 cominciato a muoversi nel mondo del web publishing.<\/p>\n Gli “Short Tags” di WordPress sono una semplice applicazione di questa tecnica e i plugin di terze parti possono presentare agli editor un insieme personalizzato di tag segnaposto realizzati in base alle loro necessit\u00e0. Sebbene l’uso da parte di WordPress di segnaposto con le parentesi come Nessun evento imminente<\/p><\/code><\/a> e EZPublish<\/a>, un CMS basato su PHP molto popolare, permette di memorizzare il contenuto come XML piuttosto che come HTML. Gli sviluppatori possono impostare dei tag personalizzati le cui propriet\u00e0 e il cui contenuto viene mappato in dei template per l’output. Sebbene non sia automatico, questi tag personalizzati possono essere integrati nei tool di editing nativi di EZPublish, cos\u00ec che i creatori di contenuto non debbano usare del puro markup per inserirli.<\/p>\n Drupal 8, attualmente in via di sviluppo, avr\u00e0 un il tool WYSIWYG CKEditor nativo. Sar\u00e0 pre-configurato con un insieme minimo di tag HTML, ma user\u00e0 i data attributes di HTML5 per memorizzare propriet\u00e0 aggiuntive<\/a> come le caption, i suggerimenti di layout e altro sugli elementi semplici. Quando viene reso il contenuto, i text filter di Drupal lo trasformeranno nella rappresentazione finale: classi CSS, tag Questo approccio al contenuto strutturato non far\u00e0 sempre affidamento su tool di pubblicazione web complessi. Molti standard relativi ad HTML5, raggruppati sotto la categoria ombrello dei Web Components<\/a>, alla fine renderanno possibile fare queste trasformazioni nel browser stesso. L’abilit\u00e0 di definire degli elementi personalizzati ci porter\u00e0 pi\u00f9 vicini alla flessibilit\u00e0 del vocabolario di XML, i template HTML supportati dai browser saranno in grado di sostituire al volo quegli elementi con markup “representational” pi\u00f9 complesso e Shadow DOM dar\u00e0 ai designer un modo per provare in “sandbox” le complesse interazioni JavaScript e CSS all’interno di quegli elementi personalizzati.<\/p>\n Il supporto dei browser per questi comportamenti \u00e8 chiaramente irregolare, ma strumenti quali Polymer<\/a> sono pensati proprio per colmare queste lacune. Nel frattempo, possiamo ancora dipendere dagli elementi HTML esistenti, migliorati con i data attributes<\/a> per sostituire quelli personalizzati. Sebbene dobbiamo ancora fare il lavoro per trasformarli, trovano un compromesso tra un preciso vocabolario su misura del contenuto e un markup pulito e browser-friendly.<\/p>\n<\/div>\n Usare questo approccio “narrative-friendly” verso il contenuto strutturato non \u00e8 un gioco da ragazzi: i creatori di siti, i content strategist e i designer devono comprendere quello che succede all’interno<\/em> del campo body, non solo i pezzi presi dal database che gli stanno intorno. Quali pattern nel contenuto devono avere dei semplici stili e quali si meritano un proprio tag personalizzato? Quali possiamo presumere che rimangano consistenti e per quali dovremmo prendere in considerazione dei cambi in futuro? Il nostro processo di pianificazione deve cominciare rispondendo a queste domande.<\/p>\n Inoltre, gli strumenti di editing del contenuto devono<\/em> essere realizzati su misura per riflettere queste decisioni. Troppi utenti sono abituati ai tool WYSIWYG “Dreamweaver nel campo body” orientati alla presentazione e farli tornare nella terra del puro markup \u00e8 la strada giusta verso il disastro. Sebbene l’insieme degli attuali tool WYSIWYG per il web possa essere personalizzato, accade raramente che li si possa modificare davvero per far s\u00ec che siano adatti al vocabolario del contenuto di un sito quando incombono le scadenze.<\/p>\n Tuttavia il riscontro potrebbe essere incredibile. Design pi\u00f9 ricchi e flessibili possono coesistere con la richiesta di editoria multicanale: i cambiamenti futuri al design possono svicolare il processo laborioso di sgrossare vecchi agglomerati di contenuto e tool pi\u00f9 semplici ed efficienti possono aiutare gli editori e gli autori a produrre contenuto migliore pi\u00f9 rapidamente. Possiamo mettere al sicuro il campo body per le future generazioni combinando il meglio di XML e il contenuto web strutturato.<\/p>\n Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":" Nel tentativo di combinare le richieste di design multi-device con testi pieni di contenuti multimediali, siamo finiti contro a un muro. L’approccio a pezzi (o chunk), composto di campi e template, che abbiamo sviluppato, non pu\u00f2 salvarci dall’accoppiamento sbagliato tra il nostro contenuto e gli strumenti descrittivi di HTML. La buona notizia \u00e8 che non dobbiamo convertire tutti i nostri progetti in XML per usufruire della saggezza della community di XML. Possiamo pubblicare del contenuto strutturato che supporti i bisogni degli editor e degli art director di oggi e contemporaneamente rendere il nostro contenuto adatto alle generazioni future, usando degli elementi e delle propriet\u00e0 personalizzate per rappresentare il significato del contenuto, trasformandolo in HTML come output e assicurandoci che i tool di editing condividano lo stesso vocabolario.<\/p>\n","protected":false},"author":818,"featured_media":7000726,"comment_status":"open","ping_status":"open","template":"","categories":[246,254,108],"tags":[],"coauthors":[415],"class_list":["post-447","article","type-article","status-publish","has-post-thumbnail","hentry","category-architettura-dell-informazione","category-content-strategy","category-numero-91-10-aprile-2014"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/447","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=447"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000726"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=447"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=447"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=447"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=447"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"MSNBC](\"http:\/\/d.alistapart.com\/391\/msnbc-screenshot_edit.jpg\")
Una “news story” di MSNBC, in cui gli elementi “rich media” devono apparire in punti specifici nelle storie ed includere caption, titoli, link correlati, etc.<\/p>\n\nPerch\u00e9 il “clean markup” non aiuta<\/h2>\n
<p><\/code> siano usati al posto dei <br \/><\/code>, usa i tag <ul><\/code> in maniera appropriata, presta attenzione ai nomi che scegli per le classi CSS e le cose si sistemeranno!<\/p>\nul<\/code>, div<\/code> e span<\/code>; degli strumenti di precisione come cite<\/code>, table<\/code> e figure<\/code> e dei nuovi elementi container di HTML5 come section<\/code>, aside<\/code> e nav<\/code>, ma a meno che il nostro contenuto sia davvero cos\u00ec semplice come una citazione senza attribuzione o una immagine con float, avremo bisogno di layour di elementi annidati e di classi CSS per catturare quello che vogliamo davvero<\/em> dire.<\/p>\n<aside class=\"gallery\">\n <h1><a href=\"gallery1.html\">Gallery Title!<\/a><\/h1>\n <figure>\n <a href=\"photo1.html\"><img src=\"photo1.jpg\" \/><\/a>\n <a href=\"photo2.html\"><img src=\"photo2.jpg\" \/><\/a>\n <a href=\"photo3.html\"><img src=\"photo3.jpg\" \/><\/a>\n <figcaption>Custom caption<\/figcaption>\n <\/figure>\n<\/aside><\/code><\/pre>\n\nNel frattempo, nel mondo di XML…<\/h2>\n
<ol><\/code> e <p><\/code> vengono usati per una semplice formattazione, ma lo standard definisce anche centinaia di ulteriori tag e propriet\u00e0 che descrivono i concetti pi\u00f9 complessi. Inoltre, include norme per delle “specializzazioni”: vocabolari add-on per un dato settore o progetto.<\/p>\n<task id=\"signup\">\n <title>Signing up for health insurance<\/title>\n <taskbody>\n <steps>\n <step>List your dependents<\/step>\n <step>Gather past medical information<\/step>\n <step>Fill out forms 21a, 39b, and 92c<\/step>\n <step audience=\"retail\">\n Hand in your paperwork to a supervisor\n <\/step>\n <step audience=\"corporate\">\n Deliver your paperwork to the HR office\n <\/step>\n <\/steps>\n <\/taskbody>\n<\/task>\n<p conref=\"..\/boilerplate.xml#disclaimer\">\n This text will be replaced by the boilerplate legal disclaimer.\n<\/p><\/code><\/pre>\n\nIl meglio di entrambe i mondi<\/h2>\n
Mettete il significato nel body, non l’aspetto<\/h3>\n
<warning type=\"hardware\">Non spegnere il server!<\/warning><\/code>. Quando un nuovo tag non \u00e8 appropriato, usate degli attributi personalizzati. L’attributo audience<\/code> di DITA ne \u00e8 un buon esempio. Pu\u00f2 essere applicato a molti diversi tipi di elementi, ma metterlo nell’attributo class<\/code> di cui spesso si abusa in CSS ne confonderebbe il significato.<\/p>\n<gallery id=\"1\" \/><\/code> e <teaser article=\"82\" rel=\"rebuttal\" \/><\/code> proprio all’interno dei campi della narrazione.<\/p>\nCreate tool editoriali per gli stessi elementi significativi<\/h3>\n
![\"Screenshot](\"http:\/\/d.alistapart.com\/391\/wikipedia-wysiwyg.jpg\")
Screenshot del rich-text editor di Wikipedia, con degli assistive tools per il markup specifico dei Wiki<\/p>\nTrasformare il contenuto perch\u00e9 si abbini al design<\/h3>\n
<gallery><\/code> citato prima potrebbe essere sostituito da pi\u00f9 immagini sottotitolate e con attribuzione di credits per la maggior parte dei browser web. Sui dispositivi mobile soggetti a vincoli di banda, una singola immagine thumbnail e i link all’intera galleria potrebbero essere inseriti al suo posto. Si possono prendere decisioni adeguate al contesto per i riassunti delle email, per le API del contenuto di partner o per i feed RSS: ciascuno di questi non \u00e8 altro che un passo di trasformazione alternativo.<\/p>\n\nLa notizia pi\u00f9 bella \u00e8 che oggi \u00e8 gi\u00e0 possibile<\/h2>\n
<\/code><\/a> renda il processing lato client di questi tag pi\u00f9 difficile, l’approccio che ne \u00e8 alla base \u00e8 lo stesso. Gli shortcode possono suddividere elementi complessi o riutilizzabili in campi ed entit\u00e0 separate, per poi posizionarli all’interno del campo body.<\/p>\n<custom name=\"about_author\" photo=\"author.jpg\" user_account=\"77\" >\nThe author wrote this article over a long holiday break, and regrets any eggnog-induced errors.\n<\/custom><\/code><\/pre>\n<figcaption><\/code> e cos\u00ec via. Gli utenti possono gestire tale complessa informazione usando i tool visuali di CKEditor invece del semplice markup, ma memorizzando contenuto di precisione e ottenendo in output dell’HTML semantico come comportamento di default.<\/p>\nUn futuro radioso<\/h3>\n
\nQuali sono i prossimi passi?<\/h2>\n