• HOME
  • Blog
  • Alle prese con il codice HTML? 6 errori frequenti da evitare
Andrea Russo
21 Dicembre 2017
Tempo di lettura: 11 min.

Alle prese con il codice HTML? 6 errori frequenti da evitare

Nelle settimane passate abbiamo fatto una rassegna degli errori più comuni in cui è possibile incappare nella gestione delle immagini nelle email. In questo post approfondiamo 6 aspetti legati al codice HTML, per assicurarsi una comunicazione più snella e pulita.

Errore 1. Utilizzare un codice troppo verboso

Sappiamo che grazie al linguaggio HTML e al CSS è possibile costruire la struttura di un’email e dare una forma (o meglio una formattazione) in maniera tale che si visualizzi, ad esempio, un certo tipo di font, uno specifico colore di sfondo, immagini e così via.

Per alcuni aspetti, sia i tag HTML che i CSS assolvono, sovrapponendosi, alla stessa funzione. Facciamo un esempio pratico: definiamo sia in HTML sia in CSS si il colore di sfondo per una tabella.

Il codice è riportato nell’immagine. Si può notare che ci sono due punti dove si definisce il colore di background:

  • bgcolor=”#e75c00” è l’attributo del tag table;
  • background-color è l’attributo del CSS applicato alla tabella.

