올해 9월 San Francisco에서 열렸던 The Future of Web Apps 회담의 개요 페이지에 가면 행사 사진들과 발표자들의 발표 내용이 담긴 슬라이드들 그리고 여기에 딸린 오디오 파일들을 들어볼 수 있다.

현재와 미래의 웹 개발에 사용될 여러 기술들과 그 경향을 미리 맛보려면 꼭 챙겨야 할 것들. 회담의 개막 소개 영상도 멋지군. 8)

다음 회담은 2007년 2월 13일부터 이틀간 London에서 열릴 예정이다.

 없음.

여러가지 주제의 동영상 강의 교육으로 유명한 VTC에서 드디어 Ruby on Rails CD 타이틀을 발표하였다.

모두 7시간 정도의 분량으로, 내용을 보면 기초적인 Ruby와 Rails Framework의 소개 그리고 간단한 Web Application 제작과 그 적용 과정들을 다루고 있는 듯 하다.

어서 Rails를 타봐야 하는데, 아직 Programming Ruby, Part II에 머무르고 있다.

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 표준을 지원하는 화면 해독기가 발표된다면, 웹 접근성에 민감한 개발자들은 더욱 세심한 주의가 필요할 것이다.

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