Framsieutvikling

Eller: Hvor skal jeg putte media queriene mine?

Nesten alle nettlesere forstår media queries. Men det er fortsatt en hel del stakkars jævler der ute som bruker IE 8. Hvem skal tenke på dem når du strør inline media queries i css-filene?

Hva er galt med inline media queries?

Nei, altså, det fungerer greit hvis du bare bruker max-width.

En nettleser som ikke skjønner media queries ignorerer alt inne i en media query-blokk. Så hvis du starter med CSS for desktop, og serverer media queries som tilpasser for mobil, så har du noe som funker.

.grid-unit { float: left; }
@media screen and (max-width: 660px) {
    .grid-unit { float: none; }
}

Ulempene er:

• Det er hinsides klønete å fjerne CSS-regler fra elementer.
• Mobil-klienter har som oftest langt dårligere ytelse enn desktop, og det er de som ender opp med å måtte prosessere mest CSS.
• Totalt sett ender du opp med mer CSS, hvor en god porsjon er negering av tidligere regler.

Dette er noen tekniske grunner til å gå mobile first. Hvis du bruker min-width inline, så vil IE ignorere regler ment for desktop, og få en mobil-lignende versjon av siten spredt over et enormt kanvas. Alle som har besøkt en m.-side vet hvor bedrøvelig det er.

Hah, jeg bruker bare en polyfill!

Sier du det, du?

Rask levering av all CSS er særdeles viktig for opplevd ytelse. Fram til nettleseren har hentet all CSSen, så viser den bare en blank, hvit side. Dette for å unngå det fryktede flash of unstyled content.

Når du bruker en polyfill, så kaster du ytelse på båten:

• Først lastes all CSS ned av nettleseren.
• Så må JavaScript lastes ned. De som ikke har JS er som vanlig ekstra kjørt.
• JavaScriptet parses og kjøres.
• Så laster scriptet ned CSS-filene på nytt. Alle sammen.
• Deretter leser scriptet CSS-filene dine som strings, og parser dem for å skrive om.
• De genererte CSS-filene blir plassert inn i DOMen.
• Og omsider blir nettsiden din rendret.

Gitt tallene vi har på hvordan ytelse påvirker bunnlinja, vil jeg kalle bruken av en slik polyfill som grov tjenesteforsømmelse. Der fikk du den!

Ok, så plasserer vi media queries på link-taggen?

Joda, det er hakket bedre. Det funker i hvert fall med mobile first. Du kan bruke IE sine conditional comments til å servere den alle CSS-filene, mens andre nettlesere får se link-tagger med media queries på.

Ulempen er at du nå har en teknisk løsning som krever at brukerne må laste ned X individuelle CSS-filer, hvor X er antall breakpoints pluss én. Det begrenser din frihet til å lage en best mulig responsiv design, samtidig som det går ut over ytelsen fordi det blir flere requests for å laste ned all CSS.

Men, hvor kan man ellers ha media queries?

På @import …

Vent, vent, ikke skyt meg!

Du skal selvfølgelig ikke bruke CSS imports i produksjonskoden din. Det er hårreisende dårlig for ytelsen, av samme grunner som at du ikke bør bruke en polyfill. Men heng med et øyeblikk, så skal jeg forklare.

Her er en `responsive.css` fra et av mine prosjekter:

@import "reset.css";
@import "base.css";
@import "off-canvas-menu.css" screen and (max-width: 459px);
@import "460up.css" screen and (min-width: 460px);
@import "660up.css" screen and (min-width: 660px);
@import "730up.css" screen and (min-width: 730px);
@import "810up.css" screen and (min-width: 810px);
@import "960up.css" screen and (min-width: 960px);
@import "space.css";

Og her er en `unresponsive.css` fra samme prosjekt:

@import "reset.css";
@import "base.css";
@import "460up.css";
@import "660up.css";
@import "730up.css";
@import "810up.css";
@import "960up.css";
@import "space.css";

#main {width: 960px;}

Ved hjelp av conditional comments kan jeg nå servere responsive.css til de fleste browsere, og unresponsive.css til IE. Slik:

<!--[if (gt IE 8) | (IEMobile)]><!-->
  <link rel="stylesheet" href="responsive.css">
