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
사용자 삽입 이미지

우리는 간단한 CSS를 통해 크기를 바꾸고, 변형하고, 기울이고, 매트릭스 작업을 할 수 있는 WebKit의 CSS 변형에 대해 얘기한 바 있습니다.

새로운 -moz-transform 덕분에 Mozilla는 진보했고, Keith Schwarz씨는 Firefox에서의 CSS 변형 지원에 대한 글을 작성하셨습니다.
[code:css]
-moz-transform: translate(100px, 200px); /* Move right 100 pixels, down 200 pixels */
-moz-transform: translate(30px); /* Move down and right 30 pixels */
-moz-transform: translate(50%, 50%); /* Move down and right by 50% of the size of the element. */
이 기능은 지정된 오프셋만큼 단순히 엘리먼트를 이동시킵니다. 예를 들어 -moz-transform: translate(100px)가 설정된 텍스트 엘리먼트는 원래의 위치에서 100 픽셀 우측 하단에 나타납니다. 물론, 단순한 변형 이상의 기능들도 있습니다. 예를 들면, 엘리먼트를 지정한 각도의 숫자만큼 회전시키는 회전; 엘리먼트를 각 축의 임의의 선을 기준으로 축소, 확대시키는 스케일; X, Y 축을 따라 기울이는 기울임; 그리고 임의의 매트릭스 변형을 위한 매트릭스 기능 등이 있습니다. 또한 skewx(X축 기울임), skewy(Y축 기울임)과 같이 몇가지 경우에 대해 보다 단순한 문법을 사용할 수 있는 단순한 버전도 있습니다.

CSS변형을 위해 개발자들이 사용한 것이 무엇인지를 보는 것도 재밌을 것입니다. 기능의 대부분들은 플러그인에서 구현될 예정이었지만, 지금은 CSS와 JavaScript에 직접 통합되어 웹 개발자들이 현재의 페이지들을 보다 생생하게 만드는 것에 도움을 줄 것입니다. 우리는 또한 이제 두 개의 구현체가 있게 된 이 속성의 표준화가 빨리 이루어지기를 기대하고 있습니다.

from CSS Transforms: First WebKit, now Gecko too!
Posted by 행복한고니 트랙백 2 : 댓글 0
Sam Allen씨가 시간의 흐름에 따른 브라우저 성능을 측정했습니다. Sam씨는 브라우저 메모리 프로파일을 만들고 결론을 도출했습니다:
이 프로파일들은 유명 브라우저들의 시간에 따른 메모리 동작 상태를 의미합니다. 절대적인 벤치마크 시간을 제공하지는 않습니다. Firefox 3.0은 메모리 관리가 꽤 괜찮았던 Firefox 2보다 메모리 사용량이 확실히 줄어들었습니다. 아래는 결과 요약입니다.

  • Safari 3.1
    Windows용 Safari는 매우 안좋은 메모리 관리를 보여주었습니다.
  • Firefox 3.0
    이 브라우저는 메모리 사용량이 다른 브라우저에 비해서 꽤 적었습니다. 메모리를 시스템에 잘 반환했으며, 전체적인 그래프 선은 거의 평평했습니다(여기서 밝힌 노력 덕분이 아닌가 싶습니다).
  • Flock (Firefox 2.0 기반)
    Flock은 꽤 좋습니다. 이 브라우저와 Firefox 2.0은 많은 문제를 일으키지 않고 장시간 실행되었습니다. 확장기능이 효율성을 다소 떨어뜨릴 수는 있습니다.
  • Opera 9.5
    Opera의 성능은 Firefox 2.0(Flock)만큼 좋습니다. 그리고 굉장히 긴 세션을 사용하는 것 같았습니다.
  • Internet Explorer 8 Beta 1
    IE도 프로파일에서는 꽤 잘해주었습니다. 비록 데이터의 추세가 증가세에 있어 걱정스럽기는 하지만 말입니다. 하지만, 이 브라우저는 보통의 사용량에서 몇 시간 동안 잘 버텨주었습니다.
