Page layout 을 하는데 필수적인 요소 중에 하나가 positioning 입니다. Positioning 이라는 것은 단어의 뜻 그대로 브라우저 창에서의 위치를 잡는 CSS property 로서 아래와 같은 것 들이 있습니다.

이 중에서 float property 같은 경우에는 일반적으로 유행하는 Page layout 에 많이 사용되는 property로서 block box의 흐름을 left나 right로 움직여서 block box들을 수평 방향으로 배열시켜 주는 사용 빈도가 높은 property 입니다. 그런데 IE의 경우 이 float 이라는 property가 제대로 처리가 되지 않아서 생기는 잘 알려진 많은 bug 들이 reporting 되고 있습니다. 한 마디로 이 float은 IE 에서는 'Untouchable thing' 이라고 표현할 수 있습니다. 바로 이 float 문제 때문에 이 series를 연재하기 전에 다른 사이트에 실린 IE의 버그 등에 관한 글들을 읽어 보았는데, 소위 cross-browsing 이라고 하는 '서로 다른 브라우저에서 똑 같이 보이거나 최소한 비슷하게 보이는 방법', 에 대한 글들이 많이 있더군요. 그리고 대체적으로 이런 글 들이 제시하는 것은 FF 같이 표준에 최대한 접근한 브라우저 입장에서 IE 에서도 보일 수 있게 맞춰주는 coding 방법 들 이었고, 대 부분 공감할 수 밖에 없는 내용 들이었습니다. 따지고 보면 IE가 표준에 맞춰서 브라우저를 만들었다면 이런 작업들이 애당초 불필요한 것 이었겠죠. 그런데 그 글들 중에서도 가장 많이 대두되는 문제가 바로 float에 관한 문제 입니다. IE의 경우 MSDN Library 를 가 보면 왼쪽 메뉴에서 Web Development > HTML and CSS > Cascadign Styel Sheets > Reference > Attributes > Layout category 에 이 float 이라는 CSS property는 없습니다. 대신 style-float 이라는 것이 그 자리를 대신하고 있는데, 그 문서 제목이 'float Attribute | styleFloat Property' 라고 되어 있습니다. 즉, CSS로 지정할 때는 float으로 사용하고, scripting 할 때는 styleFloat으로 사용하라는 것이죠. 이 사이트의 CSS > Layout > float 에서도 제가 이미 그렇게 설명했었구요. MS에서 왜 그렇게 해야만 했는지 궁금할 따름입니다. width나 height 의 경우 Doctype switch의 on, off 지정에 따른 두 가지 rendering 방식으로 처리하여 switch on 상태에서는 선택적으로 나마 표준 방식을 따르는 것은 뭐 그렇다 치더라도, float 같은 경우는 switch on, off 에 관계없이 제대로 작동하지 않는다... 왜 그럴까요? 아! 궁금하여라... 하여간 제가 본 문서들에서는 이를 해결하기 위한 여러 가지 방법(IE/WIN Hacks 라고 부르더군요.)들이 제시되고 있습니다. 그래서 우선 IE 에서 float를 사용할 경우 생기는 잘 알려진 버그에 대해 알아 보겠습니다.

float 된 첫 번째 box의 margin-left가 2배가 되는 bug

이번에 이 series를 연재하면서 IE의 CSS bug에 관심을 갖게 되며 알게 된 거지만 이 bug는 아주 유명한 bug랍니다. 'float 된 첫 번째 box의 margin-left가 2배가 되는 bug' 라는게 뭐냐하면 아래와 같이 상위 box(body tag) 속에 4 개의 div box를 float:left를 사용하여 왼쪽에서 오른쪽으로 배치하고 하위 div box 들에 margin:50px 를 주었을 경우 상위 box의 좌측면과 첫 번째 하위 div box 사이에 생기는 margin 크기가 지정한 50px 가 아니라 2 배인 100px 로 처리되는 것을 말 합니다. 우선 아래의 code를 실행해 보고 계속 설명하겠습니다.

