[HTML/CSS] Responsive design - kan dit überhaupt (netjes)?

[posttoast]

Ik heb hier een ontwerp voor me liggen dat responsive gebouwd moet worden. Echter, ik vraag me af of dit überhaupt op een nette manier opgelost kan worden. Hieronder even de voorbeelden:

Ontwerp - desktopvariant (breed):


Ontwerp - tabletvariant (smal):


Zoals je ziet moet vlak 2 in een smallere resolutie tussen vlak 1 en 3 komen te staan. Op zich geen probleem, ik kan beide vlakken samen in een container zetten en naast elkaar laten floaten. Als de container te smal wordt klappen ze vanzelf onder elkaar.

Alleen: ik weet nooit van tevoren hoe hoog de vlakken worden. Het zou zomaar kunnen dat vlak 2 twee keer zo hoog wordt als vlak 1. En dan gaat het floaten natuurlijk niet goed, omdat vlak 1 dan veel te laag komt te staan.

De enige oplossing die ik kan bedenken is om vlak 2 in mijn media-query voor de brede variant absoluut te positioneren en rechts te zetten. Maar daar kleven natuurlijk de nodige nadelen aan, onder anderen dat ik in die rechterkolom alle "flow" kwijt ben.

Ik ben nu al even aan het piekeren over deze puzzel, maar zie zo 1,2,3 geen geschikte oplossing. Voordat ik snoeihard "KAN NIET!" ga roepen hoor ik graag nog even jullie mening

[jessy100]

Met floats gaat dit hem idd niet worden. ik zou ongeveer zoiets proberen:

code:

@media (max-width: XXXpx) {
    #Vlak2{
        float: none;
                /* Andere eigenschappen */
    }
}

[ Voor 19% gewijzigd door jessy100 op 05-10-2013 12:16 ]

[posttoast]

Jessy, dank voor je antwoord maar ik geloof niet dat ik je helemaal snap Hoe lost wat jij hier zegt mijn probleem op? En wat heeft text-align er mee te maken? Ah, je deed even een ninja-edit

In welke situatie zou je die float: none toepassen? In de "smalle" variant dus? En in desktop wel floaten? Maar dat gaat toch juist niet werken omdat ik niet weet hoe hoog vlak 2 is?

[ Voor 41% gewijzigd door posttoast op 05-10-2013 12:19 ]

[incaz]

Alles floaten (1 en 3 links, 2 rechts) kan volgens mij wel. Wat is het probleem als vlak 2 twee keer zo hoog is? Dan loopt het namelijk gewoon naar beneden door, en komt vlak 3 onder vlak 1.
Als je dat niet wilt kun je een clear-fix proberen (er zijn moderne oplossingen en ouderwetse zoals de <br style="clear: both">), dan komt vlak 3 onder het einde van vlak 2.

Verder is display: inline-block; mogelijk een oplossing: je kunt de blokken een breedte geven, EN ze worden in tegenstelling tot floats dan onder elkaar gezet volgens de text-align property. (Met een float: right schuift vlak 2 nog steeds naar rechts.)

Je kunt ook kijken naar de flexbox-oplossing, maar die heb ik nog niet geprobeerd.

Het enige wat mij nog niet geheel is gelukt is een logica als 'als het erop past, maak allebei de kolommen 50% en naast elkaar maar als het niet past, dan onder elkaar en 100% breed.' Dan komen mediaqueries eerder in beeld.

[jessy100]

posttoast schreef op zaterdag 05 oktober 2013 @ 12:17:
Jessy, dank voor je antwoord maar ik geloof niet dat ik je helemaal snap Hoe lost wat jij hier zegt mijn probleem op? En wat heeft text-align er mee te maken?

Ja dat textalign mag je van mijn part negeren, was meer om aan te duiden dat je daar andere eigenschappen neer kan zetten. En wat het bovengenoemde stuk code doet is dat het bij een apparaat met een schermbreedte kleiner dan XXX (zelf invullen) Pixels de float weghaald. Als de float weg word gehaald word vlak 2 Direct onder vlak 1 gepushed.

Edit:

