오래 전부터 인간의 소통 욕구는 통신 수단의 발달과 함께 진화해 왔고, 또 여러 행태로 분출되고 있는 상황이다. 그런데 여기에 또 하나의 특화된 소통 수단이 등장하였으니, 그 이름은 바로 Twitter. 우리말로 옮기면 재잘거림 정도 되려나?

여타 다른 IM 수단과 차별되는 점은, 바로 지금 나는 무엇을 하고 있는가?라는 물음에 대한 특화된 답을 표현할 수 있는 수단이 생겼다는 것이다.
물론 이것은 불특정 다수에게 공개하여, 물론 그 불특정 다수는 전혀 니가 무엇을 하든지 관심이 없겠지만, 잠재된 스토커에게 자신의 발자취를 흘릴 수도 있고, 지인들을 초대해서 서로의 현재 상황과 관심을 공유하면서 또 다른 흥미를 나눌 수도 있을 것이다. 아니면, 단지 불평 불만의 지껄임들을 늘어놓을 수 있는 또 하나의 작은 불출 장소가 될 수도 있겠지.
처음에는 나도 별로 쓸모없게 보였지만, 새로운 표현 수단으로서 앞으로 어떻게 발전해 갈지가 흥미롭기도 하고, 잠깐 사용해본 소감은 중독성이 강하다는 것. 😮
Twitter Badget 달기(이)란 제목의 글 마저 읽기 →

웹 사이트 개발 과정 중에서 사이트의 기본 틀(wireframes)을 잡는 과정은 전체 웹 사이트의 구조와 전달 형식을 규정짓는 단계로서, 아마도 사이트의 규모가 커질수록 그 중요성은 더욱 커질 것이다.

기본 틀을 잡는다는 것은, 페이지의 헤딩이나 이동 메뉴, 문서의 꾸림 정보, 사이드바 그리고 어플리케이션 인터페이스와 같은 사이트에 포함될 주요 요소들을 추가/정의하고 위치를 잡는 작업이다.
이렇게 계획 단계에서 기본 틀을 제대로 잡는 것이 중요한 이유로는, 웹 개발 팀원들 간의 의견 교환을 통한 기본 개발 지침과 방향을 마련하게 되면서 나중에 발생할 수 있는 여러가지 변경 사항들에 관한 의견 소통을 원활하게 하고, 또 사이트가 포함하게 될 각 요소 간의 관계들을 일목요연하게 나타내면서 훨씬 수월하고 효과적으로 사이트의 동작과 스타일들을 표현할 수가 있기 때문이다.

그런데, 이러한 중요성에도 불구하고 작업의 특성상 하얀 종이 위에 사이트의 기본 틀을 여러 번 그리고 고치기란 번거로운 작업이 아닐 수 없다. 그래서 이런 수작업을 보다 효과적으로 수행하는데 도움을 받을 수 있는 도구로 다양한 도표 제작 어플리케이션인 OmniGraffle를 사용하게 되면 그 기능을 충분히 대신할 수가 있게 된다.
OmniGraffle이 사이트의 기본 틀을 잡는 과정에서 특히 빛을 발하는 기능들 중에는, stencil이라고 불리는 여러 도표들에서 사용될 수 있는 다양한 모양의 기호 형판들의 모음집이라 할 수 있는데, 기본적으로 제공되는 것들 이외에 사용자들이 stencil을 직접 제작해서 올려놓은 사이트도 있다. 물론, 이 곳의 User Interface 항목에는 사이트의 wireframe들에 사용될 수 있는 다양한 기호들의 stencil들을 내려받을 수가 있어서, 이것들을 불러와서 좀 더 사실적이고 유연한 사이트의 틀을 표현할 수가 있다.

앞의 stencil들을 모아놓은 Graffletopia라는 사이트는 Summer of Rails의 여러 프로젝트들 중의 하나로서, 어쩐지 군더더기 하나 없이 산뜻하게 만들어져 있는 모습이다. 8)

