가지고 놀다 보면 우스운 것이, CSS 2 표준은 하나인데, 브라우저마다 지원하는 방식이 모두 다른 것이다. IE와 gecko와 opera가 전부 다른 방식으로 CSS를 해석하다 보니 결국 내 시간의 대부분은 '모든 브라우저에서 동일하게 보이려면 어떻게 해야하는지' 의 문제로 귀착되었다.
이야기하자면 한이 없지만, 디자인상 가장 컸던 문제점들을 들자면
1. padding과 margin을 취급하는 방법이 다르다.
이건 희한하게 달라서 이야기하기가 애매하다. 굳이 간단하게 표현하자면, div 개체에 background 속성을 주면 IE는 padding과 margin을 제외한 개체 자체에 속성이 먹히고, gecko 엔진은 padding의 범위까지 속성이 먹힌다. 별것 아닌거 같이 생각이 될 수 있는데 이것이 무지하게 문제가 되는 것이 그림 배경을 지정할 경우이다. 그림 배경을 지정할 경우 충격적인 차이를 경험할 수 있다.
그리고 그 안에 텍스트를 입력할 경우 두 번째 충격을 받을 수가 있다. 텍스트의 위치를 지정하기 위하여 상위 div 개체에 padding 속성을 넣은 경우에 Firefox와 IE는 완전히 다른 모습을 보여줄 것이다. 브라우저간 차이를 해결하기 위해서는 상위 개체에 padding을 사용하지 않고, 텍스트에 padding 속성을 따로 주는 방법이 유일해 보인다. (이걸 생각해내느라 세시간이 걸렸다.)
2. absolute, relative, float를 취급하는 방법이 다르다
각 div의 위치 속성을 지정하기 위한 방법으로 사용하는 저 명령어들이 브라우저마다 작동이 다르다. 오페라의 경우는 %로 지정할 경우 스크롤바 부분을 포함해서 작동한다. float의 경우에 gecko 엔진은 내용이 없을 경우 해당 div의 속성을 무시한 채 다음 relative 명령에 따라 위치를 지정한다. IE의 경우에는 다중 div 속성 상속을 할 경우, 해당되는 개체가 상속받은 개체라는 것을 인식하지 못하는 경우가 있다. 가장 문제는, 저런 문제들이 모여 CSS만을 이용해서 페이지 레이아웃을 만들기가 꽤나 애매해진다는 점이다.
이건 희한하게 달라서 이야기하기가 애매하다. 굳이 간단하게 표현하자면, div 개체에 background 속성을 주면 IE는 padding과 margin을 제외한 개체 자체에 속성이 먹히고, gecko 엔진은 padding의 범위까지 속성이 먹힌다. 별것 아닌거 같이 생각이 될 수 있는데 이것이 무지하게 문제가 되는 것이 그림 배경을 지정할 경우이다. 그림 배경을 지정할 경우 충격적인 차이를 경험할 수 있다.
그리고 그 안에 텍스트를 입력할 경우 두 번째 충격을 받을 수가 있다. 텍스트의 위치를 지정하기 위하여 상위 div 개체에 padding 속성을 넣은 경우에 Firefox와 IE는 완전히 다른 모습을 보여줄 것이다. 브라우저간 차이를 해결하기 위해서는 상위 개체에 padding을 사용하지 않고, 텍스트에 padding 속성을 따로 주는 방법이 유일해 보인다. (이걸 생각해내느라 세시간이 걸렸다.)
2. absolute, relative, float를 취급하는 방법이 다르다
각 div의 위치 속성을 지정하기 위한 방법으로 사용하는 저 명령어들이 브라우저마다 작동이 다르다. 오페라의 경우는 %로 지정할 경우 스크롤바 부분을 포함해서 작동한다. float의 경우에 gecko 엔진은 내용이 없을 경우 해당 div의 속성을 무시한 채 다음 relative 명령에 따라 위치를 지정한다. IE의 경우에는 다중 div 속성 상속을 할 경우, 해당되는 개체가 상속받은 개체라는 것을 인식하지 못하는 경우가 있다. 가장 문제는, 저런 문제들이 모여 CSS만을 이용해서 페이지 레이아웃을 만들기가 꽤나 애매해진다는 점이다.
CSS의 개발 목적이 디자인 부분의 독립을 위해서였다는 것을 상기해 볼 때, 각 브라우저 별로 다른 모습으로 보이는 현재의 모습은 한숨을 자아낸다. 현재로서는 CSS2 규격을 완전히 지원하는 웹 브라우저가 존재하지 않지만, 과연 CSS2 표준의 완전한 지원을 위해서 각각의 브라우저들이 현재의 렌더링 방법을 바꿀 지는 미지수이다. -그 전까지 자사의 웹브라우저를 사용하던 사용자들의 legacy를 보장해 줄 수 없기 때문이다.
웹은 어디로 나아가게 될까.
IPV6의 실용화와 XML의 보급이 가속화되고, 인터넷2로 부르는 네트워크 시스템이 제대로 작동하기 시작하면 웹은 생각할 수도 없었던 모든 곳으로 침투하게 될 것이다. 마치 내 웹페이지의 이름인 Forest처럼, 보이고 보이지 않는 모든 것들의 뒤에 존재하는 숲이 될 미래의 웹은 정보의 공유라는 원래의 이상을 만족시키는 형태가 될 것인가?
비비꼬인 머릿속의 CSS들이 아웅댄다. 블로그 스킨 한 번 갈아엎으려 하다가 수많은 것들에 대하여 다시 생각해 보게 되었다.
(0) 
(0)"물리와 셈틀 이야기" 카테고리 돌아다니기
- 태터툴즈나 텍스트큐브 스킨 만드는 가장 쉬운 방법 2007/08/11
- 기자 간담회 요약 2007/07/07
- 맥북 에어 사용기 2008/03/30
댓글을 달아 주세요
그동안 알아낸겄으로는..
레이아웃 박스 안에(margin padding은 0px로 합니다)
또 박스를 하나더 만들어서 패딩을 주어서 만드는겄입니다
이렇케 하면 대부분 해결 가능합니다
(레이아웃과 컨텐츠의 CSS 를 분리 하는 차원에서도 좋습니다)
또 박스 = 레이아웃 박스 안의 박스 입니다
역시.-_-
웹이란건 뭔가 어렵죠..
브라우져마다 다 돌아봐야 하니..(에잉..)
매우 동감입니닷!!!!!!!!!!!!
얄팍한 상식을 모아서 겨우 CSS 스킨 하나 만들었는데
HTML표준을 한 번 지켜볼까 했다가 완전히 절망하고 말았습니다.
태터 자체 태그가 표준이 아니라는데 두 손 들고 말았죠. 흑흑..
지금까지의 모질라 재단의 행보는 포기하고 표준을 지원한다였는데.. document.all의 지원은 그걸 의심하게 만드는군.
내가 느꼈던 css 사용의 가장 큰 에러는 브라우져마다 지원 정도가 너무나 다르다는 점. 특히 제일 많이 쓰이는 IE가 확 쳐져 있다는 점 -_-
제 경우는 가장 골치를 썩였던 것이 width와 border를 같이 쓸 경우. border를 5px로 잡고 width를 100으로 잡으면, 익플에서는 정확히 100이 되는데 파이어폭스에서는 110이 되어 버리더군요.
가장 확실한 방법은 자바스크립트로 브라우저를 가린 다음에 CSS를 각기 달리 적용하는 방법일 듯 하네요. 쩝.
저도 css위주로 짤라니까... 애 많이 먹었지용...
테이블일때의 width값이 레이어의 width값과 틀려서 레이아웃이 브라우져마다 틀리는... ^^;; 저도 레이어 한개를 더 만들어서 호환성을 유지하도록 했습니다.
자세한건 ari님이 정리해주셨더군요.
http://sparcs.kaist.ac.kr/~ari/each/art ··· 204.html
mylook // 님 말씀대로 브라우저에 관계없이 같은 모양을 보여주려면 내부 컨텐츠의 속성을 따로 주어야 하더군요. 위에 제가 텍스트 속성을 따로 준다고 한 것이 그런 방법입니다만, 문제는 레이어가 하나 더 추가되는 셈이니 CSS가 너무 복잡해 지더라구요.
폭주나루 // 정말 어렵습니다. ㅠ_ㅠ
당장 태터툴즈에 든 방명록 입력 폼도 브라우저마다 다르게 적용되는 것 같아요. (심지어 같은 IE일 경우에도 2000에서와 xp sp2에서 다르게 작동하는 듯.)
올빼미 // 그래도 TT는 브라우저에 크게 구애받지 않고 거의 같은 모양을 보여주니까 다행이죠. 물론 스킨 레벨에서 표준을 지키려고 애써도 막상 툴이 그렇지 않은 부분이 있으면 좌절이긴 하지만요.
ris81ryu // document.all의 지원이 모질라의 원래 이념에는 맞지 않을 수 있지만, VHS와 베타방식의 경쟁을 생각해 보았을 때 결국 표준안을 가지고 가는 것은 다수의 사용자층이 있는 쪽이 아니던가? 현재 IE가 독점하고 있는 브라우저 시장의 경우에서 볼 수 있듯이 말야.
지금과 같은 진입장벽에서 시장에 진입이라도 하기 위해 최소한의 양보만으로 최대한의 효과를 얻어내기 위한 하나의 명령어를 고르라면 나라도 당연히 document.all을 고를 듯. 물론 웹규격의 hierachy에는 반칙인 명령이기는 하지만.
css 지원에 대한 부분은 정말 어떻게 해결될지 걱정이 된다. 이러다가 IE의 .net 버전이 나오는 날이면 결국 IE의 한심한 css 지원 방법이 표준이 되는 것은 아닐까?
reidin // 그 경우 하나를 수정하기 위해서는 브라우저별 CSS를 모두 수정해야 하기 때문에 너무 번거로운 일이 될 것 같더라구요. 가장 확실한 방법이긴 한데 말이죠.
CSS 표준에서, native-(border-padding)-margin의 순으로 위치 속성이 지정되어 있으니 그 면에서는 Firefox가 지원하는 쪽이 정확한 듯 합니다. 이래저래 양쪽 맞추려니 골치아프네요
keepmypace // 역시 그 방법이 제일 편하지만 그 경우에도 float속성을 주었을 때 내용이 없으면 Firefox에서 CSS 상속 레이어에 관계 없이 앞의 레이어를 무시해버려서 문제가 생기기도 하더라구요.
적어주신 사이트 참고하겠습니다. 감사합니다 :D
css만큼은 IE로 통일하면 좋겠어요.
텍스트에 border속성이 적용된다거나, padding에 background가 포함된다거나 하는 게 좋은데 말이에요.
으음 하지만 IE의 CSS 지원은 그 기능이 너무도 미약하여 IE로 통일되는 것은 역시 재앙이 될 것 같아요.ㅠ_ㅠ 지금 장점이라고 생각되는 것들도 어쩌면 IE가 너무 두리뭉실하게 적용해서 일어나는 것 처럼 보이거든요.