To se ne može kvalitetno riješiti. Možda u budućnosti, kada će HTML5/CSS3 postati standard i za email klijente.
Previše različitih email servisa/klijenata ljudi koriste.
Ako i radi u ovim poznatijim gmail, yahoo itd., ne znači da će raditi u nekom
desetom. A ima ih milion, ne možeš ih sve testirati itd.
Znam da, ali evo recimo mailchimp je to donekle uspješno rješio, njihovi newsletteri se dosta dobro prikazuju na različitim mail servisima. Znači, donekle je izvedivo, e sad, koliko kvalitetno pitanje je…
No slažem se, HTML5 i CSS3 su tu budućnost, e sad jedino je pitanje kad će ta budućnost doći 
Ali se ne bi bilo loše fokusirati na gmail te gmail mobilne aplikacije, a ostale ko j 
Probao sam uzeti nešto gotovo i onda sam se toliko iskilavio tražeći što-je-gdje i zašto-je-tako da sam odustao od tog pristupa i sinoć sam u notepad++ počeo od prazne stranice i praznog css-a. Definitivno mi je to bio potez dana.
Naravno da je nebo i zemlja. Treba dobro razmisliti što sve staviti na stranicu i kojim redoslijedom jer kasnije je sve teže popraviti.
Ja korisitio Foundation, jer Bootstrap nema nesto slicno.
@trnac ne znam, meni je Bootstrap toliko jednostavan, a uz to i odlicno dokumentovan.Evo upravo radim jedan malo obimniji PSD to HTML, rekao sam klijentu da mi treba 4 dana, da nema Bootstrapa to bi duplo potrajalo sigurno
Ja sam sebi napravio jedan css pre-parser, koji omogućava pisanje sljedeće sintakse:
#element
{
box-sizing:border-box;
float:left;
@destkop width:25%;
@mobile width:100%;
height:100%;
}
ili
#element
{
@destkop width:25%;
@mobile
(
max-width:$maxWidth;
width:100%;
)
}
a može se i cijeli element definirati samo za mobile ili samo za destkop
@mobile
(
#element
{
...
}
)
…prednost ovakvog pristupa spram onoga css-ovog @media() je u tome što su file-ovi olakšani…a i praktičnije je pisanje.
Olakšani iz razloga što pre-parser kreira posebno file-ove koji će se učitavati za mobile ili destkop verziju, tako da višak css uputa ne ide niti na mobile, a niti na destkop verziju. Svatko samo di treba ići…
A praktičnije pisanje, jer je em održavanje na jednom mjestu…ali isto tako mi se odličnim pokazalo dotjerivati neke sitnice na ovaj način. Samo se uskače na mjesta gdje treba dodati neku uputu za mobile ili destkop …
Ako je netko upoznat s less-om ili nekim drugim css preparserom, baš me zanima dali oni nude tako nešto slično za respozivni dizajn?
A taj parser, sam po sebi koliko je težak?
Tako si sa jedne strane možda dobio jednostavnije, tebi logičnije pisanje querya a sa druge strane imaš opet dodatno učitavanje tog prasera.
Po meni je to nepotrebno, jer su media querys jednostavni sami po sebi. Mene su razni RWD tutorijali samo bunili i ništa iz njih u vezi RWD-a nisam naučio. To je zato je jer svaki front endaš ima različit pristup toj problematici. Svaki pojekt je različit, različit DOM i nepostoji jednistvena RWD formula koja bi se mogla naštrebati. Isto vrijedi i za framewoks. Ne postoji taj koji će potpuno adekvatno poslužiti u svakoj situaciji.
Osudio bih se reći i da je RDW “način razmišljanja”, kojeg se treba uzeti u obzir i pri samom dizajnu, sketchu i prototypingu. Meni je trebalo dosta vremena da svoj 960 mentalni sklop prešaltam na RWD.
Jednom kada to “sjedne”, nema potrebe više za bootstrapom, fundationom, gridovima, parserima i sl.
Teoretski primjer;
Jedna jednostavna, prezetacijska stranica se može responzivno i skroz ispravno lomiti na sve rezulucije u 10-ak linija querya u css-u. Sve ostalo je overkill.
I onda uzmeš razliku u težini učitavanja tih 10-ak linija querya koje si sam napisao i težinu kopletnog RWD grida iz nekog frameworka…
Nikoliko
Parser postoji samo u develop modu, offline modu…ili kako god ga se trigira. Znači dok se projekt razvija, parser prije svakog reloda stranice razbija “script.bss” na “script.css” i na mobilnu inačicu: “script_M.css” .
Kasnije u production modu, učitavaju se samo gotove već parsirane skripte…destkop ili mobile skripte po potrebi…ovisno dali se poslužuje destkop ili mobilna verzija.
Kod less-a ti je ista stvar…ti uređuješ skriptu koja je “script.less”, a ona se parsira u “script.css” koju razumije browser.
Ovaj moj .bss je prema tome također moguće kombinirati i sa less-om i s čim god…nema tu nikakvih ograničenja. (Ali za sad mi nije ni trebalo, jer .bss nudi i varijable kao less, a jednog dana ću ih totalno izkrižati da izvučem najbolje iz jednog i drugog)
Inače danas nema previše smisla pisati css bez less-a (ili bilo kojeg drugog pre-parsera) jer je css toliko ograničen za uređivanje i održavanje pogotoovo, da je to strašno. Moraju se jednostavno unesti varijable i klase…koje css približavaju nekakvoj uređenoj strukturi…gdje dobiješ mogućnost da neke dimenzije izraziš kao zbroj drugih dimenzija…i svašta drugo.
Eto, jedna tek od prednosti preparsera je da omogući separirano pisanje pravila za destkop/mobile verziju koju će naknadno razdvojiti u zasebne file-ove.
To svakako…ali to je drugi par čarapa. Gornje služi da olakša tehnički dio izvedbe…bez potrebe da se time pristaje na ikakve kompromise.
Meni osobno se sviđa pristup lomljenje stranice. I ono što sam u praksi vidio - ne treba cjepidlačiti.
A so…
Nisam radio sa parserima,
sada mi malo jasnije.
Ali ne kužim šta misliš pod “css toliko ograničen za uređivanje i održavanje”.
Pod održavanje mislim na naknadne izmjene prilikom korekcije nekog parametra.
Tu je zahtjev jasan, svaka izmjena u layoutu treba zahtjevati što manje izmjena u kodu. (Pogotovo, na što manje mjesta u kodu)
A što manje izmjena možemo omogućiti isključivo sljedeći DRY dizajn, koji stoji za: Dont Repeat Yourself
Evo trivijalnog primjera. Imaš neku plavu boju na stranici koja prevladava, neka to bude: #2FAAD4
…i sad, sljedeći DRY ti ne smiješ lijepiti code boje posvuda, jer ako klijent kasnije odabere malo drugačiju nijansu…isto tako ćeš morati posvuda mijenjati taj code.
Logično, napravit ćemo klasu: .myBlueColor {color:#2FAAD4} …pa ćemo klasu lijepiti po svuda, a code naknadno možemo zamijeniti samo u atributu klase.
No imamo tu već jedan problem: boja se može pojaviti kao color, kao background-color, kao dio nekog gradienta, kao dio nekog shadow-a …i to te već tjera da razbiješ svoj DRY dizajn i da u najmanju ruku radiš nekoliko klasa koje sadrže izvorni code boje.
Druga nespretna stvar je što ne želim da moram na svaki element lijepiti klasu od boje, što ako želim imati klasu: .myBlueBox{} …kako ću boju iz klase .myBlueColor pridružiti u klasu .myBlueBox{} …ostaje nam jedino kasnije pisanje
<div class='myBox myBlueColor'></div> …jer nismo mogli DRY metodom prenesti code boje u .myBlueBox
Ali ocke, to su samo boje …to je zapravo jednostavno kako god okreneš 
Dolaze nam dimenzije…one su malo složenije od boja.
Kod dimenzija imaš malo više atributa koje ih mogu posjedovati:
top, left, width, height, padding, margin, padding-top, padding-left, …
…i sad kad imaš neku dimenziju u svom dizajnu ti ju moraš lijepiti posvuda. Ako se klijent kasnije sjeti, ja bi da su mi ovi razmaci malo veći…to može biti pravi problem. Jer taj razmak koji je uvijek isti, nekad je bio padding, nekad margin…nekad relative+left…itd itd…
A da stvar bude još kompliciranija, nekad ista dimenzija po vrijednosti kao taj razmak možda i nije u relaciji s tom vrijednosti! …dok neka druga dimenzija koja nije ista kao taj razmak, može biti u relaciji s tom dimenzijom! Recimo, negdje imaš duplo veći razmak koji ovisi o tom razmaku upravo što mora biti “2 x tvoj_razmak”.
A relacije ovisne o tvom razmaku mogu biti svakakve, recimo: element_width: calc(100% - 2 x tvoj_razmak).
Ti naravno u css-u ne možeš napisati 2 x tvoj_razmak, pa ručno računaš potrebnu dimenziju i tipkaš ju na njenu poziciju kao mrtvo (pasivno) slovo …koje se proturječi DRY dizajnu, jer ako ćeš mijenjati vrijednost razmak, morat ćeš tražiti svugdje u code-u gdje si koristio taj razmak, ili gdje ti je nešto kalkulirao ovisno o tom razmaku. Prilično gadno za održavanje i za autora code-a, što tek ako će kasnije raditi izmjene netko drugi…
E sad, divota koju ti omogućava preparser: kreiraj varijablu
Jednostavno napraviš:
$myBlueColor = #2FAAD4;
Kasnije kad definiraš klasu .myBlueBox =>
.myBlueBox:
{
color:$myBlueColor;
…
}
…više nema ni potrebe da radimo uopće klasu .myBlueColor koju ćemo lijepiti po svuda, možemo direktno vrijednost varijable staviti u klase gdje trebamo…bilo pod color, background-color…shadow…itd. A kod izmjene, mijenjamo samo vrijednost varijable $myBlueColor.
Kod dimenzija dobivamo još puno više benefita, zato jer prepaser omogućava:
$my_razmak=10px;
$my_double_razmak=2*$my_razmak;
…znači omogućava zbrajanje, oduzimanje…dijeljenje…svašta. Nema potrebe da se išta onda radi izvan DRY dizajna, a cijela stranica se može napraviti skroz povezano da kad se promjeni jedna dimenzija u parametru…da sve sjedne točno tamo gdje treba sjesti. To sa čistim CSS-om je nemoguće za imalo kompleksniji layout.
LESS (ili SASS), ako nisu već postali standardi…postat će uskoro! A nije ih teško naučiti i zato nema razloga da se ne koriste.
Oni nude i puno više od gore spomenutog…ali fora je da kad pišeš css za less, ti zapravo i ne moraš ništa znati od mogućnosti koje on nudi…jer ako pišeš čisti css, sve će štimati…samo preparser neće imati što doraditi. Znači, ti od njega možeš koristiti onoliko metoda koje ti se sviđaju ili koje si upoznao…sve ostalo izgleda kao css isto kao i prije.
A da samo koristiš varijable, imaš već ogroman benefit spram “mrtvog” css-a. Nadam se da je sad jasnije zašto je ograničen.
Shvaćam.
Da, ima to prednosti…
Čuo sam hiljadu puta za LESS i SASS ali sam ih poistovječivao sa frameworcima.
Baciti ću oko na neki tutor.
O da, mislim da u svojem CSS-u imam 3145643 puta napisan isti kod boje.
Odličan info 
@Bozoou ti si kralj pisanja tutorijala. Ovo što si napisao u vezi parsera mi je razbistrilo poglede. Krenuo sam pa stao u istraživanje naprednijih mogućnosti u kreiranju css-a no nikako si nisam uzeo više vremena. Sjetim se kad počnem duplirati kodove po css-u i kad mi je potrebna izmjena jedne boje a ona se nalazi na preko nekoliko mjesta.
Mislim da se trenutno treba fokusirati na SASS, a LESS ostaviti po strani.
Koliko znam i novi Bootstrap 4 je prepisan u SASS iz LESSA.
Uglavnom zgodna stvar, a nije mnogo komplikovana.
Ja koristim SASS/SCSS i obični CSS ne znam pisati jer sam odmah učio raditi preko pre-processora
Osim varijabli i svega navedenog, za mene najveci preporod je bilo nestanje.
Znaci u klasicnom css-u:
.parent {
rule: value;
}
.parent .child {
rule: value;
}
A u SCSS-u:
.parent {
rule: value;
.child {
rule: value;
}
}
Sto se odabira LESS/SASS(SCSS) tice, SASS je trenutno vise “u modi”, no mnogi kao buducnost smatraju PostCSS.
Ja koristim SASS, odnosno SCSS. Za one koje buni ta razlika, SCSS je isto sto i SASS jedino sto koristi istu sintaksu kao obican CSS, dok SASS ne koristi zagrade {} nego forsira pravilnu indentaciju. Ja sam poceo sa SASS jer mi se to svidjelo a i dosta je cistije, ali me pocelo zivcirati kada sam copy paste-ao neke snippete iz starih projekata ili s neta pa sam ih morao formatirati. Ovako kada koristite SCSS, svaki CSS file je validan SCSS file.
scss + BEM
Slazem se, bem je pre dobra stvar. Za one koje zanima vise, preporucam http://webuild.envato.com/blog/chainable-bem-modifiers/ (ima i link na osnove BEM-a na pocetku).
Vidiš, zanimljiva još jedna primjena pre-parsera. Ne loša ideja da se pisanje CSS-a očisti od svih onih zagrada…
No meni se općenito svidjelo kako ti pre-procesori unose još neistražene mogućnosti koje postoje neovisno od ograničenja sintakse koju razumiju browseri…
Prilično cool.A snaga pre-parsera ne leži samo u parsiranju CSS-a, nego i JS-a. Tako reći …bilo bi moguće napraviti pre-parser JS-a koji će omogućiti pisanje sintakse kao u pythonu ili nekom drugom omiljenom programskom jeziku. Vjerujem da takve stvari već i postoje…kad se pogleda, oni alati za pisanje mobilnih aplikacija…gdje pišeš u samo jednoj sintaksi, a poslije dobiješ code i za android i za iOS …upravo jesu to.