CSS 선택기 / HTML 속성에 대시가 선호되는 이유는 무엇입니까?

과거 에는 HTML에서 클래스 및 id 속성 을 정의하기 위해 항상 밑줄을 사용 했습니다. 지난 몇 년 동안 나는 대쉬로 바뀌었고, 대부분 나에게 의미가 있었기 때문에 공동체 의 트렌드 와 나 자신을 맞추기 위해 주로 바뀌었다 .

나는 항상 대시에 더 많은 단점이 있다고 생각했지만 이점을 보지 못했습니다.

코드 완성 및 편집

대부분의 편집자는 대시를 단어 구분 기호로 취급하므로 원하는 기호로 이동할 수 없습니다. 클래스가 " featured-product"이고 자동 완성 " featured", 하이픈을 입력하고 " "을 (를) 완료 해야합니다 product.

밑줄이있는 " featured_product"는 한 단어로 취급되므로 한 번에 채울 수 있습니다.

문서 탐색에도 동일하게 적용됩니다. 단어로 점프하거나 클래스 이름을 두 번 클릭하면 하이픈으로 구분됩니다.

(보다 일반적으로 클래스와 ID를 tokens 라고 생각 하므로 하이픈에서 토큰을 쉽게 분리 할 수 ​​있어야한다는 것은 의미가 없습니다.)

산술 연산자를 사용한 모호성

대시를 사용하면 JavaScript에서 양식 요소 에 대한 개체 속성 액세스가 중단 됩니다. 밑줄로만 가능합니다.

form.first_name.value='Stormageddon';

(필자는 분명히이 방법으로 양식 요소에 액세스하지 않지만 보편적 인 규칙으로 대시 대 밑줄을 결정할 때 누군가가 할 수 있다고 생각하십시오.)

Sass (특히 Compass 프레임 워크 전체) 와 같은 언어 는 변수 이름에 대해서도 대시로 표준으로 설정되었습니다. 그들은 처음에도 밑줄을 사용했습니다. 이것이 파싱되었다는 사실은 나를 이상하게 생각합니다.

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

여러 언어에서 변수 이름이 불일치

예전 underscored_names에는 PHP, ruby, HTML / CSS 및 JavaScript로 변수 를 작성 했습니다. 이것은 편리하고 일관되었지만 다시 "적합"하기 위해 사용합니다.

• dash-case HTML / CSS에서
• camelCase JavaScript로
• underscore_case PHP와 루비에서

이것은 실제로 나를 너무 귀찮게하지는 않지만, 왜 이것이 의도적으로 정렬이 잘못되었는지 궁금합니다. 최소한 밑줄로 일관성을 유지할 수있었습니다.

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

이러한 차이 로 인해 버그 가능성과 함께 문자열을 불필요하게 번역 해야하는 상황이 발생 합니다.

그래서 나는 묻습니다. 왜 공동체가 거의 보편적으로 대시에 정착했으며 밑줄보다 중요한 이유가 있습니까?

거기입니다 관련 질문 이 시작 무렵 뒤에서는,하지만 난 그렇지 않은 (또는 의견의이야 안 되었습니다) 취향의 문제. 이 컨벤션이 실제로 맛의 문제라면 왜 우리 모두가이 컨벤션에 정착했는지 이해하고 싶습니다.

코드 완성

대시가 구두점 또는 불투명 식별자로 해석되는지 여부는 선택한 편집기에 따라 다릅니다. 그러나 개인적인 취향으로 CSS 파일의 각 단어 사이를 탭하여 밑줄로 구분하고 정지가 없으면 성가신 것을 알 수 있습니다.

또한 하이픈을 사용하면 텍스트를 포함하는 요소를 선택하고 선택적으로 대시가 오는 | = 속성 선택기를 활용할 수 있습니다 .

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

이렇게하면 다음 HTML 요소가 기울임 꼴로 표시됩니다.

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

산술 연산자를 사용한 모호성

JavaScript에서 점 표기법을 통해 HTML 요소에 액세스하는 것은 기능이 아니라 버그라고 말하고 싶습니다. 끔찍한 JavaScript 구현의 초기부터 끔찍한 구성이며 실제로는 좋은 습관이 아닙니다. 요즘 JavaScript로 수행하는 대부분의 작업에 대해 DOM에서 요소를 가져 오기 위해 CSS 선택기 를 사용하고 싶기 때문에 전체 점 표기법을 다소 쓸모 없게 만듭니다. 어느 것이 더 낫니?

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

특히 '#first-name'JavaScript 변수로 대체하고 동적으로 빌드 할 수 있기 때문에 두 가지 첫 번째 옵션이 훨씬 더 좋습니다 . 나는 또한 그것들이 눈에서 더 즐겁다는 것을 안다.

Sass가 CSS 확장에서 산술을 가능하게한다는 사실은 실제로 CSS 자체에는 적용되지 않지만 Sass가 CSS의 언어 스타일을 따르는 사실을 이해하고 수용합니다 ( $변수 접두사 제외). 있었다 @). Sass 문서가 CSS 문서처럼 보이고 느껴지려면 대시를 구분 기호로 사용하는 CSS와 동일한 스타일을 따라야합니다. CSS3에서 산술은 calc함수 로 제한 되어 CSS 자체에서는 문제가되지 않음을 보여줍니다.

여러 언어에서 변수 이름이 불일치

마크 업 언어, 프로그래밍 언어, 스타일링 언어 또는 스크립팅 언어 인 모든 언어는 고유 한 스타일을 갖습니다. 예를 들어 XSLT 는 하이픈 구분 기호로 소문자를 사용 하고 XML 스키마 는 낙타 케이싱을 사용하는 XML 과 같은 언어 그룹의 하위 언어 내에서이 기능을 찾을 수 있습니다 .

