Translated with the permission of A List Apart Magazine and the author[s].
이하의 글은 A List Apart Magazine과 저자의 허락아래 번역되었습니다.

“Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8″

성장은 언제나 진통이 따른다. 브라우저도 개발자들이 특정 브라우저나 툴에 맞추게 되면 유저들이 진통을 격게된다. 새로운 브라우저 버전들이 공개되고 몇개의 버그들이나 스팩의 약간의 변화에 사이트들은 깨지게 되고 상사나 유저들이 실망하게 되는 것이다.

몇시간을 들여 왜 사이트가 깨졌는지 설명할수 있겠지만 아예 처음부터 깨지지 않는다면 더 낫지 않겠는가?

약간의 배경

CSS의 상당한 업글을 보여주었던 IE7 의 공개에 힘입어 IE팀은 완전히 새로운 렌더링을 탑제한 IE8(CSS2.1 을 최대한 따른) 개발을 시작했다. 그리고 Acid2 렌더링 테스트를 완벽하게 통과하는 기염을 토해내었다. 이것은 IE가 곧 generated content 와 data URL 을 지원한다는 것 뿐만이 아니라 hasLayout 이 완전히 사라진다는 것을 의미한다. Acid2 를 통과한 사파리나 iCab, Konqueror 그리고 오페라와 렌더링에 있어서 동격을 이룬다고 할수 있다. (Firefox3는 Acid2를 통과했지만 아직 출시되지 않았다.)

이번 새 엔진을 개발하는 동안 IE팀은 IE7 을 공개하면서 받은 여러 비판을 잊지 않았다. 몇몇 표준 구루들과 Microsoft의 몇몇 팬들까지도 IE7 이 버그나 CSS 지원에 있어서 충분하지 못했다고 생각했었고 상당수의 개발자들은 IE7 에서 깨지는 사이트들을 바라보며 불신에 속삭였다. 이에 Roger Johanssen은 자신의 블로그에 IE가 깨지는 3가지의 이유를 나열했지만 IE팀은 4번째 이유까지 발견했다. CSS 레이아웃을 가능케 하는 중요 부분인 Doctype 이 호환성을 지키기 위해서 너무나 부족함을 말이다.

DOCTYPE 스위치는 깨졌다

1998년, Todd Fahrner 가 개발자를 위한 모드와 그외의 사람들을 위한 2개의 랜더링 모드를 가능케 하도록 제안한다. 컨셉은 간단했다. 유저 에이전트(ex 브라우저) 가 표준에 적합한 DOCTYPE 을 포함한다면 제작자가 표준작업을 제대로 알고 한 문서라는 것을 가정하고 “표준”데로(W3C 박스모델을 사용하여) 렌더링을 하는 것이었다. 반대로 DOCTYPE이 명시되지 않았을 경우, “quirks” 쿽스 모드로 인식하여IE5.x/Windows 의 비표준 박스모델로 렌더링 되는 것이다.

이 컨셉은 2년후 IE5/Mac 브라우저에 처음 적용되어 타 브라우저들에 빠르게 퍼져갔다. 표준을 조금이라도 인식하는 개발자들은 이미 ‘validation’ 의 목적으로DOCTYPE 을 삽입하여 사용하고 있었으며 스펙에 따라 렌더링하는 데에는 그 이상을 따르지 않았다. 표준을 상관치 않는 개발자들에겐 DOCTYPE 을 상관치 혹은 몰랐기에 문서가 특별한 모드로 렌더링 되고 있었다.

불행하게도 다음의 두 중요한 사실이 DOCTYPE 이 표준 모드로의 스위치로써 지탱되지 못하도록 하였다.

1. A List Apart 이나 Web Standards Project 등을 통하여 표준을 자각한 개발자들은 완전한 DOCTYPE을 슬슬 삽입하게 되었고
2. IE6가 6년간 렌더링에 변동이 없었으므로 많은 개발자들이 자신들이 맞다고 생각 하게 되었다.

이 두 상황이 Doctype 스위치를 악화한 치명적인 이유는 개발자들이 Doctype을 맞게 쓰는 것이 표준을 올바로 이해하고 렌더링을 제대로 하는 것일 꺼라는 ‘가정’을 했기 때문이다. 왜 실패했는지 어떻게 아느냐고 묻는다면, 바로 IE7이 공개되었을때, 사이트들이 깨진것을 보면 알수 있다.

물론 Roger가 지적했듯이 IE6에 국한된 CSS 핵을 사용했기 때문이기도 하다. 하지만 대부분은 IE6 에서만 사이트 렌더링을 확인한 이유이거나 혹은 가장 많이 사용되는 대표적인 IE6에서만 잘 보여진다면 괜찮다고 생각했기 때문이다. IE6의 불완전함은 문서로 잘 나타나져 있었으니 개발자들이 좀 알고 있었어야 한다고 할지 모르지만 많은 개발자들은 “표준 모드” 의 옵션이 주어지지 않았거나 아예 그 존재조차 모르고 있었다.