사용자 삽입 이미지

from Browser Memory Footprints; Watching with real usage
Posted by 행복한고니 트랙백 0 : 댓글 0
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
Mozilla에겐 바쁜 한 주 였습니다. 이번에 그들의 기술을 한번 살펴볼까 합니다.

우선, 새 소식입니다. Firefox 3가 6월 17일에 공개된다고 합니다. 다운로드 관련 이벤트도 진행중이죠.

Stuart Pamenter씨가 글꼴과 텍스트에 대해 자세한 글을 작성하셨습니다.
Mozilla 개발자들이 Cairo를 통합하고 새로운 그래픽 레이어를 처음부터 작성하기로 했을 때, 그들은 브라우저에서 텍스트를 렌더링하는 시스템도 완전히 새로 작업하기로 했습니다.

텍스트는 웹에서 믿을 수 없을만큼 중요한 부분입니다. 그래픽, 오디오, 동영상의 중요성은 커가고 있지만, 우리는 여전히 Web에서의 시간 대부분을 무언가를 읽는데 사용합니다. 웹 브라우저에서 여러분이 읽는 모든 글들은 글꼴을 사용해 렌더링되며, 글꼴은 각각의 문자 형태를 만드는 데 사용하는 글리프glyph 묶음을 포함합니다. 보다 단순한 언어를 위해서 한 글자에 글리프 하나씩 1:1로 매핑합니다. 하지만 보다 복잡한 언어를 위해서는 하나의 글리프가 여러 문자들을 표현하기도 합니다.
Ben씨는 이런 종류의 것들에 엄청난 팬(anal이라 하기도 합니다)입니다. 글꼴과 렌더링은 큰 차이를 만들어냅니다. 그 글은 새로운 Firefox 3 엔진에서는 어떤 일들이 일어나는지에 대해 자세한 설명을 계속했습니다. 커닝, 활자, 힌팅, 폰트 부드럽게하기, 안티-알리아싱 등에 대해 논의했습니다. 이 글을 읽고 난 뒤에 여러분은 아마도 영화 Helvetica를 보고 싶을지도 모릅니다!

이제 모바일 쪽 얘기를 해보겠습니다. Aza Raskin씨가 Fennec을 위해 작성될 새로운 터치 스크린 인터페이스에 대한 컨셉 동영상을 포스팅했습니다. Aza씨는 설계 원칙을 포함해 상당히 많은 양의 자세한 내용을 작성했습니다.
터치 Firefox 모바일(코드네임 Fennec)을 위한 이 컨셉 프로토타입은 터치 스크린을 위해 설계되었습니다. 멀티터치는 왜 안될까요? Firefox는 터치 장치들의 최소 공통 요소에서 실행되어야 하기 때문입니다. 특히 터치가 가능한 인터페이스를 직접 조작하는 것이 중요합니다. 그 생각과 동일선상에서 인터페이스는 손가락으로 작동할 수 있어야 합니다. 입력 장치들을 왔다갔다하는 것은 시간도 들고 짜증나는 일이기 때문에, 사용자들은 스타일러스 혹은 다른 두번째 입력장치로 바꾸지 않아도 되어야 합니다. Firefox는 터치스크린이 아닌 장체이서 작동합니다, 하지만 그 부분은 이 데모의 범위가 아닙니다.

큰 타겟이 좋다 인터페이스를 컨트롤하는 똑같은 손가락 끝은 모바일 터치 스크린 수평/수직 높이/너비의 1/5 에서 1/10 까지의 크기입니다. 다시 말해, 손가락은 두껍습니다: 작은 타겟을 맞추는 것은 팔꿈치로 터치하려는 것과 마찬가지입니다. 모든 액션은 빠르고 쉽고 (최소한) 찍느라 화나는 일이 없을 만큼 충분히 큰 타겟에 의해 표현되어야 합니다.