일반적으로, 쓰고있는 언어에 가장 "느슨한"느낌을주는 스타일을 채택하는 것이 모든 다른 언어로 자신 만의 스타일을 만들어내는 것보다 낫다는 것을 알게 될 것입니다. 네이티브 라이브러리와 언어 구조를 사용하지 않아도되기 때문에 원하는 스타일에 상관없이 스타일이 기본 스타일에 의해 "오염"되므로 시도하는 것도 무의미합니다.

저의 조언은 여러 언어 중에서 좋아하는 스타일을 찾는 것이 아니라 각 언어 내에서 집에서 자신의 모든 특징을 사랑하는 법을 배우는 것입니다. CSS의 단점 중 하나는 키워드와 식별자가 소문자로 작성되고 하이픈으로 구분된다는 것입니다. 개인적으로, 나는 이것이 매우 시각적으로 매력적이며 모든 소문자 (하이픈은 없지만) HTML에 적합하다고 생각합니다 .

아마도 HTML / CSS 커뮤니티가 밑줄 대신 대시로 정렬 된 주요 이유는 사양 및 브라우저 구현의 역사적 결함 때문일 것입니다.

2001 년 3 월에 게시 된 Mozilla 문서에서 https://developer.mozilla.org/en-US/docs/Underscores_in_class_and_ID_Names

1996 년에 최종 형태로 출판 된 CSS1 규격은 "탈출"되지 않은 한 클래스 및 ID 이름에 밑줄을 사용할 수 없었습니다. 이스케이프 된 밑줄은 다음과 같습니다.

    p.urgent\_note {color: maroon;}

그러나 당시에는 브라우저에서이 기능을 제대로 지원하지 않았기 때문에 실제로 적용되지 않았습니다. 1998 년에 출판 된 CSS2는 또한 클래스 및 ID 이름에 밑줄을 사용하는 것을 금지했습니다. 그러나 2001 년 초에 발표 된 사양의 정오표는 처음으로 밑줄을 합법화했습니다. 불행히도 이미 복잡한 지형이 복잡했습니다.

나는 일반적으로 밑줄을 좋아하지만 백 슬래시는 그 당시에 거의 지원을 언급하지 않고 희망을 넘어 추한 것으로 만듭니다. 개발자가 전염병처럼 피하는 이유를 이해할 수 있습니다. 물론 요즘에는 백 슬래시가 필요하지 않지만 대시 에티켓은 이미 확고하게 설정되었습니다.

나는 아무도 이것에 대해 확실하게 대답 할 수 없다고 생각하지만, 여기 내 교육받은 추측이 있습니다.

1. 밑줄은 Shift 키를 눌러야하므로 입력하기가 더 어렵습니다.

2. 공식 CSS 사양의 일부인 CSS 선택기는 밑줄이 아닌 대시 (예 : : first-child 및 pseudo-elements : first-line과 같은 유사 클래스)를 사용합니다. 텍스트 장식, 배경색 등과 같은 속성에 대해서도 마찬가지입니다. 프로그래머는 습관의 생물입니다. 합당한 이유가 없다면 표준 스타일을 따르는 것이 합리적입니다.

3. 이것은 난간에 더 있지만, ... 신화이든 사실이든, 구글은 밑줄로 분리 된 단어를 단일 단어로, 대시로 분리 된 단어를 별도의 단어로 취급한다는 오랜 아이디어가 있습니다. (밑줄과 대쉬에 대한 매트 컷츠) 이러한 이유로, 페이지 URL을 작성하는 데 선호하는 것은 대시와 함께 단어를 사용하는 것이며, 나에게는 적어도 다른 것들에 대한 이름 지정 규칙에 빠졌습니다. CSS 선택기처럼

여러 가지 이유가 있지만 가장 중요한 것은 일관성을 유지하는 것입니다 .

나는 이 기사가 그것을 포괄적으로 설명 한다고 생각 합니다 .

CSS는 하이픈으로 구분 된 구문입니다. 이것에 의하여 나는 우리가 같은 것들을 쓰는 말은 font-size, line-height, border-bottom등

그래서:

구문을 섞어서는 안됩니다 . 일관성이 없습니다 .

최근 몇 년 동안 하이픈으로 구분 된 전체 단어 세그먼트 URL이 눈에 띄게 증가했습니다. 이것은 SEO 모범 사례에 의해 장려됩니다. - 구글은 명시 적으로 "당신의 URL 대신 밑줄 (_)의 ()는 하이픈을 사용하는 것이 좋습니다" http://www.google.com/support/webmasters/bin/answer.py?answer=76329 .

언급 된 바와 같이, 상이한 컨벤션이 상이한 상황에서 상이한 시간에 우세했지만, 일반적으로 프로토콜 또는 프레임 워크의 공식적인 부분은 아니다.

따라서 내 가설은 Google의 위치가이 패턴을 하나의 주요 컨텍스트 (SEO) 내에 고정 시키며 클래스, id 및 속성 이름에이 패턴을 사용하는 경향은이 일반적인 방향으로 천천히 움직이는 무리 일 뿐이라는 것입니다.

프로그래머 의존적이라고 생각합니다. 어떤 사람들은 대시를 사용하고 다른 사람들은 밑줄을 사용합니다. 다른 곳에서도
밑줄 ( _)을 사용하기 때문에 개인적으로 밑줄 ( )을 사용합니다. -JavaScript
변수 ( var my_name);
-내 컨트롤러 작업 ( public function view_detail)
밑줄을 사용하는 또 다른 이유는 대부분의 IDE에서 밑줄로 구분 된 두 단어가 1 단어로 간주되기 때문입니다. (double_click로 선택할 수 있습니다).