CCL source from http://www.lightmatterphotography.com/


FireBreath 1.0 이 릴리스 되었습니다. 이게 뭘까요?
FireBreath는 크로스 플랫폼 플러그인 아키텍쳐로, 다음을 목표로 합니다.
  • NPAPI 브라우저 지원(윈도우, 맥, 리눅스):
    • Gecko/파이어폭스
    • 구글 크롬
    • Apple 사파리
  • ActiveX 콘트롤 호스트 :
    • Microsoft 인터넷 익스플로러 6, 7, 8
새로 작성한 플러그인에서 스크립트를 실행하고 다양한 기능을 더하거나 수정할 수 있습니다. Indexed DB와 같은 W3C API를 구현해보는 것도 재밌을 것 같습니다.

from FireBreath: Cross platform plugin framework
Posted by 행복한고니 트랙백 1 : 댓글 0

http://www.flickr.com/photos/jasonprini/4104210048/

스티브 사우더스씨가 브라우저의 이상한 동작에 대한 글을 작성했습니다. 성능에 관련된 내용인데, 간략한 내용은 다음과 같습니다.

스키마가 없으면 두 번 다운로드
인터넷 익스플로러 7과 8 버전은 http 프로토콜이 빠져있으면 스타일 시트를 두 번 다운로드 합니다. 가끔 "//stevesouders.com/images/book-84x110.jpg" 과 같이 사용하는 경우는 봤는데, 이 경우는 계속 주의해야 할 것 같습니다.

document.write 스크립트가 다운로드 정지의 원인(파이어폭스)
파이어폭스에서는 docuemnt.write를 사용한 스크립트를 읽어들이면 다른 다운로드를 정지시킵니다. 안타까운 사실이지만, document.write는 이미 만들어졌습니다. 이 문제는 페이지 컨텐트에 document.write를 이용해서 광고를 삽입하려고 할 때 수천억배쯤 더 나빠집니다. 대충 이런 식으로 작성하죠.
[code:js]
document.write('<script src="http://www.adnetwork.com/main.js"><\/script>');
다행히 대부분의 최신 브라우저들은 document.write로 추가된 스크립트까지 병렬로 읽어들입니다. 그러나, 몇 주전 파이어폭스 3.6에서 광고를 삽입할 때 이상한 중단 현상을 발견하고, 추적해보았더니 document.write로 추가된 스크립트가 문제였습니다.
document.write 스크립트 테스트 페이지에서 이 문제점을 보여주고 있습니다. 이 페이지에는 4개의 스크립트가 있는데, 첫번째와 두번째 스크립트는 document.write를 사용해 추가되었습니다. 세번째와 네번째 스크립트는 일반적인 방법(HTML과 SCRIPT SRC)을 사용해서 추가했습니다. 그리고 모든 스크립트는 4초가 걸려야 다운로드 할 수 있도록 했습니다. IE8, 크롬4, 사파리4, 오페라 10.10은 페이지를 전부 다운로드 하는데 ~4초가 걸렸습니다. 모든 스크립트는 document.write까지 포함해서 병렬로 처리되었습니다. 반면 파이어폭스에서는 페이지를 전부 다운로드 하는데 12초가 걸렸습니다(2.0, 3.0, 3.6에서 테스트). 첫번째 document.write 스크립트는 1초부터 4초까지 걸렸고, 두번째 document.write 스크립트에 5초부터 8초까지 걸렸습니다. 그리고 나머지 두 개의 일반적인 스크립트를 9초부터 12초까지 다운로드 했습니다.

media=print 스타일시트
인터넷 익스플로러에서는 media="print"를 사용한 스타일시트가 렌더링을 정지시킵니다.
저는 웹브라우저가 현재 사용중이지 않은 미디어 타입의 스타일시트를 건너뛰지 않고 다운로드한다는 사실에 놀랐습니다. 몇몇 웹 개발자들에게 물어보았지만 아무도 이런 동작에 대한 적당한 이유를 대지 못하더군요. 또한 여러분은 media="print" 타입의 스타일시트라 하더라도 Page Speed나 YSlow의 추천에 따라 문서 HEAD에 스타일시트를 두려고 할 것입니다.

동적인 스타일시트
IE에서는 DHTML과 setTimeout을 사용해서 스타일시트를 읽어들이면 렌더링이 멈추는 것을 방지할 수 있습니다. 몇 주전에 유명한 위젯을 만든 회사와 회의를 했습니다. 위젯이 메인 페이지에 주는 영향을 줄이기 위해 그들이 사용한 기술이 바로 다음과 같이 스타일시트를 동적으로 불러들이는 것이었습니다.
[code:js] var link = document.createElement('link'); link.rel = 'stylesheet'; link.type = 'text/css'; link.href = '/main.css'; document.getElementsByTagName('head')[0].appendChild(link);
과거에는 다운로드 중단을 피하기 위해 스크립트를 동적으로 로딩하는 것에만 주의를 기울였습니다. 스타일시트를 동적으로 읽어들일 생각은 미처 하지 못했었죠. 스타일시트로 오면 다운로드 중단은 문제가 되지 않습니다. 스타일시트는 다운로드를 멈추게 하지 않습니다(파이어폭스 2.0는 예외). 스타일시트 다운로드에서 걱정스러운 부분은 스타일시트를 모두 다운로드 하기 전까지 렌더링을 멈추는 IE의 특성입니다. 다른 브라우저에서는 스타일이 적용되지 않은 컨텐트가 잠깐 나왔다가 사라지는 현상(Flash Of Unstyled Content, FOUC)이 생길 것입니다.

