Margin들 간의 충돌이란, 웹 페이지 안 두 개 이상의 block box들이 위 아래로 교차해서 만날 경우 서로가 가지고 있는 margin 값이 하나로 합쳐지는 현상을 말한다.

그렇다면, 하나로 합쳐지는 margin의 너비는 어떻게 될까? 일상적인 흐름에서 생길 경우에는, 서로 교차하는 margin 값들 중에서 최대치의 margin 너비를 가지는 놈으로 대치가 된다. 둘 중에 하나가 0 이하의 margin 값을 가지고 있는 경우에는, 최대치의 margin에서 그 만큼을 뺀 값이 되고, 모두가 0 이하의 margin 값을 가지고 있을 때에는 0에서 두 값을 모두 빼게 된다.

이런 공식은, 물론 box들 간의 일상적인 흐름에서 충돌하는 경우에 적용되는 것이고, float된 상태이거나, overflow된 상태, 혹은 절대적 값을 가지고 위치하는 경우 등에는 이런 충돌이 일어나지 않는다.

결국, box 요소에 지정되어 있는 margin 값은 절대적일 수 없고, 다른 box들과 부딪힐 경우 테두리(border)를 둘러싸고 있으면서 언제든 상황에 따라 줄어들 수 있는 스폰지와 같은 보호막 구실을 하게 된다.

참고 글: W3C Working Draft – Box model – Collapsing margins

그런데, 위의 참고 글에 의하면,

The top margin of an in-flow block-level element is adjoining to its first in-flow block-level child’s top margin if the element has no top border, no top padding, and the child has no clearance.

그래서, box 자체는 위를 감싸고 있는 스포지가 없더라도 box 안에 담겨있는 하위 요소들의 스폰지가 box의 테두리 밖으로 돌출될 수도 있단다.
이런 돌출이 의도하는 상황이 아니라면, box의 top border 혹은 top padding 값을 지정하게 되면 밖으로 삐져나오는 부작용을 막을 수 있게 된다.

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 개 이상의 변화들과 개선된 사항들이 있을 예정이라고 한다.

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