(운영체제는 Windows Vista HomeK)
Safari 3 beta
Opera 9
Firefox 2
Internet Explorer 7
우리가 보고 싶어하는 모습은?
2008년 1월 30일 수요일
Acid3 테스트해보자~
얼마전에 IE8이 Acid2를 통과했다는 반가운 소식이 들렸고, 며칠전 MS가 IE8의 기본 렌더링을 IE7과 동일하게 가져갈 것이라는 안타까운 소식도 들었다. 그 와중에 이안 힉슨은 Acid3을 발표하면서 새로운 숙제를 내주고 있네요. 다음은 제 PC에 설치된 사파리, 오페라, 파이어폭스 인터넷익스플로어7 입니다.
(운영체제는 Windows Vista HomeK)
(운영체제는 Windows Vista HomeK)
2008년 1월 28일 월요일
브라우저의 역사
지난 1월 22일이 모질라의 탄생 10주년이었단다. 기념해서 나온 모질라의 역사인데 주류 브라우저가 함께 그려져 있어 웹의 태동과 함께 탄생한 브라우저의 역사를 한눈에 볼 수 있게 해놨다.
invalid-file
invalid-file원본 PDF링크
내 블로그 가치평가
일전에도 한번 해봤는데 간만에 생각나서 다시 들어가봤다.
전(07.12)에는 127만원쯤 되었는데 지금은 148만원이 넘게 책정되었다.
요즘 주식이고 펀드고 다 떨어지고 있는데 이게 현금으로 환산되면 얼마나 좋을까 싶은 생각이 든다. 아흑-
전(07.12)에는 127만원쯤 되었는데 지금은 148만원이 넘게 책정되었다.
요즘 주식이고 펀드고 다 떨어지고 있는데 이게 현금으로 환산되면 얼마나 좋을까 싶은 생각이 든다. 아흑-
장애인차별금지법 시행에 대한 토론
지난주 한국 웹 접근성 그룹 에서 장애친차별금지법에 대한 토론이 있었다.
참여하고 싶었지만 낯을 가리다가 그만 신청 타이밍을 놓쳐 버렸다.
언론에서 지난해 말부터 장차법에 대한 기사를 속속 내놓고 있기는 하지만
뭐랄까 시행을 3개월 정도 앞둔 시점에서도 아직 많이 알려지지 않은것 같다.
오늘 몇몇 기획자와 디자이너 분들께 장차법에 대해 들어봤냐고 물어봤지만
한결같이 처음 듣는다는 답변 뿐이었다.
정작 이 법률에 영향을 받을 업계의 종사자들도 태반이 모르고 있을진데
일반인들은 오죽할까 싶다.
아무래도 대다수의 웹기획자나 개발, 디자이너들은 웹접근성 강화가
클라이언트의 요구와 웹기획자의 기획, 웹퍼블리셔의 수완으로 해결되는 것쯤으로 인식하는 것 같다.
웹에 종사하는 모든 사람들이 공통으로 이해하고,
지식을 갖추어야만 완벽한 웹표준화를 이루고,
웹접근성을 높일수 있는 것인데 말이다.
그래야 장차법을 준수하는 웹사이트를 만들어낼 수 있는데 말이다.
발등에 불이 떨어져야 그때야 불이 뜨거운줄 아는 한국사람들-
뜨겁다고 알려주는 사람이 있을때 미리 대비하고 준비하는 모습들을 가졌으면 좋겠다.
참여하고 싶었지만 낯을 가리다가 그만 신청 타이밍을 놓쳐 버렸다.
언론에서 지난해 말부터 장차법에 대한 기사를 속속 내놓고 있기는 하지만
뭐랄까 시행을 3개월 정도 앞둔 시점에서도 아직 많이 알려지지 않은것 같다.
오늘 몇몇 기획자와 디자이너 분들께 장차법에 대해 들어봤냐고 물어봤지만
한결같이 처음 듣는다는 답변 뿐이었다.
정작 이 법률에 영향을 받을 업계의 종사자들도 태반이 모르고 있을진데
일반인들은 오죽할까 싶다.
아무래도 대다수의 웹기획자나 개발, 디자이너들은 웹접근성 강화가
클라이언트의 요구와 웹기획자의 기획, 웹퍼블리셔의 수완으로 해결되는 것쯤으로 인식하는 것 같다.
웹에 종사하는 모든 사람들이 공통으로 이해하고,
지식을 갖추어야만 완벽한 웹표준화를 이루고,
웹접근성을 높일수 있는 것인데 말이다.
그래야 장차법을 준수하는 웹사이트를 만들어낼 수 있는데 말이다.
발등에 불이 떨어져야 그때야 불이 뜨거운줄 아는 한국사람들-
뜨겁다고 알려주는 사람이 있을때 미리 대비하고 준비하는 모습들을 가졌으면 좋겠다.
2008년 1월 27일 일요일
마크업이야? 메이크업이야?
내가 처음 HTML을 접한건 1997년 겨울이었다. 우연히 서점에 들렸다가 인터넷이라는 생소한 제목을 달고 있는 책들 틈이 머뭇거리게 되었고, 그 중에 HTML을 소개하는 책 한권을 손에 들게 되었었다. 나는 그날 이후로 HTML에 대해 공부했고, 궁금해했고, 찾아보게 되었다. 적지 않은 관련 서적을 구입하면서 공부했고, 처음으로 개인홈페이지를 만들었다. 동아리 홈페이지도 만들었고, 학교 홈페이지도 만들었다. PC통신을 연구하던 동아리는 내 의지로 홈페이지 연구반이 되어 버렸고, 나는 국어국문학과에 가서 인문대답지 않은(?) 홈페이지를 만들어서 엉뚱하게 유명한 학생이 되어 버리기도 했었다. 교육컨텐츠를 제작하는 회사에 들어가 반년간 드림위버를 이용한 코딩일을 하기도 했고, 처음으로 웹에이젼시에 들어가 커다란 사이트를 개발하는 프로젝트에 참여하기도 했다. 그렇게 나는 학교와 업계를 왔다갔다 하면서 웹퍼블리싱 공부를 하고, 경력을 쌓아갔었다. 그 와중에 내게 조금은 특별한 경험이 있었는데 2001년 봄 내가 다니던 고등학교에서 방과후 특별수업을 할수 있는 기회가 주어졌었다. 그때 나는 스무명 남짓의 학생들(얼굴도 알아볼 수 있을만큼 가까운 후배들)을 앉혀놓고 홈페이지 수업을 했었는데 첫 수업은 아직도 기억에 남아 있다.
칠판에 HTML이라고 써놓고 학생들에게 이게 무슨 뜻인지 아느냐고 물었다. 당연하지만 모든 학생들이 입을 다물고 나만 바라보고 있었다. 잠시 지켜보다가 동아리 후배이기도 했던 학생에게 직접 물었다. 학생은 화면을 꾸며주는 인터넷 언어입니다. 라고 대답했다. 그리고 나는 칠판에 다시 썼다. Hypertext Markup Language 라고.
어떤 책이었는지는 정확히 기억나지 않지만 2000년대 이전의 꽤 많은 책과 웹사이트에서 HTML을 Hypertext Makeup Language라고 가르쳐주고 있었다. 당영한 이야기이지만 이건 틀린것이다. 우린 HTML의 M이 Markup의 약자라는 사실을 너무나 잘 알고 있다. 하지만 그땐 그랬다. 메이크업과 마크업의 차이를 알지 못했다. 번역자의 실수일수도 있고, 검수자의 무지에서 비롯된 것일수도 있었다. 어찌되었건 덕분에 HTML을 잘못 이해해버린 사람들을 만들어 버렸다.
메이크업은 화장술에 쓰이는 용어이다. 보통 기초화장 뒤에 하는 색조화장을 말하는데, 조금 다른 분야에서 사용되더라도 그 의미는 크게 벗어나지 않는다. 그럼 HTML을 메이크업이라고 풀이했을때 어떻게 될까?
하이퍼텍스트는 화면을 꾸미는 언어가 된다!
아 이 얼마나 이해가 쉬운 풀이인가!! 내 첫 수업때 화면을 "꾸미는"이라고 대답했던 학생이 결코 죄가 없음이다. 나 역시 한때 그렇게 알고 있었으니까.
다행히도 난 당시 메이크업이 잘못된 것이고, 마크업이 맞다는 것을 알고 있었다. 그리고 학생에게 "꾸미는"이 아니라 "구조화하는" 것이라고 설명하는데 애를 써야 했다. (하지만 아쉽게도 당시의 난 구조화라는 풀이만 알았다. 스타일시트를 통한 표현의 분리까지는 이해하지 못했었다.)
그런데 아쉽게도 아직도 HTML을 웹을 꾸미는 언어쯤으로 생각하는 사람이 많은것 같다. 수 많은 웹기획자와 웹디자이너, 웹개발자들 말이다. (웹퍼블리셔들 가운데에도 있을 것이다) 웹기획자는 고객에게 어필할수 있는 화면을 고민하고, 웹디자이는 자신의 작품을 완벽하게 브라우져화면에 띄워주는 목적으로 HTML을 사용하거나 이해한다. 중간에 웹퍼블리셔가 아무도 알아주지 않는 마크업 작업을 했더라도! 웹개발자는 HTML을 조각조각 쪼개는것도 모잘라 온갖 서버측 스크립트 언어로 바꿔 버림으로써 디자인과 HTML, 스크립트가 하나되는 삼위일체의 꿈을 완성(?) 시켜준다.
요즘 우리가 고민하고 있는 웹접근성 향상과 웹표준화 작업은 애초에 Markup을 Makeup으로 오해하지 않았더라면 이만큼 늦게 깨닫지도 않았을 것이며, 이렇게 답답해하지 않았을수 있었을텐데라는 아쉬움이 든다.
칠판에 HTML이라고 써놓고 학생들에게 이게 무슨 뜻인지 아느냐고 물었다. 당연하지만 모든 학생들이 입을 다물고 나만 바라보고 있었다. 잠시 지켜보다가 동아리 후배이기도 했던 학생에게 직접 물었다. 학생은 화면을 꾸며주는 인터넷 언어입니다. 라고 대답했다. 그리고 나는 칠판에 다시 썼다. Hypertext Markup Language 라고.
어떤 책이었는지는 정확히 기억나지 않지만 2000년대 이전의 꽤 많은 책과 웹사이트에서 HTML을 Hypertext Makeup Language라고 가르쳐주고 있었다. 당영한 이야기이지만 이건 틀린것이다. 우린 HTML의 M이 Markup의 약자라는 사실을 너무나 잘 알고 있다. 하지만 그땐 그랬다. 메이크업과 마크업의 차이를 알지 못했다. 번역자의 실수일수도 있고, 검수자의 무지에서 비롯된 것일수도 있었다. 어찌되었건 덕분에 HTML을 잘못 이해해버린 사람들을 만들어 버렸다.
메이크업은 화장술에 쓰이는 용어이다. 보통 기초화장 뒤에 하는 색조화장을 말하는데, 조금 다른 분야에서 사용되더라도 그 의미는 크게 벗어나지 않는다. 그럼 HTML을 메이크업이라고 풀이했을때 어떻게 될까?
하이퍼텍스트는 화면을 꾸미는 언어가 된다!
아 이 얼마나 이해가 쉬운 풀이인가!! 내 첫 수업때 화면을 "꾸미는"이라고 대답했던 학생이 결코 죄가 없음이다. 나 역시 한때 그렇게 알고 있었으니까.
다행히도 난 당시 메이크업이 잘못된 것이고, 마크업이 맞다는 것을 알고 있었다. 그리고 학생에게 "꾸미는"이 아니라 "구조화하는" 것이라고 설명하는데 애를 써야 했다. (하지만 아쉽게도 당시의 난 구조화라는 풀이만 알았다. 스타일시트를 통한 표현의 분리까지는 이해하지 못했었다.)
그런데 아쉽게도 아직도 HTML을 웹을 꾸미는 언어쯤으로 생각하는 사람이 많은것 같다. 수 많은 웹기획자와 웹디자이너, 웹개발자들 말이다. (웹퍼블리셔들 가운데에도 있을 것이다) 웹기획자는 고객에게 어필할수 있는 화면을 고민하고, 웹디자이는 자신의 작품을 완벽하게 브라우져화면에 띄워주는 목적으로 HTML을 사용하거나 이해한다. 중간에 웹퍼블리셔가 아무도 알아주지 않는 마크업 작업을 했더라도! 웹개발자는 HTML을 조각조각 쪼개는것도 모잘라 온갖 서버측 스크립트 언어로 바꿔 버림으로써 디자인과 HTML, 스크립트가 하나되는 삼위일체의 꿈을 완성(?) 시켜준다.
요즘 우리가 고민하고 있는 웹접근성 향상과 웹표준화 작업은 애초에 Markup을 Makeup으로 오해하지 않았더라면 이만큼 늦게 깨닫지도 않았을 것이며, 이렇게 답답해하지 않았을수 있었을텐데라는 아쉬움이 든다.
사랑하는 사람들의 연락처 정도는 기억하자
핸드폰이라는 것이 생긴 뒤로 전화번호를 기억하는 일이 귀찮은 일이 되어 버린것 같다. 적게는 수십명에서 많게는 수백명의 연락처를 배불리 삼킨 핸드폰들은 똑똑하게도 단축키를 누르거나, 뛰어난 검색 기능으로 찾아내기 쉽게 만들어져 있다. 덕분에 내 머리속에 기억되는 전화번호는 고작해야 열개 남짓된다.
내것과 어머니, 동생, 집. 그리고 오래전에 외워두고 아직 잊어버리지 않은 친구 몇몇의 번호 정도-
오늘 책상 정리를 하다가 지난 2년간 군대에서 사용했던 전화번호 수첩을 찾았다. 첫장에 어머니와 동생의 사진을 꽂아놓고 그 옆에는 군번이 흐릿하게 적혀 있다. 아마 처음 군번을 받았을 때 잊어먹지 않으려고 적어두었던것 같다.
속을 들쳐보면 아버지 제사일, 어머니와 동생의 생일. 훈련소 주소부터 해서 내 군복 치수까지 적혀 있었다. 그 다음부터는 친구들 선후배들, 지인들의 연락처가 가나다 순으로 차곡차곡 적혀 있고, 몇몇을 빼고는 주소까지 빠짐없이 적어두었다.
그러고보니 군대가기 한달여전 쯤에 이 수첩을 사서 만나는 사람들마나 집주소를 물어서 적었던 일이 기억난다. 대부분의 지인들에게 편지를 보냈고, 운이 좋게도 한번 이상은 답장을 받았던 것 같다. 몇몇은 너무나 고맙게도 많은 편지를 보내주기도 했고, 지혜는 멀리 스페인에서도 잊지 않고 엽서를 보내 주었었다.
군대에 있던 2년간 저 수첩은 내게 가장 소중한 것이었다. 사회와 단절된 공간에서 유일한 소통의 기회였던 전화와 편지를 가능하게 했던것 저 허름해져버린 수첩이 있었기 때문이었으니까. 한번은 바닥에 떨어뜨려 젖어버리기까지 했지만 글자가 번질까봐 급하게 닦아내던 기억도 떠오른다.
여자친구의 전화번호를 어제까지 외우지 못했던- 아니 외워야겠다는 생각을 못했던 나.
핸드폰에 저장되어 있는 모든 연락처는 어렵겠지만 내가 사랑하는 사람들의 번호 정도는 외워둬야겠다는 생각을 해본다.
내것과 어머니, 동생, 집. 그리고 오래전에 외워두고 아직 잊어버리지 않은 친구 몇몇의 번호 정도-
오늘 책상 정리를 하다가 지난 2년간 군대에서 사용했던 전화번호 수첩을 찾았다. 첫장에 어머니와 동생의 사진을 꽂아놓고 그 옆에는 군번이 흐릿하게 적혀 있다. 아마 처음 군번을 받았을 때 잊어먹지 않으려고 적어두었던것 같다.
속을 들쳐보면 아버지 제사일, 어머니와 동생의 생일. 훈련소 주소부터 해서 내 군복 치수까지 적혀 있었다. 그 다음부터는 친구들 선후배들, 지인들의 연락처가 가나다 순으로 차곡차곡 적혀 있고, 몇몇을 빼고는 주소까지 빠짐없이 적어두었다.
그러고보니 군대가기 한달여전 쯤에 이 수첩을 사서 만나는 사람들마나 집주소를 물어서 적었던 일이 기억난다. 대부분의 지인들에게 편지를 보냈고, 운이 좋게도 한번 이상은 답장을 받았던 것 같다. 몇몇은 너무나 고맙게도 많은 편지를 보내주기도 했고, 지혜는 멀리 스페인에서도 잊지 않고 엽서를 보내 주었었다.
군대에 있던 2년간 저 수첩은 내게 가장 소중한 것이었다. 사회와 단절된 공간에서 유일한 소통의 기회였던 전화와 편지를 가능하게 했던것 저 허름해져버린 수첩이 있었기 때문이었으니까. 한번은 바닥에 떨어뜨려 젖어버리기까지 했지만 글자가 번질까봐 급하게 닦아내던 기억도 떠오른다.
여자친구의 전화번호를 어제까지 외우지 못했던- 아니 외워야겠다는 생각을 못했던 나.
핸드폰에 저장되어 있는 모든 연락처는 어렵겠지만 내가 사랑하는 사람들의 번호 정도는 외워둬야겠다는 생각을 해본다.
2008년 1월 25일 금요일
XHTML로 바꾸지 말아야 하는 이유 Top5
- 시간제로 일하고 있는 경우
- 가능한 모든 브라우저나 기기에 대한 모든 버전에 맞게 여러 개의 페이지를 만들기를 즐기는 경우
- 머리 속에서 그냥 무조건 하지 말라고 하는 경우
- 웹 사업을 그만 두려고 하는 경우
- XHTML을 사용할 줄 모르는 경우
<제프리 젤드만의 웹표준 가이드 2ed 발췌>
내가 HTML을 버리고 XHTML로 가고자 하는
이유는 적어도 위 다섯가지에 포함되지 않을 것이라는 확신때문이다.
어제 웹표준가이드(2ed)를 완독했다. 기술서라기 보다는 실무에서 와닿는 이해와 설명이 많은 책이었는데 우리가 웹접근성을 향상시키고, 웹표준화를 배우고, 적용하면서 왜? 왜지? 왜일까? 라고 수없이 물음표를 달았던 것들에 대한 느낌표를 달아주는 책이었지 않나 싶다.
책을 다 읽고 가장 먼저 회사의 기획자 한분께 바로 건네면서 꼭 읽어보시라고 했다.
나와 같은 웹퍼블리셔는 물론이거니와 웹디자이너, 웹개발자, 웹기획자까지
웹에서 손가락을 묻어놓고 먹고사는 모든 사람들은 꼭 한번 읽어봤으면 하는 책임에는 틀림없는것 같다.
-
다만, 급하게 번역을 하여서인지 오타도 더러 보였으며, 문장도 다소간 어색한 부분이 있어 아쉽게 느껴졌다.
이유는 적어도 위 다섯가지에 포함되지 않을 것이라는 확신때문이다.
어제 웹표준가이드(2ed)를 완독했다. 기술서라기 보다는 실무에서 와닿는 이해와 설명이 많은 책이었는데 우리가 웹접근성을 향상시키고, 웹표준화를 배우고, 적용하면서 왜? 왜지? 왜일까? 라고 수없이 물음표를 달았던 것들에 대한 느낌표를 달아주는 책이었지 않나 싶다.
책을 다 읽고 가장 먼저 회사의 기획자 한분께 바로 건네면서 꼭 읽어보시라고 했다.
나와 같은 웹퍼블리셔는 물론이거니와 웹디자이너, 웹개발자, 웹기획자까지
웹에서 손가락을 묻어놓고 먹고사는 모든 사람들은 꼭 한번 읽어봤으면 하는 책임에는 틀림없는것 같다.
-
다만, 급하게 번역을 하여서인지 오타도 더러 보였으며, 문장도 다소간 어색한 부분이 있어 아쉽게 느껴졌다.
2008년 1월 24일 목요일
인터넷 익스플로어 이올라스 패치
MS에서 드디어 이올라스 패치가 올라왔네요.
IE 7 버전은
http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=48ba80a0-697f-480a-a188-95c576d8a8bb
IE 6 버전은
http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=3f8ba2aa-ed73-4764-a56d-9515a9c500de
이제는 외부 스크립트를 사용하지 않고도, HTML문서에서 바로 플래쉬 같은 오브젝트 객체를 삽입할수 있겠네요. 다행입니다^^
IE 7 버전은
http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=48ba80a0-697f-480a-a188-95c576d8a8bb
IE 6 버전은
http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=3f8ba2aa-ed73-4764-a56d-9515a9c500de
이제는 외부 스크립트를 사용하지 않고도, HTML문서에서 바로 플래쉬 같은 오브젝트 객체를 삽입할수 있겠네요. 다행입니다^^
2008년 1월 22일 화요일
CSS로 만든 Layout 소개
다음은 CSS로 구현된 Layout을 소개하는 사이트들입니다.
제가든같이 유명한 곳은 많이들 알고 계실테고,
제가 즐겨찾는 몇몇 곳은 다양한 형태의 레이아웃을 보여주기도 해서 공부가 많이 되고 있습니다.
아래 사이트의 경우에는 순수하게 레이아웃만을 보여주고 있어, CSS로 처음 레이아웃을 잡아야 하는 경우에 도움이 많이 됩니다. 저도 처음에 이 곳에서 소스를 가져와서 수정해서 사용했던적이 있었습니다.
제가든같이 유명한 곳은 많이들 알고 계실테고,
제가 즐겨찾는 몇몇 곳은 다양한 형태의 레이아웃을 보여주기도 해서 공부가 많이 되고 있습니다.
- http://www.cssjuice.com/30-weblogs-with-grid-based-design/
- http://www.cssimport.com/
- http://www.mezzoblue.com/zengarden/alldesigns/
- http://www.alistapart.com/articles/holygrail
아래 사이트의 경우에는 순수하게 레이아웃만을 보여주고 있어, CSS로 처음 레이아웃을 잡아야 하는 경우에 도움이 많이 됩니다. 저도 처음에 이 곳에서 소스를 가져와서 수정해서 사용했던적이 있었습니다.
2008년 1월 20일 일요일
탭 메뉴 쉽게 만들자
CSS를 이용해서 쉽게 탭메뉴를 만들수 있는 소프트웨어를 하나 소개합니다.
CSS Tab Designer 라는 프로그램으로 일반적으로 많이 사용되는 탭메뉴를 쉽게 퍼블리싱해주는 도구입니다.
가로와 세로 형태 모두 지원하며 다양한 디자인 템플릿을 제공하고 있어, 탭메뉴를 만드는 시간을 줄여줍니다.
또한, 익스플로어, 파이어폭스, 사파리, 오페라 등 다양한 브라우져로 프리뷰를 지원하며, 표준 HTML(XHTML 1.0 Transitional)과 CSS를 이용하였기 때문에 크로스브라우징 역시 제대로 지원하고 있습니다.
웹표준화를 공부하고 계시는 분들이나, 실무에서 탭메뉴를 만들어야 하는데 부담감을 느끼시는 분들에게 요긴한 도구라는 생각이 듭니다.
위에서 보는것과 같이 대표적인 표준 브라우저들 모두 문제 없이 탭메뉴를 보여주고 있다. 사파리 3 beta(윈도우용)에서만 2px정도의 오차를 보여주는데 베타버전의 문제인지는 정확히 알수 없지만 크게 문제가 될것 같진 않다. 꼼꼼한 웹퍼블리셔라면 위의 문제만 해결해주면 될 것 같다.
CSS Tab Designer 라는 프로그램으로 일반적으로 많이 사용되는 탭메뉴를 쉽게 퍼블리싱해주는 도구입니다.
가로와 세로 형태 모두 지원하며 다양한 디자인 템플릿을 제공하고 있어, 탭메뉴를 만드는 시간을 줄여줍니다.
또한, 익스플로어, 파이어폭스, 사파리, 오페라 등 다양한 브라우져로 프리뷰를 지원하며, 표준 HTML(XHTML 1.0 Transitional)과 CSS를 이용하였기 때문에 크로스브라우징 역시 제대로 지원하고 있습니다.
 |  |