IE의 플랫폼아키택인 Christ Wilson 은 IE의 개발의 핵심은 웹을 깨트리지 않는 것이라고 자주 이야기 하곤 했다. 하지만 슬프게도 IE7 은 많은 이들에게 바로 그것을 행해버리고 말았다. 똑같은 실패를 거듭하지 않고자 Microsoft는 Web Stands Project (저자 또한 멤버이다) 와 여러 표준을 인식한 개발자들에게 앞으로 개발자들이 올바른 표준을 준수할수 있도록 도울수 있는 방법에 대해 도움을 요청했다. 목표는 DOCTYPE 스위치 보다 더 뚜렷하며 IE뿐만이 아닌 여러 브라우저들에서도 적용이 가능한 ‘방법’ 을 찾는 것이었다.

완벽을 바라는 미래

작년 SXSW 에서 나는 운좋게도 뉴욕 공립 도서관의 Carrie Bickner 가 진행하는 토론회를 보게되었다. (Carrie Bickner, A List Apart의 Jefferey Zeldman의 부인) “디지털 유산과 Individual Collector 의 보호” 라는 주제 아래 도서관들과 개개인들이 디지털 아카이브를 유지하며 격는 문제점을 토론하고 있었는데, 대부분의 문제들은 꾸준히 업그레이드 되고 있는 파일 포멧들과 어플리케이션들에서 비롯된 것들이었다. Microsoft 오피스 2007을 예로 들면, Word1.0 버전의 문서를 그 당시 의도 했던 것처럼 렌더링, 보여주지 못한다는 것이다. 이 토론회는 나로 하여금 지금까지 웹이 얼마나 변해왔으며 앞으로 웹이 진화하며 얼마나 변화할 것인가에 대해 생각하게 하였다.

웹표준의 지지자의 한사람으로써 브라우저들의 꾸준한 발전과 함께 표준 이행을 꾸준히 개선하기를 원하지만 힘들게 만들어온 웹(테이블 레이아웃 조차도)을 보존하는 것 또한 중요하다고 생각한다. 아직까지는 Doctype 스위치가 괜찮게 돌아가니 그다지 “뒤로돌리는것” 이 어렵지 않겠지만 IE6 의 “표준” 에 맞춘 사이트는 어찌할 것인가? 많은 경우 IE7 이 제대로 렌더링 하지 못한다는걸 우리는 이미 잘 알고 있다. 그렇다면 저자가 원한데로 페이지를 보기위해서는 IE6 브라우저를 언제나 하나씩 가지고 있어야 한다는 말인가? 바로 그것이 수많은 도서관들이 옛 파일들을 보기 위해서, 보존하기 위해서 택한 방법이다. IE8이 점점 다가 오고 있는 가운데 IE7의 렌더링 엔진에 맞춘 문서들이 갖게될 문제들은 앞의 도서관들과 별반 다를 것이 없다. 과연 무엇이 해답인 것인가?

브라우저 버전에 맞추기

이상적인 세상에선 모든 스펙들이 시작에서 부터 유저에이전트들의 해석, 이행까지 완벽할것이다. 그보다 약간 덜 이상적인 버전의 세상에선 브라우저 밴더들이 꾸준히 업데이트 되는 표준들을 즉시 유저에이전트(브라우저)에 적용하여 유저들이 손가락 까딱 하지 않고 최신 버전의 브라우저를 사용 가능토록 할 것이다. 우리 개발자들 또한 최신의, 최고의 기술들을 사용하여 이전 버전 호환성의 걱정 없이 사이트나 어플들을 개발 할 것이다. 하지만 모두가 알다시피 우리의 현실은 그정도 레벨의 완벽에도 가깝지 않다.

표준은 힘들게 개발되고 발전하여 가끔은 몇년씩 걸려 “권고안” 에 상태에 이른다. 브라우저 공개의 사이클은 상품개발이나 마케팅 (보안, 기능 속도등) 과 긴밀하게 연관되어 벤더들이 표준에 직접 참여함에도 불구하고 표준 스펙의 준수는 먼 이야기가 되기 십상이다. 그리고 유저들은 특히 공공기관이나 회사들은 브라우저 업그래이드가 절대 빠르지 않다.

이 모든 요인들은 우리 웹개발자들을 사이트를 제작함에 있어서 곤란하게 한다. 우리가 원하는데로 브라우저가 보여준다는 보장이 어디있단 말인가?