Ik zou overigens de floats helemaal weglaten, dan moet je wel om vlak1 en vlak2 nog een "wrapper" Div geven. En die div geef je display:inline-block. Vervolgens haal je deze weg door de media query.

Dit zou, in theorie, moeten werken.

Edit:

http://jsfiddle.net/sygL9/539/ Als je daar de display:inline-block; verwijderd komen de elementen onder elkaar te staan. dit is het idee waar ik op doel. (Verklijn je browerser scherm maar eens in jsfiddle, dan zie je dat t werkt).

[ Voor 30% gewijzigd door jessy100 op 05-10-2013 12:33 ]

[posttoast]

Jessy, dank voor het meedenken. Maar ik ben óf te verkouden om je antwoord te begrijpen óf het klopt niet wat je zegt

Ik heb even in JSFiddle nagebouwd wat ik bedoel: http://jsfiddle.net/3REv2/6/

Het punt is dat je bij inline-block (maar ook bij floats) hebt dat het rechtervlak de boel naar beneden "duwt". Volgens mij is de enige oplossing om het rechtervlak absoluut te positioneren, maar met alle nadelen die daar bij komen kijken is dat voor mij een last-resort. Daarom wil ik graag weten of er écht geen andere oplossing is. Voor alle duidelijkheid hieronder nog een screenshot van mijn Fiddle:



En voor alle duidelijkheid: als je in JSFiddle je browser smaller maakt dan vertoont hij dus wél het juiste gedrag

[ Voor 8% gewijzigd door posttoast op 06-10-2013 12:37 ]

[incaz]

Bij floats heb je dat probleem juist niet: http://jsfiddle.net/3REv2/7/
Je moet dan wel een float op alledrie de elementen zetten. Nadeel daarvan is dat de collapse lelijk is op breedtes van 75% van de 2-kolom-breedte.

Maar met mediaquery's de float verwijderen voor smallere breedtes lost dat erg eenvoudig op.
Heb je een meegroeiende container nodig, dan zet je op .container{ overflow: hidden; } zonder height.

Full solution zou dan mi ongeveer dit zijn: http://jsfiddle.net/3REv2/8/
Die 550px in de mediaquery is een beetje experimenteel vastgesteld - je moet even goed de box-widths nagaan (borders en margins en paddings kunnen roet in het eten gooien).

En nu eens kijken wat de flexbox te bieden heeft. Als het lukt post ik een update

Edit: ik ben geneigd te zeggen dat flexbox hier geen oplossing biedt. Het is in elk geval niet triviaal (zeker niet eenvoudiger dan de float / mediaquery oplossing) en flex wordt zo te zien nog niet geheel ondersteund in firefox.

[ Voor 13% gewijzigd door incaz op 06-10-2013 13:50 ]

[bartbh]

Kun je hier niet wat met Masonry is of dat overkill?

[TheNephilim]

Als je alle drie de elementen gewoon float: left; meegeeft en bij Tablets word het float: none;, dan staat het toch precies zoals jij wil?

[MoietyMe]

Dit zal je niet zomaar in CSS kunnen maken. Je kunt kijken naar een JS die dit voor je doet, wel erg reken intensief voor het apparaat waar je het op bekijkt.

Wellicht dat je met flexbox nog wat leuks kunt maken, maar dat werkt niet in IE9 en lager.

[incaz]

TheNephilim: float: left werkt niet: de sidebar drukt het content-block naar beneden. (Ik had laatst een goede uitleg over floaten en clearen gevonden, maar die ben ik kwijt. Het komt er echter op neer dat een element niet links van een links gefloat element omhoog schuift.)

Good Fella: check anders mijn voorbeeldje even

[Nilsepils]

Kan je niet iets doen met het aantal pixels dat je device in de breedte heeft? en vervolgens het goede design voorschotelen?

Ik heb zelf alleen kennis van basis HTML/CSS, dus ik weet niet hoe je zoiets uit voert, maar zo zou ik het aanpakken.

[crisp]

Zoiets:

Cascading Stylesheet:

#div1 {
    width: 50%;
    height: 400px;
    background: lime;
    float: left;
}
#div2 {
    width: 50%;
    height: 600px;
    background: red;
    float: right;
}
#div3 {
    width: 50%;
    height: 400px;
    background: blue;
    float: left;
    clear: left;
}

@media (max-width: 767px) {
    #div1, #div2, #div3 {
        float: none;
        width: auto;
    }
}

[MoietyMe]

incaz schreef op maandag 07 oktober 2013 @ 21:09:
TheNephilim: float: left werkt niet: de sidebar drukt het content-block naar beneden. (Ik had laatst een goede uitleg over floaten en clearen gevonden, maar die ben ik kwijt. Het komt er echter op neer dat een element niet links van een links gefloat element omhoog schuift.)

Good Fella: check anders mijn voorbeeldje even

Hmm, ja met slechts twee kolommen werkt dat inderdaad wel. Moesten laatst ook zoiets maken op werk, maar dat was met 5 kolommen. Vandaar de verwarring.

Dan zou je de floats ook wat makkelijker kunnen regelen:

Cascading Stylesheet:

.columns > div {
  width: 50%;
  min-height: 100px;
}

.columns > div:nth-of-type(odd) {
  float: left;
}

.columns > div:nth-of-type(even) {
  float: right;
}

jsFiddle. Al is die ook redelijk snel om zeep te helpen met 6 items en een beetje pech in hoogtes.

Sterker nog, hij is ook omzeep te helpen door in de eerste meer content te plaatsen dan de tweede.

Hieruit kunnen we dus het volgende concluderen: dit systeem werkt alleen als het rechter item hoger is dan het linker. Iets waar je in responsive design eigenlijk nooit vanuit kan gaan.

Breakpoint ligt bij alle voorbeelden op 500px.

[ Voor 13% gewijzigd door MoietyMe op 08-10-2013 08:45 ]

[FotW]

Ik heb nu niet de tijd om in dit probleem te duiken, maar ik raad je aan om sowieso de volgende link eens door te lezen Smashing magazine artikel

Daarnaast denk ik dat je er niet aan gaat ontkomen om elementen met javascript te herpositioneren

[Bosmonster]

Heb dat artikel nooit zo goed begrepen. Het was eigenlijk al outdated op het moment dat het uitkwam, aangezien het uitgaat van desktop first en vervolgens gaat proberen dit op een mobieltje te proppen. Oftewel, problemen oplossen die je beter gewoon bij de bron kan aanpakken.

Gelukkig is daar al iets voor bedacht, en die methodiek heet mobile first.

[ Voor 6% gewijzigd door Bosmonster op 08-10-2013 14:34 ]

[incaz]

Bosmonster: dat lost het probleem niet op hoor. Ook met mobile first krijg je de nuttige informatie niet altijd op de plek die je wilt, omdat er soms gewoon conflicterende orderings zijn, en de css-mogelijkheden om dat op te lossen zijn beperkt.

[FotW]

Bosmonster schreef op dinsdag 08 oktober 2013 @ 14:33:
Heb dat artikel nooit zo goed begrepen. Het was eigenlijk al outdated op het moment dat het uitkwam, aangezien het uitgaat van desktop first en vervolgens gaat proberen dit op een mobieltje te proppen. Oftewel, problemen oplossen die je beter gewoon bij de bron kan aanpakken.

Gelukkig is daar al iets voor bedacht, en die methodiek heet mobile first.

Ben ik helemaal met je eens, echter linkte ik het artikel met als doel z'n probleem op te lossen, niet om z'n workflow aan te passen

[posttoast]

Late reactie, bedankt voor alle respons. De oplossing met floats werkt inderdaad prima. Ik heb geen idee waar ik het in mijn botte hersens vandaan gehaald heb dat die float hetzelfde gedrag zou vertonen als een inline-block.

Over het mobile-first CSSen vs aanpassingen doen met javascript in de DOM: ik heb met de ontwerper afgesproken dat wat mogelijk is met CSS leading is. Als dat betekent dat bepaalde zaken uit zijn ontwerp niet exact mogelijk zijn, dan is dat dus maar jammer. Ik ben sowieso niet zo'n fan van het gebruik van JS voor dit soort dingen. Content heeft (als het goed is) in de HTML een logische volgorde (semantisch gezien), om daaraan te rommelen puur voor het visuele vind ik niet zo'n strak plan. Maar goed, wie ben ik

