jQuery가 네 번째 생일을 맞아 새 버전(1.4)을 발표했다.

지금 당장 jQuery Minified 버전과 jQuery Regular 버전을 내려받아 둘러보고 자신의 사이트에 바로 적용시킬 수가 있다. 물론 Google에서 호스팅하고 있는 놈을 자신의 사이트에 직접 추가놓는 것이 여러모로 유리할 것이다.

참고로, WordPress에 새로운 버전의 jQuery를 추가할 때는 plugin들의 중복 loading을 막기위한 약간의 주의가 필요한데, 사용하고 있는 테마 디렉토리 밑에 있는 functions.php 파일에 다음과 같이 추가해 준다.

if ( !is_admin() ) {
  wp_deregister_script('jquery');
  wp_register_script('jquery', ("http://ajax.googleapis.com/ajax/libs/jquery/1.4.0/jquery.min.js"), false, '1.4.0');
  wp_enqueue_script('jquery');
}

새 버전에서는 자주 쓰이는 method들의 function calls 횟수를 줄이면서 실행 속도가 무척 빨라졌다고 하니 반가운 일이다.

다음은 코드로 본 새로운 기능들 중 눈에 띄는 것들:

// Easy Setter Functions 
$('a[target]').attr("title", function(i,title){
  return title + " (Opens in External Window)";
});
 
// Quick Element Construction 
jQuery("<div/>", {
  id: "foo",
  css: {
      height: "50px",
      width: "50px",
      color: "blue",
      backgroundColor: "#ccc"
  },
  click: function() {
     $(this).css("backgroundColor", "red");
  }
}).appendTo("body");
 
// Per-property Easing 
$("#clickme").click(function() {
  $("div").animate({
    width: ["+=200px", "swing"],
    height: ["+=50px", "linear"],
  }, 2000, function() {
    $(this).after("<div>Animation complete.</div>");
  });
});
 
// Event Multi-binding 
$("div.test").bind({
  click: function(){
    $(this).addClass("active");
  },
  mouseenter: function(){
    $(this).addClass("inside");
  },
  mouseleave: function(){
    $(this).removeClass("inside");
  }
});

더불어서, jQuery API도 자기만의 sub-domain에 자리잡게 되었다: http://api.jquery.com/
PDF 혹은 JPEG 형식의 jQuery 1.4 API Cheat Sheet과 jQuery 1.4 iPhone reference app도 챙겨놓고 볼 일.

추가 참고 문서: jQuery 1.4 Resources For Developers | W3Avenue

갱신: 과거 전통(?)에 어긋나지 않게 일주일여 만에 버그를 잡은 jQuery 1.4.1 버전이 발표되었다.

현재 웹의 화두는 웹 어플리케이션으로의 진화라고 요약될 수 있을 것이다. 이를 아우르는 새로운 웹 표준으로 HTML5가 자리잡고 있는데, 여기에는 과거 데스크탑 어플리케이션의 전유물로만 여겨지던 여러 기술들을 거의 모두 아우르고 있다. 과거, 한 때 정체되어 있던, HTML4, XHTML1 그리고 DOM2 HTML 웹 기술들을 대체할 목적으로 새로운 틀이 만들어지고 있는 것이다.

그렇다면, 지금 당장 HTML5를 사용할 수 있을까? 해답은 바로 웹 브라우저들의 지원 상황에 달려있다.
공식적으로 발표된 HTML5의 W3C Candidate Recommendation 단계로의 진입은 일러야 2012년으로 예상하고 있으며, 현 브라우저들의 지원 상황도 그 편차가 심하지만, 대세를 그르치지 않는 이상 앞으로 상황은 급속도로 좋아지리라 생각된다.

또한, 당장 HTML5를 사용해도 별 큰 문제가 없는 것이, HTML5 태생부터 과거 호환성을 염두에 두었기에 큰 무리없이 점진적으로 새 기술을 흡수(Progressive Enhancement)하는데 유리하다는 점도 있겠다. 좀 더 자세한 브라우저들의 HTML5 기술 지원 상황은 When can I use… 페이지에서 확인할 수 있다.

자, 그럼 HTML5로 전환하기 전 챙겨야 할 사항들을 알아보자. HTML5로 한 발 더 내딛기 전에 챙겨야 할 것들(이)란 제목의 글 마저 읽기 →

항상 웹 개발자들은 IE 렌더링 엔진의 모자름을 아쉬워하며, 사용자들이 더 나은 웹 브라우저를 설치해주기만을 간절히 바라거나, 혹은 최소의 방어 장치로 셀 수도 없는 온갖 가지의 임시 대응 패취 코드를 여기저기 심어놓는 일로 스트레스만 쌓이게 되는 일은 하루 이틀이 아니다.

이런 와중에, Google에서 문제에 직접적으로 칼을 대는 제안을 내놓았다. IE 심장을 Google Chrome의 렌더링 엔진(WebKit)으로 바꿔치기를 하려고 하는 것이다.

솔직히, 문제의 근본을 뜯어고치는 해결책은 아니더라도 살짝 돌아서 갈 수 있는 기막힌 방법이 아닐까? 주장대로만 된다면 한 번 Google Chrome Frame을 설치해놓은 IE 사용자라면, Google Chrome의 탁월한 렌더링 엔진 덕분으로 HTML5를 포함한 더 많은 표준 웹 기술을 아무런 제약 없이 맛보게 될 수 있을 테니까.

