Feed on
Posts
Comments

앗! 저는 alt 입니다. ie에서만 보이죠

html, css좀 다룹니다.. 라고 하면 alt 속성 모르는 사람 있을까? 아마.. 없을 거다
시간이 꾀 지났지만 웹 표준이란 말이 나오면서 접근성과 함께 세트 메뉴처럼 딸려 나오는 건 항상 alt 속성으로 대체텍스트만 잘 지켜도 50점은 먹고 들어가는 거라고 할 정도로 언급을 했으니 말이다.

그렇다면 일반적인 사용자가 이런 것 들을 알 고 있을까?
모르긴 몰라도 아마 대부분의 사용자들이 이런 속성 따위에는 관심이 없을 거라 생각한다.
그저 본인이 이용하는 환경에서 잘 보이고 이용할 수 있게만 하면 만족할 데니 말이다..
문제는 여기에서 오는 것 이다.

이 글은 사용자의 입장이 아니라 제작자의 입장에서 생각한 내용이다.
alt는 어떤 속성일까? w3c에서는 alt속성에 대해 대상(이미지나 input, applet등)의 요소의 의미나 내용을 텍스트로도 제공할 수 있도록 할 때 쓰인다고 말하고 있다.
이렇게 alt속성을 제공 했을 때의 이점이라고 한다면 요즘과 같이 다양한 플렛폼에서 웹 페이지에 접근을 하더라도 최소한의 동등한 정보를 제공 할 수 있는 방법을 제공할 수 있다는 점과 검색봇이 컨텐츠를 검색 함에 있어도 도움을 줄 수 있다고 말하고 있다.
(물론 이 말은 반은 맞고 반은 이론상 그렇지만 그렇다고 100% 믿어도 나쁠 건 없겠지?)
여하튼 이런 의미와 기능을 가진 alt속성을 기획,개발,디자인에 까지는 바리지 않지만 클라이언트 사이드개발 쪽 사람이라면 제대로 알고 사용을 해야 하지 않겠는가?

작년부터 IE8 beta 씨리즈가 릴리즈 되면서 관련 업무를 진행 하고 있고, 주로 IE8에서 표현되지 못하는 버그나 오류를 테스트 하고 있는데 이런 문의가 온 적이 있다.

“IE8 에서 ooo 부분에 툴팁이 나오지 않고 있습니다. 수정해주세요…”

이미 IE8을 사용해 본 사람들이라면 대부분 다 알겠지만 IE8 부터는(정확히는 브라우저 모드가 IE8 standard mode 여야 한다) alt속성이 더 이상 시스템 툴팁으로 표시되지 않게 되었다.
(그전 까지 IE에서 생각하는 alt는 title속성과 동등하게 title요소가 없을 경우 대신 나타나는 속성정도로 인식되었으니..)
아마도 IE8이 엄격한 표준규칙을 지키려 노력한 브라우저인 만큼 이런 부분까지도 다른 브라우저들과 동등한 기능으로 바꾸려 했을거라 짐작된다.
그럼에도 불구하고 아직까지 10년 15년 전 브라우저를 못 잊은 사용자들의 낡은 습관 때문에 예전과 동일하고 손도 까딱 안 한 코드를 어떻게든 사용자의 입맛을 맞춰서 다시 바꿔줘야 한다고 하면 어떻게 설득 시켜줘야 할까..?
물론 title 속성을 이용해(이건 꼼수도 아닌 그냥 편법이다!) 툴팁이 나타나게 할 수도 있다.
하지만 title 속성의 사용이 alt 를 대체 하기 위한 코드는 아닌데 마냥 아쉽기만 하다.

일모리님 블로그에서는 alt와 title에 대해 정리가 잘 되어 있다.

IE8 신규기능

올초 3월부터 시작된 IE8 beta1과 8월에 beta2, 9월 한국화버전까지 MS의 Internet Explorer(IE)도 버전업그레이드와 브라우저 변화에 노력중이다.
변화의 대표적인 예로 크로스브라우징을 맞춰야 하던 분들이 골머리를 앓고 있던 IE만의 렌더링 방식인 haslayout지원을 IE8에서는 더이상 적용되지 않도록 버리고 표준모드와 Quirks mode의 렌더링이 제작자의 의도와 맞도록 맞추고 있고, Firebug와 같은 디버그 툴의 사용 용도가 높아서 인지 IE8에서는 기본으로 기존에 개발자도구(Developer Toolbar)를 탑제해서 설치되고 있다.
이외 브라우저 충돌시 자동으로 복구를 해주는 기능이 있는데 개인적으로 이 기능은 좋은 인상을 주지 못하고 있는것 같다. 다음과 같은 상황이 있다면 말이다.. 예를들어 사이트에 들어가자마자 충돌이 나는 사이트가 있다면 브라우저를 자동으로 복하기 때문에 브라우저가 복구 된다고 한들 또 오류가 나고 또 복구 하고…. 무한으로 반복하기에 결국 브라우저를 종료시키지 않고서는 상황이 끝나지 않을것 같기 때문이다.
좋고나쁨을 아직까지 정확히 판단하기는 어렵지만 beta인 만큼 여러 시도로 다양한 기능과 개선사항을 보여주고 있는것 만은 사실이기에 기대가 되기도 한다.

