Slide 1

Slide 1 text

I heard that you want to Improve your CSS @GiuseppeGurgone

Slide 2

Slide 2 text

Structure Docs & Tests Future A Styling Methodology Isolation & Composition

Slide 3

Slide 3 text

Structure

Slide 4

Slide 4 text

Structure Sparse Code organized by Technology assets/css/forms.css assets/js/checkbox.js view/partials.html tests/??? docs??? => http://wiki/docs/forms#checkbox > fidn . -name checkbox* > sudo pip install thefuck

Slide 5

Slide 5 text

it gets tricky...

Slide 6

Slide 6 text

Structure :) Self Contained Components components/Checkbox/index.css components/Checkbox/index.js components/Checkbox/index.html components/Checkbox/test/ components/Checkbox/doc/index.md components/Checkbox/doc/css.md components/Checkbox/doc/js.md components/Checkbox/doc/html.md

Slide 7

Slide 7 text

Structure Application base/ components/ pages/ utilities/ theme/ components/ pages/ utilities/

Slide 8

Slide 8 text

Docs & Tests build simple and solid solutions

Slide 9

Slide 9 text

that we can use on our worst days... * The joke is (c) Alex Sexton

Slide 10

Slide 10 text

Docs Reference for everybody Comprehensive, document every UI State Built in code examples One component at a time Generated Metalsmith.io, Jekyll

Slide 11

Slide 11 text

Tests Enforce Structure, Docs, Conventions and other common practices [‘css’, ’js’, ’html’] .forEach(ext => assertFileExists(‘doc/’+ext+’.md’)) Image diffing on UI Components (state) All [CSS,] JavaScript, Partial tested

Slide 12

Slide 12 text

(c) stripe

Slide 13

Slide 13 text

Structure Organize by Components not Technology Docs Document every Component and Utility Tests Enforce documentation and best practices

Slide 14

Slide 14 text

Future Proof

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Preprocessors are awesome buttt… Non standard APIs Often overused, easily abused: That “With power comes great responsibility” thing Nesting #nav > li > .wrapper a:hover:before, #nav > li > .wrapper a:focus:before { … } #sidebar div.widget h2.title a span { … } ...

Slide 17

Slide 17 text

preprocessors? where we’re going, we don’t need preprocessors

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

PostCSS A tool for transforming styles with JS plugins. These plugins can support variables and mixins, transpile future CSS syntax, inline images, and more. :root { --Button-color: hotpink; } .Button { color: var(--Button-color); } postcss(customProperties()).process(css).css .Button { color: hotpink; }

Slide 21

Slide 21 text

PostCSS http://github.com/postcss/postcss Plugins Autoprefixer postcss-import postcss-custom-properties postcss-calc postcss-custom-media moar @ http://postcss.parts

Slide 22

Slide 22 text

SUIT CSS is a reliable and testable styling methodology for component-based UI development developed by Nicolas Gallagher. suitcss.github.io

Slide 23

Slide 23 text

SUIT CSS Naming Convention, Scoped Styles The SUIT CSS naming convention helps to scope component CSS and make your widgets render more predictably. .MyComponent {} .MyComponent.is-animating {} .MyComponent--modifier {} .MyComponent-part {} .MyComponent-anotherPart {}

Slide 24

Slide 24 text

SUIT CSS vs BEM SUIT CSS is a flavor of BEM "Standard BEM" is also a poor choice for migrations, because .menu is going to collide with the legacy .menu code that has no isolated structure to it. Whereas the name .Menu won't, and it maps more obviously with associated JS functions and View code. PascalCase plays nice with React and JS components.

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

Isolation & Composition

Slide 28

Slide 28 text

Global Styles Hard to know in advance the context where our UI Components are going to be used. The effect of Global Styles is unpredictable Gotcha in the JavaScript world No Global typography, etc.

Slide 29

Slide 29 text

One pattern, one Component Each component should implement a single part of the UI. Don't try to do too much. Each component should have a dedicated CSS file. Ideally your component's files are grouped together in a dedicated directory.

Slide 30

Slide 30 text

One Element, one Component There should be a one-to-one replationship between HTML and CSS. .Review { color: #b4d455; }

uh-may-zing

Slide 31

Slide 31 text

Adapting to ancestral context Most components should not set their own width, margin, and positioning. By authoring a component to be full-width or inline, it can better adapt to the dimensions of an ancestral context.

Slide 32

Slide 32 text

Nesting Components Wrapping Elements
hey

Slide 33

Slide 33 text

Nesting Components Many options! http://simurai.com/blog/2015/05/11/nesting-components

Slide 34

Slide 34 text

Copy/Paste Senõr Frontend Eng Styleguides are cool, Bootstrap is cool (?) Reusable CSS alone is not enough Build reusable UI Components: Templates, Partials, Presenter Pattern

Slide 35

Slide 35 text

Future Proof :) Transpile, use Standards SUIT CSS :) Reliable Styling methodology Isolation & Composition :) Avoid dependencies & Global, Compose instead

Slide 36

Slide 36 text

No content