o o se æss æss e ælsk!!!!
1 inn’troduksjon te o o se æss æss fra jængen i Finnj
Bilde fra: https://www.nordicchoicehotels.no/kampanjer-og-tilbud/hotell_trondheim/
Meg – Espen Dalløkken
•  Utviklet ting for web
siden ’98
•  Jobber i FINN.no
•  Organiserer Web
Rebels
Spilleliste
•  Object Oriented CSS
–  Prinsipper, historie
•  Fra tresløyd til Lego
–  Awesomeboard, Feedback, www, m, pipeline
•  Responsive Web Design og mobile enheter
Object Oriented CSS
•  Skrevet av Nicole Sulivan ca i 2009 mens hun
jobbet i Yahoo!
•  Freelance konsulent og arrangør av CSS Conf
US/EU
•  Formålet var å gjøre utvikling med CSS:
–  Stabilt
–  Modularisert
–  Forutsigbart
http://www.stubbornella.org/
http://www.slideshare.net/stubbornella/object-oriented-css
Problemer med CSS i 2009 (og i 2013)
•  Størrelsene på filene blir bare større jo lengre en
løsning lever
•  Gjenbruk finnes nesten ikke
•  CSS koden er altfor skjør og knekker altfor ofte
•  Best-practices hindrer oss faktisk i å lage
robuste løsninger med bra ytelse
Nøkkelprinsipper i OOCSS
•  Skille struktur og utseende/skins
–  Bakgrunner og borders i egne skins
–  Klassenavn for å navgi objekter fremfor HTML
semantikk
•  Skille container og innhold
–  Et objekt skal se likt ut uansett hvor du legger det inn
•  Alt skal være åpent utvidelse
Gridsystem er fundamentet for OOCSS
Fra tresløyd til Lego
Eller historien om hvordan et helt
selskap plutselig snakket om strap-on i
enhver sammenheng uten blygsel..
Hvorfor begynte FINN å se på OOCSS?
•  En CSS kodebase fullstendig ute av kontroll som
gjorde oss ute av stand til å gjøre endringer på
tvers
•  En kodebase på front-end uten særlig fokus på
ytelse
•  Ingen effekt av å ha et av Norges største miljø
for framsieutvikling
•  @magnars startet å bruke det på /oppdrag
CSS kodelukten var plagsom
•  Utviklere lager sine egne ”øyer” for å holde
kontroll
•  En utvikling mot stadig mer spesifikke regler
•  !important kriger
•  Løser samme feil gjentatte ganger pga
duplisering
Strap-on prosjektet
•  Vi laget en basis pakke basert på OOCSS
•  Deretter skrev vi om del for del alt av HTML på
hele FINN
•  Dette tok litt over 1 ½ år
•  I det vi var ferdig, redesignet 3 stk hele FINN på
ca 3 uker
Hjernene bak /strapon
En kjørende styleguide - /strapon
Hva måtte vi lage selv?
•  OOCSS er en basispakke hvor vi bruker noe,
men ikke alt
•  Forms oppsett rappet vi fra Bootstrap, men har
nå skrevet det helt om
•  Kommer ikke med noe ferdig widget bibliotek
–  tooltips, dialoger, tabs, etc måtte vi lage
•  Responsive Web Design er ikke en del av
basispakken
•  Bells’n whistles måtte vi lage selv
Take aways fra å utvide OOCSS
•  Å ta inn ting som ikke er OOCSS virker lurt når
du gjør det, men du vil slite med det senere
•  Basisen kan veldig enkelt utvides
•  Du kan enkelt bygge det som måtte mangle
Økt rendering hastighet
Tallenes klare tale
Før 1. iterasjon Mars 2013 Nå
# CSS files 130 38 56 57
# Lines of
Code
32 798 2 927 6 187 5 226
# Font-size
declarations
1 623 45 57 69
Strap-on i fri dressur
Hva skjedde med rammeverket etter vi var ferdig med v1.0?
Fortsetter å levere
•  Nye tjenester kommer raskt opp med riktig
utseende (finn.no/smajobber)
•  Interne verktøy bruker oftere vårt rammeverk
over Bootstrap (yay!)
•  Utviklere med ingen kunnskap om CSS kan
jobbe uten å ødelegge noe
•  Vi utvider rammeverket med forms-oppsett og
mer responsive tilpassninger
Strap-on – one stop shop for CSS
•  Ligger i bunnen på alle løsninger vi lager
•  Nye tjenester kan lages uten å skrive ny CSS
•  To utviklere har skrev og nå vedlikeholder og
videreutvikler kjernen
–  Resten jobber med nye ting eller spesialtilpassninger
som kun brukes ett sted og bidrar med innspill og
forbedringer
CSS rammeverk smack down
Bootstrap
•  Kan brukes out of the box
•  Utstrakt widget bibliotek
•  Lite performance fokus
•  Lite mobilvennlig
•  Støtte for LESS/SASS/etc
OOCSS
•  Rammeverk som vil kreve
egen tilpasning
•  Pure CSS, ikke noe
JavaScript
•  Skrevet for performance
•  Kompatibelt tilbake til IE5
(vistnok)
Responsive Web Design og OOCSS
•  RWD ”fantes ikke” da OOCSS ble unfanget
•  Prinsippene fra OOCSS passer ikke helt med
ideen om responsive web sites
•  Finnes ingen boilerplate på hvordan gjøre det
Vi har prøvd og feilet
•  Første versjon baserte seg på å tilpasse
rammeverksklasser (opt-out)
•  Andre versjon hadde noen egne responsive
klasser
•  Tredje versjon har egne objekter som gir
responsive oppførsel (opt-in)
•  The Neverending Grid
Icon-fonts
•  Tidligere hadde vi sprites for alt av små grafikk
elementer og ikoner
•  Bilde sprites blir mye arbeid å vedlikehold med
ulike oppløsninger, størrelser, enheter og
plattformer (web/native)
•  Icon-fonts er:
–  Skalerbare
–  Cachet
Icon-font gotchas
•  IE krever eget oppsett av content-types på
serveren
•  Levetiden til nettlesercache for fontene er difus
•  Blinde brukere ser kun bokstavene du bruker
•  Du må ha fallbacks for eldre IE nettlesere
Ok, en kort recap
•  OOCSS krever litt arbeid
•  Leverer varene på ytelse, robusthet, fleksibilitet
og gjenbrukbarhet
•  Gjør store kodebaser håndterlige og hindrer at
den kommer ut av kontroll
•  Krever disiplin og vedlikehold

