Considerações práticas para convenções de nomenclatura HTML / CSS (sintaxe) [fechado]

Pergunta: quais são as considerações práticas para a sintaxe classe os idvalores?

Observe que não estou perguntando sobre a semântica , ou seja, as palavras reais que estão sendo usadas, como por exemplo, descritas neste post do blog . Já existem muitos recursos nesse lado das convenções de nomenclatura, na verdade obscurecendo minha pesquisa por informações práticas sobre os vários bits sintáticos : invólucro, uso de interpunções (especificamente o -traço), caracteres específicos a serem usados ​​ou evitados etc.

Para resumir as razões pelas quais estou fazendo esta pergunta:

• As restrições de nomenclatura em id e classe não levam naturalmente a nenhuma convenção
• A abundância de recursos no lado semântico das convenções de nomenclatura obscurece as pesquisas sobre considerações sintáticas
• Não consegui encontrar nenhuma fonte autorizada neste
• Ainda não havia nenhuma pergunta sobre os Programadores de SE sobre este tópico :)

Algumas das convenções que considerei usar:

1. UpperCamelCase, principalmente como um hábito cruzado da codificação no servidor
2. lowerCamelCase, para consistência com as convenções de nomenclatura JavaScript
3. css-style-classes, que é consistente com a nomeação de propriedades css (mas pode ser irritante quando Ctrl + Shift + ArrowKey seleciona o texto)
4. with_under_scores, que eu pessoalmente não vi muito usado
5. alllowercase, simples de lembrar, mas pode ser difícil de ler para nomes mais longos
6. UPPERCASEFTW, como uma ótima maneira de irritar seus colegas programadores (talvez combinados com a opção 4 para facilitar a leitura)

E provavelmente deixei de fora algumas opções ou combinações importantes também. Então: que considerações existem para convenções de nomenclatura e a que convenção elas levam?

Recompensa ou não, até certo ponto, a escolha sempre será uma "questão de preferência" - afinal, como você se sentiria se o W3C recomendasse (ou até impusesse) uma certa convenção que não considerava correta?

Dito isto, porém, eu pessoalmente prefiro a lowerCamelCaseconvenção e darei as razões e considerações práticas que já usei para decidir - farei isso por um processo de eliminação, usando a numeração da sua pergunta:

(5.) não é muito fácil de ler porque você sabe que as palavras começam e

(6.) ACIMA DE MAIS, NÃO PODE GANHAR ALGUM ALGUMA COISA.

(4.) historical_incompatibility_plus_see: documentação do Mozilla Dev .

(3.) um pouco mais complicado de explicar ... como você menciona, a selecionabilidade nos editores de texto é um problema (como os sublinhados, dependendo do editor), mas para mim também é o fato de que isso me lembra a sintaxe reservada para palavras-chave específicas do fornecedor , mesmo que elas comecem com um hífen e também com palavras separadas por elas.

Portanto, isso deixa seu (1.) e (2.), UpperCamelCase e lowerCamelCase, respectivamente. Apesar do vínculo mental com as classes Java (que são, por uma convenção mais claramente definida, UpperCamelCase), os nomes das classes CSS parecem, para mim, melhores começar com uma letra minúscula. Talvez seja por causa dos nomes dos elementos e atributos XHTML , mas acho que você também pode argumentar que as classes CSS usam UpperCamelCase ajudariam a diferenciá-las. Se você precisar de outro motivo, lowerCamelCase é o que o W3C usa em exemplos para bons nomes de classe (embora a própria URL, irritantemente, discorde de mim).

Aconselho contra (4.), (5.) e (6.) pelas razões expostas acima, mas suponho que argumentos possam ser apresentados para qualquer um dos outros três.

Entretanto, você (ou qualquer outra pessoa) concorda ou não comigo sobre esse assunto. O fato de você não ter uma resposta definitiva citando fontes autorizadas até agora pode ser entendido como uma dica de que não existe um padrão definido para esse problema (caso contrário, todos nós o estaríamos usando). Não tenho certeza se isso é necessariamente uma coisa ruim.

As palavras nos nomes das classes CSS devem ser separadas por traços ( class-name), pois é assim que as palavras nas propriedades CSS e nas pseudo-classes são separadas e sua sintaxe é definida pelas especificações CSS .