<!--<![endif]-->
<!--[if (lte IE 8) & (!IEMobile)]>
    <link rel="stylesheet" href="unresponsive.css">
<![endif]-->

Som du ser så er ikke lenger HTMLen min knyttet til hvor mange breakpoints eller CSS-filer jeg har. Men på grunn av @import blir det fortsatt lastet ned en haug med filer.

Det siste som mangler er noe du allerede antagelig gjør: Minifisering og konkatenering av CSS-filene. Byggeverktøyet drar da imports inn i filene.

Du ender opp med:

• én CSS-fil til nettlesere som skjønner media queries, med inline blocks.
• én CSS-fil til nettlesere som ikke skjønner filla, uten media queries, men med alle reglene for desktop.

Nydelig.

Hvordan gjør du responsiv? Syns du jeg overdriver ulempene med noen av de andre løsningene? Har du en bedre framgangsmåte? Hør fra deg i kommentarene. :-)

En kamerat og kollega som stort sett har holdt seg til baksia, fortalte meg at han ville å bli skikkelig god på framsia. Om jeg har noe lesestoff å anbefale? Å ja.

Disse bøkene er for meg essensielle for vordende framsieutviklere:

Test-Driven JavaScript Development

Tittelen til tross, denne boka er ikke bare om testdrevet utvikling. Det er en utmerket introduksjon til JavaScript. Du lærer hvordan språket fungerer, hvordan jobbe med DOM'en, hvordan du gjenbruker kode og skriver objekt orientert med JavaScript sin litt underlige prototypiske arv, funksjonell programmering, server-side scripting - og alt gjort testdrevet.

Denne boka gir deg muligheten til å styre unna masse utdaterte og dårlige råd som det florerer av på nett og i andre bøker.

Når du har lest boka, så vil du ha stor glede av dette foredraget: JavaScript design and architecture

High Performance Web Sites: Essential Knowledge for Front-End Engineers

Denne boka var for meg så spennende at når jeg stod på togperrongen og venta på toget i tre minutter, så dro jeg boka opp av sekken for å lese litt.

Den går gjennom hvorfor frontendytelse er viktig, og gir mange konkrete tiltak med forklaringer. Den spenner vidt, fra hvordan nettverk fungerer til hvordan nettlesere rendrer en side. Samtidig er boka ganske liten, så det går raskt å komme seg gjennom den.

Når du har lest boka, er det utrolig mye gull på denne julekalenderen: Performance Calendar.

Don’t Make Me Think: A Common Sense Approach to Web Usability

Selv om du er die hard teknisk frontend, så må du vite noe om usability. Dette er boka. Den er liten, lettlest, og tjokka full av gode eksempler. Den tar også livet av en del myter og “sunn fornuft” som det kan være lett å falle for.

Hva med CSS?

Innen CSS så har det meste gått ut på dato. Styr unna gamle klassikere som Bulletproof Web Design. De har bra ratings på Amazon, men proklamerer den formen for CSS som tar livet av oss.

I mangel på noe essensiell lesing, så er denne ganske okay: An introduction to object oriented css.

Til slutt

Har du noen helt essensielle bøker å foreslå? Ikke begynn å ramse opp en masse greier, bare plukk ut det aller beste. :-)

Responsive Design handler om at nettsia tilpasser seg størrelsen på skjermen. Det kommer som et svar på det voksende mylderet av enheter i varierende størrelser som besøker nettsidene våre.

De to hovedingrediensene er fleksible grids og media queries.

Fleksible grids

Legg opp layout med prosenter istedet for piksler.

En snubletråd her er W3C sin elendige boksmodell, hvor padding og borders legger seg utenpå bredden. Det er den som gjør at når du har tre stykk 33,33333% bokser ved siden av hverandre, så tar de opp mer enn 100% tilsammen og brekker layout.

Jeg ser mange som dermed prøver å regne seg fram til en prosentbredde på padding, marginer og borders for å få alt til å sitte. Ikke så rart, siden Andy Clarke anbefaler den teknikken. Det blir snåle prosenter med mange tall etter komma, og en layout som brekker for et godt ord. Klossete.

Et herlig enkelt triks

Lag dedikerte elementer til kun layout. De får aldri ha padding, margin eller borders - kun bredde og float. Dette lar deg fortsette å bruke pikselstørrelser på andre ting enn layout.

