1. Firefox 4 : 파이어폭스에서 최근 바뀐 점

    2010/09/22 • by Mincheol Im • Firefox 4 • No comments yet

    요즘 정말 바빠서 계속 업데이트할 기회가 없었는데 많은 일이 벌어졌네요:

    이상 바뀐 점은 다음 베타 버전에서 쓸 수 있습니다.

    원저자: Paul Rouget – 원문으로 가기

  2. -moz-any() 선택자(selector)를 이용한 그룹핑

    2010/06/24 • by Mincheol Im • CSS, Firefox, 주요 문서 • No comments yet

    이 글은 데이비드 바론(David Baron)의 블로그에 있던 포스팅을 가져온 것이다. 이 기능은 모질라 센트럴 (trunk) 에 적용됐고 아직 파이어폭스 나이틀리 빌드(Nightly Build)에서만 쓸 수 있다.

    지난밤 나는 :-moz-any() 선택자 그룹핑(grouping) 지원 기능을 넣었다. 이것은 결합된 선택자(combinators)가 전체적으로 비슷한데 일부분만 다르게 사용되는 경우 일일이 반복하는 대신 짧게 줄여서 쓰게 해준다. 예를 들어 이 기능으로 브라우저(user-agent) 스타일 시트 규칙을 다음과 같이 바꿀 수 있다:

    /* 3단계 (또는 그 이상) 네모기호 순서없는 목록(unordered lists) 만들기 */
