그 가운데 구글이 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 을 개발의 어느부분에서 어떻게 사용하고 있는가?

참고로 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에 대한 기술적인 문제점도 많다. 특별히 댓글부분에 대한 해석을 되도록이면 하지 않았다. 우리에게도 이제 이러한 글들에 대한 바른 해석과 토론이 이루어 질 수 있는 능력이 충분히 생겼다고 생각한다.

• HTML5의 video 태그와 audio태그를 지원한다는것 (기타 문서적인 틀을잡는 태그들은 이미 지원중이었슴)
• 더욱 빨라진 js엔진
• Location Aware Browsing 탑재
• 더욱 빨라진 컨텐츠 렌더링
• 새로운 웹기술적용: downloadable fonts, CSS media queries, new transformations and properties, JavaScript query selectors, HTML5 local storage and offline application storage, <canvas> text, ICC profiles, and SVG transforms.

파이어폭스 인스톨 후 html5의 video, audio 태그를 강조하는거 보니 안띄워줄수 없더군요. 태그는 간단합니다.

<video src="http://videos.mozilla.org/firefox/3.5/meet/meet.ogv" controls style ="width: 600px;"></video>

삽입후 출력되는 화면.

이제 css로 스타일을 입혀줄수 있겠죠 video {border: 3px solid #eee;} 응용의 부분은 무궁무진합니다.

@font-face

이번 파이어폭스 3.5 부터는 @font-face 가 지원되게 됩니다. CSS3에서 구현되는 기능으로 보지만 이미 CSS2 때에도 사실 IE에서 특정 폰트종류 (.eot) 만 지원되었었죠. 엄청난 관심가운데 개발이 되어졌음에도 불구하고 copyright, 라이센스 등의 문제와 브라우저 미지원으로 널리 사용되지 못했습니다. 물론 이제 사파리3.1, 크롬 2.0 브라우저에 이어 불여우3.5 까지 지원되며 곧 릴리스될 오페라10 에서도 지원하게 됩니다. 몇달안에 IE를 제외한 모든 메이저 브라우저들이 이 기능을 지원 한다는 것입니다.

W3C에서 정의하는 @font-face 를 따오면, @font-face는 필요한 폰트를 링크하여 필요한 부분에 출력토록 하는 기능을 담당합니다. 제작자가 특정 환경때문에 폰트 미지원을 우려하여 기본폰트만을 사용하는 제한을 벗어나서 유저에게 원하는 렌더링을 보여줄수 있게 됩니다. CSS 룰을 사용하여 유저에이전트(보통 브라우저) 는 주어진 텍스트 안에 제작자가 원하는 특정 폰트가 사용될 경우 다운로드 하여 출력하게 됩니다. TrueType (.ttf) 이나 OpenType (.otf) 을 사용할수 있는 것이죠.

The @font-face rule allows for linking to fonts that are automatically activated when needed. This permits authors to work around the limitation of “web-safe” fonts, allowing for consistent rendering independent of the fonts available in a given user’s environment. A set of font descriptors define the location of a font resource, either locally or externally, and the style characteristics of an individual face. Multiple @font-face rules can be used to construct font families with a variety of faces. Using CSS font matching rules, a user agent can selectively download only those faces that are needed for a given piece of text. – W3C

사용법은 나름 쉽습니다. @font-face 에서 사용되어질 폰트이름과 위치를 지정해 놓으면 기본조건이 갖추어 집니다. 그 후 보통 폰트 스타일을 적용하는 것과 동일하게 font-family를 사용하여 이름을 불러주면 되겠습니다.

@font-face {
   font-family: ILMOL;
   src: url("http://ilmol.com/ILMOL.ttf") format("truetype");
}

p {
font-family: ILMOL;
}

특별히 제작자가 사용하고자 하는 폰트와 비슷한 폰트가 이미 유저의 컴퓨터에 있을 시에 그것을 먼저 사용하도록 하며 비슷한 폰트 조차도 없을 경우 다운로드 하게 하는 방법이 local입니다. 예를들어 ILMOL 이라는 폰트와 ELMOL 그리고 YILMOL 이라는 폰트가 거의 비슷한 스타일을 갖고 있으니 ILMOL폰트를 다운로드 전에 ELMOL이나 YILMOL 폰트가 일단 유저 컴퓨터에 있나 확인하여 사용하게 하려면,

@font-face {
  font-family: ILMOL;
  src: local("ELMOL"), 
       local("YILMOL"), 
       url(ILMOL.ttf);
}
 
body { font-family: ILMOL, sans-serif; }

이렇게 지정해 줄수 있습니다. 이는 특히 다른 플랙폼의 컴퓨터들 사이에 비슷한 폰트를 지정할때 유용한데 맥에서의 Helvetica 는 PC에 없으므로 비슷한 서체인 Trebuchet MS 가 있나 확인을 먼저 하게한 후에 Helvetica를 다운받게 할수 있겠죠. 물론 둘다 저작권의 문제도 있고 기본적으로 제공되므로 실제적인 사용의 사례는 없겠지만 말입니다.

위는 실제적으로 사용해 본 결과 입니다. 약 40k밖에 되지 않는 “Walt Disney Script” 서체 입니다. 웹그림 1개 다운로드 받는 사이즈 정도밖에 되지 않지만 엄청나게 파워풀한 결과를 가지고 올 수 있습니다. 디자이너분들은 무슨 이야기인지 뼈저리게 느끼고 계실듯 하네요. 물론 현재 IE와 Opera 9.x는 보이지 않습니다.

아직 이른걸까?

인터넷익스플로러가 지원하지 않는다는 치명적인 단점 말고도 넘어야 할 산들이 있습니다. 일단은 서체의 라이센스 문제입니다. 다행이도 Typekit 이 이부분을 위하여 열심히 뛰고 있는 중입니다만 무료라고 제공되는 폰트들이라 해도 css링크나 웹폰트로의 사용은 금하고 있는것들이 대부분 입니다. 타입킷 이메일 알림이에 가입해 놓은지 오래되었지만 아직도 별 다른 소식이 없네요.

한국에 이 문제를 적용시키게 되면 그 문제는 더욱 커지게 됩니다. 무료로 제공되는 폰트들을 찾기가 거의 불가능 할 뿐더러 지난번 네이버에서 ‘나눔’ 서체를 공개하며 한글 폰트 개발이 얼마나 어려운가를 나누었지만서도 몇천자를 디자인하여야 함은 해외 폰트개발과는 너무나도 차이가 납니다. 또한 서체의 개발이 어렵고 방대한 만큼 그 용량또한 방대합니다. 약 4MB을 넘나드는 사이즈는 웹폰트로써 적합한지의 의문조차 갖지 못하게 만들죠.

그럼 우리에겐 단순히 그림의 떡이냐. 네 앞으로 몇년간은 충분히 가능합니다만 변화의 가능성 또한 충분합니다. 일단 IE의 미지원이 그래도 가장 큰 장애물이겠지만 IE 개발팀 또한 @font-face의 필요를 충분히 인식하고 있기 때문에 추후에 곧 지원되지 않을까 하는 생각입니다. 이미 .eot 폰트 종류를 지원하므로 가능한 부분이라고 봅니다. CSS3가 완전해지지 않는한 지원않겠다는 방침을 들고 일어서면 할말 없습니다만…

IE가 지원에 나섬으로 인해서 모든 브라우저에서 @font-face가 가능해 진다고 볼때 제일 먼저 군침을 돌릴만한 곳은 각종 메거진과 신문사들입니다. 사이트들이 더욱 미려해지고 시시각각 바뀌는 헤드라인이 그 어느때 보다도 아름답게 출력된다면 이를 마다할 미디어 매체는 없다고 봅니다. 더군다나 1px의 미학을 즐기는 디자이너들에게는 천국과 같겠죠.
“난 1px 오탁후!”
여기서 웹서체를 제공하는 회사나 폰트업체가 나온다면 그 또한 유명세를 타게 될지도 모르는 일이구요.

언제 어떠한 방식으로 이 부분이 한국의 디자이너들과 개발자들에게 영향이 갈지는 누구도 모릅니다. 하지만 이미 해외개발자들에겐 시동이 걸렸고 사이트가 더욱더 세련되어지고 진화되도록 도울것은 확실합니다.
Less image, faster browsing, better internet.
이건 그 누구도 부인할수 없는 모두가 원하는 결과입니다. :)