배경이미지 예측
크롬과 사파리는 스타일시트가 전부 준비되기 전이라도 배경 이미지의 다운로드를 시작합니다. 배경 이미지 스타일이 재정의 되는 경우라면 쓸데없는 다운로드가 늘어나는 셈입니다.
직장 동료인 스티브 램이 이런 동작을 저에게 알려주었는데, 이 얘기를 들었을 때 제가 처음 했던 말은 "완전 낭비잖아!" 였습니다. 개인적으로 프리페칭(prefetching)을 좋아하기는 하지만, 대부분의 프리페칭 기능은 너무 공격적이어서 크게 좋아하지 않습니다. 사용하지 않아도 될 다운로드 리소스를 소모하는 일이 잦기 때문입니다. 이 얘기를 처음 들은 이후에 조금 더 생각해봤습니다. 예측된 배경 이미지의 낭비는 얼마나 자주 일어날까? 검색해봤더니 유명 웹 사이트에서는 재정의된 배경 이미지 스타일이 없더군요. 하나도요. 그런 페이지가 하나도 없다고 말할 수는 없겠지만, 매우 이례적인 경우인 것만은 확실합니다.
다르게 생각하면 이러한 배경 이미지 예측 다운로드는 사용자가 인지하는 페이지 속도와 성능을 개선시킬 것입니다.

from Souders blast off 5 in a row
Posted by 행복한고니 트랙백 1 : 댓글 3
IE에 WebKit을 렌더러로 적용한다는 생각을 재미있어하는 사람들이 있습니다. 아마도 다음과 같은 부분때문에 이런 생각을 하게 된 것 같습니다.
호주 시드니에서 열린 개발자 컨퍼런스 연설에서, Microsoft 사의 CEO인 스티브 발머는 자사의 브라우저에서 WebKit을 렌더링 엔진으로 사용하게되면 "재밌을 것"이라고 하고, "검토하고 있을지도 모르죠"라고 덧붙였습니다.
재미있지 않습니까? 이것은 지난주에 우리가 PDC에서 말한 것과는 맞지 않지만요. 한 세션에서 우리는 IE8과 Office가 같은 렌더러를 공유한다는 것을 보았었습니다. 그것이나 그것으로 인해 재미있는 웹 상의 쇼케이스 오피스에 아주 재미있는 UI가 가능해질 것을 생각해보면 재미있습니다.

Microsoft와 Apple이 같은 오픈소스 코드 기반으로 작업을 한다고? 생각해보세요! 전 별로 믿음이 안가네요.

from Adopting WebKit in IE?
Posted by 행복한고니 트랙백 0 : 댓글 1

IE 8 Beta 2 Ajax 기능

2008.10.08 08:54 from [IT] Web Tech
Sunava Dutta씨가 XDR, XDM/postMessage, DOM 스토리지, 오프라인 검출 등의 Ajax 개발자를 위한 IE 8 beta 2의 확장 기능에 대해서 상세히 기술하셨습니다.

XDomainRequest(XDR)
이것은 클라이언트 사이드에서 크로스 도메인 호출을 보안성있고 쉽게 호출할 수 있도록 작성된 객체입니다. 의도하지 않은 크로스 도메인 접근을 줄이기 위해 이 객체는 클라이언트 스크립트와 서버로부터 크로스 도메인 호출에 대한 명시적인 허용를 요구합니다. 아울러, 사이트가 매시업을 위해  서드 파티의 스크립트를 직접 병합하는 위험한 방법에 대한 필요성을 감소시킵니다. 이런 방법은 서드파티에서 전체 DOM에 접근할 수 있기에 위험합니다. 이 모든 것들은 개선된 클라이언트 사이드 성능과 낮아진 서버 유지 비용으로 인해 프록시를 위한 서버군이 필요하지 않은 덕분에 가능했습니다.

Beta1 기간 동안에는 크로스 사이트 XMLHttpRequest와 Acesss Control 프레임웍을 사용하는 서드 파티 데이터의 크로스 도메인 접근과 관련한 많은 보안 정책들이 있었습니다. Beta1 때부터, 우리는 서버 사이드의 경험과 W3C의 Access Control 프레임웍의 보안을 개선하기 위해 다른 브라우저와 W3C 대면 회의의 참가자들과 함께 일할 기회를 가지게 되었습니다. 그 결과, 우리는 XDR을 클라이언트 상의 단순한 공용 서드파티 데이터 익명 요청에 대해 Access Control 영역의 문법과 지시문을 가진 명시적인 규약을 가지도록 업데이트 할 수 있었습니다(Access Control Process Model의 섹션 5.1.3).

Beta1의 XDR 업데이트로 인해 IE 8은 요청자의 직렬화된 출처값을 Origin 헤더로 전송하는 것으로 것으로 도메인의 서버로부터 데이터를 요청할 수 있게 되었습니다. IE8 Beta2 는 Beta1의 XDomainRequestAllowed:1 대신 Access-Control-Allow-Origin: *을 서버 응답으로 돌려받게 될 것입니다. 그 외 사항으로는 open 메소드에서의 상대 경로 지원과 HTTP와 HTTPS 로의 접근 제한이 있습니다.

