Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Future Proof CSS
Search
Vitor Mendrone
June 21, 2018
Programming
1
99
Future Proof CSS
Vitor Mendrone
June 21, 2018
Tweet
Share
More Decks by Vitor Mendrone
See All by Vitor Mendrone
Como se tornar indispensável em um mercado em crise?
mendrone
0
75
Expressões Regulares
mendrone
0
32
A arte da composição
mendrone
0
22
Como escolher uma stack para meu projeto?
mendrone
0
22
Future Proof CSS - 2019
mendrone
0
72
Vue.js - O Antes, o Durante e o Depois
mendrone
0
100
High Speed Workflow
mendrone
4
140
Usabilidade - O bom senso é o seu melhor amigo
mendrone
0
80
Um Simples Checkup Pode Salvar a Sua Loja Virtual
mendrone
0
58
Other Decks in Programming
See All in Programming
レイトレZ世代に捧ぐ、今からレイトレを始めるための小径
ichi_raven
0
350
Java_プロセスのメモリ監視の落とし穴_NMT_で見抜けない_glibc_キャッシュ問題_.pdf
ntt_dsol_java
0
200
JJUG CCC 2025 Fall: Virtual Thread Deep Dive
ternbusty
3
430
自動テストを活かすためのテスト分析・テスト設計の進め方/JaSST25 Shikoku
goyoki
3
680
組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する #phpconfuk
o0h
PRO
10
4.4k
r2-image-worker
yusukebe
1
170
自動テストのアーキテクチャとその理由ー大規模ゲーム開発の場合ー
segadevtech
2
1k
AI駆動開発ライフサイクル(AI-DLC)のホワイトペーパーを解説
swxhariu5
0
1k
MCPサーバー「モディフィウス」で変更容易性の向上をスケールする / modifius
minodriven
8
1.5k
「10分以内に機能を消せる状態」 の実現のためにやっていること
togishima
1
450
OSS開発者の憂鬱
yusukebe
12
4.3k
しっかり学ぶ java.lang.*
nagise
1
370
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
135
9.6k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Documentation Writing (for coders)
carmenintech
76
5.1k
Balancing Empowerment & Direction
lara
5
750
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
Agile that works and the tools we love
rasmusluckow
331
21k
Building Adaptive Systems
keathley
44
2.8k
BBQ
matthewcrist
89
9.9k
Six Lessons from altMBA
skipperchong
29
4.1k
Speed Design
sergeychernyshev
32
1.2k
Why Our Code Smells
bkeepers
PRO
340
57k
Transcript
Future Proof CSS Criando folhas de estilo resistentes ao tempo
// Vitor Mendrone // Senior Front-end Engineer
None
CSS já me f*%# pra car&*#$! Provável ferramenta utilizada na
criação do CSS
O sofrimento é um grande professor. E me ensinou algumas
lições.
1º - Aprenda com os designers de UX Planejamento é
tudo.
Seu trabalho precisa gerar valor mesmo quando você não está
codando.
Invista tempo analisando página a página do layout. Não escreva
uma linha de código sem antes planejar minuciosamente como implementá-lo.
2º - Seu CSS deve ser sempre 'HTML Agnostic' Evite
ao máximo utilizar seletores de tags (type selectors) em suas folhas de estilo.
Place your code snippet here Remember: that a presentation, be
careful with big chunks of code
Place your code snippet here Remember: that a presentation, be
careful with big chunks of code
3º - Não tenha medo de inserir novos elementos HTML
Não é errado incluir novos elementos desde que sirvam para criar componentes mais robustos
Place your code snippet here Remember: that a presentation, be
careful with big chunks of code
4º - Utilize sempre o mínimo seletor viável. Se possível,
substitua seletores aninhados por novas classes
5º - Evite adicionar mais CSS para resolver bugs Se
necessário dê um passo atrás e tenha certeza de que o bug só pode ser resolvido com mais CSS
Use e abuse das devtools do seu browser Chrome Devtools
Windows (F12) - Mac (cmd + opt + i)
6º - Eu escreveria isso a mão?
7º - Use um normalizador de CSS O normalize.css é
seu amigo e continuará sendo por muito tempo.
O normalize garante consistência em situações onde o reset não
atua.
http://necolas.github.io/normalize.css/
8º - box-sizing: border-box; Box-sizing: border-box; só não é default
por um erro do CSSWG
Box-sizing padrão considera que o width trata o tamanho do
conteúdo Dessa forma ele ignora padding e border no tamanho final
Regra não escrita do front-end: Siga o @sergio_caelum http://sergiolopes.org/css-box-sizing-border-box/
9º - Nunca use !important E nunca diga nunca!
None
9.1 - Para resolver rapidamente bugs de produção E apenas
pelo tempo necessário para investigar e codar a solução definitiva.
9.2 - Para testes rápidos Apenas durante o desenvolvimento, quando
ignorar a cascata for o caminho mais curto para o teste.
9.3 - Para garantir imutabilidade. Quando for necessário garantir que
um elemento não pode ser alterado pelo usuário.
Código escalável é negócio escalável E essas lições que aprendi
me ajudaram a garantir que sou capaz de criar produtos que escalem minha carreira.
Não são regras escritas em pedra. Seja adaptável, respeite seu
tempo e nunca deixe de aprender.
Obrigado! Github: @mendrone Twitter: @vhmendrone Telegram: @vhmendrone