몇 번의 베타 버전을 거쳐 드디어 정식 Safari 3.1 버전이 Mac과 Windows용으로 함께 공개되었다.

HTML과 JavaScript 부분에서 많은 성능 개선이 이루어졌다고 하는데, 이 밖에도 새로운 버전에서의 바뀐 면모들을 살펴보면 그 동안 WebKit에서만 구현되었던 많은 부분들이 흡수되었다.

이 번에 새로 등장한 주요 기능을은 아래와 같이 이미 WebKit 개발자 블로그에 자세하게 소개된 바 있다.

그리고, 환경 설정에서 예전 Debug 메뉴를 흡수한(?) 새로운 Develop 메뉴를 활성화시켜서 다양한 웹 개발 관련 메뉴들로의 접근이 더 쉬워졌으며, 현 브라우저들 중 가장 높은 Acid3 Test 점수(75)를 보여준단다. 물론 얼마 전 가장 최근의 WebKit은 93점의 높은 점수에 도달했다는 소식도 있었음.

IE8 베타 버전이 공개되었을 때에도 느낀 것이지만, 또 한번 시작된 브라우저들 간의 치열한 경쟁 구도 속에서도, 주요 기능들은 웹 표준을 중심으로 서로 닮아가는 경향을 보일 것으로 예상되지만, 장점을 내세운 차별화는 앞으로 그 중요성이 더 부각될 mobile web을 누가 선점하는가에 따라 결판나지 않을까 예상해본다.

마침, iPhone Dev Center에 공개되어 있는 “iPhone SDK for Web Developers” 영상에는 이번 Safari에 새로 포함된 웹 개발 관련 여러 기능들의 내용을 엿볼 수가 있었다.

iPhone SDK드디어 오늘 많은 사람들이 고대하던 iPhone SDK가 공개되었다. 키노트를 보고 있자니, 여기서 개발된 iPhone 어플리케이션들은 앞으로 App Store를 통해서 공식 배포될 예정이라고 하는데, 올 6월 있을 iPhone/iPod Touch Firmware Update 2.0을 통해 정식 3rd Party 어플리케이션들의 배포 창구가 열리는 것이다.

키노트를 보고 있노라니, 다시금 Objective-C와 Cocoa Touch를 파고 싶은 뜬금없는 욕구가 마구 샘솟는 것을 막을 길이 없구나.
iPod Touch도 없거니와 초창기 iPod로 연명하고 있는 주제에… 😳

어쨌거나, iPhone SDK를 설치하고 나면, Developer/Platforms/AspenSimulator.platform/Developer/Applications/ 경로에 Aspen Simulator.app라는 어플리케이션이 자리잡고 있는데, Apple이 제공하는 공식 iPhone 시뮬레이터로, 실제 iPhone에서 웹 서핑을 하는 것처럼 여러 사이트들을 둘러볼 수가 있었다.

올 6월 쯤, 때맞춰 갱신된 iPhone/iPod Touch가 한국에도 상륙하길 기다리면서, 당분간 대리 시뮬레이션…

IE8이 발표되기도 전, 많은 웹 개발자들은 IE8에서 새로 도입될 meta 요소를 추가하지 않는 한 가장 최신의 웹 표준 모드를 지원하지 않고 IE7과 별반 다르지 않게 된다는 사실로 인해 커다란 우려와 원성을 불러왔었다.

하지만, 오늘 올라온 IEBlog 글에 의하면, 개발자들의 말을 옳게 귀담아 들었는지, 기존 알려진 웹 표준 모드 작동 방식과 반대되는 결정을 알려왔다. 그래서, IE8의 기본 랜더링 모드는 가장 최신의 웹 표준 모드로 작동될 것이며, 기존 웹 표준을 무시하고 제작된 사이트에서 호환성을 위해 과거 “Quirks mode“를 사용해서 올바로 표시되도록 하려면 meta 요소를 이용한 “version targeting”을 따로 지정해 주어야만 한다. 결국 기존 입장을 완전히 반대로 뒤집는 것이지만, 웹 표준의 정착을 고려해보면, 이제야 올바른 방법으로 돌아온 것이라서 참으로 반가운 소식이다.

처음으로 IE 팀원들의 등을 두드려주고 싶어지지만, 역시나 IEBlog에 올려진 칭찬의 댓글들은 참으로 어색하게 느껴진다. 😈

Blueprint가 0.7로 갱신되었다. 갱신된 지 오래간만이라 바뀐 내용도 조금 많은데, 우선 반갑게도 새로운 자기만의 스타일로 CSS 수정하고 압축할 수 있게 하는 Ruby script(compress.rb)가 추가되었고, 디렉토리 구조도 단순하게 정리되었다. 그리고 .column class가 필요없게 되면서 .span-x 형식의 class 만으로 column을 구분지울 수 있게 되면서 더 정리된 느낌이 들지만, div에서만 column 지정이 가능하기 때문에, 경우에 따라 제약이 될 수도 있을 것 같다. 이외에도 많은 벌레들이 잡혔다고. Blueprint 0.7 변경 사항

약간의 디렉토리 구조의 변경으로 실제 사용하기 위해 HTML의 head에 다음과 같이 적용해 주어야 한다. (IE를 위한 CSS 파일의 위치가 바뀌었다.)

<link rel="stylesheet" href="css/blueprint/screen.css" type="text/css" media="screen, projection">
<link rel="stylesheet" href="css/blueprint/print.css" type="text/css" media="print">
<!--[if IE]><link rel="stylesheet" href="css/blueprint/ie.css" type="text/css" media="screen, projection"><![endif]-->