위의 실행 결과에서 보이는 grid('grid_50.gif')는 margin:50px 의 크기를 나름대로 정확하게 보기 위해서 background-image로 넣었고, 결과를 보면 IE 에서는 float 된 첫 번째 box의 margin을 2배로 처리한다는 것을 알 수 있습니다. 원래의 결과는 '버그 잡기'에서 display:inline 으로 보정한 결과와 같이 나와야 되는 거죠(FF 등에서는 제대로 나옵니다). 즉 첫 번째 floated box의 margin-left가 50px 이고 다음 box 부터는 50px + 50px = 100px 로 margin이 잡혀야 된다는 말입니다. 그런데 box에 지정된 margin이 50px + 50px 와 같이 덧셈이 되어 100px 가 된다... 이 Page layout series Part I 부터 자세히 보신 분 이라면 언뜻 스치는 의심이 생기리라 봅니다. 뭔가 하면 PLS Part II의 margin 예제에서 제가 분명히 25px + 25px 의 margin이 만나면 50px 가 아닌 25px의 margin이 생기고 각각 50px + 25px 의 margin이 만나면 큰 값인 50px 의 margin이 생긴다고 설명한 내용과 맞지 않게 되니까요. 그렇지 않습니까. 이와 같이 margin이 만나서 포개어 지는 것을 collapsing-margins 이라고 부르는데 위의 예제에서와 같이 floating된 box의 margin은 합쳐지지 않습니다. 따라서 위의 예제와 같이 float_box라는 class를 사용하는 div box의 경우 box끼리 만난 부분의 margin 역시 collapsing 되지 않고 각각의 margin 값을 갖는다는 뜻 입니다. 아마 대 부분 제 말을 믿으시겠지만 혹시 '이거 관리자가 자기 편리한 대로 해석한거 아닌가?' 라는 의혹을 품는 분들... 하지만 이 관리자가 '설마 거짓말 하겠습니까?' 하지만 그런 분들이 있다면 그런 분들을 위해서 증거를 제시하겠습니다. collapsing-margins 이라는 것은 제 맘대로 정한 것이 아나라 W3C 의 문서 중, box model의 collapsing-margins 부분에서 설명하고 있으니 참고 하시죠. 그 부분에서 발췌한 내용은 아래와 같으며 대략 해석하면

8.3.1 Collapsing margins (margin의 포개어짐)

In this specification, the expression collapsing margins means that adjoining margins (no padding or border areas separate them) of two or more boxes (which may be next to one another or nested) combine to form a single margin.
이 규격에서 margin의 포개어짐이라는 표현은 (padding이나 border 부분을 제외한) 2개 이상의 (어떤 box 다음에 있거나 내포된)box 들 사이의 인접 margin 들 하나의 margin으로 합쳐진다.

In CSS2, horizontal margins never collapse.
CSS2에서는 수평으로 생기는 margin끼리는 절대 포개어지지 않는다.

Vertical margins may collapse between certain boxes:
수직으로 생기는 margin 들은 아래과 같은 box 들 끼리 포개어질 수 있다.

Two or more adjoining vertical margins of block boxes in the normal flow collapse. The resulting margin width is the maximum of the adjoining margin widths. In the case of negative margins, the absolute maximum of the negative adjoining margins is deducted from the maximum of the positive adjoining margins. If there are no positive margins, the absolute maximum of the negative adjoining margins is deducted from zero.
정상 흐름에서 2개 이상의 box들 사이의 수직 margin 들은 포개어 진다. 그 margin width의 결과값은 인접한 margin width의 최대값으로 한다. 음수 margin의 경우 인접한 양수 margin의 최대값에서 음수 margin의 최대 절대값을 뺀다(예 : -50px 와 25px 가 만나면 양수 margin 값인 25px 에서 음수 margin의 졀대값인 50px를 빼서 25px - |+50px| = -25px). 둘 다 음수 margin일 경우 '0' 에서 둘 중 큰 음수 margin 의 최대 절대값을 뺀다(예 : -25px 와 -50px 의 margin 값이 만나면 0 - |-50px| = -50px).
Vertical margins between a floated box and any other box do not collapse.
float 된 box들 끼리의 margin과 float된 box와 다른 어떤 box와의 margin도 포개어 지지 않는다.
Margins of absolutely and relatively positioned boxes do not collapse.
절대적(position:absolute) 또는 상대적(position:relative)으로 positioning 된 box의 margin 들은 포개어 지지 않는다.

