오래 전부터 인간의 소통 욕구는 통신 수단의 발달과 함께 진화해 왔고, 또 여러 행태로 분출되고 있는 상황이다. 그런데 여기에 또 하나의 특화된 소통 수단이 등장하였으니, 그 이름은 바로 Twitter. 우리말로 옮기면 재잘거림 정도 되려나?
여타 다른 IM 수단과 차별되는 점은, 바로 지금 나는 무엇을 하고 있는가?
라는 물음에 대한 특화된 답을 표현할 수 있는 수단이 생겼다는 것이다.
물론 이것은 불특정 다수에게 공개하여, 물론 그 불특정 다수는 전혀 니가 무엇을 하든지 관심이 없겠지만, 잠재된 스토커에게 자신의 발자취를 흘릴 수도 있고, 지인들을 초대해서 서로의 현재 상황과 관심을 공유하면서 또 다른 흥미를 나눌 수도 있을 것이다. 아니면, 단지 불평 불만의 지껄임들을 늘어놓을 수 있는 또 하나의 작은 불출 장소가 될 수도 있겠지.
처음에는 나도 별로 쓸모없게 보였지만, 새로운 표현 수단으로서 앞으로 어떻게 발전해 갈지가 흥미롭기도 하고, 잠깐 사용해본 소감은 중독성이 강하다는 것. 😮
Twitter Badget 달기(이)란 제목의 글 마저 읽기 →
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 주소 등에도 비슷하게 적용해 줄 수가 있음.
Robert씨의 블로그에는 유능한 웹 인터페이스 개발자를 구할 때, 꼭 물어봐야 할 몇 가지 사항들을 적어놓은 글이 올라와 있다.
그 곳에 올려진 질문 항목들을 옮기면 다음과 같다:
- 왜 DOCTYPE이 중요한가?
- Quirks Mode, Almost Standards Mode 그리고 Strict Mode의 차이점은 무엇인가?
- 의미론적(semantic) 코딩이란 무엇이고, 이것이 왜 중요한가?
- 박스 모델(box model)이란 무엇인가?
- hasLayout의 문제를 설명하고 이것에 대한 대처 방법은?
- CSS에 정의되어 있는 한정성(specificity)이란 무엇인가?
- CSS에서의 float들은 어떻게 동작하는가?
- WAI란 무엇인가?
- 만약 글꼴 크기를 픽셀(pixels) 단위로 지정했을 경우, Internet Explorer에서는 어떤 문제가 발생하가?
- Internet Explorer에서는
alt 속성을 어떻게 처리하고 있으며, 결과적으로 어떤 부작용이 발생할 수 있는가?
대부분의 항목에 대한 질문과 해답은 이미 웹 상에서도 많이 논의되었던 것들이지만, Almost Standards Mode의 존재는 처음 알았다.
물론 위에서 던져진 질문들 중에서, Internet Explorer와 관련된 박스 모델과 hasLayout 문제 그리고 alt 속성 처리와 글꼴 크기 관련 문제는 Internet Explorer 7의 발표와 함께 험난했던 과거의 웹 개발 기록으로만 남게 될 듯하지만, 새로운 상황에 대처하기 위한 또 다른 골치거리들이 등장할 터이고, 따라서 의미론적 코딩과 웹 접근성에 관한 고찰 그리고 웹 표준에 대한 이해는 한결 더 중요하게 요구되어 질 것이다.
– 새로 덧붙임: 친절하게도 Robert씨는 자신의 블로그에 썼던 유능한 웹 인터페이스 개발자를 구할 때, 꼭 물어봐야 할 항목들에 대한 해답들을 올려놓았다. JavaScript에 대한 이해와 접근성에 끼칠 수 있는 폐해가 추가 덕목으로 더해졌다.
– 추가 참고의 글들
물론 여기에 소개된 꼼수들은 완전한 세상에 살고 있다면 불필요한 과정이겠지만, 냉험한 현실 속의 웹 브라우저들은 개발자들에게 차별 대우를 요구한다.
IE 7에서는 이제 CSS의 maxHeight 속성을 이해한다는 것을 이용해서, 다음과 같은 JavsScirpt 코드로 구별할 수 있다:
if (typeof document.body.style.maxHeight != "undefined") {
} else {
}
IE 7의 변화에 따른 다음과 같은 더 간단한 방법도 있다:
if (window.XMLHttpRequest) {
} else {
}
물론, 전통적으로 사용되어 왔던 MSDN에 자세하게 소개되어 있는 조건부 주석을 이용한 구별 방법도 유효하다:
... 기타 브라우져들을 위한 코드
덤으로, CSS 속성 이름 앞에 * 혹은 .(점) 그리고 _(밑줄)이 붙어있는 경우에는 브라우져들 마다 제각기 다르게 인식한다는 것을 이용해서 다음과 같은 방법을 사용할 수도 있다. (IE8의 경우 스타일 선언문 마지막에 꼭 “\9″을 붙여주어야 한다.):
#header {
margin: 10px;
margin: 12px\9;
*margin: 15px;
_margin: 20px;
}
* html #someDiv { color: red }
*+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 값을 지정하게 되면 밖으로 삐져나오는 부작용을 막을 수 있게 된다.