Perché i trattini sono preferiti per i selettori CSS / gli attributi HTML?

In passato ho sempre usato i trattini bassi per definire gli attributi di classe e id in HTML. Negli ultimi anni sono passato ai trattini, principalmente per allinearmi con la tendenza della comunità , non necessariamente perché aveva senso per me.

Ho sempre pensato che i trattini presentino più svantaggi e non ne vedo i vantaggi:

Completamento e modifica del codice

La maggior parte degli editor tratta i trattini come separatori di parole, quindi non posso accedere al simbolo che desidero. Supponiamo che la classe sia " featured-product", devo completare automaticamente " featured", inserire un trattino e completare "product ".

Con sottolineatura "featured_product " viene trattato come una sola parola, quindi può essere compilato in un solo passaggio.

Lo stesso vale per la navigazione nel documento. Saltare con le parole o fare doppio clic sui nomi delle classi è interrotto da trattini.

(Più in generale, penso a classi e ID come token , quindi non ha senso per me che un token dovrebbe essere facilmente divisibile su trattini.)

Ambiguità con operatore aritmetico

L'uso dei trattini interrompe l' accesso alla proprietà oggetto per gli elementi del modulo in JavaScript. Questo è possibile solo con caratteri di sottolineatura:

form.first_name.value='Stormageddon';

(Devo ammettere che non accedo agli elementi del modulo in questo modo, ma quando decido di trattini o trattini bassi come una regola universale, considera che qualcuno potrebbe.)

Lingue come Sass (specialmente in tutto il framework Compass ) si sono sistemate su trattini come standard, anche per i nomi delle variabili. Inizialmente usavano anche i trattini bassi. Il fatto che questo sia analizzato in modo diverso mi sembra strano:

$list-item-10
$list-item - 10

Incoerenza con denominazione variabile tra le lingue

Indietro nel giorno, ho usato per scrivere underscored_namesper le variabili in PHP, Ruby, HTML / CSS e JavaScript. Questo era comodo e coerente, ma di nuovo per "adattarmi" ora uso:

• dash-case in HTML / CSS
• camelCase in JavaScript
• underscore_case in PHP e rubino

Questo non mi dà molto fastidio, ma mi chiedo perché siano diventati così disallineati, apparentemente di proposito. Almeno con i trattini bassi è stato possibile mantenere la coerenza:

var featured_product = $('#featured_product'); // instead of
var featuredProduct = $('#featured-product');

Le differenze creano situazioni in cui dobbiamo tradurre inutilmente le stringhe , insieme al potenziale di bug.

Quindi chiedo: perché la comunità si è assestata quasi universalmente sui trattini e ci sono delle ragioni che superano le sottolineature?

C'è una domanda correlata da quando è iniziata, ma sono dell'opinione che non sia (o non avrebbe dovuto essere) solo una questione di gusti. Mi piacerebbe capire perché siamo tutti d'accordo su questa convenzione se fosse davvero solo una questione di gusti.

Completamento del codice

Se il trattino sia interpretato come punteggiatura o come un identificatore opaco dipende dall'editor di scelta, immagino. Tuttavia, come preferenza personale, preferisco poter passare da una parola all'altra in un file CSS e troverei fastidioso se fossero separati da un trattino basso e non ci fossero fermate.

Inoltre, l'utilizzo di trattini consente di sfruttare il selettore di attributi | = , che seleziona qualsiasi elemento contenente il testo, facoltativamente seguito da un trattino:

span[class|="em"] { font-style: italic; }

Ciò renderebbe i seguenti elementi HTML in stile corsivo:

<span class="em">I'm italic</span>
<span class="em-strong">I'm italic too</span>

Ambiguità con operatore aritmetico

Direi che l'accesso agli elementi HTML tramite notazione punto in JavaScript è un bug piuttosto che una funzionalità. È una costruzione terribile fin dai primi tempi di terribili implementazioni JavaScript e non è davvero una grande pratica. Per la maggior parte delle cose che fai con JavaScript in questi giorni, ti consigliamo di utilizzare selettori CSS per recuperare comunque elementi dal DOM, il che rende l'intera notazione con punti piuttosto inutile. Quale preferiresti?

var firstName = $('#first-name');
var firstName = document.querySelector('#first-name');
var firstName = document.forms[0].first_name;

Trovo le due prime opzioni molto più preferibili, soprattutto perché '#first-name'possono essere sostituite con una variabile JavaScript e costruite in modo dinamico. Li trovo anche più piacevoli per gli occhi.

Il fatto che Sass abiliti l'aritmetica nelle sue estensioni al CSS non si applica in realtà al CSS stesso, ma capisco (e abbraccio) il fatto che Sass segue lo stile linguistico del CSS (ad eccezione del $prefisso delle variabili, che ovviamente dovrebbe sono stato@ ). Se i documenti Sass devono apparire e sembrare documenti CSS, devono seguire lo stesso stile dei CSS, che utilizza il trattino come delimitatore. In CSS3, l'aritmetica è limitata alla calcfunzione, il che dimostra che nel CSS stesso non si tratta di un problema.

Incoerenza con denominazione variabile tra le lingue