Jeg tar en mer detaljert titt på grids i OOCSS i en senere blogpost.

Media queries

Moderne browsere (IE9+) lar deg selektivt inkludere CSS basert på egenskaper ved nettleseren. Slik som dens bredde.

En naiv form for bruk av media queries er å ta desktopversjonen av CSS og så fjerne elementer for mobil. To store problemer med det:

• Du serverer mer CSS til mobiltelefoner enn desktop.
• Du ender opp med å prøve å resette CSS-regler tilbake til defaults.

De som har prøvd det siste vet at det er en ensidig klønete øvelse.

Snu på flisa

Istedet bør du starte fra bunn av med en mobiltilpasset design og layout, og øke på med flere CSS-regler oppover. Da er det desktop som laster ned mest CSS, mens mobil kun trenger hente ned det den trenger.

Et nydelig triks her er å utsette inklusjon av griden til et breakpoint sånn midt på (jeg har brukt 600px). Da får du enkelt til en collapse av layout på mobil uten noe ekstra arbeid.

Hva med IE<9 ?

Godt spørsmål. Ettersom vi serverer CSS for desktop i media queries, som IE<9 ignorerer, så må de få servert en egen unresponsive CSS som inkluderer alle reglene den mangler.

Det løses greit med IE-spesifikke HTML-kommentarer. Men det får konsekvenser for hva slags media queries som kan gjøres inline i CSS-filene:

• Regler som ikke skal gjelde på desktop kan inlines.
• Regler som skal på desktop må ut i egne CSS-filer så de kan serveres til IE uten media queries.

Det finnes javascript-hacks for å få IE til å skjønne inline media queries. Måten de er implementert er ved at de laster ned CSS-filene på nytt, og så parser gjennom filene for å finne reglene som skal gjelde.

Jeg er ikke villig til å utsette sluttbruker for dobbel nedlasting av CSS og en full javascript-parsing av all CSSen, når det er såpass enkelt å unngå.

Faen da Magnar, hvor er alle kodeeksemplene?

Hah, ja, det kommer i neste spennende episode: Ned til beinet på Responsive Design.

Fy søren så vondt det gjorde.

Jeg hadde satt min stolthet i å skrive slank HTML. Jeg kjente alle triksene i boka for å få nettlesere til å oppføre seg. Det var sliding doors, clearfix og zoom:1. Jeg leste A List Apart, SimpleBits og Bulletproof Web Design.

Men selv om HTMLen var ryddig og semantisk, så hadde CSS'en eksplodert. Jeg hørte Nicole Sullivan snakke om sin OOCSS, men det var jo galskap. For det første var navnet noe av det kleineste jeg hadde hørt. Og se på den HTMLen, noe så oppsvulmet og stygt! Det var i mot alt jeg hadde lært.

Så kom denne videoen:

Our Best Practices Are Killing Us

Det ga gjenklang. Kunne dette være løsningen på min økende CSS-smerte?

Nå er det over et år siden jeg innførte OOCSS på FINN oppdrag. Og jeg må innse at Nicole hadde rett. Dette er langt bedre.

Her er noen måter hverdagen min er bedre:

• Jeg lager en ny side. Uten å opprette noen css-fil.
• Jeg setter opp layout på siden uten å skrive noen floats eller clearfix. Den funker med en gang i IE6.
• Jeg fyller siden med ferdig definerte komponenter. Uten å skrive noen custom styles.
• Jeg flytter rundt på seksjoner av siden. Den ser lik ut, selv om den er i en annen kolonne.
• Jeg bestemmer meg for å endre layout. Innholdet flyter fortsatt riktig.
• Jeg endrer spacing og farger på 2-3 steder istedet for 2-3 hundre.

I tillegg ga OOCSS meg vesentlige fordeler når jeg samtidig gjorde sidene responsive. Mer om det senere.

Hvilke ulemper er det?

• Det er mer HTML å laste ned for sluttbruker.
• JavaScript som bygger HTML må vite om OOCSS.
• Navnet er fortsatt forferdelig kleint.

Jeg trodde også at HTMLen skulle bli uhåndterlig stor og vanskelig å navigere. Det har den ikke. I stedet er det lettere å finne fram, fordi det er så veldefinerte blokker.

