티스토리 툴바

Daum
Tistory
로그인

Search Results for 'Web Standards'

5 POSTS

  1. 2007/12/20 이미지에는 대체 텍스트를 꼭 사용합시다. (169)
  2. 2007/10/24 em의 사용과 IE 버그 (141)
  3. 2007/09/30 DTD (Document Type Definition) (164)
  4. 2007/09/28 Interactive button with CSS (178)
  5. 2007/07/27 Markup Validation Service 0.8.0 Release (156)

이미지에는 대체 텍스트를 꼭 사용합시다.

Posted 2007/12/20 09:30, Filed under: Web Standards

BlackJack이 주머니에 들어온 이후로 지하철이나 버스에서도 RSS를 구독할 수 있게 되었습니다. 그렇다고 제가 항상 온라인에 접속해 있다는 것은 아니고요, 집이나 회사의 Wi-fi를 이용해 최신 글들을 미리 클립해 두었다가 이동시간 중에 틈틈히 확인하는 식으로 사용하고 있습니다. 아무리 3G망으로 접속할 수 환경이 마련되었다고 한들 그 비용이 후덜덜하기 때문이죠. 약간은 원시적인 방법입니다. 큿-

나름대로 이게 어디야~ 라며 만족하면서 사용하고 있습니다만, 역시나 불편한 점을 얘기하지 않을 수가 없습니다.
플래시? 동영상? 아직 이런 것 까지는 바라지도 않습니다. 하지만 이미지라면 얘기가 달라지죠.

지금은 News Break라는 어플리케이션을 사용하고 있는데 요놈은 페이지를 직접 열어야만 이미지를 불러오는 식이라서 온라인 상태가 아닐경우에 나타나는 이미지들은 모두 엑스박스로 나타납니다. 불필요한 패킷을 줄이기 위해 이렇게 설계가 된듯하지만 저의 사용 방식과는 궁합이 맞질 않아서 문제가 생기지요.

여기서 제가 하고 싶은 얘기는 프로그램이 못났다가 절대 아닙니다. 다만 컨텐츠를 생산하는 사용자들(e.g. 블로거)이 웹 접근성을 고려치 않고 제작한다 라는 점이 아쉬울 따름 입니다. 이게 뭔 뚱딴지 같은 소리냐면,

<img src="./ybody.jpg" />

이미지는 경우에 따라서 보일 수도 있고 안보일 수도 있다고 생각합니다만 단순히 이렇게만 작성된다면 그 이미지를 볼 수 없는 사용자들은 소외를 받게 되고, 서로의 소통에 문제가 생기게 됩니다. 어쩔 수 없이 그냥 그 곳에 어떠한 이미지가 있고, 문맥상 이러이러한 이미지가 들어갈 것이라고 추측만 하게 될 뿐이죠.
이미지가 안보이는데 그걸 어쩌라고요?

이미지 태그에는 대체 텍스트를(alternative text) 지정할 수 있는 속성이 있습니다. 엘리먼트 내에 alt="대체 텍스트 내용" 과 같은 방법으로 사용할 수가 있죠.

<img src="./ybody.jpg" alt="유재석의 근육" />

이미지를 볼 수 없는 환경이라도 이미지를 대신한 대체 텍스트를 볼수가 있어 내용을 이해하는데 많은 도움이 됩니다.

하지만 대부분의 사용자가 위지윅에디터를 사용하고 있고, 코드만 보면 울렁증을 호소하는 분들이 많기 때문에 이런 배려까지는 나에게는 무리 라고 생각하시는 분들도 계실 텐데, 다행히도 텍스트큐브(태터툴즈), 티스토리에는 이미지 옵션에 대체 텍스트 입력 칸이 존재합니다.

텍스트큐브,티스토리의 이미지 옵션 중 대체 택스트 항목

이미지를 본문에 추가하고 선택(본문에 삽입된 이미지 클릭)하면 우측에 대체 텍스트를 입력할 수 있는 항목이 나옵니다. 이 곳에 이미지를 대체할 수 있는 설명을 달아두면 대체 택스트를 쉽게 달수 있게 되는거죠.