이와 같이 float 이나 position property 를 사용해서 positioning 시킨 box의 margin 끼리 포개어지지 않는 원칙에 입각해서 IE의 double margin bug를 생각해 보면 이게 왜 bug인지를 이해가 쉬우리라 생각합니다.

Expanding box bug와 고정 치수로 지정한 block box의 width 와 height의 올바른 처리

Expanding box bug에 대해 설명하기 전에 '고정 치수로 지정한 block box의 width 와 height의 올바른 처리'에 대해 먼저 말하지 않을 수 없겠습니다. 고정 치수라는 것은 예를 들어 div를 만들고 width 값을 지정하지 않았거나 auto로 지정했을 경우(width의 초기 값이 auto이므로 둘 다 같은 결과임) 가로 방향(width)의 크기는 브라우저 창의 크기 만큼이 되고, div 속의 내용물(contents)이 브라우저 창의 width를 넘을 경우 줄이 바뀌게 됩니다. 따라서 위의 double margin bug의 예제의 경우 1024 X 768 에서 본 결과와 800 X 600 에서 본 결과가 다를 수 있다는 얘기죠. IE 의 double margin bug를 새 창으로 띄워서 브라우저 창의 가로 폭을 resizing 해 보시면 가로 크기가 줄어들면 수용할 수 있을 만큼의 box 개수를 처리하고 다음 box부터 줄을 바꾸어서 처리 한다는 것을 알 수 있습니다. 또 이 경우 브라우저 창의 width가 하위 box 1개의 가로 폭(margin + width) 보다 작아졌을 때는 더 이상 줄을 바꾸지 못하고 수평으로 scroll bar를 만들게 됩니다. 물론 이 처리 결과는 비단 IE 뿐만 아니라 NN, FF 등의 브라우저에서도 마찬가지 입니다. 그런데 문제는 width:auto 또는 width를 지정 안 했을 경우가 아닌 {width: 어떤 고정 치수} 로 지정했을 경우 입니다. 우선 아래와 같이 width, height 각각 100px 인 div box를 만들고, 첫 번째 줄의 text를 enter나 공백(space) 없이 width 보다 길게 주고, text line의 행수를 height 보다 높게 주었을 경우...

위의 실행 결과에 대해 여러분들은 어떻게 생각 하시죠? IE를 사용하면서 float propety를 써서 Page layout을 잡아 본 사람이라면 누구나 겪어 보았을 사항일 것 입니다. 또 NN, FF 등을 사용해 보지 않으신 분이라면 원래 어떻게 rendering 되어야 되는지를 모르는게 당연하겠죠. NN, FF 등에서는 아래와 같이 표현됩니다.

* 아래의 표현은 이 페이지에서 실제로 NN, FF 등에서 나오는 결과를 볼 수 없으므로 제가 position property를 사용하여 위의 code를 NN, FF 에서 실행했을 경우에 나오는 결과와 같이 꾸며 본 것 입니다.

123456789012345678901234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890

위의 simulation 결과를 보면 내용물이 있는 첫 번째 box의 경우 내용이 box의 가로, 세로를 넘치드라도 border와 background-color는 지정한 100px X 100px 가 된다는 것을 알 수 있죠. 따라서 3개의 box 모두 background-color를 지정하면 NN, FF 에서는 아래와 같이 처리합니다.

123456789012345678901234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890

