Dlaczego kreski są preferowane dla selektorów CSS / atrybutów HTML?

W przeszłości zawsze używałam podkreślników do definiowania atrybutów klasy i id w HTML. W ciągu ostatnich kilku lat przeszedłem na myślniki, głównie po to, aby dostosować się do trendów w społeczności , niekoniecznie dlatego, że miało to dla mnie sens.

Zawsze myślałem, że kreski mają więcej wad i nie widzę korzyści:

Uzupełnianie i edycja kodu

Większość redaktorów traktuje myślniki jako separatory słów, więc nie mogę przechodzić do odpowiedniego symbolu. Powiedz, że klasa to „ featured-product”, muszę wykonać automatyczne „ featured”, wprowadzić myślnik i uzupełnić „ product”.

Podkreślenia „ featured_product” są traktowane jak jedno słowo, dlatego można je wypełnić w jednym kroku.

To samo dotyczy poruszania się po dokumencie. Przeskakiwanie przez słowa lub podwójne kliknięcie na nazwę klasy jest przerywane myślnikami.

(Mówiąc bardziej ogólnie, uważam klasy i identyfikatory za tokeny , więc nie ma dla mnie sensu, aby token mógł być tak łatwo rozdzielać na myślniki).

Niejednoznaczność z operatorem arytmetycznym

Użycie myślników przerywa dostęp do właściwości obiektu do elementów formularza w JavaScript. Jest to możliwe tylko w przypadku podkreślników:

form.first_name.value='Stormageddon';

(Wprawdzie sam nie uzyskuję dostępu do elementów formularza w ten sposób, ale decydując się na myślniki vs. podkreślenia jako ogólną zasadę, weź pod uwagę, że ktoś może.)

Języki, takie jak Sass (szczególnie w ramach kompasu ), zostały ustawione na myślniki jako standard, nawet w przypadku nazw zmiennych. Początkowo używali również podkreślników. Fakt, że jest to analizowane inaczej, wydaje mi się dziwny:

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

Niespójność z nazewnictwem zmiennych w różnych językach

Wcześniej pisałem underscored_namesdla zmiennych w PHP, Ruby, HTML / CSS i JavaScript. Było to wygodne i spójne, ale ponownie, aby „dopasować się”, teraz używam:

• dash-case w HTML / CSS
• camelCase w JavaScript
• underscore_case w PHP i Ruby

Nie przeszkadza mi to zbytnio, ale zastanawiam się, dlaczego zostały one tak źle dopasowane, pozornie celowo. Przynajmniej dzięki podkreśleniom można było zachować spójność:

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

Różnice tworzą sytuacje, w których musimy niepotrzebnie tłumaczyć ciągi , wraz z potencjalnym błędem.

Pytam więc: dlaczego społeczność prawie uniwersalnie zdecydowała się na myślniki i czy istnieją jakieś powody, które przewyższają podkreślenia?

Od czasu, kiedy to się zaczęło, jest powiązane pytanie , ale jestem zdania, że ​​nie jest to (lub nie powinno być) tylko kwestia gustu. Chciałbym zrozumieć, dlaczego wszyscy zdecydowaliśmy się na tę konwencję, jeśli naprawdę była to tylko kwestia gustu.

Uzupełnianie kodu

To, czy myślnik jest interpretowany jako interpunkcja, czy jako nieprzezroczysty identyfikator, zależy od wybranego edytora. Jednak, jako osobistą preferencję, wolę możliwość tabulowania między każdym słowem w pliku CSS i byłoby denerwujące, gdyby były oddzielone znakiem podkreślenia i nie było żadnych zatrzymań.

Ponadto użycie łączników pozwala skorzystać z selektora atrybutu | = , który wybiera dowolny element zawierający tekst, opcjonalnie po nim myślnik:

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

Spowodowałoby to, że następujące elementy HTML mają kursywę:

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

Niejednoznaczność z operatorem arytmetycznym

Powiedziałbym, że dostęp do elementów HTML za pomocą notacji kropkowej w JavaScript jest raczej błędem niż funkcją. To okropna konstrukcja od pierwszych dni strasznych implementacji JavaScript i nie jest tak naprawdę świetną praktyką. W przypadku większości rzeczy, które robisz za pomocą JavaScript w dzisiejszych czasach, i tak chciałbyś używać Selektorów CSS do pobierania elementów z DOM, co sprawia, że ​​cała notacja kropkowa jest raczej bezużyteczna. Który wolisz?

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

Dwie pierwsze opcje uważam za znacznie bardziej preferowane, zwłaszcza że '#first-name'można je zastąpić zmienną JavaScript i zbudować dynamicznie. Uważam też, że są przyjemniejsze dla oczu.

Fakt, że Sass umożliwia arytmetykę w swoich rozszerzeniach do CSS, tak naprawdę nie dotyczy samego CSS, ale rozumiem (i akceptuję) fakt, że Sass postępuje zgodnie ze stylem językowym CSS (z wyjątkiem $przedrostka zmiennych, który oczywiście powinien były @). Jeśli dokumenty Sass mają wyglądać i wyglądać jak dokumenty CSS, muszą stosować ten sam styl, co CSS, który używa myślnika jako separatora. W CSS3 arytmetyka ogranicza się do calcfunkcji, która pokazuje, że w samym CSS nie stanowi to problemu.

Niespójność z nazewnictwem zmiennych w różnych językach

Wszystkie języki, jako języki znaczników, języki programowania, języki stylów lub języki skryptowe, mają swój własny styl. Znajdziesz to w podjęzykach grup językowych, takich jak XML, gdzie np. XSLT używa małych liter z ogranicznikami myślnika, a schemat XML używa obudowy wielbłąda.

