ILMOL.COM

Back

웹 그리고 표준 이야기의 재시작

Design

일모리네에서 정기적으로 사이트를 소개하고 나누려고 합니다. 혹시나 소개하고 싶으신 사이트가 있다면 주저말고 알려주세요.

Web Standards

웹표준은 생활입니다. 그 변화의 삶으로 당신을 초대합니다.

back to menu

Thanks P Roh

노무형 대통령님 감사했습니다.

back to menu

RSS 피드

정신없는 한주

정신없이 한주가 빠르게 지나가고 있습니다. 이번주말에 바자회가 있다고 해서 매일 저녁시간에 가서 도와주는 것도 큰 몫을 하고 있죠. 집에와서 씻고 보면 11시라 오자마자 잠자리로 가게됩니다. 가끔 미투데이때문에 오바한적도 있긴 합니다만. ^^ 빠르게 한주가 가고 있네요.

바자회 준비를 도우면서 좋은것이 있다면 정리중 맘에 드는 것들이 있을때 먼저 살수 있다는것! 맘에드는 책들이 몇권 있길래 입양해왔습니다. Google Story, CODE, Mere Christianity, 그리고 Cliches. 다들 시간날때마다 읽을수 있는 평균사이즈의 책들이고 관심있어 하는 분야의 책들이라 빠르게 입양 절차없이 찜해버렸습니다.

특히 CODE는 상당한 호응을 받았었던데 2006년에 CODE 2.0 에디션이 나왔더라구요. 이번꺼 읽고 맘에들면 다음 버전을 사보려 합니다. Mere Christianity 는 C.S. Lewis 가 쓴 책이라 무작정 입양했고 가장 맘에 드는 Cliches (클리쉐s) 는 미국에서 사용되는 속뜻이 담겨져 있는 문구들을 설명하고 어디서 비롯되었나 설명해주는 아주 유용한 책입니다. 가끔 맘에 드는것들은 소개해볼수 있을꺼 같습니다.

P.S.
앞으로 결혼식들이 많습니다. 4월은 이번주 빼고 다 있고 5월도 그렇고 말이죠. 즐겁고 부담되는 행복한 결혼달들 입니다. 다들 행복하기만을!

P.P.S.
요즘 기름값이 무지하게 오르고 있습니다. 어디 나가기 무섭습니다. 후..

P.P.P.S.
이제 장자법 장차법이 시행됩니다.

6

CSS Naked Day 08 어머나~

올해도 돌아왔습니다. 2008년 4월 9일, 사이트의 스타일시트를 꺼놓는 CSS Naked Day가 돌아왔습니다. 작년 CSS Naked Day의 제목을 CSS 옷벗기기로 정해놓았더니 아니나 다를까 ‘옷벗기기’ 단어로 상당한 트래픽의 상승이 있었습니다. 해서 올해는 더 자극적인 제목을 정하려다… 참았습니다. :)

CSS Naked Day는 표준이 의도하고 있는 문서와 스타일의 분리를 선전하는 의미에서 시작된 “하룻동안 스타일을 꺼 놓는 날” 입니다. 문서와 스타일이 이렇게 분리될수도 있다는걸 보여주기도 하고 스타일 없이도 문서적인 의미로도 페이지가 작동할수 있다는것을 보여주게 됩니다. 물론 “전 테이블로 레이아웃이 짜여져 있지 않아요” 라고 외칠수도 있는 의미를 담고 있습니다.

그 뿐만이 아니라 스타일을 꺼 놓으므로서 배경 이미지가 로딩되는 요청과 트래픽이 줄면서 서버의 전기 소요가 줄게되고 전기를 절약함으로 지구 온난화를 방지하는데 도움을 준다는 의미심장한 Green 의 의미도 억지지만 적용할수 있습니다.;;; 그리고 말씀드린데로 특정 키워드를 통한 트래픽 상승효과도 본의 아니게 (혹은 의도대로) 얻을수 있습니다.

참여방법

