IE Three Pixel Gap 해결책은?
IE Three Pixel Gap 해결책은?
예제 코드부터 보자면,
#container {width:600px;}
#col1 {float:left;width:100px;height:100px;background:#ccc;}
#col2 {margin-left:100px;height:100px;background:#fcc;}
<div>
<div>col1</div>
<div>col2</div>
</div>
FF나 Opera에서는 col1과 col2가 딱 붙어있습니다.
그런데 IE6는 중간에 3px가 생깁니다.
퍼펙트픽셀주의자가 아니더라도 배경색이 들어간 경우에는 용납할 수 없는 문제입니다.
또한 이때문에 걸핏하면 col2가 아래로 밀려나 레이아웃이 깨져버립니다.
PIE가 제시하는 방법을 따라가 보았지만, 위 문제가 해결되지 않는군요.
http://www.positioniseverything.net/exp ... xtest.html
의미론적으로 무의미한 div를 중첩하는 트릭을 사용하고 있습니다만, 좀더 세련된(?) 해결책 없을까요?
#container {width:600px;}
#col1 {float:left;width:100px;height:100px;background:#ccc;}
#col2 {margin-left:100px;height:100px;background:#fcc;}
<div>
<div>col1</div>
<div>col2</div>
</div>
FF나 Opera에서는 col1과 col2가 딱 붙어있습니다.
그런데 IE6는 중간에 3px가 생깁니다.
퍼펙트픽셀주의자가 아니더라도 배경색이 들어간 경우에는 용납할 수 없는 문제입니다.
또한 이때문에 걸핏하면 col2가 아래로 밀려나 레이아웃이 깨져버립니다.
PIE가 제시하는 방법을 따라가 보았지만, 위 문제가 해결되지 않는군요.
http://www.positioniseverything.net/exp ... xtest.html
의미론적으로 무의미한 div를 중첩하는 트릭을 사용하고 있습니다만, 좀더 세련된(?) 해결책 없을까요?
일단 이렇게 한번 해보시죠..
col2 엘리먼트도 float: left 로 하고 width를 500px로 하니까 둘이 붙긴 하는데.. ^^a
정확한 답변은 아닌 듯 하여 죄송합니다. ^^a
세련된 답변은 아마 다른 고수님께서..
정확한 답변은 아닌 듯 하여 죄송합니다. ^^a
세련된 답변은 아마 다른 고수님께서..
-
- 서포터즈
- Posts: 83
- Joined: 2006 05 04 02:44 45
- Location: 대전
- Contact:
k1 님 방법이 좋은데요.
float 에 대한 IE6 의 버그네요.
hack 을 써서 해결하는 방법이 있지만 권장하지 않으므로 생략하고 저라도 k1 님의 방법을 사용할 것 같습니다.
col2 에 margin-left 를 제거한 다음 foat:left 또는 float:right 를 적용하고 너비값을 추가하는 방식.
hack 을 써서 해결하는 방법이 있지만 권장하지 않으므로 생략하고 저라도 k1 님의 방법을 사용할 것 같습니다.
col2 에 margin-left 를 제거한 다음 foat:left 또는 float:right 를 적용하고 너비값을 추가하는 방식.
Last edited by dece24 on 2007 01 23 13:35 14, edited 1 time in total.
Re: 일단 이렇게 한번 해보시죠..
네, 둘다 float을 주면 달라 붙긴하는데, 이렇게 둘다 float을 줘버리고 나면, 바닥 레이어에서 차지하는 height 때문에 의미론적으로 불필요한 엘리먼트를 추가해 주어야 하는 또다른 문제가 발생합니다.k1 wrote:col2 엘리먼트도 float: left 로 하고 width를 500px로 하니까 둘이 붙긴 하는데.. ^^a
정확한 답변은 아닌 듯 하여 죄송합니다. ^^a
세련된 답변은 아마 다른 고수님께서..
예를들면, col1과 col2를 감싸는 레이어를 추가한다든지, col2 다음에 clear된 빈 레이어를 추가한다든지 하는 식으로 말입니다.
table 레이아웃을 주로 할때는 IE가 그렇게 편하고 좋았는데, html+css를 하다보면 IE가 정신건강에 몹시 해롭더군요.
Re: 일단 이렇게 한번 해보시죠..
어짜피 현실의 웹은 혼동과 혼란의 혼재 아닌가 하는 데... 완벽한 웹표준, 어찌 하오리까라는 것을 zzz님도 잘 아실테고...zzz wrote:네, 둘다 float을 주면 달라 붙긴하는데, 이렇게 둘다 float을 줘버리고 나면, 바닥 레이어에서 차지하는 height 때문에 의미론적으로 불필요한 엘리먼트를 추가해 주어야 하는 또다른 문제가 발생합니다.
예를들면, col1과 col2를 감싸는 레이어를 추가한다든지, col2 다음에 clear된 빈 레이어를 추가한다든지 하는 식으로 말입니다.
table 레이아웃을 주로 할때는 IE가 그렇게 편하고 좋았는데, html+css를 하다보면 IE가 정신건강에 몹시 해롭더군요.
적당히 Hack사용하는 것이라 생각합니다. 고민하고 이것저것 헤매다.. 어 되내.. 그럼 그걸 사용하는 것이죠. 물론 그렇게 하시고 있겠죠.
소프트원트닷컴에서 번역한 사이트에서도 나오는 이야기지만,
http://softwant.com/standards/
html+css을 이용한 웹 접근은 새로운 접근 방식을 요구하는 것이라고 하니까요. 실제 사용하다보면 그게 사실이고.
그만큼 개발자에겐 고정된 접근 방법이 아니라 창의적인 접근 방식을 가능하게 한다는 것이니까요. 그래서 웹에 새로운 바람을 불어넣고 싶은 욕구인 결과, 아작 내부려~~~~... ajax가 나온 것 아닌가 하내요. ^^
아니면 적당히 table 태그 사용하는 것입니다. 그게 실무적으로 좀 더 빠른 경우라면.............
-
- 서포터즈
- Posts: 83
- Joined: 2006 05 04 02:44 45
- Location: 대전
- Contact:
Re: 일단 이렇게 한번 해보시죠..
화면배치를 위한 CSS(IE버그) 해결방법을 묻는 질문에 Ajax 가 나오고 table 이 나오는건 좀 아니라고 생각합니다.소프트원트 wrote:그래서 웹에 새로운 바람을 불어넣고 싶은 욕구인 결과, 아작 내부려~~~~... ajax가 나온 것 아닌가 하내요. ^^
아니면 적당히 table 태그 사용하는 것입니다. 그게 실무적으로 좀 더 빠른 경우라면.............
웹표준이나 웹접근성을 고려하여 제작되는 사이트들이 하나 둘씩 늘어나고 있는 추세이고,
이제는 어느정도 노하우가 쌓이다보니 단순히 table 레이아웃을 html+css 레이아웃 대체하는 정도를 넘어서, table 레이아웃으로는 흉내내기가 쉽지않은 것들을 html+css로 정갈하게 구현해 내는 경우도 어렵잖게 접하게 됩니다.
저도 최근에 http://brokenseven.com/ 을 작업하면서, html+css로 table 레이아웃보다 더 탄탄하고, 더 미려하고, 더 세련되게 구현할 수 있다는 것을 보여주겠다는 의욕을 가지고 노력을 하였는데, 결과적으로 그런지는 잘 모르겠군요.
제가 위 질문을 드린 것은, 프로젝트가 완료되고, 뒤돌아 보니, 의미론적으로 무의미한 레이어들이 조금은 남발된듯한 느낌을 지울 수가 없었는데, 그 원인의 많은 부분이 위에서 언급한 3px과 같은 IE6의 예측할 수 없는 특이한 행동방식을 좇아가다보니 발생한 것이고, 결과적으로 html 소스도 조금은 어지러워지고 , css도 점점 난해해졌기 때문입니다.
IE7으로 테스트 해보면 IE6보다는 그나마 조금은 낫습니다만, 아직은 IE6가 주류이나보니 IE6에서 잘 되는 것을 기본 전제로하고 IE7, FF, Opera 등에서 문제가 없도록 할 수 밖에 없었습니다.
IE6를 위한 모든 배려를 다 하자면 한도 끝도 없겠지만, 이렇게 잘못 추가되는 픽셀만 (clear된 height:0인 레이어서도 나타나는 현상) 해결되어도 마크업이 의미론적으로 훨씬 탄탄해지지 않겠는가 하는 아쉬움 때문에 질문을 드렸습니다.
이제는 어느정도 노하우가 쌓이다보니 단순히 table 레이아웃을 html+css 레이아웃 대체하는 정도를 넘어서, table 레이아웃으로는 흉내내기가 쉽지않은 것들을 html+css로 정갈하게 구현해 내는 경우도 어렵잖게 접하게 됩니다.
저도 최근에 http://brokenseven.com/ 을 작업하면서, html+css로 table 레이아웃보다 더 탄탄하고, 더 미려하고, 더 세련되게 구현할 수 있다는 것을 보여주겠다는 의욕을 가지고 노력을 하였는데, 결과적으로 그런지는 잘 모르겠군요.
제가 위 질문을 드린 것은, 프로젝트가 완료되고, 뒤돌아 보니, 의미론적으로 무의미한 레이어들이 조금은 남발된듯한 느낌을 지울 수가 없었는데, 그 원인의 많은 부분이 위에서 언급한 3px과 같은 IE6의 예측할 수 없는 특이한 행동방식을 좇아가다보니 발생한 것이고, 결과적으로 html 소스도 조금은 어지러워지고 , css도 점점 난해해졌기 때문입니다.
IE7으로 테스트 해보면 IE6보다는 그나마 조금은 낫습니다만, 아직은 IE6가 주류이나보니 IE6에서 잘 되는 것을 기본 전제로하고 IE7, FF, Opera 등에서 문제가 없도록 할 수 밖에 없었습니다.
IE6를 위한 모든 배려를 다 하자면 한도 끝도 없겠지만, 이렇게 잘못 추가되는 픽셀만 (clear된 height:0인 레이어서도 나타나는 현상) 해결되어도 마크업이 의미론적으로 훨씬 탄탄해지지 않겠는가 하는 아쉬움 때문에 질문을 드렸습니다.
Re: 일단 이렇게 한번 해보시죠..
위 이야기를 하시는 게, 저에게 딴지거는 것처럼 느껴지내요. ^^dece24 wrote:화면배치를 위한 CSS(IE버그) 해결방법을 묻는 질문에 Ajax 가 나오고 table 이 나오는건 좀 아니라고 생각합니다.소프트원트 wrote:그래서 웹에 새로운 바람을 불어넣고 싶은 욕구인 결과, 아작 내부려~~~~... ajax가 나온 것 아닌가 하내요. ^^
아니면 적당히 table 태그 사용하는 것입니다. 그게 실무적으로 좀 더 빠른 경우라면.............
3px문제가 해결되고 나니, float 사용에 대해 footer 단과의 관계를 지적하는 데 그럼 무슨 말이 더 필요할까요.
이미 float로써 답은 끝난 것이고, 단지 다른 접근 방식이 있을 뿐인 것 아니였나요.
이것은 개발자의 창의성과 스팩에 대한 이해가 요구되는 부분이죠.
col2에 float를 사용하지 않는다면, col1에도 float 사용하지 않고 포지션을 이용하거나 이것도 아니라면 테이블 레이아웃을 이용하는 것 그것도 하나의 접근방식 아닌가요 ?
float를 사용하였을 때, footer 단 문제는 zzz님도 이야기하였든, 무의미한 div에 clear 속성 사용을 이야기했으니, 더이상 이야기할 내용은 없었다고 생각합니다.
float 사용이라는 전재에서는 하단 레이어와의 관계를 좀 더 진행할 수 있었는 지 모르지만, zzz님의 이야기로 제가 생각하기는 더는 없었고..
아마도 IE 죽일놈이라고 IE버그에 대한 의견을 덧붙여주는 것이였으리라는 생각이드는군요.
-
- 서포터즈
- Posts: 83
- Joined: 2006 05 04 02:44 45
- Location: 대전
- Contact:
이 게시판 '웹 표준' 이 주제 아닌가요?
현재의 게시판 주제는 Web Standard Evangelism 입니다. 웹 표준 이 주제라는 뜻이죠. 갑자기 Ajax 이야기를 하시는 것을 이해할 수 없었고 또한 실무적으로 빠르다는 이유로 Table Layout 도 하나의 대안이라고 말씀하시는 것도 이해할 수 없습니다.
Table Layout 이 실무적으로 빠르거나 그렇지 않거나를 떠나서 그것을 지양해야 할 것이 아닌 '실무적 대안' 으로 표현하는 것이 적절하지 않다는 뜻입니다.
제가 왜 Table Layout 이 적절하지 않다고 말하는지는 잘 알고 계시니 따로 설명하지 않겠습니다.
Table Layout 이 실무적으로 빠르거나 그렇지 않거나를 떠나서 그것을 지양해야 할 것이 아닌 '실무적 대안' 으로 표현하는 것이 적절하지 않다는 뜻입니다.
제가 왜 Table Layout 이 적절하지 않다고 말하는지는 잘 알고 계시니 따로 설명하지 않겠습니다.
Re: 이 게시판 '웹 표준' 이 주제 아닌가
dece24
테이블의 문제는 오남용이라는 측면을 생각하여야지, 그것을 거부적 수준으로까지 끌고간다는 것은 적절하게 테이블로 제작하는 개발자들도 도매값을 넘어갈 것입니다.
테이블 오남용 문제를 지적하고 거기에서 테이블의 유연성을 활용하는 것도 웹 개발에 도움이 된다는 점을 생각해야 하지않을까요 ?
Div가 레이아웃용 태그입니까 ?
Html+CSS, 특히 Div만으로 레이아웃 제작은 브라우저간 지원 차이 때문에 완벽한 처리가 불가능합니다. 물론 요구하는 레이아웃에 따라 다르겠죠.
완벽한 레이아웃을 하려면 Hack 사용하고 또 브라우저마다 detection 기술을 사용하는 문제가 발생하죠. 이런 상황에서 실무에서 강요한다고 됩니까 ?
외곽 레이아웃을 잡는 데, 중첩테이블을 사용하지 않고, 또 무의미한 간격용 셀을 사용하지 않는 수준에서 서식적 태그를 CSS로 걷어내는 것만으로 파일 크기를 줄이고 작업효율을 높일 수 있을 것입니다.
능력이 되고, 시간적 여유가 있다면 테이블리스로 레이아웃을 제작하면 될 것입니다. 그렇지 못한 경우라면, 머리 싸매고, 지어짜면서 고민할 필요가 있냐라는 것입니다.
dece24님도 아마도 몇 개월 이상을 나름대로 학습하여 지금의 수준에 다다른 것 아닌가요 ? 그것도 국내에서 자료 찾아서 해결한 것이 아니라 해외사이트 구굴링구굴링, 씨발씨발하면서 그랬을 것입니다.
눈으로 먼저 제대로 읽어주시기 바랍니다.
글을 눈으로 읽지않나 보는군요. 창의적 접근이라는 부연 설명 내용을 꼬트리잡아서 뭔 이득이 있으신지 모르겠군요.현재의 게시판 주제는 Web Standard Evangelism 입니다. 웹 표준 이 주제라는 뜻이죠. 갑자기 Ajax 이야기를 하시는 것을 이해할 수 없었고 또한 실무적으로 빠르다는 이유로 Table Layout 도 하나의 대안이라고 말씀하시는 것도 이해할 수 없습니다.
Table Layout 이 실무적으로 빠르거나 그렇지 않거나를 떠나서 그것을 지양해야 할 것이 아닌 '실무적 대안' 으로 표현하는 것이 적절하지 않다는 뜻입니다.
제가 왜 Table Layout 이 적절하지 않다고 말하는지는 잘 알고 계시니 따로 설명하지 않겠습니다.
또한 테이블리스가 Web Standard Evangelism입니까 ?그만큼 개발자에겐 고정된 접근 방법이 아니라 창의적인 접근 방식을 가능하게 한다는 것이니까요. 그래서 웹에 새로운 바람을 불어넣고 싶은 욕구인 결과, 아작 내부려~~~~... ajax가 나온 것 아닌가 하내요. ^^
테이블의 문제는 오남용이라는 측면을 생각하여야지, 그것을 거부적 수준으로까지 끌고간다는 것은 적절하게 테이블로 제작하는 개발자들도 도매값을 넘어갈 것입니다.
테이블 오남용 문제를 지적하고 거기에서 테이블의 유연성을 활용하는 것도 웹 개발에 도움이 된다는 점을 생각해야 하지않을까요 ?
Div가 레이아웃용 태그입니까 ?
Html+CSS, 특히 Div만으로 레이아웃 제작은 브라우저간 지원 차이 때문에 완벽한 처리가 불가능합니다. 물론 요구하는 레이아웃에 따라 다르겠죠.
완벽한 레이아웃을 하려면 Hack 사용하고 또 브라우저마다 detection 기술을 사용하는 문제가 발생하죠. 이런 상황에서 실무에서 강요한다고 됩니까 ?
외곽 레이아웃을 잡는 데, 중첩테이블을 사용하지 않고, 또 무의미한 간격용 셀을 사용하지 않는 수준에서 서식적 태그를 CSS로 걷어내는 것만으로 파일 크기를 줄이고 작업효율을 높일 수 있을 것입니다.
능력이 되고, 시간적 여유가 있다면 테이블리스로 레이아웃을 제작하면 될 것입니다. 그렇지 못한 경우라면, 머리 싸매고, 지어짜면서 고민할 필요가 있냐라는 것입니다.
dece24님도 아마도 몇 개월 이상을 나름대로 학습하여 지금의 수준에 다다른 것 아닌가요 ? 그것도 국내에서 자료 찾아서 해결한 것이 아니라 해외사이트 구굴링구굴링, 씨발씨발하면서 그랬을 것입니다.
눈으로 먼저 제대로 읽어주시기 바랍니다.
-
- 서포터즈
- Posts: 83
- Joined: 2006 05 04 02:44 45
- Location: 대전
- Contact:
그렇다고 Table 을 대안이라고 하시다니요
실무, 현실 이런말씀 하시는데 이미 실무에서 Table 없이 화면배치 하는 팁은 많이 나와 있습니다. 또, 적당히 숙련된 사람들은 Table 보다 느리지도 않습니다. 완벽한 처리는 불가능하다고 하셨는데 OS 별로 서체의 모양새가 다르게 렌더링 되는 것을 제외하고는 레이아웃과 같은 작업은 CSS 로도 완벽하게 호환시킬 수 있습니다.
이 글타래의 시발점은 화면배치를 위한 CSS 문제해결 이었다고 생각합니다만. 마땅히 가야할 방법이 있었고 그것이 가능한데 '창의' 라는 명목아래 Ajax 는 왜 나온 것이며 Table 을 대안이라고 말씀하시는 것이 저는 적절하지 않다고 지적하였을 뿐입니다.
아무튼 소프트원트님과 다른 의견을 내면서 저는 이것이 논쟁이 될 지언정 '상호비난' 하는 수준으로는 발전하지 않았으면 합니다. 몇몇 문장이나 단어들은 좀 지나치시군요.
이 글타래의 시발점은 화면배치를 위한 CSS 문제해결 이었다고 생각합니다만. 마땅히 가야할 방법이 있었고 그것이 가능한데 '창의' 라는 명목아래 Ajax 는 왜 나온 것이며 Table 을 대안이라고 말씀하시는 것이 저는 적절하지 않다고 지적하였을 뿐입니다.
아무튼 소프트원트님과 다른 의견을 내면서 저는 이것이 논쟁이 될 지언정 '상호비난' 하는 수준으로는 발전하지 않았으면 합니다. 몇몇 문장이나 단어들은 좀 지나치시군요.
Re: 그렇다고 Table 을 대안이라고 하시
dece24
국어 공부하자는 것 아니라 생각하며, 이런 소모적인 이야기는 하지않았으면 하내요.
이미 위에서 다 이야기했다고 생각합니다.
마땅히 가야할 것이 완료되었다고 판단했기에 문제에 대한 답변으로써가 아닌 접근 방식에 있어서 의견글을 올린 것입니다.
float 활용 외에 다른 방법이 있으십니까 ?
그 다른 방법을 찾는 게 더 생산적이겠죠.
ajax가 왜 나왔냐 ? table이 대안이다?실무, 현실 이런말씀 하시는데 이미 실무에서 Table 없이 화면배치 하는 팁은 많이 나와 있습니다. 또, 적당히 숙련된 사람들은 Table 보다 느리지도 않습니다. 완벽한 처리는 불가능하다고 하셨는데 OS 별로 서체의 모양새가 다르게 렌더링 되는 것을 제외하고는 레이아웃과 같은 작업은 CSS 로도 완벽하게 호환시킬 수 있습니다.
이 글타래의 시발점은 화면배치를 위한 CSS 문제해결 이었다고 생각합니다만. 마땅히 가야할 방법이 있었고 그것이 가능한데 '창의' 라는 명목아래 Ajax 는 왜 나온 것이며 Table 을 대안이라고 말씀하시는 것이 저는 적절하지 않다고 지적하였을 뿐입니다.
아무튼 소프트원트님과 다른 의견을 내면서 저는 이것이 논쟁이 될 지언정 '상호비난' 하는 수준으로는 발전하지 않았으면 합니다. 몇몇 문장이나 단어들은 좀 지나치시군요.
국어 공부하자는 것 아니라 생각하며, 이런 소모적인 이야기는 하지않았으면 하내요.
이미 위에서 다 이야기했다고 생각합니다.
마땅히 가야할 것이 완료되었다고 판단했기에 문제에 대한 답변으로써가 아닌 접근 방식에 있어서 의견글을 올린 것입니다.
float 활용 외에 다른 방법이 있으십니까 ?
그 다른 방법을 찾는 게 더 생산적이겠죠.
-
- 해커
- Posts: 691
- Joined: 2004 08 11 22:14 59
- Contact:
zzz
col2에 대한 css에
margin-left/height를 지우고
float:left;
width:넓이 지정;
height값을 지정할 경우, IE는 최소값으로 인식하기 때문에, 그 지정 범위를 넘어가더라도 박스 안에 채웁니다. 그러나 이것은 잘못입니다.
태그에 지정한 height값을 지정했는 데, 그것을 지멋대로 먹어버리니까요.
또 IE에서 문제가 되는 3px 갭이 생깁니다.
표준브라우저에는 height값을 그대로 해석하고 하단 footer div와 겹치는 것은 당연한 결과입니다. 그리고 그 범위를 넘어가는 내용이 생기게 됩니다.
그래서 height값을 없애라는 것입니다.
height값을 지정하지 않을 경우, 기본은 auto이며, 이 의미는 문서 내용을 표시할 수 있는 범위를 말합니다.
위에서 다른 분들이 해결책을 제시하였기에 더이상 언급할 내용은 없었다고 판단한 것입니다.
문제는 좌측 메뉴에서 또 생기겠죠. 좌측 메뉴 영역에서 색상을 지정하게 되면, 개발하려는 요구조건에 따라 문제가 발견됩니다. height값을 지정할 경우, 무슨 문제가 있을까요? 메인 영역의 높이와 연동되어야 하는 데, 메인 영역의 내용을 예측할 수 있을까요 ?
이를 위해 다시 메인 영역을 감싸는 div를 만들어주는 방법을 사용하게 됩니다. 그런데 여기서 끝날까요 ? height 값이 주어지지 않으면, 그래서 상위 wrapper 안에다 br=clear나 div style=clear:both;height:1px;와 같은 무의미한 태그를 생산하게 됩니다.
이에 대한 다른 접근 방법으로 스크립트를 사용해서 메인 영역을 계산하는 방법이 있더군요. 결국 계속해서 산넘고 물건너야하게 됩니다. 원래 목적하였던 단출한 코드는 점점 멀어지게 됩니다.
그래서 개발 조건에 따라, 외곽 레이아웃을 잡는 데에만 테이블 레이아웃을 사용하는 게 웹개발 환경에 따라 유연하게 접근할 수 있다는 것입니다.
위에서 이미 다 언급된 것 아닌가요 ?처음 질문의 원인이 된 프로젝트는 완료되었고, 시간에 쫓기지도 않습니다.
생산성에 대한 압박이 심하신 분들은 어쩔 수 없구요,
여유 좀 있으신(아니면 일부러 여유를 좀 내실 의향이 있으신) 분들께서 3px를 해결할 어떻한 방안이라도 제시하여 주시면 감사하겠습니다.
col2에 대한 css에
margin-left/height를 지우고
float:left;
width:넓이 지정;
height값을 지정할 경우, IE는 최소값으로 인식하기 때문에, 그 지정 범위를 넘어가더라도 박스 안에 채웁니다. 그러나 이것은 잘못입니다.
태그에 지정한 height값을 지정했는 데, 그것을 지멋대로 먹어버리니까요.
또 IE에서 문제가 되는 3px 갭이 생깁니다.
표준브라우저에는 height값을 그대로 해석하고 하단 footer div와 겹치는 것은 당연한 결과입니다. 그리고 그 범위를 넘어가는 내용이 생기게 됩니다.
그래서 height값을 없애라는 것입니다.
height값을 지정하지 않을 경우, 기본은 auto이며, 이 의미는 문서 내용을 표시할 수 있는 범위를 말합니다.
위에서 다른 분들이 해결책을 제시하였기에 더이상 언급할 내용은 없었다고 판단한 것입니다.
문제는 좌측 메뉴에서 또 생기겠죠. 좌측 메뉴 영역에서 색상을 지정하게 되면, 개발하려는 요구조건에 따라 문제가 발견됩니다. height값을 지정할 경우, 무슨 문제가 있을까요? 메인 영역의 높이와 연동되어야 하는 데, 메인 영역의 내용을 예측할 수 있을까요 ?
이를 위해 다시 메인 영역을 감싸는 div를 만들어주는 방법을 사용하게 됩니다. 그런데 여기서 끝날까요 ? height 값이 주어지지 않으면, 그래서 상위 wrapper 안에다 br=clear나 div style=clear:both;height:1px;와 같은 무의미한 태그를 생산하게 됩니다.
이에 대한 다른 접근 방법으로 스크립트를 사용해서 메인 영역을 계산하는 방법이 있더군요. 결국 계속해서 산넘고 물건너야하게 됩니다. 원래 목적하였던 단출한 코드는 점점 멀어지게 됩니다.
그래서 개발 조건에 따라, 외곽 레이아웃을 잡는 데에만 테이블 레이아웃을 사용하는 게 웹개발 환경에 따라 유연하게 접근할 수 있다는 것입니다.
-
- 해커
- Posts: 691
- Joined: 2004 08 11 22:14 59
- Contact:
-
- 해커
- Posts: 691
- Joined: 2004 08 11 22:14 59
- Contact:
Who is online
Users browsing this forum: Ahrefs [Bot] and 0 guests