그런데, 폭 넓은 웹 기술에 관심이 많은 사용자라면 애초에 IE로 웹 서핑을 하려 하지는 않을 것이기 때문에, 결국 Google이 의도한 것은 평소 웹 기술엔 관심이 없는, 그리고 불가피하게 IE 6에 묶여있는 사람들에게 일시적으로나마 특정 사이트에 사용된 웹 기술을 사용할 수 있도록 하는 일종의 통과 패스권을 나눠주는 격이 될 테고, 또 개발자들에게는 하나의 화끈한 한 방의 해결책으로 사용될 수 있는 선택권이 추가되어 고마운 일이겠다.

자, 그럼 IE 사용자가 이 요긴한 통과 패스권을 처음 받으려면 우선 마주치는 페이지가 있는데, 살짝 혼란과 거부감이 들지는 않을까? (물론, 플러그인 설치 후 원래 페이지로 돌아가긴 하겠지만 말이다.)

그림 속 보여지는 app은 Google이 준비중인 HTML5 기술을 이용한 야심작 Google Wave로 현재 Internet Explorer 6,7,8 모두 지원하지 않는다.

어찌 됐든 상황을 되짚어 보면, Microsoft가 열어 놓은 뒷 구멍을 통해 자신의 심장이 경쟁자의 것으로 통채로 바꿔치기된 형국이니, 앞으로 MS의 반응이 재밌어지겠군.

물론, 이미 TextMate에는 내장된 훌륭한 HTML과 CSS snippets을 사용해서 효율적으로 코딩할 수 있는 여건이 제공되고 있지만, 456 Berea Street의 소개 기사로 알게된 zen-coding은 여기에 엄청난 효율의 상승 효과를 더해준다.

사용 예를 보면 한 눈에 그 막강함을 눈치챌 수 있다.

div#main-menu>ul.menu>li#item-$*5{This is an item $}*5

에디터에서 위 코드를 입력하고 Zen Coding 명령(command+E)을 실행하면 다음과 같은 snippet을 돌려준다.

<div id="main-menu">
  <ul class="menu">
    <li id="item-1">This is an item 1</li>
    <li id="item-2">This is an item 2</li>
    <li id="item-3">This is an item 3</li>
    <li id="item-4">This is an item 4</li>
    <li id="item-5">This is an item 5</li>
  </ul>
</div>

말 그대로, HTML and CSS hi-speed coding 주장에 걸맞는 plugin으로, CSS selectors를 써서 HTML DOM을 효과적으로 생성/코딩할 수 있다는 점은, 과거 Ruby gem plugin으로 유명한 Haml의 장점을 그대로 따와서 바로 HTML과 CSS 파일에 사용할 수 있게 된 것이나 마찮가지다.

현재, Zen Coding은 TextMate 말고도, Aptana, Coda, NetBeans 그리고 Expresso를 지원한다고 나와있으며, 홈 페이지에서 데모용 스크린케스트도 제공하고 있다.

참고로, Zen Coding은 러시아 개발자들이 주축이 되어 개발되고 있기 때문에, HTML Root element에 속해있는 html의 lang 속성을 기본 ru에서 ko로 바꾸어주는 수정이 필요하다. TextMate의 경우, Zen-HTML bundle은 Bundle Editor를 열어서 수정하고, Zen Coding bundle은 번들 패키지 속 /Support/zencoding/settings.py 파일을 열어서 수정해주면 된다.

이제, 이런 코딩 작업 향상이 받쳐줄 만한 좋은 아이디어만 쏟아져 나와주면 좋을 텐데, 역시 어렵군. 😮

디자인에 민감한 사람들의 이야기를 듣다보면 많은 이들이 일반 링크나 대체 이미지로 치장된 링크를 눌렀을 경우 보여지는 링크 둘레의 점선을 없애달라는 요구를 많이 한다. 하지만, 이는 키보드 접근성을 해치는 경우라서, 그대로 놔두거나 적어도 링크 옆으로 삐져 보이는 점선을 없애는 조치 – a {overflow: hidden;} – 만을 권하고 있다.

요 점선의 목을 쥐고 있는 놈이 바로 outline이란 놈인데, 민감한 디자이너와 접근성 우선 옹호자 모두가 만족할 수 있는 문제의 해결 방법이 공개되었다. Opera에 속해 있는 Patrick씨가 future of web design tour 2009에서 행한 키보드 접근성에 관한 프리젠테이션에 있는 내용인데, 핵심은 적절한 상황(키보드 focus를 방해하지 않는 마우스 클릭)에서만 이 outline을 없애서 키보드 접근성을 해치지 않으면서도 링크 선택시 보여지는 점선의 둘레를 없애라는 것이다.

코드로 보면 너무나 간단하다.

a:active { outline: none; }

물론, 여기서 일반 a 태크의 outline property는 건드리지 않는 것이 중요하다.

너무나 단순하지만, 잠시라도 깊이 생각해보질 않아서 이렇게 쉬운 해결책을 그 동안 그냥 지나쳐 버렸던 것일까?
이미지 대체 링크를 마우스나 키보드를 사용해서 선택했을 때 여러 경우의 수를 조합해서 비교해 놓은 실험 페이지에서 최적의 결과를 직접 확인할 수 있다.

마지막으로, Patrick씨 행한 프리젠테이션 슬라이드(pdf)에 나와있는 맺음말을 옮겨놓는다.

if you style :hover, also :focus and :active
don’t suppress outline completely (reintroduce :focus and suppress :active)
leave tabindex alone – source order
JavaScript on hover (mouseover/mouseout) also on focus/blur (if focusable element)
lightboxes and their problems
only attach behaviour to focusable elements