단순히 이번 4월 9일에 스타일시트를 꺼놓으셔도 되지만 기왕이면 CSS Naked 사이트에서 하단에 폼을 적으시고 등록을 하신후 동참의 기분을 내시면 좋겠습니다. 한국에서 참여하는 분들을 위한 특정 사이트가 없으므로 참여하는 타 블로거들에게 서로서로 트랙백을 나누는 네트워크 방법을 사용하는 수 밖에 없겠습니다.

또한 그저 스타일만 없어지면 방문자들이 놀랄수도 있으니 상단에 왜 스타일이 입혀지지 않았는지 설명하는 문구를 삽입하거나 미리 블로그에 공지하셔서 사전에 혼란을 방지 하는 것도 좋습니다.

저 올해 확실히 벗습니다. 같이 _ _ 보아요.

덧: 현재 약 100명정도가 참여의사를 밝혔는데 (물론 꾸준히 엄청난 속도로 늘어나겠습니다만) 여섯분이 한국분들이십니다. 6%군요! 과연 마의 10%를 넘을수 있을까요 ;)

CSS Naked Day에 동참하는 약 100명의 링크들이 보입니다만 저를 비롯하여 신현석님 겨미님 도훈님 현인님 정찬명님까지 6분들의 한국어 사이트 링크가 보입니다.

24

ALT 와 Title 속성의 바른 의미

최근 CDK에 들렸다가 봄눈님의 “longdesc 쓰시나요” 의 글타래를 통해 alt 와 title, 그리고 longdesc 에 대한 의미적인 접근을 해보고 싶었습니다.

대체 텍스트의 ALT 는 이미지가 보여지지 않을시에 이미지를 대신하여 보여지는 문구 입니다. 툴팁의 목적으로 사용하는 것은 바른 방법이 아닙니다. Title은 필수 요소는 아니지만 base, basefont, head, html, meta, param, script, and title를 제외하고는 어느 곳에나 쓰여지며 삽입되는 부분에 대한 설명을 담당합니다. longdesc는 alt 가 길어지는 경우 제대로된 설명을 담은 외부문서 주소를 지정해 줍니다. 많은 브라우저들에서 지원되지 않는 longdesc 에 대한 토론은 CDK 에서 마음껏 나누실수 있습니다.

alt vs title

많은 경우 문제는 alt와 title 의 차이에 대한 선을 긋지 못함으로 비롯됩니다. 오래전에 북마크 해 두었던 alt와 title 에 대한 토론을 읽어 보셔도 아시겠지만 (결과가 나지 않아 아쉽더군요) 상당히 헛갈릴수 있는 어찌보면 자연스럽게도 보일수 있는 문제 입니다.

ALT 는 이미지가 출력이 인위적이든 아니든 출력이 되지 않았을 경우 이미지와 동일한 의미를 전달 하는 문서의 한 부분으로써 사용되는 것이며 title은 어떠한 이미지인지 설명을 담당 합니다. “동일한 의미”를 전하는 것과 “설명”의 차이는 무엇일까요. 말보다는 예가 빠르고 쉽겠습니다. 올해 여름 패션을 이야기하는 문서에 한 예로 흰 와이셔츠를 입은 남성의 사진을 첨부하는 상황에서 이렇게 이미지의 alt 와 title 이 구별될수 있습니다.

올해 패션은 깔끔하고 단조로운 스타일이 대세를 이룰것으로 보입니다. 더이상의 설명보다 이하의 사진을 보며 계속 나누겠습니다.
img src=”summerModel.jpg” title=”정면으로 찍은 남성 모델 사진” alt=”이 모델은 흰 와이셔츠와 진한 남색의 청바지를 입고 있습니다.”
흰 와이셔츠는 깔끔하면서도 시원한 느낌을 전달하며 청바지는 …

title은 이미지에 대한 설명을 하고 있고 alt는 이미지를 대체하는 즉 동일한 의미를 표현하고 있습니다. 하지만 아시다시피 대부분의 경우 img src=”summerModel.jpg” alt=”남성 모델 사진” 으로 끝이 나게됩니다. title과 alt가 뒤바뀐 것이죠.

