나라디자인

웹 표준의 나루 명인 인터뷰 소식.

정찬명 — Wed, 16 Jul 2008 16:51:14 +0000

안녕하세요? 정찬명 입니다. 얼마전 블로그 전문 검색엔진 나루에서 웹 표준의 명인이 되었다며 서면 인터뷰를 요청해 주셨습니다. 나루는 온네트에서 지난 5월 런칭한 신생 서비스로서 RSS를 제공하는 블로그만을 전문적으로 찾아주는 독특한 검색엔진 인데요. 정해진 기간 내에 특정 키워드에 대하여 많은 글을 작성하고 조회수가 높게 나타나는 블로거를 나루 명인이라고 소개하고 있습니다. 인터뷰 내용은 나루의 공식 블로그에 ‘웹 표준’의 나루명인 정찬명님 이라는 제목으로 소개되었습니다. 아래 내용은 나루에서 편집하기 전의 원본이어서 나루 공식 블로그에 소개된 본문과는 일부 차이가 있습니다. IT 전문가가 아닌 일반 대중들에게도 웹 표준을 소개하는 자리라고 생각하고 되도록 쉽게 쓰려고 했는데 의도대로 잘 될는지 모르겠습니다. 웹 표준을 어떻게 소개하면 좋을지 함께 고민해주시고 좋은 의견도 부탁드립니다.