일전에 어떤 사람이 '뭐 하러 귀찮게 이미지에 일일이 대체 텍스트를 달고 있는가?' 라고 물었던 적이 있는데, 확실히 그것은 잘못된 생각이라고 말하고 싶습니다. 단순히 눈에 보여지는 결과를 원한다면 이러한 노력은 삽질이 되고 말겠지만 시력이 불편하여 스크린 리더에 의지하며 인터넷을 사용하는 사람들이나 저처럼 이미지가 보이지 않는 환경에서 접속해 있는 사용자들의 입장을 헤아릴 수 있다면 그것만으로도 충분히 의미가 있는 일이니까요.

Tag : alt, Alternative Text, image, News Break, RSS, web standards
Response : 0 Trackback , 169 Comments

Trackback URL : http://1upz.tistory.com/trackback/99 관련글 쓰기

em의 사용과 IE 버그

Posted 2007/10/24 12:08, Filed under: Web Standards

em의 필요성

일반적으로 폰트의 크기를 지정하기 위해서 px, 혹은 pt 와 같은 단위를 습관적으로 사용 해 왔습니다만 Screen display의 경우에는 플랫폼간의 부조화나 브라우저에서 폰트 사이즈를 인위적으로 조절하는 것이 불가능한 경우가 생기기 때문에 이를 지양하고 em 과 같은 상대 단위를 사용하는 것이 좋습니다.

em의 크기는 어떻게 가늠하는가.

em은 대문자 M의 폭을 기준으로 그 사이즈가 정해지는 상대적 단위이기 때문에 원하는 크기를 지정하기 위해서는 상위 엘리먼트로 거슬러 올라가야 합니다. 마치 부모와 자식과의 관계처럼 자식은 부모에게 영향을 받는 속성을 갖고 있죠.

/* CSS */
#parent {
  font-size:20px;
  }
<!-- HTML -->
<div id="parent">
  <div id="child">Who Am I?</div>
</div>

위의 예(이해를 돕기 위해 px 단위를 사용 했습니다)를 보면, Who Am I? 의 기본 크기는 별다른 지정이 없으므로 20px로 표현이 됩니다. 만약 child 엘리먼트의 폰트 사이즈를 1em으로 지정 했을 경우 Who Am I?는 parent의 100% 크기인 20px로 나타나고, child가 2em 라면 40px, 0.5em 라면 10px로 나타나게 되는 형식이 em의 원리 입니다.

처음 크기는 무엇으로 결정 되나?

앞서 얘기 한데로 em은 상대적 단위 이기 때문에 상위 엘리먼트의 값을 참조하게 됩니다. body 그리고 html까지 올라가서 그 값을 참조하게 되는 것이죠. 그렇다면 최상위 엘리먼트는 무엇을 참조하게 될까요? 네, 브라우저의 설정 값을 참조하게 됩니다. 바꿔 얘기하자면 브라우저의 설정 값을 변경하면 페이지의 폰트 크기들을 조절할 수 있게 되는 겁니다. (참고로 Opera나 IE7의 경우에는 줌 브라우징이 가능하고 Fire Fox는 절대 단위 폰트들도 resizing이 가능하므로 em은 IE6를 위한 선택이라 해도 과언이 아닙니다.)

일반적으로 브라우저의 기본 크기는 12pt (16px)로 설정 되어 있기 때문에 12pt를 기준으로 페이지 전체를 디자인 해야 하고, 또한 기본 설정의 변경에 따라 변화되는 모습을 융통성 있게 제작하는 것이 무엇보다 중요 합니다.

Resizing bug in IE6

em을 사용하여 텍스트 크기 조절이 가능토록 디자인 해야 하는 주된 이유는 사용자 편의성에 있습니다. 만일 시력이 좋지 않은 사용자라면 작은 글씨로 된 텍스트는 읽을 수가 없으므로 이를 적당히 키워 읽기 편하도록 만들자는 것이 그 목적 이죠. 그런데 단순히 em의 사용만으로는 IE6 에서 확대/축소율의 문제점이 발생합니다. 폰트가 지나치게 커지거나 지나치게 작아져서 오히려 더욱 불편해 지는 문제 입니다.
파이어폭스의 모습과 비교한 아래 이미지를 보시면 그 차이를 느끼실 수 있을 겁니다.

FF와 IE의 텍스트 확대 축소 변화