시선을 잡아끄는 탄성과 물리의 매력 이쁜 애니메이션과 물리 엔진을 만큼 "섹시!"하게 보이는 것도 없습니다. 이런 물리력의 구현은 마케팅 차원에서 어필할 뿐만 아니라, 사용자가 인터페이스의 정신적 모형을 만드는데 도움을 주며 그런 인터페이스에 일관성을 부여합니다. 실제 세상과는 다르게 나타났다가 사라지지 않더라도, 인간은 물체들이 어떻게 움직여서 어디로 가는지를 추적하고 기억하게 되어있습니다. 물론 모든 물리적 상징들을 무턱대고 베낀다면 Microsoft Bob같이 억만금을 들인 참담한 인터페이스가 만들어질테니 상징들을 신중하게 골라야합니다.

타이핑은 어렵다 이는 어디서 무엇을 하든 키 입력을 최소화 할 필요가 있다는 것을 의미합니다.

컨텐트가 왕 제한된 화면 크기에서 모든 픽셀은 중요합니다. 가능한 많은 부분을 항상 제어기능이나 잡동사니가 아닌 컨텐트에 할당해야 합니다.
이제 서버 쪽을 얘기해보자면, Firefox 3를 포함한 Weave status update가 있습니다. 데이터 타입, 북마크 공유, 웹 클라이언트 뷰와 같은 새로운 기능들을 포함하고 있습니다. 보다 자세한 정보를 위해 위키를 확인해보세요.

from Mozilla Week: From Client (Firefox 3) to Server (Weave) to Mobile (Fennec)
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
Kevin Yank씨가 Firefox 3 RC 1 에서 새로워진 기능을 보고, 웹 개발자들이 알아야 할만한 부분을 짚어주셨습니다.

부드러운 하이픈
Firefox 3 의 CSS 개선사항을 보면 부드러운 하이픈soft hyphen이 추가된 것을 보실 수 있습니다. HTML 표준에는 있었으나 그간 브라우저들이 구현하지는 않았던 모양입니다. 이번 Firefox 3의 지원을 시작으로 IE, Safari, Opera 등의 다른 브라우저에서도 지원하게 될 것이라고 합니다. 부드러운 하이픈은 평상시에는 보이지 않지만, 내용이 밀려 내려가야 할 경우에 나타난다고 합니다. 영문을 띄어쓰기 없이 붙여썼을 때 레이아웃이 깨지거나 글이 제대로 보이지 않는 일은 많이들 겪어보셨을텐데, 이 경우에 유용하게 사용할 수 있을 것 같습니다.

실제 동작을 보시겠습니다:
사용자 삽입 이미지

Inline Blocks
이 역시 잘 알려져있지 않지만, 꽤 유용한 기능입니다. 엘리먼트 스타일에 display 타입으로 inline-block 이라는 값을 적용하면 엘리먼트는 span과 같은 inline 엘리먼트처럼 위치를 정합니다. 하지만, 내부의 컨텐트들은 해당 엘리먼트가 block 속성을 가진 것처럼 동작하게 됩니다.

모든 브라우저에서 이것만 제대로 지원된다면 그간 float 으로 삽질했던 일이 훨씬 많이 줄어들게 될 것 같습니다.
[code:js]
<ul class="gallery">
  <li>
    <div class="caption">A short caption</div>
    <div class="thumb"><img src="thumb1.jpg"/></div>
  </li><li>
    <div class="caption">A short caption</div>
    <div class="thumb"><img src="thumb2.jpg"/></div>
  </li><li>
  …
</li></ul>

위 코드는 다음과 같이 표현됩니다.
사용자 삽입 이미지

실제 동작하는 것을 확인해보세요.

from Soft-hyphens and inline-block; Subtleties in Firefox 3 RC 1 on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 2

사용자 삽입 이미지
Nicholas C. Zakas 씨가 자신의 새 책을 위한 예비 작업으로서 주요 4개 브라우저에 대한 브라우저 쿠키 제약을 연구하셨습니다:

제가 발견한 가장 흥미로운 사실은 Safari는 도메인당 설정할 수 있는 쿠키의 갯수가 제한이 없다는 것입니다. 사실, 여러분은 쿠키 헤더가 해석하기엔 너무 커 서버가 에러를 일으킬 수도 있을 만큼의 쿠키를 클라이언트에 설정할 수 있습니다.