위처럼 문서의 일부로써 사용되는 이미지가 있는가 하면 그다지 의미전달이 불필요한 이미지가 삽입된 경우도 있습니다. 예를들어 사파리 브라우저 이야기를 하기 위하여 사파리 로고를 문서위에 지정해 놓은 경우인데 이러한 꾸밈을 위한 이미지에 alt가 필수 요소이므로 “사파리 로고” 라는 문구를 넣기 보다는 alt=”" 처럼 대체 텍스트를 오히려 비워 놓는것이 맞습니다. 문서를 정보로써 이해 하는데에 불필요할 뿐더러 브라우저 이외의 유저 에이전트가 접근시에도 무의미하게 “사파리 로고” 라고 읽혀지며 낭비하기 때문입니다. 저도 아무 생각없이 지정하는 실수인데 같이 고쳐가면 좋겠습니다. :)

더욱 분명한 선을 긋기 위하여 Ian Hicks (acid2, acid3 저자) 의 상당히 오래된 글인 “Mini FAQ About the Alternate Text of Images”를 번역하여 첨부하였습니다. 한국에서 특정 태그나 속성들의 정의나 토론들을 참고 삼을때 또한 소개할때 국내에 번역되거나 직접 쓰여진 글들이 적으므로 영어 사이트를 링크하는 경우가 대부분 처럼 보입니다. 해서 앞으로 기회가 될 때마다 레퍼런스로 삼을수 있는 참고가 가능한 글들은 저자의 허락 아래 번역하려 합니다.

원문: MINI FAQ ABOUT THE ALTERNATE TEXT OF IMAGES

글을 읽기 전에 이하의 노트를 참고 하시면 글을 이해하는데 더욱 편하실꺼라 생각됩니다.

  • 텍스트 = 문구, 글로 보시면 됩니다. 문구나 글 이라고 표현하지 않은 이유는 이미 한국 웹 개발자들 디자이너들 사이에 “대체 텍스트” 라고 알려져 있기에 굳이 글자 그대로 번역하지 않은 것입니다.
  • 인라인 이라는 개념은 텍스트와 동일한 문단안에 글 처럼 삽입되는 것입니다. 같은 줄에 위치한다는 개념으로 in line 으로 이해하시면 됩니다. 반대는 그만의 영역을 같는 블락 이겠습니다.
  • 제작자 - Author 를 제작자로 넣었습니다. 저자 가 더 나은 접근입니다만 한국말로 저자는 글을 쓰는 사람으로만 인식이 되어 있기 때문에 문맥상 혼돈 되는 부분이 있을듯 하여 굳이 제작자 라고 해석하였습니다. author 는 저자, html 을 쓴 사람, 문서를 제작 하는 사람 등등의 의미를 함축하고 있습니다.

이미지의 대체 텍스트 ALT 에 대한 FAQ

개요

Alt 속성은 대체 텍스트로 이미지가 보여지지 않을때 보여진다. 유저 에이전트는 이미지를 지원하지 않거나 특정 이미지 타입을 지원하지 않을때 혹은 이미지 출력을 꺼 놓았을때 이 대체 텍스트를 보여주어야 한다.

대체 텍스트는 단순히 “alternate” 대체 하는 것이다. 다른말로 하면 이미지의 의미를 문자로 표현하여 대체 하는 것이다. 이미지가 전달 하려는 것을 그대로 전달 하는 것이다.