하지만 위의 simulation 2 의 결과는 'expanding box bug'라고 불리우는 이 bug를 overflow:hidden 으로 보정한 결과와 차이가 있습니다. overflow:hidden으로 보정한 결과는 box의 width와 height를 넘치는 내용이 clip 으로 잘라낸 것 처럼 box 이외의 내용이 잘려져 나가지만 NN, FF 에서의 simulation 2 에서는 내용이 두 번째의 파란 box를 지나서 나타 난다는 겁니다.

floating box의 줄 바꿈 방지

'floating box의 줄 바꿈' 이란 IE 의 double margin bug에서와 같이 2개 이상의 box를 float 시켰을 때 브라우저 창의 가로 폭이 floating 된 box의 width 들을 합한 길이 보다 작게 resizing 됨에 따라 floating된 box 들 중에 2 번째 이후의 box(들)가 첫 번째 box 아래로 줄이 바뀌는 현상을 말합니다. 간혹 웹 서핑을 하다보면 드물긴 하지만 브라우저가 resizing 됨에 따라 이런 줄 바꿈이 생기는 홈페이지도 있더군요. 아마 제 짐작으로는 이런 홈페이지들의 경우 page layout 을 할 때 자기는 넓은 모니터에 고해상도 화면을 보면서 저해상도 모니터를 사용하는 사람들을 생각하지 않아서 생기는 일이 아닐까 합니다만... 예를 들어 아래와 같은 layout을 만들려고 했다 치죠... Code를 실행한 다음 코드 실행기 창의 폭을 절반 이하로 줄이면 #left_column div와 #right_column div 사이에 줄이 바뀌는 것을 볼 수 있습니다.

Div의 intrinsic width

이 결과를 보면, 만약 어떤 사람이 1024 X 768 정도의 해상도에 꽉 차도록 자기 홈페이지 작업을 했다면 그 보다 저해상도 모니터를 사용하는 사람에게는 위의 실행 결과와 같이 block box의 줄이 바뀌는 현상이 생길 수 있다는 말이죠. 따라서 이런 문제를 해결하기 위해서는 IE 의 double margin bug에서와 같이 아무리 브라우저 창의 폭을 좁혀도 마지막 남은 하나의 box는 줄이 바뀌지 않는 것을 이용해서 위의 예제에서의 #left_column과 #right_column 2개(또는 2개 이상)의 floating box를 wrap 이라는 id selector를 지정한 div box 속에 넣어 보도록 하겠습니다. 이 경우도 위의 경우에서 처럼 코드 실행기 창의 가로 폭을 절반 이하로 resizing 한 후 수평 scroll bar를 움직여 봅시다.

* code 중에 #left_column과 right_column 에 float:left 를 넣지 않고 .column 이라는 class 를 만든 이유는 실제 작업을 하다보면 많은 수의 div와 id selector가 생기므로 그 중에 class="column" 이 들어간 div를 보면 '아! float:left 된 div 구나.' 하고 알아보기 쉽고, float 시켜야할 div가 더 생길 경우에도 같은 방법으로 단순히 tag에 class="column" 만을 추가하므로서 left로 float 시키는 효과를 볼 수 있지 않을까 해서 입니다.

위의 결과에 의해서 div 같은 block level box 의 width를 지정하지 않았을 경우의 width, 즉, intrinsic width value 가 100% 라는 것을 알 수 있습니다. 즉, 브라우저 창의 폭을 꽉 채우기 때문에 브라우저 창의 폭이 #wrap에 지정한 300px 이하로 resizing 되면 #header와 #footer 의 width가 #wrap 보다 짧아지는 우스꽝 스런 꼴이 되는거죠. 하지만...

FireFox 에서의 처리

