Considerazioni pratiche per le convenzioni di denominazione HTML / CSS (sintassi) [chiuso]

Domanda: quali sono le considerazioni pratiche per la sintassi classe i idvalori?

Nota che non ti sto chiedendo della semantica , cioè delle parole reali che vengono utilizzate, come ad esempio descritto in questo post sul blog . Ci sono già molte risorse su quel lato delle convenzioni di denominazione, in effetti oscurando la mia ricerca di informazioni pratiche sui vari bit sintattici : involucro, uso dell'interpunzione (in particolare il -trattino), caratteri specifici da usare o da evitare, ecc.

Per riassumere i motivi che sto ponendo questa domanda:

• Le restrizioni di denominazione su ID e classe non portano naturalmente a nessuna convenzione
• L'abbondanza di risorse sul lato semantico delle convenzioni di denominazione oscura le ricerche sulle considerazioni sintattiche
• Non sono riuscito a trovare alcuna fonte autorevole su questo
• Non c'erano ancora domande sui programmatori SE su questo argomento :)

Alcune delle convenzioni che ho preso in considerazione usando:

1. UpperCamelCase, principalmente come abitudine incrociata dalla codifica lato server
2. lowerCamelCase, per coerenza con le convenzioni di denominazione JavaScript
3. css-style-classes, che è coerente con la denominazione delle proprietà dei CSS (ma può essere fastidioso quando si seleziona Ctrl + Maiusc + FrecciaKey del testo)
4. with_under_scores, che personalmente non ho visto usato molto
5. alllowercase, semplice da ricordare ma può essere difficile da leggere per nomi più lunghi
6. UPPERCASEFTW, come un ottimo modo per infastidire i tuoi colleghi programmatori (forse combinato con l'opzione 4 per la leggibilità)

E probabilmente ho tralasciato anche alcune opzioni o combinazioni importanti. Quindi: quali considerazioni ci sono per le convenzioni di denominazione e a quale convenzione portano?

Abbondanza o no, in una certa misura la scelta sarà sempre una "questione di preferenza" - dopo tutto, come ti sentiresti se il W3C raccomandasse (o addirittura imponesse) una certa convenzione che non ritieni giusta?

Detto questo, però, preferisco personalmente la lowerCamelCaseconvenzione e fornirò le ragioni e le considerazioni pratiche che ho usato per prendere una decisione: lo farò mediante un processo di eliminazione, usando la numerazione della tua domanda:

(5.) non facilmente leggibile perché non si sa dove le parole iniziano e vanno.

(6.) ASABOVEPLUSITSANNOYINGLIKESOMEONESHOUTING.

(4.) historical_incompatibility_plus_see: documentazione di Mozilla Dev .

(3.) un po 'più complicato da spiegare ... come dici tu, la selezionabilità negli editor di testo è un problema (come per i trattini bassi, a seconda dell'editor), ma per me è anche il fatto che mi ricorda la sintassi riservata alle parole chiave specifiche del fornitore , anche se quelle iniziano con un trattino e hanno parole separate da esse.

Quindi questo lascia rispettivamente (1.) e (2.), UpperCamelCase e lowerCamelCase. Nonostante il collegamento mentale con le classi Java (che sono, secondo una convenzione più chiaramente definita, UpperCamelCase), i nomi delle classi CSS sembrano, per me, essere migliori partendo da una lettera minuscola. Forse è a causa dell'elemento XHTML e dei nomi degli attributi , ma immagino che potresti anche sostenere che avere classi CSS che usano UpperCamelCase aiuterebbe a distinguerle. Se hai bisogno di un altro motivo, lowerCamelCase è ciò che il W3C usa negli esempi per nomi di buone classi (anche se l'URL stesso, fastidiosamente, non è d'accordo con me).

Vorrei sconsigliare i punti (4.), (5.) e (6.), per le ragioni sopra esposte, ma suppongo che si possano avanzare argomentazioni per una delle altre tre.

Tuttavia, se tu (o chiunque altro) siate d'accordo con me in merito, dipende da voi. Il fatto che non hai una risposta definitiva che citi fonti autorevoli ormai può essere suggerito che non esiste una cosa come uno standard definito su questo problema (altrimenti lo useremmo tutti). Non sono sicuro che sia necessariamente una cosa negativa.

Le parole nei nomi delle classi CSS devono essere separate con trattini ( class-name), in questo modo le parole nelle proprietà CSS e nelle pseudo-classi sono separate e la loro sintassi è definita dalle specifiche CSS .

