경험에서 말씀드리자면! Div+CSS 웹페이지 제작에 대한 오해 해석

전국에 '재건축'의 봄바람이 불고 있고, 인터넷은 한동안 혼란에 빠졌습니다. '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가 "컨테이너"로 필요한 것은 아닙니다.

메인 메뉴에