그가 발견한 다른 사항은 이렇습니다:

  • Microsoft 는 Internet Explorer 8 의 도메인당 쿠키 제한을 50개까지 늘렸다고 말했지만, 제가 발견한 바로는 IE7 도 도메인당 50개의 쿠키를 허용합니다. 그렇습니다. 이는 출시된 브라우저의 첫번째 버전이 그런 것이 아니라 시스템 패치로 인해 증가한 것입니다. 하지만 여전히, 일반적으로 한계라고 생각하는 20개 보다는 많습니다.
  • Firefox는 도메인당 50개의 쿠키 제한이 있습니다.
  • Opera는 도메인당 30개의 쿠키 제한이 있습니다.
  • Safari/WebKit은 Safari 3.1을 통해 봤을 때 인지할 수 있는 한계가 없는 것 같아 가장 흥미로웠습니다. 제가 10,000개의 쿠키를 설정하고 그 쿠키를 전부 Cookie 헤더에 실어 보내 테스트를 해보았습니다. 문제는 헤더의 크기가 서버가 처리할 수 있는 정도를 넘어버렸다는 것인데, 그래서 서버에서 에러가 발생했습니다.

위에서 보듯이 브라우저의 도메인당 쿠키 제한이 20개라는 널리 알려진 지식은 더이상 바른 지식이 아닙니다. 또다른 재미있는 모순은 너무 많은 쿠키가 설정되면 브라우저가 어떻게 반응하는가에 대한 것입니다. 인식할 수 있는 숫자는 모두 설정할 수 있는 Safari를 제외하면, 두가지 접근 방법이 있습니다:

  1. 최근 최소 사용(LRU) 방법은 쿠키 제한에 도달했을 때, 새로운 쿠키를 위한 공간을 만들기 위해 가장 오래된 쿠키부터 제거합니다. Internet Explorer와 Opera가 이 방식을 사용합니다.
  2. Firefox는 약간 이상합니다: 마지막 쿠키가 항상 저장되어 있음에도 불구하고 무작위로 남겨둘 쿠키를 결정하는 것 같습니다. 일정한 법칙이 전혀 없는 것 같습니다. Firefox에서는 쿠키 제한 이상으로 사용하지 마십시오.

쿠키의 전체 크키는 브라우저마다 매우 다양합니다. 이 부분이 파악하기에 좀 힘들었던 부분입니다. 하지만 제가 테스트한 결과가 있습니다:

  • Firefox와 Safari는 쿠키를 4097 영문자까지 허용합니다. 4096 은 이름, 값, 등호(=)까지 포함한 것입니다.
  • Opera는 쿠키를 4096 영문자까지 허용합니다, 마찬가지로 이름, 값, 등호까지 포함한 것입니다.
  • Internet Explorer는 쿠키를 4095 영문자까지 허용합니다. 이름, 값, 등호까지 포함한 값입니다.
from Browser cookie restriction research 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

자식 선택자child selector는 "table td tr.className"과 같이 노드의 계층 구조를 포함하도록 작성된 CSS 선택자를 말합니다. 이러한 자식 선택자가 그냥 단순하게 클래스 이름만 쓰는 것보다 더 느릴까요?

Jim Barraud씨는 "느리다"라고 했는데, Jim 씨의 글을 읽은 Jon Sykes씨는 아무래도 이를 데이터로 증명해야 마음이 편했나봅니다.

그의 결론을 볼까요?

자식 선택자가 주요한 성능 문제라는 것은 확실합니다.

맞는 말이긴 하지만, 누군가 말한 그대로 믿기보다는 일종의 증명을 하고 싶었습니다. 그래서 지난 이틀간 이 문제를 재연하기 위한 두 가지 접근 방식을 시도해보았습니다.

첫번째는 벤치마킹으로서는 근본적인 문제가 있는 워낙 쓸모없는 아이디어였습니다.

