Usar [data-attr] no CSS para definir opções do elemento

[felipefialho]

Já faz bastante tempo que utilizo os [data-attr] para iniciar JavaScript e definir opções de plugins.

Porém comecei a fazer alguns testes com CSS, quando em projetos grandes e cheio de customizações, preciso definir muitos parametros no mesmo elemento.

Particulamente estou gostando bastante dos resultados.

Antes eu faria algo como

.hive__block.block--primary.block--offset-2.animation--scale

Tenho usado algo como:

.hive__block(block-color='blue' block-offset='2' animation-in='scale-in') 

Sei que é mais lento do que usar classes, mas estou achando que o código fica bem mais sólido.

O que acham dessa abordagem?

[marcoostan]

Já utilizei e acho uma abordagem válida. Ainda mais que se o seu padrão de JavaScript é através de data atributos, isso torna claro no HTML, CSS e JavaScript, que isso é para algo manipulável e dinâmico.

Sendo assim, em futuro refactotory ou remoção está fácil identificar todos os pontos de alteração.

[felipefialho]

Exato @marcoostan!

Um ponto importante, é que como uso os datas-* para manipular JavaScript, tenho optado usar o elemento direto, sem o data-*, no CSS.

Tudo muito experimental ainda.

Vamos ver como me sinto no decorrer do projeto.

[omarkdev]

@lfeh O problema do uso sem o data-*, é que em validações como o W3C, eles dão erro.

[felipefialho]

Cara, faz tantos anos que não valido meu código que não é uma preocupação pra mim 😄

[marcoostan]

@lfeh Depois compartilha conosco o que ganhou e o que perdeu com essa abordagem 😄

[felipefialho]

@marcoostan Pode deixar!

[fititnt]

EDIT em 10 nov 2016 14:31 BRT: esse comentário se aplica apenas a omissão de "data-" nos atributos de elementos

---

Tendo opção que é HTML válida em relação a outras, escolher a que não valida sem um ótimo motivo, é uma má prática não validar código intencionalmente:

• Você não tem controle sobre o comportamento em todos os agentes de usuário
• Seu código é menos estável e tem uma chance muito maior de parar de funcionar a qualquer momento
• Você vai ter mais trabalho pra debugar
• Se outras pessoas vão usar seu código:
  • Eles vão ter mais trabalho para debugar o que você implementou
  • Não validar seu código vai gerar ruido para testar código ou implementações de outras pessoas

Vale a pena correr todos esses riscos apenas pra economizar 5 caracteres? Você quer ver o mundo pegar fogo?

PS.: estou falando apenas de validar HTML5.1, e definitivamente eu não tenho mesma opinião quanto a validar CSS.

[akfzambrana]

Aqui nos projetos temos um problema qdo se trata de colocar o width dos inputs, selects, etc pois eles dependem do tipo de dado q vai ser preenchido e tem X colunas de largura. E temos muitos formularios pois é uma aplicação e não um site.

Nós não utilizamos classes com o nome .col-x simplesmente porque não são semanticas e fica um inferno pra mexer no responsivo então passamos a utilizar uma classe chamada .field-size-x com o mesmo intuito mas que fica menos pior ja que especifica q se refere ao "tamanho do campo x" e não a X colunas de grid qualquer. Pensando nesse ponto o tamanho do campo 2 pode ser igual a 2 colunas ou igual à categoria 2 no layout criado pelo designer ou ao nivel 2 de qq coisa então fica um pouco melhor.
Hoje estavamos discutindo a respeito do uso dessa classe e decidimos utilizar "custom attributes" pra fazer e o resultado ficou decente. O atributo q estamos utilizando é fieldsize pois tentamos sobrescrever o attr size e tivemos muitos problemas pois para cada tipo de campo o size se comporta diferente a o reset desses negocios tava deixando o bagulho mega chato/complexo/sujo.

No nosso caso a "validação" do código HTML perde para praticidade na manutenção e produtividade 😉

ah! sim, este é um exemplo de como estamos aplicando: http://codepen.io/akfzambrana/pen/ObVrpp

[felipefialho]

@fititnt

Você não tem controle sobre o comportamento em todos os agentes de usuário

O suporte ao data-attr passa dos 97% segundo o Can I Use

Seu código é menos estável e tem uma chance muito maior de parar de funcionar a qualquer momento

Basicamente todos os plugins JavaScript atuais utilizam data-* para manipulação. Nunca vi nenhum problema de instabilidade.

Você vai ter mais trabalho pra debugar
Se outras pessoas vão usar seu código:
Eles vão ter mais trabalho para debugar o que você implementou
Não validar seu código vai gerar ruido para testar código ou implementações de outras pessoas

Não muda nada para debugar. Todos os elementos do data-* são debugados como qualquer outro método de estilização.

Quando a validar, até concordo com você, porque especialmente usando Template Engines, podem gerar cagadas sem a gente perceber (como o html fechando antes do body no meu site, na issue que você abriu), mas vale mais atenção do desenvolvedor.

---

Com relação a escalabilidade, percebo uma melhoria grande. Fica mais legível. Estou curtindo usar assim por enquanto.

Mas aviso que aqui fica MUITO importante fazer documentação das opções do componente. Tal qual você faria (ou deveria fazer) no JavaScript.

[fititnt]

Adicionei um edit explicito no meu comentário. Note que minha crítica é exclusivamente ao omitir "data-" e usar um atributo bruto, que potencialmente pode conflitar com atributos existentes ou futuros.

[felipefialho]

@fititnt Só editando. Você tem toda razão. Usar o elemento sozinho, sem o data-*, tem chances imensas de dar merda.

To testando algumas nomenclaturas. Por hora estou utilizando algo como:

data-bg

Vou atualizando conforme mude. Esse é um projeto enorme, com bom prazo de desenvolvimento, então estou usando para testar técnicas novas.