CSS2.1이나 JS1.5 등의 언어의 버전을 명시하는 방법도 있긴 하다. 하지만 불행하게도 브라우저 벤더들은 몇몇 부분들의 스펙들을 적용하며 브라우저들 간의 해석이 다르기도 하니 두개의 동급의 브라우저들 에서 같은 CSS 인데도 완전히 다른 렌더링을 보여주기도 하며 같은 컨트롤이지만 완전히 다른 이벤트를 연출하기도 한다.

이러한 상황 가운데 우리 개발자들에게 주어지는 게런티, 보장, 5년 후나 지금이나 똑같이 해석될수 있는 옵션은 한가지 밖에 없다. 개발 배경이 된 브라우저들 리스트를 명시하게 한 후 해당 브라우저들을 이전 버전들도 지원케 하여 개발자가 원래 계획했던 모습들이 현재 뿐 아니라 미래에도 렌더링 되도록 하는 것이다.

이것이 바로 우리 그룹이 IE8에 제안하기로 결정한 것이며 타 브라우저들에도 적용되기를 바라는 것이다.

syntax 를 간편하게

이 “버전 지정”을 개발자들이 브라우저에 적용함에 있어서 중요하다 생각했던 부분중의 하나는 하드코딩이나 프로그램에 사용함을 쉽게 적응 할수 있도록 하는 것이었다. Conditional 코멘트나 XML 프롤로그, 혹은 HTML 프로필 형식등의 여러 syntax 옵션들을 고려해 보았고 그중 META 메타 엘리먼트 만큼 역할을 잘 수행하는 것이 없었다.

간단한 meta 선언을 삽입하여 우리는 IE8 이 어떠한 렌더링 엔진을 사용하는지 지정할수가 있다. 예를들어 이것을 head 부분에 삽입하면

<meta http-equiv="X-UA-Compatible" content="IE=8" />

IE8에서 새 “Standard Mode”를 사용하여 렌더링 하게 된다. 이 방법은 쉽게 다른 브라우저들도 포함할 수 있다.

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

이 지정법을 쉽게 설명하자면 이 meta 엘리먼트를 사용을 character 인코딩을 지정해 주는것과 같은 방식이다. 이 “버전지정”이 작동하기 위해서는 meta 엘리먼트가 head안에 최대한 상위에 위치해야 하고 타 메타 엘리먼트나 타이틀 엘리먼트가 상위에 위치할수 있으나 타 엘리먼트들 보다 아래에 위치하면 안된다.

요목조목 살펴 보신 분들은 HTTP-equiv 형을 사용한것을 아셨을 것이다. 이 뜻은 서버쪽 해더에도 다음의 삽입시에 같은 효과를 볼수 있다는 것이다.

X-UA-Compatible: IE=8;FF=3;OtherUA=4

또한 함께 사용할수도 있다. 예를들어 header 방법으로 기본락을 전체 사이트에 적용시킨 후에 각각의 필요한 페이지에 meta 엘리먼트를 사용하여 적용 시키는 것이다.

Progressive enhancement은 어디로?

특정 브라우저 버전에 지정하는 “버전지정”은 미래까지도 확실한 사이트 렌더링의 보장이 있지만 그렇다면 progressive enhancement(1)의 콘셉을 깨뜨리는 것일까? 앞으로 우리가 사이트를 만드는 방식을 바꿔야 하는 것일까? 최신 CSS 속성들이 유효할때 즉시 사용할수 있는 것인가 말이다. 이 질문들은 우리가 처음 “버전명시” 를 논의할때 갖고 있었던 많은 질문들 이었다.

예를들어 IE8이 generated content(2) 을 지원하지 않는다고 한다고 가정한 후 (Acid2를 통과한만큼 지원하지만 그저 예를 든것임) IE8을 지정하여 generated content 를 사용한다면 IE외의 타 최신 브라우저들에서는 generated content가 보여질것이고 IE9가 generated content를 지원하더래도 사이트는 IE8에 지정되어 있기에 볼수 없을 것이다. 이 사이트에 “지정” 되어 있는 정보를 IE9로 업데이트 해야 비로소 generated content를 볼수 있는 것인데, 이것은 progressive enhancement의 코어 컨셉을 역행 하는 것이다.

이 progressive enhancement 부분을 포기해야 한다는 것이 상당한 고통인만큼 이 지침은 어찌보면 public-facing 임을 감안할때 최선일지도 모른다. 앞으로 브라우저들이 어떻게 작동할 것인지에 대한 “가정”을 내리면 안되기 때문이다. IE9로의 변화가 조금이라도 사이트의 레이아웃을 깨뜨리거나 스크립트의 지침의 해석을 바꾸게 된다면 유저들에게도 재난일 뿐 아니라 새 브라우저가 나오기전에 잘 보이던 상태로 돌리기 위하여 개발팀 또한 고생해야 할것이다.(이것이 현재 웹의 상태이기도 하다) “버전지정”은 개발팀이 원할때, 새 브라우저에 맞추어야 겠다고 결정을 내렸을때, 특히 새 브라우저 버전에 맞출 시간을 우리 팀이 정하여 원하는 만큼의 시간을 맞추고(새 브라우저 출시 시간에 맞추지 않고) 작업에 착수할수 있다.

