한국 웹 사이트들이 거대 인트라넷이 된 것이나 웹 표준 관련 기술들의 발전이 실무자들에게는 그냥 남 얘기인 것은 솔직히 말해서 IE 잘못이 아니다. 그냥 구버전 브라우저일 뿐인 IE6 잘못도 아니다. MS 잘못이다.
IE6을 사용하는 사람들에게 캠페인을 할 게 아니라 MS를 들들 볶아야 한다.
아, 제발… 서비스팩도 좋고 뭐도 좋으니… IE7로 자동 업그레이드 좀 시켜주소. 지금 안되고 있는 게 아니라 심각한 보안 문제처럼 적극적으로 푸시해달란 말이오. 웹 사이트 좀 만들어볼라면 IE6 성능문제 때문에 상상의 날개가 부러진 채로 시작하고 있소. 실버라이트도 좋고 혁신도 좋소. 그 전에 기본적인 것 좀 어떻게 안되겠소?
CDK에서 주최하고
2008년 5월 1일부터 2008년 6월 1일까지 진행된 웹 표준 경진대회에 참석했습니다.
감사하게도 금상을 수상했음에도 불구하고 후기가 좀 늦었네요. 좀 게을러서 정리를 못하고 있다가 이제서야 정리해봅니다. 죄송합니다. ㅠ_ㅠ
대회에는 제가 참여하고 있는 하코사
강남스터디에서 3개의 조로 나누어 그 안에서
비티님과 한 조로 참석하였습니다.
웹 표준에 많은 관심을 가진 디자이너이신 아트강님도 함께 참여하려고 했는데 개인적인 사정이 있으셔서 하차하시어 아쉬웠습니다.
각설하고…
……
상을 받았지만 많이 신경쓰지 못해 부끄러움과 아쉬움이 남는 부분입니다. 그냥 심플하게 만들었어요. (…)
다음의 것들에 신경을 써서 작성하였습니다.
xml:lang, lang 속성)을 부여id, class 속성을 의미있는 단어로 구성.<a rel="license">…</a> 사용다음은 심사결과 감점을 받은 내용들에 대한 변명(?)입니다. ㅋ
h2, h3 단계 부적절텍스트 아닌 콘텐츠의 인식 페이지를 보면
페이지 좌측의 인식의 용이성이라는 지침명과 페이지 우측의 텍스트 아닌 콘텐츠의 인식이라는 항목명을 모두 h2 요소로 마크업 하였는데 이게 감점 요인이었던 것 같습니다.
제 의도는 이 두 가지를 지침과 항목이라는 상·하 개념이 아닌 내비게이션과 컨텐츠라는 개별적인 문서의 최상위 요소 – 사이트 이름 다음 최상위 요소 – 라고 보았던 것이고요.
address 요소 미사용저작자와 관련된 정보라고 요약되는 address 요소, 저작권이 과연 저작자와 관련된 정보일까요?
무조건 아니라고 생각하진 않지만 그렇다라고 단정할 수는 없는 부분입니다.
저작자의 정보는 웹 페이지의 필수 구성 요소가 아니기 때문에 빠질 수 있습니다.
실제로 Web Standards Project, A List Apart 등의 웹 표준 관련 해외 대표 사이트들에는 address 요소가 사용되지 않았으며
저작권 표기에 address 요소를 사용하지 않은 모습을 보여주고 있습니다.
rel 속성은 a 요소에 사용해야 한다.a 요소가 아닌 그 부모 요소인 p 요소에 넣었었답니다. -_-; 덕택에 Markup Validation 오류도 있었군요. ㅋdiv, li 요소의first-child의 대체)을 제외하고 표현을 위한 마크업 – id, class 속성 포함 – 이 없도록 하였습니다.min-width 속성을 지원하지 않는 IE6을 위해
Conditional Comments를 통해
min-width와 같은 동작을 하는
IE 전용 속성(expression)을 사용하였습니다.
이 부분에서 CSS Hack으로 인한 감점이 있었는데
기본 CSS로 구현할 수 없는 부분에 사용된 핵에 대한 감점이 타당한가 하는 의문이 들었습니다.
이 문제를 자바스크립트나 표현을 위한 마크업 등으로 우회하여 해결할 수는 있지만 CSS Hack을
사용한 경우와 크게 다르지 않다는 생각입니다.
로고 부분에 IR을 사용하였습니다. 여기에 또 표현을 위한 마크업이 들어갔네요. ^^;
사용한 방법은 Gilder/Levin Method라고 하는데
이미지가 로드 되지 않았을 경우를 고려한 방법입니다. 그런데 이미지가 로드되지 않는 상황을 고려하지 않았다는 감점 항목이 있었어요. ㅠ_ㅠ
물론 텍스트 확대·축소 시 텍스트 영역을 온전하게 확보하지 못한다는 단점이 있긴 합니다. 그래서 이 정도로… ㅋㅋ
미약하게나마 사이트 이용안내 – 우리네 제작자들 사이에서 accessibility.html이라는 고유명사로 통하죠? – 페이지도 만들어보았고,
심플 그 자체로 만든만큼 접근성 지침에 위배됨이 없도록 제작하였습니다.
외부 사이트로의 링크를 할 수 있는 부분을 다 빼먹는 등의 실수도 있었습니다. ^^;
웹 표준 경진대회와 같은 멋진 행사를 만들어주신 CDK와 관계자 여러분께 감사드립니다.
심사결과에 약간 불만이 있는 부분도 적고 했습니다만…
심사해주신 분들, 행사 진행해주신 분들 모두 수고 많으셨고 2회 때는 조금 더 발전된 대회가 되는 마음에 정리해보았습니다.
늦었지만 참가하신 모든 분들, 진행에 참여하신 모든 분들, 대놓고던 마음 속으로던 응원해주신 분들 모두 좀 짱인 듯 합니다. 더 멋진 2회 웹 표준 경진대회를 기약합니다. ^^
2008년 7월 5일 하드코딩을 하는 사람들 웹 표준 스터디 소모임간의 연합 스터디 시 발표한 자료입니다.
abbr 등)지난 번에 Multiple Backgrounds에 대해 알아보았는데 이에 이어 오늘은 Web Fonts에 대해 써보겠습니다.
웹 폰트는 상당히 오래된 기술입니다. 브라우저 전쟁 시절 IE와 넷스케이프가 각자의 독자적인 기술로 사용했고 IE에는 그 때의 웹 폰트가 아직도 남아있습니다. 그런 과정에서 MS는 웹 폰트에 대한 표준 제정을 제안했고 현재 CSS3의 한 부분이 되었습니다.
오페라의 CTO인 Håkon Wium Lie가 A List Apart에 기고한 CSS @ Ten: The Next Big Thing이 웹 브라우저에서의 웹 폰트 지원과 그 필요성에 대해 설명하였고 현재 사파리 3.1 버전이 이를 지원하고 있습니다. 오페라는 아직 지원하지 않습니다만, 정황 상 곧 지원하겠죠?
파이어폭스의 경우 버그질라의 글을 통해 지켜보고 있습니다만, 파이어폭스3의 일정에는 웹 폰트의 지원이 빠져있습니다. 그러나 브레인 스토밍에 언급된 것은 고무적인 일이고 곧 추가될 것이라는 기대를 갖게 하는군요.
IE의 경우 현재 출시된 IE8 베타에서도 Embedded OpenType만을 지원하고 있습니다. 늘 그렇듯 앞으로의 판도를 예상할 수 있는 정보를 찾을 수 없었죠.
CSS @ Ten: The Next Big Thing에서 쓰인 예제 중 한 개를 사파리 3.1을 통해 보았습니다. 트루타입 폰트를 사용한 예제입니다. 그리고 해당 트루타입 폰트들을 Embedded OpenType으로 변환 후 IE에서 실험해보았습니다.
제법 비슷합니다. 하지만 다릅니다.
다음으로 HY견명조라는 한글 폰트를 본 블로그에 포함시켜서 테스트 해보았습니다. IE에서는 위와 마찬가지로 변환 후 테스트 하였습니다.
XP와 비스타의 윈도우의 폰트 렌더링 기술인 클리어 타입을 적용한 결과입니다. IE에서 사용할 수 없을만큼 투박하게 표시됩니다. 운영체제의 문제라고 생각됩니다만 결론은 비스타의 IE에서도 웹 폰트용으로 특수하게 가공되지 않은 폰트들은 사용할 수 없다는 것입니다. 그다지 좋은 결과는 아니군요. 제가 폰트에 관한 지식이 부족한 관계로 테스트를 잘못 수행한 것은 아닌지 약간은 염려됩니다. 혹시 그런 부분이 있으면 지적 부탁드립니다.
애석하게도 CSS3의 웹 폰트 모듈은 마지막 업데이트가 6년전(2002년)이었고 아직도 Working Draft 상태입니다. 또한 IE는 Embedded OpenType만을 지원하고 있으며, 폰트의 렌더링 또한 우리가 원하는 모양새가 아닙니다.
오페라 진영의 제안과 사파리의 지원이 있었지만 IE와 파이어폭스에서 매끄럽게 사용할 수 있기 전까지는 마냥 기다릴 수 밖에 없을 것 같습니다.
True Font Family에서는 웹 폰트 속성을 대체하는 자바스크립트 라이브러리를 제공하고 있습니다. 자세히 살펴보지는 않았지만 웹 폰트가 점점 정착되어 가는 동안 하위 호환성을 보장할 수 있는 대안이 될 수 있을 것 같습니다. 국내에서는 우리글닷컴이 확대·축소 가능한 웹 폰트를 제공하고 있습니다. 윈도우에서 깨져보이지 않도록 가공된 폰트이죠. (싸이월드나 네이버 등에서 사용하는 가독성 떨어지는 고정 사이즈의 비트맵 웹 폰트랑은 많이 다릅니다.)
조만간 마크업에서 텍스트를 미려하게 표현하기 위한 <img> 태그를 곧 거둬낼 수 있지 않을까 하는 기대를 해봅니다.
웹 퍼블리셔 일을 하면서 가장 짜증나고 마음 아픈 작업이 디자인을 위해 의미 없는 마크업을 넣는 것과 텍스트를 대체한 이미지를 자르고 <img> 태그를 붙이는 일입니다. 어느 웹 퍼블리셔든지 시맨틱한 마크업을 만들고 싶은 마음이 간절하지만 앞서 언급한 문제들로 인해 마크업은 복잡해지고 지저분해집니다. 이미 W3C는 이 문제를 해결할 표준을 만들었는데 그것이 Multiple Backgrounds와 Web Fonts입니다.
라운딩된 가로와 세로 길이가 유동적인 박스 제작해보신 경험이 있으신가요? 이 박스를 CSS2의 Background 속성만으로 제작하려면 많은 고통이 따릅니다. 예를 들어 어떤 <div> 태그로 마크업한 박스를 앞에 쓴 것과 같이 만들려면 추가로 의미없는 마크업을 잔뜩 집어넣거나 자바스크립트를 사용해야 합니다. – 이 경우에도 자바스크립트가 의미없는 마크업을 집어넣는 것은 마찬가지입니다. 대체로 다음과 같은 형식의 마크업이 필요합니다.
<style type="text/css">
div { background: url("left-top.png") no-repeat left top; }
div div { background: url("right-top.png") no-repeat right top; }
div div div { background: url("left-bottom.png") no-repeat left bottom; }
div div div div { background: url("right-bottom.png") no-repeat right bottom; }
</style>
<div>
<div>
<div>
<div>내용</div>
</div>
</div>
</div>이게 뭡니까? (ㅠㅠ)
Multiple Backgrounds가 지원되면 하나의 <div> 태그만으로도 이것을 지원할 수 있습니다. 아무리 복잡한 박스라도 말이죠. 배경 이미지를 몇 십개도 깔 수 있으니까요(실제로 몇 십개를 만들면 안되겠지만요.;;).
<style type="text/css">
div {
background:
url("left-top.png") no-repeat left top,
url("right-top.png") no-repeat right top,
url("left-bottom.png") no-repeat left bottom,
url("right-bottom.png") no-repeat right bottom;
}
</style>
<div>내용</div>아, 얼마나 간결하고 아름다운 코드입니까?
그럼 현재 브라우저들의 Multiple Backgrounds 지원 현황을 알아볼까요?
파이어폭스 개발의 핵심 인물 중 하나인 David Baron은 Multiple Backgrounds에 관해 다른 견해를 가지고 있는 것 같습니다. 좀 난감하지요.
처음 글 쓸 때에서 상당히 많은 변화가 있었습니다. 결국 David Baron이 Multiple Backgrounds를 지원하기로 결정하였고 현재의 Nightly Build인 3.2pre1에서는 실제로 동작합니다.
슬픈 얘기지만 아마도 IE8에 추가되지는 못할 것 같습니다. 파이어폭스의 경우 David Baron의 결정이 나면 바로 추가되지 않을까 하고요. 결국 IE9일까요? IE9라면 4~5년 정도만 삽질하면 되는 걸까요? 하하하;; 그래도 IE9에서라도 추가된다면 3년쯤 후에는 기본적으로 Multiple Backgrounds를 사용하여 마크업을 구성하고 IE8 같은 하위 브라우저를 위해 자바스크립트로 의미없는 마크업을 추가하는 라이브러리를 사용할 수 있겠네요. 이거 뭐 기뻐해야 하는건지 슬퍼해야 하는건지 모르겠습니다.
다음 글에 Web Fonts에 관한 내용이 이어집니다. 기대해주세요. :D
우연히 Acid Test Results on Popular Browsers라는 글을 보게 되었는데 최신 브라우저들의 Acid3 테스트의 점수를 볼 수 있었다. 놀라운 것은 파이어폭스3 베타의 점수였다. 베타 2는 55점, 베타 3는 59점을 기록한 것이다. 호기심에 베타 4를 테스트 해보니 무려 67점을 기록하였다.
IE8은 Acid2 테스트를 통과하였다. 그러나 Acid3 테스트에서는 겨우 17점이라는 초라한 성적표를 보여주었다. 파이어폭스3 베타가 각 버전마다 4점, 8점의 향상을 보여준 것과 대조적으로 IE8은 IE7에서 겨우 3점 오른 것이 전부였다. MS 제품군이 그러하듯 IE8도 파이어폭스3 베타와 같은 계속적인 향상을 보여주기는 힘들지 않을까 생각된다.
파이어폭스3 베타 4의 Acid3 테스트 점수 67점은 오페라 9.50 베타 1의 점수 60점을 뛰어넘었다. 흐뭇한 마음으로 파이어폭스3 베타의 웹 표준 지원 노력이 어디까지 계속될지 지켜보아야겠다. 마음 속으로나마 열렬히 응원한다!
최근 IE8이 Acid2 테스트를 통과했다고 해서 웹 표준 진영이 크게 고무된 바 있다. 그런데 HTML5의 리더인 이안 힉슨(Ian Hickson)이 또 웹 브라우저 제작자에게 또 시련을 주려나 보다. 바로 Acid3 테스트이다.
Acid3을 100% 통과한 웹 브라우저의 화면 스크린샷
Ian Hickson has been working hard on the acid3 test. The new test will focus mostly on ECMAScript and Dom through Selectors Level3, Media queries and data URIs. The new acid3 test isn’t quite ready yet but it should become ready within the coming months.
dustin brewer의 Developers are working on ACID3 test이라는 글에 따르면 새로운 Acid3 테스트는 ECMAScript와 DOM3, CSS3의 Media Queries, data URIs에 초점을 둔 것이라고 한다. Acid2 테스트가 나온지 3년 가까이 지난만큼 그 동안 나온 새로운 웹 표준 기술들에 대한 검증의 필요성이 대두되어 Acid3 테스트가 작성중인 듯 하다.
글을 쓰며 IE8의 Acid2 테스트 통과에 환호하는 현실이 조금 씁쓸한 기분이 든다. 하지만 IE 역시 웹 표준을 적극 수용하려는 자세를 보이고 있는 만큼 Acid3 테스트는 Acid2의 그것보다 훨씬 빠르게 웹 브라우저에 반영될 것으로 기대한다.
아래는 재미로 최신 웹 브라우저들의 Acid3 테스트를 해본 결과이다. IE8의 점수가 궁금해진다. Acid3 테스트는 아직 완료된 테스트가 아니므로 참고만 하자.
| 웹 브라우저 | 테스트 점수 |
|---|---|
| Internet Explorer 6 | 0% |
| Internet Explorer 7 | 0% |
| Firefox 2.0.0.11 | 60% |
| Firefox 3.0b2 | 63% |
| Safari 3.0.4 | 50% |
| Opera 9.25 | 56% |
스스로 웹 표준을 하는 이유에 대해 좀 정리할 필요를 느껴 간단히 적어 보았습니다.
우스갯소리처럼 들리겠지만 사실 그렇지 않다. 어떤 일을 시작하는데 그런 일을 하는 다른 사람들이 모두 A라는 방식으로 일을 한다면 당연히 A로 하는 게 맞지 않는가? B라는 대안을 스스로 찾는다면 그것은 A를 충분히 이해하고 있을 때의 이야기이다. 아직 웹 표준에 대한 이해가 충분하다고는 생각하지 않지만 현재로서는 나도, 다른 이들도 웹 표준에 대한 대안을 가지고 있지 않다. 그리고 적어도 발전안은 있어도 대안은 존재하지 않을 것 같다.
<font size="4"><b>웹 표준 관련 사이트</b></font>
<table cellspacing="0" cellpadding="0" border="0">
<tr>
<td><img src="bullet.gif"> Standard Magazine</td>
<td><img src="bullet.gif"> KWAG</td>
<td><img src="bullet.gif"> Web Standards Korea</td>
</tr>
</table><h3>웹 표준 관련 사이트</h3>
<ul>
<li>Standard Magazine</li>
<li>KWAG</li>
<li>Web Standards Korea</li>
</ul>위의 두 코드는 웹 브라우저에서 시각적으로 같은 결과물을 갖는다. 그러나 웹 표준이 아닌 마크업 – 웹 브라우저의 시각적 결과물에 의존한 – 은 시각적인 결과물 외에는 다른 의미를 갖지 못한다. 단어들 간의 상관관계, 중요도 등이 없기 때문에 시각적 요소를 인지할 수 없는 CUI 기반의 사용자, 스크린 리더 사용자, 기계(검색엔진 등) 등은 웹 표준이 아닌 마크업을 이해하는 데 웹 표준 마크업에 비하여 그 정도가 크게 저하된다.
웹 사이트 전체가 웹 표준이 아닌 마크업으로 구성되어 있다면 앞서 언급한 시각적 요소를 인지할 수 없는 사용자들은 웹 사이트에 표시되는 수많은 단어들을 차례대로 훑어가며 원하는 정보를 찾기 위한 쓸데 없는 노력을 해야 할 것이다. 그것도 그 단어들이 다행이도 텍스트로 되어 있을 때의 이야기지만.
새로이 출시되는 웹 기반 기기나 소프트웨어는 대부분 W3C의 표준 명세를 준수하고 있고 그 비율 또한 증가되고 있다. 웹 표준에 기반한 마크업 문서는 이에 따라 상위 호환성을 갖는다. 그렇지 않은 문서에 비해 웹 표준에 기반한 문서는 그만큼 높은 가치를 갖는다.
이것은 웹 표준을 하는 이유라기 보다는 웹 퍼블리셔를 하는 이유이다. 국내에 "웹 퍼블리셔"라는 직종이 존재하는 이유라고도 여겨진다. 웹에 대한 인식이 부족한 웹 제작자들의 교육을 목적으로, 그 결과물의 보정을 위해 이러고 있다.
장사 하루 이틀 할 것 아니니까 웹 표준 합시다! 구구절절하게 따져보고 싶으시면 토론합시다. Standard Magazine에서 많은 분들에게 다양한 얘기도 들어보시면서 하시면 더 좋겠네요.
끝.
HTML5의 2010년말까지의 일정이 W3C HTML Working Group 페이지에 공개되어 있습니다. 이하 공개되어 있는 일정입니다. 자세한 사항은 HTML Working Group Charter에서도 확인 가능합니다.
현시점에 HTML5는 W3C에 있어 Editor’s Draft입니다만, 내년부터 초안(Working Draft)가 되어, 2010년에는 권고(Recommendation)이 되는 일정을 예상하고 있습니다.
현단계의 W3C의 HTML5 Editor’s Draft (WHATWG에서는 Working Draft)에는, 아직 완성되지 않은 목차가 많이 있어, 나날이 눈에 띄일 정도로 업데이트 되고 있습니다만, 내년이래, Working Draft로서 일단 완성된 모습이 될 듯 합니다.
지난 수요일 시작된 email standard project과 관련하여 국내 유명 웹메일 CSS 지원 테스트를 올렸었는데 그새 다음(daum)의 CSS 지원의 향상이 있었다. 지금 막 확인한 사항이지만 테스트 시 지원하지 않거나 불완전하였던 background-image와 list-type-image의 지원이 추가되었다.
메일 컨텐츠 중 어떤 태크나 ID 값에 “x-” 라는 prefix를 붙였었는데 그 대상을 크게 줄인 결과인 것 같다(확인한 바로는 meta 태그에만 붙이는 것으로 변경되었다). ESP의 효과인지는 알 수 없지만 다음(daum)의 이번 변화는 훌륭한 것이라고 생각된다. 이제 모든 화살을 네이버에게…ㅋㅋ
다음(daum)은 이제 default CSS에 의해 덮어씌여진 font-family 속성을 사용할 수 있도록 수정하면 ESP의 추천사항을 전부 충족할 수 있다. cheer up!
웹 사이트 개발을 하다보면 하나의 폼에 여러 개의 제출 버튼을 써야하는 경우가 있다. 그 경우 자바스크립트를 사용하지 않고 원하는 기능을 구현하려면 어떻게 해야할까? IE의 버그로 인해 여러 방법 중 대부분이 사용이 어렵지만 submit 타입의 input 태그를 여러 개 넣어서 폼을 구성하면 버그 없고 자바스크립트 의존적이지 않은 결과물을 만들 수 있다.
그럼 실제로 각 글에 체크박스가 있어서 체크 후 삭제 혹은 이동하는 기능이 있는 게시판 목록을 만들어보자. 결과물은 다음의 그림과 같을 것이다.
그림을 보고 HTML 페이지를 만들어보자.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ko">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>여러개의 폼 제출 버튼 예제</title>
</head>
<body>
<form action="test.html">
<h1>여러개의 폼 제출 버튼 예제</h1>
<table summary="게시판 목록">
<thead>
<tr>
<th>선택</th>
<th>제목</th>
<th>작성자</th>
<th>작성일</th>
<th>조회수</th>
</tr>
</thead>
<tbody>
<tr>
<td><input type="checkbox" title="1번글 선택"
name="check1" value="Y" /></td>
<td>게시판 제목1</td>
<td>아무개</td>
<td>2007년 10월 13일</td>
<td>4</td>
</tr>
<tr>
<td><input type="checkbox" title="2번글 선택"
name="check2" value="Y" /></td>
<td>게시판 제목2</td>
<td>아무개</td>
<td>2007년 10월 13일</td>
<td>4</td>
</tr>
<tr>
<td><input type="checkbox" title="3번글 선택"
name="check3" value="Y" /></td>
<td>게시판 제목3</td>
<td>아무개</td>
<td>2007년 10월 13일</td>
<td>4</td>
</tr>
<tr>
<td><input type="checkbox" title="4번글 선택"
name="check4" value="Y" /></td>
<td>게시판 제목4</td>
<td>아무개</td>
<td>2007년 10월 13일</td>
<td>4</td>
</tr>
</tbody>
</table>
<p>
<input type="submit" name="delete_selected"
value="선택된 글 삭제" />
<input type="submit" name="move_selected"
value="선택된 글 이동" />
</p>
</form>
</body>
</html>선택된 글 삭제와 선택된 글 이동 버튼을 submit 타입의 input 태그로 주고 각각에 name 속성을 부여하였다. 여기에서 1번글을 선택하고 선택된 글 삭제 버튼을 누른다면 제출된 값은 다음과 같을 것이다.
check1 = "Y"
delete_selected = "선택된 글 삭제"마찬가지로 이동 버튼을 누른다면,
check1 = "Y"
move_selected = "선택된 글 이동"위와 같은 값이 제출될 것이다.
"선택된 글 삭제"와 같은 값을 다른 원하는 임의의 값으로 줄 수 없을까? 답은 불가능하다. 화면에 보여지는 값을 그대로 사용해야 한다. 이 것이 필자가 설명한 방식의 한계이다. 개발자들은 보통 "Y" 혹은 "delete"와 같은 명확한 코드 형식의 단어를 사용하고 싶어할 것이다. 하지만 자바스크립트를 사용할 수 없는 사용자들의 불평을 듣고 싶지 않다면 현재로서는 어쩔 수 없다. IE(IE7 포함) 사용자는 submit 타입의 input 태그 외에 submit 타입의 button 태그나 image 타입의 input 혹은 button 태그에 name 속성을 통해 제출 값을 구분할 수 없기 때문이다.
이미지 버튼일 경우는 어떻게 하나? image 타입의 input 태그를 사용할 수 없다면? 답은 Image Replacement이다. Image Replacement를 사용할 수 없는 상황이라면 폼 제출 버튼을 이미지 – 배경 이미지 제외 – 로 하지 않는 디자인을 고려해보아야 할 것이다.
<style type="text/css">
input.delete-selected {
width: 100px;
height: 20px;
background: url(delete_selected.gif) no-repeat;
text-indent: -5000px;
}
input.delete-selected {
width: 100px;
height: 20px;
background: url(move_selected.gif) no-repeat;
text-indent: -5000px;
}
</style>
<!-- 중략 -->
<p>
<input type="submit" class="delete-selected"
name="delete_selected" value="선택된 글 삭제" />
<input type="submit" class="move-selected"
name="move_selected" value="선택된 글 이동" />
</p>글의 코드는 아래의 첨부파일을 다운로드를 통해 실행해볼 수 있다.
페이징 기능을 포함한 게시물 리스트 화면이나 Breadcrumb 구조 등 다수의 공통적인 파라미터를 가지고 다녀야 하는 경우가 있다. 이 경우에 쓰이는 방법이 여러가지가 있는데 일반적으로 서버 사이드 스크립트를 통해 공통적인 파라미터를 묶어서 여러 개의 관련 링크에서 일관적으로 적용하도록 하는 방법이다. 그런데 다음과 같은 HTML 코드를 만들어내는 경우가 있다. (common1~3을 공통적인 파라미터라고 가정한 게시물 보기 화면) Breadcrumb 구조 등 다수의 공통적인 파라미터를 가지고 다녀야 하는 경우가 있다. 이 경우에 쓰이는 방법이 여러가지가 있는데 일반적으로 서버 사이드 스크립트를 통해 공통적인 파라미터를 묶어서 여러 개의 관련 링크에서 일관적으로 적용하도록 하는 방법이다. 그런데 다음과 같은 HTML 코드를 만들어내는 경우가 있다. (common1~3을 공통적인 파라미터라고 가정한 게시물 보기 화면)
select.html<script type="text/javascript">
function goDelete(id) {
var form = document.forms["blahform"];
form.id.value = id;
form.action = "delete";
form.submit();
}
function goUpdate(id) {
var form = document.forms["blahform"];
form.id.value = id;
form.action = "updateForm";
form.submit();
}
function goList() {
var form = document.forms["blahform"];
form.action = "list";
form.submit();
}
</script>
<a href="javascript:goDelete(1)">삭제</a>
<a href="javascript:goUpdate(1)">수정</a>
<a href="javascript:goList()">리스트</a>
<form name="blahform" method="post">
<input type="hidden" name="common1" value="1" />
<input type="hidden" name="common2" value="2" />
<input type="hidden" name="common3" value="3" />
<input type="hidden" name="id" value="" />
</form>프로그램 적으로 생각하자면 공통 파라미터의 일관성을 유지할 수 있는 한가지 방법이라고 할 수 있겠지만, 결과적으로 HTML 태그가 의미에 맞지 않고 자바스크립트 의존적인 코드가 되었다. 기본적으로 form 태그는 사용자 입력 양식을 뜻하는데 위에 쓰인 form 태그는 프로그램 내부적인 용도 그 이상의 의미를 지니지 않는다.
앞서 언급한 것과 같이 공통 파라미터를 한 변수에 할당하는 방법으로도 일관성을 충분히 얻을 수 있고 그 이외에도 서버 사이드 스크립트 단에서 위의 코드에서 얻으려고 했던 이득을 놓치지 않을 수 있는 방법이 많이 있다. 이와 같은 오류를 범하지 않으려면 HTML의 구조화를 해치지 않고 자바스크립트 의존적인 페이지를 피하는 자세가 필요하다.
Lachlan Hunt가 2007년 8월 3일에 공개한 “HTML5를 통한 개발(Developing with HTML5)” 슬라이드 입니다. 간단히 번역을 했는데 오역이나 의역은 원문을 참조하여 이해해 주셨으면 좋겠습니다.
(그림1. 전송 버튼이 적용되지 않은 select 태그)
그림1은 현재 게시판의 분류나 바로가기 메뉴 등에서 선택 시 바로 폼을 전송시키거나 자바스크립트를 이용하여 페이지 전환을 하는 용도로 쓰이고 있다. 그러나 키보드 사용자나 자바스크립트를 사용할 수 없는 사용자를 고려하였을 때 위와 같은 사용은 불가하다. 자바스크립트가 불가능한 사용자를 위해 <noscript> 태그를 이용하여 서브밋 버튼을 추가하면 되지 않느냐? 그것은 반쪽짜리 접근성이다. 마우스 기능을 사용할 수 없는 사용자의 접근성이 상당히 저하되기 때문이다. 키보드 사용자는 select 태그의 목록을 활성화 시킨 후 아래 방향키를 한 번 누르는 순간 select 태그의 자바스크립트가 활성화되어 마치 목록 두 번째 요소를 선택한 듯한 결과를 보게 될 것이다.
(그림2. 전송 버튼이 적용된 select 태그)
전송 버튼을 넣고 select 태그의 onchange 이벤트를 제거하여 모든 사용자에 대한 접근성을 확보할 수 있다. 마우스 사용자들의 편의성 문제는 어떻게 하는가? 결국 판단은 제작하는 사람의 몫이지만 누군가의 접근성을 저해하면서 얻는 편의는 기능에 대한 남용이다.
이밖에 장애인이 공공부분의 인터넷 사이트를 손쉽게 이용할 수 있도록 `웹 접근성 준수’를 제도화하기 위해 올해안에 웹 접근성 국가표준을 개정하기로 했으며 공공기관은 물론 민간기관들의 참여를 이끌어내기 위해 `웹 접근성 품질 마크’를 적극적으로 부여하기로 했다.
정부 차원에서 장애인들의 IT 활용 활성화를 추진하고 있다는 기사가 났다. 웹 접근성에 대해 국가 차원의 관심과 필요성이 더욱 늘어나게 되었다는 이야기이다. 좋던 싫던 관심이 있던 없던 웹 표준과 접근성은 점점 피할 수 없는 필수요소가 되어가고 있다. 장애인의 인터넷 접근 장치는 점점 늘어가는데 정보를 얻는 통로인 웹사이트가 그들을 소외시킨다면 정부의 이런 정책은 아무런 의미가 없을 것이다.
기사대로라면 2012년에는 접근성을 보장 여부가 13만명의 잠재 이용자를 잡느냐 놓치느냐를 판가름한다. 웹표준과 웹접근성의 가치가 보다 빠르게 늘어날 것이라는 기대를 해본다.
자 이제 CSS를 입혀보자.
일단 전역설정이다. 이 작업은 브라우저마다의 차이를 극소화하고, 사용할 tag의 기본적인 속성을 부여하는 작업이다. 갖가지 태그의 padding과 margin을 0으로 지정! tag마다 기본적으로 padding과 margin값이 틀리다. 쉬운 디자인 작업을 위한 설정이기도 하다. 가로줄(hr tag)은 디자인에서 (대개) 불필요하므로 보이지 않도록 처리한다. hr tag를 생략할수도 있겠지만, 디자인이 배제된 페이지에서의 head, body, foot의 구분을 위한 용도로 유용하므로 사용을 권한다!
Developing with HTML5.ppt
html,body,img,form,div,span,h1,h2,h3,h4,hr,ul,li,table,tr,th,td {
padding: 0;
margin: 0;
}
hr {
display: none;
}위의 작업 외에도 기본적인 링크(a tag) 설정, 링크걸린 이미지를 위한 border 설정 등 작업내용에 맞는 기본설정을 한다!
자, 이제 페이지에 디자인을 입히는 작업 시작! 첫번째, 전체적인 레이아웃을 보자. 검은 테두리가 모든 정보를 덮고 있고, 그 안에 배경색이 있고, 중앙으로 정렬이 되어 있고, 위로부터 10px 떨어져 있다.
여기서 전체를 담당하는 container와 body tag의 선언을 하자. 브라우저 틀에 해당하는 body tag, 다음과 같이 선언해보자.
body {
margin-top: 10px; /* 상단의 마진을 10px로 설정 */
background-color: #fff; /* 배경색을 흰색으로 설정(=#ffffff) */
}검은 테두리와 그에 해당하는 부분은 container에 선언한다.
#container {
margin: auto; /* 중앙정렬! 상하 마진에는 관여되지 않는다. */
width: 700px;
border: 1px solid #000; /* 테두리를 1px 검은색으로 설정 */
background-color: #f9f9fe;
}이제 전체적인 틀을 만들었다. 다음으로는 실제 내용 하나하나에 디자인을 입혀보겠다. 로고, 상, 하, 좌에 각각 20px의 마진, font의 크기는 h1의 그것으로 결정하기로 했다고 하자. 또 로고의 폰트를 두껍게, 2차 로고(div 레이아웃 첫번째 페이지)는 표시하지 않기로 하자. (이미지에서 로고가 두껍게 나오지 않는건 내 컴의 문제 -_-+)
#logo {
padding: 20px;
border-bottom: 1px solid #000; /* 로고 아래의 검은줄 */
}
#logo h1 { /* 폰트에 대한 내용이므로 해당 tag에 직접 써준다 */
font-weight: bold;
}
#logo span { /* 2차 로고를 숨긴다 */
display: none; /* visible 속성은 보이지 않지만, 레이아웃에 해당영역을 차지 한다. */
}좌측 메뉴, 다음으로 나올 뉴스 내용이 오른쪽에, 좌측 메뉴가 왼쪽에 배치되어 있다. top과 left의 border는 있으니, right, bottom에만 border를 적용시켜주면 되겠다. 배경색이 다르다. text가 중앙정렬이며, 상하도 중앙정렬이다 – 이럴 땐, 높이를 지정하지 않은 padding 옵션이 적당하다.
#menu { /* 메뉴 전체의 틀을 지정 */
width: 150px;
float: left; /* 왼쪽으로 정렬시킨다. 뿐만 아니라, 다음의 나올 컨텐츠의 위치를 이것도 동일선상(?)으로 위치시키는 기능도 있다. 자세한 내용은 http://www.w3.org/TR/CSS21/visuren.html#floats를 보도록 하자. */
text-align: center; /* 좌우 중앙정렬 */
background-color: #e0e0ef;
}
#menu li {
list-style-type: none; /* 앞 딴의 미려하지 않은 동그랑땡을 제거! */
padding: 8px; /* 중앙정렬을 위해. */
border-right: 1px solid #000;
border-bottom: 1px solid #000;
}자, 이제 내용을 메뉴의 오른쪽으로 위치시킬 차례이다. 전체의 가로 size에서 메뉴의 가로 size를 제외한만큼의 영역을 차지한다. 행의 높이를 20px로 한다.
#contents { /* 내용 전체의 틀 */
float: right; /* 오른쪽으로 띄운다. */
width: 550px;
}.news { /* 여러개의 뉴스가 한 페이지에서 보일 개연성을 부여한다(?) */
padding: 10px;
}
.news-body p { /* 행의 높이는 전역설정을 하지 않는다!! */
line-height: 20px;
}행의 높이는 레이아웃에 뜻하지 않은 악영향을 끼치는 경우가 많다. 필요한 경우에만 사용한다. 여러군데에서 같은 행의 높이가 사용된다면, 따로 class를 부여하여 사용하면 좋다.
자, 이제 copyright를 만들고 전체적인 레이아웃을 마무리한다! float 상태를 취소하고 아랫쪽으로 배치! 좌우 중앙, 상하 중앙(padding 사용!), 상단에 1px의 border!
#copyright {
clear: both; /* float 상태를 취소 (both = left + right) */
text-align: center;
border-top: 1px solid #000;
padding: 20px;
}페이지가 완성되었다. 결과물을 눈으로 확인하자! 예제 – divcss2.html
다음 공략에서는 좀더 실제상황가 가깝게 이미지, 링크 등이 들어간 디자인을 입혀보겠다!
덧) 모자란 실력으로 공략같은걸 씁니다. ^^ 많이 부족한 부분이 있고, 간혹 틀린 부분이 있을 수도 있습니다. 이런 부분에 대해선 미리 죄송하다는 말씀 드립니다! 많은 정보 얻고있는 forums.mozilla.or.kr에게는 언제나 감사하다는 말씀.. 덧붙입니다!
XHTML 1.0 Strict에는 a tag에 target attribute가 없다. 동작이야 하지만, validator에서 에러를 봐야한다. 단순히 새 창을 띄울 때 다음과 같은 방법이 아주 유용하다.
<a href="http://tenshi.pe.kr/" onclick="window.open(this.href); return false;">tenshi.pe.kr</a>자바스크립트 parser가 없는 경우는 대개 text 브라우저 같은 녀석들이니 상황에 따른 새 창 혹은 자기자신의 선택이 되는 장점도 아울러 가질 수 있다!
자! 지난 글에서도 언급했듯 실제로 사이트에 있을만한 페이지를 한번 작성해보자! 일단 첫번째로는! 페이지의 재료가 필요하다. 로고라든지, 메뉴, 페이지의 내용, 카피라이트 등.
타이틀
멋져부러 뉴스
서브타이틀
div 레이아웃 첫번째 페이지!
----
메뉴
home
뉴스
방명록
링크
----
뉴스
박지성, 에인트호벤과 계약연장 합의
네덜란드 프로축구에서 활약하는 박지성(24.에인트호벤)이 소속팀에 3년 더 남을 전망이다.
PSV 에인트호벤은 내년 시즌을 끝으로 계약이 만료되는 박지성과 3년 재계약을 맺기로
원칙적으로 합의했다고 현지 신문 알게메네 다흐 블라드가 12일(한국시간) 보도했다.
구단 웹사이트(www.psv.nl)도 "PSV는 박지성이 오랫동안 에인트호벤에 남아주기를
바라고 있고 그와 협상을 시작했다"고 밝혔다.
이번 계약 연장은 구단 측이 적극적으로 요구한 것으로 이에 따라 박지성은 오는
2008년까지 에인트호벤 유니폼을 입게 된다.
거스 히딩크 에인트호벤 감독은 "박지성도 이곳에 남기를 바라고 있다. 2002년
한일월드컵 이후 많은 한국 선수들이 유럽에 진출했지만 박지성과 이영표가 유일하게
성공한 예"라면서 "두 선수는 우리팀의 엔진과도 같다. 나머지 구체적인 사항도
잘 성사될 것으로 믿는다"고 기대를 나타냈다.
----
copyright
2005 blahblah.com. All rights reserved.[/code]
자, 위의 재료로 div 레이아웃 페이지를 만들어보자! 일단 디자인이 배제된 html 페이지를 구성하는 단계이다. 내 생각엔 이 단계가 div 레이아웃 공략에서 제일 중요한 단계가 아닐까 생각한다. 그만큼 중요하다는 말씀!!!
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>박지성, 에인트호벤과 계약연장 합의 - 멋져부려 뉴스</title>
<style type="text/css">
</style>
</head>
<body>
<div id="container">
<div id="logo">
<h1>멋져부러 뉴스</h1>
<span>div 레이아웃 첫번째 페이지</span>
</div>
<hr />
<div id="menu">
<ul>
<li>home</li>
<li>뉴스</li>
<li>방명록</li>
<li>링크</li>
</ul>
</div>
<hr />
<div id="contents">
<div class="news">
<h3>박지성, 에인트호벤과 계약연장 합의</h3>
<div class="news-body">
<p>네덜란드 프로축구에서 활약하는 박지성(24.에인트호벤)이 소속팀에 3년 더 남을 전망이다.</p>
<p>PSV 에인트호벤은 내년 시즌을 끝으로 계약이 만료되는 박지성과 3년 재계약을 맺기로 원칙적으로 합의했다고 현지 신문 알게메네 다흐 블라드가 12일(한국시간) 보도했다.</p>
<p>구단 웹사이트(www.psv.nl)도 "PSV는 박지성이 오랫동안 에인트호벤에 남아주기를 바라고 있고 그와 협상을 시작했다"고 밝혔다.</p>
<p>이번 계약 연장은 구단 측이 적극적으로 요구한 것으로 이에 따라 박지성은 오는 2008년까지 에인트호벤 유니폼을 입게 된다.</p>
<p>거스 히딩크 에인트호벤 감독은 "박지성도 이곳에 남기를 바라고 있다. 2002년 한일월드컵 이후 많은 한국 선수들이 유럽에 진출했지만 박지성과 이영표가 유일하게 성공한 예"라면서 "두 선수는 우리팀의 엔진과도 같다. 나머지 구체적인 사항도 잘 성사될 것으로 믿는다"고 기대를 나타냈다.</p>
</div>
</div>
</div>
<hr />
<div id="copyright">
2005 blahblah.com All rights reserved.
</div>
</div>
</body>
</html>간단히 html 페이지를 구성해보았다. 이제 이 html 페이지를 뜯어가며 살펴보자!
일단 body 안쪽에 전체를 포괄하는 div tag( id="container" )를 선언한다. 이는 디자인을 입힐 때의 전체적인 레이아웃(가로길이, background 등..) 지정을 담당하는 역할을 주로 한다.
이제 재료의 구분(타이틀, 메뉴, 뉴스..)별로 다시 div tag를 감싸준다. 타이틀이나 메뉴처럼 한번만 나오는 녀석은 id로, 뉴스처럼 중복된 내용이 나올 수 있을만한 녀석은 class로 css를 위한 선언을 하여준다.
다음으로는, 타이틀의 로고나 뉴스의 제목 등 다른 내용들보다 중요한 text는 headings(<h1> ~ <h6>)로 강조됨을 표시한다. 로고 같은 제일 중요한 녀석은 h1 tag로, 본문(뉴스)의 제목은 h2나 h3 tag 정도로 배정해주면 적당하겠다.
메뉴와 같은 몇 개의 간단한 text의 묶음은.. lists( <ul>, <ol>, <li> )로 묶어주기를 추천한다. 그 외 문단나눔(p tag), 표(table tag) 등은 용도에 맞게 쓰자!
이 정도면 기본적인 html 코딩의 기초를 다 적지 않았나 싶다. 부족한 부분이 있겠지만 그런 것들은 이런 저런 상황들을 통해 내공을 쌓을 수 있을 것이다! 원래 이번 공략에서 CSS까지 입혀보기로 했으나, 이미 긴 작문에 기력을 소진한 상태라..-_-; 다음 시간에 CSS를 입혀보기로 하겠다!!
자! 이제 본격적인 공략…에 앞서 한가지만 더 짚고 넘어가자. 바로 html 문서의 형식을 결정하여 주는 DTD(Document Type Definitions)라는 녀석!
W3C(World Wide Web Consortium)에서는 여러가지 버전별 html 표준 규약을 제공하고 있는데, DTD는 그 여러가지 버전중에 한가지 규약을 사용하겠다 하는 선언이다.
우리의 공략의 표준 규약으로 사용할 html의 버전은 XHTML 1.0으로 해당 DTD들은 XHTML1 DTDs에서 볼 수 있다.
보면 3가지 DTD가 있는데, 엄격한 규약(strict), strict보다 약간 느슨한 규약(transitional), frameset 페이지에서의 규약(frameset)이 있다. 앞으로 예제에서는 엄격한 녀석(strict)을 쓰겠다.
아래는 strict DTD를 적용한 XHTML 1.0 페이지의 기본이다. 우리의 공략은 이 페이지를 바탕으로 출발하겠다!
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Hello, tenshi!</title>
</head>
<body>
<p>
contents...
</p>
</body>
</html>기본적으로 DOCTYPE(Document Type)을 최상단에 선언하고, html tag(이하 html)가 처음과 끝에 나오고, html안에 head tag(이하 head), body tag(이하 body)가 반드시 포함, head안에 title tag, 문서의 encoding( , [url=http://www.w3.org/TR/xhtml1/#C_9]다른 방법[/url]도 있지만 여기선 다루지 않겠음!)을 반드시 선언…
암튼, XHTML 1.0의 규약을 지키기 위해서는 여러가지 제약조건들이 있다. 처음부터 힘들게 외우기 보다는 손 가는대로 페이지를 만들고 유효성 검사를 하면서 고치면 훨씬 쉽게 코딩할 수 있다~ 유효성 검사에 대해서는 추후에 다시 설명하도록 하겠다.
이제 XHTML 1.0 strict 규약을 적용한 기본 페이지도 만들어봤고, 다음엔 실제로 예제 페이지를 하나 맹글어보자~ 또, CSS로 디자인을 입히는 요령에 대해서도 하나하나 배워보자!
HTML 코딩, 우리는 여지껏 열심히 table tag(이하 table) 안에 또 table을, 또 table을 넣어가며 코딩을 해왔다.
"td tag(이하 td)를 하나 안닫았다!"
"table 10단 콤보에 들여쓰기를 하려니 온통 공백밖에 없다 OTL"
그렇게 table 중첩 코딩을 하면서 위와같은 문제를 많이 겪었으리라 싶다.
이제 저런 문제들을 좀 벗어나보자, 바로 div+css 레이아웃(이하 div 레이아웃)으로! 그냥 위와 같은 문제들만이라면 div 레이아웃을 뭐 굳이 배우겠냐 싶지 않은가? 그렇다! 궁극적으로 div 레이아웃을 공략해야만 하는 이유는 따로 있는 것이다.
그 외에도 많은 장점들이 있다! 굳이 알고 싶다면 한글 모질라 포럼 – Web Standard Evangelism을 한번 둘러보시라!
자 이제 div 레이아웃으로 옮겨갈 마음이 생겼다면 본격적으로 공략을 시작해보자!