Unmatched Style 에서 콘테스트를 열고 있습니다. Fireworks 파일 혹은 Photoshop 파일을 받으시고 바른 마크업으로 사이트 제작을 하시면 됩니다. 11월3일 마감인데 영어가 되시면 곧바로 Contest 사이트로 가시고 시원하게 한국말로 번역해 놓으신 토비님의 글을 참고하세요.

ps. 호랑이 담배 말던 시절 CSS Design Korea 에서 열었던 웹표준 경진대회 생각이 나네요

돌아오면서 작년에 거의 끝내놓고 설치하지 않았던 테마를 좀더 손보고 입혀놓으니 먼가 새 기분이 난다. 아주 오래간 바뀌지 않을듯 싶다.

서론이 길었다. 아시다시피 브라우저 전쟁은 아직도 계속되고 있다. 새기술, 새 플랫폼, 새 os 등은 꾸준히 브라우저 전쟁에 불을 지피고 있다. Sitepoint가 언급했듯이 9월은 정말 브라우저 벤더들에게는 바쁜 한달이었을 것이다. 불여우 7, 크룸 14, IE10 플랫폼 프리뷰 버전을 내놓은 한달이지만 브라우저 점유율의 변화는 상대적으로 조용했다고나 할까..

전 세계적으로는 IE가 꾸준한 하락세를 보이지만서도 IE9의 사용도는 꾸준히 상승하고 있다. IE전체적으로는 하락세가 점점 평행선을 향해가는 상황이니 곧 변환의 시점이 올듯 하기도 하다. IE점유율이 상승세를 타는 그런것… 말이다…

흥미로운건 그 어느 브라우저보다도 큰 하락폭을 보인건 파이어폭스 브라우저 부분인데 이대로 가다가는 꾸준한 상승세를 타고있는 크롬에게 올해안에 자리를 양보해야할지도 모르는 상황이 올지 모르겠다. 예상은 올해 12월이라지만 지켜볼만 한 부분이다.

여기서 한국의 상황을 잠깐 보겠다.
올해 1월부터의 데이터이다. 윈도우7의 보급과 함께 IE8 이 빠르게 자리를 잡은 상황에서 5월을 기점으로 하락세를 보이면서 IE9 가 매달 거의 1%씩 성장하고 있다. 9월엔 시장점유율을 8.5%까지 끌어 올렸다. 반대로 IE6은 올해 1월부터 8.5%가 하락하면서 현재 23.35% 점유율을 보인다.

브라우저 별로 보면 한국은 이미 크롬이 파이어폭스를 제친 상태다. 파이어폭스보다는 2배정도의 점유율로 6% 시장점유율인데, 반IE운동처럼 파이어폭스 사용이 퍼져나갔던 것을 생각하면 크롬의 시장 점유율은 놀랍다.

한국에서 IE 의 점유율이 하락하고 있긴 하지만 위에서 보았던 전세계적 브라우저 점유율과 비교할때 파란선과 그 외의 선 간격이 참 넓다고 다들 느끼셨을것이다. 저번 포스팅에서 언급했지만 Windows XP 가 팔리기 시작한때가 정확히 10년전 2001년 10월인것을 생각하면 그 오래간 달려온 IE6가 참 많은 영향을 주었겠다는 생각도 들고 물론 아직도 20%의 점유율을 보이는 힘을 보여주고 있으니 아직 왠만한 비IE 브라우저 점유율 보다 높다.

지금은 브라우저가 어디로 가고 있나? 모바일은 전 세계적으로는 오페라 미니/모바일이 22% 를 보이며 기염을 토하고 있는데 스티브잡스의 일과 함께 애플(아이폰, 아이패드)의 향방도 흥미로울것이고 크롬북을 푸쉬하는 구글을 지켜보는것, 윈도우8과 IE10을 들여다 보는것도 흥미로울것이다.

오랜 시간이 지난거 같은데도 브라우저 시장은 후끈하다.

마지막으로 IE10 PP2 데모영상이다.

그 가운데 구글이 validation을 자신들의 페이지 코드들의 건강상태를 측정하는 용도로 사용한다는 글을 통해 이제 나에게 있어서의 validation 은 무엇인가를 생각해 보게하는 글이라 번역해봤다.

Validation(검증): 코드의 질을 측정하고 추적하기.