Cross-document Messaging(XDM)
크로스 문서 메시징제가 이전에 블로깅했던 또 다른 강력한 크로스 도메인 기능입니다. 이 기능은 원격 웹 서비스에 백엔드 요청을 만드는 것보다는 사이트가 IFrame 기반으로 된 써드파티 "가젯"이나 컴포넌트가 동일출처정책(same site origin policy)을 불안전하게 위배하지 않고도 부모 문서와 직접 통신할 수 있도록 하는 것에 목적이 있습니다. 이것은 개발자들이 브라우저간에 서로 다른 방법에 의존하고 원하지 않는 부작용에 괴로워하지 않아도 되도록 함으로써 성능을 개선하고 신뢰성을 높이는 등의 장점이 있습니다. 이 기술은 또한 여러분의 페이지에서 서드 파티 스크립트를 포함할 필요가 없도록 만들어 민감한 데이터(소셜 네트웍 프로필 정보)가 여러분의 동의없이 서드 파티로 새나가는 것과 같은 잠재적인 정보 유출 취약성을 감소시킵니다.

Beta2 업데이트에서 onmessage 핸들러는 업데이트된 HTML 5.0 초안에 잘 맞도록 document 객체에서 window 객체로 옮겨졌습니다.
window.attachEvent("onmessage", HandleMessage);
또한 "scheme" + "호스트" + "기본이 아닌 포트" 의 직렬화된 형태인 e.URIe.origin으로 바꾸었습니다. 이는 수신측에서 허용 여부를 결정하는데 필요하지도 않는 민감할 수도 있는 정보를 출처 사이트로부터 URI를 통해  나르는 것보다 더 안전합니다.
if (e.origin == 'http://www.contoso.com')
{
    // 메시지 텍스트 처리
}
끝으로, HTML 5.0 초안에서 postMessage 메소드에서 targetOrigin 파라미터가 이전과 달리 필수 파라미터로 변경되었습니다. 이는 출처 <URL>이나 와일드카드 <*>를 지정함으로써 메시지의 목적지를 명시적으로 표시하도록 하는 것으로 개발자들이 에러를 덜 내도록 했습니다.
frameOther.postMessage("This is a message", "http://example.com");

DOM Storage
현재, 웹 페이지는 로컬 머신에 데이터를 저장하기 위해 document.cookie 속성을 사용하고 있습니다. 쿠키는 사이트가 도메인당 50개의 키/값의 쌍을 저장하지 못한다는 용량의 한계가 있습니다. 게다가, 쿠키 프로그래밍 모델은 귀찮고 데이터를 얻기 위해 쿠키 문자열을 파싱해야 합니다. 쿠키가 요청 헤더에 최대 4KB의 데이터를 함께 보내 서버로 클라이언트 상의 변화나 변동사항을 알려주는 것에 유용하긴 하지만, IE8은 클라이언트 상의 데이터를 영구적으로 유지할 때와 다른 탭에서 세션을 유지할 때를 대비한 보다 나은 대안을 제시합니다. W3C의 HTML 5 DOM 스토리지 객체가 그것으로, 키/값 쌍의 문자열 데이터를 위한 훨씬 간단한 전역과 세션 저장 모델을제공합니다. 사이트는 탭 또는 사이트가 살아있는 동안 혹은 사용자가 데이터를 제거할 때까지 데이터를 저장할 수 있습니다.

Beta2 업데이트에서는 영구 globalStorage 속성의 이름이 localStorage로 바뀌고, localStorage를 사용할 때 도메인 이름을 지정하지 않아도 되도록 했습니다.
// 키-값 쌍 저장.
localStorage.setItem("이름", "Sunava");
또한 저장소가 변경되었을 때 반환되는 업데이트된 onstorage HTML 5.0 이벤트를 개선했습니다. 지금은 로컬 저장소가 변경되면 URI를 반환하며 따라서 페이지의 핸들러는 저장 공간에 누가 마지막 트랜잭션을 보냈는지를 알 수 있고, 출처 창에 원본을 제공할 수도 있습니다. 더 좋은 소식은, HTML 5.0 Working Group이 우리가 Beta 1에 포함시켰던 clear 메소드를 초안에 포함시켰다는 것입니다. 이는 스크립트가 모든 키에 대해 반복하지 않고도 저장소의 접근할 수 있는 모든 데이터를 삭제할 수 있도록 합니다.

Connectivity Event
navigator.onLine 속성과 online/offline 이벤트는 현재 Windows XP/Vista에서 동작하고 있습니다. Windows XP의 접속 알림이 Windows Vista만큼 진보되어있지 않아서 이를 가능하게 하는 것이 쉬운 일은 아니었습니다. 즉, 이것은 우리가 OS 차이에 대해 걱정할 필요가 없다고 믿는 개발자들에게 많은 이점이 될 것입니다. 접속 이벤트의 값은 네트웍이 불가능한 경우에 데이터를 캐시하도록 localstorage와 연동해 사용될 때 매력적입니다.

XMLHttpRequest
IE8에서의 XDomainRequest 객체 도입을 했다고 해서 같은 도메인 상의 통신에 계속 사용될 객체인 XMLHttpRequest의 개선과 조정에 대한 우리의 관심이 사라진 것은 아닙니다. Beta1 이전의 에너지는 신뢰성을 위해 몇몇 버그를 수정하고, 초안 명세와 우리의 규약을 개선하고 명확하게 하기 위해 Web Apps Working Group과 작업하는 것에 집중되어 있었습니다. Beta1에서 개발자들의 편의를 위해 도입된 timeout 메소드는 현재 XMLHttpRequest 스펙에 적용되어 있습니다.
// Sets timeout after open to two seconds.
xhr.timeout = 2000;