웹표준화를 공부하고 계시는 분들이나, 실무에서 탭메뉴를 만들어야 하는데 부담감을 느끼시는 분들에게 요긴한 도구라는 생각이 듭니다.
다양한 브라우저로 프리뷰를 지원합니다
표준HTML, CSS를 사용하고 있습니다.
크로스 부라우징을 제대로 지원한다
위에서 보는것과 같이 대표적인 표준 브라우저들 모두 문제 없이 탭메뉴를 보여주고 있다. 사파리 3 beta(윈도우용)에서만 2px정도의 오차를 보여주는데 베타버전의 문제인지는 정확히 알수 없지만 크게 문제가 될것 같진 않다. 꼼꼼한 웹퍼블리셔라면 위의 문제만 해결해주면 될 것 같다.
<b>와 <strong>의 차이
HTML문서를 작성할 때 가장 많이 표현하게 되는 양식이 글자를 굵게하는 것입니다. 그리고 이 문제를 해결하기 위해서 <b> 앨리먼트를 너무나 당연하게, 그리고 쉽게 사용합니다. 하지만 웹접근성을 높이고자 한다면, 웹표준을 이해하고 준수하고자 한다면 <b>앨리먼트보다는 <strong>앨리먼트가 좋습니다.
<strong>앨리먼트는 의미적으로 강조를 가리킵니다. 반면에 <b>앨리먼트는 글자를 단순히 굵게 표시하여 표현하는데 목적을 둡니다. 표현상으로 두 앨리먼트의 차이는 없지만, 스크린리더와 같이 앨리먼트 의미를 해석해서 내용을 읽어주는 경우 <strong>앨리먼트가 적용된 텍스트를 강조해서 읽어줄 수 있습니다.
더불어 강조된 글자 표현을 위해서 스타일을 이용하는 경우가 많은데, 이럴 경우 스크린리더에서는 display, visibility등 몇몇 경우를 제외하고는 스타일을 참조하지 않으므로(신현석님 도움말씀) 강조의 의미를 살릴수가 없는것 같습니다. 특별히 의미를 고려해서 텍스트를 강조해야만 한다면 <strong>앨리먼트를 이용하는 것이 좋을것 같습니다. 그런데 <b> 앨리먼트를 <strong>앨리먼트로 교체해야한다는 논리 때문에 무수하게 많이 사용된 모든 <b>앨리먼트를 <strong>앨리먼트로 바꾼다면 오히려 문제가 생기지 않을까 싶습니다. 첫째로 글자수가 늘어나 시간이 늘고, 용량이 늘어나게 됩니다. 둘째로 습관적인 굵은 글씨가 모두 의미적으로 "강조"였는가 하는 것입니다. 무분별하게 <strong>앨리먼트를 사용한다면 정말로 중요한 것과 우선순위를 낮출수 있는 것들과의 구분이 모호해질 수 있게 됩니다. 따라서, <b>와 <strong>앨리먼트를 사용할 곳을 잘 판단하여야 할 것이고, <strong>과 같이 강조 의미를 가지고 있는 <em>앨리먼트를 지정한 후에 스타일을 이용해서 기본 스타일속성을 없애고, <strong>과 같이 굴게 표시(이 경우 본래의 em 속성을 사용할 일이 없어야 한다)하는 스타일을 지정해볼수도 있을것 같습니다.
<strong>앨리먼트는 의미적으로 강조를 가리킵니다. 반면에 <b>앨리먼트는 글자를 단순히 굵게 표시하여 표현하는데 목적을 둡니다. 표현상으로 두 앨리먼트의 차이는 없지만, 스크린리더와 같이 앨리먼트 의미를 해석해서 내용을 읽어주는 경우 <strong>앨리먼트가 적용된 텍스트를 강조해서 읽어줄 수 있습니다.
더불어 강조된 글자 표현을 위해서 스타일을 이용하는 경우가 많은데, 이럴 경우 스크린리더에서는 display, visibility등 몇몇 경우를 제외하고는 스타일을 참조하지 않으므로(신현석님 도움말씀) 강조의 의미를 살릴수가 없는것 같습니다. 특별히 의미를 고려해서 텍스트를 강조해야만 한다면 <strong>앨리먼트를 이용하는 것이 좋을것 같습니다. 그런데 <b> 앨리먼트를 <strong>앨리먼트로 교체해야한다는 논리 때문에 무수하게 많이 사용된 모든 <b>앨리먼트를 <strong>앨리먼트로 바꾼다면 오히려 문제가 생기지 않을까 싶습니다. 첫째로 글자수가 늘어나 시간이 늘고, 용량이 늘어나게 됩니다. 둘째로 습관적인 굵은 글씨가 모두 의미적으로 "강조"였는가 하는 것입니다. 무분별하게 <strong>앨리먼트를 사용한다면 정말로 중요한 것과 우선순위를 낮출수 있는 것들과의 구분이 모호해질 수 있게 됩니다. 따라서, <b>와 <strong>앨리먼트를 사용할 곳을 잘 판단하여야 할 것이고, <strong>과 같이 강조 의미를 가지고 있는 <em>앨리먼트를 지정한 후에 스타일을 이용해서 기본 스타일속성을 없애고, <strong>과 같이 굴게 표시(이 경우 본래의 em 속성을 사용할 일이 없어야 한다)하는 스타일을 지정해볼수도 있을것 같습니다.
2008년 1월 18일 금요일
내 뽀삐~!
서브 노트북이지만 깔끔하고 오동통한 외관 덕분에 뽀삐(포피)라고 불렸던 후지쯔 P5010 모델. 내 세번째 노트북이자 가장 오랜시간 함께한 노트북이다. 얼마전에 후지쯔 E8410을 새로 구입하면서 동생에게 물려(?) 주었는데 상황이 바껴서 다시 내게로 돌아왔다. 갑자기 오갈데 없는 신세가 되어버린 뽀삐... 이젠 중고로 팔아야 하나 했는데 예전에 한번 떨어뜨리면서 깨먹은 부분이 유난히 아리게 느껴진다.
무상 기간은 한참 지났지만 일단 후지쯔에 문의를 해보고, 비싸지 않은 견적으로 수리가 된다면 (사실 CF 슬롯을 사용하지 않을거라면 쓰는데는 문제가 없다. 나도 여지껏 그렇게 잘 써왔으니까-_-) 고쳐서 팔던가, 아니면 정말로 서브로 사용해야할 것 같다.
2008년 1월 16일 수요일
한국모질라커뮤니티 연말모임때 발표하던 모습
2008년 1월 15일 화요일
스킨 변경했습니다.
공개된 스킨을 몇번 갈아탔던 것을 제외하면 직접 고쳐쓴 스킨을 사용하는건 처음이 아닌가 싶습니다.
적어도, 이와 똑같은 스킨이 '아마도' 없을것이라는 생각을 가진다면 말이지요.
이 스킨은 Ludens님의 상단 디자인 협조속에 Daisy님의 스킨위에 덮어쓰는 방식으로 제작되었습니다.
전체적으로 연두색 계열로 가고자 했고, 파스텔 느낌을 말했더니 Ludens님이 로고와 나뭇잎 네장을 앙증맞게 그려주셨네요. 감사합니다^-^ 컨텐츠와 사이드바 너비 영역은 Daisy님의 레이아웃을 거의 그대로 사용했기 때문에 동일하구요. 일부 스타일을 제 마음대로 고쳐버렸습니다. Article 영역에 태그가 한 줄 이상으로 길어지면 하단 라인이 글자와 겹쳐지는 문제 등이 있어 고쳐놨구요.(Daisy님께도 말씀드려야 하나...) 전체적인 배색과 줄간격을 조금씩 조정했습니다.
디자이너가 아닌지라 직접 디자인도 못하고, 귀차니즘 때문에 남의 레이아웃을 가져와서 내것인양 되새김질한 스킨이긴 하지만 그래도 이 세상 단 하나뿐인 스킨이라는 것 때문에 만족하고 있습니다. 자잘한 버그와 디자인 수정은 차차 하도록 하겠습니다.
ps. 앞서 밝혔듯이 순수 본인 제작이 아닌 까닭으로 배포까지는 양심상 못하겠습니다^^; 그리고 멋진 스킨을 만들어서 배포해주신 Daisy님과 로고와 나뭇잎을 그려준 Ludens 형고맙습니다.
적어도, 이와 똑같은 스킨이 '아마도' 없을것이라는 생각을 가진다면 말이지요.
전체적으로 연두색 계열로 가고자 했고, 파스텔 느낌을 말했더니 Ludens님이 로고와 나뭇잎 네장을 앙증맞게 그려주셨네요. 감사합니다^-^ 컨텐츠와 사이드바 너비 영역은 Daisy님의 레이아웃을 거의 그대로 사용했기 때문에 동일하구요. 일부 스타일을 제 마음대로 고쳐버렸습니다. Article 영역에 태그가 한 줄 이상으로 길어지면 하단 라인이 글자와 겹쳐지는 문제 등이 있어 고쳐놨구요.(Daisy님께도 말씀드려야 하나...) 전체적인 배색과 줄간격을 조금씩 조정했습니다.
디자이너가 아닌지라 직접 디자인도 못하고, 귀차니즘 때문에 남의 레이아웃을 가져와서 내것인양 되새김질한 스킨이긴 하지만 그래도 이 세상 단 하나뿐인 스킨이라는 것 때문에 만족하고 있습니다. 자잘한 버그와 디자인 수정은 차차 하도록 하겠습니다.
ps. 앞서 밝혔듯이 순수 본인 제작이 아닌 까닭으로 배포까지는 양심상 못하겠습니다^^; 그리고 멋진 스킨을 만들어서 배포해주신 Daisy님과 로고와 나뭇잎을 그려준 Ludens 형고맙습니다.
2008년 1월 14일 월요일
라운드박스(RoundBox) 만들기
이런말을 해도 될런지 모르겠지만 웹1.0 아니 웹디자인 1.0에 있어서 라운드박스의 공헌을 이루어 말할수 없을 정도다. 대한민국 포털 치고 라운드박스 없는 디자인 없다. 일종의 유행이자 커다란 패러다임과 같은 존재가 바로 라운드박스 디자인이다. 웹2.0의 시대가 도래했고, 스타일을 적극 도입하고자 하니 과거의 찬란했던 라운드박스가 애물단지가 되고 있다. 하지만 인간은 자고로 막힌곳은 뚫고, 가로막은 돌은 치우며 간다고, 온갖 비법과 술수를 동원하여 이 난관을 해결해냈다. 바야흐로 무림의 절대지존 라운드박스를 거스를수 없는 지경인 것이다!
잡설이 길었는데, 아래는 라운드박스를 만들수 있는 여러가지 방법중 하나가 될 것 같다. 스타일시트, 자바스크립트, DOM에 대한 짧은지식으로 과연 쓸만한가?하는 판단은 차후로 미루고 똥배짝두 먼저 내민놈이 커보인다고 무식하게 공개해 본다.
<!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">
<head>
<title>라운드박스</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Editplus" />
<style type="text/css">
body, * { margin: 0px; padding: 0px; }
.box { }
.rndBox { position: relative; }
.box01 { width: 196px; height: 100%; min-height: 196px; border: 2px solid #b0db4a; }
.box02 { width: 96px; height: 100%; min-height: 96px; border: 2px solid #b0db4a; }
.rounding { position: absolute; width: 10px; height: 10px; }
.rndLeftTop { top: -2px; left: -2px; background: url('bg_lt.gif') no-repeat 0 0; }
.rndLeftBot { bottom: -2px; left: -2px; background: url('bg_lb.gif') no-repeat 0 0; }
.rndRightTop { top: -2px; right: -2px; background: url('bg_rt.gif') no-repeat 0 0; }
.rndRightBot { bottom: -2px; right: -2px; background: url('bg_rb.gif') no-repeat 0 0; }
* html .rndLeftBot, * html .rndRightBot { bottom: -11px; }
</style>
<script type="text/javascript">
<!--
window.onload = function() {
var tmp = document.getElementsByTagName("DIV");
for(var i=0; i<tmp.length; i++)
{
divClassName = tmp[i].className;
if(divClassName)
{
divClassName2 = divClassName.split(" ");
for(var j=0; j<divClassName2.length; j++){
if(divClassName2[j] == "rndBox")
{
var lt = createRnd("rndLeftTop"); tmp[i].appendChild(lt);
var lb = createRnd("rndLeftBot"); tmp[i].appendChild(lb);
var rt = createRnd("rndRightTop"); tmp[i].appendChild(rt);
var rb = createRnd("rndRightBot"); tmp[i].appendChild(rb);
}
}
}
}
}
function createRnd(classname){
classname = "rounding " + classname;
var rnd = document.createElement("DIV");
rnd.setAttribute("class",classname);
rnd.className = classname;
return rnd;
}
//-->
</script>
</head>
<body>
<div class="rndBox box01">
<p>하코사 만세</p>
</div>
<br />
<div class="box box01">
Not Round Box 01
</div>
<br />
<div class="rndBox box02">
<p>하코사 만세</p>
</div>
<br />
<div class="box box02">
Not Round Box 02
</div>
</body>
</html>
길지 않은 소스이니 보면 이해가 번특! 일겠지만 간략 설명하면,
HTML문서에서는 박스를 만들고자 하는 DIV 앨리먼트의 외로운 독고다이만이 느껴질 뿐, 사방의 수호신 청룡, 백호, 주작, 현무의 보이지 않는다! 나는 HTML 문서를 작성할때 가급적 의미를 가지지 않는 코드를 없애야 좋은 코드가 된다! 라고 생각한다. 그래서 위처럼 의미적으로 박스임을 나타낼수 있는 최소한의 DIV 앨리먼트만을 잡아두었다.
그럼 어떻게 사방의 수호신을 모시고, 라운드를 처리하리까?
DOM이란걸 생각했다. 일단 브라우져가 HTML문서를 읽어온 뒤에 DOM을 이용해서 박스라고 정의된(box classname) DIV 앨리먼트를 찾아내서 DIV 앨리먼트 안에 앨리먼트 자체가 의미는 가지지 않지만 표현을 위해 사용될 라운드용 DIV 앨리먼트를 생성해서 집어 넣는 것이다. 위 Javascript가 그 일을 맡는다.
이렇게 하면 미리 정의된 스타일시트의 문서를 통해 사방의 라운드가 둘러지게 된다. 짜잔~~! 하고 말이다.
이 방법의 단점으로는 DOM이나 Javascript를 제대로 지원하지 않는 브라우져에서는 사용할 수 없다는 것이다. 또한, 위 소스에서는 DOM이나 Javascript 브라우져의 사용여부를 미리 체크하고 있지 않아서 바로 사용하기에는 무리가 있음을 알린다. (약간의 내공증진이 필요한 소스다) 그렇긴 하지만 이 방법은 HTML 문서 자체에 라운드 처리를 위한 불필요한 앨리먼트를 삽입하지 않는 점과 둘 이상의 라운드박스를 쉽게 처리할 수 있다는 점에 있어서 쓸만한 방법이라는 생각이 든다.
잡설이 길었는데, 아래는 라운드박스를 만들수 있는 여러가지 방법중 하나가 될 것 같다. 스타일시트, 자바스크립트, DOM에 대한 짧은지식으로 과연 쓸만한가?하는 판단은 차후로 미루고 똥배짝두 먼저 내민놈이 커보인다고 무식하게 공개해 본다.
<!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">
<head>
<title>라운드박스</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Editplus" />
<style type="text/css">
body, * { margin: 0px; padding: 0px; }
.box { }
.rndBox { position: relative; }
.box01 { width: 196px; height: 100%; min-height: 196px; border: 2px solid #b0db4a; }
.box02 { width: 96px; height: 100%; min-height: 96px; border: 2px solid #b0db4a; }
.rounding { position: absolute; width: 10px; height: 10px; }
.rndLeftTop { top: -2px; left: -2px; background: url('bg_lt.gif') no-repeat 0 0; }
.rndLeftBot { bottom: -2px; left: -2px; background: url('bg_lb.gif') no-repeat 0 0; }
.rndRightTop { top: -2px; right: -2px; background: url('bg_rt.gif') no-repeat 0 0; }
.rndRightBot { bottom: -2px; right: -2px; background: url('bg_rb.gif') no-repeat 0 0; }
* html .rndLeftBot, * html .rndRightBot { bottom: -11px; }
</style>
<script type="text/javascript">
<!--
window.onload = function() {
var tmp = document.getElementsByTagName("DIV");
for(var i=0; i<tmp.length; i++)
{
divClassName = tmp[i].className;
if(divClassName)
{
divClassName2 = divClassName.split(" ");
for(var j=0; j<divClassName2.length; j++){
if(divClassName2[j] == "rndBox")
{
var lt = createRnd("rndLeftTop"); tmp[i].appendChild(lt);
var lb = createRnd("rndLeftBot"); tmp[i].appendChild(lb);
var rt = createRnd("rndRightTop"); tmp[i].appendChild(rt);
var rb = createRnd("rndRightBot"); tmp[i].appendChild(rb);
}
}
}
}
}
function createRnd(classname){
classname = "rounding " + classname;
var rnd = document.createElement("DIV");
rnd.setAttribute("class",classname);
rnd.className = classname;
return rnd;
}
//-->
</script>
</head>
<body>
<div class="rndBox box01">
<p>하코사 만세</p>
</div>
<br />
<div class="box box01">
Not Round Box 01
</div>
<br />
<div class="rndBox box02">
<p>하코사 만세</p>
</div>
<br />
<div class="box box02">
Not Round Box 02
</div>
</body>
</html>
길지 않은 소스이니 보면 이해가 번특! 일겠지만 간략 설명하면,
HTML문서에서는 박스를 만들고자 하는 DIV 앨리먼트의 외로운 독고다이만이 느껴질 뿐, 사방의 수호신 청룡, 백호, 주작, 현무의 보이지 않는다! 나는 HTML 문서를 작성할때 가급적 의미를 가지지 않는 코드를 없애야 좋은 코드가 된다! 라고 생각한다. 그래서 위처럼 의미적으로 박스임을 나타낼수 있는 최소한의 DIV 앨리먼트만을 잡아두었다.
그럼 어떻게 사방의 수호신을 모시고, 라운드를 처리하리까?
DOM이란걸 생각했다. 일단 브라우져가 HTML문서를 읽어온 뒤에 DOM을 이용해서 박스라고 정의된(box classname) DIV 앨리먼트를 찾아내서 DIV 앨리먼트 안에 앨리먼트 자체가 의미는 가지지 않지만 표현을 위해 사용될 라운드용 DIV 앨리먼트를 생성해서 집어 넣는 것이다. 위 Javascript가 그 일을 맡는다.
이렇게 하면 미리 정의된 스타일시트의 문서를 통해 사방의 라운드가 둘러지게 된다. 짜잔~~! 하고 말이다.
이 방법의 단점으로는 DOM이나 Javascript를 제대로 지원하지 않는 브라우져에서는 사용할 수 없다는 것이다. 또한, 위 소스에서는 DOM이나 Javascript 브라우져의 사용여부를 미리 체크하고 있지 않아서 바로 사용하기에는 무리가 있음을 알린다. (약간의 내공증진이 필요한 소스다) 그렇긴 하지만 이 방법은 HTML 문서 자체에 라운드 처리를 위한 불필요한 앨리먼트를 삽입하지 않는 점과 둘 이상의 라운드박스를 쉽게 처리할 수 있다는 점에 있어서 쓸만한 방법이라는 생각이 든다.
2008년 1월 13일 일요일
PNG 포멧 용법
PNG-24 Check
CSS/JS
가장 많이 알려져 있는 방법으로 인터넷 익스플로어의 필터속성을 이용하여 png의 투명/반투명 효과를 만들어준다. 자바스크립트로 작성된 png를 투명하게 처리해주는 스크립트를 작성하고, 이를 stylesheet에서 호출하는 방식이다. 하지만 이 방법의 경우 IMG Element에서만 적용할수 있다는 단점이 있고, 투명 배경 처리를 위해서는 .bgIE6과 같이 별도의 스타일을 지정해줘야 한다.
Stylesheet
.png24 { tmp:expression(setPng24(this)); }
Javascript
function setPng24(obj)
{
obj.width = obj.height = 1;
obj.className = obj.className.replace(/\bpng24\b/i,'');
obj.style.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='"+ obj.src +"',sizingMethod='image');"
obj.src = '';
return '';
}
배경처리를 위한 추가코드
IE6에서 투명 배경을 처리하기 위해서는 아래와 같이 style문서안에 IE6을 위한 별도의 스타일을 지정하거나, HTML문서 Head Element안에 Hack을 이용한 방법으로 처리해야 한다.
방법1
.bg { width: 114px; height: 60px; background: url('img_logo.png') no-repeat 0 0; }
* html .bg { background-image : none; filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='img_logo.png',sizingMethod='scale'); }
위 방법은 .bg에서 png배경을 기본값으로 배경에 설정한 것이고, 다시 * html 핵을 사용해서 IE6에만 배경을 재설정한 것이다.
방법2
<head>
<!--[if IE]>
<style type="text/css">
.bg {
background-image : none;
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='img_logo.png',sizingMethod='scale');
}
</style>
<![endif]-->
</head>
위 방법은 스타일 문서에 정의하지 않고, HTML문서 내에 직접 작성할때 사용하는 것으로, <--[if IE]> 와 <![endif]-->를 이용한 핵을 사용한다.
HTC
Stylesheet
.iePngFix {behavior:url(iepngfix.htc);}
HTC
이 방법은 twinhelix에서 확인해볼수 있는 방법인데 이미지 앨리먼트와 배경을 동시에 처리할 수 있고, 스타일 문서에 별도의 핵을 사용하지 않아도 된다. 아울러 IE5.5 이상의 익스플로어에서 적용 가능하여, 위의 방법보다는 권장할 수 있는 방법이라고 생각됩니다. 또한, 애플등의 사이트에서도 적용하여 사용하는 것으로 보아 심각한 문제를 일으키지는 않는것으로 보입니다.(나라디자인 참조 문서 확인)
<public:component>
<public:attach event="onpropertychange" onevent="doFix()" />
<script type="text/javascript">
// IE5.5+ PNG Alpha Fix v1.0RC4
// (c) 2004-2005 Angus Turnbull http://www.twinhelix.com
// This is licensed under the CC-GNU LGPL, version 2.1 or later.
// For details, see: http://creativecommons.org/licenses/LGPL/2.1/
// This must be a path to a blank image. That's all the configuration you need.
if (typeof blankImg == 'undefined') var blankImg = 'blank.gif'; // 1x1px 짜리 투명 이미지(blank.gif)의 경로를 변경.
var f = 'DXImageTransform.Microsoft.AlphaImageLoader';
function filt(s, m)
{
if (filters[f])
{
filters[f].enabled = s ? true : false;
if (s) with (filters[f]) { src = s; sizingMethod = m }
}
else if (s) style.filter = 'progid:'+f+'(src="'+s+'",sizingMethod="'+m+'")';
}
function doFix()
{
// Assume IE7 is OK.
if (!/MSIE (5\.5|6\.)/.test(navigator.userAgent) ||
(event && !/(background|src)/.test(event.propertyName))) return;
var bgImg = currentStyle.backgroundImage || style.backgroundImage;
if (tagName == 'IMG')
{
if ((/\.png$/i).test(src))
{
if (currentStyle.width == 'auto' && currentStyle.height == 'auto')
style.width = offsetWidth + 'px';
filt(src, 'scale');
// 'scale' 을 'image' 으로 변경하면 padding 적용시 나타나는 이미지 크기의 변화(잘못된 렌더링)를 방지할 수 있다. 하지만 border 표현에 문제가 생긴다.
src = blankImg;
}
else if (src.indexOf(blankImg) < 0) filt();
}
else if (bgImg && bgImg != 'none')
{
if (bgImg.match(/^url[("']+(.*\.png)[)"']+$/i))
{
var s = RegExp.$1;
if (currentStyle.width == 'auto' && currentStyle.height == 'auto')
style.width = offsetWidth + 'px';
style.backgroundImage = 'none';
filt(s, 'crop');
// IE link fix.
for (var n = 0; n < childNodes.length; n++)
if (childNodes[n].style) childNodes[n].style.position = 'relative';
}
else filt();
}
}
doFix();
</script>
</public:component>
참고링크
본 내용은 이미 인터넷에 여러번 올라온 내용을 재탕하고자 한 것은 아니고, 제가 참여하는 스터디모임에서 사용할 목적으로 작성된 것입니다. png의 개념과 HTC사용과 관련한 문제와 설명은 아래 나라디자인에서 한번더 확인해보시면 좋을것 같습니다.
CSS/JS
가장 많이 알려져 있는 방법으로 인터넷 익스플로어의 필터속성을 이용하여 png의 투명/반투명 효과를 만들어준다. 자바스크립트로 작성된 png를 투명하게 처리해주는 스크립트를 작성하고, 이를 stylesheet에서 호출하는 방식이다. 하지만 이 방법의 경우 IMG Element에서만 적용할수 있다는 단점이 있고, 투명 배경 처리를 위해서는 .bgIE6과 같이 별도의 스타일을 지정해줘야 한다.
Stylesheet
.png24 { tmp:expression(setPng24(this)); }
Javascript
function setPng24(obj)
{
obj.width = obj.height = 1;
obj.className = obj.className.replace(/\bpng24\b/i,'');
obj.style.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='"+ obj.src +"',sizingMethod='image');"
obj.src = '';
return '';
}
배경처리를 위한 추가코드
IE6에서 투명 배경을 처리하기 위해서는 아래와 같이 style문서안에 IE6을 위한 별도의 스타일을 지정하거나, HTML문서 Head Element안에 Hack을 이용한 방법으로 처리해야 한다.
방법1
.bg { width: 114px; height: 60px; background: url('img_logo.png') no-repeat 0 0; }
* html .bg { background-image : none; filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='img_logo.png',sizingMethod='scale'); }
위 방법은 .bg에서 png배경을 기본값으로 배경에 설정한 것이고, 다시 * html 핵을 사용해서 IE6에만 배경을 재설정한 것이다.
방법2
<head>
<!--[if IE]>
<style type="text/css">
.bg {
background-image : none;
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='img_logo.png',sizingMethod='scale');
}
</style>
<![endif]-->
</head>
위 방법은 스타일 문서에 정의하지 않고, HTML문서 내에 직접 작성할때 사용하는 것으로, <--[if IE]> 와 <![endif]-->를 이용한 핵을 사용한다.
HTC
Stylesheet
.iePngFix {behavior:url(iepngfix.htc);}
HTC
이 방법은 twinhelix에서 확인해볼수 있는 방법인데 이미지 앨리먼트와 배경을 동시에 처리할 수 있고, 스타일 문서에 별도의 핵을 사용하지 않아도 된다. 아울러 IE5.5 이상의 익스플로어에서 적용 가능하여, 위의 방법보다는 권장할 수 있는 방법이라고 생각됩니다. 또한, 애플등의 사이트에서도 적용하여 사용하는 것으로 보아 심각한 문제를 일으키지는 않는것으로 보입니다.(나라디자인 참조 문서 확인)
<public:component>
<public:attach event="onpropertychange" onevent="doFix()" />
<script type="text/javascript">
// IE5.5+ PNG Alpha Fix v1.0RC4
// (c) 2004-2005 Angus Turnbull http://www.twinhelix.com
// This is licensed under the CC-GNU LGPL, version 2.1 or later.
// For details, see: http://creativecommons.org/licenses/LGPL/2.1/
// This must be a path to a blank image. That's all the configuration you need.
if (typeof blankImg == 'undefined') var blankImg = 'blank.gif'; // 1x1px 짜리 투명 이미지(blank.gif)의 경로를 변경.
var f = 'DXImageTransform.Microsoft.AlphaImageLoader';
function filt(s, m)
{
if (filters[f])
{
filters[f].enabled = s ? true : false;
if (s) with (filters[f]) { src = s; sizingMethod = m }
}
else if (s) style.filter = 'progid:'+f+'(src="'+s+'",sizingMethod="'+m+'")';
}
function doFix()
{
// Assume IE7 is OK.
if (!/MSIE (5\.5|6\.)/.test(navigator.userAgent) ||
(event && !/(background|src)/.test(event.propertyName))) return;
var bgImg = currentStyle.backgroundImage || style.backgroundImage;
if (tagName == 'IMG')
{
if ((/\.png$/i).test(src))
{
if (currentStyle.width == 'auto' && currentStyle.height == 'auto')
style.width = offsetWidth + 'px';
filt(src, 'scale');
// 'scale' 을 'image' 으로 변경하면 padding 적용시 나타나는 이미지 크기의 변화(잘못된 렌더링)를 방지할 수 있다. 하지만 border 표현에 문제가 생긴다.
src = blankImg;
}
else if (src.indexOf(blankImg) < 0) filt();
}
else if (bgImg && bgImg != 'none')
{
if (bgImg.match(/^url[("']+(.*\.png)[)"']+$/i))
{
var s = RegExp.$1;
if (currentStyle.width == 'auto' && currentStyle.height == 'auto')
style.width = offsetWidth + 'px';
style.backgroundImage = 'none';
filt(s, 'crop');
// IE link fix.
for (var n = 0; n < childNodes.length; n++)
if (childNodes[n].style) childNodes[n].style.position = 'relative';
}
else filt();
}
}
doFix();
</script>
</public:component>
참고링크
본 내용은 이미 인터넷에 여러번 올라온 내용을 재탕하고자 한 것은 아니고, 제가 참여하는 스터디모임에서 사용할 목적으로 작성된 것입니다. png의 개념과 HTC사용과 관련한 문제와 설명은 아래 나라디자인에서 한번더 확인해보시면 좋을것 같습니다.
2008년 1월 2일 수요일
전차남과 미투데이 그리고 하이퍼텍스트문학
일본에서 책과 영화, 다시 드라마로 만들어지며 큰 인기를 끌고 있는 '전차남'이라는 이야기가 있다. 전형적인 오타쿠에 소심하기 짝이 없는 남자가 전차에서 곤경에 처한 지적이고 아름다운 여자를 구하게 되면서 만남이 시작되고, 인터넷 게시판을 통해 서툰 자신의 사랑과 연애를 극복해가는 과정을 코믹하면서도 솔직하게 그려낸 작품이다.
작품 자체의 소재나 전개는 사실 과거의 플롯에서 크게 벗어나지는 않는다. 하지만 이 이야기가 인기를 끌고, 내가 관심을 가진것은 인터넷이라는 매체가 가져다주는 스토리텔링의 변화다. 전차남은 여자를 만난 순간부터 여자로부터 사랑을 확인받는 마지막 순간까지 인터넷 게시판에 자신의 심정을 토로하고, 질문을 하고 도움을 받는다. 하나의 글이 흔히 댓글이라고 부르는 형태의 파생글로 확대되고, 재생산되는 모습을 띄고 있는데 이러한 과정이 결국은 '전차남'이라는 영화 전체를 관통하는 스토리 라인이 되어 버린다. 우리는 잘 만들어진 책이나 영화, 드라마로 이 장면을 바라보았지만 사실은 게시판 속 글을 읽고 있었다고 생각할 수 있다.
이점은 우리가 의식하지 못하고 있지만, 여기 블로그와 같은 개인매체속의 포스트와 미니홈피의 사진, 미투데이나 플레이톡의 댓긋 커뮤니티 속에서 문학적인 이야기가 만들어질수 있음을 보여주고 있는 것이다. 이는 과거에 PC통신 시절 유행하던 릴레이소설과는 다르다. 릴레이소설은 이미 '릴레이'라는 틀이 제한되어 있으나, 현재의 웹은 게시판이든 미투든 블로그든 그 영역의 제한이 조건지어지지 않는다. 그것들은 서로 링크로 물려 있으며, 사진과 음악, 동영상을 흡수한다. 그리고 제3자의 개입(댓글)은 개인의 단순한 일상에 반전을 가져다 주거나 이야기의 증폭을 유도한다. 댓글은 또 다른 댓글을 야기하며, 확장된 댓글은 하나의 스토리로 커간다. 하나의 스토리는 또 다른 글, 포스트, 댓글, 사진, 음악, 동영상과 링크되며 다시 확장된다. 이런 과정은 무한하며 반복적이다. 시작과 끝이 없으며 소설의 고전적 플롯을 해체한다. 비롯하여 하이퍼텍스트의 자연발생적인 현상으로도 볼 수 있지 않을까 생각한다. 최근 몇년동안 연구되어온 하이퍼텍스트문학이 외국에 비해 국내에서는 그다지 주목받지도 못하고 깊이있게 연구되지도 못하였는데, 웹의 발전속에 더욱더 개인화된 웹서비스와 글쓰기 형태는 의도하지 않은 방향으로 하이퍼텍스트문학의 태동을 일굴어낼지 모른다는 생각이 들게 만든다.
작품 자체의 소재나 전개는 사실 과거의 플롯에서 크게 벗어나지는 않는다. 하지만 이 이야기가 인기를 끌고, 내가 관심을 가진것은 인터넷이라는 매체가 가져다주는 스토리텔링의 변화다. 전차남은 여자를 만난 순간부터 여자로부터 사랑을 확인받는 마지막 순간까지 인터넷 게시판에 자신의 심정을 토로하고, 질문을 하고 도움을 받는다. 하나의 글이 흔히 댓글이라고 부르는 형태의 파생글로 확대되고, 재생산되는 모습을 띄고 있는데 이러한 과정이 결국은 '전차남'이라는 영화 전체를 관통하는 스토리 라인이 되어 버린다. 우리는 잘 만들어진 책이나 영화, 드라마로 이 장면을 바라보았지만 사실은 게시판 속 글을 읽고 있었다고 생각할 수 있다.
이점은 우리가 의식하지 못하고 있지만, 여기 블로그와 같은 개인매체속의 포스트와 미니홈피의 사진, 미투데이나 플레이톡의 댓긋 커뮤니티 속에서 문학적인 이야기가 만들어질수 있음을 보여주고 있는 것이다. 이는 과거에 PC통신 시절 유행하던 릴레이소설과는 다르다. 릴레이소설은 이미 '릴레이'라는 틀이 제한되어 있으나, 현재의 웹은 게시판이든 미투든 블로그든 그 영역의 제한이 조건지어지지 않는다. 그것들은 서로 링크로 물려 있으며, 사진과 음악, 동영상을 흡수한다. 그리고 제3자의 개입(댓글)은 개인의 단순한 일상에 반전을 가져다 주거나 이야기의 증폭을 유도한다. 댓글은 또 다른 댓글을 야기하며, 확장된 댓글은 하나의 스토리로 커간다. 하나의 스토리는 또 다른 글, 포스트, 댓글, 사진, 음악, 동영상과 링크되며 다시 확장된다. 이런 과정은 무한하며 반복적이다. 시작과 끝이 없으며 소설의 고전적 플롯을 해체한다. 비롯하여 하이퍼텍스트의 자연발생적인 현상으로도 볼 수 있지 않을까 생각한다. 최근 몇년동안 연구되어온 하이퍼텍스트문학이 외국에 비해 국내에서는 그다지 주목받지도 못하고 깊이있게 연구되지도 못하였는데, 웹의 발전속에 더욱더 개인화된 웹서비스와 글쓰기 형태는 의도하지 않은 방향으로 하이퍼텍스트문학의 태동을 일굴어낼지 모른다는 생각이 들게 만든다.
2008년 1월 1일 화요일
12월 31일 청계천 루미나리에
2007년 마지막 날. 영하의 날씨 속에도 종로와 시청앞은 사람들로 붐볐다.
지난 한 해를 보내기 위한 사람들과 새로운 한 해를 맞으려는 사람들의 소란스러움으로 그렇게 거리는 따듯했다.
곳곳에 설치된 성탄 트리와 빛으로 반짝이는 루미나리에는 참 아름답다.
하지만 사람냄새가 없는 풍경을 상상해 봤는가?
겨울밤이 춥고 황량하다지만 그럼에도 아름다울수 있는건 빛을 찾아 나온 사람들이 있기 때문이다.
지난 한 해를 보내기 위한 사람들과 새로운 한 해를 맞으려는 사람들의 소란스러움으로 그렇게 거리는 따듯했다.
곳곳에 설치된 성탄 트리와 빛으로 반짝이는 루미나리에는 참 아름답다.
하지만 사람냄새가 없는 풍경을 상상해 봤는가?
겨울밤이 춥고 황량하다지만 그럼에도 아름다울수 있는건 빛을 찾아 나온 사람들이 있기 때문이다.
피드 구독하기:
글 (Atom)