제작자는 페이지의 형식을 위한 이미지들을 위해 무의미한 텍스트를 넣는 실수를 하면 안된다. 예를들어 붉은 공 모양의 이미지가 헤딩이나 문단을 꾸미기 위해 첨가 되었는데 alt=”빨간 공” 이라는 대체 텍스트는 올바르지 않은 사용이다. 이러한 상황이라면 그저 빈 텍스트가 어울린다 (alt=”"). 제작자들은 이전에 페이지 형식을 위한 이미지 사용을 피하기를 권한다. 스타일시트가 사용되어야 하겠다.

제작자들은 무의미한 대체 텍스트 삽입 또한 주의하기 바란다. (더미 텍스트 라고들 한다.) 유저들을 불편하게 할 뿐 아니라 글을 읽어주는 유저에이전트나 점자 에이전트를 느리게 할 뿐이다.

전형적인 주장들

만약 이미지가 빠졌다면 프레임(이미지 틀)이 제외되고 이미지와 똑같은 정보를 제공하는 인라인 텍스트로 대체 되야 한다고 생각한다. 그 텍스트가 바로 대체 텍스트로 alt 속성이 담고 있는 텍스트이다.

많은 사람들이 이미지가 보이지 않을때 이미지의 원래 틀(영역, 사이즈)은 유지되어야 한다고 주장한다. 이 글을 통하여 왜 그것이 불필요한지 설명할것이다.

주장 #1

“이미지의 생명은 영역이다”

이미지의 생명은 영역이 아니다. 오히려 그것의 의미이다. 이미지의 그래픽적인 표현의 요소는 (보통) 절대 필요한 것이 아니다. (예외를 예로 들자면 환영이나 착각을 목적으로 한 이미지가 있겠다. 그런 경우엔 이미지의 그래픽 요소가 절대 중요하겠다.(하지만 그 외에는 대부분 절대적이 아니다))

주장 #2

“내 생각엔 원초적으로 html 의 버그라고 본다. HTML 을 사용하여 제작하는 저자들에게 특정 이미지가 텍스트를 대체 하기 위해 사용한 것인지 아니면 텍스트의 부가물로 사용한 것인지를 구별 하라는 것은 말이 안된다.”

모든 이미지들은 글을 replace 대체(교체) 한 것이다. 아니 오히려 텍스트와 이미지 둘 다 “의미”를 대체 한 것이라고 볼수 있다. 다시 말하면 둘 중 한가지가 언제든지 다른 한가지를 대신하여 “의미” 전달의 도구로 사용될수 있다는 것이다. 하지만 가끔은 둘중 한가지가 다른 것 보다 특정 의미를 전달하는데에 더 나을 수 있다.

주장 #3

“삽화(다이아그램)로써 어떤 이미지들은 보는 것이 천마디 말보다 나은 이미지들이 있다. 예를들어 이러한 alt 를 담고 있는 이미지 이다. alt=”인디아나폴리스 학교의 Communicator 4.x 의 프록시 세팅을 보여주는 스크린샷” ”

일단 그것은 절대 올바른 대체 텍스트가 아니다. title 속성으로는 좋을지 모르나 대체 텍스트로는 부적절 하다. 적절한 대체 텍스트로는 이런식일 것이다.

alt=”Proxy 세팅 다이어로그 박스는 ‘proxy.i.edu’ 를 ‘host’ 필드에 담고 있고 모든 프로토콜에 3128 ‘port’ 를 담고 있다”

그리고 이하의 페이지에 이러한 부분이 첨가 되어있어야 할 것이다.

**위의 스크린샷은 인디에나폴리스 켐퍼스의 Commnicator 4.x 프록시 세팅을 담고 있다.**
이미지는 인디에나폴리스 켐퍼스의 Communicator 4.x 어플리케이션의 프록시 세팅을 묘사하고 있다. 다이어로그 박스는 HTTP, FTP, GOPHER, HTTPS 의 4열의 수정가능한 박스들을 담고 있다. 각 열은 host 와 port 가 맨 위에 위치한 두개의 수정 가능한 박스들을 담고 있다.

각 ‘host’ 필드는 ‘proxy.i.edu’ 를, 그리고 ‘port’ 필드는 3128 을 담고 있다.

이 페이지는 (설명이 기므로) <IMG> 태그에 “longdesc” 속성을 사용하여 연결되어 있어야 한다. 고로 이미지 태그는 이렇게 생겼을 것이다.

<IMG src=”screenshot1.png”
alt=”Proxy 세팅 다이어로그 박스는 ‘proxy.i.edu’ 를 ‘host’ 필드에 담고 있고 모든 프로토콜에 3128 ‘port’ 를 담고 있다”
title=”위의 스크린샷은 인디에나폴리스 켐퍼스의 Commnicator 4.x 프록시 세팅을 담고 있다.”
longdesc=”screenshot1.desc.html”
/>

대체 텍스트 alt 가 이미지를 대신하였고, title은 간단한 description(caption, 묘사) 를 하고 있으며 longdesc 는 이미지의 긴 설명을 담당하고 있다.

다시말하지만 alt 대체 텍스트는 이미지를 DESCRIPTION 묘사하는 것이 아니다. 오히려 이미지의 의미 MEANING 전달의 대체적 대변인이 되는 것이다.

다른 예:
<p>
<img src=”house.png” height=”110″ width=”320″
alt=”이 집은 초록색 창문이 있는 흰색 집이다.”
title=”서쪽에서 바라보는 집”
/>
이 집은 XXXXX 중간에 위치하고 있다.
</p>

이고 이하는 아니다.

<p>
<img src=”house.png” height=”110″ width=”320″
alt=”초록색 창문의 흰 집.”
title=”서쪽에서 바라보는 집”
/>
이 집은 XXXXX 중간에 위치하고 있다.
</p>

이것은 참 중요한 구별이며 웹이 아직도 WYSIWYG(보이는 그대로가 결과물인것) 이라고 생각하는 제작자들에게는 설명하기 어려운 부분이다.

올바른 첫번째 html 예제 부분을 보며 이미지가 꺼져있다면 어떻게 렌더링 되고 싶은지 상상해 보라. 아마도 이하와 같을 것이다.

이 집은 초록색 창문이 있는 흰색 집이다. 이 집은 xxxx 중간에 위치하고 있다.

그리고 이하와 같지는 않을것이다.

+——————————————-+
| 이 집은 초록색 창문이 있는 흰색 집이다. |
+——————————————-+ 이 집은 xxxx 중간에 위치하고 있다.

문단의 한 부분처럼 렌더된것은 “대체 텍스트 인라인 렌러딩” 이라고 하고 틀 안에 들어간 것은 “placeholder box 틀 안의 렌더링된 대체 텍스트” 라고 부른다.

주장 #4

“생각컨데 위의 이미지는 방향을 나타내고 있는데 유저의 이해를 위하여 각각(텍스트와 이미지)의 역할이 있으며 어느 한 부분도 때어 놓을수 없는거 같다.”

아니다. 이미지가 없다면 바른 인라인 대체 텍스트가 이미지의 title보다 그렇다 아니할지라도 빈 박스 보다 낫다. 그리고 빈 박스는 못생겼다.

주장 #5

“만약 이 예제에서 이미지가 읽히는데 실패하면서 사이즈가 지정된 이미지 대신 대체 텍스트가 출력되었다면 시멘틱 아이덴디티를 지키면서 유저들에게 페이지가 제대로 표현될만큼 로딩되지 않았다는 팁을 줄수 있다고 본다. 만약 대체 텍스트가 인라인으로 문단안에 위치하여 보이게 되면 (페이지가 제대로 로딩된 것인지 아닌지) 유저들에게 혼란을 줄수 있는거 같다.”

유저들은 제작자가 실수를 한것인지 아닌지에 관심을 두는 것이 아니다. 유저들은 정보를 원한다. 이미지가 제공되지 않았다면 페이지가 상황에 맞추어 적응해야 한다. 그리고 그것이 바로 대체텍스트 alt 가 하는 일이다.

주장 #6

“spacer GIF (레이아웃을 위해 사용되는 텅빈 gif) 를 사용하는 페이지가 있다. 하지만 웹마스터의 에러로 인해 존재하지 않는 파일이름으로 지정되어 이미지가 출력되지 않고 파일이름이 출력되며 그것이 레이아웃을 깨고 있다.”

그럼 제대로된 spacer GIF 파일이름으로 바꾸면 되지 않는가. 페이지에 문제가 있다면 당연히 수정되어야 한다. 그리고 레이아웃을 위한 것들은 CSS 가 사용되어야 하겠다.

주장 #7

“하지만 왜 파일명이 출력되는가? “alt” 텍스트가 없다면 파일이름이 아니라 아무것도 출력하지 않아야 하는거 아닌가?”

HTML 스펙 에 따르면 파일 이름을 써야 한다.

주장 #8

“대체 텍스트를 넣었다고 가정하고 (title이나 name 혹은 파일이름이 없다면) 사이즈가 정해진 박스안에 대체 텍스트를 보여준다면 1)언제나 대체텍스트는 보여지고 (텍스트가 다 보여지도록 툴팁을 더하고) 2)특정 상황을 염려하지 않아도 되고 3)페이지 레이아웃을 깨지 않아도 된다.”