좋은 소식에도 불구하고 한숨소리가…? ;; ㅠㅠ

사파리 브라우저를 설치하시면 오프닝 영상이 나오게 됩니다. 이 영상은 처음에 단순한 맥OSX 설치후에 시작되는 프로그램 자체적인 영상으로 생각했지만 그것이 아니라 여러 이미지들과 작은 MOV 파일을 가지고 HTML, CSS3, JS 로 이루어진 html 페이지 입니다. 물론 영상을 보시면 하나의 비디오 파일을 돌리는 듯한 착각이 들 정도로 잘 꾸며져 있습니다. 이미 베타버전 공개시 토론되었던 부분이라 아주 오랜 시간 후에 치는 뒷북일수 있겠군요.

<audio id="music" src="http://images.apple.com/safari/welcome/media/audio.mp4"></audio>
  <div id="header">
      <h1>Welcome to Safari 4</h1>
  </div>
  <div id="apple">
		<div class="icon"></div>
		<div class="spots"></div>
		<div class="flare"></div>
		<div class="flareicon"></div>
  </div>
  <div id="safari">
    <div>
		 <video id="compass" src="http://images.apple.com/safari/welcome/media/compass.mov" width="256" height="256">
			 <img src="http://images.apple.com/safari/welcome/images/safari.jpg" width="200" height="200" alt="Safari 4" />
		 </video>
    </div>
  </div>