ToStaticHTML, to JSON, and fromJSON
XDomainRequet나 Cross-document Messaging을 이용해 서드 파티로부터 받은 문자열로 무엇을 하시겠습니까? 오늘날 스크립트 인젝션과 크로스 사이트 스크립팅(Cross-site Scripting : XSS) 공격이 증가함에 따라 이들을 안전한 파서를 통해서 받는 방법이 환영받고 있습니다. Erix Lawrence씨가 IE 8 보안을 위한 Comprehensive Protection이라는 글에서 기술했듯이, toStaticHTML은 실행가능할 수 있는 컨텐트를 제거함으로써 문자열을 무해하게 만드는 강력한 방법을 제공합니다.
// Calling:
window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");

// will return:
This is some <b>HTML</b> with embedded script following...!
추가로, IE8 Beta2의 toJSON과 fromJSON 메소드는 네이티브가 아닌 JavaScript 시리얼라이저와 디시리얼라이저에 비해 개선된 성능을 제공합니다. 구현체는 Douglas Crockford씨의 json2.js API를 사용한 네이티브 JSON 핸들링에 대한 ECMAScript 3.1 제안에 기반하고 있습니다. 네이티브라는 성능상의 이점외에도 JSON 파서는 eval() 메소드의 안전한 대안을 제공합니다. 이 메소드는 JSON 객체를 되살리는 일반적이고도 위험한 방법이어서, 임의의 스크립트 함수가 실행되도록 할 수 있었습니다.
From IE 8 beta 2 Ajax features

'[IT] Web Tech' 카테고리의 다른 글

alert()에게 작별을  (3) 2008.10.17
웹 에디터 비교  (4) 2008.10.14
iPhone in Action 일부 챕터 다운로드  (0) 2008.10.10
Pyjamas: Python을 위한 GWT  (0) 2008.10.08
IE 8 Beta 2 Ajax 기능  (0) 2008.10.08
JavaScript로 만든 팩맨  (0) 2008.09.20
iPhone에서도 SVG를 사용할 수 있습니다  (0) 2008.09.19
리눅스에서도 AIR를!!  (0) 2008.09.18
iPhone Web App: Spin the Bottle  (0) 2008.09.18
Posted by 행복한고니 트랙백 0 : 댓글 0
Microsoft의 Sameer Chabungbam씨가 아래 기능을 포함하고 있는 새로운 JScript 프로파일러에 대한 글을 작성하셨습니다:
  • JScript 함수의 성능 데이터를 두가지 방법으로 제공
    • 함수 View  - 모든 함수의 비계층적 목록
    • 호출 트리 View - 호출 흐름에 기반한 함수의 계층적 목록
  • 데이터를 파일로 내보내는 기능 지원
  • 익명 함수를 위해 추측된 이름 제공
  • 내장 JScript 함수 프로파일링
  • 다중 프로파일 보고서 지원
  • 페이지 탐색과 리프레시에 걸친 프로파일링 지원
사용자 삽입 이미지

한편 Eric Pascarello씨는 새로운 도구를 찾아  구글 크롬 디버거에 대한 자신의 경험을 글로 작성했습니다. 그는 다양한 명령어와 중단점 기능에 대해 상세히 기술했습니다.

from New Profilers and Debuggers in Google Chrome and IE
Posted by 행복한고니 트랙백 0 : 댓글 0

Micah Tischler씨는 IE 6에서 투명 PNG를 지원하는 너무 많은 방법에 짜증이 났습니다. 그래서 투명 PNG 이미지를 위한 진정한 배경 이미지 반복과 풀 포지셔닝을 지능적으로 제공하는 mtjs_iepnghandler를 계속 작업해왔습니다.

이 스크립트에서 빈칸 공백 GIF가 있든 그렇지 않든 이미지 태그가 지원되며, 배경이미지에서도 PNG를 이용해 반복이나 위치 정의가 가능해졌습니다. 이미지들이 컨텐트 엘리먼트보다 작은 경우에도 말입니다. 또한, 반복 기능은 대충 아무렇게나 늘려놓은 것이 아닌 진정한 반복기능을 제공합니다.

mtjs_iepnghandler.js는 DOM을 다루며, PNG가 있는 곳을 조정합니다. 이 방법은 PNG가 이미지에서 사용중인지 배경이미지로 사용중인지에 따라 달라집니다. 배경이미지에 사용되고 있다면 반복되거나 위치를 설정했을 것입니다. 이 스크립트는 또한 반복 기능을 구현할 방법에 대해 똑똑한 결정을 내리기 위해 PNG의 치수를 계산합니다. 기억해야할 것은, mtjs_csswalker_iepnghandler.js와 마찬가지로 이 스크립트도 그냥 놓기만 하면 되고, IE5-6 이외의 브라우저에서는 아무런 동작도 하지않는 것입니다.

Micah씨는 끝으로 자신의 방법과 다른 것들을 비교하며 글을 마쳤습니다.

from mtjs_iepnghandler: more PNG support for IE 6
TAG IE, png
Posted by 행복한고니 트랙백 0 : 댓글 3
Firefox3 정식 공개이벤트 덕분에 다른 브라우저 소식은 묻힌 것 같습니다. PPK씨가 몇가지 소식을 쓰셨네요.

IE

새로 릴리스 된 것은 없지만 지난 2주간 중요한 질문에 대한 답변이 달렸습니다. IE8b2이 8월에 출시된다라는 것과 새로운 IE=EmulateIE7이 <meta> 로 변경할 수 있도록 추가된 것입니다.

Firefox

Firefox 3 최종판이 공개되었습니다.