이건 기초를 놓친 것이다. HTML 은 “페이지 레이아웃”을 위한것이 아니다. 만약 제작자가 원하는대로 표현되지 않았다면 어쩔수 없다. 그게 표현된것이다. 예를들어 폰트가 바꼈다거나 유저 스타일시트가 적용됬다거나 제작자의 색상들이 disable 되었다거나 브라우저가 그래픽을 지원하지 않는 경우, 페이지가 방화벽을 지나가며 필터되었거나 혹은 기타 다른 가능성들이 있다는 것이다.

만약 꾸밈을 위한 그래픽 요소라면 무시해 버릴수 있다 (alt=”" 를 해버려야 하는 상황이다) 하지만 decorative 꾸밈을 위한 이미지를 올바른 방향으로 이끌어 줘야하겠다. 만약 꾸밈을 위한 이미지가 아니고 정보적인 요소를 담고 있다면 텍스트와 동일한 폼의 대체 텍스트를 담고 있어야 하며 그것이 우리가 보여주어야 하는 것이다. (혹은 종합적 버전인 filename 이나 title).

위에서 언급했지만 페이지의 중요 요소는 레이아웃이 아니라 컨텐츠다. 만약 이미지를 disable 했는데 페이지가 레이아웃을 위한 이미지들에 의지하고 있었다면 어쩔수 없다. 괜찮다. 레이아웃보다 나머지 텍스트에 집중하면 된다.

주장 #9

“ALT 는 접근성의 이슈이다. 목표는 중요 포멧(여기서는 이미지)이 보이지 않는 컨텐츠에도 접근토록 하는 것이다.”

꼭 그렇지 만은 않다. 목표는 “의도한” 컨텐츠에도 접근토록 하는 것이다.

주장 #10

“대체 텍스트가 이미지의 의미적 대체 방법이라는 강조는 인터페이스의 툴로써 상당수 사용되는 이미지들을 빼놓고 있다. (anchor link 나 이미지맵)”

그러한 사용들을 배재하려는 것이 아니다. 버튼에 “Submit”(확인)이라고 적힌 이미지가 갖는 “의미”가 무엇이라고 생각하는가? 의미는 확인(제출) 이다. 고로 대체 텍스트는 Submit 인 것이다. 반복되는 “submit” 임을 감안하고 보통 쓰이는 이미지처럼 alt를 갖는 것이다.
(일몰: 이에대해서는 약간 애매한 주장이 나올수 있습니다. 한국에서는 제출이라는 단어를 포함한 버튼이 없죠. 보통 ‘확인’ 이라는 단어를 쓰니 의미적인 반대 의견을 낼수 있지만 아무튼 나중에 다루기로 합니다.)

주장 #11

“나는 꾸밈 이미지의 대체 텍스트가 “컨텐츠 안의 이미지 목적을 위한 기능적 텍스트모드 대체” 라는 기본원칙을 표현한다는 쪽으로 기울고 있다.”
(주석: 대체 텍스트는 단순히 텍스트 모드를 위한 기능적 대체 방법 이지 않는가 라는 의문)

동의하지 않는다. 꾸미는 이미지의 목적으로써 기능적 텍스트 모드 대체는 ASCII 의 부속물이겠지만 그것은 alt 텍스트라고 하기엔 부적절하다. 대체 텍스트는 텍스트 미디어 뿐만이 아니라 Speech 말하는 미디어 에도 사용된다. 그러므로 여기서 텍스트 대체 방법은 텍스트 모드의 대체 방법이 아닌 것이다.

결론

이미지를 갖고 있는 페이지를 Lynx 가 어찌 하는지 본적이 있는가? 제작자가 제대로 대체 텍스트를 사용하였다면 유저들은 Lynx 라 하더래도 모든 정보를 얻는다. 물론 이미지가 보일때 보다 약간 효율이 떨어질수도 있다. 하지만 유저들에게 “아 죄송합니다. 이미지를 보셔야만 저의 정보가 제값을 합니다.” 라고 아무도 말해주지 않았다.


이상 Ian Hicks의 글이었습니다. 이번글은 의미적인 논란이기에 이해와 해석에 상당한 어려움이 있었습니다. 하지만 그만큼 다룰만한 글이라고 생각됩니다. 위에서 잠깐 언급한 “확인” 버튼에 대하여는 사용성과 관련하여 후에 다루도록 하겠습니다.

13

CSS로 쉽게 animation을. (in 사파리)

safari
어제 만우절날 CSS3-IE 에 놀라신 분들게 죄송한 마음으로 이번에는 제대로된 포스팅을 올립니다. ^^ 최근 사파리 3.1출시된 소식은 이미 접하셨으리라 생각 됩니다. 그다지 큰 관심은 갖지 않았는데 3.1에서 구현 가능해진 이 CSS Animation 부분은 짚고 넘어가도 괜찮겠다는 생각이 들었습니다. 특히 CSS3 에서 구현되면 정말 좋으리라 라는 생각도 들고 말이죠.

사파리 블로그에 이미 소개 되었는지라 많은 분들이 아실지도 모르지만 CSS Animation 이라 불리우는 역동적인 CSS 부분들이 이번 3.1에 첨가되었고 그 중에서도 Transition (전환) 에 관한 것들이 구현 가능케 되었습니다. [이하의 모든 예제들은 사파리 3.1이 설치되어 있어야 확인하실수 있습니다.]

transition-property - 어떠한 전환 속성을 작동시킬 것인지 지정 예: opacity
transition-duration - 얼마동안 이 속성이 지속될것인지 지정ow long the transition should last.
transition-timing-function - 어떠한 종류의 타이밍을 갖을것인지 지정. 예: linear vs. ease-in vs. a custom cubic bezier function
transition - 물론 한번에 지정가능한 속성도 제공하는군요.

Google 사투리 번역은 사람이 직접 번역하는 대신 고도의 기계번역 기술을 활용해 제공되는 서비스입니다… 예를 들어 번역하고자 하는 문장을 전라도 사투리로 넣으면, 해당 문장을 다양한 사투리로 번역하여 문서를 검색하고, 검색된 문서들은 다시 전라도 사투리로 변환되어 사용자에게 제공됩니다 - Google Korea

위의 div 에 마우스를 가져다 대시면 천천히 div 가 사라지는 효과를 확인하실수 있습니다. 이는 div 에다
div {opacity: 1; -webkit-transition: opacity 1s ease-in; }
값을 정해준 후 hover 시에 opcity 가 0으로 되도록 지정된 결과 입니다.
div:hover {opacity: 0;}

이 외에도 여러가지 효과를 줄수 있는데 간단한 transition 속성으로 많은 이득을 볼수 있습니다.

  • Home
  • About
  • Contact

실무적으로야 아직 쓰이지는 못하겠지만 여러가지 생각해 볼수 있는 부분인거 같네요. 이번에 Torrey Rice가 이 CSS Animation 기능을 활용해서 SVG 와 함께 멋진 동작 예제를 구현해 놓았습니다. 설명을 곁들여서 보시면 이해가 더 쉬우실 겁니다.

4

IE9, CSS3-IE 를 지원키로 결정

최근 IE9의 루머가 빠르게 퍼지고 있는 가운데 IE 팀이 블로그를 통한 IE9의 입장과 CSS3 에 대한 계획을 밝혔습니다. 이것저것 살펴보니 IE8과 그다지 다를 것은 없지만 CSS3 부분에 있어서는 상당한 논란을 불러올듯 하네요.

아시다시피 CSS3의 계획이 계속 지연되면서 몇몇 브라우저들 사이에서 multi background image나 text shadow 등등이 자체적으로 지원되고 있는 실정입니다만 이러한 불완전함을 핑계로 인터넷익스플로러 팀이 자체 CSS 개발을 이루겠다는 야심을 보인 것입니다. 일단은 CSS3-IE 로 부르고 있고 이 스타일시트가 초안으로 들어갈때 즈음에 IE9 베타가 출시될 것으로 보입니다.

많은 개발자들과 디자이너들의 한숨이 여기저기서 튀어 나오고 있는데요.

마이크로소프트의 인터넷익스플로러 팀이 CSS3-IE를 개발하려 한다는 것은 일모리의 조작된 만우절 논리일 뿐이다. - 빌게인츠

CSS3-IE 개발을 과연 누가 믿겠느냔 말이다. 그저 4월1일의 장난일 뿐이다. - 젤든맨

이러한 논란들로 CSS3-IE 의 개발을 무시하고 있습니다. 저 또한 강력히 동의하고 있는 부분이구요. 여러분들도 동의 하시리라 생각됩니다.

너무나도 낚이신분들이 많을꺼 같아 두려움의 한숨만 나올 뿐입니다…

죄송합니다. :)