구글 웹마스터 팀은 Job site이나 개인정보관리 페이지 같은 구글의 여러 정보 사이트를 담당한다. 수만개의 페이지들을 관리하며 새 구글 사이트를 공개하는것은 단순한 열정으로는 부족하다. 질높은 관리(management)가 필요하다.

이 글에서 웹사이트를 분석하는 여러 테스트에 대하여 이야기 하지는 않을것이다. 오히려 HTML, CSS 검증 (validation, w3c에서 제공하는 검증을 말함) 과 질적인 부분을 시간이 흐름에 따라 변화되는 모습을 볼 것이다.

왜 검증(validation) 이 중요한가? 검증에 대한 여러 견해들이 있다. 구글에서도 여러 다른 접근방식과 우선순위들이 있지만 우리 웹마스터 팀은 validation을 기본적인 질좋은 속성이라고 생각한다. 접근성이나 성능이나 보존성을 보장해주는것은 아니지만 수많은 이슈들을 사전에 알려주며 바른 기술 사용법을 측정해 준다.

이러한 검증 부분에 많은 신경을 쓰는 동시에 우리가 만든 페이지가 질적인 부분에서 얼만큼 잘 하고 있는지를 측정하는 시스탬을 개발하였다. 이러한 방식이다. 각 페이지당 10점 만점을 기준으로 측정하여 0점은 최하 (HTML과 CSS 검증에서 10개 이상의 에러가 나온 경우 이겠다) 이고 10점 (0 개의 에러) 이 최고로 정하였다. 우리는 약 2년전 전부터 처음엔 샘플링으로 시작하여 지금은 모든 페이지를 감독하고 있다.

처음 시작때부터 검증 스코어를 계산하고 기록하며 현재 어떻게 하고 있는지 앞으로는 어떤 방향으로 나아가야 하는지를 보고자 했다. 결과가 향상되고 있는가 아니면 그 반대인가를 말이다.

기록을 보여주는 도표이다.

웹마스터팀은 평균적으로 약 3개 정도의 validation 이슈를 보여주며 이는 약 4개정도의 이슈가 났던 2년전 보다는 향상되었다.

이 정보는 우리에게 상당한 중요성을 갖는데 완벽히 검증된 코드를 전달하자는 우리의 목표에 얼마나 도달 했는가를 보여주며 우리가 바른 방향으로 가고 있는지를 알려준다. 보시다시피 2009년의 2분기와 2010의 첫분기를 제외하고는 긍정적인 트랜드로 향하고 있다.

알아두어야 할 것은 데이터의 정직성 integrity of the data 의 이슈들이 있다는 것이다. 예를들어 셈플의 크기라던지 “부정확한 통과” 등등이 있을 수 있다. W3C와 우리는 이러한 부분들 개선해가기 위해 함께 노력하고 있지만 소프트웨어가 완벽할수 없듯이 이슈가 안되는 것들이 에러가 나는 경우들도 있다. 최근 고쳐진 border-radius 같은 것들 말이다. 이런것들이 validation 스코어에 좋지 않게 반영되는 부분들이 있지만 아직은 어느 정도인지 측정할 만한 데이터는 없다.

비록 질적인 제어를 위해 validation 이상의 것들을 검사하지만 validation 자체가 구글 정보 사이트들의 건강을 측정하는 용도로써의 갖는 중요성은 이루 말할 수 없다.

여러분들은 validation 을 개발의 어느부분에서 어떻게 사용하고 있는가?

이제 겨우 베타출시. 물론 그전 테스팅버전들 보통 알파버전이라고 부르는 IE의 플랫폼프리뷰 버전들도 여기저기 buzz 가 있었지만 나름 IE9 베타는 오랜만에 크게 풍파를 일으키는듯 합니다. (여기에 캬~ 넣어주기)

아마도 아주 오랜만에 IE가 IE다워지는 버전을 출시하는 것 부터해서 뜨거워질대로 뜨거워진 HTML5의 열풍을 ‘나름’ 만족시켜줄만한 버전에다가 언제나 ‘표준’의 적이라고 불려지던 IE의 첫 ‘표준’ 선두주자 (나름) 로 부상된 IE이기 때문인거 같네요. :)

지난 IE 플랫폼 프리뷰 마지막 버전에서 어떤 ‘표준’의 이야기를 종식했다면 이번 IE9 베타버전에서는 인터넷 사용의 전반적인 개선을 강조하는듯 합니다.

