Open Web 짝사랑. iOS Programming.
using a minifed version of the code is much faster than the packed one – even though its file size is quite larger.
The iPhone cache experiment suggests an additional performance rule specific for developing web sites for the iPhone: Reduce the size of each component to 25 Kbytes or less for optimal caching behavior.
Performance Research, Part 5: iPhone Cacheability – Making it Stick
잘게 자르는 것도 요령이 필요하군.
많은 논란을 일으켰던 어제의 IE8 version targeting 사건으로 상당수 웹 개발자들에게 혼란과 걱정을 불러일으켰었으나, 하루가 지난 지금 뜻하지 않은 반가운 소식이 들리고 있다.
우연하게도, 바로 어제 W3C에 첫 Working Draft로 등재된 HTML5가 마침 구원의 손길을 보내온 것이다. 요는 HTML5 DOCTYPE을 쓰면, IE8을 포함한 모든 웹 브라우저들에서 어떤 쓸때없는 코드를 추가하지 않아도 가장 최신의 표준 랜더링 엔진을 사용하도록 할 수 있다는 것이다.
결국 다음 한 줄의 Doctype 선언이면, 예전처럼 브라우저 버전에 관계없이 웹 표준(CSS, HTML5, DOM, JavaScript)을 따르면서 미래를 대비하는 웹 사이트를 개발할 수 있게 된다는 것이다:
<!DOCTYPE HTML>
평상시 사용하는 Doctype 보다 무척 간단해 보이지만, 이것은 일부러 이렇게 간단하게 쓰일 수 있도록 의도된 바이다.
더 놀라운 것은, 현재의 모든 브라우저들(IE, FF, Safari, Opera)은 위의 Doctype을 보면 비록 HTML5을 아직 모두 다 구현하지는 않더라도 standards mode로 문서를 해석한다는 사실! 그래서, 약간의 무리는 따르겠지만, 지금 당장 문서에 적용할 수도 있단다.
골치 꽤 썩힐 뻔했던 version targeting으로부터 해방될 수 있으니 다행인 것은 사실이지만, 여전히 웹 표준을 따르며 제작된 현재의 웹 사이트들은 어떠한 수정 조치를 취하지 않는 한, IE8에서는 표준 모드로 해석되지 않는다는 것은 그래도 아쉬움으로 남을 수밖에 없다.
아무튼, 앞으로 HTML5가 가져올 흥미진진한 변화를 기대하며, 책갈피해 두었던 HTML5의 변화된 면모를 자세히 훑어볼 때이다.
지금 웹 개발자들 사이에선 갑자기 터져나온 차기 IE8에서 처음 도입될지도 모를 소위 “Version Targeting”에 관한 논쟁으로 시끌거리고 있다.
이 웹 사이트는 IE X에 최적화되어 있습니다.
의 부활?
당연한 얘기지만, 제대로 된 웹 개발자들은 웹 표준 규약을 준수하면서 접근성이 좋고 동시에 효율적이고 유용한, 그리고 점진적으로 확장 가능한(progressive enhancement) 웹 사이트를 개발하려고 하지 결코 특정 버전의 웹 브라우저만을 목표로 개발하지는 않는다고 믿고 있다. 그런데 이번 소식은 어쩌면 이런 믿음에 찬 물을 끼얹는 얘기가 될 수도 있다.
이런 얘기가 나온 것이, 앞으로 웹 표준 규약을 정말 잘 따르는 IE8을 발표하게 된다면, 현재 다수의 웹 표준을 무시하고 제작된 많은 웹 사이트들이 무참히 깨져 보이게 되는 현상을 막아보겠다는 의도로 이해되지만, 그 실제 구현 가능성이 의심스럽고 (IE8에 내장된 Time Machine?), 설령 이것이 그대로 구현된다고 하더라도, 위의 제안서에 의도된 대로 다른 웹 브라우저들에서도 똑같이 이번 version targeting 관련 meta tag가 구현되지는 않기만을 바랄 뿐이다. (다행히, 이미 WebKit에서는 version targeting을 구현하기 어렵다는 점을 밝혔다.)
이 소식을 듣고 가장 먼저 드는 의문은, 만약 이 meta tag을 완전 무시해서 개발된 지금의 사이트들은 IE8에서는 과연 IE6의 랜더링 엔진을 쓰게 될 것인가? 아니면 IE7? 짐작컨데, 이 경우는 또 Doctype switch에 따라 IE7(Standards mode)과 IE6(Quirks mode)를 오락가락 할 듯한데, 이렇게 되면 미래에 사용자가 아무리 더 똑똑한 웹 브라우저로 접속해도 해당 웹 사이트는 개발자의 손을 떠나 하나의 특정 랜더링 엔진에 묶여버리는 것은 아닌지?
몰론, 이것을 방지하기 위한 방법으로 한 줄의 meta tag를 추가해주고, 오래된 사이트의 경우 새로운 웹 표준 환경에 맞게 오래되고 잘못된 코드를 수정해주면 되겠지만, 과연 개발자의 주기적 유지보수가 지원되고 있는 웹 사이트는 얼마나 될 것이며, 어쩌면 웹 표준 나몰라라 하는 무지한 웹 개발자의 경우 이 version targeting을 역 이용해서 아예 자신의 웹 사이트를 자청해서 IE6에 묶어놓는 경우도 빈번할 것이다.
결국, 혁신에는 둔감해졌으나 시장 장악력을 최우선시 할 수 밖에 없는 MS가 독점적 위치에 있는 웹 브라우저의 자리를 앞으로도 계속 고수하기 위한 또 하나의 방어막이자 웹 표준으로 가기 위한 걸림돌로 밖에 보이지 않고, backwards compatibility를 앞세워서 현재의 웹 환경을 그냥 꽁꽁 얼려버릴지도 모를 일이다.
가장 우려되는 점은 이것이 실제 구현될 경우, 특히 IE의 독과점이 지속되고 있는 국내의 현실을 비추어 볼 때, 웹 표준화의 진척 속도는 더 느려질 수 밖에 없을 것이고, 어쩌면 웹 환경은 더 오랫동안 IE6 혹은 IE7에 묶여버리게 되리라는 예측이다.
더러운 먼지는 털어내야지, 진공 포장해서 고이 간직할 필요는 없지 않은가?
이번 제안을 몇 번씩 읽어봐도 장점이라고 예시된 backwards compatibility나 더 가속화될 IE의 웹 표준 기술 지원 주기(?), 개발시 특정 IE 버전을 위한 가상 머신의 불필요, 더 예측 가능하고 계획된 점진적 개발의 진행 등 여러 이점들 보다도, 이것이 가져올 더 심각한 부작용이 염려되는 것은 어쩔수 없다.
But wait, a lot of people say at this point, why isn’t this a problem for Firefox, or Safari, or any other browser? The answer is that developers of many sites had worked around many of the shortcomings or outright errors in IE6, and now expected IE7 to work just like IE6. Web developers expected us, for example, to maintain our model for how content overflows its box, even in “standards mode,” even though it didn’t follow the specification – because they’d already made their content work with our model.
그건 웹 표준이란 존재를 모르는 무지한 웹 개발자들의 불평이었겠지.
그나마, 이제 HTML5의 spec은 훨씬 더 명확해졌다는 소식은 들려오지만, 앞으로의 웹 개발 환경은 훨씬 더 복잡해지겠군. IE6 mode, IE7 mode, Super Standards mode… 😕
IE8에서 Super Standards mode를 원하세요? 그럼, 할 일이 하나 더 있군요. 아래의 meta tag를 추가하는 것도 잊지 마세요. 이제 Super Standards mode는 공짜가 아니랍니다! 아참, 요놈은 IE8 전용.
최근에 갱신된 iPhone 1.1.3 firmware update를 설치하면 새로 추가된 Safari의 WebClips 기능으로 iPhone의 Home Screen에 자주 가는 웹 사이트들을 등록해서 손쉽게 다시 꺼내볼 수 있게 되었다.
그런데, 이렇게 등록해고 iPhone의 Home Screen에서 보여지는 웹 사이트들의 아이콘들은 등록 당시의 웹 사이트 모습을 그대로 축소해 놓은 모양이다. 이렇게 되면 간혹 등록해 둔 다른 웹 사이트들과 비슷해져서 혼동을 일으킬 수 있는데, iPhone Dev Center 문서에 있는 Create a WebClip Bookmark Icon 단락에 가면 이 아이콘을 대체하는 방법이 소개되어 있다.
간단히, 보통 “favicon.ico”이 위치하는 웹 사이트의 root 디렉토리에 57X57 픽셀 크기의 “apple-touch-icon.png” 이름의 파일을 위치시켜 주면 된단다. 그리고, 만약 웹 사이트 전체를 위한 책갈피 아이콘 대신에 특정 웹 페이지의 책갈피 아이콘을 다르게 사용하려면, 해당 페이지의 <head> 부분에 다음과 같이 추가해줘도 됨.
아이콘의 “반들거리는(glossy)” 효과는 iPhone 혹은 iPod touch가 알아서 처리해 준단다.
개인적으로 함께 작업하기 가장 편안한 JavaScript 라이브러리인 jQuery가 벌써 공개 2주년을 맞이하였다.
이를 기념해서 새로운 버전 1.2.2가 발표되었는데, 바뀐 주요 내용으로 몇몇 버그 수정과 함께 가장 많이 사용되는 DOM element를 jQuery 함수로 전달하는 과정이, 예를 들어 $(DOMElement), 3 배나 더 빨라졌다고 한다.
이 밖에도, .ready() 함수의 경우 Internet Explorer에서의 기능 구현이 개선되었고, 이젠 모든 브라우저가 DOM을 다 읽어들일 때까지 기다리는 것이 아니라 CSS까지 마저 읽어올 때까지 기다려 준단다. 이것은 보통 특정 요소의 스타일을 변경하고 싶을 떄, 어차피 웹 브라우저가 CSS 파일을 먼저 해석해야 하기 때문에 바뀐 변화인 듯.
그리고, .hover()는 이제 새로운 mouseenter와 mouseleave 이벤트로 분리되었다. 참고로, 이놈들은 하위 요소들에도 함께 적용되는 mouseover와 mouseout과는 차별되서, 해당 요소에만 적용된다.
또, 새로 추가된 Mouse Wheel plugin이 소개되었다. 사용 예:
$"div"bind"mousewheel"if delta < 0$thisappend"up";else$thisappend"down";;
:not() selector의 사용 용법도 다양해져서, 다음과 같은 작업도 가능해졌다:
$".hover:not(li.active)"$"li:not(.active,.hover,:contains(test))"
무척 복잡해 보이지만, 그 사용 목적은 아주 명확하고 세밀해졌다.
일반 jQuery Ajax 작업에도 변화가 있어서, 덤으로 서버에 Accept header 정보도 함께 전달하면서, 원하는 종류의 데이타를 선택적으로 불러올 수 있게 되었다.
매번 생각하지만, jQuery는 개발자들을 위한 두통 완화제일지도.