키워드 ‘웹표준’의 나루명인으로 선정되신 것을 축하드립니다. 정찬명님의 소개를 부탁드릴께요.: 무척 영광입니다. 나루에서 제 블로그가 검색이 아주 잘 되는 모양이군요. 나루에서는 혹시 웹 표준 지킨 사이트를 더 잘 검색해 주나요? 아참, 저를 소개해야 하는데 이렇게 독자층이 다양한 경우에 자기소개를 하는것이 처음이라서 어떻게 자기소개를 해야할지 조금 고민되네요. 저는 사람들이 ‘웹 퍼블리셔‘ 또는 ‘UI^{User Interface}개발자‘ 또는 ‘프론트 엔드 엔지니어‘ 라고 부릅니다. 웹의 역사가 길지 않아서 아직 저희 직군의 이름이 하나로 정착되어 있지 않고 국가 또는 기업마다 이렇게 다르게 불리워 지고 있습니다. 저는 HTML/CSS/Javascript 라고 하는 클라이언트측 언어(반:서버측 언어)를 이용하여 웹 콘텐츠를 웹 브라우저나 검색엔진이 해석할 수 있도록 설계 합니다. 그리고 사람이 그것을 이해할 수 있도록 의미있게 구성하고 화면에 표시하는 역할을 합니다. 저는 웹 디자이너가 아니며 프로그래머(서버측 개발자)도 아닙니다. 하지만 제가 작성하는 코드에 의하여 웹 페이지의 품질과 성능(사용성, 접근성, 속도)은 크게 좌우 됩니다. 예전에는 웹 디자이너 또는 웹 프로그래머들이 하던 일들이지만 최근에는 이 분야에 대한 고도화가 필요한 기업에서 별도의 직군으로 분리하는 경향이 있고 인력 수요 는 점차 늘어날 것으로 전망하고 있습니다.
웹표준이 무엇이죠? ^^;: 약속입니다. 웹을 개척하거나 이용함에 있어 모든 사람이 차별받지 않고 어떤 장치에서도 이용할 수 있도록 기본적인 규칙을 정해서 웹의 상호 운용성^{Web Interoperability} 을 높이기 위한 목적으로 W3C^{World Wide Web Consortium}에서 제정하고 있습니다. W3C는 시대가 요구하는 웹 기술에 관한 업계의 의견을 수렴하여 표준에 반영하고 업데이트 하는 일을 하고 있습니다.
왜 웹표준을 준수해야 하는건가요?: 웹은 발전속도가 매우 빠른 편인데 나타나는 최신 기술들을 장애인이 이용할 수 없거나 특정 회사의 제품을 사용해야만 이용할 수 있다면 어떨까요? 실제로 장애인들이 이용할 수 없거나 Internet Explorer를 사용하지 않으면 접근할 수 없는 사이트가 많습니다. 웹 표준을 근간으로 하기보다는 특정 회사의 브라우저에서만 잘 보이도록 구축되어서 그렇게 된 것이죠. 웹 페이지 제작자가 웹 표준을 지키면 누구나 어떤 장치(Internet Explorer 이외의 브라우저 또는 휴대장치)를 가지고도 웹에 쉽게 접근할 수 있습니다. 웹 페이지를 이용하는 사람들을 IT업계에서는 흔히 ‘사용자’라고 하는데 ‘고객’이라고 불러야 하는것 아닐까요? 웹 사이트가 동네 마트라면 고객이 슬리퍼를 신고 오든 구두를 신고 오든 휠체어를 타고 오든 누구나 이용할 수 있게 해줘야 하는게 당연한것이라고 생각합니다. 가능한 지켜야 한다는 거죠. 고객의 권리라고도 생각하구요. 세상에는 Internet Explorer라는 브라우저만 존재하는것도 아니고 평균에 해당하는 보통 사람들만 존재하는 것도 아니니까요. 삽화는 대한민국 전자정부에서 Opera 웹 브라우저를 지원하지 않는다는 경고 메시지 인데요. 제 입장에서는 너무 뻔뻔스러운 메시지라고 생각합니다. 이렇게 꽉 막힌 정부에게 문좀 열어달라는 소송도 진행되고 있답니다.
아무리 웹표준을 준수해도 브라우저마다 다르게 보여지는건 어쩔수 없는 것 같습니다. 물론 ‘동일’ 해야 하는 것이 ‘Content’ 라는 것에는 동의합니다만, 그 ‘Content’가 의도한대로 ‘View’ 가 안나오는 경우도 있거든요. W3C의 웹표준과 실무에서의 표준화 작업에는 간극이 있지 않나요?: 웹 표준과 브라우저 호환성^{Cross Browser} 에 관한 질문이군요. 브라우저 호환성이라는 것은 다양한 브라우저 에서 동일한 콘텐츠와 동일한 화면을 제공하는 것을 의미하는데 브라우저 마다 화면표시에 대한 규격이 약간씩 달라서 때로는 1px만 차이가 나더라도 다른 브라우저에서는 화면이 깨진 것처럼 보일 수 있다는게 문제이긴 합니다. 즉, 웹 표준이라는 것은 웹 페이지 제작자들만 잘 지킨다고 해결되는 문제가 아니라는 거죠. 문제가 점점 복잡해 지는데요. 웹 브라우저나 보조공학기기(화면낭독기 등)들도 웹 표준을 잘 지켜야만 비로소 그 혜택이 고객에게 돌아갑니다. 맑은 생수를 더러운 통에 부으면 어떻게 되나요? 다시 더러워지잖아요. 맑은 생수는 깨끗한 통에 부어야 먹을 수 있죠. 그래서 웹 페이지 제작자의 노력도 중요하지만 웹 브라우저 제작사와 보조공학기기 제작사의 표준화에 대한 노력도 반드시 필요합니다. 웹 페이지 제작자가 웹 표준을 잘 지켰지만 웹 브라우저마다 다르게 보이는 것은 웹 브라우저 제작사가 표준에 따라 브라우저를 구현하지 못했기 때문입니다. 고객들이 이런 문제를 피하려면 브라우저를 가장 최신 버전으로 업데이트 하는 것이 좋습니다. 하지만 웹 페이지 제작자는 오래된 구형 브라우저에서 접속하는 고객들을 위하여 하위 호환성을 유지하는데에도 많은 노력을 기울여야 합니다. 웹 표준과 실무의 간극 같은 문제를 이상과 현실의 문제처럼 생각하시는 분들도 많지만 극복할 수 없는 문제는 아니라고 생각합니다. 예전과 다르게 사람들은 다양한 웹 브라우저와 휴대장치를 이용하여 웹에 접근합니다. 웹 페이지의 저작기술도 그만큼 복잡하고 어려워진 것이 사실입니다. 그것은 표준 때문에 발생한 문제가 아니라 접근 환경의 다양성 때문에 발생한 문제 입니다. 또한 웹 표준을 지킨다고 해서 모든것이 해결되지는 않습니다. 웹 표준을 다르게 해석하거나 표준대로 구현하지 못한 브라우저의 다양성도 동시에 해결해야 하는데 그것을 해결하기 위하여 때로는 웹 표준을 준수하지 못하는 경우도 있음을 현재로서는 인정할 수 밖에 없습니다. 그럼에도 불구하고 웹 표준을 지키는 것이 가장 쉽게 문제를 해결하는 방법이라는점은 의심할 여지가 없습니다.
웹표준도 좋지만, 현실적으로 가장 많이 쓰고있는 IE 사용자만 고려해서 잘 만드는게 낫다는 의견도 있습니다. 웹브라우저가 한가지 플랫폼으로 집중된 국내 현실에서 웹표준을 준수함으로써 얻을 수 있는 장점과 야기되는 문제점에는 어떤 것이 있을까요?: Internet Explorer 브라우저만 고려해서 웹을 만드는 것은 정부가 버스 요금을 현찰로만 받겠다고 공언하는것과 다를바가 없습니다. 현찰 없으면 어디 돌아 다니겠어요? 대중교통의 결재 수단을 고객이 선택할 수 있는 것처럼 웹 브라우저도 고객이 선택할 수 있어야 합니다. 웹 표준은 상호 운용성을 증진시키는 역할 외에도 독점을 견재하는 역할을 하기도 합니다. Internet Explorer는 현재 대중적인 브라우저 가운데 가장 점유율이 높고 표준 준수율은 낮은 브라우저였지만 표준 준수율이 높은 대안 브라우저들이 속속 나타나면서 점유율이 떨어지고 있으며 곧 등장하게 될 Internet Explorer 8은 과거의 제품과는 다르게 표준 준수율을 극도로 개선하였습니다. 이렇게 웹 표준은 자유시장의 독점을 견재하고 다양한 비즈니스의 기회를 열어주고 있습니다. 실제로 Internet Explorer 8 제품이 등장하면 그동안 지원하지 않던 표준을 지원하면서 표현할 수 있는 UI 기술의 폭과 성능이 개선되어 비즈니스의 기회도 넓어집니다. 또한 웹 표준을 준수하면 접근성과 사용성이 높아지기 때문에 웹 사이트 이용 고객의 만족도가 높아지고 그것은 해당 기업의 이미지에도 영향을 미칠 것이라고 생각합니다.
화려하고 파워풀한 기능을 우선으로 요구하면서, 웹표준을 엄격히 준수하면 다양한 기능이나 화면을 제공할 수 없다고 고집부리는 Client를 설득할 수 있는 방법을 알려주세요.: 답답 해지네요 ㅡㅡ; 저라고 뭐 별 수 있습니까?(고객은 고객이우~) 하지만 웹 표준을 준수하는 것과 파워풀한 기능이나 화면을 제공하는 것은 완전히 별개의 문제 입니다. 오해를 풀어야죠. 그리고 이제는 ‘장애인차별금지 및 권리구제 등에 관한 법률‘ 때문에 웹 표준을 지키는게 상책이라고 설명해 드리는게 좋을것 같습니다. 웹 표준을 지키게 되면 접근성이 크게 향상되기 때문에 웹 사이트의 장애인 차별요인이 많이 줄어들게 됩니다. 내년²⁰⁰⁹ 4월부터 공공기관 웹사이트들은 장애인 차별요소가 발견되면 피해를 입은 기관이나 개인으로부터 소송을 당할 수 있습니다. 고객이 알지 못하는 현실에 대하여 잘 정리해서 전달해 드리는 것이 좋을것 같습니다. 민간기업은 5년간의 유예기간이 적용되어 2013년 4월부터 이 법의 적용을 받게 됩니다. 기업이 이러한 소송에 휩싸이는 것은 사회적 책임을 다하지 못하고 있다는 현실을 반영하는 사건이기 때문에 미리 예방하는것이 리스크를 효과적으로 줄이는 방법입니다. 기업이 사회적 책임을 다하기 위하여 돌봐야 하는 대상은 오프라인에서만 찾을것이 아니라 이제는 온라인에도 존재하며 그들중 일부는 바로 정보소외계층이라는 점을 강조하고 싶습니다.
정찬명님께서 생각하시는 웹 접근성은 무엇인가요?: 여러 기관이나 학자들의 정의를 모아보면 웹 접근성은 ‘누구나 다양한 환경에서 다양한 장치를 이용하여 제약을 받지 않고 웹을 이용할 수 있는 것’ 이라고 요약할 수 있습니다. 저도 이런 정의에는 이견이 없지만 간혹 웹 접근성을 ‘장애인’을 위한 개념인 것처럼 정의하거나 해석하는 문장에는 동의할 수 없습니다. 저는 좁아터진 주차장에 텅텅 비어있는 ‘장애인 전용 주차장’을 보면서 매우 비효율적이라고 생각하는 사람입니다. 저는 장애인을 위하지도 않고 특별하게 생각하지도 않습니다. 저도 장애인이 될 수 있고 그런 상황이 되더라도 차별받지 않아야 한다는 것에는 동의하지만 장애인을 특별대우 하면서 역차별이 발생하는 상황은 바람직하지 않다고 생각합니다. 저는 지금 우리의 웹에 필요한 궁극의 가치로서 웹 표준이나 웹 접근성 보다는 ‘유니버설 디자인‘ 이 필요하다고 생각합니다. 웹 표준이나 웹 접근성이 유니버설 디자인의 가치를 내포하지 않은 것은 아니지만 유니버설 디자인 철학은 수혜자의 범위가 더 넓습니다. 웹 접근성이 ‘장애인’에게 도움이 된다고 많은 사람들이 말하지만 저는 ‘모든 사람’에게 도움이 되어야 한다는 생각이고 이러한 생각은 유니버설 디자인에 더 가깝습니다. 유니버설 디자인은 사람을 장애인과 비 장애인으로 구분하지 않고 모두를 아우르는 설계를 포함하는 개념으로서 웹 접근성과는 접근방법이 다소 다릅니다.
지난 2006년 세계 전자정부 평가결과 198개국 중 1위를 차지한 우리나라는 유독 웹 접근성 부문은 43위로 크게 미흡한 수준이었습니다. 그 이유가 뭐라고 보시나요?: 2007년에도 1위^English 를 차지했습니다. 종합 성적은 높았으나 접근성 항목의 점수는 0점 이었습니다. 이게 무슨 의미가 있습니까? 전교 1등은 윤리점수 0점 맞아도 되는건가요? 웹 접근성에 대한 기관 공무원의 무지 때문이라고 생각합니다. ‘장애인차별금지 및 권리구제 등에관한 법률’ 덕분에 관계기관 공무원들의 인식이 많이 달라졌다고 하는데요. 2009년의 평가를 다시 기대해 봅니다.
‘웹접근성이 높다’는 것은 어떤 의미인가요?: 제한된 조건에서도 웹 콘텐츠를 이용하는데 무리가 없는 상태를 말합니다. 제한된 조건은 크게 두 가지로 나눌 수 있는데 하나는 신체적으로 핸디캡을 지니게 된 경우이고 다른 하나는 환경적인 요인으로서 주변장치를 사용할 수 없게 된 경우 입니다. 신체적 핸디캡의 대표적인 예는 시각장애나 지체장애를 지닌 경우이며 주변장치를 사용할 수 없게 된 경우는 마우스나 스피커가 없는 경우 입니다. 더 나아가 접근성이 아주 높은 사이트는 색상만으로 정보를 표시하지 않아야 한다는 규칙을 적용하여 흑백으로 인쇄를 하더라도 그래프와 같은 시각정보를 이해하는데 무리가 없을 정도 입니다. 이것은 웹 접근성이 매우 뛰어난 기술수준을 요구하는 것이 아니라 매우 세심한 배려를 요구하고 있다는 것을 의미합니다. 특히 시각장애인은 마우스 포인터를 볼 수 없기 때문에 마우스를 사용하지 않고 키보드만을 입력장치로 사용합니다. 또한 화면낭독기 소프트웨어를 이용하여 글을 듣고 그림에 포함된 대체문자를 소리로 인식하게 되는데 국내 시각장애인 인구중 절반 정도가 이러한 방법으로 인터넷을 이용하고 있다고 합니다. 웹 접근성이 높은 사이트는 보통 키보드 접근성이 좋아서 별도의 장애인 전용 웹 사이트를 제공하지 않습니다. 하지만 국내 공공기관의 경우 별도의 장애인 전용 웹 사이트를 제공하는 것과 ActiveX 형식의 화면낭독장치(TTS:Text To Speach)를 인스톨 하도록 하는것이 장애인을 위한 배려의 기본인듯 오해하는 경우가 많습니다. 장애인에게 별도의 웹 사이트를 제공하는 것은 오히려 장애인을 차별하는 행위(양적 질적 측면에서 일반인과 다른 콘텐츠를 제공하는 행위)이며 별도의 음성출력장치를 제공하는 것은 OS에 설치된 화면낭독기 장치와 음성 또는 키보드 명령이 충돌할 수 있기 때문에 오히려 불편한 장치가 되므로 사용하지 않는편이 좋습니다. 시각장애인은 OS에 설치된 화면낭독기 장치 없이는 윈도우를 부팅하거나 웹 브라우저를 띄우는 등의 행위를 할 수 없기 때문에 인터넷을 이용하는 시각장애인은 모두 자체적으로 화면낭독기를 보유하고 있는 것으로 판단해야 합니다.
‘웹 페이지의 성능을 크게 향상시킬 수 있는 팁’ 중에서 가장 유용한 팁 하나만 알려주세요.: 훌륭한 웹 개발자(서버측, 클라이언트측 모두)를 채용하셔야 한다고 생각합니다. 인사가 만사. 그리고 자바스크립트 코드는 되도록 아래쪽에 넣으세요.
웹디자이너셨다가 Web Publisher가 되신걸로 아는데요, 어떤 계기가 있었나요?: 디자인에 소질이 없었습니다. ㅜㅜ; 사실 디자이너로 근무할 당시부터 디자인보다는 사용성이나 접근성 같은 측면에 더 관심이 많았는데요. 이미 이 계통에서 저보다 더 유명하신 신현석님, 신승식님, 조훈님의 블로그와 한국모질라커뮤니티, CDK^{CSS Design Korea} 라는 커뮤니티를 통해서 웹 표준이나 웹 접근성에 대한 관련정보를 접하게 되었고 그 매력에 흠뻑 빠져버렸습니다. 한편 저는 웹 퍼블리셔의 경계가 현실세계에서는 완전히 명확하지 않다고 생각합니다. 웹 퍼블리셔와 같은 역할을 하는 웹 디자이너도 있고 웹 프로그래머도 있는데 그런 분들이 웹 퍼블리셔가 아니라고 볼수는 없다는 생각 때문입니다.
HTML과 CSS를 두려워하는 웹디자이너들에게 한 말씀 부탁드립니다.: HTML/CSS를 모르는 웹 디자이너는 없다고 생각합니다. 만약 모른다고 말씀하시면 웹 디자이너는 아니실꺼에요. 설사 디자이너가 HTML/CSS를 모른다고 하더라도 디자이너의 창의성을 웹 표준에 끼워 맞추기 위하여 제한하는 것을 저는 원하지 않습니다. 웹 표준이 디자이너의 창의성을 제한하면 안된다는 생각이며 실제로 그러한 문제로 협의가 필요했던 상황은 흔하게 발생하지 않았습니다. 하지만 웹 디자이너가 HTML/CSS를 잘 이해하고 있다면 더 창의적이고 효율적인 디자인이 가능하리라는 것을 확신합니다. 최근 브라우저들이 점점 좋아지면서 표준 코드를 이용하여 표현 가능한 기법이 다양해 졌기 때문입니다. 나아가 디자이너가 유관업무의 특성을 잘 이해하는 것은 업무효율과도 직결되기 때문에 중요하다고 생각합니다. 제가 알고 있는 디자이너 분들은 대부분 HTML/CSS를 자신의 또 다른 경쟁력이라고 생각하고 있었습니다. 알면 알수록 재미있고 매력적이라는 말씀들도 많이 하시더라구요.
웹표준에 대해 공부를 하고 싶은 분들께 추천하고 싶은 도서가 있다면 알려주세요.: 아직 이 분야에 관한 책들이 국내에 많지는 않지만 그렇다고 해서 부족하다는 생각을 하지는 않습니다. 순서상으로 가장 먼저 권해드리고 싶은 것은 ‘실전 웹 표준 가이드‘와 ‘웹 접근성을 고려한 콘텐츠 제작기법‘ 으로서 무료로 배포되지만 가장 기초에 충실한 내용을 다루고 있다고 생각합니다. 그리고 번역서 가운데는 ‘웹 표준 완전정복 세트‘와 ‘웹 표준 교과서‘를 추천 합니다. 자바스크립트분야에도 관심이 있으시다면’DOM 스크립트‘ ‘PPK 자바스크립트‘ ‘자바스크립트 완벽가이드‘를 추천 드립니다.
Web Publisher가 반드시 갖고 있어야할 개념. 혹은, 철학이 있다면 어떤 것이 있을까요?: 이건 정말 멋진 질문인데요. 이런 좋은 질문을 해주시다니 정말 감사합니다. 제가 알고 있는 최고의 말은 바로 이겁니다. "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." -Tim Berners-Lee, W3C Director and inventor of the World Wide Web- "웹의 힘은 보편성에 있다. 장애와 무관하게 누구나 접근하는 것은 필수적인 측면이다." -팀 버너스 리, 월드와이드웹의 창시자이며 W3C 이사-