추가로, Firefox 3.1 알파 (FTP)가 다운로드 가능해졌고, 이 버전에서는 모든 CSS3 셀렉터에 대한 지원이 추가되었다고 합니다.

Safari

Apple에서 Apple Developer Connection을 통해 Safari 4 개발자 프리뷰를 공개한 것 같습니다. 하지만, 실제 다운로드 링크는 어디있는지 모르겠습니다. 애플에서는 언급도 없군요.

다운로드 경로를 알게되면, 코멘트를 남겨주셨으면 합니다.

Opera

예상했던 대로, Opera 9.5 버전이 릴리스되었습니다; 보다 자세한 정보는 이 기사를 참고하시기 바랍니다.


from Browser News: IE, FF, Safari, and Opera
Posted by 행복한고니 트랙백 0 : 댓글 0
IE팀이 IE 8의 IE=EmulateIE7 이라는 글을 통해 X-UA-Compatible 이라는 새로 작성한 헤더에 대해 말했습니다.

우리는 이미 "IE7 표준 모드"로 페이지를 표시하도록 하는 IE=7 이 있습니다. 이것은 해당 경로에 있는 모든 페이지에 quirks와 표준 모드를 강제하는 것이어서 사람들이 일부만 non-quirks로 사용할 수 있는 방법을 문의했었습니다. 그래서 새로운 옵션이 만들어진 것이죠:
우리가 받은 IE8 Beta 1에 대한 피드백에 대한 응답으로, 우리는 이 문제를 처리하기 위해  "IE-EmulateIE7" 태그를 도입했습니다. EmulateIE7은 IE8에 표준 DOCTYPEs을 IE7 모드에서 보여주고, Quirks DOCTYPE은 Quirks 모드에서 보여달라고 요구합니다. 우리는 이것이 대부분의 경우에 선호하는 IE7 표준모드가 될 것이라고 생각합니다. IE=EmulateIE7의 지원은 IE8 Beta 1에 대한 6월 IE 보안 패치의 일부가 되었습니다. 이 업데이트를 설치하시면 사이트를 정상적으로 보이게 하기 위한 EmulateIE7 태그를 적용했는지 검증할 수 있습니다.

HTTP 헤더를 구현하는 것은 컨텐트를 업데이트 하지 않고 사이트의 대부분을 IE7에서 했던 것과 같이 보여주고 싶을 때 유용합니다. 이 헤더를 포함하면 사이트에 속한 어떠한 Quirks 모드 페이지라도 지켜줍니다.

각각의 페이지에 메타 태그를 사용하는 것은 발행자가 특정 페이지만 IE7에서와 같이 렌더링하고 싶을 때 유용합니다.

X-UA-Compatible 태그와 헤더는 현재 있는 DOCTYPE을 덮어씁니다. 또한, 페이지에 의해 정의된 모드는 HTTP 헤더보다 우선합니다. 예를 들어, EmulateIE7 HTTP 헤더를 사이트에 추가하고, IE8 모드로 보여주고 싶은 특정 페이지를 설정할 수도 있습니다(content="IE8"이라는 메타태그 사용).

IE=EmulateIE7 호환 태그를 사용하는 것은 사이트의 컨텐트를 보다 표준 호환적인 컨텐트로 업데이트하기 전까지 사용자의 현재 경험을 지속할 수 있는 가장 간단한 방법입니다. 비록 이 태그를 추가하는 것이 대부분의 표현 이슈를 방지할 수 있을 지는 모르나 사이트에서 IE8인지 올바르게 탐지하는 것도 필요해지게 됩니다. IE8 문서 호환성과 브라우저 탐지에 대해 보다 많은 정보는 IE 호환성 센터를 방문해보시기 바랍니다.

from X-UA-Compatible: IE=EmulateIE7
Posted by 행복한고니 트랙백 0 : 댓글 0
사용자 삽입 이미지
Tom Trenka 씨가 문자열 성능에 관한 그의 최근 글IE에 관해 더 깊이 탐구Array.join의 신화를 무너뜨리는 글을 썼습니다.

Tom씨는 여러 버전의 IE와 다양한 크기의 데이터를 사용해 수많은 테스트를 했습니다.

결론
IE7에서는 성능 개선을 위해 우선 해야할 것으로, 우리는 더이상 대규모 문자열 연산을 다룰 때의 대체 방안 사용에 대해 고려할 필요가 없습니다; 대체 상황에서 Array.join을 사용하는 것은 같은 상황에서 += 를 사용하는 것에 비해 두드러진 이득을 주지는 못합니다. 게다가 IE6에서의 차이는 특정 버전을 위해 따로 코드를 작성하지 않아도 될만큼 미미한 것입니다.

이러한 종류의 연산에서 문자열 대신 배열 사용을 고려해야할 유일한 때는 추가할 조각들이 매우 크다고(65546 bytes 이상) 느껴질 경우입니다; 이런 일을 하는 것은 Dan Pupius씨가 객체 할당과 JScript 가비지 컬렉터에 대한 그의 분석에서 말한 바와 같은 GC 문제를 초래합니다.

그로부터, 우리는 Internet Explorer에서의 프로그래밍 기술을 발전시킬 수 있었고, 단순한 반복과 한번에 한 곳에 밀어넣는 일보다는 가능한 많은 인자를 가진 Builder.append라 부르는게 더 나을 것 같습니다.

또한 작게 시작하는 것이 좋습니다; 문자열 연산을 구조화 하세요 그러면 대규모 문자열 연산은 최소화 될 것입니다. 이 경우에, 문자열 세트를 조립하기 위해 임시 버퍼를 사용하고 이들을 보다 매우 큰 문자열에 덧붙이는 것이 작은 조각들을 늘 큰 문자열에 붙이는 것보다 더 좋습니다.