</video>

HTML5 지원 하면 떠오르는 두 태그죠 audio, video가 눈에 띄실겁니다. 그러나 어찌보면 이 페이지에서 작은 부분을 차지할뿐 중요한건 CSS3 자체에 있습니다. #apple 안에 들어있는 .icon, .spots .flare .flareicon 등이 영상에 직접적인 연관을 보여줍니다. 물론 이벤트를 컨트롤 하는 js도 빼 놓을수 없겠죠.

오프닝 페이지의 소스를 보시면 아시겠지만 웹킷전용 CSS3를 제어하여 각각의 icon spots 등을 순서대로 ease-in, linear 방식등으로 일정 시간에 플레이되고 지연되도록 설정되어 있습니다. 간단한 순서대로 나열해서 말씀드리자면 첫째로 대강의 기본 설정이 첫 부분입니다. 그리고 각각의 엘리먼트들이 스케쥴데로 플레이 되도록 -webkit-keyframes 값들이 지정되어 있고 마지막에는 설정값과 엘리먼트의 연결 그리고 플레이 시간이 지정되어 있습니다.

하나하나 설명을 드리면 너무나 길어질듯 하구요, 간단히 예제를 보면서 설명드리겠습니다.
이하 코드는 제가 방금 제작한 ilmol.com 인트로입니다… 참 썰렁하네요.
대강의 스토리 라인은 ilmol.com/wp 를 클릭시 설정된 애니메이션이 작동하는 것입니다. 애니메이션은 하단에서 부터 화면 상단부분까지 사이즈및 투명도가 올라가면서 뚜렷하게 출력된후 사라지는 순서로 정했습니다. 일단 구현된 페이지를 사파리4에서 한번 보시구요.