이 문제는 최상위 엘리먼트의 폰트 사이즈 단위를 %로 지정하여 간단히 해결할 수 있습니다. 만약 font-size를 body부터 시작 했다면 html을 추가해 % 값을 지정해 주십시오.

html {
  font-size:100%;
  }

폰트의 크기를 브라우저 기본값의 100%로 보여주라는 코드라 이론상으로는 아무런 의미가 없지만 사이즈의 근본을 em이 아닌 %로 우회하여 IE에서도 확대, 축소의 비율을 적당하게 적용 시킬 수 있도록 한다는 원리 입니다.

만일 html 에 이미 폰트 사이즈를 지정했거나 html이 아닌 다른 곳에 %를 지정하고 싶다면 폰트가 지정된 최 상위 엘리먼트(보통은 body가 되겠죠)의 수치와 단위를 em 에서 %로 변경 해 주시면 됩니다.

body {
  font:75%/1.6 'Trebuchet MS', Helvetica, sans-serif;
  }

그 밖의 문제

IE에서 하이퍼링크를 클릭할 경우 본문의 텍스트 크기가 순식간에 줄어들거나 커지는 증상도 앞서 얘기한 것처럼 최상위 단위를 %로 지정해 줌으로써 해결이 가능할 것 같습니다. 그렇지만 확실한 것은 아니고, 어디까지나 추측일 뿐인데, 일단은 제 환경에서는 재현이 되지 않기 때문에 혹시라도 이런 증상이 나타나시는 분은 테스트를 부탁 드립니다.

Tag : Bug, CSS, em, font, Internet Explorer
Response : 0 Trackback , 141 Comments

Trackback URL : http://1upz.tistory.com/trackback/95 관련글 쓰기

DTD (Document Type Definition)

Posted 2007/09/30 02:15, Filed under: Web Standards

DTD은 왜 작성해야 하나

DTD은 브라우저의 랜더링 모드를 지정해주고 유효성 검증기(Validator)의 기준이 되므로 (X)HTML 문서의 상단에 반드시 선언 해 주어야 합니다. 만일 DTD를 생략하거나 형식이 잘못된 문서일 경우에는 웹 브라우저마다 코드의 해석 방식이 다른 Quirks mode로 랜더링이 되기 때문에 엉뚱한 결과물로 출력되는 문제에 직면하게 됩니다.

DTD의 종류

웹 페이지에서 주로 사용하는 HTML 4.01 과 XHTML 1.0에는(2007년 기준) 각각 Strict, Transitional, Frameset 의 3가지 DTD가 있습니다. (XHTML1.1에서는 Transitional 과 Frameset은 파기되고 Strict 기반으로 재구성 되었습니다.)

HTML 4.01

HTML 4.01 Strict DTD
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd">
HTML 4.01 Transitional DTD
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">
HTML 4.01 Frameset DTD
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" 
http://www.w3.org/TR/html4/frameset.dtd">

XHTML 1.0

XHTML 1.0 Strict DTD
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XHTML 1.0 Transitional DTD
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
XHTML 1.0 Frameset DTD
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.1

XHTML 1.1 DTD
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

어떤 DTD를 선택해야 하는가?

XHTML은 데이터의 표현(Presentation)에 초점이 맞춰져 있는 HTML의 문제점을 개선하기 위해서 XML방식으로 구현한 언어이기 때문에 약간의 문법적인 차이를 제외하고는 HTML과 크게 다르지 않습니다. 하지만 XML 을 기반으로 만들어 졌으므로 이 둘의 차이점을 이해하지 못헸거나 기존의 웹사이트가 HTML 기반으로 제작되어 있다면 무리하게 XHTML을 고집할 필요는 없겠죠.

무엇보다 중요한 것은 Transitional DTD와 Strict DTD 타입의 선택 입니다. W3C는 CSS를 장려하기 위해 표현을 위한 태그를 엄격히 배제한 Strict DTD를 권고하고 있습니다만 기존의 수많은 웹사이트들을 한 순간에 변화 시킬 수는 없으므로 호환성 유지를 위해 과도기적 성질인 Transitional DTD를 사용할 수도 있도록 배려했습니다. 다시 말해서 (X)HTML과 CSS의 분리가 완벽히 이뤄 지느냐 그렇지 않느냐에 따라서 DTD를 정할 수 있다는 것이죠. 만약 (X)HTML 내에 표현을 위한 요소를 CSS로 분리가 된다면 Strict DTD를, 그럴 수 없는 환경이라면 Transitional DTD를 지정하시면 됩니다.