FireFox 에서는 아주 간단히 처리되는군요. FF에서는 min-width 를 사용하면 됩니다. min-width라는 peorperty는 예를 들어 min-width:300px 로 지정하면 브라우저 창(상위 block box)이 300px 이하가 되어 수평 scroll bar가 생겨도 지정한 300px 의 width를 유지하고, 300px 이상이 되면 width:100%로 지정한 것과 같이 브라우저의 폭을 꽉 채우게 해주는 CSS property 입니다. NN(version 8.0 영문)에서는 브라우저 창이 300px 이하가 되어도 수평 scroll bar가 생기지 않아서 확인할 도리가 없군요. 저만 그런건지... 하지만 min-width property를 사용해도 IE에서는 이게 인식이 안되는 관계로 width:100%와 같이 처리되네요. 따라서 많은 사이트에서 예제의 #header와 #footer 의 width를 고정 치수로 지정하는 이유도 바로 여기에 있지 않나 생각합니다.

The 'IML'

사실 이런 방법 말고도 이런 문제를 해결할 수 있는 방법이 저한테 있긴 있습니다만... 아직 개발 단계라서 밝히기는 쩜 뭐 하지만... IML 이라는 것이 있습니다. 이렇게 말하면 무슨 약장사 말투 같지만, 이 IML로 말할 것 같으면 물리적인 효과는 아직 밝혀진 바 없지만(한 번도 안 써 봤으므로), 문서 작성자에게 있어서 정신적인 효과는 상당히 기대되는 언어라고 할 수 있습니다. 이 물리적인 효과가 밝혀진 바가 없으므로 여러분들에게 적극적으로 권장하지는 않습니다만 최소한 손해를 보지는 않으리라 생각 합니다. 단, IML 사용 후에 그 실제적인 효과에 대해 분개한 나머지 게시판이나 메일을 통해 글로서 저한테 어떠한 테러도 가해서는 안되며, 심지어 마음속으로 나마 분통을 터뜨리는 일이 없어야 된다는 조건부로 사용하시기 바랍니다. 이 조건에 동의 하신다면 아래의 '동의' 를 선택한 후 내용을 보시기 바랍니다.

이 조건에 동의 하시겠습니까?

IML 사용법
<IML:expectation scroll-y-only="Yeah!" scroll-x="Please don't" resize="Oh! no!" noresize="Thanks" from="Me" to="Visitors"></IML:expectation>

이 IML 용법에서는 start tag과 end tag 사이의 어떤 문자 데이터도 허용하지 않습니다. 만약 문자 데이터를 사용하면 그게 진짜루 브라우저 상에 나타나게 되어 낭패를 보게 됩니다. 단  와 같이 주석 속에서는 사용을 허용 한다고 합니다. 또한 사용 위치는 head section과 body section 사이에 넣는 것을 원칙으로 하지만 사용자의 당시 기분에 따라서 변동도 가능하다는군요. scroll-y-only 같은 attribute의 경우 예제의 속성값인 Yeah 앞 뒤에 'Oh!' 와 같은 감탄사나 '^^'와 같은 emoticon을 뒤에 붙이면 효과가 증폭되고, 특히 from과 to 의 attribute value가 'Me'로 일치 하면 그 효과가 극대화 되고 강한 믿음과 함께 사용할 때 극치를 이룬다고 합니다. 더우기 우리를 놀라게 하는 IML의 장점은 element와 attribute를 사용자 자신이 임의로 생성해서 쓸 수 있고, 한글의 사용도 가능하다는 것 입니다. 한가지 사소한 단점은 이 IML의 작동 여부를 문성 작성자가 전혀 통제할 수 없고, 순전히 보는 사람 마음에 따라야 된다는거죠.

<아예멜:썰렁하긴
왜이런짓을하나="PLS Part I 부터 여기가지 보면 이 때 쯤 지루할 것 같아서..."
효과에대한불만="참아 주세효~..."
물리적실제효과="알려진 바 없음"
정신적안정효과="믿음의 정도에 따라 천차만별이지만 그에 따라 정비례나 반비례하는 것 같지는 않음">
부작용="사용 후에 불안, 초조증세를 보이면서 때로는 치를 떨기도 함"

</아예멜:그러게>

