오늘날 Internet Explorer Box Model 문제 는 대부분 문제 가 아닙니다. 대부분의 웹 개발자는 <!DOCTYPE>
표준 준수를 시행하기 위해 태그를 배치하며 더 이상 Internet Explorer 5.5 지원에 관심이있는 사람은 없습니다.
그러나 일부 개발자 들은 IE 박스 모델을 방어 할 때 주관적이고 개념적 주장을 내놓았습니다. 그들은 W3C 모델 이 박스 의 내용 을 측정하는 반면 IE 모델이 박스 자체를 측정 하기 때문에 IE 박스 모델이 W3C 모델보다 "직관적"이라고 주장했다 .
나는 그들의 관점을 볼 수 있지만 기본적으로 주관적인 주장이며, 가장 중요한 것은 표준 준수입니다.
그러나 최근에는 심각한 실용적인 이유로 IE 박스 모델을 선호하게되었습니다 . W3C 박스 모델은 요소를 다른 요소의 정확한 화면상의 픽셀 너비로 동적으로 크기 조정하는 것을 어렵게합니다. 그 이유는 style.width
요소 의 속성이 요소의 전체 화면 크기를 고려하지 않기 때문입니다. 추가 테두리와 패딩도 고려해야합니다. 두 요소가 모두 동일한 CSS 클래스를 사용하는 경우에는 문제가되지 않지만 서로 다른 CSS 클래스가있는 경우 이는 매우 어려울 수 있습니다.
A와 B라는 두 개의 div가 있다고 가정합니다. A는 HTML에서 400px div로 하드 코딩 된 반면 B는 Javascript를 사용하여 동적으로 생성됩니다. 시각적으로, B는 A의 정확한 너비가되기를 원합니다. 이전 IE Box 모델에서는 사소한 것입니다. 우리는 단순히 말 : B.style.width = A.style.width
, 또는 B.style.width = A.offsetWidth + "px"
.
그러나 W3C 박스 모델에서는 그렇게 간단하지 않습니다. 이제 스타일 시트에 대해서도 걱정해야합니다. B가 A와 동일한 CSS 클래스를 가지고 있다면 말할 수 있습니다 B.style.width = A.style.width
. 그러나 그것이 심미적 인 이유로 원하지 않는다면 -우리는 어려움에 처해 있습니다. 이제 경계와 패딩의 A와 B의 총 픽셀 수를 고려해야합니다. 경계와 패딩이 일치하지 않는 단위로 지정된 경우 (특히 경계는 종종 1px 행이므로 패딩이 일반적 임) ems에 지정 될 수 있습니다). 그런 다음 공통 단위 (em에서 px 또는 px에서 em)로 변환 하는 준 불가능한 작업 에 직면했습니다 . 이 모든 것은 단지 두 개의 div가 화면에 정확하게 정렬되도록합니다.
따라서 기본적으로 W3C 상자 모델은 요소의 크기를 설정할 때 CSS 테두리 및 패딩 문제를 고려해야하지만 너비 는 상자 의 전체 크기 를 측정하기 때문에 IE 상자 모델은 그렇지 않습니다. 상자 의 내용 이 아닌 -end) . 따라서 서로 관련하여 요소의 크기를 훨씬 쉽게 조정할 수 있습니다.
이 모든 것이 W3C 모델보다 IE 박스 모델을 선호하는 꽤 강력한 이유처럼 보입니다 (적어도 개념적으로는 물론 실제로 IE 박스 모델은 죽었습니다).
질문 : W3C가 왜이 박스 모델을 선택 했습니까? 몇 가지가 있습니까 장점 단순히 보이지 않아요하는 W3C 박스 모델은? 아니면 단순히 문제를 과장하고 있습니까?