그래서 저는 새로운 접근방식을 취했습니다. 이 방식은 몇몇 유효하고 꽤 흥미로운 결과를 반환하는 듯 보였습니다. 특히, Safari 와 Firefox 3와 관련해 이들이 자식 선택자와 성능에 어떻게 반응하는지에 대해서 말이죠.

테스트 결과는 IE6, IE7, Safari3 에서 직접적인 클래스 선언보다 자식 선택자를 사용하는 것이 느리다고 말합니다. Safari3가 자식 선택자에 가장 많은 영향을 받았습니다. Firefox는 약간의 영향을, 그리고 Firefox3는 전혀 영향을 받지 않는 것처럼 보였습니다.

이 실험은 매우 극단적입니다. 보통은 한 페이지에 20,000 개나 되는 클래스 선언을 정의하거나 그들 모두가 4단계의 자식 선택자일리는 없습니다.

사용자 삽입 이미지

(주 : child selector, child 셀렉터, 자식 셀렉터, 자식 선택자 등의 많은 명칭을 놓고 고민했습니다. 아직 널리 쓰이는 말이 없기에 이왕이면 우리말로 바꾸려는 노력이 필요하지 않을까 생각해서 자식 선택자라고 번역했습니다. 똑같은 의미의 '자식'을 의미하는 자식 노드라는 말이 이미 쓰이고 있기 때문에 그렇게 써도 괜찮지 않을까라고 생각해서 선택한 어휘입니다만 어색하기는 하네요 ^^a)

from CSS Child Selector Performance on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 4
URL 형태의 여러 제안 중 가장 새롭게 눈에 띄는 것이 mountpoint://인데, 브라우저에서의 File I/O API를 위한 Opera 제안사항의 일부입니다:
전통적으로, 웹 응용프로그램은 로컬 파일시스템 측의 리소스에 대해 조금의 접근도 허용되지 않았습니다. File I/O를 위한 ECMAScript 인터페이스들은 샌드박스화된 파일 시스템을 지정해, 위젯이나 다른 신뢰된 컴포넌트들이 로컬 파일 시스템에 접근할 수 있도록 합니다.

이 명세의 파일 I/O 인터페이스들은 추상 파일시스템을 나타내며, 기반 파일 시스템의 경로 분리자, 읽기/쓰기 권한 같은 파일 속성을 설정하기 위한 컨벤션 등에 대한 지식이 없어도 됩니다.

인터페이스는 파일을 열고, 쓰고, 파일이나 디렉토리를 생성하고, 옮기고, 지우고, 그밖의 것들을 위한 메소드를 제공합니다.

파일 작업을 하기 위해, 응용프로그램은 우선 마운트지점(mountpoint)을 얻어야 합니다. 마운트지점은 디스크 상의 파일이나 폴더에 대한 레퍼런스 혹은 같은 폴더가 아닐 수도 있는 파일 묶음에 대한 추상 레퍼런스입니다.
만약 응용프로그램에서 File I/O API를 사용하고 싶으면, 브라우저 사용자에게 가상 파일 시스템을 위한 위치를 선택하도록 요구하게 되고, 그러면 샌드박스 안에서 파일에 접근할 수 있습니다.
코어 인터페이스는 이렇습니다:

FileSystem 인터페이스
FileSystem 인터페이스를 응용프로그램에서 사용할 수 있게되면, 인터페이스는 opera.io.filesystem으로 인스턴스화 됩니다. 인스턴스가 되면, 이 객체는 로컬 파일시스템에 있는 파일들과 폴더들에 접근하기 위한 속성과 메소드를 제공합니다.

File 인터페이스
File 인터페이스는 가상 파일시스템내의 객체를 나타내고, 파일이나 폴더를 나타낼 수 있습니다. 파일 객체는 수많은 속성과 파일이나 폴더객체에 작동하는 메소드들로 구성되어있습니다.
지속성(persistent)있다고 표시된 파일 객체는 응용프로그램이 재시작되어도 지속됩니다.

