CSS는 DRY(Don’t Repeat Yourself) 하라는 언어의 기초적 원리를 여태 따르지 않는다는 불평의 소리. 더군다나 여러 곳에 흩어져 있는 방대한 CSS 코드들을 수정해야 할 때는 이런 불평과 아쉬움이 쏟아질 만도 하다.
그래서 보통 프로그래밍 언어들에서 자주 사용하는 변수나 매크로의 필요성이 CSS 자체 내에서 구현되어야 한다는 것이 대두되는 이유이겠지만, 가까운 미래에 이런 요구가 반영되기는 어렵겠지.

여러 표준 규약들의 개정과 그에 따른 새로운 표준의 실제 적용 속도는 현재 개발자들의 요구와 사용자들의 변화를 따라가기에도 너무 벅찬 데다가 현 브라우져들 간의 CSS 해석차이는 상황을 더욱 복잡하게 만들고 있는 것이 현실이다.

보통 웹 문서에 있는 제목들 간의 구분을 위해 우리는 자신의 취향에 맞는 여러 형태의 글자들을 사용해 왔다. 하지만, 이런 글자들이 화면 해독기 사용자들에게는 그저 무의미한 글자로 들릴 수도 있음을 생각해 본 적이 있는가?

이런 제목들 간의 구분을 위해 사용된 글자들이 화면 해독기에서 과연 어떻게 들리는지에 관한 글을 읽어보면, 구분 글자들의 사용에도 세심한 배려가 필요하다는 것을 깨닫게 된다.

물론, 위의 글에 예시된 보기들은 영어판 JAWS 화면 해독기를 본보기로 들었지만, 시각 장애인들이 처해있는 상황을 이해하는 데에도 도움이 될 수 있을 것이다.

요는, »와 같은 반복적인 글자 형태로 된 것은 피하고, → (→)와 ★ (★)와 같은 특수 유니코드 글자들은 화면 해독기가 올바로 읽어들이지 못할 수도 있으므로 사용에 주의를 요한다.

결국 가장 무난한 것은 수직 막대 (|), 점 (·) 혹은 수평 막대 (-)가 사용될 수도 있겠지만, 가장 중요한 것은 구분 글자들 주의에는 항상 빈 공간으로 둘러싸서 시각 장애인이든 아니든 모두에게 제목들 간의 구별을 쉽게 해주라는 것이다.

여기서, 제목들 사이를 구분해 놓는 글자로 많이 쓰이는 수직 막대(|)의 경우에는, 차라리 다음과 같은 CSS의 테두리 적용 용법을 사용해서 시각적 효과에 관련된 내용은 아예 웹 문서에서 따로 빼줄 수도 있을 것이다.

#navlinks li {
  display: inline;
  margin-right: 0.5em; padding-right: 0.75em;
  border-right: 1px solid #99C;
  font-weight: bold;
}
 
#navlinks li.last {
  border-right: 0;
}

이 글을 읽으면서 또 한 가지 발견한 사실은 청각 기능을 담은 CSS 표준의 존재이다. 물론, 이것도 영어를 기준으로 한 것이지만, 이런 청각 CSS 표준을 지원하는 화면 해독기가 발표된다면, 웹 접근성에 민감한 개발자들은 더욱 세심한 주의가 필요할 것이다.

아무리 웹 접근성을 주장해도 현실은 아직 갈 길이 멀고, 웹 개발자들에게는 더욱 세심한 관심이 요구된다.

CSS Specificity는 CSS 규칙들이 어떤 하나의 특정 요소에 적용되면서 CSS 규칙들 간의 두 개 이상의 충돌이 생길 경우, 브라우져가 더 한정적으로 선언되어 있는 특정 규칙을 따르게 되는 몇 가지 정해진 기본 적용 순위를 말한다.

대개의 경우, 아주 복잡한 CSS 파일들을 한꺼번에 적용할 경우 이런 충돌이 일어나는데, 이럴 때 웹 디자이너들이 주로 간편하게 선택하는 방법은 더 우선순위를 갖는 규칙에 불필요할지도 모르는 !important 속성을 적용하는 것이다. 이렇게 하면 개발자들로 하여금 어떤 한 요소를 손쉽게 변경할 수도 있게 할 것을 더 복잡하게 만는다. 그래서, CSS Specificity의 올바른 이해와 적용은 모든 웹 개발팀원들에게 바람직할 것이다.

먼저 선택자(selector)의 specificity는 다음과 같이 계산된다:

• 선택자에 있는 ID 속성에 있는 갯수를 계산 (=a)
• 선택자에 있는 기타 다른 속성들과 pseudo-class들의 갯수를 계산 (=b)
• 선택자에 있는 요소 이름들의 갯수를 계산 (=c)
• pseudo-element들은 무시

이것들의 계산법은 다음과 같다:

*              {}  /* a=0 b=0 c=0 -> specificity =   0 */
li             {}  /* a=0 b=0 c=1 -> specificity =   1 */
ul li          {}  /* a=0 b=0 c=2 -> specificity =   2 */
ul li a        {}  /* a=0 b=0 c=3 -> specificity =   3 */
a:hover        {}  /* a=0 b=1 c=1 -> specificity =  11 */
ul li a.red    {}  /* a=0 b=1 c=3 -> specificity =  13 */
li a.red:hover {}  /* a=0 b=2 c=2 -> specificity =  22 */
#candy         {}  /* a=1 b=0 c=0 -> specificity = 100 */

물론, 여기에는 빠져있지만 inline style 속성이 또 따로 지정되어 있다면 ID 속성보다도 더 높은 우선순위를 갖게 된다.

더 자세한 내용은, Eric씨와 Molly씨가 specificity에 관해 올려놓은 글을 참고.

Particletree · A Designer’s Guide to Prototyping Ajax의 글에서 따옴.

오랜만에 IEBlog에 IE7에 적용될 CSS 변화들에 관한 환영할 만한 글이 올라와 있다.

여기에는 <!DOCTYPE> 전환에 의한 strick 모드 하에서만 적용되는, CSS2.1와의 호환성을 높이기 위한 거의 200 개 이상의 변화들과 개선된 사항들이 있을 예정이라고 한다.

물론 예전의 잘 못된 습관들에 의해서 개발된 사이트들은 이에 따른 수정도 불가피하게 되었지만, 수정에 필요한 도구들도 마련해 두었다고 하니 지켜볼 일이다.

IEBlog에 올려진 글에 의하면, 차기 Vista에 포함될 IE 7에서는 그동안 웹 개발자들의 골치를 썩여왔던 웹 표준과 CSS 관련 벌레들이 만족할 만한 수준은 아니지만 어느 정도는 수정되어서 발표될 예정이라고 한다.

그 동안 개발자들로부터 가장 많이 요구되어 왔던, PositionIsEverything과 Quirksmode에서 지적되어 왔던 것들을 포함한, 버그들의 수정과 함께 완전한 CSS 2의 지원을 목표로 하고 있다고…
이로써, 그 동안 자행되어 왔던 땜질 처방은 정식 IE 7 발표와 동시에 많이 줄어들겠지만, 또 다른 땜질 제거 작업과 더불어서 당분간 혼란한 상황은 계속될 듯 하다.

땜질에 익숙한 웹 개발자의 입장이라면, 정식 IE 7의 발표가 가져다 줄 상황은 상당히 복합적일 듯. 🙄