그렇다면 “버전지정”은 progressive enhancement의 끝을 말하는 걸까? 현재로써는 no, 아니다. 일단 “버전지정”이 포함되지 않은 버전들의 브라우저들을 앞으로 몇년간 써야 하고 progressive enhancement은 여러 레벨의 CSS와 JS 를 지원하는데 필요한 방법이기 때문이다. 더 나아가 conditional 코멘트를 사용하여 스타일을 구현하고 스크립트를 덧붙여 IE 브라우저들을 사용하는 것을 몇년간 더 해야하기 때문이며 마지막으로 Progressive enhancement 테크닉을 사용한 JS 는 새 브라우저를 준비하는데에 재코딩의 시간을 줄여주기 때문이다.

보너스: “edge”

위험을 감수하며 무모함을 즐기는 이들을 위하여 IE는 “edge” 라는 값을 제공하기로 했다.

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

이 옵션은 권장하지 않으며 사이트를 가장 최신의 IE브라우저로 렌더링을 지정하는 방법이다. IE=1000 이라는 편법을 써서 최신 IE 브라우저를 지정 하는 것 보다는 깨끗한 방법이지 않은가? 하지만 실험용 사이트에 적용 하는것 말고는 edge값을 적용 하는 것은 그리 실용적이지 않을 것이다. 이유는 Eric Meyer 라고 해도(렌더링의 지존) 새 브라우저가 가지고 올 레이아웃이나 스크립트 버그들을 예상할수 없기 때문이다.

미래의 희망

오랫동안 우리 디자이너들과 개발자들은 사이트를 제대로 출력이 가능한 신뢰할수 있는 방법을 고대하고 있었다. 크로스 플랫폼이 가능한 스타일과 스크립트를 짜야하는 두통에다 새 브라우저의 출시와 함께 손도 대 보지 못한곳이 깨지는 아픔을 견뎌야 하고 우리의 클라이언트들과 보스, 그리고 유저들에게 예상치 못한 곳이 깨지는 원인을 설명하는것이 절대 즐겁지도 않다. 하지만 IE8 의 버전지정의 소개와 함께 터널끝에 희망의 빛이 보인다. 나는 다함께 타 브라우저 벤더들도 마이크로소프트와 뜻을 같이 하여 이 기능을 적용했으면 하는 바램이다.

1. Progressive Enhancement - 기본 컨텐츠와 기본 기능들이 모든 브라우저들과 모든 이들에게 접근이 가능케 하며 접근성, 시멘틱 마크업 그리고 외부 css 와 스크립트를 강조하는 컨셉이다.
2. Generated Content - 생성된 컨텐츠. 예를들어 :before나 :after 를 사용하여 컨텐츠를 브라우저가 직접 생산하는 것을 일컫는다.

<link rel="stylesheet" type="text/css" href="print.css" media="print" />

<!-- 혹은 -->
<style type="text/css" media="print">
   @import "print.css";
</style>

<!-- 혹은 -->
@media print {
   /*직접코드 입력 */
}

display:none;

프린트 스타일시트 제작시에는 Law of Elimination, 즉 불필요한 정보 제거 작업부터 시작 하시는 것이 좋습니다. 불필요한 요소들을 먼저 살펴보시고 {display:none;} 에다가 하나씩 더해갑니다. 보편적으로 메뉴부분, 사이드바 부분, 인풋 박스, 광고 등이 해당되겠습니다. 일모리네를 예로 들자면 사이드바, 메뉴, 코멘트부분 알림 해더 등등을 지워버렸습니다.

#sidebar, #menu, #header_special, 
.permlink, .ttag, .ad, 
#commentinputs, #commentwrap h2, 
.comment {display:none;}

배경과 폰트 지정

대충 지우신 후에 기본적인 배경과 폰트지정 으로 넘어갑니다. 폰트 사이즈는 프린트를 위한 pt (point) 단위로 잡으시고 9에서 12 사이로 잡아주시면 되겠습니다. 저는 9pt 로 잡았습니다. 그리고 배경은 transparent 이 default 이지만 혹시나 어딘가에 껴 들어가는것을 미리 방지하는 차원에서 transparent으로 잡아주면 좋겠죠. body의 배경을 흰색으로 잡아주면 마무리 되겠습니다. 또한 브라우저에게 해더 사이즈를 맡겨 놓으면 상당히 크고 낭비가 심하니 직접 h1, h2, h3 사이즈를 잡아주는 것도 좋은 방법입니다. 아시다시피 해더들은 기본적으로 굵게 bold 출력됩니다.