드림위버 ‘단축키’와 ‘양질전환의 법칙’.

정찬명 — Tue, 08 Jul 2008 16:01:23 +0000

안녕하세요? 정찬명 입니다.

여러분은 대학시절 어떤 동아리 활동을 하셨나요? 저는 생긴것 답게 ‘독서토론동아리’에서 활동했었습니다. 작년 연말 팀 내에서 ‘가장 책을 많이 읽을 것 같은 사람’으로 지목되기도 했었는데 이것이 ‘생긴것 답게’의 증거라고 치죠.(주의:생긴것과 실제 다독률의 현저한 차이) 대학시절에는 책이 너무 좋아서 동아리에 가입했다기 보다는 ‘이제 대학생도 되었으니 책도 좀 읽자’라는 의지가 있었는데요. 기대만큼 그 의지는 따라주지 못했지만 그 때 읽은 책들이 인생관에 적지않은 영향을 주었던것 같습니다. 제가 가입한 동아리에서는 ‘사회과학’서적을 주로 읽었습니다. 특히 유물론을 알기 쉽게 풀어쓴 책들을 재미있게 읽었죠. 저는 오늘의 포스팅을 위하여 다시 유물론 책을 뒤적거렸고 ‘양질전환의 법칙’이라는 말을 찾아 냈습니다. ‘질적인 변화는 양적인 변화에 의해서만 일어난다’ 라는 것이 바로 ‘양질전환의 법칙’이고 오늘의 팁은 여기서 부터 시작하겠습니다.