<!DOCTYPE html>
<html lang="en-us">
<head>
<meta charset="utf-8" />
<title>Welcome to ILMOL</title>
<meta name="Author" content="ilmol" />
<style type="text/css">
body {margin:0; color:#fff; background: #000; overflow:hidden;text-align:center;}
div h1 {-webkit-box-reflect: below 0 -webkit-gradient(linear, left top, left bottom, from(transparent), color-stop(0.4, transparent), to(rgba(255, 255, 255, 0.4)));
}
@-webkit-keyframes introo {
 
      0% {
        opacity: 0;
        -webkit-animation-timing-function:ease-out;
        padding-top: 200px;
      }
 
      60% {
        opacity: 1;
        -webkit-transform: scale(2);
        -webkit-animation-timing-function:ease-in;
        padding-top: 50px;
      }
      
      100% {
        opacity: 0;
        -webkit-transform: scale(0.7);
        -webkit-animation-timing-function:linear;
        padding-top: 75px;
       
      }
    }
.slide {
  -webkit-animation-name: introo;
  -webkit-animation-duration: 3s;
  -webkit-animation-iteration-count: 2;
}
</style>
</head>
<body>
<div onclick="className='slide'">
    <h1>ilmol.com/wp</h1>
</div>
</body>
</html>

보시다시피 html 은 별거 없습니다. 간단한 js로 slide가 시작되도록했고 ilmol.com/wp 주소가 그 안에 들어있습니다.
이 간단한 부분을 가지고 css에서 여러가지를 지정해 주어야 합니다. 애니메이션의 키프래임안에서 시간에따라 어떻게 변화할 것인지를 지정하는 것이 첫번째 입니다. -webkit-keyframes 다음에 나오는 것이 에니메이션 이름이구요. 각각의 keyframe 타임라인에는 투명도, animation-timing-function, 위치 등이 지정되어 있습니다.

keyframe 이 지정되었다면 몇초간 이루어지는지 몇번 이루어 지는지 등을 지정합니다. 저는 3초간 한 사이클이 이루어지고 2번 플레이 되도록 지정했습니다.

.slide {
  -webkit-animation-name: introo;
  -webkit-animation-duration: 3s;
  -webkit-animation-iteration-count: 2;}

주의깊게 보실 부분은 에니메이션 이름이 지정되어 있다는 것입니다. “-webkit-animation-name: introo;” 키프래임 설정이름과 애니메이션 이름이 연결되어야 합니다. 위의 말씀드린 몇가지만 주의하셔서 살펴보시면 전혀 어렵지 않습니다 :)

이번 사파리4 오프닝 영상은 이를 백분 활용하여 감쪽같은 영상을 만들어 내었고 그 영상만으로도 우리를 매혹시키기에 충분했습니다. 앞으로 여러가지 활용 부분들이 개발되고 적용되겠지만 사파리내에서 한정되기 보다는 공식 css3를 사용하여 모든브라우저에 활용되면 좋겠다라는 꿈을 가져봅니다. 물론 쉽지도 않을듯 하고 시간도 걸리리라 생각됩니다만… 스케쥴에 앞서가고 있는 html5, 스케쥴에 뒤쳐진 css3, 둘의 만남은 어떻게 웹을 바꾸어 놓을지. 그리고 언제가 될지가 괜시리 기다려지는 그런 날입니다.

이번 컨퍼런스는 강하게 시작되었습니다. 새로운 맥북 라인을 발표하며 유니바디 디자인 맥북이 맥북프로로 들어가면서 새로운 맥북 프로라인이 형성되었습니다. $1200 대의 맥북프로가 생긴 것이죠. 모두 8G 까지 가능하며 500GB 하드장착이 가능합니다.

그후 새로 발표될 OS 스노우레퍼드를 발표하며 이번 키노트는 정말 굵직한 것들만 발표되는 구나라는 생각이 들었죠. 윈도우 7을 언급하며 발표를 시작한 것이 아무래도 윈7이 상당히 Mac OS X에 근접했음을 알수 있었습니다. 이제 몇주간 윈7을 써보며 상당히 안정적이고 적어도 맥OS를 써보지 않은 사람들에겐 ‘바로 이거야’ 라는 생각이 들 정도의 여파를 가지고 올수 있는 마소의 (잘 배낀) 시스탬이구나 라는 생각이 들었거든요. 스노우 레퍼드의 매력은 충분하지만 윈도우7은 아주 성공적으로 시작되는데에는 큰 영향을 주지 않을꺼 같습니다. 아무튼 스노우레퍼드는 최고의 os로 남을것으로 생각됩니다. 설치후 용량이 6GB나 리커버 해준다니…. :)