Jeg trodde at jeg skulle fortsette å plages over den stygge HTMLen. Det viste seg å være en vanesak.

I etterkant har også Twitter Bootstrap blitt veldig populært, og med det har denne formen for CSS-arkitektur (om jeg tør bruke et sånt ord) fått sitt godkjentstempel. Bra.

Jeg tenkte å se litt på hva jeg har lært det siste året om OOCSS og Responsive Design i noen bloggposter. Heng på om du vil!

• Hvis bare utviklerne hadde vært med i salgsmøtene,
• Hvis bare utviklerne hadde estimert sakene bedre,
• Hvis bare utviklerne hadde planlagt sprinten nøye,
• Hvis bare utviklerne hadde blitt enige på forhånd,
• Hvis bare utviklerne hadde satt seg ned sammen med interaksjonsdesigneren,
• Hvis bare utviklerne hadde satt seg ned sammen med produkteieren,
• Hvis bare utviklerne hadde satt seg ned sammen med arkitekten,
• Hvis bare utviklerne hadde satt seg ned sammen med kunden,
• Hvis bare utviklerne hadde brukt mindre tid i møter,
• Hvis bare utviklerne hadde fått ting ferdig fortere,
• Hvis bare utviklerne hadde skrevet testene først,
• Hvis bare utviklerne hadde gjort en sak av gangen,
• Hvis bare utviklerne hadde brukt bedre verktøy,
• Hvis bare utviklerne hadde konsistent bruk av whitespace,
• Hvis bare utviklerne hadde startet med de største sakene,
• Hvis bare utviklerne hadde samme vokabular som kunden,
• Hvis bare utviklerne hadde kjørt koden gjennom statisk analyse,
• Hvis bare utviklerne hadde vært mer smidige,
• Hvis bare utviklerne hadde jobbet konsentrert,
• Hvis bare utviklerne hadde parprogrammert,
• Hvis bare utviklerne hadde brukt samme editor,
• Hvis bare utviklerne hadde startet med en velfundert arkitektur,
• Hvis bare utviklerne hadde skrevet integrasjonstester,
• Hvis bare utviklerne hadde ryddet opp i gammel kode,
• Hvis bare utviklerne hadde lagd færre bugs,
• Hvis bare utviklerne hadde sett alle konsekvenser av en endring,
• Hvis bare utviklerne hadde fulgt prosessen til punkt og prikke,
• Hvis bare utviklerne hadde skrevet utfyllende dokumentasjon,
• Hvis bare utviklerne hadde funnet gode navn på alle variable,
• Hvis bare utviklerne hadde samarbeidet på tvers av team,
• Hvis bare utviklerne hadde jobbet godt alene,
• Hvis bare utviklerne hadde brukt bunnsolide rammeverk,
• Hvis bare utviklerne hadde fulgt formateringsreglene,
• Hvis bare utviklerne hadde tatt en fot i bakken,
• Hvis bare utviklerne hadde fortalt hvor mange timer som gjenstod,
• Hvis bare utviklerne hadde brukt mindre tid på produksjonssaker,
• Hvis bare utviklerne hadde kjørt alle testene før hver commit,
• Hvis bare utviklerne hadde latt være å brekke bygget,
• Hvis bare utviklerne hadde sjekket i alle nettleserne,
• Hvis bare utviklerne hadde tatt høyde for framtidige endringer,
• Hvis bare utviklerne hadde vært litt flinkere,

så hadde alt vært … ok.

I dag snublet jeg i en felle som jeg merkelig nok ikke har ramlet i før. Jeg bruker Raphaël for å lage en visualisering av sidene i eventyr til spillet mitt, og hadde dette objektet:

var page = {
    size: 10,
    alternative_spacing_dx: 4,
    alternative_spacing_dy: 20,
    
    create: function (number) {
        var self = Object.create(this);
        self.number = number;
        return self;
    },

    // ...
}

Så jeg lagde en haug med sider med page.create(). Noen av sidene endret sin state.

Problemet oppstod når jeg fikk den gode idéen å endre alternativenes spacing til

alternative_spacing: {
    dx: 4,
    dy: 20
}