FileStream 인터페이스
FileStream 인터페이스는 읽기 그리고/혹은 쓰기 속성으로 열린 파일 객체를 나타내며, 이 작업을 위한 메소드와 속성을 정의합니다.

from File API via mountpoint:// on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

Chris Hester씨가 다양한 브라우저와 OS에서 버튼 여백이 어떻게 보이는지에 대한 글을 썼습니다.

그가 발견한 몇가지 사항입니다:

  • IE 6와 7은 2px보다 작은 버튼에 추가 여백을 적용하지만, IE8은 그렇지 않다.
  • IE 8과 Opera는 충분히 크게 확대하면 모든 표준 버튼에 경계선을 추가한다.
  • 표준 버튼의 Padding 속성은 Mac Firefox, Safari(Mac, Windows 둘 다)에 아무런 효과가 없다.
사용자 삽입 이미지

from Details of button padding in various browsers 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
John Resig 씨는 "새로운 Selectors API 명세(와 이어질 구현체)에 대해 흥분하지 않을 JavaScript 개발자는 없을 것"이라고 했습니다.

그는 API에 대한 피드백을 제공해주기를 요청받았고, 다음과 같은 내용의 메일을 보냈습니다.

그는 세가지를 고려했습니다:

잘못된 엘리먼트를 반환하는 DOMElement.querySelectorAll

이것이 가장 치명적인 이슈입니다. 이것 덕분에 DOM 엘리먼트 기반의 쿼리들은 라이브러리와 사용자들에게 거의 쓸모가 없습니다. 기본 동작은 예상을 벗어나고, 혼란스럽습니다. Dojo를 사용한 예제를 실행해보세요:
[code:xml]
<div><p id="foo"><span></span></p></div>
<script src="http://o.aolcdn.com/dojo/1.1.0/dojo/dojo.xd.js"></script>
<script>
var foo = document.getElementById("foo");
// should return nothing
alert( dojo.query('div span', foo).length );
// will return the SPAN (booo!)
alert( foo.querySelectorAll('div span').length );
</script>
그 후 그는 다른 라이브러리 개발자들에게 동의하는지 물어보았습니다:

Andrew Dupont (Prototype의 셀렉터 엔진 작성자):
이것과 관련한 저의 논지는 이것이 최소 놀람의 법칙을 위반하고 원래의 API와 닮은 구석이 없다는 것입니다.
Alex Russell (Dojo의 셀렉터 엔진 작성자):
이건 스펙상의 버그입니다.

결합자(Combinator) 기반 쿼리


저는 이전에 이와 관련된 몇가지 논의를 읽었습니다(특히 DOMElement.querySelectorAll - 스타일 쿼리와 관련있는). 이것은 그대로 대부분의 라이브러리에서 중요한 부분입니다. Maciej씨가 제안한 해결책에 - 선행 결합자를 허용하는 :root를 사용한 - 저도 완전히 동의합니다(:root가 document element가 아닌 element와 동등하게 만들어져있는 한).
[code:js]
// jQuery
$("#foo").find("> span");

// DOM
document.getElementById("foo").querySelectorAll(":root > span")
라이브러리는 이것을 쉽게 찾아내고 삽입할 수 있습니다.

에러 처리

저는 제안된 try/catch 해결책이 마음에 들었습니다, 하지만 셀렉터의 어떤 부분이 잘못되었는지 쉽게 알려줄 방법이 있어야만 합니다. 현재 Safari에선 다음과 같이 발생합니다:
[code:js]
try {
    document.querySelectorAll("div:foo");
} catch(e) {
    alert(e); // "Error: SYNTAX_ERR: DOM Exception 12"
}
만약 셀렉터의 적합하지 않은 부분을 가리키는 특별한 속성이 있었다면, 그것은 원래는 중요한 것입니다. 아마도 아래와 같이 작동하는 문자 인덱스를 제공하는 것이 최선의 해결책(구현자와 JavaScript 라이브러리 개발자 모두에 있어)이 될 것입니다:
[code:js]
var selector = "div:foo";
try {
    document.querySelectorAll(selector);
} catch(e) {
    alert(selector.slice(e.position)); // ":foo"
}
이 모든 것을 공개적으로 볼 수 있어 좋습니다. 특히 우리에게 영향을 끼칠 스펙에 라이브러리 개발자들이 참여하는 것을 지켜볼 수 있어서 말입니다.

