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

Bontà 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 ritenevi fosse giusta?

Detto questo, personalmente preferisco la convenzione lowerCamelCase , e darò le ragioni e le considerazioni pratiche che ho usato per prendere una decisione - lo farò con un processo di eliminazione, usando la numerazione dalla tua domanda:

(5.) non è facilmente leggibile perché non si sa da dove iniziare e partire.

(6.) ASABOVEPLUSITSANNOYINGLIKESOMEONESHOUTING.

(4.) historical_incompatibility_plus_see: Documentazione di Mozilla Dev .

(3.) a-bit-trickier-to-explain ... come accennato, la selettività negli editor di testo è un problema (come con i caratteri di sottolineatura, a seconda dell'editor), ma per me è anche il fatto che mi ricorda la sintassi riservata per parole chiave specifiche del fornitore , anche se iniziano con un trattino oltre ad avere parole separate da loro.

Quindi questo lascia rispettivamente (1.) e (2.), UpperCamelCase e lowerCamelCase. Nonostante il collegamento mentale con le classi di Java (che sono, con una convenzione più chiaramente definita, UpperCamelCase), i nomi delle classi CSS mi sembrano migliori a partire da una lettera minuscola. Forse a causa del elemento XHTML e dei nomi degli attributi , ma immagino che potresti anche fare il caso che avere classi CSS usa UpperCamelCase aiuterebbe a distinguerli. Se hai bisogno di un altro motivo, lowerCamelCase è ciò che il W3C usa in esempi per i buoni nomi di classe (sebbene l'URL stesso, fastidiosamente, non sono d'accordo con me).

Vorrei sconsigliare (4.), (5.) e (6.), per le ragioni sopra esposte, ma supponiamo che si possano fare degli argomenti per uno degli altri tre.

Se tu (o chiunque altro) sia d'accordo con me su questo argomento, dipende da te. Il fatto che tu non abbia una risposta definita che citi fonti autorevoli ormai può essere presa come un suggerimento che non è una cosa come uno standard definito su questo problema (altrimenti lo useremmo tutti). Non sono sicuro che sia necessariamente una brutta cosa.

Le parole nei nomi delle classi CSS dovrebbero essere separate da trattini ( class-name ), in quanto è così che le parole nelle proprietà CSS e pseudo -classes sono separati 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 perché i nomi ID vengono spesso utilizzati negli URL 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 quello che ti senti più a tuo agio; basta essere coerenti.

Personalmente, utilizzo css-style-with-dashes , ma cerco di evitare nomi di classi multi-parola e di utilizzare più classi, ove possibile (quindi button important default anziché button-important-default ). Dalla mia esperienza, anche questa sembra essere la scelta più popolare tra siti web e framework di alta qualità.

Anche i caratteri minuscoli con i trattini sono più facili da scrivere rispetto alle altre opzioni (esclusa la convenzione di nowordseparatorswhatsoever difficile da leggere), almeno sulle tastiere statunitensi, perché non richiede l'uso del tasto Maiusc.

Per gli id, vi è la considerazione pratica aggiuntiva che se vuoi fare riferimento agli elementi in base al loro ID direttamente in javascript (es. document.forms[0].btn_ok ), i trattini non funzioneranno molto bene, ma poi, se stai usando jQuery, probabilmente lo userai comunque attraverso $() , quindi puoi semplicemente avere $('#btn-ok') , il che rende questo punto principalmente moot.

Per la cronaca, un'altra convenzione che ho incontrato utilizza regolarmente verruche ungheresi negli ID per indicare il tipo di elemento, in particolare per i controlli del modulo, quindi avresti #lblUsername , #tbUsername , #valUsername per l'etichetta del nome utente, input e validator.

Credo fermamente che la cosa più importante sia la coerenza.

Ci sono due modi per osservare questo:

1. Un buon argomento può essere fatto per alllowercase o css-style-clauses (probabilmente la scelta migliore) perché saranno i più coerenti con il codice in cui si troveranno. Darà un flusso più naturale a il codice in generale e nulla sarà stridente o fuori luogo.

2. Un argomento altrettanto valido può essere fatto per uno stile che sia diverso dai nomi dei tag HTML o dalle clausole CSS, se differenzierà ID e classi in un modo che aiuti la leggibilità. Ad esempio, se hai utilizzato UpperCamelCase per ID e classi e non l'hai utilizzato per nessun altro costrutto o scopo, sapresti di averlo colpito ogni volta che hai visto un token in quel formato. Una restrizione che potrebbe imporre è che sarebbe più efficace se l'ID o la classe ogni fossero un nome di parola 2+, ma in molti casi è ragionevole.

Nello scrivere questa risposta ho scoperto che sono molto più incline alla seconda scelta, ma lascerò entrambi perché penso che entrambi i casi abbiano un merito.

È tutta una questione di preferenza, o è questione di pigrizia. CamelCasing è più facile da digitare, ma preferisco usare la notazione del trattino basso perché trovo che sia più facile da leggere ed eseguire il debug di CamelCase. Non esiste una convenzione sulla codifica impostata da rispettare, non ho mai lavorato in un luogo che aveva le stesse linee guida di codifica del luogo che lo precedeva.

La maggior parte delle aziende ha linee guida che in genere devono rispettare qualsiasi modo per mantenere il codice pulito e più facile per tutti su cui lavorare. Se sei un freelance, puoi fare il tutto esaurito poiché sei l'unica persona che lavora sul codice. Secondo me ci sono solo 2 convenzioni di codifica da seguire: CamelCase o notazione Underscore. Il mio consiglio è di sceglierne uno e poi seguirlo.

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

È fatto dai grafici.

Non si preoccupano delle nostre guerre di editing e non potrebbero importare di meno di ciò che facciamo con il tasto shift.
Probabilmente nemmeno sanno dove quella chiave di _ è . (o come si chiama)

A loro non interessa l'estetica del codice , a loro interessa l'estetica estetica .

(E potrebbero avere un punto lì)

Loro non leggono le specifiche , ricevono il tutorial.
E poi ricontrolla i riferimenti su w3schools.

Alcuni di loro probabilmente credono di non poter usare nomi di classi maiuscole per ragioni.
Sono pieni di malintesi, per lo più irrilevanti.