- Preprocessor;
- Task runner;
- Scaffolding;
- Code style;
- Pendências da documentação
Sass!!!
Resposta curta: é mais completo que o LESS.
Gulp!!!
Resposta curta: o ionic usa ele já :D
/app
|- ...
|- /assets
|- images
|- fonts
|- scss (não vai haver outro preprocessador, então não tem porque ter uma pasta “style”)
|- app.scss
|- base.scss
|- fonts.scss
|- icons.scss
|- variables.scss
Onde haverá os includes dos arquivos .scss, declaração de paths e outras configurações sobre estilo.
Estilos para resets, normalizações ou estilos básicos/default para elementos HTML como UL, LI, IMG, tamanho de fonte, cor de fonte… ficam aqui ;)
Aqui nós importamos as fontes que a nossa app vai usar e criação de classes comuns a APP para modificação de texto. Exemplo:
#classe de uso geral para app
.text-strong {
font-family: ‘Font Strongão’;
}
Se os ícones são fontes ou imagens, aqui que nós trabalharemos com a importação em forma de classes, dando manutenção a cada pacote de ícones que mandem para nós o/
Gostaria de ter essa skill de saber só de olhar que #DB2955 é um vermelho que #B98389. Mas vou treinar. Enquanto isso vamos agradecer ao século 21 e usar variáveis ao nosso favor. E é nesse arquivo que podemos definir nossa paleta de cor, espaçamento, tamanho de fonte, viiix… o céu é o limite.
Como vamos usar módulos para dividir os negócios, cada um terá o seu .scss dentro da pasta do seu módulo (melhor documentado no scaffolding de módulos)
- User hífen para módulos e underscore para nomes compostos;
- Tentar não usar !important;
- Tentar não usar #id;
- Usar sempre as variáveis do SASS;
- Cuidado ao mexer no estilo alheio;
- Tentar usar o SASS ao seu favor com mixins, %
.nave {
width: 200px;
}
.nave-marciana {
}
.nave-inter_estelar {
color: azul;
}
Como regra, vamos evitar a “Profundidade de Aplicabilidade” (depth of applicability) dos nossos seletores. O que isso significa? Significa ter um código CSS gerado assim:
#sidebar div {
border: 1px solid #333;
}
#sidebar div h3 {
margin-top: 5px;
}
#sidebar div ul {
margin-bottom: 5px;
}
Trecho de: Jonathan Snook. “Scalable and Modular Architecture for CSS.” iBooks.
“NOSSA, que sunita! O CSS é assim justamente assim porque ele tem CASCADING no nome, então deixa o estilo escorrer pelos filhos. E outra: o SCSS ajuda a criar estilos aninhados (nested)”.
Se usarmos o SCSS e o CSS do jeito que foi mostrado, estamos criando: #1 Dependencia do estilo com a estrutura HTML (se um dia o div no meio da regra css virar um span, você perdeu aquela regra); #2 A profundidade do regra tá muito longa. Exemplo: pense que você tem uma classe com profundidade deep web
#header > div > ul > li > p > span {
color: red;
}
Se eu quiser modificar esse span para verde, ao invés de poder colocar um modificador .is-green, vamos ter que fazer um seletor mais específico que #header > div > ul > li > p > span. #3 Regras longas pecam no desempenho;
Então, por favor, vamos tentar usar uma classe para cada elemento ou um conjunto de classes.
<div class=“nave nave-marciana is-green”></div>
#módulo
.nave {
width: 200px;
}
#submódulo
.nave-marciana {
from: marte;
}
#modificador. Vamos usar o prefixo ‘is-‘ para modificadores
.is-green {
background: green;
}
É aceitável que modificadores sejam específicos, porque as vezes o green de marte é um green diferente do de júpiter.
<div class=“nave nave-marciana is-green”></div>
<div class=“nave nave-jupiteriana is-green”></div>
.nave {
width: 200px;
}
.nave-marciana {
from: marte;
}
.is-green {
background: green;
}
.nave-jupiter{
from: jupiter;
&.is-green {
background: dark-green;
}
}
- Scaffolding de módulos;
- Code style para .js