As palavras nos nomes de ID também devem ser separadas por hífens, para corresponder ao estilo sintático dos nomes das classes e porque os nomes de ID são frequentemente usados ​​em URLs e o traço é o separador de palavras original e mais comum em URLs.

É principalmente uma questão de preferência; não existe um padrão estabelecido, muito menos uma fonte autorizada, sobre o assunto. Use o que você se sentir mais confortável; apenas seja consistente.

Pessoalmente, eu uso css-style-with-dashes, mas tento evitar nomes de classes com várias palavras e usar várias classes sempre que possível ( button important defaulte não button-important-default). Pela minha experiência, essa também parece ser a escolha mais popular entre sites e estruturas de alta qualidade.

Letras minúsculas com traços também são mais fáceis de digitar do que as outras opções (excluindo a nowordseparatorswhatsoeverconvenção de difícil leitura ), pelo menos nos teclados dos EUA, porque não requer o uso da tecla Shift.

Para os IDs, existe a consideração prática adicional de que, se você quiser referenciar elementos por seu ID diretamente em javascript (por exemplo document.forms[0].btn_ok), traços não funcionarão tão bem - mas, se você estiver usando jQuery, provavelmente irá use-as de $()qualquer maneira, para que você possa ter $('#btn-ok'), o que torna esse ponto discutível.

Para o registro, outra convenção me deparo regularmente usa verrugas húngaras em ID de indicar o tipo de elemento, especialmente para controles de formulário - então você teria #lblUsername, #tbUsername, #valUsernamepara o rótulo nome de usuário, entrada e validador.

Eu acredito firmemente que o que mais importa é consistência.

Existem duas maneiras de analisar isso:

1. Um bom argumento pode ser feito a favor alllowercaseou css-style-clauses(provavelmente a melhor escolha), porque eles serão os mais consistentes com o código em que serão inseridos. Isso proporcionará um fluxo mais natural ao código geral e nada será estridente ou fora do lugar .

2. Um argumento igualmente bom pode ser feito para um estilo distinto dos nomes de tags HTML ou cláusulas CSS, se diferenciar IDs e classes de uma maneira que ajude a legibilidade. Por exemplo, se você usasse UpperCamelCaseIDs e classes, e não o utilizasse para qualquer outra construção ou finalidade, saberia que havia encontrado um toda vez que visse um token nesse formato. Uma restrição que isso pode impor é que seria mais eficaz se cada ID ou classe tivesse um nome com mais de 2 palavras, mas isso é razoável em muitos casos.

Ao escrever esta resposta, descobri que estou muito mais inclinado para a segunda opção, mas deixarei as duas porque acho que ambas as hipóteses têm mérito.

É tudo uma questão de preferência, realmente, ou uma questão de preguiça. O CamelCasing é mais fácil de digitar, mas eu prefiro usar a notação de sublinhado, pois acho pessoalmente mais fácil ler e depurar do que o CamelCase. Não existe uma convenção de codificação a ser cumprida; nunca trabalhei em um local que tivesse as mesmas diretrizes de codificação do local anterior.

A maioria das empresas possui diretrizes em que geralmente é necessário respeitar qualquer forma de manter o código limpo e fácil para todos trabalharem. Se você é freelancer, pode se esforçar ao máximo, pois é a única pessoa que trabalha no código. Na minha opinião, existem apenas duas convenções de codificação: CamelCase ou Underscore notation. Meu conselho é escolher um e depois ficar com ele.

Você parece alheio a um fato simples: a maioria das CSS não é feita por programadores .

É feito por designers gráficos.

Eles não se importam com nossas guerras de edição e não se importam com o que fazemos com a tecla Shift.
Eles provavelmente nem sabem onde está essa _chave sofisticada . (ou qual é o nome dele)

Eles não se preocupam com a estética do código , eles se preocupam com a estética estética .

(E eles podem ter um ponto lá)

Eles não leem as especificações , recebem o tutorial.
E, em seguida, verifique novamente as referências no w3schools.

Alguns deles provavelmente acreditam que não podem usar nomes de classe em maiúsculas por motivos.
Eles estão cheios de equívocos estranhos, principalmente irrelevantes.