Anche le parole nei nomi ID devono essere separate da trattini, in modo che corrispondano allo stile sintattico dei nomi delle classi e spesso negli URL vengono utilizzati spesso nomi ID e il trattino è il separatore di parole originale e più comune negli URL.

È principalmente una questione di preferenza; non esiste uno standard stabilito, per non parlare di una fonte autorevole, in materia. Usa tutto ciò con cui ti senti più a tuo agio; sii coerente.

Personalmente, io uso css-style-with-dashes , ma cerco di evitare i nomi di classe multi-word e utilizzo più classi ogni volta che è possibile (quindi button important defaultpiuttosto che button-important-default). Dalla mia esperienza, questa sembra anche essere la scelta più popolare tra siti Web e framework di alta qualità.

Le lettere minuscole con trattini sono anche più facili da digitare rispetto alle altre opzioni (esclusa la nowordseparatorswhatsoeverconvenzione difficile da leggere ), almeno sulle tastiere statunitensi, perché non richiedono l'uso del tasto Maiusc.

Per gli ID, c'è l'ulteriore considerazione pratica che se si desidera fare riferimento agli elementi tramite il loro ID direttamente in javascript (ad esempio document.forms[0].btn_ok), i trattini non funzioneranno così bene - ma quindi, se si utilizza jQuery, probabilmente si usali $()comunque, quindi puoi semplicemente averlo$('#btn-ok') , il che rende questo punto per lo più discutibile.

Per la cronaca, un'altra convenzione mi imbatto regolarmente utilizza verruche ungheresi in ID di indicare il tipo di elemento, in particolare per i controlli dei moduli - così si avrebbe #lblUsername, #tbUsername, #valUsernameper l'etichetta nome utente, l'input e validatore.

Credo fermamente che ciò che conta di più sia la coerenza.

Esistono due modi per esaminare questo:

1. Un buon argomento può essere fatto per alllowercaseocss-style-clauses ( probabilmente la scelta migliore) perché saranno i più coerenti con il codice in cui si troveranno. Presterà un flusso più naturale al codice in generale e nulla sarà stonato o fuori posto .

2. Un'argomentazione altrettanto valida può essere fatta per uno stile distinto dai nomi dei tag HTML o dalle clausole CSS, se differenzierà ID e classi in modo da facilitare la leggibilità. Ad esempio, se si utilizzava UpperCamelCaseper ID e classi e non lo si utilizzava per nessun altro costrutto o scopo, si saprebbe di averne colpito uno ogni volta che si vedeva un token in quel formato. Una limitazione che ciò potrebbe imporre è che sarebbe più efficace se ogni ID o classe avesse un nome di 2+ parole, ma ciò è ragionevole in molti casi.

Nello scrivere questa risposta sono arrivato a scoprire che sono molto più propenso alla seconda scelta, ma lascerò entrambi perché penso che entrambi i casi abbiano merito.

È davvero una questione di preferenza o di pigrizia. CamelCasing è più facile da scrivere, ma preferisco usare la notazione di sottolineatura in quanto trovo personalmente più facile da leggere ed eseguire il debug di CamelCase. Non esiste una convenzione di codifica definita da rispettare, non ho mai lavorato in un posto che avesse le stesse linee guida di codifica del luogo precedente.

La maggior parte delle aziende ha linee guida che generalmente devi rispettare in qualsiasi modo per mantenere il codice pulito e più facile su cui tutti possono lavorare. Se sei un libero professionista, puoi fare tutto perché sei l'unica persona che lavora sul codice. A mio avviso ci sono solo 2 convenzioni di codifica da seguire: notazione CamelCase o Underscore. Il mio consiglio è di sceglierne uno e poi attenerci.

Sembri ignaro di un semplice fatto: la maggior parte dei CSS non viene eseguita dai programmatori .

È fatto da grafici.

A loro non importa delle nostre guerre di modifica e non gliene potrebbe fregare di meno di ciò che facciamo con il tasto Maiusc.
Probabilmente non sanno nemmeno dove sia quella _chiave di fantasia . (o come si chiama)

A loro non importa dell'estetica del codice , si preoccupano dell'estetica estetica .

(E potrebbero avere un punto lì)

Essi non leggono le specifiche , ottengono il tutorial.
E poi ricontrolla i riferimenti su w3schools.

Alcuni di loro probabilmente credono di non poter usare i nomi di classe maiuscoli per motivi.
Sono pieni di idee sbagliate strane, per lo più irrilevanti.