HTML / CSS 명명 규칙 (구문)에 대한 실제 고려 사항

질문 : 구문 class과 id값 에 대한 실제 고려 사항은 무엇 입니까?

예를 들어이 블로그 포스트에 설명 된 것처럼 의미론 , 즉 사용중인 실제 단어 에 대해서는 묻지 않습니다 . 명명 규칙의 측면에는 이미 많은 리소스가 있습니다. 사실 , 펑크 사용 (특히 대시), 사용하거나 피할 특정 문자 등 다양한 구문 적 비트 에 대한 실제 정보에 대한 검색을 모호하게합니다 .-

이 질문을하는 이유를 요약하면 다음과 같습니다.

• ID 와 클래스 에 대한 이름 제한 은 자연스럽게 어떤 규칙도 초래하지 않습니다
• 명명 규칙의 의미 측면에서 풍부한 자원이 구문상의 고려 사항에 대한 검색을 모호하게합니다.
• 이것에 대한 권위있는 소스를 찾을 수 없습니다
• 이 주제에 대해서는 아직 SE 프로그래머에 대한 질문이 없었습니다. :)

내가 사용하기로 고려한 일부 규칙은 다음과 같습니다.

1. UpperCamelCase주로 서버 측 코딩의 교차 습관으로
2. lowerCamelCaseJavaScript 명명 규칙 과의 일관성을 위해
3. css-style-classesCSS 속성의 이름과 일치하지만 Ctrl + Shift + 화살표 키를 선택하면 성 가실 수 있습니다.
4. with_under_scores개인적으로 많이 보지 못했던
5. alllowercase기억하기 쉽지만 더 긴 이름은 읽기 어려울 수 있습니다
6. UPPERCASEFTW동료 프로그래머를 괴롭히는 좋은 방법으로 (가독성을 위해 옵션 4와 결합했을 수도 있음)

그리고 아마도 중요한 옵션이나 조합도 생략했을 것입니다. 명명 규칙에 대한 고려 사항은 무엇이며 어떤 규칙을 사용합니까?

현상금 여부는 어느 정도 선택이 항상 "선호의 문제"가 될 것입니다. 결국 W3C가 귀하가 느끼지 않은 특정 협약이 권장 (또는 부과) 될 경우 어떻게 느끼겠습니까?

그럼에도 불구하고, 나는 개인적으로 lowerCamelCase협약을 선호하며, 나는 내 마음을 구성하는 데 사용한 이유와 실제적인 고려 사항을 줄 것입니다. 귀하의 질문에서 번호 매기기를 사용하여 제거 과정으로 그렇게 할 것입니다.

(5.) 단어가 시작하고 끝나는 곳을 알지 못하기 때문에 쉽게 읽을 수 있습니다.

(6.) 플러스 인을 좋아하는 사람 처럼요.

(4.) history_incompatibility_plus_see : Mozilla 개발자 문서 .

(3.) 설명하기가 쉽지만 텍스트 편집기에서 선택 가능성은 한 가지 문제 (편집자에 따라 밑줄과 마찬가지로)이지만 나에게도 상기시켜줍니다. 하이픈으로 시작하고 단어로 구분되는 경우에도 공급 업체별 키워드 용으로 예약 된 구문 입니다.

따라서 (1.) 및 (2.), UpperCamelCase 및 lowerCamelCase가 각각 남습니다. Java 클래스에 대한 정신적 연결에도 불구하고 CSS 클래스 이름은 소문자로 시작하는 것이 더 나을 것 같습니다. 아마도 XHTML 요소와 속성 이름 때문일 수도 있지만 CSS 클래스에서 UpperCamelCase를 사용하면 그것들을 구별하는 데 도움이 될 수 있습니다. 다른 이유가 필요하다면, lowerCamelCase는 W3C가 좋은 클래스 이름에 대한 예제 에서 사용하는 것입니다 (URL 자체는 성가 시게도 나와 동의하지 않지만).

위에서 언급 한 이유로 (4.), (5.) 및 (6.)에 대해 조언하고 싶지만 다른 세 가지 중 하나에 대한 주장이 가능하다고 가정합니다.

귀하 (또는 그 문제의 다른 사람)가이 문제에 대해 나와 동의하는지 여부는 귀하에게 달려 있습니다. 권위있는 출처를 인용 하는 확실한 대답을 얻지 못했다는 사실은 이 문제에 대한 명확한 표준과 같은 것이 없다는 힌트로 받아 들일 수 있습니다 (그렇지 않으면 우리 모두 그것을 사용하고 있습니다). 나는 그것이 반드시 나쁜 일인지 확실하지 않습니다.

CSS 클래스 이름의 단어는 대시 ( class-name) 로 분리해야합니다 . CSS 속성과 유사 클래스의 단어 가 분리되고 구문이 CSS specs에 의해 정의되는 방식 입니다.

