전국에 '재건축'의 봄바람이 불고 있고, 인터넷은 한동안 혼란에 빠졌습니다. 'div+CSS'는 이미 '패션'이 되었습니다. 하지만 이런 다양한 웹사이트의 소스코드를 공개하면 사람들이 웃기는 경우가 많습니다——
6~7개의 중첩 레이어가 있는 div 레이아웃, 테이블이 없는 테이블, 순수한 div+a로 구성된 페이지, 수백 개의 프레젠테이션 레이어 클래스 등이 있습니다. 요즘에는 광고하는 몇 권의 책을 제외하고 표준에 관한 책이 점점 더 많아지고 있습니다. "고급 기술", 책의 처음 몇 장에서 "구조와 표현의 분리"라는 문장을 강조하지 않는 사람은 거의 없습니다. 그러나 이 책의 처음 몇 장을 진지하게 읽은 독자는 몇 명이나 됩니까? 아니면 지루한 구조 설명을 건너뛰고 고급스러워 보이는 레이아웃 기술과 해킹에 대해 알아보고 싶으신가요?
사실 div+CSS라는 용어는 처음부터 너무 많은 사람들을 오해하게 만들었고, 빠른 성공을 열망하는 사고방식이 이러한 현상의 주범입니다. 테이블 레이아웃 웹페이지 제작에 익숙한 사람이 표준을 접하기 위한 첫 번째 단계는 다양한 레이아웃을 구현하기 위해 무작정 CSS 기술을 구하는 것이 아니라, 자신의 사고 방식을 바꾸기 위해 노력하는 것입니다.
아래에서는 개인적인 경험을 바탕으로 표준을 준수하는 사고방식에 대해 이야기하겠습니다. 그 중 많은 부분이 표준을 이제 막 접한 XDJM들에게 도움이 되기를 바랍니다.
1. “코드 저장”은 목적이 아닌 마케팅 도구입니다.
"div 레이아웃을 사용하면 테이블 레이아웃보다 더 많은 코드를 절약할 수 있습니다."라는 문장을 많은 책과 웹사이트에서 본 적이 있습니다. 이 문장 자체는 맞습니다. "코드를 저장하는 것"은 실제로 웹 페이지 표준화의 이점 중 하나입니다. 그러나 그것은 "유일한 이익"이 아닌 "이익 중 하나"일 뿐이며, 목적도 아니라는 점을 기억하시기 바랍니다. "코드 저장"은 완고한 상사를 설득하기 위해 사용하는 마케팅 전략인 경우가 많습니다. 웹페이지 표준화의 유일한 목적은 "구조와 성능의 분리"이며, 결코 코드를 저장하기 위해 코드를 저장하는 것이 아닙니다. 사이드바와 심지어 웹사이트의 주요 콘텐츠까지 동일한 프리젠테이션 형식을 갖고 있기 때문에 통합 클래스를 사용한 적이 있습니다(아직도 이를 가르치는 책이 있습니다). 이는 ID를 별도로 명명하는 것보다 실제로 코드를 더 절약해 줍니다. 이는 코드의 품질이 떨어진다는 것입니다. 좋은 구조를 잃으면 다음과 같은 결과가 발생합니다. 1. 소스 코드를 더 이상 읽을 수 없습니다. 2. 웹 사이트는 알 수 없는 유지 관리 비용을 증가시킵니다. 링크 색상 등과 같은 필요에 따라 특정 콘텐츠의 표시가 변경되면 페이지 소스 파일을 수정하고 추가 클래스를 추가해야 하며 작업량은 단순히 ID를 조정하는 것보다 훨씬 큽니다. 그룹화. 그리고 이대로 가면 구조가 점점 더 악화되어 되돌리기 어려운 악순환이 형성될 것이다.
ID 이름을 지정할 때 발생하는 또 다른 상황이 있는데, 이 역시 제가 저지른 실수입니다. 당시에는 '코드 저장'을 위해 메인 메뉴 이름을 'mm', 보조 메뉴 이름을 'm2', 3차 메뉴 이름을 'm3'으로 정했다. 웹페이지가 심각하게 줄어들어 다른 동료들이 대신하기 어려워졌고, 문제를 해결하려고 노력했지만 나 자신도 피곤했습니다. 마찬가지로 파일이나 폴더의 이름도 지나치게 단순화하는 것은 바람직하지 않습니다. 예를 들어 "Website Reconstruction"에서는 모든 이미지를 "i" 디렉터리에 저장할 것을 권장합니다. 매우 축약된 디렉토리 구조입니다. 자세히 설명하고 다른 생산 직원, 개발자, 심지어 지식이 풍부한 상사까지 포함하여 관련된 모든 사람이 이를 이해하고 구현할 수 있는지 확인하십시오. 그렇지 않으면 불필요한 문제만 추가될 뿐입니다.
2. 아이디는 저격총, 클래스는 양날의 검
좋은 웹 페이지 구조를 가지려면 ID와 클래스를 모두 능숙하게 마스터해야 합니다. 소위 "두 손으로 쥐기, 두 손이 강해야 합니다". ID는 스타일을 로드하려는 요소를 정확하게 찾는 데 도움이 되는 저격총과 같으며, 클래스는 손끝에서 더 가볍고 유연한 기사의 검과 같습니다. 그리고 풍부한 성능. 그러나 이제 ID가 클래스로 완전히 대체될 수 있다는 잘못된 견해가 있습니다. 실제로 이는 전체 클래스를 열면 ID를 찾을 수 없는 경우가 많습니다. 이러한 현상에는 여러 가지 이유가 있지만, 테이블 시대부터 이어져 온 뿌리 깊은 "class=CSS" 개념이 근본 원인이다. 클래스가 id보다 더 다양하고 유연한 것은 사실이지만 좋은 웹 페이지 구조를 구축하는 데에는 클래스가 id보다 훨씬 덜 효과적이라는 점도 깨달아야 합니다. id의 필수 고유성 덕분에 id를 통해 필요한 모듈을 쉽게 검색할 수 있지만 클래스에는 이러한 이점이 없습니다. 모듈에 대해 고유한 클래스 이름을 정의할 수 있지만 전제는 생산자 자신만이 웹 페이지 스타일을 변경할 수 있다는 것입니다. 그렇지 않으면 약간 게으른 사람을 찾아보자. 그는 이전 클래스를 직접 적용할 것이다. 그 결과 우리는 웹 페이지에 "gonggao" 또는 "xinwen"이라는 모듈이 12개 이상 있음을 발견했다. ", 그래서 구별하기가 어렵습니다. HTML 주석을 많이 추가하지 않으면 이 결과는 분명히 우리가 원하는 결과가 아닙니다. 게다가 앞서 언급했듯이 유니버설 클래스를 통해 저장한 코드는 개별적으로 정의된 클래스마다 낭비되어야 한다.
ID는 저격총이고, 클래스는 양날의 검입니다. 함께라면 둘 다 이익을 얻고, 떨어져 있으면 둘 다 패배합니다.
3. 모든 콘텐츠에 div가 "컨테이너"로 필요한 것은 아닙니다.
메인 메뉴에 <div id="mainnav"><ul> 또는 <ul id="mainnav">를 사용해야 합니까? 이것은 게임 문제입니다. 지금까지 이 질문에 대해 명쾌한 답을 줄 수 있는 사람은 아무도 없으며 심지어 나 자신도 마찬가지다. <div id="mainnav">에 <ul> 요소가 하나만 포함되어 있으면 이 div가 약간 중복되는 것처럼 보이지만 때로는 멋진 디자인과 일치시키기 위해 태그 레이어가 하나 더 있으면 변경 사항이 하나 더 있다는 의미입니다. 어떤 사람들은 a 태그에 span을 사용하기도 합니다.) 원래 속성이 없는 div의 고유한 이점은 다른 태그와 비교할 수 없습니다. 나는 이 제안으로 한 가지만 설명하고 싶습니다. 즉, <div id="mainnav"><ul> 외에도 <ul id="mainnav"> 이러한 작성 방법이 있다는 것을 깨달아야 한다는 것입니다. 또한 좋은 구조와 의미를 가지며 중첩 레이어를 제거합니다. 화려한 예술에 대해 걱정할 필요가 없을 때 구조를 더 단순하게 만들 수도 있을까요?
이 제안은 실제로 "모든 콘텐츠에 컨테이너로서 블록 요소가 필요한 것은 아닙니다" 및 "모든 링크에 컨테이너로서 다른 요소가 필요한 것은 아닙니다"(예: 많은 페이지에 있는 "더 보기")로 확장될 수 있습니다. "<div class="more"><a>"라고 쓰는 사람도 있고 <p><a> 또는 <strong><a>라고 쓰는 사람도 있습니다. 이러한 "컨테이너"에 <a> 태그만 포함되어 있는 경우에도 여전히 존재해야 합니까? 직접 쓰면<a class="more">구조가 깨질까요? 의미론이 부족할까요? 레이아웃에 영향을 미칠까요? 다르게 생각하면 다른 것을 얻을 수도 있습니다.
4. 직장에서 '구조와 성과의 분리'를 실현한다
이에 대해 인터넷의 많은 전문가들은 먼저 에디터를 열고 구조를 완전히 작성한 다음 CSS로 가서 성능을 작성하고 이미 작성된 구조를 건드리지 않도록 노력하는 것을 제안합니다.
그러나 대부분의 표준 서적은 단계별로 가르치기 때문에 책 읽기를 주요 학습 방법으로 사용하는 사람들은 이해하기 어렵습니다. 즉, 구조와 표현을 단계별로 결합해야 함을 의미합니다. 일부 책에는 이와 관련하여 제안이 있지만 몇 가지 짧은 문장은 읽는 과정에서 미묘한 효과보다 훨씬 열등합니다. 제작진이 구조를 잘 파악할 수 있다면, 글쓰기 구조와 퍼포먼스가 동시에 결과에 큰 영향을 미치지 않을 것입니다. 하지만 내 경험에 따르면 구조와 표현을 동시에 작성하는 것보다 구조와 표현을 분리하는 작업 방식이 훨씬 효율적입니다. 동시에 페이지의 요소를 놓치기도 쉽지 않습니다.
물론 소위 "구조와 성능의 분리"가 성능을 완전히 무시한다는 의미는 아닙니다. 성능을 고려하려면 CSS 선택기가 구조를 파괴하지 않고 최대한 많은 콘텐츠를 선택할 수 있도록 해야 합니다. . 클래스를 어디에 추가할지, 클래스를 구별하기 위해 어떤 라벨을 사용할지는 각자의 경험이 있다고 생각합니다. 서로 다른 디자인 초안을 결합하면 때로는 이에 상응하는 변경이 필요합니다. 그러나 이러한 변경은 모두 동일한 전제를 가져야 합니다. 즉, 코드의 구조와 가독성을 파괴하지 않아야 합니다.
더욱이 우리는 모든 시각적 도구는 악마라는 사실을 깨달아야 합니다. 시각적 인터페이스에 나타나는 효과는 실제 브라우저의 효과와 수천 마일 떨어진 경우가 많습니다. 우리가 실제로 호환되기를 원하는 것은 편집기의 시각적 인터페이스가 아니라 브라우저입니다.
5. CSS는 만병통치약이 아니며 CSS 없이 살아가는 것이 불가능하지 않습니다.
CSS1.0 시대에 비해 오늘날 CSS는 더 많은 일을 할 수 있습니다. 그러나 수요는 항상 기술보다 앞서 있습니다. CSS는 때때로 웹 페이지의 모든 프레젠테이션 레이어 작업을 완료할 수 없습니다. 때로는 일부 효과를 얻기 위해 JS나 다른 언어를 결합해야 합니다. . 어떤 경우에는 JS를 사용하는 것이 CSS에만 의존하는 것보다 훨씬 간단하고 코드가 더 잘 구조화되어 있습니다. 가장 일반적인 예는 드롭다운 메뉴입니다. 이럴 때 우리는 더 간단하고 합리적인 방법을 사용하도록 우리 자신이나 상사, 고객을 설득해야 합니다. DOM은 웹페이지 표준의 중요한 구성요소이기도 하기 때문에 JS를 사용한다고 해서 웹페이지의 효율성이 떨어지거나 더 이상 표준이 아니라는 의미는 아닙니다. 오히려 이것이 JS에 대한 가장 큰 오해입니다. 이렇게 말하지만, 오늘날의 모든 직업은 그 어느 때보다 관련 지식이 필요하다는 점을 말씀드리고 싶습니다. 디자인을 하는 사람은 인터랙션과 프로덕션에 대해 조금 알아야 하고, 프로덕션을 하는 사람은 디자인과 프로그래밍도 이해해야 합니다. , 특히 JS와 같은 프런트 엔드 기술을 사용하면 이러한 방식으로만 귀하와 동료가 더 잘 협력할 수 있으며 개인 개발 전망이 더 밝아질 것입니다.
CSS 없음은 알 수 없는 여러 가지 이유로 웹사이트에서 CSS 파일을 로드하지 못하는 경우를 의미합니다. 이 때문에 당황하지 마세요. 지금이 코드 품질을 테스트하기에 가장 좋은 시기입니다. 웹페이지가 CSS 없이도 여전히 좋은 가독성을 유지한다면, 이 성과는 W3C 인증을 통과하는 것보다 훨씬 더 자랑스럽습니다.