IE 베타 출시 이전 막바지의 글 “User Experiences: Site-Centric Browsing on Windows” 유저 사용경험 : 윈도우 OS에서의 사이트 중심의 브라우징 과 “Putting sites at the center of the browsing experience, using the whole PC: IE9 Beta Available for Download” 컴퓨터의 모든것을 동원하여 사이트를 중심으로한 브라우징 경험을 하도록하기 를 보면 대충 알수 있습니다.

OS 를 사용하여 인터넷 브라우징의 극대화를 보겠다는 시도인데 참신하고 보기 좋습니다. 그리고 그게 맞고요.

태스크바에 직접 넣어버리기.

마치 패북 플러그인을 깐것처럼 웹사이트를 os자체에서 지원하기

사이트의 색상을 브라우저에서 adapt 적응해버리기

애플의 사파리 사용을 보면 전반적인 OS 의 특정 기능을 살린 브라우저 극대화라면(브라우저 뿐만이 아닌 프로그램들이 OS의 이득을보죠) 이번 IE베타는 OS자체가 반응하는 브라우저 극대화가 아닐지.

그러고 보니 지난번 IE7,8 소개한다고 오픈했던 사이트보다는 이번 사이트가 98배 정도 나은듯합니다. ;)

“IE9 베타 다운로드” 브라우징의 앞날은 아직도 넓게넓게 열려있는 광대한 대륙. 모두 달려요.

IE팀의 짱 Hachamovitch가 말하는 ie.. 대충의 사용은 볼수 있습니다

그외 IE9 글들

• 익스플로러가 크롬 만큼 빨라졌는데: IE9 써봤더니
• IE9, 복사니 밴치마크니?
• 인터넷 익스플로러 9 베타 다운로드 링크
• IE9 베타 출시를 축하하며

참고로 longdesc 속성은 long description ‘긴 설명’을 줄인 말로 이미지에 대체 텍스트 ALT 와 함께 쓰이는 속성입니다. 보통 외부 html과 연결이 되곤 하는데요.
<img src=”graph.gif” alt=”graph image” longdesc=”graphdescription.html” />
이렇게 사용하면서 alt 이상의 이미지에 대한 표현을 할수 있는 대체적인 방법입니다. 접근성을 높이는 용도이지만 실제적으로 거의 사용되지 않을 뿐더러 많은 기술적인 문제도 따랐기에 HTML5 에서 빼버린 속성입니다.

이 글은 rebuildingtheweb의 Vlad Alexander가 제시한 “어떻게 하면 longdesc속성을 살릴수 있을까?” 를 번역한 글입니다. 최근 HTML5에서 제외되면서 이 속성에 대한 재조명들이 이루어지고 결론적으로 불필요 하다 라는 방향으로 가는 중에 생각해 볼만한 글이 올라왔군요. 저도 한창 고민하던 부분이라 재미있게 보았습니다.

어떻게 하면 longdesc 를 구할수 있는가?

longdesc 속성은 유용하게 쓰일수 있는 가능성이 있음에도 불구하고, 또한 HTML 접근성 Accessiblity Task Force 에서도 고려해주기를 바랬음에도 불구하고 HTML5 스팩에서 제외되었다. 이 longdesc 를 제외하기로 한 결정은 HTML5 팀의 개으른 반응법을 보여주었다. “이 속성은 잘 안쓰이니까 버리지 머.” 물론 그렇다고 Task Force 가 원하는데로 longdesc 가 재활성화 된다고 해도 개발자들이 열심히 쓰는 것은 아니다. 두 기관이 자신들의 의무를 다시한번 상기하고 나아간다면 올바른 해결책이 나오리라 생각 된다.

HTML5 팀의 의무

HTML5팀은 HTML5가 현재 어떻게 쓰이는지에 초점을 맞춘다. 그것을 기반으로 longdesc의 가치를 바라보며 비인기적이며 현실적으로 의도에 맞게 잘 쓰이지 않는다고 보았다. 그러나 이 상황에서 ‘어떻게’ longdesc 의 사용에 대한 문제점이 고쳐질수 있는지는 묻지 않았다. 어떻게 HTML이 잘 사용되고 있는가에 대한 의무를 바라봤을뿐 어떻게 해야 잘 사용되느냐에 대한 질문을 하지 못했다.