OOCSS e ælsk

  • 1.
    o o seæss æss e ælsk!!!! 1 inn’troduksjon te o o se æss æss fra jængen i Finnj Bilde fra: https://www.nordicchoicehotels.no/kampanjer-og-tilbud/hotell_trondheim/
  • 2.
    Meg – EspenDalløkken •  Utviklet ting for web siden ’98 •  Jobber i FINN.no •  Organiserer Web Rebels
  • 3.
    Spilleliste •  Object OrientedCSS –  Prinsipper, historie •  Fra tresløyd til Lego –  Awesomeboard, Feedback, www, m, pipeline •  Responsive Web Design og mobile enheter
  • 4.
    Object Oriented CSS • Skrevet av Nicole Sulivan ca i 2009 mens hun jobbet i Yahoo! •  Freelance konsulent og arrangør av CSS Conf US/EU •  Formålet var å gjøre utvikling med CSS: –  Stabilt –  Modularisert –  Forutsigbart http://www.stubbornella.org/
  • 5.
  • 6.
    Problemer med CSSi 2009 (og i 2013) •  Størrelsene på filene blir bare større jo lengre en løsning lever •  Gjenbruk finnes nesten ikke •  CSS koden er altfor skjør og knekker altfor ofte •  Best-practices hindrer oss faktisk i å lage robuste løsninger med bra ytelse
  • 7.
    Nøkkelprinsipper i OOCSS • Skille struktur og utseende/skins –  Bakgrunner og borders i egne skins –  Klassenavn for å navgi objekter fremfor HTML semantikk •  Skille container og innhold –  Et objekt skal se likt ut uansett hvor du legger det inn •  Alt skal være åpent utvidelse
  • 9.
  • 10.
    Fra tresløyd tilLego Eller historien om hvordan et helt selskap plutselig snakket om strap-on i enhver sammenheng uten blygsel..
  • 11.
    Hvorfor begynte FINNå se på OOCSS? •  En CSS kodebase fullstendig ute av kontroll som gjorde oss ute av stand til å gjøre endringer på tvers •  En kodebase på front-end uten særlig fokus på ytelse •  Ingen effekt av å ha et av Norges største miljø for framsieutvikling •  @magnars startet å bruke det på /oppdrag
  • 12.
    CSS kodelukten varplagsom •  Utviklere lager sine egne ”øyer” for å holde kontroll •  En utvikling mot stadig mer spesifikke regler •  !important kriger •  Løser samme feil gjentatte ganger pga duplisering
  • 13.
    Strap-on prosjektet •  Vilaget en basis pakke basert på OOCSS •  Deretter skrev vi om del for del alt av HTML på hele FINN •  Dette tok litt over 1 ½ år •  I det vi var ferdig, redesignet 3 stk hele FINN på ca 3 uker
  • 15.
  • 16.
  • 17.
    Hva måtte vilage selv? •  OOCSS er en basispakke hvor vi bruker noe, men ikke alt •  Forms oppsett rappet vi fra Bootstrap, men har nå skrevet det helt om •  Kommer ikke med noe ferdig widget bibliotek –  tooltips, dialoger, tabs, etc måtte vi lage •  Responsive Web Design er ikke en del av basispakken •  Bells’n whistles måtte vi lage selv
  • 18.
    Take aways fraå utvide OOCSS •  Å ta inn ting som ikke er OOCSS virker lurt når du gjør det, men du vil slite med det senere •  Basisen kan veldig enkelt utvides •  Du kan enkelt bygge det som måtte mangle
  • 19.
  • 20.
    Tallenes klare tale Før1. iterasjon Mars 2013 Nå # CSS files 130 38 56 57 # Lines of Code 32 798 2 927 6 187 5 226 # Font-size declarations 1 623 45 57 69
  • 21.
    Strap-on i fridressur Hva skjedde med rammeverket etter vi var ferdig med v1.0?
  • 22.
    Fortsetter å levere • Nye tjenester kommer raskt opp med riktig utseende (finn.no/smajobber) •  Interne verktøy bruker oftere vårt rammeverk over Bootstrap (yay!) •  Utviklere med ingen kunnskap om CSS kan jobbe uten å ødelegge noe •  Vi utvider rammeverket med forms-oppsett og mer responsive tilpassninger
  • 23.
    Strap-on – onestop shop for CSS •  Ligger i bunnen på alle løsninger vi lager •  Nye tjenester kan lages uten å skrive ny CSS •  To utviklere har skrev og nå vedlikeholder og videreutvikler kjernen –  Resten jobber med nye ting eller spesialtilpassninger som kun brukes ett sted og bidrar med innspill og forbedringer
  • 27.
    CSS rammeverk smackdown Bootstrap •  Kan brukes out of the box •  Utstrakt widget bibliotek •  Lite performance fokus •  Lite mobilvennlig •  Støtte for LESS/SASS/etc OOCSS •  Rammeverk som vil kreve egen tilpasning •  Pure CSS, ikke noe JavaScript •  Skrevet for performance •  Kompatibelt tilbake til IE5 (vistnok)
  • 29.
    Responsive Web Designog OOCSS •  RWD ”fantes ikke” da OOCSS ble unfanget •  Prinsippene fra OOCSS passer ikke helt med ideen om responsive web sites •  Finnes ingen boilerplate på hvordan gjøre det
  • 30.
    Vi har prøvdog feilet •  Første versjon baserte seg på å tilpasse rammeverksklasser (opt-out) •  Andre versjon hadde noen egne responsive klasser •  Tredje versjon har egne objekter som gir responsive oppførsel (opt-in) •  The Neverending Grid
  • 31.
    Icon-fonts •  Tidligere haddevi sprites for alt av små grafikk elementer og ikoner •  Bilde sprites blir mye arbeid å vedlikehold med ulike oppløsninger, størrelser, enheter og plattformer (web/native) •  Icon-fonts er: –  Skalerbare –  Cachet
  • 32.
    Icon-font gotchas •  IEkrever eget oppsett av content-types på serveren •  Levetiden til nettlesercache for fontene er difus •  Blinde brukere ser kun bokstavene du bruker •  Du må ha fallbacks for eldre IE nettlesere
  • 33.
    Ok, en kortrecap •  OOCSS krever litt arbeid •  Leverer varene på ytelse, robusthet, fleksibilitet og gjenbrukbarhet •  Gjør store kodebaser håndterlige og hindrer at den kommer ut av kontroll •  Krever disiplin og vedlikehold