저희와 같은 직군에서 근무하시는 분들은 HTML/CSS 편집도구(드림위버, 에디트플러스…)를 하루중 얼마나 다루실까요? 하루종일 옆에서 시간을 측정하면서 지켜본 적이 없으니 정확히 알 수는 없지만 추측해 보면 하루중 절반이 넘지 않을꺼라고 생각합니다. 메일 읽어야죠. 성실하게 답장 해야죠. 구두로 대화를 하거나 회의에도 참석 해야죠. 포토샵도 다뤄야 하구요. 어떤 HTML 엘리먼트와 CSS 기법을 사용해야 하는지 창의적인 고민도 해야하고. 4대 브라우저에서 렌더링 테스트도 해야하고. 렌더링된 화면은 디자이너의 시안과 일치하는지 일일이 대조도 해야 하구요. 커피 마시고 담배 태우고 밥도 먹어야죠. 이런 시간들을 제외하고 남는 시간이 편집기를 다루는 시간이 되겠죠. 따라서 저는 하루중 8시간을 근무하지만 실제로 편집툴을 다루는 시간은 4시간 미만일 것으로 추정 하고 있습니다. 이 4시간동안 편집툴을 사용하는 개발자들의 작업 효율은 과연 비슷할까요?

제가 처음 드림위버의 단축키를 과도하게(?) 사용하기 시작한 계기는 위와같은 질문으로부터 시작되었습니다. ‘단순한 작업을 빠르게 처리하면 보다 창의적인 일에 시간을 소비할 수 있다’는 생각이었고 소규모 에이젼시에 근무하던 시절에는 정말로 대부분의 일정을 앞질러 나아갔습니다. 남는 시간에는 관련분야의 전문지식을 읽거나 습득한 지식을 블로그에 포스팅 하는 등 ‘생각대로’하면 되었습니다. 지금은 뭐 남는 시간에는 주로 매일같이 올라오는 ‘BTS’를 해결하고 있습니다만. ㅜㅜ (BTS : Bug Tracking System) BTS는 아무리 해치워도 끝이 없네요.(이게 다 IE 때문이야!) 제가 하고싶은 이야기는 여러분이 ‘질적으로 달라지기 위해서는 반드시 양적인 변화가 필요하다’라는 것이고 하찮아 보이는 드림위버의 단축키 활용은 여러분의 성장에 도움이 된다는 겁니다. 드림위버 단축키 활용법 소개하는데 ‘양질전환의 법칙’까지 들먹거리는건 제가 생각해도 참 유별나다 싶지만 제가 도구 사용법만 알려드리면 별로 재미가 없지 않나요?

이제 시작 할께요! 제가 즐겨 사용하는 단축키를 모두 소개해 드릴텐데요. 이러한 단축키들은 드림위버에서 기본적으로 제공하는 것도 있고 제가 만들어 사용하는 것도 있습니다. 제가 만들어 사용하는 단축키는 우측에 ‘사용자 정의’라고 적어두겠습니다.