웹 표준은 XHTML?

웹 표준과 시멘틱한 웹사이트를 위해서는 XHTML 사용을 해야 한다는 말이 있지만 그 말은 사실이 아닙니다. XHTML 1.0 Transitional 보다는 HTML4.01 Strict의 규격이 구조와 표현을 더욱 엄격하게 구분 짓고 있으므로 무조건 XHTML이라는 말은 잘못 되었다고 볼 수가 있는 거죠. 고로 HTML이냐 XHTML이냐의 선택 보다는 제작하려는 사이트의 방향과 목적을 제대로 파악하고 그에 걸맞은 DTD 선택이 더욱 중요할 것입니다.

Tag : DOCTYPE, DTD, HTML, XHTML
Response : 0 Trackback , 164 Comments

Trackback URL : http://1upz.tistory.com/trackback/91 관련글 쓰기

Interactive button with CSS

Posted 2007/09/28 00:56, Filed under: Web Standards

이번 학기에 수강하고 있는 웹 디자인 수업은 테크니컬 적인 내용은 배제하고 인터렉티브를 기반으로 한 디자인을 다루고 있습니다.

Interact는 '상호적인(Inter)' 이라는 단어와 '활동, 작용(Act)'을 뜻하는 단어의 합성어로 '상호 작용하다', '서로 영향을 끼치다' 라고 풀이되는데, 상호적으로 작용한다는 의미는 일방적인 활동으로 그치는 것이 아니고 작용에 대한 반응(React)과, 또 반응으로 인해 새로운 행동 반응이 연거푸 일어나는 작용이라 할 수 있습니다. 이해를 돕기 위해 한가지 예를 들자면, 앞에 있는 놈을 한대 쥐어 박았을 경우 그것으로 끝나는 것이 아니라 그 놈의 머리에서 혹이 나고, 눈물을 흘리며 나에게 주먹질을 해오는 이러한 작용과 반응이 인터렉티브라 할 수 있겠죠.

그렇다면 웹사이트에서 가장 기본적인 인터렉티브는 무엇이 있을까요? 


