Bespotrebno kompliciranje.
Responzivan dizajn nije uveden tek onako, jer je nekom liku bilo dosadno u zivotu.Iskoristi ga i ostavi se hard codinga.
EDIT:
A sto se tice example stranice - dovoljno je reci da je radjena u table layout-u i sve je jasno.
Znači, umjesto jednog sajta radiš dva različita, i svaku i najmanju izmjenu moraš raditi duplo.
Ako te veseli nepotrebno si komplicirati život, može i tako, ali trebaš znati da je to upravo suprotno od responzivnog dizajna.
Biti ce ispravljeno, bas je vlasnik danas pregledavao sajt prvi puta pa mi je poslao par gresaka.
Kako rješavate menu?
Na desktopu ih imam dva, jedan vodoravno, drugi okomito lijevo.
Na smanjenom ekranu mi je to previše i moram reducirati. Jedna od opcija je da napravim JS menu, na gumbić pa dropdown. Druga opcija je ostavim sve samo smanjim što je dosta nezgrapno.
Ideje i best practices?
Imas jos jednu opciju, a to je select box.
Lajkam 
Prikaz tabličnih podataka je dosta zeznut. Još nisam odlučio što ću ni kako ću, nekoliko zgodnih ideja http://exisweb.net/responsive-table-plugins-and-patterns
Dvojim između tabličnog prikaza s reduciranja broja stupaca i prikaza red-po-red.
Zasto jednostavno ne koristis Bootstrap ? Ne moras cijeli mozes samo cekirati stavke koje zelis
http://getbootstrap.com/customize/
Ustedjeti ces dosta vremena, ok za neke sitnice nema potrebe za Bootstrapom, ali za neke nazovimo ih normalne projekte neces naci bolje rijesenje.
Just sayin’ 
RWD je proces o kojemu treba razmišljati na početku, odnosno istovremeno kada se počme razmišljat o DOM-u.
Ja sam u početku radio kritičnu grešku. RWD sam ostavljao za kraj, nakon što iskucam html/css a to je koma.
Kada pogledam svoje query-e i RWD “princip” iz 2012. i danas; razlika je nebo-zemlja:)
Zbog navedene kritične greške u startu, trebalo je puno više CSS iskucati da dobijem ono šta danas,
planiranjem dobijem sa puno manje koda.
Poveznica na temu, responzivni mailovi, netko radio, netko rješio ? U browseru mi recimo normalno radi kad odem na preview, ali u gmail aplikaciji na mobitelu nema šanse…
Uglavnom je logika ako je media-width veći od 600px ide se na px u table cellovima, a ako je manji onda na postotke… Čak postoji i “bootstrap” za mailove - http://foundation.zurb.com/emails
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.