Ogólnie rzecz biorąc, przekonasz się, że przyjęcie stylu, który wydaje się najbardziej „rodzimy” dla języka, w którym piszesz, jest lepsze niż próba wygrania własnego stylu w każdym innym języku. Ponieważ nie można uniknąć korzystania z bibliotek rodzimych i konstrukcji językowych, Twój styl zostanie „zanieczyszczony” stylem rodzimym, niezależnie od tego, czy ci się to podoba, czy nie, więc nawet próba jest bezcelowa.

Radzę nie znaleźć ulubionego stylu w różnych językach, ale zamiast tego poczuj się jak w domu w każdym języku i naucz się kochać wszystkie jego dziwactwa. Jednym z dziwactw CSS jest to, że słowa kluczowe i identyfikatory są pisane małymi literami i oddzielane myślnikami. Osobiście uważam to za bardzo atrakcyjne wizualnie i myślę, że pasuje do wielkiej litery (choć bez myślnika) HTML .

Być może kluczowy powód, dla którego społeczność HTML / CSS dostosowała się do myślników zamiast podkreślników, jest spowodowana historycznymi brakami w specyfikacjach i implementacjach przeglądarki.

Z dokumentu Mozilli opublikowanego w marcu 2001 r. @ Https://developer.mozilla.org/en-US/docs/Underscores_in_class_and_ID_Names

Specyfikacja CSS1, opublikowana w ostatecznej formie w 1996 r., Nie zezwalała na stosowanie znaków podkreślenia w nazwach klas i ID, chyba że zostały one „usunięte”. Znak ucieczki podkreślenia wyglądałby mniej więcej tak:

    p.urgent\_note {color: maroon;}

Jednak w tym czasie przeglądarki nie były dobrze obsługiwane, a praktyka nigdy się nie przyjęła. CSS2, opublikowany w 1998 r., Również zabronił używania znaków podkreślenia w nazwach klas i identyfikatorów. Jednak errata specyfikacji opublikowanej na początku 2001 r. Po raz pierwszy legalnie uwypukliła podkreślenia. To niestety skomplikowało i tak już złożony krajobraz.

Ogólnie lubię podkreślenia, ale ukośnik sprawia, że ​​jest brzydki ponad wszelką nadzieję, nie wspominając o rzadkim wsparciu w tym czasie. Rozumiem, dlaczego deweloperzy unikali tego jak zarazy. Oczywiście nie potrzebujemy obecnie odwrotnego ukośnika, ale etykieta kreskowa została już mocno ustalona.

Nie sądzę, aby ktokolwiek mógł ostatecznie odpowiedzieć na to pytanie, ale oto moje wykształcone domysły:

1. Podkreślenia wymagają naciśnięcia klawisza Shift i dlatego są trudniejsze do wpisania.

2. Selektory CSS, które są częścią oficjalnej specyfikacji CSS, używają myślników (takich jak pseudoklasy, takie jak: first-child i pseudo-elementy: first-line), a nie podkreślenia. To samo dotyczy właściwości, np. Dekoracji tekstu, koloru tła itp. Programiści są nawykami. Ma sens, aby postępowali zgodnie ze stylem standardu, jeśli nie ma dobrego powodu, aby tego nie robić.

3. Ten jest dalej na półce, ale ... Bez względu na to, czy jest to mit, czy fakt, od dawna istnieje pomysł, że Google traktuje słowa oddzielone podkreśleniami jako pojedyncze słowo, a słowa oddzielone myślnikami jako osobne słowa. (Matt Cutts na podkreślenia vs. kreski.) Z tego powodu wiem, że teraz wolę tworzyć adresy URL stron, używając słów-z-myślnikami, a dla mnie przynajmniej wpisało się to w moje konwencje nazewnictwa dla innych rzeczy , podobnie jak selektory CSS.

Jest wiele powodów, ale jedną z najważniejszych rzeczy jest utrzymanie spójności .

Myślę, że ten artykuł wyjaśnia to kompleksowo.

CSS to składnia rozdzielana łącznikami. Rozumiem przez to napisać takie rzeczy jak font-size, line-height, border-bottomitd.

Więc:

Nie powinieneś mieszać składni: to niespójne .

W ostatnich latach wyraźnie poprawiono segmentowane adresy URL zawierające całe słowa. Zachęcają to najlepsze praktyki SEO. Google wyraźnie „zaleca stosowanie łączników (-) zamiast podkreślników (_) w adresach URL”: http://www.google.com/support/webmasters/bin/answer.py?answer=76329 .

Jak zauważono, różne konwencje obowiązywały w różnych momentach w różnych kontekstach, ale zazwyczaj nie są one formalną częścią żadnego protokołu lub struktury.

Moja hipoteza jest zatem taka, że ​​pozycja Google zakotwicza ten wzorzec w jednym kluczowym kontekście (SEO), a tendencją do używania tego wzorca w nazwach klas, identyfikatorów i atrybutów jest po prostu stado zmierzające powoli w tym ogólnym kierunku.

Myślę, że to zależy od programisty. Niektórzy lubią używać myślników, inni podkreślenia.
Osobiście używam podkreślenia ( _), ponieważ używam go również w innych miejscach. Takie jak:
- zmienne JavaScript ( var my_name);
- Moje działania kontrolera ( public function view_detail)
Innym powodem, dla którego używam podkreślników, jest to, że w większości IDE dwa słowa oddzielone podkreślnikami są uważane za 1 słowo. (i można je wybrać za pomocą double_click).