Differenze tra browser uguali (WebKit).
In Chrome e Safari background-size: cover (che serve a scalare dinamicamente lo sfondo) può non rendere nello stesso modo, ovvero viene ignorato da Chrome, SE nel .css non hai indicato prima l’immagine di sfondo. Mi ero accorta che all’improvviso Chrome non stretchava più il background (vogliamo fa’ i responsive o no?) mentre Safari sì. Trovata soluzione e spiegazione su StackOverflow (benedetto).
Eterno debugging.
The CSS Ratiocinator automatically refactors your CSS and generates a new stylesheet for your site. It works by examining your site’s live DOM in the browser and reverse engineering a new, more elegant definition that captures styles down to the pixel.
(Fonte: onethingwell)
Tumblr blinda i paragrafi sotto ai post fotografici e video in una stringa {Caption} che da come output <p>...</p>. Questo significa che nel mark-up del tuo tema non puoi in nessun modo agganciare quel pezzo di html, non hai controllo su quel paragrafo.
Nel mio mark-up in locale avevo inserito ad apertura del paragrafo un’icona via <i class="mia icona"></i> perfettamente allineata e con gli stili giusti in cascata. Poi provato a tradurre il tutto in lingua tumblr dove <p> è chiuso in {Caption} l’iconcina mi veniva spostata alla fine del paragrafo. Allora mumble mumble, mi sono industriata per un soluzione alternativa CSS only sfruttando lo pseudotag :before.
#photo figcaption p:first-child:before {
content: "\f020";
word-spacing: 1px;
position: relative;
top: .14em; margin-right: .5em;
font: normal normal .85em "GeneralFoundicons";
}
In questo modo, si prende a target il primo elemento del primo paragrafo e lo si fa precedere dall’elemento dichiarato nella seconda riga, un simbolo del mio webfont. Per riuscire però ad allinearlo come se fosse naturalmente inserito nel flusso del testo è stato necessario regolare il posizionamento e la grandezza del font. Il risultato è quasi identico a quello che sarebbe stato più semplice e pulito se avessi potuto inserire il mio markup in quel paragrafo, e di certo la misurazione dei margini può essere sminchiata da questo o quel browser.
Questo è Tumblr e ti devi rassegnare, è così e l’hai scelto tu come piattaforma (ma è un social network). Snello, duttile, veloce, ma estremamente grezzo. L’output di html ingarbugliato e schifoso (farà fede il nome?) che produce non è scusabile. Da quanti anni non ci lavorano? Sono stata 3 ore a correggere questo post causa stringhe di codice inserite da editor visuale (con markdown starei altre 3 ore), e ogni volta che capita mi rendo conto che la scarsa voglia di scrivere, che limitarmi a postare inutile rumore (foto, video, reblog con blockquote annidati), è colpa della piattaforma che davvero, per scrivere, è lammerda.
Sì, smanettare con l’antialiasing in CSS fa più danni che altro perchè il supporto dei vari browser è molto frammentato e ogni sistema operativo ci mette il suo. Siamo d’accordo.
Io invece stasera sto cercando proprio di fissare l’antialiasing su un icon font, semplicemente perchè di default viene visualizzato male, soprattutto su Chrome. L’iconcina del + è blurry rispetto al testo.
Poi poichè sono spericolata sto controllando l’output in Chrome beta (living on the edge!™), ma lavorando da Espresso, che ha un motore di rendering un po’ vecchio (oltre a vari bachi). Praticamente due Webkit distinti.
Trovato qualche sistema che funzioni? No. Con -webkit-font-smoothing: none; il testo esce tipo come su System 6. Con -webkit-font-smoothing: antialiasing; è blurry. Esiste un -webkit-font-smoothing: subpixel-antialiased; segnalato da Max Voltar, che è quello che si vede applicato nell’immagine sopra, ma come è evidente non produce risultati apprezzabili sul mio icon font (Foundation Icons, niente roba convertita più o meno male). Dipenderà dal font, con font più ortodossi le differenze sono evidenti.
Alla fine se tolgo completamente l’antialiasing o lascio il subpixel antialisaing il risultato non varia. Stop fixing antialiasing (e tienitelo di m…).
Full.
Tumblr, più che scriverci ci faccio inconcludente manutenzione.
Zelle: le freccette (sbadataggine) e la box con gli avatar (<ul> e <li>) che mantiene i margini corretti solo a culo, visto che lo spazio viene ricalcolato tra viewport variabile e grandezza delle immagini fissa, e non sempre restano in proporzione. Non c’è soluzione, credo. The truth is that fluid grids are broken.
PS: dopo aver visto la preview di questo post m’è passata la voglia di pubblicarlo (le box delle foto, così incomplete, quel pugno in occhio delle stringhe di codice su sfondo nero), ma lo pubblico lo stesso :))
Homer Simpson in CSS e Verdana. Quanta fatica per niente :))
L’ortodossia tipografica vuole che un blocco di testo, per risultare agevole da leggere, sia di una larghezza compresa tra 45 e 75 caratteri spazi inclusi (un autorevole riferimento qui). In un layout fluido, con un container che fluttua a seconda del viewport (la larghezza della finestra di un browser, o la larghezza del display tout court in un tablet o un telefono), è difficile che un blocco di testo non sfori il limite 45-75. Allargate a dismisura la finestra mentre state leggendo questo and enjoy :(
Si può usare max-width:1140px nel container (1140 è la misura più duttile e la più utilizzata nei sistemi a griglia, vedasi Cssgrid.net), ma ancora è difficile che si abbia un blocco di testo di 45-75, tranne nel caso in cui sia confinato in un div o una section all’interno del container. Ma viene fuori un mark-up ingarbugliato e brutto.
L’unica per restare nel limite di quella larghezza è adattare la grandezza del font fino a che non si raggiunga 45 di minimo o 75 di massima (l’ideale è 66, ad essere pignoli). Viene fuori del testo a prova di nonno. Può non piacere. Trent Walton è un sostenitore del testo a prova di grandi miopi. Tutto il suo blog è così. E sì, si legge una bellezza. Ma è anche molto osseo come design, 99% testuale. Inoltre non tutti i font si comportano bene a tutte le grandezze. Alcuni risultano favolosi, ma i più temo tremendi.
Ho provato a farlo io. Il font slab è un horse power ciuccio e rende benissimo, più è grande più è bello. Il sans serif, mmmh. Così così. Qui in full size (che è quello che interessa). Non so se terrei queste dimensioni…
Interessante. Chrome visualizza @font-face usando i file .svg, che di solito vengono inseriti come ultimi nella lista di file e relativi url da chiamare, dopo .woff e .ttf. Esempio:
@font-face {
font-family: 'chunk-webfont'; src: url('../../includes/fonts/chunk-webfont.eot');
src: url('../../includes/fonts/chunk-webfont.eot?#iefix') format('eot'), url('../../includes/fonts/chunk-webfont.woff') format('woff'), url('../../includes/fonts/chunk-webfont.ttf') format('truetype'), url('../../includes/fonts/chunk-webfont.svg') format('svg');
font-weight: normal;
font-style: normal;
}
Chrome impiega i file nell’ordine in cui sono dichiarati, anche se non sono quelli che digerisce meglio, producendo in questo modo un rendering non ottimale. Se invece pesca subito gli .svg la visualizzazione è migliore. Basta quindi anticipare gli .svg al secondo posto, dopo gli .eot. Ricordando che la chiamata ai file .eot va messa obbligatoriamente per prima altrimenti IE non visualizza i webfont (perchè oltre la prima riga non legge: cretino o stronzo?).
Il logo di Sass (Syntactically Awesome Stylesheets), YEAH.
An experiment on creating volumetric 3d-like clouds with CSS3 3D Transforms and a bit of Javascript. Spaventoso!
Con Firefox mille problemi. È schizzinoso sul file location, se i file non sono nella root del sito non li carica. Idem, root o meno, se sono dichiarati in @media screen. Idem se i webfont non sono encodati in base64. Fontsquirrel fornisce un servizio di conversione di font in webfont che usa questo encoding. Ho testato file generati con FontXChange (quello che uso quando mi do alle sperimentazioni di font illegali prima di comprare l’eventuale licenza) o forniti direttamente in un kit: effettivamente, non li digerisce. FontXChange inoltre genera un .css con sintassi un po’ approssimativa che già da sola impedisce la visualizzazione su Firefox (anche con conversioni corrette). Gli stessi file convertiti con Fontsquirrel, in base64, vanno.
Safari:
Chrome Canary (webkit filters sulle immagini)
Opera Next!
Firefox:
E tra l’altro, you get what you pay for:
Vendor prefixed properties were never supposed to be something developers could depend on. They were, and are, for experimental implementations and technologies in progress.
E invece.
post precedenti
pagina 1 di 2, puoi navigare da tastiera con ← e →