그리고 이어진 사파리 4 이야기. 사파리 4가 정식 출시되며 여러부분 메이저 업글이 있음을 시사하며 강력히 선보였습니다. Acid3 100, JS 향상. 새로운 커버플로우와 그리드 UI 는 매력덩어리로 다가왔습니다. 백문이 불여일견 곧바로 설치.

의례적으로 브라우저 설치후 몇초의 짧은 오프닝 영상이 돌아가더군요.

영상후 곧바로 그리드 형태로 Top Sites 들을 자동으로 불러들여와서 로딩됩니다.


물론 편집이 가능하며 몇개의 사이트를 나열할지도 설정이 가능합니다. 처음 로딩시 페이지를 이미지화 하는 작업때문인지 약간의 시간이 걸리는군요. 이 Top Sites 부분은 첫페이로 설정이 가능하여 매번 새 탭을 열거나 새 창을 열때 보여지게 됩니다. 물론 다르게 설정도 가능합니다. 이미 오페라에서 시도된 부분이지만 맥의 그래픽과 만남으로써 진화된 느낌이 드는군요. 이번 오페라 10의 탭 사이트 프리뷰 기능도 상당히 맘에 들던데 아직 오페라가 건장하다는걸 잘 보여주고 있습니다.

북마크를 열면 이제 맥유저와 아이튠즈 유저에게는 친근한 커버플로우 UI가 실행됩니다. 이건 상당한 변화인데요. 아시다시피 북마크가 커지면 커질수록 사이트 이름과 내용을 연관 시키기 힘들어 지면서 활용성이 떨어지게 됩니다. 그것들을 이제 쉽게 살펴보고 사이트를 구별할수 있는 커버플로우는 북마크 정리에 상당히 도움이 될것으로 보입니다. 제 북마크들이 너무 많다보니 커버플로우가 데이터를 수집 할것인지 물어보는군요. 그다지 북마크가 많지 않으시다면 이미 정리가 되어 있을 것입니다.

이런 커다란 변화 말고도 탭 디자인의 작은 변화 그리고 검색창의 드랍다운 자동검색 결과는 매력을 더해주고 있습니다. 전에는 플러그인을 설치해야 했죠.

플러그인 이야기를 하다보니 이번 사파리는 플러그인 크래쉬가 될 경우 사파리 브라우저 자체가 다운되기 보다는 플러그인이 다운되도록 설계되어 더욱 안정적으로 프로그램이 돌아가게 되었습니다.

겉은 그렇고, 내부를 살펴보면, Acid3 의 100/100 통과, 그리고 JS 실행속도가 이전 버전보다 4.5배 빨라진점, 더욱 넓은 범위의 HTML5, CSS3 준수등이 눈에 들어옵니다.

아직도 강력한 브라우저 IE를 비교대상으로 놓는건 당연한 일. IE8보다 JS 실행속도는 7.8배가 빠르며 IE8이 21/100점으로 Acid3를 통과한데 비해 거뜬히 100/100 을 통과했다는 비교는 이제 거의 식상할정도로 들려오는 ‘IE보다 좋은’ 브라우저의 표현입니다. 이 js는 new Nitro JavaScript engine 기술에 힘입어 상당한 속도를 보여주고 있고 html 페이지에서도 빠른 로딩을 보여주고 있네요.^[1]

HTML5 와 CSS3 의 업데이트는 아무래도 어느정도 위치확인을 위한 움직임일뿐 커다란 웹개발자들의 개발 리밋이 변화되는건 아닌거 같습니다. 물론 꾸준히 개발되고 발전되고 적용되어야 합니다. 이미 어느정도의 기본 HTML5는 모든브라우저에서 실행이 가능하고 CSS3 또한 구현방법이나 정도의 차이가 브라우저들마다 있으므로 실무적 변화를 줄꺼 같지는 않습니다. 좀더 살펴 본후 더 자세히 업데이트 하겠습니다.

업데이트: 사파리4의 오프닝 영상의 비밀

아이폰, 맥북, 스노우레퍼드, 사파리등의 큰 뉴스를 불러온 WWDC. 그러나 큰 실망을 안겨주기도 했네요. 아무튼 좋은 한주, 그리고 여름의 시작입니다.