from We are JavaScript library authors. Hear us roar! on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

이벤트 호환성 표

2008.05.07 00:30 from [IT] Web Tech

PPK 씨가 이벤트 등록 모델(traditional, W3C and Microsoft)과 이벤트 버블링 및 캡쳐를 테스트한 이벤트 호환성 표를 공개했습니다.

다양한 브라우저의 quirks 모드에 대한 많은 데이터가 있습니다.

이벤트 호환성 테이블

이벤트 호환성 테이블


from Events Compatibility Tables on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

Cuzillion Test

Cuzillion 테스트


Steve Souders 씨가 Cuzillion이라는 이름의 멋진 작은 도구를 릴리스했습니다. 이 도구는 브라우저에서 성능 최적화를 위한 각기 다른 테스트를 해주고, 여러 사람과 결과를 공유할 수도 있다고 합니다.

위 그림과 같이, 페이지에 포함할 수 있는 다양한 리소스들을 간단하게 추가해서, 브라우저가 어떤 식으로 이러한 리소스를 처리하는지 살펴보고 이를 통해 페이지의 성능을 최적화 할 수 있는 툴입니다(최적화는 물론 알아서 하셔야합니다).

from Cuzillion: Performance best practices tool on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

WebKit의 CSS 마스크

2008.04.28 00:09 from [IT] Web Tech
CSS Mask 샘플

CSS Mask 샘플


WebKit 에서 CSS 마스크를 지원한다고 합니다. 이 속성은 이미지는 몰론, <video> 엘리먼트에도 적용이 가능합니다.

WebKit 이 CSS에서의 알파 마스크를 지원하게 되었습니다. 마스크를 이용하면 최종 화면에서 어떤 부분을 제외하는 데 사용하는 패턴을 컨텐트 위에 겹칠 수 있습니다. 다시 말해, 어떤 이미지의 알파를 이용해 복잡한 모양으로 자를 수도 있습니다.

이런 속성들을 사용할 수 있습니다:

-webkit-mask (background)
-webkit-mask-attachment (background-attachment)
-webkit-mask-clip (background-clip)
-webkit-mask-origin (background-origin)
-webkit-mask-image (background-image)
-webkit-mask-repeat (background-repeat)
-webkit-mask-composite (background-composite)
-webkit-mask-box-image (border-image)

이 글 상단에 있는 이미지는 이렇게 만들 수 있습니다:
[code:Xml]
<img src=”kate.png” style=”-webkit-mask-box-image: url(mask.png) 75 stretch;”/>

좀 더 둥근 모서리를 사용할 수도 있습니다:
[code:Xml]
<img src=”kate.png”style=”-webkit-border-radius:10px; -webkit-mask-image:
-webkit-gradient(linear, left top, left bottom, from(rgba(0,0,0,1), to(rgba(0,0,0,0))”/>

이미지 입력을 SVG로 할 수도 있습니다:
[code:Xml]
<img src=”kate.png” style=”-webkit-mask-image: url(circle.svg)”/>

from WebKit keeps going with CSS Masks on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

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 CSS Gradients in WebKit on Ajaxian

사용자 삽입 이미지
Dave Hyatt 씨가 WebKit 에서의 CSS Gradients 에 대해서 포스팅했습니다. 위 이미지가 CSS로만 만든 그래디언트 효과 입니다. 이 효과는 다음과 같은 코드를 이용해서 가능합니다.
-webkit-gradient(<type>, <point> [, <radius>]?, <point> [, <radius>]? [, <stop>]*)
가능한 영역은
  • 배경 이미지
  • 경계선 이미지
  • 목록 이미지
  • 본문
이라고 합니다.

몇 가지 예제가 더 있습니다:
Posted by 행복한고니 트랙백 0 : 댓글 0