이미 널리 쓰이고 있는 CSS3 Gradients의 용법이 이번에 또 바뀌었는데, 관련 CSS Image Values and Replaced Content Module Level 3가 지난 1월 12일에 “Last Call” draft 상태로 진입한 것을 보면 어떤 커다란 용법의 변경은 더는 없으리라 예상(기대)된다.

우선 Linear Gradient 용법의 달라진 점.

Linear Gradient의 가장 단순한 사용 예로 다름과 같은 것이 있다. (vendor prefix는 생략함)

div { background: linear-gradient(white, black); }

적용하면 위에서 아래 방향으로 흰색을 시작으로 점점 짙어지면서 마지막은 검은색으로 표시된다.

linear gradient function의 첫 번째 argument는 gradient의 시작점과 끝점을 잇는 기준 축인 gradient-line을 지정하게 되는데, 위의 예에서처럼 생략되면 위에서 아래방향을 가리킨다. 그리고 gradient-linedeg 단위를 써서 각도를 지정해 주거나, 혹은 몇몇 정의된 keywords를 쓸 수도 있다. 글 마저 읽기 »

실생활에서 어떤 것에 대한 궁금증으로 관련 정보를 얻으려고 할 때 가장 먼저 취하는 행동이 인터넷 검색이고 여기서 가장 적합한 정보를 효율적으로 빨리 취하는 것도 그만큼 중요할 것이다. 대부분 직접적이고 효율적인 관련 검색어의 선택만으로도 원하는 정보를 얻을 수 있지만, 좀 더 정교하게 추려낸 검색 결과를 원한다면 특별한 요령이 필요하다.

그래서 대표적으로 Google에서는 효율적인 정보 검색을 도와주는 몇 가지 요령을 담은 문서를 제공하고 있다.

다음은 개인적으로 몇 가지 몰랐던 내용:
검색 결과에서 특정 단어의 배제 (-) – 특정 검색어 앞에 마이너스 사인을 붙이면 해당 단어가 포함된 페이지는 솎아내고 나머지의 검색 결과를 보여준다. 마이너스 사인 바로 앞에 다른 글자가 붙어 있으면 안 되고 검색어 사이엔 공백으로 띄워져 있어야만 제대로 인식된다.
동의어 검색 (~) – 검색어와 더불어 해당 동의어도 함께 포함된 검색 결과를 얻으려면 검색어 앞에 물결무늬 사인(~)을 붙여주면 된다.

이 밖에도 Google 검색 요령에 관한 더 자세한 내용을 담은 cheat sheets:

이렇게 요긴한 검색 요령만 잘 알고 있으면 다음과 같은 족집게 검색도 가능하다.

site:nytimes.com filetype:html ~college intitle:"test scores" intext:"new york city" -SATs 2010..2011
switch(foo) {
  case 'alpha':
    // do X
    break;
  case 'beta':
    // do Y
    break;
  default:
    // do Z
    break;
}

위와 같은 구문을 다음처럼 Object notation을 써서 약간 더 빠르게 실행될 수 있도록 구현할 수 있다.

var switchObj = {
  'alpha': function() {
    // do X
  },
  'beta': function() {
    // do Y
  },
  '_default': function() {
    // do Z
  }
};
(switchObj.hasOwnProperty(foo) && switchObj[foo] || switchObj._default)(args);

물론 비교 대상의 case가 별로 많지 않을 땐 속도의 차이는 크게 나지 않는다.

따온 곳 – How DRY Affects JavaScript Performance — Faster JavaScript Execution For The Lazy Developer

WHATWG Blog에서 전한 내용: WHATWG Weekly: Now it's <time> for <data>

HTML5에 포함되었던, 주로 시간과 날짜를 마크업 할 때 사용되던, time element가 보다 폭넓은 데이터 형식에 대한 요구를 수용하기 위해 schema.org에 정의된 Microdata 용어를 사용하는 data element로 대치되었다는 소식.

이번의 변경을 가져온 처음의 제안 내용과 논의를 살펴보면 적지 않은 반대 의견도 살펴볼 수 있는데, 개인적으로도 time element가 소개되기 이전에 미리 이러한 논의가 이뤄져서 개발자의 혼란을 막았었으면 하는 아쉬움이 있다. (HTML5는 아직 Working Draft임을 감안하더라도.)

Spec에 나와 있는 data element의 사용법을 살펴보면, data element는 감싸고 있는 내용에 대한 기계적으로 해석되는 용도의 value attribute을 항상 포함하고 있어야 한다.

간단한 예로, data element를 써서 특정 시간을 마크업 한 예.

<p>Our first date was <data value="2006-09-23">a Saturday</data>.</p>

다음은 data element로 schema.org에 정의된 Microdata 용어를 써서 블로그 글이 작성된 날짜를 마크업 한 예.

<article itemscope itemtype="http://schema.org/BlogPosting">
 <h1 itemprop="headline">Small tasks</h1>
 <footer>Published <data itemprop="datePublished" value="2009-08-30">yesterday</data>.</footer>
 <p itemprop="articleBody">I put a bike bell on his bike.</p>
</article>

data-* attributes과 마찬가지로 문서에 저장된 다양한 형식의 정보를 data element를 써서 기계와 JavaScript가 접근하기 쉽게 해놓았다지만, 마크업 하기 간단명료했던 time element의 어쩔 수 없는 퇴장은 그래도 아쉽다. 아직 덜 똑똑한 기계 때문에 이런 혼란스런 상황이 벌어졌고, 그래서 더 부지런해야만 하는 것은 개발자들의 몫으로 남겨졌다.

덧붙임: time element의 완전한 삭제/퇴장/배제를 재고해달라는 공식 요청
결국 time, data element가 공존하는 방향으로 갈 수도 있을듯한데 어떻게 될지는 지켜볼 일.

덧붙임 2: 결국, WG 회원들 간의 충분한 논의가 없었음을 인지하고 이번 사건과 관련된 spec의 수정은 일단 보류되었다.