그리고 늘 그렇듯이, 반복 규모의 최소화는 JScript의 성능을 향상시키는데 도움이 될 것입니다.


더 자세한 결과를 살펴보실 수도 있습니다.

from String Performance in IE: Array.join vs += continued
Posted by 행복한고니 트랙백 0 : 댓글 0
Hendger Wang씨는 최근 IE6의 메모리 문제에 대한 해결책을 찾기 위해 수많은 중국어 블로그를 탐색했습니다. 그의 눈길을 끌었던 것 중 하나는 try ... fianlly를 사용하여 메모리 누수를 멈추기 위해 객체를 null로 바꾼 매우 재치있는 방법이었습니다. 아래가 메모리 누수가 일어나는 코드입니다.
[code:js]
function createButton() {
      var obj = document.createElement("button");
      obj.innerHTML = "click me";
      obj.onclick = function() {
        //handle onclick
      }
      obj.onmouseover = function() {
        //handle onmouseover
      }
      return obj;//return a object which has memory leak problem in IE6
}

var dButton = document.getElementsById("d1").appendChild(createButton());
//skipped....

하지만 다음과 같은 코드를 사용하면 방지할 수 있습니다.
[code:js]
function createButton() {
      var obj = document.createElement("button");
      obj.innerHTML = "click me";
      obj.onclick = function() {
        //handle onclick
      }
      obj.onmouseover = function() {
        //handle onmouseover
      }
      //this helps to fix the memory leak issue
      try {
        return obj;
 
      } finally {
        obj = null;
      }
    }
    var dButton = document.getElementsById("d1").appendChild(createButton());
}

더 많은 데모, 개념을 증명하는 예제와 "finally"에 대한 설명은 Hedger씨의 블로그에 그가 작성한 글에 있습니다.
Finally, the alternative fix for IE6's memory leak is available

from Is "finally" the anwer to all IE6 memory leak issues?
Posted by 행복한고니 트랙백 0 : 댓글 0
IE 8 이 8월에 나올 예정이라고 빌 게이츠가 TechEd에서 개발자들을 향한 자신의 마지막 연설에서 밝혔습니다. 여러분이 어떻게 생각하든 그는 소프트웨어 산업의 창궐을 도운 하나의 아이콘입니다. 빌 게이츠와 스티브 잡스가 아니면 누가 그럴 수 있었겠습니까? :)

다시 IE 얘기로 가서 그는 Internet Explorer와 IE 8이 두 달간 어떻게 업데이트 될 것인지 말했습니다:
빌 게이츠는 또한 몇년에 걸쳐 회사의 자산이자 재앙이 되어버린 Microsoft의 중요한 웹 기술인 Internet Explorer(이하 IE)에 대해 강조했습니다. 비록 그것이 Microsoft로 하여금 Web 브라우징 기술에서 지배적인 지위를 가지도록 해주었지만, 또한 오늘날 Microsoft에 가장 많이 나타나는 반독점법 불행을 유발했습니다. IE는 또한 지난 몇년간 Mozilla Firefox라는 오픈소스 브라우저가 추종자들을 모으며 Microsoft가 자신들의 제품(=IE)을 발전시키고 보다 혁신적으로 만들도록 압박해옴에 따라 타격을 받은 바 있습니다.

빌 게이츠는 IE의 차기 버전, IE 8 beta 2가 8월에 출시될 것이라고 밝혔습니다. 그는 또한 그가 Microsoft에서 보낸 세월동안 흥미있어 했던 것들에 대해 말했습니다 -- 인간과 컴퓨터가 그들 각각이 자신들과 상호작용하는 것과 유사한 방식으로 상호작용할 수 있는 자연스러운 휴먼 인터페이스 기술입니다. 지난주에, Microsoft 는 Windows의 차기 버전인 Windows 7이 그가 연설에서 언급한 것과 같이 터치스크린 기술을 포함하게 될 것이라고 밝혔습니다.
IE 8이 멋진 모습으로 출시되었으면 좋겠습니다.

from IE 8 beta 2 coming in August on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0
IE를 버전별로 테스트하는 것은 짜증나고 힘든 일입니다. Microsoft가 Windows에 여러 버전의 브라우저를 사용할 수 없도록 했기 때문이죠. 물론, 이런 제한을 우회할 해결책이야 찾으면 있습니다만, 경험상 늘 예기치 않은 결과를 가져오고 불안정하거나 VM을 실행해야합니다. 좋진 않죠.

IE 디버거 중 하나인 DebugBar를 만드신 Jean-Fabice RABAUTE 씨가, IETester 라 부르는 괜찮은 해결책을 제시했습니다. 이것을 이용하면 Vista와 XP에서의 IE8 beta 1, IE7, IE6, IE5.5의 렌더링과 JavaScript 엔진을 한 프로세스 안에서 테스트할 수 있도록 해줍니다.
사용자 삽입 이미지
동영상도 함께 보세요.

ScreenCast IETester from WebInventif.fr on Vimeo.

from Testing IE Versions Just Got a Little Easier on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

IEBlog에 IE 8 이 postMessage지원한다는 글이 올라왔습니다. 멋진 소식이죠.

지원 사항과 사용 사례에 대한 것은 MSDN 기사를 보라고 링크해두었더군요.