ID 이름의 단어는 또한 클래스 이름의 구문 스타일과 일치하기 위해 대시로 구분해야하며, ID 이름은 URL에서 자주 사용되며 대시는 URL에서 원래의 가장 일반적인 단어 구분 기호입니다.

그것은 주로 선호의 문제입니다. 권위있는 출처는 물론이 문제에 대한 확립 된 표준은 없습니다. 가장 편안하다고 느끼는 것을 사용하십시오. 일관성을 유지하십시오.

개인적으로을 사용 css-style-with-dashes하지만 여러 단어로 된 클래스 이름을 피하고 가능한 경우 (가 button important default아니라 button-important-default) 여러 클래스를 사용하려고합니다 . 내 경험상, 이것은 고품질 웹 사이트와 프레임 워크 중에서 가장 인기있는 선택 인 것 같습니다.

대시가있는 소문자 nowordseparatorswhatsoever는 Shift 키를 사용할 필요가 없기 때문에 적어도 미국 키보드에서는 다른 옵션 (읽기 어려운 규칙 제외)보다 입력하기가 더 쉽습니다 .

id의 경우 자바 스크립트에서 직접 ID로 요소를 참조하려는 경우 (예 document.forms[0].btn_ok:) 대시가 제대로 작동하지 않지만 jQuery를 사용하는 경우 아마도 $()어쨌든 그것들을 사용하면을 가질 수 있습니다 $('#btn-ok').

기록을 위해, 내가 정기적으로 건너 또 다른 규칙은 특히 폼 컨트롤, 요소의 유형을 표시하는 ID의 헝가리어 사마귀를 사용합니다 - 당신이 가진 것, 그래서 #lblUsername, #tbUsername, #valUsername사용자 이름 라벨, 입력 및 검증합니다.

가장 중요한 것은 일관성입니다.

이것을 보는 두 가지 방법이 있습니다 :

1. 좋은 인수를 위해 할 수 alllowercase또는 css-style-clauses그들이에있을거야 코드와 가장 일치하기 때문에 (아마도 더 나은 선택). 그것은 전체 코드와 아무것도 더 자연스러운 흐름 빌려 것이다 부조화 또는 장소에서한다 .

2. 가독성을 높이는 방식으로 ID와 클래스를 구분할 경우 HTML 태그 이름 또는 CSS 절과 다른 스타일에 대해서도 마찬가지로 좋은 주장을 할 수 있습니다. 당신이 사용하는 경우 예를 들어, UpperCamelCaseID와 클래스, 및 기타 구조 또는 용도로 사용하지 않은, 당신은 당신이 일에 당신이 그 형식의 토큰 보았다 때마다 공격 한 알 것입니다. 이것이 부과 할 수있는 한 가지 제한은 모든 ID 또는 클래스가 2+ 단어 이름 인 경우 가장 효과적 이지만 많은 경우에 합리적이라는 것입니다.

이 답변을 작성하면서 나는 두 번째 선택에 훨씬 더 관심이 있다는 것을 알게되었지만 두 경우 모두 장점이 있다고 생각하기 때문에 둘 다 떠날 것입니다.

그것은 모두 선호의 문제이거나 게으름의 문제입니다. CamelCasing은 입력하기가 쉽지만 CamelCase보다 개인적으로 읽고 디버깅하는 것이 더 쉽다는 것을 알기 때문에 밑줄 표기법을 사용하는 것이 좋습니다. 준수해야 할 코딩 규칙은 하나도 없으며, 이전과 동일한 코딩 지침이있는 곳에서 일한 적이 없습니다.

대부분의 회사에는 일반적으로 모든 사람이 작업하기 쉽게 코드를 깨끗하게 유지하기 위해 어떤 방법을 따라야하는 지침이 있습니다. 프리랜서라면 코드를 작성하는 유일한 사람이므로 모든 것을 처리 할 수 ​​있습니다. 필자의 의견으로는 CamelCase 또는 Underscore 표기법이라는 두 가지 코딩 규칙 만 있습니다. 내 조언은 하나를 고른 다음 고수하는 것입니다.

한 가지 간단한 사실을 잊어 버린 것 같습니다. 대부분의 CSS는 프로그래머가 수행하지 않습니다 .

그래픽 디자이너가 수행합니다.

편집 전쟁에 신경 쓰지 않고 Shift 키로하는 일에 대해서는 신경 쓰지 않았습니다.
그들은 아마도 그 공상 _열쇠가 어디에 있는지 조차 모릅니다 . (또는 그 이름이 무엇인지)

그들은 코드 미학에 관심이없고 미학 미학에 관심이 있습니다.

(그리고 그들은 거기에 포인트가있을 수 있습니다)

그들은 spec을 읽지 않고 튜토리얼을 얻습니다.
그런 다음 w3schools에서 참조를 다시 확인하십시오.

그들 중 일부는 아마도 이유로 인해 대문자 클래스 이름을 사용할 수 없다고 생각합니다.
그들은 이상하고 대부분 관련이없는 오해로 가득합니다.