Jeg syns det var en fin refaktorering, men testene mine gikk fullstendig bananas. Du ser kanskje hvor det gikk galt?

Sidene mine som før hadde endret sin egen state med this.alternative_spacing_dx, endret nå state til et felles alternative_spacing-objekt. Jeg var nødt til å endre create-metoden til å inneholde:

self.alternative_spacing = Object.create(this.alternative_spacing);

Men det føltes litt kjipt. Jeg liker ikke at alle objektene jeg refererer må creates, og hva om de har objekter igjen, og de også? Huff. Har du en bedre måte?

Og ja, beklager tittelen, det kan se ut til at jeg har blitt ødelagt av VGs forsider opp gjennom årene.

Her er lyntalen jeg holdt på FINN.no sin techdag i går. Den går sikkert raskt ut på dato, så se den mens den er fersk. ^^

Og ja, det er den lille jenta mi som fant det for godt å våkne på slutten der.

Et par lenker fra lyntalen

• html5readiness.com
• FINN labs

TextMate har en haug med bra snippets og kommandoer ut av boksen, men det er også lekende lett å legge til egne.

I min screencast om TDD med javascript og sinon brukte jeg noen hjemmelagde snippets. Jeg legger dem ut her. Bruk dem om du vil!

TextMate sin bundle editor

Her ser du Bundle Editoren som du raskt åpner med ctrl+opt+cmd+b. En herlig shortcut!

1. Trykk på + nede i venstre hjørne, og lag en ny Bundle ved navn sinon.
2. Lag en ny Snippet. Tab Trigger: tc, Scope Selector: source.js. Lim inn:

TestCase("${1:${TM_FILENAME/(?:\A|_)([A-Za-z0-9]+)(?:\.js)?/(?2::\u$1)/g}}", sinon.testCase({
${2:	setUp: function (stub, mock) {
		$3
	\},

}	"test ${4:should ${5:do stuff}}": function (stub, mock) {
		$0
	}
}));

Regexp-helvetet på første linje drar ut filnavnet, og lager CamelCase av den. Deretter tabulerer du deg fra $1 til $2 til $3 .. og til slutt ender cursoren på $0.

Så er det bare å lukke Bundle Editoren og prøve.

Et par ekstra hendige snippets

Her er et par andre jeg bruker:

Ny test. Tab Trigger: tt, Scope Selector: source.js

"test ${4:should ${5:do stuff}}": function (stub, mock) {
	$0
}

Sett inn test-HTML. Tab Trigger: doc, Scope Selector: source.js

/*:DOC += 
	<div>
		$0
	</div>
*/

Kjør testene fra TextMate

Det er også en smal sak å lage en shortcut for å kjøre testene rett fra TextMate. Lag en ny Command:

• Save: Current file
• Input: None
• Output: Show as HTML
• Activation: Key Equivalent: cmd+R
• Scope Selector: source.js

Og kommando:

jstestdriver --tests all --html --reset --config "../jsTestDriver.conf"

Legg merke til at kommandoen kjøres relativt fra filen du har åpen.

En bra bok om emnet

Jeg kan anbefale TextMate: Power Editing for the Mac av James Edward Gray II. Der er det mange gode TextMate-triks å lære. Jeg kom meg ikke helt gjennom de siste kapitlene om Language Grammars, men hovedparten av boka om Editing og Automation er spennende og nyttig.

Jeg tør påstå at JavaScript er et av språkene som er mest utsatt for cargo culting. For noen år siden var det utstrakt klipping og liming, og uvanene spredte seg fortere enn du kunne si globalt navnerom.

Her er noen saker du må slutte med:

1. Du trenger ikke støtte Netscape 1

Jeg ser fortsatt script-tagger som denne:

<script type="text/javascript">
<!--

// -->
</script>

De utkommenteringene er der for at browsere uten kjennskap til script-taggen ikke skal skrive kildekoden vår rett inn i DOMen. Det kan du få lov å slutte med i år 2010.

2. Slutt å forsøple det globale navnerommet

Alle variable som ikke er deklarert i en funksjon deler samme navnerom, på tvers av alle scripts. Etter hvert som mengden javascript på en side øker, blir sjansen også stadig større for at dere begynner å tråkke i hverandres bedd.