신규기능
최근 브라우저들은 속도개선을 주로 내세우며 사용자들이 보다 더 빠르게 브라우저를 이용할 수 있는 것에 집중을 하고 있다.
IE브라우저는 웹표준도 웹표준이지만 이런 면에서도 유난히 좋은 인상을 주지 않는 것이 사실이지만 사용자의 이용율을 무시할 수는 없는 거의 절대적인 비율이기 때문에 이런 추가되는 기술이나 신규기능에 대해서 민감하지 않을 수는 없다.
IE8에서 내가 관심있는 신규기능은 Accelerator, Webslices이며, 두 신규 기능에 대한 간단한 설명과 현재 서비스에서 적용시 고민해 봐야할 문제에 대해 이야기 해보려 한다.
참고로 추가되는 새로운 기능이나 기술은 IE8 백서에서 더 자세히 찾아볼 수 있다.

Accelerator
Accelerator(액셀러레이터)는 beta1에서 Activity로 소개되었던 기능에서 이름이 변경된 것이다.
정보를 하나의 서비스로만 이용하지 않고 서비스 제공자가 규격화 된 xml코드를 이용해서 제공해 놓은 다양한 서비스들로 다르게 접할 수 있도록해주는 기능이다.
쉽게 이야기해 정보서비스를 이용함에 있어 사용자가 다양한 서비스를 끊김없이 이용할 수 있도록 제공해 주는 기능이다.

Accelerator 데모화면

예를 들자면..
기존에는 현재 보고 있는 웹페이지에서 다른 관련된 정보나 서비스를 이용하기 위해서 관련 키워드나 웹사이트 주소를 복사하거나 외워서 브라우저 주소창에 치거나 검색폼에 작성후 검색하고 원하는 서비스 페이지로 이동하는 방식이였다.
하지만 액셀러레이터 기능을 이용한다면 이런 절차를 줄여줄 수 있다. 액셀러레이터는 현재 페이지에서 관련 키워드나 페이지 그 자체를 자신의 브라우저에 추가된 액셀러레이터를 이용해서 바로 이용할 수 있도록 하고있기 때문이다.
위에서 이야기 했던것 처럼 사용자가 정보를 이용함에 있어 불필요한 절차를 조금이라도 줄여줄 수 있도록 해 주는 기능이라 할 수 있지만 이 기능에도 약간에 문제가 있다.
하나는 해당 서비스를 제공하기 위해 서비스 제공자는 서비스 페이지 어딘가에는 액셀러레이터를 설치할 수 있는 링크를 제공해야 한다. 한번은 설치를 해야 한다는 것이다.
다른 하나는 마우스 오른쪽 클릭이 제한된 곳이나 드래그로 컨텐츠의 하이라이트가 제한된 곳에서는 제한을 풀어야 할지 말아야 할지에 대한 고민이 생기게 된다는 것이다.
액셀러레이터는 키워드를 드래그 했을때 액셀러레이터 버튼이 활성화 되거나 마우스 오른쪽 버튼을 이용해서 사용하거나 브라우저 상단 페이지 메뉴에서 이용할 수 있게 되어 있다. 일반 적으로 가장 편한 방식이 키워드를 드래그 후 나타나는 메뉴를 이용해서 사용하는 것이 가장 좋겠지만 어떠한 이유에 의해 이런 기능을 막아놓은 사이트라면 액셀러레이터를 위해서 풀지 고민이 생기게 될 것이다.
액셀러레이터는 검색,사전,지도,메일 등 카테고리의 구분만 명확하다면 다양한 서비스와 연동을 할 수 있기에 그 매력이 상당히 높아 보이지만 위의 사항에 문제가 생긴다면 쉽지 않은 고민이 생길거라고 생각된다.

Webslices
Webslices(웹슬라이스)는 MacOS의 Webclip widget과 똑같다는 생각이 들었다.

Webslices 데모화면

