Validare = sacrificare?
Mercoledì 18 Giugno 2008 - 09:31
di Cesare Lamanna
Questo post nasce raccogliendo gli spunti offerti dai commenti all’intervento sulla resa del testo in Safari pubblicato un paio di giorni fa. A quello rimando per i dettagli sulla questione, qui mi interessa porre alla vostra attenzione una questione più generale.
Nel secondo commento così si esprime, con grande puntualità, floyd:
Nella validazione del file CSS, le 2 dichiarazioni vengono rilevate come errori:
La proprietà
text-shadownon esiste per CSS versione 2.1 ma esiste in CSS2 e CSS3: #000000 0 0 0La proprietà
opacitynon esiste per CSS versione 2.1 ma esiste in CSS3: 0.9999999
Poco più sotto interviene Troglos:
In effetti ho dovuto eliminarla perché non mi validava più il CSS…
Ed eccoci al dunque. La tecnica oggetto del post consente di ottenere un miglioramento in termini di leggibilità del testo (su questo credo che convengano sia floyd che Troglos). Ora, uscendo dallo specifico e ragionando in termini generali, in casi simili sareste disposti a sacrificare un po’ di usabilità pur di ottenere l’approvazione del validatore del W3C?
Categoria: Web Standards | Permalink
Commenti
1
mhhh… dipende dai casi.
ad un sito a cui ho gia’ fatto passare la validazione mi seccherebbe rovinare tutto solo perchè safari ha deciso di renderizzare a modo suo le font.infatti in una web application che sto sviluppando, (scritta comunque in maniera standard) ma di cui non mi interessa ufficializzare la validazione, ho lasciato il codice css “incriminato”.
in tutti gli altri casi magari dovrei provare ad intercettare safari con uno sniffer e ad aggiungere il trick solo se serve
2
dipende dai casi e dal target di persone a cui è diretto il sito. Solitamente preferisco la validazione anche se talvolta ricorro a soluzioni intermedie.
3
Io punto ad un’accessibilità operativa e non formale, l’esempio da te fatto è solo uno dei tanti.
Solo quando viene richiesto formalmente l’adesione totale agli standard e relativo bollino mi adopero per validare al 100% css e Xhtml.
Alcune pratiche sono TOTALMENTE INNOQUE ma consentono di risparmiare tempo e di permettere hack vari.
…aspettiamo che tutti i browser aderiscano completamente ai css3
4
Ovviamente dipende dai casi, ma mediamente preferisco la validazione: anche se bisogna sempre controllare tutti i browser, in generale la validazione offre una tranquillità maggiore.
# - postato da Slam - 18 Giugno 2008 - 10:13
5
Per me erano leggibilissimi entrambi, quindi tra i due sceglierei il CSS che rispetta gli standard W3C
6
In tutta sincerità non vedendo il font rendering di Safari come problema (anzi) non mi preoccupo di hackare il tutto.
La tua domanda però é più generica e supera il caso particolare.Quando e dove vi sono contraddizioni tra una applicazione usabile o economicamente viabile e le specifiche (qualsiasi) come occorre comportarsi?
Personalmente seguo criteri di usablità e necessità economiche di prodotto/servizio sapendo, già nelle prime fasi del progetto, dove occorrerà deviare dalle specifiche ed il perché.
Le specifiche sono linee guida non tavole delle leggi.
# - postato da semioticmonkey - 18 Giugno 2008 - 10:33
7
Innanzitutto un grazie a Cesare per aver riportato il mio commento.
Anche io quoto Troglos: “dipende dai casi”. Se dovessi fare una applicazione per me, allora potrei anche accettare i 2 errori riportati.
Se, come spesso accade, un cliente dovesse dirmi: “Mi raccomando, che il sito sia validato css xhtml”, allora le cose sono diverse.
Io ho installato safari per Win solo per testare le pagine che realizzo e mi ero accorto di questa resa “diversa” rispetto agli altri browser. Onestamente non è un effetto che dà fastidio ma… se non ci fosse sarebbe meglio.
Tornando all’ipotetico cliente che “pretende” la validazione senza sapere, il delle volte, il significato semantico dei tag, allora la cosa cambia. Niente codice per safari, nel css. Chi vuole un sito non fa altro che “fregiarsi” dei 2 link, nel footer, alla validazione del codice. Come gli si spiega che le pagg. xhtml non sono scritte in maniera corretta? (leggi: content=”text/html;). Chi glielo dice che, ad oggi, mentre stiamo andando verso l’html 5, qualche anno fa ci stavano proponendo l’XHTML 2, tutto quello che vediamo attraverso i browsers, è solo e soltanto html 4.01? Ma questo, forse, potrebbe essere motivo di un’altra discussione. Scusate l’OT. :)
Floyd
8
Concordo con Semioticmonkey.
Secondo me l’importante è che eventuali elementi non validati non siano dovuti ad un errore o ignoranza del programmatore, ma siano stati inseriti con consapevolezza dopo un valutazione su costi/benefici, in mancaza di un’alternativa inserita nelle linee guida.Altrimenti, se si vuole fare i fondamentalisti della validazione “ad ogni costo”, si corre il rischio che questa sia solo uno “status” fine a se stesso da ostentare con il suo bel richiamo nel footer.
# - postato da idrolitina - 18 Giugno 2008 - 11:09
9
Quoto quasi tutto.
Tuttavia non dimentichiamo la definizione di CSS (foglio di stile a cascata) e quindi parliamo di stile, visual design oppure di accessibilità?
Penso che se opacity non è una proprietà valida, ma ho bisogno di utilizzarla, non capisco il motivo per cui debba usare javascript per definirla e non il mio bel foglio di stile, che appunto, serve per la presentazione. Alla fine resto sempre dell’idea che l’importante è avere un markup accessibile disabilitando il foglio di stile, e penso che spesso l’usabilità, la leggibilità di un testo debbano primeggiare nelle pratiche quotidiane del web design.
Alla fine creare un bell’effetto hover che utilizza qualche proprietà fuorilegge ma che miglira tanto l’usabilità e l’interattività di un layout non ha prezzo.
10
ho risolto tutto con 2 righe 2 di js
carico la proprietà text-shadow solo se il browser è safarila differenza si nota eccome!
mai piu font tozze con safari! ^__^
11
sdfsdf
# - postato da sdfds - 18 Giugno 2008 - 12:13
12
In questo caso, Safari non ha una quota di mercato cosi ampia da giustificare una violazione dello standard.. Fosse stato firefox o explorer ci avrei pensato, ma safari non è abbastanza diffuso ed utilizzato..
13
In genere preferisco avere un CSS validato, senza utilizzare proprietà su misura per i vari browser.
In certe situazioni però è molto più pratico personalizzare certi dettagli (vedi le trasparenze, ad esempio) direttamente dal foglio di stile, quindi può valere la pena “sporcare” il CSS.
Va considerato che all’utente finale il CSS non valido non importa e non crea problemi, quindi se può trarre maggiori benefici le aggiunte sono ben accette.
14
Come gli si spiega che le pagg. xhtml non sono scritte in maniera corretta? (leggi: content=”text/html;). Chi glielo dice che, ad oggi, mentre stiamo andando verso l’html 5, qualche anno fa ci stavano proponendo l’XHTML 2, tutto quello che vediamo attraverso i browsers, è solo e soltanto html 4.01? Ma questo, forse, potrebbe essere motivo di un’altra discussione. Scusate l’OT. :)
E chi l’ha detto che le pagine xhtml non sono state scritte in maniera corretta? che c’entra il content type? questa è una leggenda metropolitana.
Vediamo html4 o xhtml 1.0 perché questi sono gli standard disponibili, che problema c’è?# - postato da gino - 18 Giugno 2008 - 12:50
15
@Gino: forse nn mi sono espresso bene ma non credo si tratti di leggenda metropolitana. Non voglio ergermi a sapientone di turno ma c’è molta verità. Scrivere una pagina in html 4.01 ed una in xhtml 1.0, oggi, è la stessa ed identica cosa. Tag soup ti dice qualcosa? Le pagg in xhtml, essendo una riformulazione dell’XML, dovrebbero avere la dichiarazione di apertura (cosa succede in IE? Quirks mode). il content type c’entra eccome. Essendo una pagina derivata dall’xml, il corretto content è: content=”application/xhtml xml; Se a questo aggiungiamo che la pagina dovrebbe avere estensione .xhtml e non .html, ti invito a scrivere un qualsiasi testo, mettici il content type che ho scritto su, dalle estensione .xhtml e dimmi cosa vedi in IE.
Floyd
16
Continuo a non capire cosa intendi con tag soup. il tag soup lo fa lo sviluppatore quando si inventa codice del tutto arbitrario, mischiotti e beveroni.
La pappazza sul content type è leggenda metropolitana, non causa alcun danno alla pagina html o xhtml 1.0(certo, se è standard e valida). Diversa è la situazione con xhtml 1.1, dove accade quello che dici tu. Ma qui stiamo parlando di html/xhtml 1, quindi quello che dici non accade, così come non serve mettere il prologo a una pagina xhtml 1 in text/html.# - postato da gino - 18 Giugno 2008 - 21:39
17
@ floyd
Prospettiva visiva interessante, la tua… non avevo mai visto i due linguaggi da qual punto di vista… Mi documenterò a dovere… :)
18
@gino: scusami ma… sono io a non essere d’accordo con te; se l’xhtml è una riformulazione dell’XML… ne consegue che la pagina deve essere scritta con tag xhtml e non html. il prologo ci va eccome in una pagina xhtml (indipendentemente che sia 1.1). Inoltre… non credo si possa inventare codice del tutto arbitrario, in html o xhtml, tantomeno mischiotti e beveroni. :)
19
In casi simili sareste disposti a sacrificare un po’ di usabilità pur di ottenere l’approvazione del validatore del W3C?
Premesso che dipende dai casi e che, come qualcuno ha già detto, è necessario valutare sempre prima le conseguenze di una scelta di questo tipo, mi sento molto più lanciato verso l’usabilità che verso la validazione. Ciò non significa rinunciare a scrivere codice aderente alle specifiche, anzi. L’importante è non diventare i soliti “draconiani” disposti a rinunciare a tutto pur di passare la validazione.
Un po’ come disse Eric Meyer ai tempi del suo articolo sulla proprietà line-height espressa senza unità di misura: è il validatore che sbaglia e che va sistemato. Forse si dovrebbe cominciare a ragionare in questo senso. Seguire gli standards non significa solo passare un controllo automatico, ma anche conoscere a fondo le specifiche cui ci si sta riferendo.
20
No, xhtml non è una riformulazione di XML, è HTML con le regole di scrittura di XML, i tag sono sempre gli stessi e la loro semantica è sempre la stessa, più l’appendice C.
Con XHTML 1.1 invece la situazione cambia drasticamente.
Direttamente dalle specifiche XHTML 1.0:
[esempio dichiarazione doctype]
segue:
Nota che in questo esempio viene inclusa la dichiarazione di XML. Una dichiarazione XML come quella sopra non viene richiesta da tutti i documenti XML. Si raccomanda fermamente agli autori di documenti XHTML di usare le dichiarazioni XML in tutti i loro documenti. Questo tipo di dichiarazione viene richiesta quando la codifica dei caratteri del documento è un’altra rispetto a quella usata per default UTF-8 o UTF-16.http://www.w3c.it/traduzioni/x.....ml#docconf
Comincia a essere più chiaro perché parlo di leggenda metropolitana?
# - postato da gino - 19 Giugno 2008 - 13:14
21
Mantengo la versione con le proprietà CSS3 e, se nel sito ho uno dei famosi pulsantini del W3C che “certifica” la validazione, specifico che voglio validare rispetto ai CSS3:
http://jigsaw.w3.org/css-valid.....ofile=css3# - postato da Andrea Zilio - 31 Agosto 2008 - 19:45