12

워드프레스2.5 정식 릴리스

워드프레스

드디어 워드프레스 2.5가 정식 릴리스 되었습니다. 지난번 RC1 공개때 상당히 기대를 했던지라 공개되자마자 일모리네 업데이트를 단행했습니다. 오랜만의 업그레이드라 살짝 긴장되더군요. 잠시 한글이 깨지는 사태가 발생하긴 했으나 팔콘님께서 빠르게 복구에 도움을 주셨습니다. 피드또한 제대로 작동 중입니다.

Wordpress 2.5 는 내부 Structure 틀 뿐만 아니라 관리자 페이지의 업데이트가 가장 큰 변화이지만 새로운 메뉴 배치라던지 디자인등이 이전 버전의 틀을 기반으로 옮겼기 때문에 사용성에 있어서 어려움은 없고 오히려 상당히 만족스러운 인터페이스를 제공하고 있습니다. 업그레이드를 적극 추천하고 싶군요.

워드프레스 업그레이드 가이드

  1. DB를 백업합니다.
  2. 워프 파일들 또한 백업합니다.
  3. 백업들이 제대로 되었나 확인합니다.
  4. 플러그인들을 모두 Activate 에서 Deactivate으로 꺼줍니다.
  5. 위의 4 스텝들이 제대로 되었나 다시 확인해 봅니다.
  6. 워드프레스 새 버전을 다운하여 압축을 풉니다.
  7. 이하의 파일들을 제외하고는 모든 워드프레스 파일들을 계정에서 지웁니다.
    wp-config.php
    wp-content 폴더. 하지만 그 안의 cache 나 plugins/widgets 는 지우는 것이 좋습니다.
    wp-images 폴더
    wp-content/languages 폴더
    .htaccess 파일
    robots.txt 파일
  8. 새 파일들을 계정으로 업로드 합니다.
  9. 워드프레스 업그레이드 프로그램을 돌립니다.
    http://계정주소/워드프레스폴더/wp-admin/upgrade.php
  10. Permalinks 와 .htaccess 를 업데이트 시켜줍니다.
  11. 플러그인들과 테마를 2.5와 호환이 가능한 버전으로 업데이트 시켜줍니다.
  12. 플러그인들을 Activate 모드로 작동시킵니다.
  13. 워드프레스에 어떤 변화가 있는지 살펴봅니다.

업그레이드 완료!

9
Page 4 of 49« First...«23456»...Last »

    RECENT POSTS

    COMMENTS

    • Korea.net의 베너
    • 한RSS 구독