.아빠-엄마 {
  margin: 0;
  padding: 0;
  background: skyblue;
}
.아빠-엄마__자식 {
  background: inherit;
}
.아빠-엄마__자식:last-child {
  font-weight: lighter;
  font-size: small;
}
.아빠-엄마__자식--예쁜-딸래미 {
  color: pink;
}
.아빠-엄마__자식--개구쟁이-막내 {
  color: tan;
  transform: skewX(30deg);
}

여기서 개구쟁이 막내는 특별하게 .아빠-엄마__자식--개구쟁이-막내란 class를 따로 지정해 줄 필요 없이 CSS pseudo-class인 :last-child만 써서 처리해 줄 수도 있었지만, 워낙 개구쟁이라 어쩔 수 없었다는 소문이…

추가 참고 문서:

• Scalable and Modular Architecture for CSS
• ‘Scope’ in CSS
• Using Encapsulation In CSS

HTML5에선 근래에 그 쓰임새가 더욱 다양해진 여러 형태의 웹 문서나 웹 애플리케이션의 사용 패턴에 부응하려고 기존 elements의 확장 개념으로 좀 더 명확한 구조적/의미론적 정의를 부여하는 새로운 elements가 추가되었다.

그래서 그 쓰임새에 맞는 적절한 elements를 가지고 HTML 문서를 작성하면, 저자가 의도한 대로 그 의미가 제대로 전달되면서 더불어 다양한 웹 접속 장비에서의 해석도 훨씬 수월해지기 마련이다.

문제는, 웹 브라우저가 새로운 elements에 대응하는 Accessibility APIs를 아직 제대로 적용하지 못하고 있는 실정이다. 결국 웹 접근성을 고려해서 WAI-ARIA에 근거한 적당한 ARIA landmark role을 직접 지정해 주어야 하는데, 마침 W3C에서 HTML을 작성할 때 WAI-ARIA를 올바로 구현하는 법에 대한 안내 문서(W3C Editor’s Draft )를 공개하였다.

이 문서에서 ARIA role을 적용해야만 하는 HTML5 elements와 해당 element에 지정해 주어야 하는 기본 ARIA role을 간추리면 다음과 같다.
ARIA role을 적용해야만 하는 HTML5 elements(이)란 제목의 글 마저 읽기 →

CSS를 작성하다보면 스타일 정의 갯수가 증가함에 따라 주의를 한다고 해도 분명 얘기치 않게 중복된 스타일 선언을 하기 마련이다. 물론 나중에 최적화 과정에서 CSS 파일을 minimize 하게 되면 파일 크기에 큰 영향을 끼치진 않겠지만, 나중에 관리적인 측면에서 불필요하게 덤으로 정의된 스타일은 상당히 귀찮아질 수가 있다.

csscss는 이렇게 CSS 파일을 해석해서 덤으로 중복되게 정의된 스타일 선언을 꼭 집어서 보여주는 도구인데, Ruby gem으로 배포되고 있으며 설치는 다음과 같다.

$ gem install csscss

csscss – CSS 파일에서 중복 정의된 스타일을 꼬집어주는 도구(이)란 제목의 글 마저 읽기 →

JavaScript에서 간단하게 다음과 같이 탐지할 수가 있다.

if (document.body.scrollWidth > window.innerWidth) {
  // horizontal scrollbar is visible. 
}

이 시점은 가령 기존 데스크탑 전용 웹페이지를 반응형 디자인으로 구현하고자 할 때, 여러 breakpoints 중 하나의 후보가 될 수 있다. 하지만 미리 마련된 어떤 기준에 따라 나머지 적당한 breakpoints를 자동 탐지해 내는 것은 너무 복잡한 일이다.

결국, 나머진 그냥 눈대중?

전에는 나 자신도 미처 눈치채지 못하고 그냥 버릇처럼 써왔던 것인데, 자주는 아니지만 그래도 간혹, 지금도 html body 끝에 링크된 jQuery 사용 JavaScript 파일이 아래처럼 무조건 jQuery의 ready() 함수로 감싸서 작성된 것을 목격하게 된다.

$(document).ready(function() {
  // Stuff to do as soon as the DOM is ready; 
});

혹은 더 짧게,

$(function() {
 // Handler for .ready() called. 
});

하지만 DOM parsing 작업을 방해하지 않으려고 </body> tag 바로 위에다 스크립트를 추가했다면, 이미 웹 브라우저에선 DOM 해석을 끝낸 시점이기 때문에, 굳이 DOM이 준비되어 있는지 확인하는 작업은 불필요하단 얘기다.

물론 이렇게 한다고 해서 얻을 수 있는 성능상의 이득은 거의 없지만, 불필요한 작업인 것은 분명하다.
추가 참고 문서: You Don’t Need the DOM Ready Event