← Ga naar ischagast.nl

***Flawless CSS

De weg naar vlekkeloze CSS met een team van 8 front-enders op dezelfde codebase.

Deze presentatie heb ik gegeven tijdens de Fronteers bijeenkomst bij Schiphol op 29 september 2016.

Video van presentatie

Transcript van presentatie

  1. 01: Beyonce looking flawless

    Vandaag zal ik jullie meenemen in mijn reis naar vlekkeloze CSS bij Schiphol.

    Tevens zal ik jullie wat tips geven en wat kleine tools laten zien zodat je CSS supersexy wordt en vooral beter onderhoudbaar.

  2. 02: The Fresh Prince of Bel-Air vraagt "Wie is die Gast?"

    Jullie zullen nu waarschijnlijk denken van Heyyyyyyyyyyyyy, wie is die Gast?

  3. 03: Illustratie stoere Gast door Cosh

    Mijn naam is Ischa Gast.

    Ik ben vooral gespecialiseerd in HTML, CSS en toegankelijkheid en vooral geen JavaScript. Dat laat ik over aan Tamara.

  4. 04: Jongeman komt juichend uit bordeel Amsterdam na verliezen maagdelijkheid

    Vandaag is het mijn ontmaagding wat betreft het geven van presentaties. Ik hoop wel straks net als deze guy gewoon zo hier de kamer uit te lopen, dat het allemaal helemaal top was.

  5. 05: Verschillende foto's van Lost Boys

    Ik ben front-end developer sinds 2000. Ik was ook bij de oprichting van deze mooie vakvereniging.

    De meeste jaren van mijn werkloopbaan heb ik gewerkt bij Lost Boys.

  6. 06: Website NS Spoordeelwinkel

    Daar heb ik vooral gewerkt aan heel veel grote sites zoals: De NS, Anne Frank, Ahold, ING en dat soort dingen.

  7. 07: Website Anne Frank
  8. 08: Foto vliegende Peter Pan

    Na bijna 10 jaar Lost Boys werd het voor mij tijd om weg te vliegen en ergens te landen bij Schiphol.

  9. 09: Foto Schiphol Airport

    Waarom Schiphol?

    Hier kreeg ik de kans om vooral alle leuke dingen te doen die ik op dat moment erg interessant vond.

    Styleguides, toegankelijkheid, progressive enhancement en hier ga ik gewoon iets meer de diepte in dan bij mijn oude bedrijf. Dat is eigenlijk precies wat ik wilde.

  10. 10: 2 Scrum teams

    Toen ik hier kwam hadden wij 2 scrum teams

  11. 11: 3 Scrum teams

    Op dit moment zijn het er 3.

  12. 12: 4 Front-end developers

    We hadden 4 front-end developers.

  13. 13: 8 Front-end developers

    Op dit moment zijn het er 8.

    Mijn taak was om het allemaal een beetje te stroomlijnen.

  14. 14: Animated gif van Ace Ventura die iets van heel dichtbij aan het bekijken is

    Het eerste wat ik heb gedaan toen ik hier kwam is heel goed alle code goed bekijken en aan de hand daarvan al mijn bevindingen op papier te zetten en een soort plan de campagne te maken hoe wij onze CSS goed gestructureerd gaan opzetten.

    Het eerste wat mij opviel was het volgende:

  15. 15: 4 Code styles

    Er waren 4 verschillende soorten code styles.

  16. 16: Voorbeeld code patternlab style

    Eén daarvan was De Patternlab style. Hier heb je mooie object, molecules en atoms. Het ziet er wel mooi uit. Maar de eerste keer dat ik de HTML bekeek dacht ik.

    Wow, wow, wat gebeurd hier? Wat is de a-, wat betekent die -m. Ik werd er geen wijs uit in ieder geval.

  17. 17: Voorbeeld code patternlab + BEM style

    Daarnaast hebben wij de Patternlab style gecombineerd met een soort van BEM. Waarbij wij dit soort hele mooie mooie, hele lange selectors krijgen. Soms wel meerdere op 1 regel.

    Ik dacht WoW WTF wat is dit? Dit wil ik niet!

  18. 18: Voorbeeld code BEM mixin style

    Daarnaast hadden wij een BEM mixin. Opzich een hele mooie mixin.

    Heb je @include en dan heb je een block. Dat block heet dan footer, dan heb je een element erin. Dat is dan zeg maar footer__disclaimer, footer__link, dat is dan uiteindelijk wat er dan uit komt.

    Wat ik heel vaak doe in de browser. Ik zoek wat op, dit element klopt niet helemaal. Ik zoek de classname. Ik ga dan kijken in mijn CSS. Doe gewoon ⌘F. Zoek de classname.

    Niets gevonden. Huh?

    Hoe kan het nou dat hij niets vindt?

    Dat kwam dus door deze mixin want dit is het enige wat je kan vinden. Dan zou je allemaal maar op het achterste gedeelte kunnen zoeken. Ik vond dat zelf heel erg irritant dus dit is iets wat wij niet hebben gehanteerd later.

  19. 19: Voorbeeld code nesting

    Daarnaast werd er heel veel gebruikt gemaakt van nesting.

    Nesting is best wel evil!

  20. 20: Inspector Gast denkt na

    Aan het einde van dat dacht ik Hmmmmm... hoe kunnen wij er nu voor zorgen dat die CSS iets meer gestructureerd wordt?

    Stap 1 is…

  21. 21: Coding guidelines

    Coding Guidelines

  22. 22: Keep It Simple Stupid

    Ik ben vooral van Keep It Simple Stupid!

  23. 23: Code moet leesbaar zijn, ook voor nieuwe medewerkers en freelancers

    Code moet leesbaar zijn, ook voor nieuwe medewerkers en freelancers.

    Stel ik heb de code geschreven, ik ga weg en er komt iemand nieuws. Hij snapt er geen bal van. Dan heb je uiteindelijk gewoon hele slechte code en dat wil je gewoon niet.

    Iedereen moet het kunnen lezen.

    Ik ben er daarom ook voorstander van om alles zo clean mogelijk te houden. Gewoon simpel CSS. Sass gebruiken wij ook eigenlijk alleen maar voor variabelen, soms een mixin en bijna geen functions. Geen rare dingen, gewoon plain CSS, niets meer dan dat?

  24. 24: Animated gif van ontploffing, BEM!

    Uiteindelijk zijn wij terecht gekomen bij BEM!

    Is BEM de shit?

    Het maakt niet uit wat je gebruikt als je er maar voor kiest om één ding te gebruiken en dus niet Patterlab en BEM maar gewoon één ding.

    Uiteindelijk hebben wij gekozen voor BEM.

  25. 25: Voorbeeld code BEM

    Maar dan wel op deze manier. Gewoon simpel, kleine componenten met een paar childs en niet zoals wat jullie net ook al zagen. Met dit soort ellenlange selectors.

  26. 26: Component based

    Alles is eigenlijk component based. Heb je een componentjes hier, dan moet het ook ergens anders op de site gewoon hergebruikt kunnen worden.

  27. 27: Zie je background, color en font op dezelfde hoogte staan als position, width, height en margin. Kijk UIT!

    Dus als je dingen gebruikt zoals position, width, height en margin wat op dezelfde regel staat als background, color en font dan moet je heel erg oppassen.

    Zeker met position bijvoorbeeld. Je hebt een componentje hier. Je stopt er ergens position top: -40px; Zou zomaar kunnen dat het er raar uitziet, gaat rare dingen doen en dat wil je gewoon niet.

  28. 28: Geen nesting. In de regel, als een selector werkt zonder dat het genest is dan niet nesten.

    Verder geen nesting.

    In de regel, als een selector werkt zonder dat het genest is dan gewoon niet nesten.

  29. 29: Voorbeeld code van gecompileerde CSS als je nesting gebruikt in SCSS

    In onze code wordt bijna niets genest. Want je wilt natuurlijk niet dit soort hele lange selectors in je gecompileerde CSS hebben. Dat wil je gewoon niet. Dat ziet er gewoon niet uit.

  30. 30: Voorbeeld code nesting met state classes

    Wat wij wel nesten zijn dit soort hele kleine dingen zoals state classes of wij nesten een beetje de :hovers, :focus, ::before en ::after maar dat is allemaal prima te doen. Dat kan allemaal geen kwaad.

  31. 31: Voorbeeld code nesting met hover en focus selector
  32. 32: Voorbeeld code parent selector

    Daarnaast gebruiken wij best wel veel parent selectors. Lijkt een beetje op nesten maar het is eigenlijk het omgekeerde. Zodat wij alles wat bij person__face hoort, dat houden wij ook gewoon bij person__face. Dat het niet allemaal door het hele document heen staat.

  33. 33: CSS opzet wat lijkt op ITCSS

    Onze CSS opzet is ook een beetje zoals dit.

    We hebben settings daar staan onze variabelen in. Onze color variabelen, onze spacing variabelen. Allemaal kleine soorten variabelen.

    Daarnaast heb je tools. Dat zijn mixins. Zijn er niet zo heel veel. Zijn er een paar voor bijvoorbeeld media queries gebruiken wij een mixin. Zijn echt hele kleine dingetjes.

    Daarnaast hebben wij generic. Dat is zeg maar de CSS reset.

    Dan heb je elementen. Dat zijn alle standaard HTML elementen zoals H1, H2. Die worden hier allemaal gestyled.

    Dan hebben wij een paar objecten. We gebruiken heel veel containers die bijvoorbeeld de breedte van je container bepalen. Daarin komen dan alle componenten. Dat zijn ongestylde dingen.

    Daarnaast hebben wij gewoon alle componenten. Naast componenten heb je nog componenten in componenten en dat zijn compositions.

    Dan heb je een mooi document en mooie coding guidelines maar dan ben je er natuurlijk nog niet. Want stel, ik heb de coding guidelines gemaakt. Iedereen moet zich er nog wel aan houden.

    Hoe ga je dat voor elkaar krijgen?

    Stel ik ga weg… Er komt een nieuw iemand zoals bijvoorbeeld Joey. We hebben coding guidelines maar niemand heeft hem dat verteld. Je vergeet gewoon op gegeven moment van. Hey je moet wel even dit lezen en niet je eigen code gaan schrijven. Dat vergeet je gewoon. Dat gebeurd geheid.

    Maar nadat wij dit allemaal hebben gedaan is onze code nu beter?

  34. 34: Oh jazeker!

    Oh Jazeker!

    De basis van de code is op dit moment gewoon goed.

  35. 35: Handige tools

    Maar hoe weet je nu echt of het goed is? Daar heb je een paar hele handige tools voor.

  36. 36: Voorbeeld code .editorconfig file

    Eén van die tools is de .editorconfig

    Daar kan je gewoon instellen wat je indent size is, of we gebruiken maken van tabs of spaces. Of er na de laatste regel nog een nieuwe lijn moet komen. Dit werkt in bijna alle IDE's. Daar heb je gewoon plugins voor en dat werkt gewoon super fijn.

  37. 37: Website CSS Stats

    Daarnaast heb je nog zoiets moois als CSS Stats.

    Hoe lager de waarde van je selectors hoe beter het is.

  38. 38: Website CSS Stats met specificity graph van beta.schiphol.com

    Hier zit heel veel eigenlijk rond de 30 of nog minder. Zitten een paar flaws in onze code en ik zal jullie zometeen wat van deze code laten zien. Maar opzich ziet het er qua onderhoudbaarheid goed uit.

    Hoe lager, hoe beter onderhoudbaar het is.

    Alleen nu ben ik benieuwd, wie van jullie het aandurft om zijn site door CSS Stats te halen.

    ING.nl

    Daar ga je hoor.

    Je ziet alle kleuren die gebruikt worden in de site. Het zijn er maar een paar. Ik denk iets van 50 tinten grijs. Alle font sizes. Even door scrollen. Unieke z-indexes. Dat zijn er ook best wel aardig wat. Maar hier komt het interessante.

    Nah… dit ziet er opzich nog wel redelijk goed uit. Geen hele grote gaten. Een paar, hier een kleintje. Dat hadden wij ook.

    Opzich, uiteindelijk qua onderhoudbaarheid is het best nog wel okay.

    Is er nog iemand die het aandurft om een site te noemen?

    tweakers.net

    Let op hé Wouter, daar ga je. Dat valt allemaal opzich nog wel mee

    Oooooooeeeeeh!

    Dit is een mooie grafiek! Ik denk dat ze hier nog wel wat aan kunnen doen als ik het zo zie.

    Je ziet, het is een hele mooie tool. Je kan er eigenlijk best wel veel mee. Het is vooral heel interessant om te kijken van waar zitten nu de flaws.

    Het enige nadeel is dat je hier dus niet ziet. Ik heb hier zo'n hele grote spike maar ik kan hier niet zien wat nu die spike veroorzaakt. Maar daar heb je dan wel weer een hele andere mooie handige tool voor.

  39. 39: Voorbeeld top selector specificity via Parker Stylesheet analysis tool

    Eigenlijk gebruikt CSS stats ook deze Parker Stylesheet Analyzer tool.

    Daar kan je bijvoorbeeld de CSS hier invoegen, je drukt op Enter, dan gaat hij kijken en dan zie je hier bijvoorbeeld. Bij ons is de meest zware selector

    .flight-info-dialogue__form #search-flight-by-date.active

    deze dat valt opzich nog best wel mee. En eigenlijk is het verder best wel cool. Het is best wel cool om dit eens te bekijken. Je kan er best wel veel dingen uit halen en ook veel verbeteren.

  40. 40: Voorbeeld complex selector via testmycss.com

    Naast deze tool heb je dus de Parker Stylesheet Analysis Tool. Bij ons is dit de langste selector.

    Dan heb je nog een andere tool, TestMyCSS.com.

    Dat is ook een hele leuke tool. Hier kan je bijvoorbeeld… Ik kan hem beter even laten zien. Daar kan je heel goed zien. Dan gooi je daar je CSS in en dan zie je hier dat hier onze meest complexe selector.

    Ik kan je vertellen. Ik heb hier bijvoorbeeld iets als nos.nl ingegooid. Dan schrik je je echt dood wat hieruit komt. Hele rare classes. Een hele lijst van zeker 50 selectors die heel erg complex waren.

    Ook dit is heel erg interessant om te bekijken om je CSS wat beter te maken.

  41. 41: Voorbeeld Hound melding github

    Daarnaast hoorden jullie Arjen al praten over Hound.

    Hound is eigenlijk een tool om je code te bewaken. Alle regels die in onze coding guidelines staan ook in een file voor Hound. Iedere keer als wij een push doen naar Github dan checked hij automatisch al je code.

    Dan krijg je dus dit soort dingen eruit. De properties moeten in de juiste volgorde staan. Wij gebruiken de alfabetische volgorde omdat iedereen dat snapt.

    Toen voor de eerste keer een CSS file door Hound werd gecontroleerd kreeg ik iets van 40 hound messages.

  42. 42: Foto blaffende hound

    WTF! Die hond die bleef maar blaffen!

    Hound messages oplossen en oplossen en nog steeds 20 hound messages. In het begin denk je echt van WTF dit wil ik helemaal niet, ik wil er weer vanaf. Ik ga het niet gebruiken. Maar na een tijdje als je een beetje bekend bent met wat je guidelines zijn dan…

    In het begin heb je misschien eerst 40, daarna heb je nog 5 messages over en aan het einde nog maar 1 per keer.

  43. 43: Animated gif John Cena in beast mode

    Uiteindelijk doe je gewoon beast mode aan je fixed alle messages. Uiteindelijk is de code die je daarna opleverd is gewoon super sexy.

    Soms laat je iemand anders naar je code kijken. Je vergeet dan soms gewoon wel eens dingen, je ziet dingen niet. Hound fixed deze dingen gewoon voor je. Helemaal top!

  44. 44: Communicatie

    Daarnaast is communicatie gewoon heel erg belangrijk

  45. 45: Vraag om feedback!

    Vraag om feedback!

    Dan doen wij ook allemaal hier bij Schiphol. Onze PR's assign je aan iemand anders uit een ander team wellicht. Gewoon een andere front-end developer, maakt niet uit wie het is. Als er maar iemand naar je code kijkt.

    Daar komen dan soms discussies van of hij zegt "Dit kan je beter zo doen". Dan gaan we gewoon met elkaar praten van hoe zou jij dit doen? Is dit beter? Uiteindelijk hebben wij gewoon mooie code.

  46. 46: Gebruik giphy & emoji’s 🍆

    Daarnaast is het gewoon heel erg belangrijk om giphy & emoji's 🍆 te gebruiken.

  47. 47: Voorbeeld gebruik van gif bij github pull request

    Soms willen mensen nog wel eens wat dingen mergen. Dan drukken ze op de knop merge now. Delete branch. Nee, dit wil ik niet. Ik was er nog mee bezig.

    Staat een label op "Work in progress"

    Sommige mensen vergeten dat nog wel eens. Dan kan je een mooi giphy erbij doen. Nee, niet mergen. Dan is het gelijk duidelijk.

  48. 48: Foto wonderwoman trekkend aan hendel

    Daarnaast gebruiken wij giphy gewoon om elkaar PR's te sturen.

    Er staat nog een PR voor je open. Check hem even.

  49. 49: Voorbeeld emoji gebruik commit messages

    Mooie emoji's in je commit messages.

    Hier heb ik een klein dingetje qua CSS gefixed. Een klein beetje 💄lipstick erop. Een nieuw ding toegevoegd. Een beetje ✨sparkles erbij. Hier heb je die irritante 🐩Hound weer. Hebben wij alle issues weer gefixed. En uiteindelijk hopen wij dan gewoon mooie nette code te hebben.

  50. 50: Animated gif van Tracy Morgan die heel hard nee schudt

    En is onze code flawless?

    Nee, zeker niet.

    Onze code is zeker nog niet flawless. Maar uiteindelijk komen wij wel ergens. De basis van flawless code die staat er. Daar kunnen wij makkelijk goed op voortborduren.

  51. 51: Foto van meneer die aangeeft dat hij klaar is

    Dit was mijn talk. Zijn er nog vragen?

  52. 52: Foto van Beyonce die iedereen dankt voor haar aanwezigheid

    Okay, dat was hem dan.