body {font: 9pt/1.5 sans-serif;background: white; color: black;}
/* 참고로 9pt/1.5 는 9pt 폰트사이즈에 line-height 
   줄간격을 1.5배로 하라는 것이 되겠습니다. */

h1 {font-size: 18pt;}
h2 {font-size: 15pt;}
h3 {font-size: 11pt;}

#content {background: transprent;}

글을 글답게 세밀하게

위의 부분만 하셔도 어느정도 문서 분위기가 나겠지만 (ie6 포함) 약간만 더 손을 본다면 더할 나위 없는 프린트 지정이 될수 있습니다. 먼저 링크 부분을 손보겠습니다. 기본색인 파란색도 좋지만 흑백 프린트시에는 별 효과가 없으니 밑줄을 주어 링크를 표기할수 있습니다. 간단히 a {color: black; text-decoration: underline;} 을 주면 되겠습니다. 하지만 밑줄이 혼란스럽다면 밑줄 대신 링크뒤에 주소를 삽입하는 방법을 택하셔도 됩니다. 오래전에 Eric Meyer 가 나누었던 방법입니다.

#content a:link:after, #content a:visited:after {
   content: " (" attr(href) ") ";
   font-size: 90%;
   }

브라우저가 지원만 한다면 (사파리가 아주 잘보이는 군요) #content 안에 있는 링크 뒤에 주소를 출력 하도록 하게 합니다. 하지만 #content 안의 글 제목에도 링크가 붙게되니 글 자체의 블록엘리먼트를 지정해 주어서 글 안의 링크에만 출력되도럭 하는 것이 좋은 방법이겠습니다. 일모리네는 .writing 부분이겠네요. 이러한 방법으로 링크를 지정해 주면 인쇄물이지만 웹주소를 찾아갈수 있는 장점이 있겠습니다.

링크에 스타일을 주었으니 문단에도 스타일을 지정해 보겠습니다. 문단 시작시에 들어짜기, 움푹 들어간 부분의 indentation 을 주어 문단 시작을 표현할수 있습니다. text-indent: 값; 의 형식을 사용하면 되겠네요. 또한 인쇄는 페이지라는 테두리가 있기에 문단이 페이지의 마지막 부분일때에 한줄만 출력되고 다음 페이지로 넘어가는 경우가 있을수 있습니다. 이 때에 orphans를 지정해 주면 orphans 에 지정된 값 데로 문단의 최소 출력이 지정됩니다.

p {text-indent: 13pt; orphans: 3;}

마지막으로 전체적인 여백의 문제나 간격등을 조절해 주면 되겠습니다. content에 margin 값을 준다거나 문단간의 간격 조절등이 되겠네요.

일모리네 print.css 입니다.

body {font: 9pt/1.5 sans-serif;background: white; color: black;}

