Skip to main content

Anche quest’anno Intesys ha presenziato al CssDay, che si è tenuto a Faenza lo scorso 25 marzo e ha visto più di 200 partecipanti (numero in netta crescita rispetto all’edizione precedente).

Inclusa inizialmente nel JsDay, ormai la manifestazione si è guadagnata un intero giorno dedicato alle principali tematiche frontend. Quest’anno tra He-Man, rapper e quiz televisivi si è parlato di best pratices nello sviluppo e nell’organizzazione del team. Inoltre sono state introdotte alcune nuove features, che saranno disponibili prossimamente agli sviluppatori.

Per semplificare la lettura, questo articolo è diviso in due parti:

  • la prima, di interesse più generale, riguarda gli aspetti organizzativi del team e il miglioramento dei progetti attraverso l’accessibilità;
  • la seconda, più tecnica, tratterà invece di tools e features che migliorano, o miglioreranno, il lavoro e la produttività dei frontenders.

Organizzazione e Accessibilità

In questa sezione, dal carattere riflessivo ed etico, Vittorio Vittori ha parlato del metodo di lavoro e dell’organizzazione tra i frontenders e gli altri team (in particolare sviluppatori e designer).

Riassumendo per punti:

  • utilizzo di una metodologia (BEM, SMACSS, OOCSS). Lo scopo di una metodologia è standardizzare la naming-convenction all’interno del team, semplificando la scrittura di codice ordinato, scalabile e manutenibile nel tempo. Utilizzando una metodologia conosciuta si migliora anche il tempo di ambientamento su un nuovo progetto, quindi nuove risorse possono lavorarci pur non conoscendolo appieno. Tra tutte le metodologie spicca BEM (Block Element Modifier), che risulta essere la più utilizzata;
  • divisione del codice in più files, organizzati in una struttura gerarchica. Questo comportamento rende il codice più pulito e più semplice da manutenere. I singoli file, poi, possono essere riutilizzati in altri progetti se organizzati in maniera opportuna;
  • stesura di una styleguide Css: il codice scritto viene commentato dai frontender e, tramite dei tools, viene generato un sito presentazione di stili e componenti custom. Questo è molto utile, specialmente su progetti medio-grandi, dove il layout viene smontato e montato da persone diverse o in siti con molti elementi ripetuti;
  • formattazione del Css scritto: praticamente un controllo ortografico del codice. Il processo può essere automatizzato (tramite dei linter). Mantenere uno stile di scrittura uguale per tutti può essere utile per abbattere le “perdite” di tempo principali: l’analisi del codice presente per cercare le problematiche o i componenti da estendere.

Un tema molto importante è stato discusso da Marco Solazzi e riguarda l’accessibilità di un sito.

Per ogni sito è presente una fascia di visitatori con disabilità motorie o di percezione (dislessia, problemi di vista come daltonismo o addirittura cecità), difficoltà nell’utilizzo del mouse: tutti elementi che, se non presi in considerazione, ne rendono difficile la navigazione e causano l’allontanamento.

Il problema di tipo prestazionale (cioè di perdita di una fascia di utenti) è il primo, ma c’è anche quello etico: dovremmo, infatti, rendere un sito visibile al maggior numero di utenti possibile, qualunque difficoltà abbiano nella sua fruizione.

Si può ad esempio paragonare un sito ad un teatro: se non sono presenti gli scivoli all’entrata in alternativa alle scale, come fanno disabili o anziani in carrozzina ad entrare? Va considerato che in Italia, oltre alle motivazioni di tipo etico, l’accessibilità è prevista per legge sui siti pubblici o di interesse pubblico (vedi legge Stanca).

Come si può garantire l’accessibilità di un sito?

Di seguito alcune best practices:

  • utilizzare contrasto elevato e font ridimensionabile (o creare una versione ad alto contrasto del tema, attivabile da interfaccia);
  • migliorare la renderizzazione dell’outline sugli elementi dinamici del sito, in modo da guidare correttamente i visitatori che utilizzano solamente la tastiera;
  • utilizzare semanticamente i tag HTML, per favorire la fruizione e la navigazione con screen reader e/o dispositivi simili;
  • adottare tecniche di “Don’t speak” per filtrare parti di testo che non devono essere lette dagli screen reader;
  • utilizzare gli attributi ARIA.

Su diversi progetti, il cui target può avere una parte rilevante di persone con disabilità, la garanzia dell’accessibilità può rivelarsi un valore aggiunto sia per il visitatore che per il cliente.

Best practices e nuove features per Frontenders

Non sono mancati i talk puramente tecnici, che offrono delle buone best pratices e la descrizione di alcune nuove features disponibili ai developers.

Interessante l’intervento riguardante le responsive images, in cui sono stati elencati i possibili metodi per implementarle:

  • via svg (non utilizzato perché molto difficile e molto poco supportato);
  • via srcset/sizes (buon supporto tranne IE)
  • via picture element (supportato da Chrome e Firefox)

Grazie al loro utilizzo è possibile ridurre notevolmente il peso delle immagini scaricate dal client, selezionando quelle adatte in base a risoluzione schermo/pixel density, aumentando sensibilmente la velocità di rendering e riducendo il traffico generato sul server. Fortunatamente esistono i polyfill per IE, quindi è possibile utilizzare questi tag/attributi sui progetti.

Matteo Guidotto ha parlato di PostCss, un tool che si sta affiancando, e in molti casi addirittura sostituendo ai vari preprocessori che ci hanno aiutato finora (Sass, Less, Stylus).

Come suggerisce il nome esso trasforma i Css, scritti o generati, eseguendo plugins JS (autoprefix, concatenazioni, minificazione, linting in base ad una configurazione descritta nel file di build). La differenza principale tra i preprocessori tradizionali e postCss è appunto la possibilità di quest’ultimo di essere esteso a piacere, attraverso un ecosistema di plugins composto da più di 200 pacchetti. Il fatto di essere scritti in JS (node) semplifica il tutto, consentendoci di estenderlo in base alle nostre necessità,  risparmiandoci di imparare linguaggi alternativi.

Dopo la partecipazione al FEVR di marzo, Davide Di Pumpo ha presentato anche al CssDay il suo speech su Flexbox, il nuovo attributo Css3 che da anni si propone di rivoluzionare lo sviluppo del frontend, eliminando un sacco di hacks che durante i numerosi anni di sviluppo sono stati creati, a scapito della semantica del documento. I floats e il clearfix sono (finalmente) destinati a scomparire!

Pienamente supportato dai moderni browser tramite autoprefixer, può essere supportato anche da IE9 tenendo in considerazione alcune best-practices e/o aiutandosi con Modernizr.

Giacomo Zinetti ha poi parlato di Css custom properties: feature Css che arriverà nel futuro (ma già ottenibile, seppur parzialmente, utilizzando un plugin postCss), che permette di dichiarare proprietà Css personali, da utilizzare come variabili Css dinamiche lato Client.

Maurizio Mangione ha poi parlato della gestione degli stili nei web components e dello shadow DOM, utilizzato dai più recenti framework (React, Polymer e Angular 2).

I web components risultano particolarmente potenti in progetti modulari quali applicazioni, gestionali, etc. grazie alla loro flessibilità ed indipendenza rispetto ai componenti esterni (ogni componente ha un suo DOM, che non deve essere modificato dagli altri, che si devono limitare ad emettere azioni che modificano lo stato).

 

No Article rating
0 Reviews
Cosa ne pensi dell'articolo?
  1. Amazing
  2. Good
  3. Bad
  4. Meh
  5. Pff
NEWSLETTER