접근성 전문가들의 의무

접근성 전문가들의 의무는 단순히 longdesc를 HTML5에서 재활성화 시키는것 이상에 있다. 이 속성에 대한 유저와 브라우저 밴더들이 바라보는 시각을 사용할만한 기능을 가진 속성이 되도록 바꿔주어야 한다. 이것을 달성하기 위해서는 전문가들이 개발자들의 시각에서 왜 longdesc 속성이 비인기적인 요소인지를 바라보아야 한다.

한가지 제안하는 해결책

상위 WYSIWYG 에디터 개발자중의 한명이자 컨텐츠 개발자들과 꾸준한 교류를 나누는 사람으로써 longdesc 가 제대로 사용되지 않은 이유를 들자면 longdesc와 그와 연관된 속성 alt 가 HTML 스팩에서 제대로 정의되지 않고 있기 때문이라고 말하고 싶다. 그러다 보니 리포트나 기사, 강좌, 레퍼런스같은 파생적인 사용들에서 잘못된 사용을 보여주게 되고 그것들을 통해 브라우저와 Tool 벤더들이 무턱대고 불규칙적인 기능들로 사용하게 되어 버린 것이다.

많은 퍼블리셔들, 컨텐츠 개발자들이 불행하게도 alt 속성은 이미지의 짧은 설명을 삽입하고 longdesc에는 더욱 긴 설명을 삽입한다고 이해하고 있다. 글 쓰는 이들의 관점으로 보면 이것은 당연히 헛갈리는 부분이다. 그들은 ‘왜 내가 짧게 설명하고 나중에 또 길게 똑같은것을 써야 하는가?” 라고 질문하며 왜 이것이 제대로 사용될수 없는지 증명해준다.
[일모리: img 태그 안에 alt 와 longdesc를 같이 삽입하다보니 '왜 똑같은걸 2번 쓰는가'를 의미하는듯 하다.]

그렇다면 앞으로 alt는 이미지의 ‘문자적인 대체’ 로 속성을 정의하고, 콘텐츠 안의 이미지의 ‘설명’을 longdesc로 정의해보면 어떨까 제안해본다. 미묘한 차이이지만 의미있는 중요한 차이점으로 단순히 글자의 숫자에 반영하는 것이 아닌 의미적으로 둘의 선을 확실히 그어준다고 생각한다. 이렇게 변화된 결과는 접근성 뿐만 아니라 개발 벤더들에게도 의미있는 인터페이스 개발의 도움을 주게 될것이며 글을 작성하는 사람들에게도 올바른 컨텐츠를 작성토록 도움을 줄 것이다. longdesc 속성의 약정을 충당하기에 아직 늦지 않았다. alt 와 longdesc가 어떻게 쓰여져야 할지 HTML 레퍼런스와 글들, 강좌들을 업데이트 할수 있다. (늦지 않았다) 브라우저 벤더들에게 alt 와 longdesc가 어떻게 렌더링되어야 하는지 해석 되어야 하는지 보여주고 개선된 사용자 인터페이스를 사용하게 되면 어떤 이득과 도움을 주는지 알려주자.

결론

단순히 longdesc를 HTML5에서 다시 살린다고 해서 웹이 더 접근하기 쉽도록 변하지 않는다. 대신 longdesc같이 접근성 기능들을 인기있도록 만들어 주는 것이 HTML5 팀과 접근성 전문가들의 의무이다. 그리고 그것의 한 방법이 alt 속성과 longdesc 속성을 제대로 정의하여 브라우저 벤더들과 제작자들 퍼블리셔들이 쉽게 적용하고 사용하도록 하는 것이다.

일모리: 이것은 상당히 흥미롭다. 글자수에 따라 longdesc와 alt를 구별하기 보다는 그 의미에서 구별하여 벤더들과 개발자들이 정확히 선을 그을수 있도록 하자 라는건 longdesc 뿐만이 아니라 이미지의 접근성에 대한 시각을 바로 볼수 있도록 눈을 열어주는듯 하다. 물론 longdesc에 대한 기술적인 문제점도 많다. 특별히 댓글부분에 대한 해석을 되도록이면 하지 않았다. 우리에게도 이제 이러한 글들에 대한 바른 해석과 토론이 이루어 질 수 있는 능력이 충분히 생겼다고 생각한다.