.left {float:left;}
.picL{float:left;}
.right {float:right;}
.border1 {border: 1px solid #000;}

a {color: black; text-decoration:none;}

h1 {font-size: 18pt;}
h2 {font-size: 15pt;}
h3 {font-size: 11pt;}
p {text-indent: 15pt; orphans: 3;}

#sidebar, #menu, #header_special, .permlink, .ttag, .ad, 
#commentinputs, #commentwrap h2, .comment {display:none;}

#content {width: auto;}
.posttitle {float:left;}
.postdate {float:right;}
.writing {clear:both;}
.writing a {text-decoration: underline;}
h1 a:link:after, h1 a:visited:after, 
.writing a:link:after, .writing a:visited:after {
   content: " (" attr(href) ") ";
   font-size: 90%;
   }
#commentwrap p {text-indent:0;}

즐거운 한주를 보내고 계신가요!? 얼뚱, 쌩뚱. 광복절이라고 태극기 달아봤습니다. 참 어색합니다. 364일 놀다가 하루를… 그래도 하루만이래도 좋은 날로 기념해야겠네요.

P.S. 조용히 진행되고 있는 HTML5 의 인쇄버전을 PDF 로 출력했습니다.

권고안 (Recommendation)이 되기까지 Proposed Recommendation 이 남아있습니다.

W3C is pleased to announce the advancement of “Cascading Style Sheets (CSS) 2.1″ to Candidate Recommendation. Implementation feedback is welcome through 20 December. CSS is one of the Web’s most widely implemented languages. By separating the presentation of style from the content of documents, CSS simplifies Web authoring and site maintenance. CSS 2.1 is derived from and is intended to replace CSS Level 2. A snapshot of usage, the specification brings the language in line with implementations, fixes errata and adds a few highly requested features including the inline-block value for the display property, the color orange and the values pre-wrap and pre-line for the white-space property. Visit the CSS home page. - W3C

요약. CSS2.1이 CR이 되었으니 기쁘다 - W3C

XStandard 2.0 이나 건드려 봐야겠네요.

저도 POSH 를 추구합니다. I LOVE POSH.

이번 2007년 6월1일이 첫 콘테스트 날입니다. CST 로 정오 12PM 이라고 했으니 한국 시간으로 6월2일 새벽 2AM 이 되겠군요.

시간이 허락하신다면 모두 참가하여 좋은 결과 있으시면 좋겠습니다.

저 참가합니다.

Andy Budd는 CSS 의 빠른 성장을 소개하며 CSS3 또한 그러하리라 생각되었었다고 소개 하며 왜 지체되었는가의 글을 시작합니다.

First proposed by Hakon Lie in Oct 1994, CSS1 became one of the first W3C recommendations in Dec 1996. Nipping at its heals, CSS2 became an official recommendation in May 1998, just 18 months later. By June 1999 the first 3 draft modules of CSS3 had been published, and in their ground breaking book published that same year, Bert Bos and Hakon Lie postulated that CSS3 would arrive sometime in late 1999.
Over 7 years later, and we’re still waiting. This begs the question, what went wrong?

요약: Hakon Lie 에 의해 1994년에 제안되어 2년후인 1996년에 W3C의 첫 권고안들중 하나가 된 CSS1 은 다시 2년후에 CSS2 권고안으로 나오게 되었고 18개월 후에는 CSS3의 첫 3개의 드래프트 모듈이 완성되어 Bert Bos 와 Hakon Lie 는 1999년 말 즈음 CSS3 권고안이 나올꺼라 예상했습니다.
7년이상 지난 지금 아직도 기다리고 있습니다. 무엇이 잘못된 것일까요?

이러한 궁금증으로 그는 CSS3 개발의 문제와 이유등을 이해하려 노력했고 어느정도의 답을 얻은듯 여러 문제점을 제기하며 설명하고 있습니다.

일단 많은 부분이 호환성이나 버그 등등의 기술적인 부분이며 또한 정치적인 부분도 없잖아 있다고 소개하고 있습니다. 여러 회사들이 자신의 일정과 계획에 맞추려는 부분이나 여러 반복되는 옛 이슈들도 있으며 지역화 부분에서도 상당한 어려움을 격고 있다고 합니다. 이러한 여러 부분들에서 지체되다 보니 시간적인 환경의 변화도 생겨나고 어려움이 이만저만 아닌듯 싶군요.

W3C has bitten off more than it can chew, and this is having a negative effect on the web.
W3C는 역량 이상을 추구하며 웹에 좋지않은 영향을 주고 있습니다

미래의 완벽함을 추구하다 보니 현재를 잊은듯 하다면서 웹의 기술이 매순간 발전하고 있는 지금 ‘둥근 모서리’ 구현조차 언어로 표현할수 없으니 하루하루 변하는 웹에서 실제적인 필요를 충족해 주는 것이 좋지 않을까 라는 제안을 합니다.

I’ve been thinking about this for a while, and wonder if we need an interim step. If CSS3 is as big and complicated as the development timeline suggests, maybe we need something simpler? Something that gives us designers and developers the tools we need today, and not the tools we need in five or ten years. Maybe we should take all of the immediately useful parts of CSS3 such as multiple background images, border radius and multi-column layout. Maybe we should take all the CSS3 properties, value and selectors currently supported by the likes Safari, Opera and Firefox. Maybe we should take all of this information and build a simpler, interim specification we can start using now. Maybe, just maybe, it’s time for CSS2.2?

요약: 혹시나 우리에겐 작은 스탭이 필요한건지도 모르겠습니다. CSS3 가 만약 상당한 시간이 걸린다면 우리에겐 좀더 간략한 것이 필요한게 아닐까요? 지금 유용하게 사용될수 있는 다중배경이미지나 둥근테두리, multi-column 등의 현재의 개발자와 디자이너들에게 필요한 것들을 쓰는건 어떨까요. 아니면 현재 브라우저에서 지원되고 있는 여러 CSS3 속성들을 사용하게 하는것은 어떨지. 이 모든 정보를 고려하여 지금 쓸수 있는 더 간편한 소단계의 specification 을 내놓는건 어떨까요? CSS2.2 정도?

크게 공감을 느끼는 부분은 정말 그 큰 물고기를 잡으려다 너무 지체되어 후엔 쓸모없는 CSS 가 되지 않을까 하는 우려 입니다. DOCUMENTATION, SEO 등을 앞세워 텍스트 지향적인 부분으로 아직까지 단순한 언어를 붙잡고 있지만 저멀리 앞에 가고 있는 FLASH 를 바라볼때에 정말 언젠가는 결단을 내려야 할 순간이 곧 오지 않을까 라는 생각이 듭니다. 더욱 다양해지는 필요와 사용, 그리고 무궁무진한 가능성을 제공하는 하드웨어들, OS, 프로그램들이 즐비하는 가운데 너무 긴 지체는 ‘웹에 아주 좋지않은 영향’ 이라는 말이 맞다고 생각합니다. XHTML2 만 봐도 그렇습니다. 곧 소개하려 하지만 너무나 많은 지체와 큰 스탭에 HTML5 라는 스팩이 오히려 큰 지지를 받고 있는게 현실입니다.

언제나처럼 의견 부탁드립니다.

internet explorer 에서 max 와 min 너비를 지정해 줄수 있다고 봤지만 min-width 가 에러를 발생한다.

#wrap
{
max-width: 1000px;
width:expression(document.body.clientWidth > 1000? “1000px” : “auto”); }

에러가 나는 min-width
#wrap
{
min-width: 700px;
width:expression(document.body.clientWidth < 700? “700px” : “auto”); }

흠.

참고로 최근 일모리네를 방문한 25,000 명의 해상도를 나눈 그래프다. 40% 가 1280해상도를 사용하고 있으며 23%가 1024 해상도를 사용하고 있다. 하지만 나머지 결과를 살펴보면 모두가 1024 이상의 해상도를 보여주고 있다. 다시 말하면 23%를 뺀 전체방문자의 77%가 1024해상도 이상을 사용하고 있음을 알려준다.

#school #desk {}

식으로 선택되어 값들이 지정되어 있었다. 보통 이러한 절대 선택 부분은 특별히 어느 특정 부분에만 지정값을 주고자 할때 쓰는 방법인데 몇몇 스타일시트에선 대부분의 경로가 절대경로로 되어 있었다.

이 부분이 위험한 이유는 유연성을 0% 로 만들어 버리는 데에 있다. 누구는 타 제작자가 스타일시트를 살펴 볼 때에 좀더 쉽게 알아볼수 있는 장점이 있다고 하지만 아직 스타일시트를 잘 이해하지 못하고 있는 것이다. 오히려 타 제작자와 스타일시트를 공동 제작한다면 서로에게 유연성을 부여해야 하는것이 맞을것이다. 절대경로는 그 반대를 추구한다.

간단한 예로 #school #desk 에서 만약 다른 페이지로 넘어가며 #school 이 아닌 #office 로 바뀌었다고 한다면 #desk값을 아무리 같게 하고 싶더래도 #desk의 값은 0 이다. 스타일시트에서 고른 선택자는 #school 안의 #desk 이기 때문이다. 물론 office 에도 넣고 싶다면 #office #desk 를 또 지정해 주어야 하는 번거로움과 후에 #office가 타인에 의해 또다른 이름으로 바뀌게 될 경우 난감한 경우가 된다.

특히나 class 로 지정된 부분은 더욱 민감하다. class 는 반복적인 선택자를 가능케 하는데 절대 경로를 쓰면 class의 의미가 없어진다.

#desk .pencel

은 아무리 pencel 이 다른 부분에서 반복되어 사용된다고 하더래도 #desk 안의 pencil 밖에 지정이 안되어 있다고 보기 때문에 값은 0 이다.

물론 이 절대 경로를 반대로 사용하면 유용하게 쓰일수 있다. 오래전에 나누었던 body 의 id 를 지정해 주어 여러 특별한 요소를 사용하게 한다거나 .pencil 은 다 붉은 색이지만 #desk 에 지정된 pencil만은 파란색으로 지정을 가능케 할수 있다.

.pencil {color: red;}
#desk .pencil {color: blue;}

비슷한듯 하지만 유연성에 있어서 판이하게 차이가 나므로 절대경로를 선호하는것은 위험성이 있다. 그리고 좋지 않은 습관이다.

스타일시트를 알아 보기 쉽게

이 패턴이 제작자들 안에서 알아보기 쉽게 하기 위한 목적으로 시작되었다면 이 방법 외에 서로 알아보기 쉽게 할수 있는 방법은 없을까? 오래전에 나누었던 방식도 괜찮다. 종속 되는 부분은 타 언어 코딩 방식과 같이 indentation(TAB) 을 사용하여

#desk {}
        #hotwater {}
        #notes {}
                #pencil {}
                #eraser {}
        #chair {}

이런 식으로 표현 할수가 있겠다. 특히 어느정도 html 과 비슷한 틀을 갖는다면 더욱 이해하기 편리하다.

이에 덧붙이자면 세부적인 주석 표기법이다. 약간 코드의 양이 많아 지면 검색을 하여 찾는 빈도가 높아진다. 하지만 header 부분을 찾고 싶지만 #header 를 찾게 되는 번거로움이 있으므로 주석을 달 경우 앞에 =를 붙여주어

/* =header —————— */
라는 방식으로 갈수가 있다. 특정 id 보다 부분을 찾고 싶을때에는 검색시에 =header 를 타입하여 쉽게 구분을 할수 있는 방법이다.

line-height: 을 사용하여 잡아주면 문제없다. px보다는 단순 자연수를 사용하자. 나중에 폰트 크기를 조절할때 line-height은 신경쓰지 않아도 된다.

font-size: 40px; line-height:1;

line-height 은 40px이다.

폰트단위를 em 으로 사용때에도 같은 em으로 line-height을 잡아주기보다는 단위를 지정하지 않는것도 좋은 팁이다.

p.s. Ecto 에서 포스팅

Technorati Tags: explorer, ie, line-height, css, web standard, 폰트

장점? 유용?

장점은 저자가 원하는 간단한 설명이나 간단한 주석 혹은 코멘트를 방문자가 쉽게 알아볼수 있도록 표현이 가능 하다는 것입니다. 책을 읽으면서 이러한 레이아웃을 볼 때에 블로그나 웹컨텐츠에 적용하면 좋겠다는 생각은 했었지만 깊게 생각해 본적은 없었습니다. 어느 특정 위치에 원하는 문구나 덧글은 넣을수 있지만 글을 쓰다가 아무곳이나 원하는 위치에 갯수에 관계받지 않고 side comment를 달아야 한다는 것이 issue 였습니다.

생각해보면 너무 간단 합니다만. ^^ 약간의 float과 negative margin을 넣어서 표현하는 방식입니다. 글을 써가면서 css나 다른것을 건드리지 않는점이 좋은점일수 있겠네요.

예제 페이지를 일단 보시면 이해하기 편하실듯 합니다. 왼쪽의 빨간 부분이 저자의 간단한 코멘트가 달린 부분입니다. 회색은 전체 글이 표현되는 부분이며 흰색은 p 의 문단 부분입니다. xhtml 코드를 직접 보시거나 style을 끄는것이 가능한 브라우저로 보시면 흐름이 어떻게 되는지 이해가 되실겁니다.

사용법

레이아웃에 삽입하는 방법은 간단 합니다. CSS에

.add {float:left; margin-left: -100px; width:80px;}

를 지정해 놓으시고, 글을 쓰다가 주석이나 덧글을 넣어야 하는 부분에 어느곳이나

<span class="add">덧글 내용</span>

를 삽입 하시면 됩니다. img를 삽입하신다면 img의 class 값만 add로 하시면 되겠습니다.

Side Comment에 왼쪽으로 여백을 -100을 주게되면 레이아웃 밖으로 -100px 위치하게 되고 float값 때문에 레이아웃에 영향을 주지 않게 됩니다. 물론 글을 담는 블락엘리먼트의 padding-left 값을 .add 의 margin-left값 보다 많이 주셔야 합니다.

후에 print.css 를 지정해 줄때도 이러한 방식으로 표현하셔도 되고 끄고 싶으시면 display:none;을 넣어주시면 전혀 문제가 없겠습니다.

발전 가능?

물론 이것은 간단한 기본 방법이고 여기서 더욱 개발을 해야겠죠. 혹시 TT 라면 지정값을 만드셔서 [SC] 코멘트 [/SC] 라고 하실수도 있구요. 물론 배포시 기본값을 display:none: 으로 해놓고 스킨제작자가 display: block; 으로 풀어주면 될듯 합니다. 워프라면 첫 페이지는 display:none;으로 되어 있다가 글을 제대로 읽기 클릭시에 display:block 으로 보여주는 방식도 있구요.

이슈가 없는건 아닙니다. Feed Reader에서 모든 CSS 스타일을 끄게 된다고 할 때에 이 부분이 Side Comment 부분 이라는 것을 표현하기가 힘들다는 것입니다. 저는 지금은 단순히 [ 내용 ] 대괄호로 나타내었습니다만, 여러가지 표현의 방법을 생각해 봐야겠네요.

잘만 사용된다면 유저가 글을 읽을시에 상당히 도움이 될꺼라 생각됩니다. 곧(과연 언제…….) 일모리네 레이아웃을 그렇게 바꿀듯 합니다만, 즐거운 레이아웃이 될듯 하네요. both author and the readers ^^

위의 예제를 응용해서 약간 손질을 본 레이아웃 입니다. 확인해보세요 ^^

HAPPY READING~~