hAtom 마이크로포맷 기술을 이용해서 서비스 제공자가 사용자에게 이용하고 싶은 콘텐츠만 쉽게 전달할 수 있도록 해주는 기능으로 사용자 입장에서는 즐겨찾기와 유사하게 취급되나 RSS의기능과 같이 정보갱신을 인식해 항상 최신정보를 유지하며 정보를 이용할 수 있게 해주며 정보제공자는 기존 마크업을 이용해서 제공할 수도 있다는 장점이 있다.
단순히 html만을 이용해서 제공할 수 있기 때문에 편리하지만 웹슬라이스 역시 고민해야할 점이 없는것은 아니다.
첫째로 기존 html 구조가 웹슬라이스를 제공하기위해 적합하지 않은 구조라면 웹슬라이스를 구현하기 위한 최소한의 골격을 마춰야 하는 단점이 있다.
두번째 문제는 사이트를 접속하지 않고 원하는 정보만 볼 수 있다는 장점은 사이트 접속으로 인한 수익(광고나 연동되는 기타서비스)을 추구하던 서비스에서는 그리 적합하지 않은 기능이기 때문이다.
때문에 ebay와 같은 상품의 꾸준한 정보갱신을 원하는 사용자가 많은 서비스라면 꾀나 적합한 기능이라 생각되지만 다양한 정보를 한곳에 다 표현하고 있어 정말 필요할것만 같은 한국의 포털메인 사이트와 같은 곳에서도 과연 좋은 기능일지 고민해봐야 하지 않을까 생각된다.

끝으로
Accelerator와 Webslices가 매우 매력적인 기능인건 분명하다.
beta지만 벌써부터 대응하고 있는 사이트도 생기고 있고.. 이런 현상은 IE가 단순히 사용율이 높기 때문만은 아닐 것이다.(정말 이런 기능이 필요했던 사이트도 있을 것이고…)
지금은 접목하기 힘든 서비스라도 기존 서비스를 잘 연구한다면 좋은 방향으로 사용할 수 있지 않을까 생각된다.
참고로 ebayAuction에서는 벌써 대응을 하고 있는중이고 꾀 잘 사용하고 있다고 보인다.

IE8 신규기능 개발가이드

점심을 먹고와서 우연히 CDK의 질문글을 보다가 나도 궁금해져서 실험을 해봤다.

실험인즉, 브라우저별로 border의 변화가 다를까? 라는 의문을 두고 실험을 했는데 예상처럼 모든브라우져가 조금씩 차이가 있었다.

총 8px의 굵기인 border 를 border-right 부분만 1px씩 줄여나가면서 변화를 지켜봤는데 변화과정이나 결과가 참 묘하군..

FireFox 2.0

8 By 8 FF border 8 by 8
8 By 7 FF border 8 by 7
8 By 6 FF border 8 by 6
8 By 5 FF border 8 by 5
8 By 4 FF border 8 by 4
8 By 3 FF border 8 by 3
8 By 2 FF border 8 by 2
8 By 1 FF border 8 by 1

IE6.0

8 By 8 IE border 8 by 8
8 By 7 IE border 8 by 7
8 By 6 IE border 8 by 6
8 By 5 IE border 8 by 5
8 By 4 IE border 8 by 4
8 By 3 IE border 8 by 3
8 By 2 IE border 8 by 2
8 By 1 IE border 8 by 1

Opera 9

8 By 8 Op border 8 by 8
8 By 7 Op border 8 by 7
8 By 6 Op border 8 by 6
8 By 5 Op border 8 by 5
8 By 4 Op border 8 by 4
8 By 3 Op border 8 by 3
8 By 2 Op border 8 by 2
8 By 1 Op border 8 by 1

DTD에 따라 달라질꺼라 생각되진 않고.. Opera브라우저가 Acid2 Test를 통과했으니 Opera의 랜더링 방식이 옳은걸지도 모르지만 모든 브라우저에서 동일하게 보이는 방법으로 우회해서 해야되지 않을까 싶네..

크로스 브라우징을 추구하면서 퍼팩트픽셀을 요구하는 사람들에게는 border의 표현 방식을 신중히 고려해서 작업해야하지 않을까 생각된다.

지난주 금요일(3월16일)에 “글로벌 웹 기술 워크샵” 이라는 주제로 워크샵이 있었다.

처음 이 워크샵을 신청할때는 내 관심과는 좀 다른 내용으로 진행되는줄 알았지만 행사장엘 가서야 가장 궁금했으며 관심을 가졌던 부분들에 대해 발표했었다.

현재 가장 많이 알려진 브라우저 제조사(?)에서 나와서 발표를 했으며 각 대표로 나오신 윤석찬님(Firefox), 김국현님(Internet Explorer), 왕수용님(Safari), 조만용(Opera)님 외 준비하신 모든분들이 수고해주셨다.

다음날 지방으로 결혼식을 다녀오고 업무가 바쁘다는 핑계로 후기가 좀 늦은감이 있는듯하다… 빨리 놋북이나 맥북을 빨리 휴대해야 할 터인데 ㅠ_ㅠ