의미론에 대하여
의미론은 기호와 상징의 관계와 그것이 나타내는 의미를 연구합니다. 언어학에서는 언어의 상징(단어, 구, 소리 등)의 의미를 연구합니다. 프런트 엔드 개발 분야에서 의미론은 주로 HTML 요소, 속성 및 속성 값(마이크로데이터와 같은 확장 포함)의 합의된 의미를 포함합니다. 사양에 일반적으로 사용되는 이러한 공식 규칙 의미는 프로그램(및 나중에 개발에 참여하는 사람들)이 웹 사이트의 모든 측면을 더 잘 이해하는 데 도움이 될 수 있습니다. 그러나 이러한 요소, 속성, 속성값의 의미가 형식화되더라도 여전히 개발자의 적응과 집단적 선택의 대상이 됩니다. 이는 공식적인 계약 의미가 미래에 수정될 수 있음을 가능하게 합니다(그리고 이는 HTML 디자인 원칙 중 하나입니다).
다양한 유형의 HTML 의미 체계 구별
"의미론적 HTML" 작성 원칙을 고수하는 것은 현대 전문 프론트엔드 개발의 기초 중 하나입니다. 대부분의 의미론은 콘텐츠의 현재 또는 예상되는 특성(예: h1 요소, lang 속성, 유형 속성의 이메일 값, 마이크로데이터)과 관련됩니다.
그러나 모든 의미론이 콘텐츠 지향적일 필요는 없습니다. 클래스 이름은 "의미론적"일 수 없습니다. 이름이 무엇이든 의미와 목적이 있어야 합니다. 클래스 이름의 의미는 HTML 요소의 의미와 다를 수 있습니다. 우리는 HTML 요소, 특정 HTML 속성, 마이크로데이터 등의 "글로벌" 의미를 사용할 수 있으며, 그런 다음 웹사이트나 애플리케이션의 "로컬" 특정 의미를 사용하여 구별할 수 있습니다. 이러한 특정 의미는 일반적으로 다음과 같은 속성 값에 포함됩니다. 클래스 속성 .
이러한 "모범 사례"가 HTML5 사양의 클래스 속성 섹션에서 반복되어 있지만...
...개발자가 표시될 것으로 예상되는 콘텐츠를 설명하는 대신 클래스 속성 값을 사용하여 실제 콘텐츠를 설명하도록 권장합니다.
…이렇게 할 본질적인 이유는 없습니다. 실제로 대규모 웹사이트나 애플리케이션에서 이 접근 방식을 사용하면 종종 방해가 될 수 있습니다.
HTML 요소 및 기타 속성은 이미 콘텐츠 수준 의미를 제공합니다.
컴퓨터나 방문자의 경우 클래스 이름은 유용한 의미 정보를 거의 또는 전혀 나타내지 않습니다. 합의된 이름의 작은 부분이 아닌 한(기계 판독 가능) - Mircoformats
클래스 이름의 주요 목적은 CSS 및 JavaScript에 대한 연결이 되는 것입니다. 페이지에 프리젠테이션과 동작을 추가할 필요가 없다면 HTML에 클래스 이름
을 추가할 필요가 없을 것입니다. 클래스 이름은 개발자에게 유용한 정보를 전달해야 합니다. DOM 조각을 읽으면 특정 클래스 이름의 구체적인 목적을 이해하는 데 도움이 됩니다. 특히 여러 사람으로 구성된 개발팀에서는 프론트엔드 개발자만이 HTML 구성요소를 다루는 것은 아닙니다.
아주 간단한 예를 들어보세요.
반명뉴스는 내용이 명확하지 않으면 아무 것도 알려줄 수 없습니다. 이는 구성 요소의 전체 구조에 대한 정보를 제공하지 않으며 내용이 더 이상 "뉴스"가 아닌 경우 이 클래스 이름을 사용하는 것은 매우 부적절해 보입니다. 클래스 이름의 의미가 내용과 너무 가깝고 아키텍처가 확장하기 쉽지 않고 다른 개발자가 사용하기도 쉽지 않습니다.
콘텐츠 독립적인 클래스 이름
디자인 패턴의 구조와 기능에서 클래스 이름의 의미를 추출하는 것이 더 나은 접근 방식입니다. 클래스 이름이 내용과 관련이 없는 구성 요소는 재사용성이 더 높습니다.
명확한 내용을 엄격하게 반영하기 위해 클래스 이름을 사용하기보다는 각 레이어 간의 관계를 명확하고 모호하지 않게 만드는 것을 두려워해서는 안 됩니다(구조 레이어, 콘텐츠 레이어 등을 참조해야 함, 번역자 주). 이렇게 한다고 해서 클래스 이름이 "의미론적"이 되는 것은 아니며 단지 해당 의미론이 내용에 의존하지 않는다는 것을 보여줄 뿐입니다. 또한 더 강력하고 유연하며 재사용 가능한 구성 요소를 만드는 데 도움이 되는 한 추가 HTML 요소를 사용하는 것을 두려워해서는 안 됩니다. 그렇게 한다고 해서 HTML이 "의미론적"이 되는 것은 아니며 단지 최소 요소 수 이상을 사용하여 콘텐츠를 마크업한다는 의미일 뿐입니다.
프런트엔드 아키텍처
구성 요소, 템플릿 및 객체 지향 아키텍처의 목적은 특정 범위 내에서 다양한 콘텐츠 유형을 포함할 수 있는 제한된 수의 재사용 가능한 구성 요소를 개발할 수 있도록 하는 것입니다. 대규모 애플리케이션에서 클래스 이름 의미론에 대한 가장 중요한 점은 실용주의를 바탕으로 기본 목적을 수행한다는 것입니다. 즉, 개발 또는 사용을 위한 의미 있고 유연하며 재사용 가능한 성능 또는 동작 후크를 제공합니다.
재사용 및 구성 가능한 구성요소
일반적으로 확장 가능한 HTML/CSS는 재사용 가능한 구성 요소를 생성하기 위해 HTML의 클래스에 의존해야 합니다. DOM 트리의 특정 부분에 의존하지도 않고 특정 유형의 요소를 사용하지도 않는 유연하고 재사용 가능한 구성 요소입니다. 다양한 컨테이너에 적용할 수 있어야 하며 테마를 쉽게 변경할 수 있어야 합니다. 필요한 경우 콘텐츠를 마크업하는 데 필요한 요소 외에 추가 HTML 요소를 사용하여 구성 요소를 더욱 강력하게 만들 수 있습니다. Nicole Sullivan의 미디어 개체가 좋은 예입니다.
클래스를 지원하기 위해 유형 선택기를 사용하지 않으면 구성 요소를 더 쉽게 병합할 수 있습니다. 다음 예에서 btn 구성 요소와 uilist 구성 요소는 병합하기 쉽지 않습니다. 문제는 .btn이 .uilist a보다 가중치가 작다는 것입니다(이것은 모든 공유 속성을 무시합니다). 그리고 ulist 구성 요소에는 하위 노드로 앵커 포인트가 필요합니다.
uilist 구성 요소를 다른 구성 요소와 쉽게 결합하는 한 가지 방법은 클래스를 사용하여 uilist의 하위 DOM 요소에 스타일을 추가하는 것입니다. 이렇게 하면 무게가 줄어들지만 주요 이점은 하위 노드의 구조적 스타일을 처리할 수 있는 옵션을 제공한다는 것입니다.
JavaScript 전용 클래스
어떤 형태로든 JavaScript 전용 클래스를 사용하면 구성 요소 스타일이나 구조 변경으로 인해 JavaScript가 실패할 위험을 줄일 수 있습니다. 내가 찾은 매우 효과적인 방법은 JavaScript 후크에만 특정 클래스(js-*)를 사용하고 클래스 이름에 설명을 추가하지 않는 것입니다.
구성 요소의 구조나 스타일을 수정하면 필요한 JavaScript 동작과 복잡한 기능에 의도치 않게 영향을 미칠 수 있습니다. 이 방법을 사용하면 가능성을 줄일 수 있습니다.
구성요소 수정자
구성 요소에는 기본 구성 요소와 약간만 다른 변형이 있는 경우가 많습니다. 예를 들어 배경색이나 테두리가 다릅니다. 이러한 구성 요소의 변형을 만드는 데는 두 가지 주요 모드가 있습니다. 나는 이를 "단일 클래스 이름" 패턴과 "다중 클래스 이름" 패턴이라고 부릅니다.
단일 클래스 이름 패턴
여러 클래스 이름 패턴
전처리기를 사용하는 경우 Sass의 @extend 기능을 사용하면 "단일 클래스 이름" 패턴을 사용할 때 관련된 유지 관리 작업을 일부 줄일 수 있습니다. 그러나 전처리기의 도움에도 불구하고 나는 여전히 "다중 클래스 이름" 모드를 사용하고 HTML에서 클래스 이름을 수정하는 것을 선호합니다.
저는 이것이 더 확장 가능한 패턴이라고 생각합니다. 예를 들어 기본 btn 구성 요소를 구현하고 5가지 유형의 버튼과 3가지 추가 크기를 추가하려고 합니다. "다중 클래스 이름" 모드를 사용하면 9개의 클래스만 필요하고, "단일 클래스 이름" 모드를 사용하면 24개의 클래스만 필요합니다.
또한 필요한 경우 구성 요소에 맞게 컨텍스트를 조정하는 것이 더 쉬워집니다. 다른 구성 요소에 나타나는 btn을 세부적으로 조정하고 싶을 수도 있습니다.
"다중 클래스 이름" 모드는 모든 유형의 btn 요소 스타일을 변경하려면 단일 내부 구성 요소 선택기만 사용해야 함을 의미합니다. "단일 클래스 이름" 패턴은 새 버튼 변형을 만들 때 가능한 모든 버튼 유형을 고려하고 선택기를 조정해야 함을 의미합니다.
구조화된 클래스 이름
구성 요소를 생성하고 여기에 "테마"를 추가하면 일부 클래스는 각 구성 요소를 구별하는 데 사용되고 일부 클래스는 구성 요소의 수정자로 사용되며 다른 클래스는 DOM 노드를 연결하는 데 사용됩니다. 더 큰 추상 구성 요소 내에 포함되어 있습니다.
btn(컴포넌트), btn-primary(수식자), brn-group(컴포넌트), btn-group-item(컴포넌트 하위 개체) 사이의 이름이 명확하지 않아 관계를 판단하기 어렵습니다. 수업의. 일관된 패턴이 없습니다.
지난 1년 동안 저는 HTML, CSS, JS 파일을 서로 전환하지 않고도 DOM 조각의 노드 표현 간의 관계를 빠르게 이해할 수 있도록 명명 패턴을 실험해 왔습니다. 웹사이트의 구조. 이 패턴은 BEM 시스템의 명명 접근 방식에 크게 영향을 받았지만 탐색하기 더 쉬운 형식으로 조정되었습니다.
컴포넌트 이름
컴포넌트 이름--수정자 이름
컴포넌트 이름__하위 개체
컴포넌트 이름__하위 개체--수정자 이름
상태-유형
js-액션-이름
js-구성요소 유형
저는 일부 구조를 추상적인 "템플릿"으로 취급하고 다른 구조를 더 명확한 구성 요소(종종 "템플릿"을 기반으로 구축됨)로 취급합니다. 그러나 이러한 구별이 항상 필요한 것은 아닙니다.
이것은 지금까지 유용하다고 생각한 명명 패턴 중 하나일 뿐입니다. 명명 패턴은 어떤 형식이든 취할 수 있습니다. 그러나 이 명명 패턴의 장점은 모호한 클래스 이름을 제거하고 (단일) 커넥터, 밑줄 또는 낙타 대문자 형식에만 의존한다는 것입니다.
Raw 파일 크기 및 HTTP 압축에 대한 참고 사항
모듈식 및 확장 가능한 CSS에 대한 논의에는 파일 크기 및 '부풀림'에 대한 우려가 포함됩니다. Nicole Sullivan의 발언에서는 Facebook과 같은 회사가 이 접근 방식을 채택한 경험을 인용하면서 파일 크기 저장(및 유지 관리 개선)에 대해 자주 언급합니다. 한 단계 더 나아가서, 출력 전처리에서 얻은 HTTP 압축 효과 중 일부와 HTML 클래스의 과도한 사용을 공유하고 싶다고 생각했습니다.
Twitter Bootstrap이 처음 나왔을 때 수동으로 조작한 파일과 크기를 더 잘 비교하기 위해 컴파일된 CSS를 다시 작성했습니다. 모든 파일을 최소화한 후 수동으로 조작한 CSS 파일은 전처리기 출력보다 10% 더 작았습니다. 그러나 모든 파일을 gzip으로 압축하면 전처리기에서 출력되는 CSS 파일이 수동 작업보다 5% 더 작아집니다.
파일 크기가 줄어든다고 전체 내용을 알 수는 없으므로 HTTP 압축 후 파일 크기를 비교하는 것이 중요하다는 점을 강조합니다. 이는 전처리기를 사용하는 숙련된 CSS 개발자가 컴파일된 CSS의 어느 정도 중복에 대해 너무 걱정해서는 안 된다는 것을 의미합니다. HTTP 압축 후에 CSS가 작아지기 때문입니다. 전처리기를 통해 보다 유지 관리하기 쉬운 CSS 코드를 처리하는 이점은 원시 CSS 및 축소된 출력 CSS의 미적 측면이나 파일 크기에 대한 우려보다 큽니다.
또 다른 실험에서는 인터넷에서 60KB HTML 파일(재사용 가능한 여러 구성 요소로 구성됨)을 스크랩하고 각 클래스 속성을 삭제했습니다. 이 처리 후에는 파일 크기가 25KB로 줄어듭니다. 원본 파일과 추출된 파일을 모두 gzip으로 압축하면 크기는 각각 7.6KB와 6KB가 되어 불과 1.6KB의 차이가 납니다. 자유로운 클래스 사용으로 인한 실제 파일 크기 결과는 더 이상 강조할 가치가 없습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