[Munki]

crisp schreef op maandag 07 oktober 2013 @ 21:57:
Zoiets:

Cascading Stylesheet:

#div1 {
    width: 50%;
    height: 400px;
    background: lime;
    float: left;
}
#div2 {
    width: 50%;
    height: 600px;
    background: red;
    float: right;
}
#div3 {
    width: 50%;
    height: 400px;
    background: blue;
    float: left;
    clear: left;
}

@media (max-width: 767px) {
    #div1, #div2, #div3 {
        float: none;
        width: auto;
    }
}

Ik snap niet waarom er altijd de neiging is om desktop-first te werken.. Draai je mediaqueries om door er min-width van te maken. Zo voorkom je dat je CSS regels moet "resetten". In jouw geval moet je dus je floats resetten naar float none en je width terug naar auto, totaal niet nodig en zorgt alleen maar voor extra regels CSS. Daarnaast zijn er bepaalde styles die je niet eens kunt resetten. Wat doe je dan?

Geen mediaquery == mobiel (tot aan de eerste mediaquery en hoger)
Hier zou je de blokken in dit geval een kleur geven die je zowel in mobiel als desktop wilt hebben.

1e mediaquery: min-width van 768 pixels == iPad en hoger
Hier zou je de blokken dus floaten en een breedte van 50% meegeven, etc.

etc. etc.

Voorbeeldje:

Cascading Stylesheet:

#div1 { background: lime; }
#div2 { background: red; }
#div3 { background: blue; }

@media (min-width: 768px) {
    #div1, #div2, #div3 { width: 50%; } /* Of natuurlijk een specifieke class definiëren. Maargoed, niet belangrijk nu. */

    #div1, #div3 {
        float: left;
        height: 400px;
    }

    #div2 {
        float: right;
        height: 600px;
    }
}

Overigens ook niet nodig om ID's te gebruiken. Vertraagt de boel.

[ Voor 4% gewijzigd door Munki op 11-10-2013 00:51 ]

[MoietyMe]

Munki schreef op donderdag 10 oktober 2013 @ 23:48:
Overigens ook niet nodig om ID's te gebruiken. Vertraagt de boel.

Wellicht een andere discussie, maar op welke manier vertraagt het gebruik van ID-selectors en attributen 'de boel'? Naast dat je zinloos ID gebruik sowieso moet vermijden zou ik niet weten waarom je ze niet mag gebruiken/zou moeten beperken voor snelheid.

Naar mijn weten staat .classname gelijk aan #id in termen van snelheid. Dat is voor zover ik artikelen en onderzoeken heb gelezen over de processing time van selectors.

Cascading Stylesheet:

#id > .classname > header + section ~ footer > .author-name

Is volgens mij—naast een stuk ranziger en onbruikbaarder—niet langzamer/sneller dan:

Cascading Stylesheet:

.author-name

[R4gnax]

Good Fella schreef op vrijdag 11 oktober 2013 @ 01:10:
[...]

Cascading Stylesheet:

#id > .classname > header + section ~ footer > .author-name

Is volgens mij—naast een stuk ranziger en onbruikbaarder—niet langzamer/sneller dan:

Cascading Stylesheet:

.author-name

Oh nee. Natuurlijk; een selector die enkel een class name op de key selector hoeft de matchen is echt niet sneller dan een selector die daarna nog naar zijn parent node moet kijken, naar alle voorgaande siblings daarvan moet kijken, daarna van al die voorgaande siblings naar de inviduele direct voorgaande sibling moet kijken, op de parent nodes daarvan een classname moet gaan matchen en op de parent nodes daarvan weer een id moet gaan matchen.

Hoe kom je er toch bij dat er enig verschil in de snelheid zou zitten...[/sarcasm]

[Bosmonster]

Los daarvan is de stelling dat ID's gebruiken "de boel vertraagt" natuurlijk alsnog complete onzin.