a {text-decoration:underline;}
a:link {color:#09c;}
a:visited {color:#906;}
a:hover {font-weight:bold; color:#0c3;}
a:active {color:#c00;}
a:focus {background-color:#eee;}

네, 저는 a 태그의 가상 클래스 라고 생각 합니다. 링크를 확인하고, 마우스를 올리고, 클릭하는 행위가 이뤄지는 부분이죠.

위와 같은 평범한 링크 스타일로도 충분히 상호작용이 일어나지만 일반적으로 mouse over 에 대한 반응에만 신경을 쓰고 있지, 클릭에 대한 반응은 생략하는 경우가 많아 클릭했을 경우의 스타일을 생각 해 봤습니다.

a 태그를 간단하게 버튼 모양으로 만들어 보도록 하겠습니다. 예제 보기


a {
    display:block;
    width:8em;
    padding:.5em 0;
    background-color:#eee;
    font-size:1em;
    text-align:center;
    text-decoration:none;
    border:1px solid #ddd;
    border-width:0 1px 1px 0;
    }

a:link, a:visited {
    color:#000;
    }

a:hover {
    color:#c06;
    }

a:active {
    position:relative;
    top:1px;
    left:1px;
    background-color:#e3e3e3;
    color:#f39;
    }

active 클래스에 position을 relative로 설정하고 위치를 위쪽, 왼쪽에서 각각 1px씩 이동하라고 지정해 뒀습니다. 링크를 클릭하는 순간 마치 버튼을 클릭 한 것과 같은 시각적 효과를 보여줌으로써 자신이 클릭했다는 사실을 눈으로 확인 할 수 있게 되는 것이죠. 클릭과 그 작용에 대한 시각적인 반응, 즉 인터렉트가 일어나는 것입니다.

물론 페이지 이동은 짧은 순간에 이뤄지고 마우스의 커서도 자동으로 바뀌거나 시스템에 따라서는 효과음도 출력되기 때문에 굳이 이러한 노력을 들이지 않더라도 클릭에 대한 반응을 인지할 수는 있습니다만 CSS를 응용하여 좀 더 멋지고 쉬운 인터렉티브 디자인을 만들어내는 것은 디자이너로서 상당히 매력있고 의미있는 일 이라 생각 합니다.

Tag : button, CSS, interactive
Response : 0 Trackback , 178 Comments

Trackback URL : http://1upz.tistory.com/trackback/90 관련글 쓰기

Markup Validation Service 0.8.0 Release

Posted 2007/07/27 00:52, Filed under: Web Standards

W3C Markup Validator 가 7월 25일부로 버전 0.8.0 베타의 딱지를 때고 정식으로 릴리즈 되었습니다.

Markup Validation Service

2007-07-25 - 0.8.0 Release:

Releasing version 0.8.0 of the W3C Markup Validator, a major milestone in the development of the validator, including changes in its architecture, UI, new features and fewer bugs, for a better, more accurate and helpful quality process.
This release includes all the changes and bug reports of the 0.8.0 Beta 1 and 0.8.0 Beta 2.

몇몇의 새로운 기능과, 자잘한 버그들, 정확도를 높인 도움말 등의 변화 이외에 디자인이 깔끔하게 변경된 점이 눈에 띕니다.

기존의 고리타분한 이미지에서 탈피하려는 의도가 있었던 걸까요. 모던, 심플 그 자체네요..
잠깐 속 살을 살펴 보니 mootools 스크립트를 사용한 흔적도 보이고 span 을 이용하여 코너를 라운드 처리한 버튼들도 보입니다.
역시 라운드 버튼은 현 시점에서 span 으로의 처리가 최우선인것 같다는 생각이 드네요. CSS3 시대는 언제 도래하려나....(한숨)

앞으로 Markup Validator가 얼마나 발전할지는 의문이지만 문법적인 오류를 검사하는 도구로서 잘못 알고 있는 상식을 바로 잡도록 도와주고 조금 더 오버를 떨자면, 웹 표준에 관심을 갖고 노력 해 보는 사람들이 늘어나는데 일조하는 역할이 되었으면 좋겠다는 생각을 해 봅니다.

말이 나온 김에 우리 모두 Markup Validation Service 에 방문하여 자신의 사이트의 요류들을 체킹해 봅시다.

Tag : validation, W3c
Response : 2 Trackbacks , 156 Comments

Trackback URL : http://1upz.tistory.com/trackback/87 관련글 쓰기

  1. 블로그 오류 검색하기 (Markup Validation Service 0.8.0 Release)

    Tracked from roman of women..... 2007/08/02 18:33 Delete

    자신의 웹사이트 혹은 블로그에 오류가 ? 오류 체크하기 !W3C Markup Validator 가 베타버전에서 정식으로 릴리즈 되었네요.블로그 오류 검색하거나 혹은 웹사이트 오류 검색할때 URL 주소만 집어넣으면 오류와웹표준을 바로 알려주는 웹사이트 입니다.몇몇의 새로운 기능추가와 함께 자잘한 버그들을 고치고 정확도를 높여서 정식릴리즈되었네요.심플해진 사이트 디자인도 눈에 띄이는 군요.문법적인 오류를 검사하는 사이트로서 웹표준을 바로잡아주는 사이트로..

  2. W3C테스트 통과 XHTML 호환

    Tracked from 밝은햇살비치는 2007/08/10 01:47 Delete

    웹표준에대한 여러가지 생각이나 이야기들을 읽으면서 과연 자신의 블로그에선 어느정도 까지 웹푠준 준수사항에 맞도록 디자인될수 있을까? 하는 생각을 하게 되었습니다. 그리고 티스토리의 플러그인을 어느정도까지 사용할수 있는가? 하는 생각도 했습니다. 현재 알아낸 걸로는 배경음악 서비스를 사용하지 못하지만 포스팅에 넣는 방법을 사용하면 전체 도메인에는 테스트가 동작하며 일부 배경음악을 호함하는 포스팅의 경우에는 문제가 발생할거라는 생각이 들었습니다. 200..

Total 532,848 hit (Today 33, Yesterday 247)

Valid XHTML, CSS