The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers.
CSS3 선택자에 대한 슬픈 사실은 페이지 성능 향상에 조금이라도 신경을 쓴다면 전혀 사용하지 말아야 한다는 것이다. 순수하게 클라스와 아이디 선택자를 사용하며 자식 선택자, 하위 선택자, 인접 선택자를 사용하지 않으면 모든 브라우저에서 확연하게 성능 향상을 볼 수 있다.

David Hyatt은 모던 브라우저들의 개발에 영향을 주며 카미노를 만들고 불여우 파이어폭스를 Blake Ross 와 같이 만들어간 사람인 만큼 저 멘트에 대한 여파가 컸었다. 여러 테스팅도 진행되었고 하나같이 결론은 차이는 ‘significant’ 확연하게 차이가 나는 것이 아니므로 남용하지 않는다면 실용적인 사용에도 문제가 되지 않는다고 의견들이 모아졌었다. 오히려 그 시간에 다른 부분에서, 예를들어 JS 향상을 위해 손 보는것이 오히려 더 효율면에서 낫다라고 누군가 언급했었던 기억이 난다.

여기서 최근 재미난 테스팅을 SCREWLEWSE.COM 에서 진행했다. CSS 선택법, 사용법에 대한 카테고리를 나누어 그것이 브라우저 성능 상태와 어떤 연관성이 있을까라는 발상에서 시작 되었는데 일단은 CSS 테크닉에 있어서 나누어 놓은 3가지 방법을 살펴보아야 한다.

1. OOCSS 한창 주목받았던 그리고 꾸준히 접목되고 있는 아이디어. 기본 룰을 담은 class 를 부르고 세밀한 부분을 다른 클라스에 담아 복수 클라스를 부르는 방법. Object Oriented CSS 객채지향 CSS 로 소개도되고 잘 알려진 것으로 안다.

   .ilmol 에 기본 속성을 정의해 주고 .ilmol-1 .ilmol-2에 각각 세밀한 부분을 넣은 후에 html에서 class=”ilmol ilmol-1″ 처럼 복수의 클라스들을 불러주는 방식.

   .ilmol {margin: 10px 25px; font-size: 100%; background: black;}
   .ilmol-1 {color: red;}
   .ilmol-2 {color: yellow;}

2. Sass @extend 는 OOCSS를 좀더 세분화 한 것이라고 보면 된다. 기본 룰을 담을 클라스를 새로 만들지 않고 단순히 여러 클라스를 불러 기본 룰을 정의 한 후 나중에 하나하나 세밀하게 룰을 적용하는 방법.

   .ilmol-1, .ilmol-2 {속성} 을 정의한 후 나중에 .box1 과 .box2를 정의해 주면됨.

   .ilmol-1, .ilmol-2 {margin: 10px 25px; font-size: 100%; background: black;}
   .ilmol-1 {color: red;}
   .ilmol-2 {color: yellow;}

3. Long / Bloated 그냥 각각의 클라스에 알아서 스타일을 주는 방식

   .ilmol-1 {margin: 10px 25px; font-size: 100%; background: black;color: red;}
   .ilmol-2 {margin: 10px 25px; font-size: 100%; background: black;color: yellow;}

이 세가지와 CSS가 없는 스타일을 합하여 4가지들에 각 브라우저들 마다의 테스팅을 진행 하였다. 그래프상 높을수록 시간이 오래걸린다는 것이니 성능에는 반비례한다.

from screwlewse.com

위의 그래프가 보여주듯이 Sass 테크닉이나 oocss 테크닉이 평범하게 사용되는 기법과는 확연한 차이를 보여주고 있다. 특별히 oocss는 모든 브라우저에서 가장 빠르게 읽혔음을 볼수 있는데 Cascading Style Sheet 이라는 법칙인 만큼 oocss 가 적용되지 않았나 생각이 들었다.

재미있게 보셨으리라 생각되고 이 테스팅이 절대 보통하는 테크닉이 잘못되었다거나 속도가 현처히 느리다라는 결론이 아니다. 여러 테크닉을 이해하는데에 있어서 이론적인 결과물을 보여주는 것이다. 적어도 일모리에겐 어느정도의 브라우저마다의 CSS 입력방식에 대한 팁을 선사해주는 부분에서 깨닳음을 얻었다고나 할까?