[MoietyMe]

R4gnax schreef op vrijdag 11 oktober 2013 @ 08:54:
[...]


Oh nee. Natuurlijk; een selector die enkel een class name op de key selector hoeft de matchen is echt niet sneller dan een selector die daarna nog naar zijn parent node moet kijken, naar alle voorgaande siblings daarvan moet kijken, daarna van al die voorgaande siblings naar de inviduele direct voorgaande sibling moet kijken, op de parent nodes daarvan een classname moet gaan matchen en op de parent nodes daarvan weer een id moet gaan matchen.

Ik ben wel benieuwd naar wat statistieken die dat bevestigen

Kan er best inkomen dat de door mij geschetste selector niet bepaald performance vriendelijk is, maar als dat verschil .00000021 seconden is dan hebben we het hier over een 'moo' point.

[crisp]

Munki schreef op donderdag 10 oktober 2013 @ 23:48:
[...]

Ik snap niet waarom er altijd de neiging is om desktop-first te werken.. Draai je mediaqueries om door er min-width van te maken. Zo voorkom je dat je CSS regels moet "resetten". In jouw geval moet je dus je floats resetten naar float none en je width terug naar auto, totaal niet nodig en zorgt alleen maar voor extra regels CSS.

Simpel: omdat in veel gevallen het uitgangspunt al een bestaande desktop-geoptimaliseerde website is. Mobile-first zou dan betekenen dat je van scratch af aan moet beginnen. Daarbij moet ik zeggen dat in ons eigen responsive project hier bij Tweakers deze aanpak toch niet tegen blijkt te vallen.

Daarnaast zijn er bepaalde styles die je niet eens kunt resetten. Wat doe je dan?

Tegen dergelijke issues zijn wij nog niet aangelopen. Het voordeel van resetten is ook dat je het op een veel generieker niveau kan doen wat juist weer zorgt voor kleinere additionele stylesheets.

[...]

Voorbeeldje:

Cascading Stylesheet:

#div1 { background: lime; }
#div2 { background: red; }
#div3 { background: blue; }

@media (min-width: 768px) {
    #div1, #div2, #div3 { width: 50%; } /* Of natuurlijk een specifieke class definiëren. Maargoed, niet belangrijk nu. */

    #div1, #div3 {
        float: left;
        height: 400px;
    }

    #div2 {
        float: right;
        height: 600px;
    }
}

Je bent het belangrijkste nog vergeten: de clear: left op #div3

Als ik in mijn voorbeeld iets meer properties zou groeperen, of zoals je (overigens terecht, maar het was slechts een q&d voorbeeld) al aangaf voor generieke eigenschappen classes zou gebruiken dan scheelt het volgens mij weinig qua aantal rules.

Overigens ook niet nodig om ID's te gebruiken. Vertraagt de boel.

Selector matching is juist een van de dingen waar browsers tegenwoordig behoorlijk snel in zijn, en zeker enkele id-selectors zijn een van de snelste. Je moet juist oppassen met overgespecificeerde selectors, maar dat geldt voor alle type selectors.

[incaz]

Munki schreef op donderdag 10 oktober 2013 @ 23:48:
[...]

Ik snap niet waarom er altijd de neiging is om desktop-first te werken..

Scheelt een IE8-fix

Zo voorkom je dat je CSS regels moet "resetten".

Niet per definitie waar. Als je in je basislayout iets instelt dat je in de andere layout niet nodig hebt, kom je uit op resetten. Welke eerst is maakt dan niet zoveel uit. Als je immers je links een display: inline-block geeft om ze padding te kunnen geven voor touch moet je dat ook resetten voor desktop.

[Munki]

crisp schreef op vrijdag 11 oktober 2013 @ 09:41:
[...]

Tegen dergelijke issues zijn wij nog niet aangelopen. Het voordeel van resetten is ook dat je het op een veel generieker niveau kan doen wat juist weer zorgt voor kleinere additionele stylesheets.


[...]


Je bent het belangrijkste nog vergeten: de clear: left op #div3

