Closed rafaelchavesfreitas closed 10 years ago
ver #214
tem um post no nosso p2 sobre essa questão, deixei um comentário lá http://design.hacklab.com.br/2014/07/11/less-x-sass/
(minha resposta curta é sass)
Optamos por Sass como relatado aqui: http://design.hacklab.com.br/2014/08/14/papo-design-14082014-relatos/
Fiz uma branch (issue-222-sass) e acabei de pushar o primeiro commit 46ebf6ecffe Segui a seguinte estrutura de pastas:
.../assets/css/sass/
|
|-- globals/ # Variáveis, mixins, funções que não viram css, mas são usados em todo o css
|
|-- modules/ # Arquivos de regras básicas ( nesse sentido http://smacss.com/book/type-base) e classes de apoio
|
|-- components/ # Arquivos de componentes, como botões, abas, tooltips, etc. reutilizáveis
|
|-- application/ # Arquivos de componentes da aplicação, como header, footer, home, busca avançada
|
|-- vendor/ # CSS ou Sass que sobrescrevem estilos de outros projetos (jquery ui)
| ...
|
-- main.scss # Arquivo Sass principal (ainda não criei)
Comecei a quebrar o css em partials do Sass, (ainda não terminei) e comecei o arquivo de variáveis. Estou aberta a sugestões e melhorias. Ainda não tenho certeza se faz sentido ter a pasta application ou se transformo tudo em partials de components. Com certeza, os arquivos de application gerarão vários components, se mantidos, mas por enquanto estou tentado estruturar, depois vou atacar arquivo por arquivo e transformar em Sass e limpar. Usei como referência e inspiração as seguintes referências:
Gostaria da ajuda do @seufelipe pra pensar num plano de como tocar essa mega tarefa, quebrá-la em várias issues.
Limpar estilos do xeditable a medida que for migrando pro angular. *xeditable é a biblioteca de edit inline.