Jeff Walden씨는 "현재의 IE 8 베타가 구현한 인터페이스는 하위 호환성을 보장하지 못하는 방법으로 여러 버전에 걸쳐 HTML5 스펙에 뒤쳐져 있습니다, 따라서 이를 경험해보고자 하신다면, 여러분이 작업한 것이 앞으로 나올 IE8에서 깨질 수도 있음에 주의하십시오."라고 주의시켰으며 차이점에 대해 상세히 설명했습니다.

현재의 스펙을 구현한 것은 Firefox 3 RC 1 와 Webkit Nightly 밖에 없는 것 같습니다.

from IE8 and Cross Domain Messaging on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

IEBlog에서 IE와 XP SP3와 같은 제목을 보았다면 "아, IE6 사용자들도 업그레이드 되겠네"라고 바랬을 것입니다. IE 6의 사용률이 최소가 되기까지 얼마나 힘들었습니까?

안타깝게도, 또 한번 실망하고 말았습니다:

XPSP3는 IE6를 계속 탑재하고 있으며, IE6에 대한 최신 보안 업데이트들을 포함하고 있습니다.  여전히 Internet Explorer 6를 사용하고 계신다면, Windows Update 사이트를 통해 중요 업데이트로 XPSP3를 제공받을 것입니다. XPSP3를 안전하게 설치하실 수 있으며, 홈페이지나 즐겨찾기 등의 개인설정을 그대로 유지한채로 IE 6를 업데이트 하실 수 있습니다.


from IE and Windows XP Service Pack 3 ... still IE6 on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 2

Kris Zyp 씨가 미래를 대비한 100줄짜리 Ajax wrapper를 만들었습니다:

IE8의 새로운 기능인 XDocmainRequest는, 크로스 사이트 요청을 위해 추가된 새로운 API로서, W3C의 크로스-사이트 접근 제안 대신 사용할 수 있습니다. 그냥 재미삼아, 다음 세대 웹 개발자들을 위해 고전적인 Ajax request wrapper 함수는 어떻게 보일런지 보여주고자 했다. 그냥 XMLHttpRequest를 몇번 호출하는 것이 너무 쉬우니까 우리는 대신 이렇게 했다:

[code:JScript]
function doRequest(method,url,async,onLoad,onProgress) {
    var xhr;
    if ((onProgress || isXDomainUrl(url)) && window.XDomainRequest) {
        // if it is x-domain or streaming/incremental updates are needed we will use IE's XDomainRequest for IE
        // streaming/interactive mode is broken in IE's XHR, but for some reason works in XDR (with onprogress), so we will
        // need to use XDR if incremental updates are necessary
        // see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=334813
         if (url.match(/^https:/) && !onProgress) {
            // XDR doesn’t work for secure https communication
            // see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=333380
            loadUsingScriptTag(url); // script tag insertion can be more secure than XDR
                // in some situations because it supports https
            return;
    }
        xhr = new XDomainRequest;
        // relative paths don’t work in XDomainRequest, see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=333275
    if (!url.match(/^http:/)) { // test to see if it is an absolute url
            url = absoluteUrl(location.href,url); // must have a function to turn it into an absolute url
    }
    if (!(method == “GET” || method == “POST”)) {
        // XDomainRequest does not support methods besides GET and POST
        // see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=334809
        // We will try to add the method as a parameter and hope the server will understand… good luck :/
        url += “&method=” + method;
        method = “POST”;
    }
    function xdrLoad() {
       if (xhr.contentType.match(/\/xml/)){
        // there is no responseXML in XDomainRequest, so we have to create it manually
        var dom = new ActiveXObject(”Microsoft.XMLDOM”);
        dom.async = false;
        dom.loadXML(xhr.responseText,200);
        onLoad(dom);
       }
       else {
           onLoad(xhr.responseText,200); // we will assume that the status code is 200, XDomainRequest rejects all other successful status codes
        // see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=334804
       }
    }
    if (async === false) {
        // XDomainRequest does not support synchronous requests
        // see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=336031
        // so we will try to block execution on our own (which is not really possible in any reasonable manner)
        var loaded;
        xhr.onload = function() {
        loaded = true;
        xdrLoad();
        }
            xhr.open(method,url);
        xhr.send(null);
        while(!loaded) { // try to block until the response is received
        // I am sure the user won’t mind just clicking OK so we can block execution
        alert(”Waiting for the response, please click OK because it probably is here now”);
        }
         return;
    }
    else {    // do an asynchronous request with XDomainRequest
            xhr.onload = xdrLoad;
            xhr.open(method,url);
            xhr.onprogress = onProgress;
    }
    }
    // we will mercifully skip all the branches for ActiveXObject(”Microsoft.XMLHTTP”) to accomodate IE6 and lower
    else {
        xhr = new XMLHttpRequest; // use the standard XHR for same origin and browsers that implement cross-site
            // W3C requests and streaming
        xhr.open(method,url,async);
        xhr.onreadystatechange = function() {
            if (xhr.readyState == 3) // interactive mode
                onProgress(xhr.responseText);
            if (xhr.readyState == 4) // finished
                onLoad(xhr.responseText,xhr.status);
        }
    }
    xhr.send(null); // finally send the request whether it be XDR or XHR

    // and supporting functions
    function absoluteUrl : function(baseUrl, relativeUrl) {
        // This takes a base url and a relative url and resolves the target url.
        // For example:
        // resolveUrl(”http://www.domain.com/path1/path2″,”../path3″) ->”http://www.domain.com/path1/path3″
        //
        if (relativeUrl.match(/\w+:\/\//))
            return relativeUrl;
        if (relativeUrl.charAt(0)==’/') {
            baseUrl = baseUrl.match(/.*\/\/[^\/]+/)
            return (baseUrl ? baseUrl[0] : ”) + relativeUrl;
        }
            //TODO: handle protocol relative urls:  ://www.domain.com
        baseUrl = baseUrl.substring(0,baseUrl.length - baseUrl.match(/[^\/]*$/)[0].length);// clean off the trailing path
        if (relativeUrl == ‘.’)
            return baseUrl;
        while (relativeUrl.substring(0,3) == ‘../’) {
            baseUrl = baseUrl.substring(0,baseUrl.length - baseUrl.match(/[^\/]*\/$/)[0].length);
            relativeUrl = relativeUrl.substring(3);
        }
        return baseUrl + relativeUrl;
    }
    function loadUsingScriptTag(url) {
        … do JSONP here if we want
    }

}
음... IE팀은 제발 표준을 좀 지켜줬으면!

from 100Line Ajax Wrapper on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0
from Are you sure your unload handler is firing in IE? on Ajaxian

Johan Sörlin씨가 IE에서 때때로 unload 이벤트가 일어나지 않는다는 사실을 발견했습니다:

우리는 최근에 특정 웹사이트에서 unload 이벤트가 일어나지 않는 IE의 심각한 버그를 발견했습니다. 버그를 추적한 결과, unload 이벤트는 페이지가 미처 다 로딩되기 전에 우리가 다른 페이지로 이동했기 때문에 일어나지 않는 거였습니다.

이 문제는 꽤 중요한데, unload 이벤트가 IE의 순환 참조 메모리 누수를 방지하기 위해서 일반적으로 사용되기 때문입니다. 따라서, 만약 페이지의 컨텐트 로딩이 완료되기 전에 페이지를 벗어난다면 이 버그는 IE에서 unload 이벤트에 의존하는 모든 Ajax 라이브러리/프레임웍이 제대로 동작하지 않도록 만들 것입니다.

버그 샘플이 있습니다, 페이지를 IE에서 실행하고 페이지에 있는 과정을 따라 해보세요.

그가 작업한 것입니다:
function fixUnload() {
        // Is there things still loading, then fake the unload event
        if (document.readyState == 'interactive') {
                function stop() {
                        // Prevent memory leak
                        document.detachEvent('onstop', stop);
                        // Call unload handler
                        unload();
                };
                // Fire unload when the currently loading page is stopped
                document.attachEvent('onstop', stop);
                // Remove onstop listener after a while to prevent the unload function
                // to execute if the user presses cancel in an onbeforeunload
                // confirm dialog and then presses the stop button in the browser
                window.setTimeout(function() {
                        document.detachEvent('onstop', stop);
                }, 0);
        }
};

function unload() {
        alert('Unload event occured.');
};

window.attachEvent('onunload', unload);
window.attachEvent('onbeforeunload', fixUnload);

또 다른 IE 소식입니다. IE6에서 문제가 되므로, CSS 클래스 이름에 (유효한) _ 문자를 사용하면 안되다는 것을 명심하세요.
Posted by 행복한고니 트랙백 0 : 댓글 2

from IE 8 strict mode doesn’t allow for CSS opacity? on Ajaxian

Howard Rauscher 씨가 opacity와 IE 8 strict 모드를 함께 사용할 수 없다고 말한 IE 8 ticket 을 알려왔다고 합니다:

Description

IE8 Strict 모드는 필터를 뺐습니다: IE8 이전 버전에서 비록 CSS3의 opacity는 구현되지 않았지만 사용자는 필터를 통해 CSS에서 alpha(opacity=xx)처럼 opacity를 설정할 수 있었습니다. 저는 opacity가 아직 최종확정되지 않은 CSS3 스펙의 일부라고 알고 있습니다. 그런데, css 요소에서 opacity를 바꾸는 것이 더이상 가능하지 않는데도 어처구니 없는 기능상 퇴보를 한겁니다(IE 5.5, IE6.0, IE7.0, Mozilla Firefox, Apple Safari 등에선 가능했습니다).

Comments

이것이 그런 식으로 설계되었다는 사실은 지난 10여년의 세월을 통틀어 IE8이 최고 strict한 모드에서 opacity를 지원하지 않은 유일한 브라우저가 될 거라는 것을 짐작케 합니다. 어처구니가 없죠. 저도 표준 준수에 대한 바람은 이해합니다만, CSS3의 opacity 태그를 인식하도록 구현하는 게 얼마나 어렵길래요(filter를 사용한다 해도 그건 나중에 호환성을 위해 남을건데).

어떤 점에서 표준은 사용성을 저해할 수 밖에 없습니다. Mozilla, Opera, Apple은 모두 아직까지 CSS2의 공식 스펙이 아닌 태그라도 사용할 수 있어야 한다는 것을 알아차렸습니다. IE8의 표준 준수 모드에서 주요 기능이 빠져있다면 누가 그것을 쓰겠습니까. 설령 표준을 준수한다 해도 말이죠.

당신들은 표준을 준수하지만 표준 준수모드에서 불가능한 기능이 필요한 웹사이트를 보게 될 것입니다. 이런 웹 사이트들은 IE7 모드를 이용해야겠죠. 그리고 IE9이 출시되면 당신은 또 다시 모든 표준 이슈를 처리해야 할 것입니다.

Posted by Ames on 3/17/2008 at 3:59 PM

IE8 걱정됩니다... 불만이 여기저기서 터져 나오네요.
Posted by 행복한고니 트랙백 0 : 댓글 1