Ik ben het hier dus totaal niet mee eens, als je je CSS moet resetten doe je het gewoon niet goed. (het 'normalizen' van je CSS buitengelaten.) Ook als je generieke resets gebruikt. Resets == extra onnodige regels. Als je uitgaat van een desktop-geoptimaliseerde website kan ik er min of meer mee inkomen dat je desktop-first wilt werken, maar uiteindelijk werk je jezelf alleen maar tegen, omdat, zoals ik eerder al aangaf, je CSS er echt niet kleiner op wordt en al helemaal niet overzichtelijker. Daarnaast kun je bepaalde styles dus niet resetten. Jij bent dat misschien nog niet tegengekomen, maar ik weet zeker dat dit uiteindelijk toch aan de orde gaat komen.

Mijn voorbeeld was overigens alleen maar om aan te geven hoe je het responsive gedeelte, in mijn ogen, goed zou kunnen doen. Dat ik een regel vergeten ben is dan ook irrelevant.

Maargoed, laten we verder niet offtopic gaan. Wellicht interessant om hier een aparte topic van te maken. Ik ben wel benieuwd hoe andere mensen hierover denken.


*EDIT*

@Incaz;

Scheelt een IE8-fix

Even een klein bestandje inladen (https://code.google.com/p/css3-mediaqueries-js/), nee, sorry, dat weerhoudt mij niet om mobile-first te werken.

Daarnaast houdt IE8 een keer op. Ik laad wat fixes in, maar voor de rest kijk ik er echt niet meer naar.

[ Voor 9% gewijzigd door Munki op 11-10-2013 10:39 ]

[Grijze Vos]

Good Fella schreef op vrijdag 11 oktober 2013 @ 09:38:
[...]

Ik ben wel benieuwd naar wat statistieken die dat bevestigen

Kan er best inkomen dat de door mij geschetste selector niet bepaald performance vriendelijk is, maar als dat verschil .00000021 seconden is dan hebben we het hier over een 'moo' point.

Dat soort selectors zinnig implementeren is het verschil tussen een website die vloeiend draait op je telefoon of niet. Wij hebben hier op het werk een designer die dat soort selectors schrijft, de nieuwe sites die 100% door webdevs geschreven zijn performen echt een factor 3x zo goed op mobile. Jouw ene inefficiente selector heeft weinig impact op je hele page load, maar als je hele site riddled is met dat soort selectors dan wordt het heel snel heel duur.

Zeker als je dingen als drag drop in je site gooit ga je het merken op langzame mobile hardware.

(Bovendien spaart het letterlijk accuduur van mobile devices, dus ook al zou je processor krachtig genoeg zijn om het te renderen, dan nog kun je op de wereldwijde energierekening besparen.)

[crisp]

Munki schreef op vrijdag 11 oktober 2013 @ 10:33:
[...]


Ik ben het hier dus totaal niet mee eens, als je je CSS moet resetten doe je het gewoon niet goed. (het 'normalizen' van je CSS buitengelaten.) Ook als je generieke resets gebruikt. Resets == extra onnodige regels.

Maar ook bij mobile-first zal je styles moeten resetten voor desktop zoals incaz al aangaf...

Als je uitgaat van een desktop-geoptimaliseerde website kan ik er min of meer mee inkomen dat je desktop-first wilt werken, maar uiteindelijk werk je jezelf alleen maar tegen, omdat, zoals ik eerder al aangaf, je CSS er echt niet kleiner op wordt en al helemaal niet overzichtelijker.

CSS overzichtelijk houden is sowieso een uitdaging Zeker als je zoals in ons geval met 'technical debt' zit op dat punt door veel legacy code. We hebben eigenlijk simpelweg geen andere keuze; een compleet andere insteek (mobile-first) zou gewoon minstens drie keer zo lang duren waarbij alle andere ontwikkelingen noodgedwongen uitgesteld zouden moeten worden. En zoals gezegd valt onze aanpak toch niet tegen; de clientside code voor het 'respsonsive maken' is toch behoorlijk overzichtelijk, compact en efficient

Daarnaast kun je bepaalde styles dus niet resetten. Jij bent dat misschien nog niet tegengekomen, maar ik weet zeker dat dit uiteindelijk toch aan de orde gaat komen.

Heb je een concreet voorbeeld? Ik kan toch zo snel niet iets bedenken waar we dan tegen aan zouden kunnen lopen...

[MoietyMe]

Grijze Vos schreef op vrijdag 11 oktober 2013 @ 10:45:
[...]

Dat soort selectors zinnig implementeren is het verschil tussen een website die vloeiend draait op je telefoon of niet. Wij hebben hier op het werk een designer die dat soort selectors schrijft, de nieuwe sites die 100% door webdevs geschreven zijn performen echt een factor 3x zo goed op mobile. Jouw ene inefficiente selector heeft weinig impact op je hele page load, maar als je hele site riddled is met dat soort selectors dan wordt het heel snel heel duur.

Lijkt me stug dat dat verschil puur en alleen door die selectors komt. Dat lijkt mij meer een optimalisatie aan JS, images e.d. kant.

Zeker als je dingen als drag drop in je site gooit ga je het merken op langzame mobile hardware.

Klinkt als JS.

(Bovendien spaart het letterlijk accuduur van mobile devices, dus ook al zou je processor krachtig genoeg zijn om het te renderen, dan nog kun je op de wereldwijde energierekening besparen.)

Dat zou heel goed kunnen, maar dan hebben we het al niet meer over snelheid. Verder een valide punt.

Overigens ben ik geen voorstander van dat soort selectors, laat dat duidelijk zijn. Ik betwijfel gewoon of de impact echt zo groot is als jij die doet voorkomen.

[Bosmonster]

incaz schreef op vrijdag 11 oktober 2013 @ 09:44:
[...]


Scheelt een IE8-fix

IE8 mobile first kan in principe zonder fixes (zoals respond.js).

HTML:

    <link rel="stylesheet" media="screen" href="global.css" />
    <link rel="stylesheet" media="(min-width: 720px)" href="720.css" />
    <link rel="stylesheet" media="(min-width: 960px)" href="960.css" />

    <!--[if lte IE 8]>
        <link rel="stylesheet" media="screen" href="720.css" />
        <link rel="stylesheet" media="screen" href="960.css" />
        <link rel="stylesheet" media="screen" href="ie8.css" />
    <![endif]-->

Je hoeft voor IE8 toch uiteindelijk alleen een desktopversie over te houden.

Daarnaast wil je extra CSS bij voorkeur sowieso in losse files houden, omdat je anders op mobile alsnog de complete CSS moet downloaden.

Media-attribuut wordt tegenwoordig vergeten, maar is soms helemaal zo gek nog niet.

Good Fella schreef op vrijdag 11 oktober 2013 @ 11:42:

Overigens ben ik geen voorstander van dat soort selectors, laat dat duidelijk zijn. Ik betwijfel gewoon of de impact echt zo groot is als jij die doet voorkomen.

Voor 1 selector? Inderdaad verwaarloosbaar. Maar bij een grote site kunnen dergelijke complexe selectors de boel flink vertragen, zeker op mobiel waar de processorkracht nu eenmaal een stuk minder is. CSS-parsing is daar een aanzienlijk deel van de verwerkingstijd van een grote pagina.

[ Voor 26% gewijzigd door Bosmonster op 11-10-2013 12:45 ]

[incaz]

Het serveren van een volledige extra stylesheet is niet overzichtelijker dan een reset voor je mobiele stylesheet hoor. Ik vind het spreiden van je mediaqueries over verschillende files trouwens vanuit dev-perspectief zeer onoverzichtelijk. Mijn methode is toch meer om samenhangende stijldelen bijelkaar te houden. Ik zou dus nooit de stijldefinities van de #sidebar in 3 verschillende bestanden willen hebben.
Uiteraard kun je wel scss gebruiken om dingen te splitsen en samenvoegen, al levert dat niet standaard een oplossing daarvoor, omdat samenvoegen bepaald makkelijker is dan splitsen.

Wat betreft het downloaden: dat is niet waar. Alle stylesheets worden gedownload, ongeacht de mediaqueries die erop staan.