P.S. 애플사이트에 공식 키노트가 올라왔습니다.

P.P.S. 확실하게 메모리 관리가 향상되었군요. 장시간 브라우저를 사용하다 보면 버벅거리는 것이 한번에 느낄수 있었지만 이번 업데이트는 상당한 안정성을 보여주고 있습니다. 물론 아직도 메모리를 차지하는 양은 상당합니다. 이번 맥북라인이 8G 메모리 서포트를 선언한 이유? :)

1. source: apple.com

Div 엘리먼트는 특별한 의미가 전혀 없다. 자식 엘리먼트를 나타낸다. 이어지는(연속적인) 엘리먼트 그룹에 일반적인 의미를 마크업 하기위해 class, lang/xml:lang 그리고 title 속성과 함께 사용될수 있다.
The div element has no special meaning at all. It represents its children. It can be used with the class, lang/xml:lang, and title attributes to mark up semantics common to a group of consecutive elements. – W3C

div 엘리먼트에 phrasing content 을 담을 수 있도록 허락함으로써 저자들이 class=”" 속성 사용에서 부터 마크업 안에 다른 어떤 엘리먼트를 넣지 않는등 div 를 남용하기 쉽도록 되어있다. 접근성의 시각으로 볼때 이것은 악몽^[1] 이며 그러한 페이지들을 표준이 아님을(non-compliant) 알리는 식으로 하되 스팩이 따로 지원하지 않는 한 지금 상태의 메카니즘대로 사용되는걸 제한하지는 않도록 하면 좋을꺼 같다.
Allowing div elements to contain phrasing content makes it easy for authors to abuse div, using it with the class=”" attribute to the point of not having any other elements in the markup. This is a disaster from an accessibility point of view, and it would be nice if we could somehow make such pages non-compliant without preventing people from using divs as the extension mechanism that they are, to handle things the spec can’t otherwise do (like making new widgets). – W3C

그러고 보니 Table 의 악용 그리고 남용에 대해 글을 쓴지가 어제 같은데 이제는 div 남용에 대한 글들을 여기 저기서 볼 수 있다. 사실 불완전한 HTML 내에서 시멘틱 마크업을 최대한 살리면서 디자이너들이 표현하려다 보니 남용아닌 남용이 표출될 수 밖에 없다. 단순한 division 을 나타내며 문서를 자르는 것 뿐만이 아니라 이것 위에 프레젠테이션을 씌워야 하는 고통은 이미 많은 퍼블리셔들과 개발자들이 경험한 고통이다 (물론 nested div 도). html5 에서 header, footer, article, section, aside 등이 어느정도 해결을 해준다고 하지만 그 또한 ‘바로 이거야!’ 라는 뇌리를 치는 해결책은 아니다. 물론 어느정도의 시멘틱적인 요소를 첨가함으로써 문서 자체에 의미를 주지만 그것을 더욱 의미 있게 나누려다 보니… 사실 더 머리가 아파온다. 오해는 없으시길. 대환영 그리고 대환영이다. 숨통이 트여지는 기분.

물론 아직 밖은 흐리다.

Phrasing content 는 문서의 text(문자, 본문)들과 그 text 들을 마크업 하는 문단내(intra-paragraph) 엘리먼트들 까지도 포함한다. phrasing content 의 모음이 문단을 형성한다.
Phrasing content is the text of the document, as well as elements that mark up that text at the intra-paragraph level. Runs of phrasing content form paragraphs. – W3C

P.S. 사이트에 간단히 JS 로 HTML5 분위기를 IE 에서도 낼 수 있다는 장점을 사용해서 일몰.com에 몇안되는 요소들을 첨부 해보았다. 전에 어느분의 포스팅에서도 본거 같은데, DOCTYPE html PUBLIC “-//W3C//DTD XHTML Basic 1.0//EN” “http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd” 이거… 외우기 힘들다… <!DOCTYPE html> 얼마나 좋나…

P.P.S 몇일간 사이트 업데이트를 할 예정.

1. disaster 재앙이라는 표현은 한국에선 최악의 상황으로 표현될 뿐더러 잘 사용되지 않는다.