배로 크게 만들고 강제로 기존 사이즈 적어주면 되긴 하는데..
이 경우는 접속 환경의 Retina Display인지 아닌지 구분할 수 없다는 문제점이 있다.
하지만 아래 나온 class 할당 방식으로 해결할 수 있긴 하지만 바람직한 방법은 아닌듯 하며,
번거롭지만 배경이미지로 바꾸는게 나아보인다.
이런 반응을 보이셨을 것이다.
이건 마치 "헤딩태그는 책과 같다고 생각하시면 되요"라고 말한 것과 똑같은듯하다
여러분의 느끼실 그 허탈함에 전편을 포스팅하고 바로 후편을 쓴다.
후편에서는 무엇이 잘못되었는지 집어볼 것이다.
헤딩태그의 잘못된 사례(헤딩태그의 오해)
1. 레이아웃팅 제목으로 사용
어떤 관공서의 사이트에서 CSS를 제거한 모습과 HTML 코드이다. 지금 헤딩태그를 레이아웃팅한 영역의 제목으로 사용하고 있다.
"상단 메뉴", "하단 정보", "하단 링크"가 유의미한 데이터일까?절대아니다.
헤딩태그를 의미없는 레이아웃 영역의 제목으로 사용하고 있다. 실제로 많은 관공서의 사이트의 헤딩이 이런식으로 구성되어 있다. 이러한 방식은 올바르지 않은 사용법이다.
2. 제목이라고 하긴 애매모호한 헤딩
이건 제목이라고 하긴 애매모호한 헤딩들이다. 그 이유는 레이아웃 영역으로써의 의미도 포함이 되어 있기 때문이다. 그러므로 이러한 사용법 또한 올바르지 않은 사용법이다.
3. 메인메뉴 혹은 서브메뉴를 헤딩으로
(아래의 스샷은 재현을 위해 제가 급조한 것입니다.)
위 1번과 2번은 쉽게 이해를 했는데, 3번에 와서는 고개를 갸웃하는 분이 계실 듯하다. 유의미한 데이터를 헤딩태그로 사용했는데 왜 문제가 될까?
그 이유는 메인메뉴(혹은 서브메뉴. 이하 메인메뉴로 통일)의 링크들은 헤딩이 아니기 때문이다.
다시말해 메인메뉴는 현재 보고 있는 콘텐츠의 제목이 아닌 링크들의 집합이다.
역시 어렵다. 쉽게말해 메인메뉴는 헤딩이 아니라 목차인것이다.
그러므로 헤딩태그를 사용하지 말고 그냥 a태그로 마크업을 해야 한다.
4. 레벨링 1) 누락
##시 사이트에서, 자유게시판까지의 메뉴 구조가
##시 -> 시만참여 -> 자유게시판
라고 하자. 그런데 디자인된 페이지에는 "시민참여"가 없다.
그래서 아래와 같이 헤딩을 부여했다.
라는 의문을 가지실 텐데, 상관없다.
작업하는 페이지 내에서의 헤딩만 부여하면 되는 것이다.
그렇다면
<h1>자유게시판</h1>
이렇게 자유게시판을 h1으로 마크업하는 것은 어떨까?
아마 여러분들은 혼란에 빠지실 것이고, 아래 세가지 의견들일 것이다.
h1에는 사이트 제목이 들어가야 하는데..? (페이지당 h1은 한번만 와야 한다)
h1만 넣으면 이 페이지가 어느 사이트(혹은 어느 위치(뎁스))에 있는지 모를텐데..?
페이지에 헤딩태그가 하나만(그것도 h1) 있어도 되는건가?
먼저, 1번 h1에는 사이트 제목이 들어가야 하는데..? (페이지당 h1은 한번만 와야 한다)
이것은 논란의 여지가 많은것으로, 전편에 해석에 따라 견해의 차이가 있다고 한 그 부분에 해당되는 내용이다.
실제로 몇해전 웹 접근성/표준쪽의 유명하신 두분이 이것으로 술자리에서 다투셨던 적이 있다.
그 분들의 의견은
사이트명은 책제목과 같고, GNB의 시작점이기 때문에 h1으로 해야하고, 한번만 와야 한다.
아니다
개인적인 의견은 제작자 맘이라고 생각한다. 즉 "아니다"쪽에 가깝다.
그 이유는 헤딩의 목적은 콘텐츠의 제목을 제공하는 것에 있지, GNB를 나타내기 위해 있는것이 아니기 때문이다.
그렇다면 GNB로써 헤딩을 사용하는 것이 잘못된것이냐? 그렇지도 않다. 페이지의 GNB를 콘텐츠의 제목이라고 생각할 수도 있기 때문이다.
전편에서 예를 들었던 "2분기 실적"은 "2009년 A 사업의 2분기 실적"이기 때문에,
"2009 실적 보고서", "A 사업 실적"도 헤딩이 될 수 있다.
그러므로 제작자 맘이라는 것이다
2번, h1만 넣으면 이 페이지가 어느 사이트(혹은 어느 위치(뎁스))에 있는지 모를텐데..?
이것 역시 헤딩을 GNB로써만 이해했기 때문에 생기는 오해이다. title을 제대로 제공을 했고 정보구조가 제대로 구성되어 있다면 딱히 문제가 되지 않는다는것이 개인적인 견해이다.
3번. 페이지에 헤딩태그가 하나만(그것도 h1) 있어도 되는건가?
문제될 것 없다.
3) 단계
헤딩의 숫자가 의미하는 바는 단계(level)이라고 생각하면 된다.
대메뉴는 제일 큰 헤딩이므로 h1 중메뉴는 두번째로 큰 헤딩이므로 h2 소메뉴는 두번째로 큰 헤딩이므로 h3 이런식으로 레벨링을 하면 된다.
그러므로 대메뉴를 h2, 소메뉴를 h1 이런식으로 정보구조에 위배되게 마크업을 하면 안된다.
5. 중복된 내용 (아래의 스샷은 재현을 위해 제가 급조한 것입니다.)
간혹 보면 사이트의 제목이 헤딩에 항상 따라다니는 경우가 있다.
사이트 제작자가 얼마나 사이트를 사랑하고, 자랑하고 싶어하는지 그 마음이 전해진다.
하지만 이것은 좋은 방법이 아니다.
헤딩의 레벨이 낮아지면, 상단의 레벨에 나오는 내용은 생략해도 된다.
<h1>##시</h1>
<h2>홍보관</h2>
이렇게 마크업이 되었으면
##시의 홍보관
이라고 받아들이면 된다.
즉 레벨이 낮아지면 상위 헤딩의 내용이 접두어로 붙은 것으로 여기면 된다.
헤딩이란
하.. 그럼 도대체 어떻게 헤딩을 하란 말이냐?!
전편에서 했던것 그대로 하면 된다.
너무나도 쉬웠던 그것이 바로 정답이다.
헤딩태그가 너무 간략하다보니 오해가 많이 생기는 것 같다.
그 오해의 근본은 무엇이 헤딩인가? 즉 헤딩의 정의에 있는것 같다.
헤딩태그는 헤딩은 페이지의 제목이다.
절대 아니다. 헤딩태그는 페이지의 제목이 아니다. 헤딩은 페이지의 제목이 아니라 콘텐츠의 제목이다.
더 정확하게 이야기를 하면 섹셔닝된 콘텐츠의 제목이다.
전편에 나왔던 "2009 실적 보고서"를 가지고 예를 들어보자.
현재 내가 보고 있는 페이지는 A사업 실적의 2분기 실적을 보고있다면
대제목: 2009 실적 보고서
중제목: A 사업 실적
소제목: 2분기 실적
이게 바로 전편에서 말한 헤딩이다. 이것을 코드화하면
<h1>2009 실적 보고서</h1>
<h2>A 사업 실적</h2>
<h3>2분기 실적</h3>
이렇게 된다. 이게 아닌 다른것은 헤딩이 되면 안된다.
자, 그럼 상황을 바꿔보자
현재 내가 보고 있는 페이지에는 A사업의 모든 정보가 다 나온다고 하자.
그렇다면 어떻게 헤딩을 구조해야 할까?
대제목: 2009 실적 보고서
중제목: A 사업 실적
소제목: 1분기 실적
소제목: 2분기 실적
소제목: 3분기 실적
소제목: 4분기 실적
소제목: 전년과 비교
소제목: 총평
HTML5가 회자되고 있는 이마당에, HTML의 기초중에 기초인 헤딩태그에 대해서 포스팅한다는 현실이 부끄럽기도 하고 안타깝기도 하지만.. 이렇게 포스팅을 해야 많은 분들이 올바른 헤딩태그를 사용하시리라는 희망을 품으며 몇자 적어봅니다.
전편과 후편으로 나뉘며
전편에는 헤딩태그를 사용했을 때의 장점(전반적으로 시멘틱 마크업에 대한 이야기), 해딩태그의 이해
후편에는 잘못된 헤딩태그 사용예, 헤딩태그 결론에 대해 포스팅됩니다.
2009년 하반기동안 Javascript강의를 많이 다녔는데, 이때 받았던 질문중 기억에 남는 질문은
"헤딩태그를 어떻게 사용해야 할지 모르겠어요"
라는 질문이였다. (Javascript강의인데 HTML을 질문하는 용자의 용기와 호기심에 박수를 보냅니다.;) )
알고보면 매우 간단한 것인데 이 질문을 여러번 받았었다.
아마도 원문에 헤딩태그에 대한 자세한 설명과 예제가 부족해서 그런게 아닌가 하는 생각을 해본다.
접근성을 준수했다는 사이트들도 상당수가 잘못된 헤딩태그를 사용하는 것을 목격하였다.
이제 헤딩태그에 대해 파해쳐보자. 팍팍
팍팍 파해쳐보기 전에..
지금 포스팅된(그리고 포스팅될) 이 글은 견해의 차이가 있을 수 있다.
그 이유는 원문에는 간략한 설명만 있을 뿐 자세한 설명과 예제가 적다.
이로인해 원문을 이해하는데 견해의 차이가 생길 수 있기 때문이다.
이건 마치 성경을 놓고서 사람마다(혹은 종파마다) 해석하는 바가 틀린 것과 같은 이치이다.
자. 자기방어는 이쯤으로 마무리하고, 이제 제대로 한번 파해쳐보자 팍팍.
헤딩을 올바르게 사용했을 때의 장점(시멘틱마크업의 장점)
헤딩을 올바르게 사용하면 SEO가 올라간다.
물런 국내 대형 포털의 검색에는 안걸릴 확률이 아주 높다. 실제로 검색이 되었다 하더라도 검색결과에 나올 확률은 알 수 없다. 그 이유는 다들 알겠지만 검색 방식의 차이와 광고 및 정책 때문이다.
"그렇다면 도대체 어떻게 SEO가 올라간다는 말이냐?"
라는 의문을 품은 분도 계실 것이다.
우리가 종종 착각을 하는것이.. 포털의 검색만 "검색"이라고 착각을 하는데, 사실은 그렇지 않다.
크롤러(혹은 봇. 이하 크롤러로 통일)가 돌아다니면서 수집하는 모든것이 검색이라고 생각해도 무관하다.
크롤러가 정보를 수집해갔다는 행위의 시초가, "검색"이라는 이벤트가 있었기 때문에 정보를 수집해간 것이라 해석할 수 있기 때문이다.
크롤러가 무작위로 정보를 수집해 갔다 하더라도, 수집해간 정보가 언젠가는 노출이 될 확률이 높으므로 이것 또한 긍정적으로 생각할 수 있다.
엄청난 비용을 지불하여 SEO를 올릴 수도 있지만, 간단하게 HTML 코드를 수정함으로써 SEO를 올릴 수 있다는 것이다.
HTML을 수정했다고 엄청나게 SEO가 향상된다고 말하기는 어렵다. 위에 언급했듯이 국내 포털들은 검색에 안걸릴 확률이 높으므로 그렇다. 안하는 것보다 나은 정도의 수준이라고 생각하는 것이 좋을 것이다.
하지만 다행스럽게도 구글에서는 확률이 올라가니 아무 소득이 없는것은 아니다.
사람이 보는 것이 아닌 기계가 알아볼 수 있는 헤딩
그럼 크롤러가 정보를 수집해가는 원리에 대해서 알아보자. 일반적인 크롤러의 경우 HTML을 읽은 후 거기서 키워드를 인덱싱한후 저장하는 방식이다.
여기서 어려운것은 HTML을 분석하여 이 HTML이 어떤 정보를 담고 있는지, 혹은 해당 키워드가 있는지 인덱싱하는 기술이다.
수많은 text중에 어떤 것이 의미가 있는 정보이고 광고이고 쓰레기인지 구분해내야 하기 때문이다.
이 말인즉슨 유의미한 데이터(정보)가 무분별하게 쓰레기와 썩여있다면, 크롤러가 유의미한 데이터를 찾지못하고 넘어갈 수도 있다는 것이다.
시멘틱 마크업
좋은 크롤러라면 모래 속의 진주를 발견해 갈 수 있지만, 이런 기대는 감나무 밑에서 감 떨어지길 기다리는것과 같다.
우리가 유의미한 데이터라고 표시를 해주면 어떻게 될까? 당연히 크롤로가 한결 수월하게 정보들을 수집해 갈 것이다.
이렇게 표시를 할 수 있는 태그중 하나가 바로 헤딩태그이다. 우리가 헤딩태그를 올바로 사용하면 크롤러는 별 어려움없이 유의미한 데이터를 수집해 갈 수 있다.
그 이유는 기본적으로 크롤러들은 head안에 오는 태그들(title 등등)이나 헤딩태그, 강조태그들을 주로 수집해가기 때문이다. (크롤러마다 차이가 있음)
크롤러가 이해할 수 있다면 크롤러가 아닌 다른 녀석도 알아볼 확률이 높아지게 된다.
여기서 다른 녀석은 우리가 흔히 사용하는 브라우저(IE, FF, Opera, Safari, Chrome)가 아닌 다른 브라우저 및 디바이스를 의미한다.
PDA, 모바일 브라우저 뿐만 아니라 사내 터미널 등등 호환성이 넓어지는 것이다. 사실 이것은 웹표준을 준수했을때 생기는 이점이며, 시멘틱 마크업을 했을때 시너지가 생겨 그 효과가 극대화 된다.
기계(HTML을 수집하거나 분석하는 모든것들)가 이해를 해야지만이 SEO도 올라가고, 기계가 이해를 할 수 있으니 다른 디바이스(장치)와도 호환이 된다.
결국은 기계가 이해할 수 있는 마크업을 해야한다는 것이다.
이것이 바로 내가 생각하는 시멘틱마크업이다.
헤딩태그의 이해
많은 분들이 헤딩태그를 설명할 때 책과 비유를 한다. 나 또한 책에 비유를 많이 했었는데
이렇게만 설명하면 이해할거라고 생각했었는데 그것은 내 착각이었다.
많은 분들에게 "책"예를 들면 다들 그때는 고개를 끄덕거리시지만, 막상 사용할려고 했을때 감을 못잡으시는 경우가 허다했다.
하지만 이번에는 책이 아닌 다른것으로 예를 들어 설명을 해보겠다.
바로 문서로 예를 들겠다.
여기저기서 실망감을 표출하며 "그게 그거다", "낚시하냐"라는 원성이 들리지만..
책보다는 문서가 더욱 적절한 예제여서 헤딩태그에 대한 오해를 줄일 수 있을 듯 하다.
수많은 문서 중 보고서를 예를 들겠다.
2009 실적 보고서라고 하자. 그리고 이 실적보고서의 내용을 상상해보자.
각 사업별 실적이 나올 것이고, 전년도 실적과 비교도 할 것이고, 분기별 비교도 있을 것이다.
이러한 것을 목차로 생각해보면
2009 실적 보고서
전체 사업 실적 요약
A 사업 실적
1분기 실적
2분기 실적
3분기 실적
4분기 실적
전년과 비교
총평
B 사업 실적
1분기 실적
2분기 실적
3분기 실적
4분기 실적
전년과 비교
총평
총평
뭐 대충 이런식으로 있게 될 것이다.
그럼 여기서 A 사업 실적의 2분기 실적을 보고 있다고 가정하자.
그렇다면 이 페이지의 헤딩은 어떻게 되야할까?
바로 그렇다. 여러분이 생각한 것이 바로 정답이다.
생각대로 하면 되고~
대제목: 2009 실적 보고서
중제목: A 사업 실적
소제목: 2분기 실적
참 쉽죠잉~?
다음편에는 헤딩태그의 오해와 결론에 대해 적어보도록 하겠습니다.
ps. 왠지 다른 블로거가 헤딩태그 관련해서 글을 썻을거 같은 이 느낌.. ㅠ,.ㅠ
IE7에서 text-decoration: underline 이 이상하게 표현될 때가 있습니다.
조금 더 정확하게 표현을 하자면 밑줄이 제자리에 있지 않는 증상이죠.
font-family가 어떤것이냐에 따라 1px 올라가느냐 2px이 올라가느냐 정도의 차이가 있습니다.
문제의 원인은
vertical-align:middle속성을 가진 DOM이
text-decoration: underline 속성을 가진 DOM과
같은 레벨에 있을때
나타납니다. 아마 IE7의 Bug인것 같네요.
IE7에서 같은 레벨상에 vertical-align: middle의 DOM이 있을경우 text-decoration: underline인 DOM이 이상하게 표현되는 경우
해결책은 아주 간단합니다. vertical-align: middle의 객체를 div같은 display:block으로 감싸주면 되죠. 만약 이 객체의 우측에 위치해야 한다면 float: left로 Positioning을 해주시면 됩니다.
그 외 세세한것들은 디자인에 맞춰서 Styling 하면 되는것이죠.
OS에 상관없이 CSS Editor를 16개나 Review 한 것입니다. 영어의 압박이 있긴 하지만..심심풀이 땅콩으로 볼만한 것 같습니다.
세세하게 둘러보진 않았지만..지금보니.. Mac용 Editor도 많네요. 괜찮아 보이는것들도 있고... 메인 OS가 Windows여서 Windows용이 사실 좋은데.. 왠지 Mac Editor가 더 이뻐보이네요.. 이뻐보여서 그런지 왠지 기능도 더 좋을거 같고;; (Rails랑 svn용으로만 쓰는 불쌍한 내 MacBook의 활용도가 조금 더 올라갈려나;;)
둘러보니 Linux에서도 구동되는 CSS Editor(CSSED)도 있네요!! 그리고 CSS 천재라고 불리는 Eric Meyer가 CSS Editor도 만들었다는 사실도 알았습니다. 듣는순간 촌티가 확 나면서 왠지 안쓰고 싶은 느낌이 드는 이름을 가진 Editor.. 그 이름하여 Eric Meyer’s CSS Sculptor..............;;;
그래도 Eric Meyer인데!! 라는 생각으로 Eric Meyer’s CSS Sculptor 에 들어가는 순간.. 순간 두 눈을 의심하게 되며, 머리속이 하얗지면서 두 손과 어깨의 힘이 쭉빠지게 됩니다. 요즘 흔히들 말하는 "멍~" 때리게 됩니다. 그리고 정확히 2.515초 후에 Scream!!! 하게 될 수 도 -ㅁ-;; (역시 서양인들의 쎈쓰!! ㅎㅎ)
자료(정보)를 담고 있다는 측면에서 보면 웹은 책, 신문 처럼 문서라고 할 수 있다. 그리고 실제로 웹은 문서이다. 책에서 중요한것중 하나는 "좋은 정보를 어떻게 보여줘야 독자들이 잘 이해할 수 있을까?" 라고 생각한다. 가장 중요한것은 장식이 아니라 정보 그 자체이다.
그러므로 정보의 성격을 구분을 해서 문서의 구조를 새우는것이 가장 중요하다. 이렇게 하면 semantic한 마크업을 보다 쉽게 할 수 있게 되고, 이후 작업인 CSS, Javascript도 접근성을 보장하며 작업하게 될 확률이 높아진다.
한마디로 문서 구조부터 생각을 하고 작업을 시작하면 표준을 준수한 결과물이 나오게 될 확률이 높아지는 것이다. (시작이 반..?)
tab menu 의 링크를 각각의 content에 걸어줌으로 인해 quick link의 역활을 수행하여 접근성을 높였고, 각 content 하단에 tab menu로 바로 가는 quick link도 제공함으로 더욱 완성도 높은 접근성이 보장되었다. 하지만 이렇게 보면 전혀 tab menu같지가 않다.
이제는 tab menu스럽게 꾸며보자.
body { font:12px arial; } a { text-decoration:none; } img { border:0; }
/* tab menu */ #tab_menus { margin:0; padding:0; list-style:none; } #tab_menus li { margin-bottom:16px; float:left; padding:0px; } #tab_menus li a { padding:8px 10px; color:#505050; border-width:1px 0 1px 1px; border-style:solid; border-color:#ae9f96; background-color:#eae4e0; background-image:none; font-weight:bold; font-size:0.9em; display:block; } #tab_menus li a:hover { color:black; } #tab_menus li.selected a { border-bottom:0 solid white; background:white url("blt_arrowdown.gif") no-repeat center bottom; color:black; }
tab menu의 a를 block으로 잡고 hover를 주어 onMouse상태일때 Javascript없이도 변화를 줄 수 있게 하였다. #Menu_02, #Menu_03에 display:none을 안 준 것을 궁금해 하는 독자가 있다면, 당신은 천재! Javascript없이도 모든 content의 접근성을 보장하기 위해서다. 이건 조금 후 다시 설명하기로 하고..
자 이제는 마무리. Javascript로 tab menu 동작을 만들자. mootools 1.11(Element.Event, Element.Selectors)을 이용하였다
var selected_menu = 0;
var menus = $$('#tab_menus li'); var contents = $$('div.content'); contents.each(function(div, i) { if (i != 0) { div.setStyle('display', 'none'); } })
menus.each(function(quick_link, i) { quick_link.getElement("a").blur(); quick_link.addEvent('click', function(event) { e = new Event(event).stop(); contents[selected_menu].setStyle('display', 'none'); menus[selected_menu].removeClass('selected');
#Menu_01을 제외한 다른 content들은 가려주었고, tab menu의 박스에 click 이벤트를 걸어줌으로써 toggle 기능이 완성이 되었다. 만약 content들을 CSS에서 가려주었다면(#Menu_02, #Menu_03 display:none) CSS는 render가 되었는데 Javascript가 동작이 안되는 상황이 오면 다른 content에 접근할 방법이 없어진다. Javascript로 원하는 content를 display:block으로 바꿔줘야 하는데 Javascript가 동작이 안되니 tab을 백날눌러도 그 tab의 content는 볼 수 가 없게 되는 것이다.
결론. 결국은 content는 CSS와 Javascipt에 영향을 받지 않게 설계,코딩 되어야 하고 더불어 semantic하게 markup되어야 한다는 것이다.
다운로드 미리보기 (링크걸리는줄 알았는데 그게 아니네요. 아..이럴때 개인서버가 살아있었다면..)
HTML 코딩을 하다보면 어쩔 수 없이 CSS Hack을 사용해야 만 하는 경우가 있다. 저질 IE6만 특별하게 왕따를 시키거나, FF만 특별대우를 해주거나, 혹은 IE6, IE7, FF 각개격파를 하거나.. 일반적으로 비중이 높은것이 IE6왕따시키기, FF 특별대우 해 주기 인데 이것들을 Hack하는 방법은 여러가지가 있겠지만 아주 간단한 Hack 한가씩만 공개(?)를 한다.
먼저 IE6(저질)만 왕따시키기 방법은
IE6에만 적용시킬 CSS를 쓰고
IE7, FF에 적용시킬 CSS는 style name을 쓰고 한 칸 공백을 준 후 /**/(주석) style value를 적어주는 방법이다.
여기서 중요한것은 순서인데 IE6 CSS를 먼저 쓴 후 IE7, FF CSS를 적는것이다. 순서를 바꿔서 IE7, FF CSS을 먼저 적었다면 IE7, FF는 자기들을 위해 마련된 CSS를 적용한 후 IE6 CSS도 적용하면서 덮어씌워지기 때문이다.
IE7에서(6은 확인 못해봤습니다.) fieldset에 legend가 있을때 fieldset에 bgcolor 줄경우 fieldset border 안으로만 bg가 칠해지는게 아니라 legend의 영역까지 fieldset의 bgcolor가 칠해져 버린다.
legend의 bgcolor는 textNode가 있는 부분만 칠해지기때문에 해결책이 되지 못하고 legend width:100% 해도 왼쪽영역은 여전히 fieldset bgcolor가 먹혀져 있게 된다. 여기에 margin-left:-10px;padding-right:10px 같은 방식으로 장난을 쳐보면 해결이 된 것 같아 보이지만 fieldset의 border가 사라져 버리게 된다.
(그림판 역시 최고 ㅠ,.ㅠ)
이럴경우 fieldset position을 relative로 주고 legend의 position을 absolute로 줘서 positioning을 해 주면 해결이 된다. (CSS Position 을 참고)
relative는 parent element를 기준으로 상태 위치로 지정하는 방법이고 absoulte는 절대 위치로 지정하는 방법인데 이를 하게되면 child element가 아닌 절대위치를 가진 element가 되기때문에 floating과 상관없이 해당 element는 붕 떠있는 상태가 된다. (1) parent element에는 아무값을 주지 않고 본인 스스로 relative를 줘도 되지만 이럴경우 자기 자신이 parent에 속해져 있는 상태가 되기 때문에 자신의 width 혹은 height만큼 parent element도 영향을 받게 된다.
(2) 하지만 parent element를 relative를 주고 child element를 absolute를 주게 되면 parent를 기준으로한 절대위치가 된다.
물런 간단히 예를 들어 보자 HTML 코드는 아래와 같다
<div id="parent_element"> Parent Element <div id="child_element">Child Element Line number #1 <br />Child Element Line number #2 <br/>Child Element Line number #3 </div> </div> <div id="absolute_element">Absolute Element</div>
Mac전용 폰트인 Monaco 폰트(dfont)를 트루타입(ttf)로 바꿔도, XP에서는 알리아싱(Aliasing)때문에 안이쁘게 보입니다. 그렇기 때문에 안티-알리아싱(Anti-Aliasing)을 설정을 해야 하는데.. Window + R 키를 눌러서 실행창을 띄운 후, regedit 을 명령해서 레지스트리 편집기를 엽니다.
HKEY_CURRENT_USER\Control Panel\Desktop 에서
FontSmoothing 항목의 값을 2로,
FontSmoothingType 항목의 값을 1로 수정
HKEY_CURRENT_USER\Control Panel\Desktop 에서 FontSmoothing = > 2 FontSmoothingType => 1
로 수정 후 재부팅을 합니다.
그럼 적용된 화면을 보여드리겠습니다. EditPlus에 Monaco / 10 으로 적용했습니다.
xp에서 트루 타입 보정을 줄때 부드러워 보이게 하는 또다른 방법이 있는데.
배경화면에서 마우스 오른쪽버튼을 누른후~ 디스플레이 설정에서. 배경화면의 글꼴을 클리어 타입으로 바꾸어주는게 있었는데. 그걸 바꾸어주니 aptana나 에디터플러스에서 사용하는 폰트도 클리어 타입이 보정 되더라구요 ^_^..
아 그랬던가요..? 그리 오래된 일이 아닌데 기억이 안나에요 ㅎㅎ;;
사실 저렇게 해보니깐 "잘된것처럼"보이긴 하는데, 가끔씩 scroll과 연관되어서 문제가 생겼던걸로 기억이 납니다.
그래서 결국 javascript를 사용했던걸로 기억합니다.
.
.
.
하지만 이렇게 작업했던 부분은 디쟈인에서 걷어냈다죠..ㅠㅠ
var year = _date.getFullYear();
var month = this.month[_date.getMonth()];
var day = _date.getDate();
var hour = _date.getHours();
var min = _date.getMinutes();
var sec = _date.getSeconds();
if(format){
format = format.replace(/y/i, year);
format = format.replace(/m/i, month);
format = format.replace(/d/i, day);
format = format.replace(/h/i, hour);
format = format.replace(/i/i, min);
format = format.replace(/s/i, sec);
스마트에디터오픈하면서 font size 논쟁을 지켜보다가, 과거 제가 겪었던 고민을 공유해보자 글을 써 내려 갑니다.(모두가 한번쯤 생각해볼만한 문제)
폰트 크기를 상대크기로 하면 줌 브라우징을 지원하니 접근성이 향상이 됩니다. 하지만 막상 상대크기로 하고 나면 예상치 못한 문제점들이 발생합니다.
많은 사람들이 브라우져의 글자크기 조절하는 법을 모릅니다. 브라우져 텍스트크기가 보통이 아닌 다른 글자크기로 정의되어 있는데 사이트가 상대크기라면 글자가 갑자기 크게 나오거나, 혹은 작게 나오거나 하겠죠. 이런 상황을 일반적인 사용자가 맞닥뜨리면 기겁을 하며(특히 IE 6) 해킹당한건 아닌지, 바이러스 걸린건 아닌지, 컴퓨터가 고장난건 아닌지 하는 겁이 덜컥 듭니다. 너무 극단적인 예인가요? 하지만 컴퓨터를 조금 아시는 분이라도 당황하기는 마찬가지 입니다.
사용자가 많을 수 록 이러한 문제의 비율은 극격히 높아질 것 이고, 고객센터에 엄청난 질문과 항의가 올라올 것 입니다.(때때론 전화가 올 수 있구요..ㅎㅎ;) FAQ에 올려 있다고 하더라도, 이걸 보는 사용자가 얼마나 될까요..?
대다수의 고객들이 절대크기를 경험에 의한 학습으로 사용해 왔고, 사용하고 있습니다. 회사 입장에서는 모험을 하기보다는, 안정적인 운영을 위해 절대크기로 갈것입니다. (안정적인 운영은 곧 수익창출을 할 수 있는 기반이니깐요)
그럼 결국 줌브라우징이 필요한 소수의 사용자들은 또 배척되는 딜레마 상황이 되어버리죠.. 양쪽 모두를 아우를 수 있는 방법은 없는 걸까요?
IE 6 이 패치되는 방법은 어떨까요? (IE 7 부터는 줌브라우징이 지원됩니다) 패치됬을때 불러올 혼란을 생각하면 끔찍하지만, 가장 확실한 방법이죠. 하지만 MS가 그 무리수를 감당하려 할까요? 애시당초 IE 6 이 줌브라우징을 지원했었더라면..(덤으로 표준도 준수했더라면;;)
고니님과 대화를 하면서 외국계 회사들은 상대크기를 많이 쓰는거에 대해 얘기를 하게 되었는데 고니님은 그 이유를 서체에 있다고 보셨습니다. 영어는 줌브라우징으로 작게해도 알아볼 수 있는 마지막단계가 한글보다 높다는 의견이었는데, 즉 무슨말인고 하니(숫자가 작을수록 글씨크기는 작아진다면) 영어로 사이즈를 2으로 하면 더 이상 알아보기 힘들다고 한다면 한글은 5로 하면 더 이상 알아보기 힘든 사이즈가 되는 것이죠.
상대폰트 쓰면 좋은데, 막상 쓰고나면 이러저러한 문제점들이 생기니...
ps > 이것 말고도 많은 고민들과 문제점이 있을 수 있습니다. 그런것들을 서로 공유를 하면 좋겠습니다. (트랙백 혹은 코멘트로) 이러한 고민들을 서로 공유해 나가는것이 해결책을 찾아 나가는 길이니깐요.
2007/08/01 14:51TRACKBACK FROM Feel the Freeism: To Be 2.0
유니버설 디자인이라는 개념이 있습니다. 웹 접근성을 논하면서 자주 나오는 개념이라고 할 수 있겠습니다(방법론은 아닙니다..) 간단히 설명을 드리면... 유니버설 디자인(Universal Design)은 별도로 개조하거나 특별히 설계하지 않아도 모든 사람들이 최대한 사용하기 쉽게 만들어진 제품과 환경에 대한 디자인을 의미한다.유니버설 디자인의 철학은 그 대상을 모든 사람들(all people) 또는 가능한 많은 사람들(as many people as..
요즘 저도 사이트를 만들면서 5개의 브라우저로 랜더링 테스트를 하면서 작업을 합니다.
IE7, IE6, FF, Opera, Safari...;;;
근데 가만히 생각해보면(기다림님의 글에서 처럼), 표준을 지키지 않는 브라우저 때문에 개발자들이 싸워야 되는 상황이 우습기도 하고 화도 납니다. ㅠ _-) 오페라가 웹 표준을 준수하는 브라우저라고 하지만, 정작 중요한 것은 IE7, IE6 유저가 70%인 상황인거죠.
위의 폰트 크기도 그래서 이래저래 말이 많은거 아닌가 싶습니다.
(단, 한글이냐 영문이냐의 차이로 인한 문제는 별개로 하고 말씀드립니다. ^^;;; )
웹 표준을 지키면 지킨다고 뭐라뭐라~ 어쩔 수 없이 안 지켜도 안 지킨다도 부라부라~
완전 털썩입니다. ^^;
영화에서나 나올법한 말이지만 '정의는 없다' 라고나 할까요? ㅋㅋ
그래서 저는 그냥 핵(CSS hack)을 써서 브라우저 별로 글자크기를 다르게 지정해 버립니다. 기본은 상대 크기로 하지만, 여차 싶어서 아니다 싶으면 그냥 망설임없이 절대 크리고 지정을 해 버리죠(아. 이게 또 상대크기가 옳다는 이야긴 아닙니다. 그냥 제가 그렇다는 겁니다. ^^;; ). 근데 이렇게 또 핵을 쓰면 '핵은 되도록 사용하지 마세요. 표준도 아니고 나중에 문제 생깁니다'라는 의견이 주르륵...;;;;;;;
아하하~ 어쩌란 거지요~ ^ -^);;
아무튼 현 상황은 개인적인 경험과 대세[?!]를 따라서 가장 불편함이 없는 방법을 취하는 수 밖에 없을 것 같습니다. 어쩌면 앞으로도 영원히 말이죠. ㅠㅠ
여기까지 끈기있게 읽으신분들은 "근데 이거 만들어서 어따 쓸려고.." 라는 의문점이 드실거에요.(의문점이 드시면 당신은 천재..!!?? 혹은 동변상련을 느끼시는 분들..??) 이걸 왜 만들었냐하면, Wiki에 쓸 Formatter를 만드는데 거기에 쓸려고 만든 정규식입니다. (Formatter 같은거 만들때 꽤나 유용하게 쓰일 정규식입니다.)
wiki 혹은 punBB같은 Formatter가 있는것들은 내부적으로 문법이 있습니다. 문법따라 여러가지 옵션들이 붙는데 이 옵션을 뽑아내서 처리하는 부분이 필요하죠. 바로 이 문제때문에 만들게 된 것입니다. 무슨말이신지 잘 모르시겠죠?? 그러실것 같아서 아래 예제를 준비했습니다.
와 같은 문법이 있다고 한다면, 각각의 Attribute을 뽑아서 선행처리(Attribute가 옳바른 것인가? 쉽게 말하면 onclick 같은게 있는가..검사하는 등등)해야 하고, Attribute속성에 맞게 다시 수정을 해줘야 합니다.(width, height같은것은 css로 만드는 등등)
이런것에 아주 유용하게 쓰일 정규식입니다.
쓸대없이 두서가 길었네요. Formatter에서 [[image(~~~)]] 는 제거하여 순수하게 Attribute만 남기겠습니다. 그렇게 되면
댓글을 달아 주세요