ol ol ul,     ol ul ul,     ol menu ul,     ol dir ul,
ol ol menu,   ol ul menu,   ol menu menu,   ol dir menu,
ol ol dir,    ol ul dir,    ol menu dir,    ol dir dir,
ul ol ul,     ul ul ul,     ul menu ul,     ul dir ul,
ul ol menu,   ul ul menu,   ul menu menu,   ul dir menu,
ul ol dir,    ul ul dir,    ul menu dir,    ul dir dir,
menu ol ul,   menu ul ul,   menu menu ul,   menu dir ul,
menu ol menu, menu ul menu, menu menu menu, menu dir menu,
menu ol dir,  menu ul dir,  menu menu dir,  menu dir dir,
dir ol ul,    dir ul ul,    dir menu ul,    dir dir ul,
dir ol menu,  dir ul menu,  dir menu menu,  dir dir menu,
dir ol dir,   dir ul dir,   dir menu dir,   dir dir dir {
  list-style-type: square;
}

    이것을 고치면:

    /* 3단계 (또는 그 이상) 네모기호 순서없는 목록(unordered lists) 만들기 */
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) ul,
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) menu,
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) dir {
  list-style-type: square;
}

    이론적으로는 다음과 같이 쓸 수도 있는데:

    /* 3단계 (또는 그 이상) 네모기호 순서없는 목록(unordered lists) 만들기 */
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) :-moz-any(ul, menu, dir) {
  list-style-type: square;
}

    그러나 이렇게하면 태그 버킷(tag bucket)에 더이상 들어가지 않기 때문에 더 느려지게 된다. (만일 :-moz-any()가 앞으로 많이 쓰이게 되면, 우리가 코드를 수정해서 빠르게 만들 수도 있지만, 아직 그렇게 하지 않았다.)

    :-moz-any()는 (CSS 2.1이 아니라 단순 선택자(simple selectors)의 css3-선택자 정의를 따르는) 다중 단순 선택자(multiple simple selector)를 선택자에 포함하는 것이 허용되지만, 결합된 선택자 또는 의사-요소(pseudo-elements)를 포함하는 것은 허용되지 않는다. 그래서 :-moz-any(p.warning.new, p.error, div#topnotice)라든지 :-moz-any(:link, :visited).external:-moz-any(:active, :focus) 처럼 쓸 수는 있지만, :-moz-any() 안에 “div p” 라든지 “div > p 또는 “:first-letter”를 집어넣을 수는 없다.

    두가지 이유로 -moz- 접두사(prefix)를 붙여놓았다. 첫째, 이건 단순한 제안(proposal)일 뿐이고 어떤 기술적 구현방법을 명세화하지 않았다. 둘째, 아직 이 특성을 올바르게 다루지(handle specificity correctly) 않았기 때문에 prime-time을 위해 잘 준비되지 않았다.

    참조(Note): 이 방식이 HTML5 기반 환경(context)에서 sections 과 headings 위치에 쓰일 경우 매우 중요해질 것이다. section, article, aside, 그리고 nav는 중첩될 수 있기 때문에 깊이가 다른 단계에서 모든 h1요소에 스타일을 지정하는 것은 극히 복잡해질 수 있다.

    /* 단계(Level) 0 */
h1 {
  font-size: 30px;
}
/* 단계 1 */
section h1, article h1, aside h1, nav h1 {
  font-size: 25px;
}
/* 단계 2 */
section section h1, section article h1, section aside h1, section nav h1,
article section h1, article article h1, article aside h1, article nav h1,
aside section h1, aside article h1, aside aside h1, aside nav h1,
nav section h1, nav article h1, nav aside h1, nav nav h1, {
  font-size: 20px;
}
/* 단계 3 */
/* ... 꿈도 꾸지 마라 */

    -moz-any(): 를 쓰면

    /* 단계 0 */
h1 {
  font-size: 30px;
}
/* 단계 1 */
-moz-any(section, article, aside, nav) h1 {
  font-size: 25px;
}
/* 단계 2 */
-moz-any(section, article, aside, nav)
-moz-any(section, article, aside, nav) h1 {
  font-size: 20px;
}
/* 단계 3 */
-moz-any(section, article, aside, nav)
-moz-any(section, article, aside, nav)
-moz-any(section, article, aside, nav) h1 {
  font-size: 15px;
}

    원저자: Paul Rouget – 원문으로 가기

  3. 파이어폭스 3.6에서 HTML용 pointer-events

    2010/06/20 • by Mincheol Im • CSS, Firefox 3.6, SVG, 웹표준, 주요 데모, 주요 문서 • No comments yet

    CSS 속성(property)인 pointer-events는 오랫동안 SVG의 일부로써 쓸 수 있었다. 만일 요소(element)에 마우스이벤트(mouse event)가 마우스 바로 밑에 있는 요소에 보내져야 하거나 또는 그 밑에 있는 요소로 뚫고 지나가야 할 때 이를 제어하는 방법이다. 파이어폭스 3.6에서 우리는 속성을 확장해 일반적인 HTML 콘텐츠에서도 이를 적용할 수 있게 만들었다.

    SVG 사용시에는 pointer-events 속성을 여러 값(values)중 하나로 정할 수 있지만, HTML에서는 단지 둘 중 하나만 지정할 수 있다: auto 또는 none.

    .foo {
  pointer-events: none;
}

    pointer-events를 none으로 지정할 때 pointer-events는 목표 요소에 보내지는 대신 그 밑으로 뚫고 지나간다.

    .foo {
  pointer-events: auto;
}

    pointer-events를 auto로 지정하면 pointer events는 평범하게 작동한다. 즉 아래쪽 요소로 뚫고 들어가는 현상으로부터 events를 막아준다.

    여기 Paul Rouget이 만든 실제 사례가 있다. 이것이 작동하는 모습을 보려면 파이어폭스 3.6 베타가 필요할 것이다.

    이미지 밑에 있는 pointer-events: none 체크박스(checkbox)를 눌러서 어떻게 다른지 확인하라.

    그는 트위터닷컴(twitter.com) 첫화면에서 태그 목록을 복사해놨다. (주: 태그 목록을 보려면 로그인하지 않은 상태여야 한다.) 만일 트위터에 찾아가서 이를 살펴본다면 태그 목록에서 오른쪽 부분이 희미하게 사라진 모습을 볼 수 있을 것이다. 이것은 그 아래 있는 박스 위에 놓인 이미지에 점차 희미하고 투명한 효과를 줘서 만든 것이다. 밑에 깔린 태그는 누를 수 있는(clickable) 링크들인데 이미지가 사라진 효과를 받는 부분 밑으로 보내진 events를 막아버린다.

    Paul이 한 일은 위에 사라짐 효과가 적용된 요소가 있는 경우에도 밑에 있는 링크를 누를 수 있도록 pointer-events 속성을 사용하는 방법을 보인 것이다.

    원저자: Christopher Blizzard – 원문으로 가기

  4. WOFF 산업 표준과 파이어폭스 3.6

    2010/06/20 • by Mincheol Im • Firefox 3.6 • No comments yet

    오늘 우리는 파이어폭스 3.6 버전을 내놓았고 사용자들은 판올림을 시작했다. 더 중요한 사항 가운데 하나는 우리가 개발자들을 위해 WOFF라는 새 글꼴 표준을 지원한다는 것이다.

    WOFF는 활자(type) 커뮤니티에서 폭넓은 지지를 받아왔고 우리는 그 결과를 확인하기 시작했다. 출시된 당일(on day zero) 우리가 지목할만한 사례를 몇가지 들어 본다 :

    1. 세계 최대 활자 개발사 폰트폰트(FontFont)는 FF 누보 미디움 데모(FF Nuvo Medium Demo)라는 무료 체험판 글꼴을 WOFF 형식(format)으로 선보였다. 이것은 폰트폰트가 의무로 삼은 것들중 일부로, 새로 나온 형식을 지원하고 사람들이 써볼 수 있도록 도구를 제공하는 활동이다.

    2. 상용 글꼴 호스팅 업체 타이프키트(Typekit)는 파이어폭스 3.6 사용자를 위한 WOFF 글꼴을 서비스하겠다고 발표했다.

    이미 새로운 형식이 지원받기 시작했지만 상업적으로도 지원받는 것을 볼 수 있으니 훌륭한 일이다. 이는 웹 사용자의 경험을 실제로 향상시키게 될 것이다.

    원저자: Christopher Blizzard – 원문으로 가기

  5. 파이어폭스, 유튜브, 웹M(WebM)

    2010/06/13 • by Mincheol Im • Firefox 4, HTML5, Video, 웹표준, 주요 문서 • No comments yet

    이번 모질라가 VP8 코덱을 지원하는 것(Mozilla’s support for the VP8 codec)에 관련된 글에 대한 다섯 가지 중요한 사항:

    1. 구글은 VP8을 로열티 없이 오픈소스 라이선스로 출시할 것이다. VP8은 구글이 인수한 온투(On2)라는 회사에서 얻은 고품질 동영상 코덱이다. VP8 코덱은 테오라(Theora)보다 훨씬 향상된 비트당 화질(quality-per-bit)을 보여주며 H.264에 견줄만 하다.
    (역자 주 : Theora 역시 오픈소스 기반 코덱으로 On2가 예전에 만든 VP3 코덱에서 갈라져나왔음.)

    2. VP8 코덱은 보비스(Vorbis) 음성 코덱과 묶여 마트로스카(Matroska) 파일 형식에 들어간다. 웹M(WebM)이라 불리는 웹용 오픈 비디오(Open Video) 표준을 새로 만들기 위해서다. 프로젝트에 대한 상세한 내용을 해당 웹사이트에서 찾아볼 수 있다:http://www.webmproject.org/.

    3. 우리는 파이어폭스에서 웹M을 지원할 예정이다. 현재 극히 초기버전으로 웹M을 지원하는 파이어폭스4 프리-알파 빌드를 구할 수 있다. 웹M은 구글 크롬(Chrome)과 오페라(Opera)에도 포함될 것이다.

    (불확실) 4. 모든 유튜브 동영상은 웹M 코덱으로 변환된다. 현재 재생할 수 있는 동영상이 120만개쯤이며 제공되는 영상 목록을 시간이 지남에 따라 갖출 것이다. 그러나 모든 동영상이 웹M 코덱을 지원하게 돼있다.

    5. 단지 구글과 다른 상대들만이 아니라 여러 협력사들이 웹M을 지원한다. 브라이트코브(Brightcove)같은 콘텐츠 제공자들이 완전한 HTML5 동영상 기술의 일부로써 웹M을 지원하기 위해 동참해왔다. 하드웨어 회사, 인코딩 업체, 그리고 다른 동영상 관련 기술 분야 종사자들이 모두 웹M을 후원하는 이들에 속한다. 심지어 어도비(Adobe)는 플래시(Flash)에서 웹M을 지원할 예정이다. 영향력있는 리더십과 시장점유율을 갖춘 파이어폭스와 동영상 서비스 시장을 주도하는 유튜브가 여기서 가장 중요한 협력사다. 하지만 우리 모두는 더욱 거대한 동영상 생태계에서 작은 일부분을 차지할 뿐이다.

    우리는 구글이 오픈 비디오를 지원하기 위해 우리쪽에 동참하는 것을 보고 매우 흥분했다. 구글은 오픈 웹(Open Web)과 W3C 로열티 면제 라이선스 조항에 맞춰 쓸 수 있게 기술을 개발한다. 그리고 – 가장 중요한 건 – 이들이 세계 최대 동영상 서비스 사이트에서 완전히 개방된 동영상 기술을 지원하려고 열심이라는 것이다. 이는 서비스 수준을 유지하는 동시에 동영상 기술분야에서 신기술을 받아들여야하는 다른 사이트들을 위한 출발점을 옮겨놓는 것이며 동영상 업계 지형도를 바꿔버리는 것이다. 사용자 기반을 늘리고 차세대 웹 기술을 지원해나가는 브라우저들에 대한 호환성 문제는 말 할 것도 없다.

    모질라에서, 우리는 웹이 정체하는 만큼 웹기반 동영상이 빠르게 움직이길 바랐다. 그러려면 토대가 될 공개 기술에서 출발해야 한다. 테오라는 썩 괜찮게 시작했지만, 출발선은 VP8이 더 낫다. 우리가 동영상 분야에서 활기찬 혁신을 일궈 나갈 것을 기대해라. 우리는 웹이 그랬던 것처럼 가장자리에서부터, 일부분을 합쳐 더 큰 뭔가를 이루는 수십여개 작은 변화들과 함께 혁신해나갈 것이다. VP8은 그 작은 한 조각이며, HTML5은 또 다른 조각이다. 만일 당신이 이 블로그(weblog)를 본다면, 당신은 마찬가지로 드러나기 시작한 나머지 조각들(other pieces starting to emerge as well)을 보기 시작할 것이다. 웹은 점점 더 파이어폭스 주도하에 많은 기술을 받아들이고 있다. 우리는 HTML5를 넘어 필요한 단계까지 웹을 계속 주도해 나가려고 한다.

    오늘은 위대한 변화가 있은 날이다. 내일은 또 다른 변화가 있을 지어다.

    원저자: Christopher Blizzard – 원문으로 가기

  6. 캐싱 재활성화(Revitalizing Caching)

    2010/06/05 • by Mincheol Im • Firefox, HTML5, 성능, 오프라인 기능, 웹표준 • No comments yet

    확실히 컴퓨터 과학에서 풀기 어려운 문제는 캐시를 쓸모 없게 만드는 것과 뭔가에 이름을 붙이는 것 두 가지 뿐이다. (필 칼튼의 격언에 따르면 그렇다.) 이달초 우리는 트위터, 페이스북, 스프라우트코어(SproutCore), 팜의 웹OS, 마이크로소프트의 ‘오피스 온 더 웹(Office On The Web)’, 야후, 그리고 구글 대표자들을 초대했다. 우리는 뭔가에 이름을 붙이는 것도 큰 문제임을 잘 알고 있었지만 (다른 것들 보다는) 그 모임은 캐시를 쓸모 없게 만드는 문제에 대해서 얘기하기 위해서였다.

    캐싱은 휴대용 단말기에서 웹 애플리케이션을 널리 쓰이게하는 것 말고도 웹상에서 올바른 권리를 얻기 위해 중요하다. 모임에서 우리가 추구한 목표는 캐싱과 HTTP request 효율을 향상시킬 수 있는 사용사례를 확립하는 것이었다. 예를 들어 우리가 직접 팔을 걷어부치고 파이어폭스에서 HTTP/1.1 파이프라이닝(Pipelining)을 살피는 것이 이상적인 방식일까? 이밖에 HTTP layer에 필요했던 것이 뭘까? 그리고 파이어폭스 3.5에서 전면적으로 지원하기로 알려진 HTML5 앱캐시(AppCache) 기능이 개발자들에게 실제로 유용한가? 이밖에 within content나 additional headers 가운데 웹 애플리케이션에 노출돼야 하는 것은 무엇인가?

    개발자 피드백은 매우 소중한 것이며 우리가 원하는대로 조각난 웹 플랫폼들을 점차 통합해 나가는 일에 밑거름이 된다. 웹 개발자들은 우리들의 주요 유권자 가운데 하나다 : 웹 표준에 대해 우리가 수행하고 집중할 필요가 있는 것들 가운데 우선순위를 정할 수 있도록 개발자들이 도와주길 바란다. 우리는 참가자들을 현명하게 택한 셈이다 ; 어떤 사람들이 속한 그룹이든 웹 플랫폼에서 웹 애플리케이션(web application) at scale, 현재 캐시의 성능, 그리고 앞으로 등장할 브라우저가 행하는 캐시 처리동작에 대한 희망사항에 대해 얘기할 수 있다면. 그리고 이들이 우리에게 돌려준 피드백은 내용이 풍부하고 유용했다 — 우리 일은 이를 발췌하는 것뿐이었다. 특히 우리는 우리가 뒤이어 진행해야 할 몇가지 행동을 찾아냈다 :

    • 디스크와 메모리 캐시 기본크기를 늘려라. 파이어폭스에서 디스크 캐시 기본값이 50메가바이트(MB)로 돼 있는데, 요새 하드웨어에서 쓸 수 있는 디스크 용량에 비해 작다. (그리고 고급 설정 항목에서 캐시를 늘릴 수 있지만 실제로 기본값을 바꾸는 사용자는 거의 없다.) 우리 입장에서는 쉽게 고칠 수 있는 일이다. 우리가 디스크 캐시 크기를 더 늘려 정하는 대신에 자동산출 방식으로(heuristically) 만드는 게 어떻냐는 재미있는 질문을 받았다. 캐싱 서밋에 참석했던 스티브 소더스(Steve Souders)는 블로그에 캐시 크기와 조기 캐시 메모리 반환(premature cache evictions)에 관한 글을 올렸다.

    • 모질라 시범사용자(Mozilla Test-Pilot) 프로젝트를 운영해서 현재 캐시 사용현황에 대한 정확한 데이터를 수집해라. 이건 우리 캐시 알고리즘 갱신에 대한 더 방대한 질문 가운데 일부분이다. 다른 브라우저들처럼 우리는 LRU-SP라 불리는 최근최소사용(LRU : Least Recently Used) 캐싱 알고리즘을 쓴다. 캐시 자원 히트율, 평균, 변동량, 분포를 측정한 것이 우리에게 필요한 데이터에 포함된다. 캐시 데이터들의 평균 수명이 어느정도인지? 상이한 모드로 작동하는 LRU-SP기반 메모리 반환정책이 어떤 애플리케이션에서 잘 작동하지 않는지, 어떤 경우에 (필수 스크립트 파일처럼) 큰 데이터가 (맵 타일같은) 작은 것보다 먼저 삭제되는지? 우리는 주기적으로 캐시를 초기화하는 안티바이러스 소프트웨어 작동방식을 연구해야 한다. 이러한 안티바이러스 동작은 유효한 자원을 뜬금없이 날려버리는 현상을 더욱 조장한다.

    • MIME 형식 기반 캐시 데이터에서 우선순위를 고려해라. 예를 들어 자바스크립트(text/javascript)가 우리 LRU-SP 알고리즘으로 불필요한 것들을 제거하고 항상 더 높은 우선순위를 받아가도록 허용할 수 있다. 이 방식을 제대로 구현하기위해 크롬, IE, 애플, 그리고 오페라가 우리와 의논을 하고, MIME 형식 기반 “나이브(naive)한” 우선순위 부여 방식에 대한 문서를 만드는 것이다. 우리는 또한 개발자들이 어쩌면 헤더를 통해서 직접 캐시 데이터 우선순위를 설정할 수 있게 만들었으면 한다. 이건 곧 논의될 가능성이 높다.

    • 프록시에서 나온 데이터를 포함해, 웹에서 HTTP/1.1 파이프라이닝 도입을 진짜로 방해되는 것과 이를 없앨 방법을 찾아라. (노키아 N900과 안드로이드 단말기에서 돌아가는) 모바일 파이어폭스 버전에서 파이프라이닝 기능은 기본적으로 작동하는데, 데스크톱 파이어폭스 버전에서는 이걸 꺼놨다. 이유는 여러가진데 특히 파이프라인 기능을 통한 요청 하나가 다른 것들을 느리게 만들 경우 전체적인 성능이 떨어지는 문제가 있어서다. 우리 의논에서 확실한 것은 캐싱 서밋에 참석했던 사람들 대부분은 자신들의 애플리케이션들이 파이프라이닝을 쓰면 성능이 훨씬 향상될 거라고 생각했다는 점이다. 오늘날 웹에서 파이프라이닝 기술에 대한 상황은 일종의 인질의 딜레마(hostage’s dilemma)다. 주요 데스크톱 브라우저들은 성능 저하를 일으키는 시나리오를 겁내기 때문에 아무도 파이프라이닝 기능을 활성화하지 않는다(먼저 나서서 “느려 터진 브라우저”라는 비난에 시달릴 테니까). 우리를 찾아온 개발자들은 낡은 논쟁을 그만뒀다; 웹에서 파이프라이닝 기술을 쓸모없게 만드는 게 무엇인지 이해하고 우리가 실제로 그런 장애들을 없애기 위해 할 수 있는 게 뭔지 결정해야 했다.(역자 주: 인질의 딜레마, 다수인 인질들이 자신을 잡아둔 소수 범죄자에게 덤비지 못하는 이유를 먼저 나섰다가 목숨을 잃을지 모른다는 심리 때문이라고 설명하는 게임 이론 사례. 우리나라 식으로 말하자면 고양이 목에 방울 달기쯤.)

    • HTML5 앱캐시를 발전시킬 방법을 찾아라. 우리는 처음 예상했을 때 솔직히 앱캐시가 채택될 거라고 생각지 않았다. 우리가 캐시 매니페스트(Cache Manifests)와 윈도.애플리케이션캐시(window.applicationCache)처럼 HTML5를 구성하는 부분들을 아직 (사용량이 빠르게 늘어나는 웹 애플리케이션 작동을 보장하기 위한) 또다른 성능 툴이라고 간주한다면, 일반적인 브라우저 캐시와는 다를 것이다. 이름에 무슨 의미가 있는 것이며, 무언가에 이름을 붙이는 건 왜 컴퓨터 과학 분야에서 가장 어려운 문제일까? 오프라인 웹 애플리케이션을 다루는 HTML5 부분들을 설명하고자 “캐시”라는 낱말을 쓰는 것은 일부 개발자들에게 혼란을 초래한다. 우리가 HTML5 앱캐시라고 부르는 것은 원래 오프라인 웹 애플리케이션을 쓸 수 있게 만들어주는 것이었는데, (스프라우트코어 같은 것으로 구축된) 많은 애플리케이션들은 보조 캐시를 사용한다. 애플리케이션 실행 속도와 일반적인 성능을 보장하기 위해서다. 왜? 우리는 의문을 품었고, 두 가지 생각이 들었다 : 일반적으로 브라우저 캐시가 갖는 목적은, 오프라인 환경에서 쓰기 위한 것인가? 한가지 드는 생각은, HTML5 앱캐시는 (일부 모바일 단말기에 쓰이는 “빠른 실행 아이콘”을 쓸 수 있는) 네이티브 앱처럼 작동하는 웹앱을 허용하는데, 어쩌면 결국 네이티브 애플리케이션 실행방식과 통합될지도 모른다. 그리고 다른 측면에서 보자면, 일반 캐시에서 HTML5 앱캐시를 분리하는 것은 일반 캐시를 사용하기 위한 또다른 API를 만들어낸다는 의미일 수도 있다. 일반적으로, 이름에 “캐시”라는 표현이 포함된 API를 동시에 만들어내는 것은 혼란을 초래한다. 그러나 저것이 바로 어려운 문제 가운데 하나로 이름붙이기가 들어가는 이유이며, 우리가 다음번에 이런 혼란과 중복성을 되풀이하지 않도록 염두에 두고 설계해야 하는 까닭이기도 하다.

      우리는 데이터 참조 위치를 기억해주는 곳에서 버그를 추적해왔다: “HTTP 캐시 향상.” 당신은 우리가 여기서 소개하려고 하는 다방면의 변화를 보게 될 것이고, 여기에는 크롬(Chromium)에 대한 캐시 벤치마킹도 포함된다. (그리고 만일 우리가 필요하다면 그냥 크롬의 캐시 코드를 사용할 수도 있다.)

      캐싱은 중요하지만 어렵다. 인덱스를 만들 수 있는 데이터베이스 용량, 스트리밍 비디오, 또는 CSS를 활용한 새 레이아웃 모델 등을 소개하는 방법으로 웹의 단기간 발전 대부분을 묘사하는 것이 적당할수도 있다. 이런 변화들은 꼭 표준 body나 listserv 안에서가 아니라 차라리 시험판을 신속하게 만들고 의미있는 피드백을 주고받으며 만들어진 것이다. 이것이 우리가 웹 개발자들에게 우리를 도와 옳은 일을 할 수 있게 해 달라고 얘기하는 이유이며, 우리가 최근 캐싱 서밋을 진행한 것처럼 계속 모임을 조직하는 이유다.

    원저자: Arun Ranganathan – 원문으로 가기