Entrambi gli attributi fanno la stessa cosa, perciò si sovrappongono: impongono il colore arancione (#e75c00 secondo il formato esadecimale) allo sfondo della tabella.

Ora dovrebbe essere più chiaro il punto critico: l’accavallarsi delle definizioni di proprietà tra HTML e CSS. Spesso, infatti, nei vari rimaneggiamenti o nelle variazioni dello stesso modello di email può capitare che il codice sia appesantito da proprietà ridondanti che assolvono la medesima funzione.

Ma c’è di più. Dal momento che gli stili inline possono essere applicati a ogni singolo elemento, potrebbe presentarsi anche questo (perverso) caso:

Un browser (o un client di posta) leggerebbe il codice più o meno così:

  • Applica uno sfondo di colore grigio (bgcolor=”#efefef”) alla tabella
  • Successivamente applica uno sfondo di colore nero (bgcolor=”#000000”) alla riga
  • Infine applica uno sfondo di colore arancione (background-color: #e75c00) alla cella che contiene la scritta Hello World!

In questo e nell’esempio precedente il risultato finale è identico: una scritta bianca su sfondo arancione. Il problema è che nel secondo caso si sono definite tre diverse regole di sfondo. Quella visualizzata dall’utente è quella definita sulla cella perché il browser legge il codice sequenzialmente (table -> tr -> td) e dato che l’ultima definizione è stata imposta sul <td> è proprio questa che sarà visualizzata.

È evidente che gran parte del codice non è necessario. Non solo perché l’unico colore di background visualizzato è quello applicato alla cella, ma anche perché uno dei propositi del buon Email Marketing è mantenere quanto più possibile leggera la comunicazione. Un codice molto verboso e ridondante non è un codice leggero.

Le nostre raccomandazioni:

  • Mantenere il codice il più pulito possibile
  • Evitare le ripetizioni non necessarie nella formattazione del codice
  • Preferire gli stili inline
  • Cercare di costruire una struttura modulare del codice della comunicazione
  • Cercare di mantenere il codice quanto più ordinato, tramite indentazione (esistono diversi servizi online che fanno questo, come HTMLformatter o Clean CSS), per avere a colpo d’occhio la struttura della comunicazione
  • Tenere traccia dello storico dei macro cambiamenti di un modello
256x218
prova la piattaforma
Attiva la trial gratuita e scopri cosa puoi fare con MailUp.

Dallo sviluppo di integrazioni al supporto strategico, dalla creazione di concept creativi all’ottimizzazione dei risultati.

Errore 2. Commentare eccessivamente il codice

 

Come per la maggior parte dei linguaggi, anche l’HTML ha la possibilità di inserire dei commenti. Che cos’è un commento in uno script HTML? È una porzione di listato che viene ignorata dal programma che legge ed esegue il codice.

Si può notare che tutto ciò che si trova tra <!– e –> non solo è di un colore differente (dipende dal programma di editing), ma soprattutto non viene visualizzato a schermo.

Ciò permette di inserire delle “comunicazioni di servizio” riguardanti il codice che si è scritto oppure indicazioni su parti che devono essere ancora completate o migliorate.

Esiste anche un altro modo per utilizzare i commenti. Dal momento che tutto ciò che è tra il marcatore di apertura e di chiusura non viene mostrato, con esso è possibile celare intere parti di pagina, come mostra il successivo esempio. Infatti si può vedere che a video sono visibili solo tre righe al posto di quattro che sono scritte nel codice.

L’utilizzo dei commenti è utile, certo, ma non bisogna abusare dello strumento: se è vero che il codice commentato non viene mostrato, è altrettanto vero che rimane nella comunicazione inviata, appensantendola.

Le nostre raccomandazioni:

  • Usare i commenti sapientemente: ad esempio per indicare l’inizio e la fine di strutture della comunicazione o per inserire indicazioni utili per lo sviluppatore
  • Non essere prolissi nel commenti, meglio ancora scriverli in inglese
  • Eliminare il codice commentato prima dell’invio in quanto non necessario ai fini della comunicazione

Errore 3. Non definire i contenuti dell’email

In fase di progettazione di un’email, ancor prima di scrivere una singola riga di codice, è bene definire alcuni parametri che non possono essere modificati nella successiva fase di realizzazione e di conseguenza in produzione.

Alcuni di questi parametri sono:

  • Larghezza della email
  • Dimensione delle immagini
  • Numero delle immagini
  • Dimensione del font usato nell’header
  • Dimensione del font del testo principale

E così via. Spesso si tralascia un parametro altrettanto importante, ovvero il numero di battute massimo per un qualsiasi elemento testuale. A questo punto si potrebbe obiettare che si sta peccando di fanatismo normativo, ma ci sono due buoni motivi per preferire la rigidità all’assenza di regole. Il primo è concettuale, il secondo operativo.

A livello concettuale, contenuto (testo, immagini, etc.) e contenitore (struttura HTML) sono due entità ben separate con una gerarchia ben precisa, che vede il primo subordinato al secondo.

È infatti il contenuto che si deve adattare al contenitore, e non viceversa. Quando si scrive il codice, si costruisce l’architettura della comunicazione definendo il contenitore. Una volta plasmato, il contenitore rimane tale a prescindere dal contenuto.

Per essere sintetici – parafrasando Bruce Lee – il contenuto è come l’acqua: se metti l’acqua in una tazza, diventa la tazza; se metti l’acqua in una bottiglia, diventa la bottiglia; se metti l’acqua in una teiera, diventa la teiera.

Non si può pretendere che una tazza diventi bottiglia, così come una teiera non sarà mai una tazza. Quindi deve essere il testo (o un’immagine o un bottone) ad adattarsi alla struttura che lo contiene, e non viceversa.

Il secondo motivo è più operativo. Se a priori si conoscono esattamente tutti i parametri che vanno a comporre la comunicazione, allora in fase di stesura è possibile realizzare non solo una comunicazione più efficace, ma anche una comunicazione più equilibrata.

Facciamo un esempio più concreto: supponiamo di avere una DEM con due prodotti affiancati l’uno all’altro. Di solito a un prodotto vengono associati:

  • Un’immagine
  • Il nome del prodotto
  • La descrizione del prodotto
  • Il prezzo
  • La CTA che punta alla pagina del prodotto

Ora, visto che i prodotti sono affiancati, deve esserci necessariamente anche un bilanciamento tra le parti. Ciò significa che le immagini dovranno avere la stessa altezza, che i testi descrittivi dovranno avere una lunghezza simile e le due CTA non dovranno esser troppo dissimili.

Ignorando o non rispettando questi principi base si può presentare il caso dell’immagine qui sopra. La simmetria tra i due elementi è spezzata perché a sinistra il titolo del prodotto è così lungo da andare su tre righe, mentre a destra è così corto da rimanere su una singola riga. Si è introdotta una distonia che in ultima analisi indebolisce tutta la comunicazione.

Il rispetto di queste regole diventa ancora più importante se si pensa al mondo mobile, dove le risoluzioni dei vari device sono le più disparate: dai 1125 x 2436 px dell’iPhone X ai 1440 x 2960 px del Samsung Galaxy S8, passando per i 768 x 1280 px del Microsoft Lumia 1020.

Questa enorme eterogeneità (che si sovrappone alla già fitta savana dei client di posta elettronica) non permette di avere un controllo totale della visualizzazione della DEM in quanto non esiste il codice definitivo che si adatti ovunque alla perfezione. Ciò che non si riesce a controllare via codice, quindi, deve essere controllato indirettamente, agendo sulle altre parti che compongono una email, come appunto la lunghezza dei testi o le dimensioni delle immagini.

Le nostre raccomandazioni:

  • Definisci in tutte le sue parti il template
  • Mantieni la coerenza tra le varie parti della comunicazione
  • Rispetta le regole che ti sei dato
  • Gli strappi alla regola sono ammessi, ma in piena consapevolezza
  • Se il template non soddisfa le esigenze, pensa di definirne uno nuovo

Errore 4. Sbagliare i numeri di telefono e indirizzi interattivi

Alcune volte, in particolar modo nel footer, il titolare dell’email inserisce le informazioni per esser contattato. Di solito sono presenti un indirizzo e/o un numero di telefono, che rivestono un’importanza particolare nella fruizione delle comunicazioni da mobile.

Questo avviene principalmente per due motivi:

  • Con un semplice click l’informazione diventa actionable, ovvero utilizzabile in un’app che gestisca il dato (calendar, telefono, navigatore)
  • Lo spazio di visualizzazione è ridotto quindi un’informazione, anche se posta nel footer, ha comunque una maggior visibilità

Nel momento dello sviluppo di una comunicazione, risulta quindi importante non tralasciare anche questi dettagli, il cui comportamento sui vari device è differente. Soffermiamoci su un esempio realizzato ad hoc tramite una simulazione. Entrambi gli esempi sono visualizzati da iPhone 6+ iOS 9.

L’immagine a sinistra raffigura la newsletter ricevuta dall’utente con il testo inserito direttamente, senza alcuna formattazione.

Dal punto di vista tecnico è tutto corretto, ma bisogna tenere conto che lato mobile lo stesso codice viene interpretato dall’app di posta. Essa “legge” il testo della mail e quando riconosce un testo con la forma di una data, di un indirizzo o di un numero di telefono aggancia automaticamente il link attivo alla rispettiva app – Calendar, Mappe oppure telefono.

Tutto molto comodo: con un singolo click è possibile fare una telefonata, mettere a calendario un evento oppure aprire la mappa per stabilire un itinerario. Quello che stride è la resa grafica, con gli antiestetici blue link e la sottolineatura. Quindi che fare, come procedere?

Si può intervenire con un piccolo workaround – un trucco – per riportare le cose alla normalità. Perché intendiamoci: anche se sono degli strappi alla regola di un HTML ben formattato, i workaround risultano indispensabili nel mare magnum dei client di posta elettronica, per rendere visualizzabile su quanti più client possibili la comunicazione.

Come siamo intervenuti sul codice?

Risolvere la questione del telefono è semplice: dal momento che il tag anchor permette di definire anche un numero di telefono tramite tel nella proprietà href, andiamo ad aggiungere il numero di telefono senza alcuno spazio o linee di separazione.

Per l’indirizzo o la data, invece, bisogna agire diversamente: è necessario definire una classe (.address) che imponga il colore (color:#ffffff;) al tag anchor che inserirà automaticamente il client e soprattutto che elimini la sottolineatura di default di ogni link (text-decoration:none;).

Si noti che entrambi gli attributi della classe address hanno !important, il che impone al client di applicare a prescindere la proprietà. Senza di esso non è detto che il workaround funzioni.

Le nostre raccomandazioni:

  • Fare sempre attenzione alla visualizzazione della comunicazione da mobile (ovvero, effettuare dei test)
  • Ove possibile, fare dei micro fixing per rendere la comunicazione mobile-friendly
  • Non dare per scontato che ciò che va bene per desktop lo sia anche da mobile
  • Conoscere la propria audience: quale tecnologia utilizza? Quali device? Quali supporti?
  • Sperimentare le proprie comunicazioni anche con test interni, soprattutto quando si verificano aggiornamenti consistenti delle app client di posta

Errore 5. Non ripulire da tag abbandonati o vuoti

Sempre nell’ottica di cercar di mantenere ai minimi termini il peso complessivo della comunicazione, bisogna porre attenzione a quelle parti del codice esistenti, ma svuotate del loro contenuto naturale.

Facciamo subito un esempio concreto: un tag <font>, magari con una serie di stili inline, che non contiene alcun testo. Ovviamente lato email non sarà possibile leggere alcunché, tuttavia il tag di formattazione <font> continua ad esistere occupando spazio fisico nell’email.

Un altro classico esempio sono i tag anchor <a> che non hanno alcun oggetto linkato, quindi un qualcosa del tipo: <a href=”https://www.mailup.it” style=”color:#00000;text-decoration:none”></a>.

Di solito questi “errori” sono presenti in quel codice che è stato rimaneggiato o utilizzato molte volte, per cui diverse parti come immagini, link e testi sono state inserite, modificate, cancellate.

O ancora, potrebbe essere indice dell’uso scorretto di un editor WYSIWYG. Questi editor, infatti, se utilizzati male o con poca accortezza, hanno il difetto di aggiungere codice su codice, visto che ogni elemento predefinito ha normalmente una parte di codice definita al momento della realizzazione dell’editor stesso.

Il programma applica acriticamente il modello ogni volta che verrà inserito l’elemento selezionato: rimaneggiando un numero sufficiente di volte la stessa parte della email, ecco che possono sorgere problemi dati da tag abbandonati e non più utilizzati.

I nostri consigli:

  • Controllare sempre che non esistano tag abbandonati o vuoti in fase di scrittura del codice
  • Se si usa un editor WYSIWYG e se è possibile accedere al codice, fare una verifica che tutto sia in ordine e non ci siano errori come quello appena descritto

Errore 6. Usare HTML non validato

Parlare di validazione per il codice di una email è un argomento spinoso. Di cosa si tratta, innanzitutto?

“Most pages on the World Wide Web are written in computer languages (such as HTML) that allow Web authors to structure text, add multimedia content, and specify what appearance, or style, the result should have.

As for every language, these have their own grammarvocabulary and syntax, and every document written with these computer languages are supposed to follow these rules. The (X)HTML languages, for all versions up to XHTML 1.1, are using machine-readable grammars called DTDs, a mechanism inherited from SGML.

However, Just as texts in a natural language can include spelling or grammar errors, documents using Markup languages may (for various reasons) not be following these rules. The process of verifying whether a document actually follows the rules for the language(s) it uses is called validation, and the tool used for that is a validator. A document that passes this process with success is called valid.

With these concepts in mind, we can define “markup validation” as the process of checking a Web document against the grammar (generally a DTD) it claims to be using”.

Definizione W3C

Il W3C, come custode e garante del codice, ci viene in aiuto fornendo uno strumento di validazione del codice la cui analisi indica gli errori e suggerisce la loro correzioni. Grazie a questo tool è possibile individuare e correggere gli errori di struttura più grandi.

È bene ricordare che, lato codice, nel mondo dell’Email Marketing si presenta spesso una situazione dicotomica:

  • Da un lato l’HTML, cioè un linguaggio standardizzato con regole e strutture ben precise
  • Dall’altra una serie di workaround non standard, spesso deprecati, ma che funzionano egregiamente per ottenere una corretta visualizzazione sui client di posta elettronica

Questi due aspetti sono come una vecchia coppia sposata in cui la passione si è spenta da tempo: non sanno bene perché convivono, ma sono costretti a farlo scendendo a compromessi. Allora perché parlare di validazione del codice? Ha senso? Quali sono i compromessi?

Ha senso parlare di validazione del codice nel momento in cui ci si pone in una prospettiva più ampia, senza scendere troppo nel particolare. Quindi in un’ottica di struttura, di moduli in cui è composta l’email, di tabelle che costituiscono l’ossatura della comunicazione, ha perfettamente senso avere un codice quanto più pulito e vicino allo standard dettato dal W3C.

Ma bisogna prendere atto della realtà: il compromesso consiste nella realizzazione di una struttura solida e funzionale, a cui si vanno ad aggiungere i workaround in una sorta di fine tuning per estendere una visualizzazione corretta a quanti più client possibili.

I nostri consigli:

  • Se hai dei dubbi sul codice, la validazione può esser un veloce e buon strumento di analisi
  • La validazione del codice può essere un buon strumento per individuare velocemente gli errori più grossi in un listato di codice
  • Un codice validato è sempre un’ottima base di partenza per una successiva evoluzione e adattamento della comunicazione con i workaround per renderla quanto più universale
  • La validazione può essere vista come il “tagliando” del codice, soprattutto su modelli manipolati e maneggiati spesso
  • Costruirsi, con l’accumularsi dell’esperienza, una piccola libreria di soluzioni ad hoc per i vari client in maniera da risparmiare tempo nella risoluzione dei problemi.

Qual è la tua esperienza con il codice HTML delle email? Quali gli errori più frequenti in cui ti sei imbattuto? Faccelo sapere nei commenti sotto!

Share this article

80x80
Andrea Russo

Nerd al 100% certificato; appassionato di astronomia, fisica e matematica. Credo nell’eleganza della semplicità, nel pensiero critico e nella sintesi hegeliana di esperienze come fucina di nuove idee.

    Ricevi aggiornamenti e novità con la nostra newsletter!