엘리먼트 삽입
- div : Ctrl+Alt+D (사용자 정의)
- h1~h6 : ‘Ctrl+1′ ~ ‘Ctrl+6′
- ul : Ctrl+Alt+Shift+U (사용자 정의)
- ol : Ctrl+Alt+Shift+O (사용자 정의)
- li : Ctrl+Alt+Shift+L (사용자 정의)
- dl : Ctrl+Alt+Shift+F (사용자 정의)
- dt : Ctrl+Alt+Shift+T (사용자 정의)
- dd : Ctrl+Alt+Shift+D (사용자 정의)
- a : Ctrl+Alt+A (사용자 정의)
- p : Ctrl+Shift+P
- img : Ctrl+Alt+I
- strong : Ctrl+B
- em : Ctrl+I
- table : Ctrl+Alt+T
- form : Ctrl+Alt+F (사용자 정의)
- fieldset : Ctrl+Alt+S (사용자 정의)
테이블 편집
- 테이블 셀 합치기 : Ctrl+Alt+M
- 테이블 열 삭제 : Ctrl+Shift+’-’
- 테이블 행 삭제 : Ctrl+Shift+M
빠른 이동/선택/삭제
- 단어 단위로 이동 : Ctrl+방향키
- 단어 단위로 선택 : Ctrl+Shift+방향키
- 단어 단위로 삭제 : Ctrl+BackSpace, Ctrl+Del
주석 삽입
- HTML 주석 삽입 : Ctrl+Alt+C (사용자 정의)
- CSS/JS 주석 삽입 : Ctrl+Alt+Shift+C (사용자 정의)
코드 접기/펼치기
- 코드 짝 맞추어 접기 : Ctrl+Shift+C (사용자 정의)
- 선택한 코드 펼치기 : Ctrl+Shift+E
코드 자동완성 : Space, Ctrl+Space
HTML Validation 검사 : Shift+F6
디자인뷰/코드뷰 전환 : Ctrl+`
열린 탭간 이동 : Ctrl+Tab

제가 즐겨쓰는 단축키는 모두 30개 정도이고 직접 만들어서 활용하는 ‘사용자 정의 키’는 13개 로군요. 보시면 아시겠지만 빈도 수가 높은 엘리먼트는 모두 단축키를 할당해서 삽입하고 있으며 직접 타이핑 하는 것은 거의 속성 뿐인데 이마저도 자동완성 기능을 사용합니다. 이것이 바로 제가 현재의 콘텐츠를 마크업하기 위한 최적의 구조를 고민하고 창의적인 CSS 기법에 보다 많은 생각의 에너지를 투자할 수 있는 비법 입니다. 한 순간에 모두 외우려고 하기보다는 필요할 때 마다 하나씩 순차적으로 셋팅하면서 머리보다 손으로 익히시는 것이 효과적 입니다.

사용자 정의 단축키 셋팅은 이렇게 하세요!

File > Keyboard Shortcuts. 키보드 단축키 대화상자를 엽니다.

Current set > Duplicate set. 드림위버의 기본 단축키 셋에 대한 사본을 만듭니다.

Name of duplicate set. 단축키 사본의 이름을 작성 하시구요.

Commands. 단축키를 설정하고 싶은 명령을 찾아낸 다음 나만의 단축키를 만듭니다.

만약 원하는 명령이 어디 숨어 있는지 찾기 어렵다면 Export set as HTML 명령으로 현재 설정된 기본 단축키 목록을 HTML 파일로 내보내기 하세요.

누구나 쉽게 따라할 수 있고 매우 적은 노력으로도 ‘양질전환의 법칙’을 실천할 수 있는 팁이 아닐까요?

제1회 ‘웹 표준 경진대회’ 심사평.

정찬명 — Mon, 23 Jun 2008 19:11:01 +0000

안녕하세요? 최근 CDK(CSS Design Korea)가 주최했던 ‘웹 표준 경진대회‘ 에 심사원으로 참여했던 정찬명 입니다. ‘규칙과 창조의 만남’이라는 멋진 슬로건으로 주최된 행사에는 웹 에이젼시 ‘메가존, 디지털미디어리서치, 에이콘출판사‘ 에서 상품을 후원하고 ‘미래웹기술포럼‘에서 시상행사를 후원하였습니다. 참여했던 선수들에게는 자신의 실력을 마음껏 뽐내고 인정받을 수 있었던 의미있는 날이 되었습니다. 선수로 참여하고자 마음먹고 있었는데 심사원으로 참여하게 되어 ‘아이팟터치‘를 손에 넣을 수 있는 기회를 잃었지만 오히려 더 영광이라 생각하면서 심사평을 공유할까 합니다. 이 대회는 어느날 갑자기 만들어진 것은 아니고 저도 이미 CDK에서 한 두 차례정도 가볍게 언급한 적이 있는데 CDK의 배후세력인 홍윤표님, 조현진님께서 이것을 현실화 해주셨고 저를 비롯하여 신현석님, 김요한님께서 심사원으로 참여하여 진행을 도왔습니다. 물론 이것을 현실화 하고 진행을 돕는일에 참여한 개인들은 어떤 물질적인 대가 없이 모두 자원했다는 점에서 무척 자랑스럽습니다.

‘웹 표준 경진대회’의 의의

국내에는 웹 사이트 저작 기술을 인정받을 수 있는 대회로서 ‘웹 어워드 코리아‘라는 행사가 존재하지만 ‘웹의 표준기술 구현정도‘ 또는 ‘웹 접근성, 보편적 설계, 호환성‘과 같이 ‘정보의 균형있는 분배‘ 가치를 실현하기 위한 기술적 측면은 제대로 검토되지 않고 주로 ‘디자인, 독창성, 콘텐츠‘ 에만 편향되게 집중하는 경향이 있어 그 대회의 권위가 이 계통에서 가히 절대적이라고 인정하기에 부족하다고 생각합니다. 관련글 : ‘Web Award Korea’ 웹의 ‘보편성’ 을 장려하는 평가기관으로 거듭나길(정찬명).

‘웹 표준 경진대회‘는 ‘웹 어워드 코리아‘가 더 나아가야 할 측면을 제시하고 있거나, 또는 전혀 새로운 측면의 가치를 평가하는 대회 입니다. ‘웹 어워드 코리아’가 ‘사지 멀쩡하고 PC 앞에 앉아서 오른손에 마우스를 쥐고 있는 통계적으로 보통사람에 해당하는 사람들에게 얼마나 공헌했는지‘의 여부를 측정하는 대회라면 ‘웹 표준 경진대회‘는 ‘보통사람을 포함하여 신체적으로 핸디캡이 있거나 PC 아닌 다른 접근 장치를 쓰거나 마우스가 없는 사람들에게도 얼마나 공헌할 수 있는지‘ 즉, 얼마나 ‘보편적(Universal)‘ 으로 고려하면서 설계할 수 있는 기술을 지녔는가를 측정하는 대회 입니다. ‘보통사람‘ 또는 ‘소수‘를 위한 기술이 아니라 ‘모두를 위한 기술의 실현‘ 말입니다.

‘웹 표준 경진대회’ 심사 방법

대회에는 모두 18개팀(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18) 30여 분의 선수들이 참여해 주셨고 평가 항목은 다음과 같습니다. 상세한 평가항목이 존재하지만 여기서는 간략하게 적겠습니다.

Markup (35점)
CSS (30점)
디자인 (20점)
기타 -제출일 준수, 자바스크립트의 올바른 사용, 전체적 구성- (15점)

심사원들에게는 디자인 점수(20점)와 제출일 준수 점수(5점)를 제외한 최고 85점을 각각의 사이트에 부여할 수 있게 되었고 ‘잘 한것‘에 대한 가점 없이 ‘적절하지 못한 것‘을 찾아내어 감점하는 방식으로 채점 되었습니다. 표준 스펙을 잘 따르는 것이 ‘잘 한것‘ 인데 이것은 ‘웹 표준 경진대회‘에서 당연한 것이었으므로 가점이 없고 ‘적절하지 못한 것‘에 대한 감점으로 진행한 것은 적절했다고 생각합니다. 디자인 점수는 CDK 회원들의 공개 추천에 의하여 결정되었고 제출일 준수 점수는 제출시각을 초과하여 제출한 팀에 감점하는 방식으로 진행되었습니다.

심사원들은 평가 체크리스트를 기준으로 평가하되 주관적인 평가기준도 가질 수 있었고 주관적인 평가기준에 대하여 다른 심사원이 이의를 제기하지 않는다면 인정하기로 하였습니다. 따라서 심사원 가운데 배점이 후한 사람도 있고 박한 사람도 있었습니다.

사실 배점이 가장 박했던 사람은 바로 저였습니다. 주관적인 평가기준 하나를 예로 들자면 이런게 있습니다. 저는 콘텐츠를 마크업 하기에 가장 적합한 HTML 엘리먼트가 존재한다면 그것을 사용해야 한다고 생각했고 문서 속에 존재하는 HTML Code를 … 엘리먼트로 마크업하지 않았거나, 페이지 하단에 존재하는 저작자(또는 저작권) 정보를

…

엘리먼트로 마크업 하지 않은 경우 감점 처리 하였습니다. 왜냐하면 시멘틱하지 않다고 생각했고 감점처리를 하더라도 이의를 제기할 수 없다고 생각했기 때문입니다.

‘웹 표준 경진대회’ 심사평

과반수 이상의 작품들은 code 엘리먼트를 적절하게 마크업 하지 않았고 address 엘리먼트를 적절하게 마크업한 작품은 단 한 작품 뿐이었습니다. 이 두 엘리먼트들은 의미있는 마크업을 구사할 때 면밀하게 체크하지 않았다면 놓치기 쉬운 부분이었습니다. 그리고 상대적으로 h1~h6, ol, ul, dl, div, strong, em 등의 엘리먼트는 대부분 적절하게 마크업 되었으며 의외로 h1~h6 엘리먼트의 부적절한 마크업 사례가 많이 눈에 띄었습니다.

code 엘리먼트를 적절하게 마크업 한 사례: 이름:
address 엘리먼트를 적절하게 마크업 한 사례: Copyright © cssdesignkorea. All Rights Reserved.

시멘틱한 마크업을 강조하는 이유는 간단합니다. 사람이나 기계가 어떤 code를 검색할 수 있도록 지원하게 되거나 또는 웹 페이지를 인덱싱(또는 크롤링)할 때 자동으로 저작권 정보를 표기할 수 있도록 지원한다면 어떨까요? 현재는 이렇게 표준대로 고지식하게 마크업하는 사례가 적기 때문에 지원해 주는 곳이 없지만 향후 등장하게될 검색엔진들이 이러한 마크업을 이용하지 않으리라는 보장 또한 없기 때문에 시멘틱한 마크업은 확장성이 높다고 말할 수 있습니다. ‘코드 전문 검색, 인용구 전문 검색, 저작권 전문 검색, 문서 제목 전문검색, 강조된 문구 전문검색’ 이런 시시콜콜한 전문 검색엔진이나 검색 옵션이 등장하지 말라는 법은 없으니까요.

사실 가장 중요하면서도 가장 아쉬웠던 부분은 제목 h1~h6 엘리먼트의 마크업 이었습니다. 하나의 페이지에 두 번 이상의 h1 엘리먼트를 사용해도 될지 안될지 이런 쟁점은 논쟁의 소지가 충분히 있기 때문에 감점처리 할 수 없었습니다. 아직 끝나지 않았고 과연 정답이 있을까? 싶은 문제를 주관적으로 판단해서는 안된다고 생각했기 때문입니다. 하지만 다음과 같은 사례는 감점 되었습니다. 논리적이지 않거나 상식적이지 않다고 판단되는 사례들 입니다.

문서 최상위 계층의 제목인 ‘인터넷 웹 콘텐츠 접근성 지침(또는 상응하는 제목)’에 대하여 h1으로 마크업 하지 않은 경우: h1은 현재 문서의 최상위 제목에 대하여 마크업 하는것이 명백하다고 판단 되었으며 대부분 잘 적용 하였지만 h1을 이용하여 최상위 제목을 마크업하지 않은 작품은 감점 되었습니다.
문서를 선형화 했을 때 h1 엘리먼트보다 h2 또는 h3 엘리먼트가 먼저 등장하거나 h1 엘리먼트를 생략한 경우: 최상위 계층의 h1 제목보다 h2 또는 h3가 먼저 등장하는 것은 논리적인 순서가 맞지 않기 때문에 이해하기 어려운 문서가 될 수 있고 h1을 생략한 것은 실수라고 판단 했습니다.
제목의 중간 단계를 건너 뛴 경우: h1으로 최상위 계층의 제목을 마크업 한 다음 h2 엘리먼트 없이 h3 또는 h4가 등장한 경우도 중간 단계를 뛰어 넘었으므로 논리적이지 못한 문서라고 판단했고 감점 하였습니다.

이런 실수 외에도 HTML Validation이나 CSS Validation을 통과하지 못한 페이지도 있었습니다. Firefox의 부가기능인 HTML Validator를 사용 했다면 HTML Validation은 실시간으로 체크할 수 있고, 드림위버의 CSS 브라우저 호환성 검사기능을 이용했더라면 문법적인 오류를 범하는 실수도 간단하게 유추가 되기 때문에 이부분도 다소 아쉬운점 이었습니다.

‘웹 표준 경진대회’수상을 축하드립니다

명예롭게 수상하신 분들께 축하인사를 전해 드립니다. 여러분들이 대한민국 최고 입니다. 주로 CDK 또는 하드코딩하는사람들 커뮤니티에서 왕성하게 활동하시는 분들이 많이 눈에 띄는데요. 그만큼 열정적이고 받을만한 분들이 상을 받으셨다고 생각합니다.

대상(1팀): 김한솔 : 작품보기
금상(1팀): 김군우, 김문정 : 작품보기
은상(3팀): 이원민, 배선, 강선아 : 작품보기; 이길환 : 작품보기; 최준호 : 작품보기
동상(5팀): 김세민 : 작품보기; 추지호, 박아름, 권희숙 : 작품보기; 태임, 임희영 : 작품보기; 정을수 : 작품보기; 서정민, 김영관 : 작품보기

한편 출전은 했지만 수상하지 못한 8개팀 선수분들의 노고에도 격려의 박수를 보내드리고 싶습니다. 올해는 안타깝게 수상까지는 못했지만 내년을 기약해 주세요. 좋은 파트너를 만나지 못해 혼자 출전하면서 디자인 점수를 놓치신 분들도 있고 분명히 훌륭한 마크업과 디자인을 구현 했음에도 불구하고 안타깝게 디자인 분야에서 의외로 추천을 받지 못해서 수상을 놓친 분들도 있습니다. 너무 억울하다 생각하지는 말아 주세요. 제가 마음속으로 응원 드립니다. 사실은 여러분도 상 받을 자격이 충분했었다구요.

아들과 단 둘이 떠나는 첫 자전거 여행.

정찬명 — Mon, 02 Jun 2008 20:44:04 +0000

제게는 4살 된 아들이 있습니다. 항상 자식자랑을 하고 싶은데 팔불출이라는 소리를 듣는것이 두려워서 다른 누군가가 먼저 자녀들 이야기를 꺼내주길 바라는 철없는 아빠 입니다. 오늘은 누가 먼저 이런 이야기를 꺼낸것은 아니지만 특별히 기록하고 싶은 일이 있었습니다. 아들과 처음으로 자전거를 타고 엄마와 떨어져 단 둘이 여행을 하게 된 것이지요.

일주일 가운데 월~금요일은 주로 바깥일에 몰두하는 날이고 토~일요일은 가족과 함께하는 날이라서 주말에는 모두들 집에 있으려고 하지를 않습니다. 직장생활을 하지 않는 아내와 어린이집을 다니는 아들이 주말에도 집에 있는것을 좋아할리 없죠. 주말이면 이렇게 늘 세식구가 함께 외출을 했었습니다. 그런데 이번 주말에는 엄마가 좀 아팠습니다.

엄마가 쉴수있는 여유를 좀 주려고 아들과 단 둘이서 집 밖으로 나갈 생각을 했습니다. 하지만 솔직히 말해서 엄마 없이 아들과 단 둘이 남으면 처음에는 조금 어색 합니다. ‘뭘 어떻게 해줘야 하지?’ 부터 시작해서 ‘이녀석 어떤말을 해야 솔깃해할까?’ 등등.. 아빠로서 엄마의 빈틈을 매워주어야 한다는 강박관념에 사로잡히거든요.

그러다가 생각난 것이 바로 차 대신 자전거를 타고 멀리(?) 여행을 떠나는 일이었습니다. 이 계획은 아들이 초등학교쯤 들어가면 시도해 보려고 마음먹은 일인데 생각보다 빨리 진행 되었네요. 기실은 고작 왕복 6.6km 거리를 다녀 온것 뿐이라서 어디 여행이랍시고 말하기엔 좀 뻘쭘해지는 거리죠.

"아빠, 얼마까지나 더 가야돼요?" 라고 자꾸 묻더군요. 집은 분당구 정자동 한솔주공 6단지이고 목표지점은 분당구 서현역 인근의 ‘콜드스톤‘ 아이스크림 가게 였습니다. 아이스크림은 평소에 피하는 음식중의 하나인데 이곳 아이스크림은 비싸기도 하지만 아이스크림 싫어하는 저도 먹을만 하더라구요. 즉석에서 과일과 쿠키 따위를 넣어 버무려 주는 아이스크림 입니다. 우리 아들도 좋아라 하구요. 3,800원짜리가 제일 작은 컵이고 양도 적은데 이걸 둘이서 배 터지게 먹는답니다. ㅎㅎㅎ.

아들 이름은 ‘아람‘ 입니다. 잘 익은 열매를 뜻하는 한글 이름이지요. 저를 닮아서 사진찍는것도 굉장히 좋아하는데요. 다음에는 자전거 타고 사진여행 하는것도 괜찮을것 같아요. 이녀석 벌써 자기 얼굴만한 SLR 카메라를 번쩍 들고 반셔터 누르는 법을 알더라니까요!

float을 clear하는 4가지 방법.

정찬명 — Mon, 26 May 2008 21:59:28 +0000

CSS 속성 가운데 float 속성은 자기 자신의 위치를 주변의 콘텐츠로부터 상대적으로 배치하는 속성입니다. float은 사전적 의미로 ‘뜨다, 띄우다, 뜨는 물건, 부유물’ 이라는 의미가 담겨져 있습니다. float은 높이가 가변적인 다단 컬럼 형태의 CSS 레이아웃을 위하여 반드시 요구되는 속성으로서 처음 CSS 배치기법을 익힐 때 가장 이해하기 어려운 속성중의 하나 입니다. float 속성이 부여된 엘리먼트는 좌측이나 우측으로 배치되면서 주변 콘텐츠의 배치에도 영향을 미친다는 사실은 어렵지 않게 학습되나 ‘float 된 엘리먼트가 부모 엘리먼트의 높이에 영향을 주지 않는다는 사실’은 몇 번의 경험 또는 선배들의 조언으로 깨닫게 되는 것이지요.

오늘은 float 속성을 이해하고 다단 컬럼형 레이아웃을 시도할 때 주변 엘리먼트들이 원하는 상태로 배치될 수 있도록 이것에 대응하거나 clear 하는 방법에 대하여 공유하고자 합니다. clear 속성은 float이 더이상 주변 엘리먼트의 배치에 영향을 미치지 않도록 해제시키는 속성입니다. 만약 Internet Explorer 브라우저를 사용하여 학습을 시도하신다면 일단 멈추시고 표준계열 브라우저에서 먼저 시도해 보세요. CSS 표준 렌더링을 엄격하게 준수하는 Opera와 Safari를 권장합니다. Internet Explorer와 Firefox 브라우저는 float, clear 속성에 관한 버그를 포함하고 있으므로 float과 clear의 표준 렌더링이 어떻게 구현되는지를 학습할 때 도움이 되지 않습니다. 하지만 버그를 해결하는 방법도 소개되어 있으니 안심하세요.

오늘 글의 핵심은 ‘float된 자식 엘리먼트의 높이를 부모 엘리먼트에 반영하도록 대응하는 방법’ 이라고 한마디로 설명할 수 있겠습니다. 부모 떠난 자식을 다시 부모의 품 안으로 돌아오도록 하려면 어떻게 해야 하는지 한번 살펴 보시죠.

float에 아무런 대응도 하지 않은 상태

#container는 부모 엘리먼트이며 #lnb와 #content는 자식 엘리먼트로서 현재 float된 상태 입니다. 아래 예제는 float에 아무런 대응을 하지 않으면 자식 엘리먼트가 부모 엘리먼트의 높이에 영향을 주지 않는다는 사실을 보여주고 있습니다. #container의 높이가 자식 엘리먼트의 높이를 반영하지 않고 있다는 사실에 주목해 주세요. float에 아무런 대응도 하지 않은 상태의 예제가 준비되어 있습니다.

float에 float으로 대응하는 방법

자식 엘리먼트의 높이를 부모에게 반영하는 방법으로 부모에게도 float 속성을 부여하는 방법이 있습니다. 부모에게 float 속성을 부여하게 되면 부모엘리먼트는 자식 엘리먼트의 높이를 반영합니다. 하지만 부모 엘리먼트의 너비는 float된 두 자식의 너비를 담을만큼만 작게 줄어든다는 사실에 주목해 주세요. 부모의 너비가 브라우저 크기에 따라 가변적이어야 하는 경우에 적용하기 어려운 단점이 있습니다. 또한 조상 엘리먼트들이 겹겹이 존재하는 경우 자식의 높이를 조상 엘리먼트에게 각각 전달하기 위하여 조상 엘리먼트들을 모두 float 시켜야 하므로 일반적으로 사용하는것을 권장하지 않습니다. float에 float으로 대응하는 방법 예제.

float에 overflow 속성으로 대응하는 방법

자식 엘리먼트의 높이를 부모에게 반영하는 방법으로 부모 엘리먼트에 overflow:auto 또는 overflow:hidden 속성을 부여하는 방법이 있습니다. overflow:auto 속성은 자식의 너비가 가변적이고 부모의 너비보다 커지는 상황이 발생할 때 가로 스크롤바를 유발하기 때문에 일반적으로 권장하는 방식이 아닙니다. overflow:hidden 속성은 그러한 상황에서 가로 스크롤바를 유발하지는 않지만 자식의 너비가 넘치는 경우 넘치는 부분이 잘리기 때문에 이 역시 완전하게 안전한 방법은 아닙니다. float에 overflow 속성으로 대응하는 방법 예제.

float을 빈 엘리먼트로 clear 하는 방법

이 방법은 #container 영역이 끝나기 직전 빈 엘리먼트를 넣고 빈 엘리먼트에 clear:both 속성을 부여하여 부모가 자식의 높이를 인식하도록 하는 방법입니다. 하지만 의미 없는 빈 엘리먼트를 사용하기 때문에 이 역시 권장되는 방법은 아닙니다. float을 빈 엘리먼트로 clear 하는 방법 예제. 예제에서는 .clear 라는 빈 엘리먼트를 가시적으로 보이도록 하였지만 실무에서는 보통 .clear {clear:both; height:0; overflow:hidden;} 처리하여 .clear 라는 빈 엘리먼트가 스스로 높이를 갖지 않도록 하고 보이지 않도록 처리 합니다.

float을 가상 선택자 :after로 clear 하는 방법

가장 탁월하다고 생각하는 방법 입니다. 우선 ‘가상 선택자‘라는 개념을 이해하셔야 하기 때문에 약간 상세히 설명드리겠습니다. 여러분들이 익히 알고 계시는 :link, :visited, :hover, :active, :focus는 모두 가상 선택자 입니다. ‘가상 선택자’는 다시 ‘가상 클래스‘와 ‘가상 엘리먼트‘로 구분할 수 있는데요. ‘가상 클래스‘는 특정 엘리먼트에 대하여 아무런 class를 부여하지 않았지만 마치 역동적으로 class를 변경한것과 같은 효과를 낼 수 있는 것들로서 이미 존재하는 엘리먼트에 조합해서 사용할 수 있습니다. :link, :visited, :hover, :active, :focus, :first-child가 가상 클래스에 해당됩니다. 한편 ‘가상 엘리먼트‘란, 존재하지 않는 엘리먼트를 가상으로 생성해내는 선택자로서 :first-line, :first-letter, :before, :after가 있습니다. 심지어 :before와 :after는 HTML문서상에 존재하지 않는 콘텐츠를 출력시키기도 합니다. Hello World Collection이라는 웹 사이트에 신현석님이 ‘Hello World’라는 메시지를 어떻게 출력했는지 살펴보시면 재미있고 이해하기도 쉽죠. 이렇게 가상의 엘리먼트를 생성 #container:after {content:" "} 시킨 다음 display:block; clear:both 처리를 추가하게 되면 의미 없는 빈 엘리먼트를 사용하지 않으면서도 가상 엘리먼트를 이용하여 깔끔하게 float이 clear됩니다. float을 가상 선택자 :after로 clear 하는 방법 예제.

상기 예제로부터 가상 엘리먼트가 스스로 높이를 갖지 않고 화면에 보이지 않도록 처리 하려면 추가적으로 아래와 같이 높이를 제거하고 visibility 속성을 hidden으로 처리 합니다.

#container:after {content:" "; display:block; clear:both; height:0; visibility:hidden;}

하지만 Internet Explorer는 :before, :after 가상 엘리먼트 선택자를 지원하지 않기 때문에 다음과 같은 Hack이 필요합니다.

#container {_height:1%;} /* IE6 및 하위 버전 브라우저 대응 Hack */ *:first-child+html #container {height:1%;} /* IE7 대응 Hack */ #container:after {content:" "; display:block; clear:both; height:0; visibility:hidden;} /* 표준계열 브라우저에 대응하는 float 해제용 가상 엘리먼트의 생성 */

Internet Explorer는 엘리먼트에 높이값을 부여했을 때 min-height 속성을 부여한 것처럼 렌더링하는 특징이 있는데 이때부터 float된 자식의 높이까지 인식하게 되는 버그가 있고 이러한 특성을 이용한 것입니다. Internet Explorer 버그와 관련하여 Wystan님 께서 오류를 지적해 주셨습니다. 정확하게 말해서 #container라는 엘리먼트가 min-height속성을 부여한 것처럼 렌더링 하는 특징은 #container라는 엘리먼트에 height 속성뿐만 아니라 width 속성을 부여하는 경우에도 동일하게 나타납니다. 이것은 IE가 hasLayout이 라는 IE만의 속성을 지니고 있기 때문입니다. 그리고 min-height속성을 부여한 것처럼 렌더링 하는 특징은 IE6 이하 브라우저와 IE7이 조금 다릅니다. #container의 부모 엘리먼트에 높이값이 지정되어 있지 않은경우라면 IE6과 IE7은 min-height 속성을 부여한 것처럼 동일하게 렌더링 하지만 #container의 부모 엘리먼트에 높이값이 지정되어 있는 경우라면 IE7은 min-height 속성을 부여한 것처럼 렌더링 하지 않습니다. 따라서 이 팁은 #container의 부모 엘리먼트에 height값이 명시되어 있는 경우 IE7에서 원하는 형태로 렌더링 하지 않으므로 상황에 맞게 제한적으로 사용하여야 합니다. Wystan님께 감사드립니다.^^

참조

Cascading Style Sheets, level 2 CSS2 Specification - http://www.w3.org/TR/REC-CSS2/
CSS2 규격 한글 번역문 - http://trio.co.kr/webrefer/css2/cover.html
YAML > How Floats Work - http://www.yaml.de/en/documentation/basics/how-floats-work.html
신현석 > CSS Floating and Clearing - http://hyeonseok.com/soojung/web/2005/03/07/123.html

웹 페이지 성능향상을 위한 Javascript 코드의 지연.

정찬명 — Thu, 22 May 2008 16:28:25 +0000

안녕하세요? 오늘은 매우 간단한 방법으로 웹 페이지의 성능을 크게 향상시킬 수 있는 팁 하나를 공유하고자 합니다. 혹시 알고 계셨나요? Javascript코드의 배치를 바꾸거나 간단한 속성을 추가하는 것만으로도 웹 페이지는 더 빠르게 화면을 렌더링 하게 됩니다. Yahoo.com 에 근무하며 High Performance Web Site라는 책을 저술했던 Steve Souders는 친절하게도 자신의 웹 사이트를 통하여 책에 있는 14가지 지침에 대한 예제를 공개하고 있습니다. 그것이 바로 14 Rules for Faster-Loading Web Sites 입니다. 포털의 UI부서에 근무하시는 분들에게는 거의 웹 페이지 성능에 관한 교과서로 읽힌다고 해도 과언이 아닐껍니다. 오늘 소개할 내용은 14원칙중 6번째인 ‘Put Scripts at the Bottom‘편이지만 그 밖의 나머지 지침들도 강력하게 권해드립니다.