Ta dette høyst sannsynlige eksempelet:

function debug(message) {
    if (window.console && console.log) {
        console.log(message);
    }
}

Her har jeg lagd en hendig liten metode for å slippe å brekke browsere når jeg glemmer å fjerne mine console.log() linjer før innsjekk.

Så kommer det en annen kar med et annet script:

var debug = true;

Og med det er ikke min debug-funksjon lengre noen funksjon, men en boolsk verdi. Velkommen til hodepinen!

Løsningen? Lag et navnerom rundt scriptet ditt med denne sildesalaten:

(function () {
    // din kode her
}());

Les mer på Christian sin blog.

3. Nei, blocks har ikke scope

Så slutt å skrive

function iterate_over(a) {
    for (var i = 0; i < a.length; i++) {
    }
}

Du forvirrer bare deg selv og andre. I JavaScript er det bare funksjoner som skaper nytt navnerom. Du bør etterstrebe å deklarere variablene i toppen av funksjonen:

function iterate_over(a) {
    var i, length = a.length;
    for (i = 0; i < length; i++) {
    }
}

4. Ikke bruk stor forbokstav på funksjoner

JavaScript er ikke et perfekt designet språk. Det er mange feller å falle i. Derfor er det viktig at du bruker JSLint.

En særdeles graverende feil forekommer hvis du skulle komme til å kalle en “constructor” uten new foran. Constructorer i JavaScript er bare funksjoner, så du får ingen feilmelding. I stedet blir this satt til det globale navnerommet, og så fyller du det opp med alt mulig rask uten å mene det - eller vite om det.

Derfor har godeste herr Crockford foreslått at vi bruker stor forbokstav på funksjoner som er ment som constructorer. Da kan JSLint si i fra hvis vi glemmer oss ut, og dermed unngår vi hele spetakkelet.

5. JavaScript har ikke klasser

Så la oss slutte å late som.

JavaScript har prototypisk arv i bunnen, med et tynt lag pseudo-klassisk arv på toppen som:

• har klønete syntaks
• har leaky abstractions
• ikke gjenspeiler språkets virkemåter og styrker

I stedet lager du et parent-objekt, og lar alle andre arve fra det med Object.create. Jeg er også glad i bruke jQuery.extend. Da ser det slik ut:

var feline = {
    legs: 4,
    claws: "sharp",
    speak: function () {
        print("roar!!");
    }
};

cat = jQuery.extend(Object.create(feline), {
    diet: ["mice", "birds"],
    speak: function () {
        print("purr...");
    }
});

garfield = jQuery.extend(Object.create(cat), {
    diet: ["lasagna"],
    owner: "Jon"
});

Dessverre er ikke Object.create implementert i alle browsere. Det løser du slik:

if (typeof Object.create !== 'function') {
    Object.create = function (o) {
        function F() {}
        F.prototype = o;
        return new F();
    };
}

Se også Christian sine kommentarer under for tilfeller der du heller bør definere create i ditt eget navnerom.

Har du noe på hjertet?

Hører gjerne fra deg i kommentarfeltet om du syns jeg er på viddene, bak mål, eller midt på blinken.

Testdrevet utvikling med JavaScript har hatt noen seriøse ulemper, men etter hvert som det har kommet stadig bedre verktøy, smaker det stadig flauere av unnskyldningene.

I dag skal vi raskt få opp et fullgodt utviklingsmiljø for testdrevet javascript:

• JsTestDriver kjører testene våre, og løser de to største problemene fra andre rammeverk; halvautomatiske tester eller simulerte nettlesere.
• jstdutil legger seg rundt JsTestDriver og tilbyr et hyggeligere grensesnitt og autotest.
• sinon gir oss et lettvekts rammeverk å skrive testene i, og gir presise og lettleste tester.

Obs! Videoen har begynt å vise sin alder. Den bruker Sinon.js 0.5.0. Det er bittelitt endring i forhold til versjonen nå (1.1.1).

Der testmetodene tidligere tok inn (stub, mock) så får man nå tilgang til disse metodene via this.stub() eller this.mock(). Dermed fungerer testen "test should do stuff" bedre om den begynner slik:

"test should do stuff": function() {
  this.stub(jQuery, "getJSON");

Lykke til med testingen!