Tutte le lingue, essendo linguaggi di markup, linguaggi di programmazione, linguaggi di stile o linguaggi di scripting, hanno il loro stile. Lo troverai all'interno di sotto-lingue di gruppi linguistici come XML, dove ad esempio XSLT utilizza lettere minuscole con delimitatori di trattini e XML Schema utilizza il rivestimento dei cammelli.

In generale, scoprirai che adottare lo stile che sembra e sembra più "nativo" nella lingua in cui stai scrivendo è meglio che cercare di inserire il tuo stile in ogni lingua diversa. Dal momento che non puoi evitare di usare librerie native e costrutti di linguaggio, il tuo stile sarà "inquinato" dallo stile nativo, che ti piaccia o no, quindi è praticamente inutile persino provarci.

Il mio consiglio è di non trovare uno stile preferito tra le lingue, ma invece di sentirti a casa all'interno di ogni lingua e imparare ad amare tutte le sue stranezze. Una delle stranezze di CSS è che le parole chiave e gli identificatori sono scritti in minuscolo e separati da trattini. Personalmente, trovo questo accattivante dal punto di vista visivo e penso che sia compatibile con l' HTML tutto minuscolo (sebbene senza trattino) .

Forse un motivo chiave per cui la comunità HTML / CSS si è allineata con trattini anziché caratteri di sottolineatura è dovuto a carenze storiche nelle specifiche e nelle implementazioni del browser.

Da un documento Mozilla pubblicato nel marzo 2001 @ https://developer.mozilla.org/en-US/docs/Underscores_in_class_and_ID_Names

La specifica CSS1, pubblicata nella sua forma definitiva nel 1996, non consentiva l'uso di caratteri di sottolineatura in classe e nomi ID a meno che non fossero "evasi". Un carattere di sottolineatura con escape sarebbe simile a questo:

    p.urgent\_note {color: maroon;}

Tuttavia, al momento questo non era ben supportato dai browser e la pratica non ha mai preso piede. CSS2, pubblicato nel 1998, proibiva anche l'uso di caratteri di sottolineatura in classe e nomi ID. Tuttavia, errata alle specifiche pubblicate all'inizio del 2001 ha reso i caratteri di sottolineatura legali per la prima volta. Questo purtroppo ha complicato un paesaggio già complesso.

In genere mi piacciono i caratteri di sottolineatura, ma la barra rovesciata lo rende brutto oltre ogni speranza, per non parlare del supporto scarso in quel momento. Posso capire perché gli sviluppatori lo hanno evitato come la peste. Certo, al giorno d'oggi non abbiamo bisogno della barra rovesciata, ma l'etichetta trattata è già stata stabilita con fermezza.

Non penso che nessuno possa rispondere in modo definitivo, ma ecco le mie ipotesi colte:

1. I caratteri di sottolineatura richiedono di premere il tasto Maiusc e sono quindi più difficili da digitare.

2. I selettori CSS che fanno parte delle specifiche CSS ufficiali utilizzano trattini (come pseudo-classi come: first-child e pseudo-elements: first-line), non caratteri di sottolineatura. Stessa cosa per le proprietà, ad es. Decorazione del testo, colore di sfondo, ecc. I programmatori sono creature abituali. Ha senso che seguano lo stile dello standard se non ci sono buone ragioni per non farlo.

3. Questo è più in là, ma ... Che si tratti di mito o fatto, esiste da tempo l'idea che Google tratti le parole separate da caratteri di sottolineatura come un'unica parola e le parole separate da trattini come parole separate. (Matt Cutts su Underscores vs. Dashes.) Per questo motivo, so che la mia preferenza ora per la creazione di URL di pagina è quella di usare parole con trattini e, almeno per me, questo è insanguinato nelle convenzioni di denominazione per altre cose , come i selettori CSS.

Ci sono molte ragioni, ma una delle cose più importanti è mantenere la coerenza .

Penso che questo articolo lo spieghi in modo esauriente.

CSS è una sintassi delimitata da trattini. Con questo voglio dire che scriviamo cose come font-size, line-height, border-bottometc.

Così:

Non dovresti semplicemente mescolare le sintassi: è incoerente .

Negli ultimi anni c'è stato un chiaro aumento nei segmenti di URL di parola intera separati da trattini. Ciò è incoraggiato dalle migliori pratiche SEO. Google "consiglia espressamente di utilizzare trattini (-) anziché caratteri di sottolineatura (_) nei tuoi URL": http://www.google.com/support/webmasters/bin/answer.py?answer=76329 .

Come notato, diverse convenzioni hanno prevalso in momenti diversi in contesti diversi, ma in genere non fanno parte formale di alcun protocollo o framework.

La mia ipotesi, quindi, è che la posizione di Google ancori questo modello all'interno di un contesto chiave (SEO), e la tendenza ad utilizzare questo modello nei nomi di classe, ID e attributo è semplicemente la mandria che si muove lentamente in questa direzione generale.

Penso che sia una cosa dipendente dal programmatore. Ad alcuni piace usare i trattini, altri usano i trattini bassi.
Personalmente uso underscore ( _) perché lo uso anche in altri posti. Come ad esempio:
- variabili JavaScript ( var my_name);
- Le azioni del mio controller ( public function view_detail)
Un altro motivo per cui utilizzo i trattini bassi è che nella maggior parte degli IDE due parole separate da trattini bassi sono considerate come 1 parola. (e è possibile selezionare con double_click).