새로 덧붙임: 틀을 잡을 때 특히 강조되는 것으로, 중요한 것에 치중하라는 얘기가 있다.
이 말은, 웹 디자인 과정에서 UI(User Interface) 요소들의 중요도에 따라 접근하면서 디자인을 확장하라는 얘기이다. 먼저, 웹 페이지에서 꼭 필요한 요소들은 무엇인지부터 시작해서, 그 중요도에 따라 적용이 가능한 여러 표현 방법들을 고민하는 것이다.
이러한 과정은 웹 사이트의 틀(wireframe)을 잡는 과정과 함께 동반적으로 이루어지는 작업이며, 틀을 잡는 작업의 보조적 장치로서 Page Description Diagrams이 필요해지는 이유이다.

이것은 곁가지들만 치다 몸통을 베어내는 실수를 막으려는 또 하나의 안전장치로 볼 수도 있다.

CSS 3의 선택자들(selectors) 가운데에는 HTML 요소들이 가지고 있는 특정한 형태의 속성 값에 따라서 선택적으로 모양을 정의해 주는 것이 가능하다.

그래서, CSS 3에 새로 소개된 추가 속성 선택자들 중에서 [att^=val] 형태의 선택자를 이용하면 문서 밖으로의 연결 고리들을 따로 구분해서 꾸며줄 수도 있다. 이렇게 하면, 독자들에게 새로운 창에서 바깥 연결 고리들을 따로 열 수 있게 하는 선택권을 줄 수가 있는 것이다.

실제 사용 예를 보면, 모든 외부 연결 고리들은 http:로 시작하기 때문에, 다음과 같이 정의해 줄 수 있다:

a[href^="http:"] {
  background: url(images/externalLink.gif) no-repeat right top;
  padding-right: 10px;
}

이렇게 하면, 모든 외부 연결 고리들은 externalLink.gif 그림 파일의 배경을 덤으로 갖게 된다. 물론, 내부 문서들로의 연결할 때 상대적 URLs 대신에 절대적인 주소를 사용한 경우도 있기 때문에, 다음과 같은 정의도 필요하다:

a[href^="http://www.yoursite.com"]a[href^="http://yoursite.com"] {
  background-image: none;
  padding-right: 0;
}

이 기술은 Mozilla 계열과 Safari 그리고 IE7을 포함한 대부분의 표준을 지원하는 브라우져들에서 적용 가능하만, 그렇지 않은 경우라도 단지 무시만 해버린다.

물론, 전자 우편이나 AIM 주소 등에도 비슷하게 적용해 줄 수가 있음.

물론 여기에 소개된 꼼수들은 완전한 세상에 살고 있다면 불필요한 과정이겠지만, 냉험한 현실 속의 웹 브라우저들은 개발자들에게 차별 대우를 요구한다.

IE 7에서는 이제 CSS의 maxHeight 속성을 이해한다는 것을 이용해서, 다음과 같은 JavsScirpt 코드로 구별할 수 있다:

if (typeof document.body.style.maxHeight != "undefined") {
  // IE 7, Mozilla, Safari, Opera 9 
} else {
  // IE 6, older browsers 
}

IE 7의 변화에 따른 다음과 같은 더 간단한 방법도 있다:

if (window.XMLHttpRequest) {
  // IE 7, Mozilla, Safari, Opera 9
 
} else {
  // IE 6, older browsers 
}

물론, 전통적으로 사용되어 왔던 MSDN에 자세하게 소개되어 있는 조건부 주석을 이용한 구별 방법도 유효하다:

<!--[if IE 7]>
<script type="text/javascript">isIE7 = true;</script>
< ![endif]-->
 ... 기타 브라우져들을 위한 코드

덤으로, CSS 속성 이름 앞에 * 혹은 .(점) 그리고 _(밑줄)이 붙어있는 경우에는 브라우져들 마다 제각기 다르게 인식한다는 것을 이용해서 다음과 같은 방법을 사용할 수도 있다. (IE8의 경우 스타일 선언문 마지막에 꼭 “\9″을 붙여주어야 한다.):

/***** Attribute Hacks ******/
#header {
  margin: 10px;   /* any browsers */
  margin: 12px\9; /* IE 8 and below */
  *margin: 15px;  /* IE 7 and below */
  _margin: 20px;  /* IE 6 and below */
}
 
/***** Selector Hacks ******/
/* IE6 and below */
* html #someDiv { color: red }
/* IE7 */
*+html #someDiv { color: red }

– 참고 글

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 값을 지정하게 되면 밖으로 삐져나오는 부작용을 막을 수 있게 된다.