참, IML 은...

The 'IML' stands for Insane Markup Language.

TIPS - Page layout에서 block box 사이에 border 넣기

위의 float을 사용한 page layout 예제에서와 같이 각 block box에 background-color를 지정해서 box 영역을 구분하기도 하지만 또 한가지 방법으로서 인접한 block box를 border로 구분하기도 합니다. 아래와 같이 말이죠.

양쪽에 모두 border를 지정했으니 당연한 결과 입니다만, 수직 border의 경우 위의 예제 실행 결과는 1px 의 border 2개가 겹쳐서 2px 가 되었습니다. 이걸 1px로 보이게 하려면 결국 둘 중에 하나에만 border를 지정해야 된다는 말이죠. 그렇다면 둘 중 어디에 지정해야 될까요? 답은 간단합니다. 둘 중 height가 더 큰쪽에 지정한다가 정답입니다. 하지만 그러기 위해서는 한 쪽이 항상 길어야 된다는 보장 있어야 되는데, 그게 어디 그렇게 되겠습니까. 그렇다고 border를 지정한 쪽을 항상 길게 하려고 없는 내용을 만들 수는 없지 않습니까. 따라서 둘 중 어느 쪽이 더 긴지에 대한 답은 '그 때 그 때 달라요.' 가 되겠죠. 그래서 제가 한 가지 대안을 제시하려고 하는데 방법은 #left_column이나 #right_column 이 아닌 두 box를 싸고 있는 #wrap 에 border를 지정하는 거죠. 하지만 box 가운데에 border를 지정할 수는 없으므로 background-image를 이용 하도록 하겠습니다. 사용할 point_1x1.gif (1px X 1px의 gray 색)을 4배 확대하면 아래와 같습니다.

어떻습니까. 이와 같이 point_1x1.gif 를 background-image로 #wrap에 넣으므로서 좌측과 우측 중에 어느 쪽이 길어지든 관계없이 수직 border를 넣은 것과 같은 효과를 낼 수 있겠습니다. 이 방법을 사용하면 실선 뿐만 아니라 점선 효과(sample file 1 , sample file 2 )도 낼 수 있습니다. 즉, 가로 1px 세로 2px 의 image를 만들되, 위의 1px는 점선으로 쓸 원하는 color를 넣고, 아래의 1px 는 투명(또는 배경색과 같이)하게 처리하여 background-repeat:repeat-y로 반복 시키면 될 것이고, column이 3개 있는 layout (sample file)의 경우, 예를 들어 150px, 450px, 150px 의 column이라면 가운데 450px 에 맞춰서 가로 450px 세로 1px 크기에 양쪽 끝을 원하는 color로, 가운데를 투명하게 지정하여

background:url('image file') 150px 0 repeat-y

로 반복 시키면 되겠습니다. 하지만 FF 에서는 위의 min-width property와 마찬가지로 min-height property를 사용하면 이런 문제를 간단히 처리할 수 있습니다. 일반적으로 왼쪽 column에 menu를 배치한다고 치면 오른쪽 column 에 {min-height:왼쪽 height 보다 더 큰 px} 로 지정하면 된다는 말입니다. 하지만 역시 다른 브라우저에서는 안 먹는 군요. 쓸 수 있는데도 다른 브라우저에서 지원하지 않기 때문에 못 쓰는 심정... FF 사용자의 입장에서 보면 마치 '흡연을 위해서 지나친 건강을 삼가'하는 경우랄까요...

원래 positioning에 관련된 모든 것을 이 페이지에서 다루려고 했는데 내용이 너무 길어지는군요. 나머지 positioning 관련 property들은 다음 페이지에서 진행하도록 하겠습니다. 주변에 있는 친구의 말로는 요즘은 긴 페이지를 싫어하는 추세라는데, 내용이 너무 길어진게 아닌가 합니다. 그럼 PLS Part V에서...

Layout with Positioning | Page Layout Series Part IV

Positioning을 이용한 Page layout