이번 갱신에서 가장 눈에 띄는 변화로 compressor 스크립트(lib/compress.rb)를 들 수 있는데, 이 놈은 압축 뿐만이 아니라 설정 파일(settings.yml)을 기준으로 여러 프로젝트에 위치하는 CSS 파일을 한꺼번에 자신의 입맛에 맞게 생성할 수도 있다.
터미널에서 compress.rb가 위치한 디렉토리로 이동 후, $ ruby compress.rb -h를 치면 아래와 같은 용법을 확인할 수 있다.

$ ruby compress.rb -h
Usage: compress.rb [options]
Blueprint Compressor
 
options
  -o, --output_path=OUTPUT_PATH    Define a different path to output
                                   generated CSS files to.
  -n, --namespace=BP_NAMESPACE     Define a namespace prepended to all Blueprint classes
                                   (e.g. .your-ns-span-24)
  -p, --project=PROJECT_NAME       If using the settings.yml file, PROJECT_NAME is the
                                   project name you want to export
  --column_width=COLUMN_WIDTH      Set a new column width (in pixels) for the output grid
  --gutter_width=GUTTER_WIDTH      Set a new gutter width (in pixels) for the output grid
  --column_count=COLUMN_COUNT      Set a new column count for the output grid
  -h, --help                       Show this help message.

보이다시피, 프로젝트별 설정을 위해 settings.yml 파일이 필요한데, 간단한 예로 딸려오는 settings.example.yml파일을 참고하면 된다.

my_project:
  path: /path/to/my/project/stylesheets
  namespace: custom-namespace-1-
  custom_css:
    ie.css:
      - custom-ie.css
    print.css:
      - docs.css
      - my-print-styles.css
    screen.css:
      - subfolder-of-stylesheets/sub_css.css
  custom_layout:
    column_count: 12
    column_width: 70
    gutter_width: 10
  plugins:
    - fancy-type
    - buttons

여기서는, 우선 각 프로젝트의 이름이 있고 각 프로젝트의 해당 디렉토리 위치와 BP(Blueprint) class 앞에 붙게 될 namespace, 그리고 BP 이외의 추가되는 custom css 파일을 지정할 수 있다.
또한 custom_layout 항목에서는 기본적으로 사용되는 24 column, 전체 너비 950px, column간 10px margin 말고, 사용 환경에 맞는 column의 갯수와 너비, 그리고 gutter(column 간의 margin)을 따로 지정할 수 있다. plugins 항목에서는 추가로 제공되는 여러 BP plugins 중에서 사용하고자 하는 놈을 선택해 준다.
마지막으로, semantic_classes 항목이 있는데, 이 놈은 그 동안 순결주의 웹 표준 개발자들로부터 약간의 비난을 받아왔던 의미없는 class 사용에 대한 반응으로 추가된 듯 하다. 이 놈은 단순하게 실제 BP를 사용하면서 지정해 두었던 class의 pattern을 이용해서 여기에 대응하는 의미를 갖는 이름의 id나 class로 대치시켜주는 기능을 하지만, 순수 결백 주의자들에게는 반가운 기능일지도.
사소한 변화로, clearing floats를 위해 사용됐던 .clear class가 .clearfix로 이름이 바뀌었고, 기본적 clearing을 위한 .clear (clear:both;) class가 추가되었다.

마지막 적용은, $ ruby compress.rb -p MY_PROJECT_NAME만 쳐주면 끝.

이렇게 Blueprint도 1.0 버전에 가까워 지면서 더욱 성숙되고 편해져 가는 모습을 보니, 믿음직하군.

지금의 웹 어플리케이션 개발의 추이를 보면, 어떤 동작을 부여하는데 있어서 대부분은 특정 DOM elements를 불러와서 원하는 동작 적용하게 된다. 여기서 특정 DOM elements를 가져오는데 걸리는 시간은 웹 어플리케이션의 동작 속도에 커다란 영향을 끼칠 수도 있다.

현재, 많은 JavaScript library들이 CSS3 selectors를 이용해서 특정 DOM 요소들을 불러오는 기능을 구현하고 있으나, 경쟁적인 속도 단축 노력에도 불구하고, 웹 브라우저가 직접 이런 작업을 지원해 준다면 속도와 효율면에서 커다란 득을 볼 수 있는 것은 당연한 얘기다. 이런 작업의 표준화를 위해 W3C에서는 Selectors API를 제공하고 있는데, 마침 얼마전 WebKit에서도 getElementsByClassName을 지원하기 시작한데 이어서, 이제 특정 DOM 요소들을 끄집어 오는 작업을 위한 querySelector와 guerySelectorAll methods를 지원하기 시작했단다.

사용 예를 보면,

/*
   * Get all the elements with class "hot" (duplicating getElementsByClassName)
   * A common use for this is as a toggle;
   * for example, a search feature might tag results with a class
   */
  document.querySelectorAll(".hot");
 
  /*
   * Get the currently hovered element
   */
  document.querySelector(":hover");
 
  /*
   * Get every other element in the <li> with id "large"
   * This is mostly useful for doing "zebra stripe" alternating rows.
   * Once CSS3 becomes more widespread, doing this directly via CSS will be more practical
   */
  document.querySelectorAll("#large:nth-child(even)");

이제, CSS3 selectors를 이용해서 특정 DOM elements를 손쉬우면서도 빠르게 끄집어 내서 동작을 부여할 수 있게 된 것이다. 앞으로 이 Selectors API가 기타 다른 브라우저들에서도 지원해 준다면, DOM Scripting의 효율도 더 높아질 듯 하다.

조만간 있을 Safari의 갱신 때 이것도 포함되었으면 좋겠군.