Category Archives: css

Cascade Style Sheets

windows firefox3 1px 버그

플래시를 페이지에 보여주기 위해 javascript를 이용하거나 object나 embed태그를 이용해서 표현을 한다.
그러나 z-index 때문에 혹은 다른 개발 사정으로 인해 iframe을 이용해서 표현 할 경우가 있는데 이럴때 firefox3에서는 일부 경우에 따라 플래시 좌측 1px을 표현하지 못하는 버그가 발생한다.
이 버그의 공통된 원인은 플래시를 감싸는 박스가 margin:0 auto;의 속성으로 가운데 정렬이 된 경우 발생하며, 박스의 width 값이 홀 수이거나 짝수 일 경우 발생하게 된다.
여기서 width값이 홀 수 이거나 짝수일 경우라는 것은 브라우저의 세로 스크롤 때문이다.(어쩌면 브라우저의 가로사이즈가 홀수이냐 짝수이냐의 문제일 수도 있다.)
감싸는 박스란 플래시에서 바깥의 어떤 박스든 플래시가 포함되어 있다면 어느 박스이던지 해당되며, 플래시와 가장 가까운 박스가 플래시에게 최종적인 영향을 가할 수 있다.
말이 어렵다면 그림으로 다시 확인 해 보자.
플래시 박스 예제1

위 그림을 보면 D를 제외한 A,B,C,F 박스에 어떤 박스이던지 margin:0 auto; 속성이 들어갈 경우 발생하게 된다.
문제는 박스의 가로 사이즈가 홀수, 짝수 모두 발생할 수 있기 때문인데 스크롤이 항상 있는 경우라면 가로 사이즈는 홀 수로 설정되어야 하고 스크롤이 항상 없는 경우라면 짝수로 설정되어도 된다.
하지만 이럴 경우는 거의 없다. 그리고 window XP의 테마가 고전이냐 XP테마 이냐에 따라서도 홀수, 짝수 기준이 달라지고 브라우저의 전체 가로사이즈가 홀수 이냐 짝수 이냐에 따라서도 달라지게 된다.

이 문제를 해결하기 위해서 현재까지 해결 방법으로는 플래시의 wmode를 window로 설정하는 것이 유일한 대안이지만 wmode의 window는 기본값이고 성능이 가장 좋다고는 하지만 플래시위에 레이어를 띄울 수도 없고, 아래쪽의 배경이나 요소가 보여지지도 않기 때문에 상황에 따라서는 해결방법으로 적합하지 않을 수 도 있다.

지금까지 왠만한 가운데 정렬되는 사이트에서 사용중인 iframe을 이용한 플래시가 눈으로 봤을 때 1px이 보이지 않는 불편함이 느껴지지 않았다고 생각되어, 특별한 경우가 아니라면 수정하지 않아도 문제는 없겠지만 분명한 것은 Firefox3 브라우저의 버그이기 때문에 이후 버전에서나 현재 버전 업데이트를 통해 수정 되었으면 하는 바람이다.

webkit계열 브라우저의 입력폼 outline, resize제어

미투데이 서비스는 글쓰기를 개편하면서 처음 글을 쓰려는 사용자의 사용성을 더 편하게 하고, 접근성을 높이기 위해 노력중이다.
개선사항 중 입력폼의 비쥬얼 적이면서도 실용도를 높일 수 있는 기능들을 탑제하다 보니 작게 만들어 놓거나 기능이 사용되고 실체는 드러나지 않게 배경색 위에 위장해 놓은 부분이 Webkit 계열(safari, chrome)브라우저 에서는 포커스가 위치하면서 실체가 들어나 버리게 된다…
(이런 테두리의 압박이…)

outline 예제

그래서 뭔가 저런 시스템 적인 기본기능처럼 보이지만 없앨 방법이 있지 않나해서 찾아보니 이런 경우엔 css2 스팩에도 있지만 IE에서는 지원하고 있지 않는 속성인 outline 속성으로 간단히 없앨 수 있었다.
코드는 아래와 같다.

textarea, input {
outline-color:-moz-use-text-color; outline-style:none; outline-width:medium;
}

참고로 위 속성을 사용하면 outline 속성이 firefox 에서도 적용되기 때문에 outline-color:-moz-use-text-color; 속성으로 색상을 지정해 줘야 한다.

그리고 추가로 사파리나 크롬에서 textarea 의 사이즈를 사용자가 마음대로 조절할 수 있는데 만약 이 기능을 막으려면 아래 코드를 넣어 간단히 제어할 수 있다.

textarea {
resize:none;
}

입력 폼 컨트롤러에 대한 제어는 일부 사용자의 입장에서는 다소 민감한 부분일 수 있다. 어떤 곳에서는 오히려 좋은 기능이 될 수 있으니 서비스에 맞게 사용하면 좋을 것 같다.

객체지향CSS가 무엇인고…?

갑자기 CSS에서 객체지향 이라는 말을 붙이니 뭔가 어색하다.
웹 표준이 대두되고 CSS의 활용 범위가 전에 없던 개발, 디자인 까지 도움을 줄 정도가 되면서 이제는 객체지향적인 기법(?) 내지는 객체지향 이라는 말까지 붙일 수 있게 된 것이라 생각되지만, 아직까지 객체지향CSS가 뭔지 정확히는 잘 모르겠다.
프로그래밍에서 말하는 클래스, 메소드, 상속, 오버로딩, 오버라이딩, 다형성, 추상화 등을 CSS에서도 찾는 것일까? 확실히 알 수 있는 것은 프로그래밍에서 말하는 그 정도의 개념은 아닐 것이라는 거다.
어쩌면 이미 우리가 CSS를 활용하는 방법이 객체지향CSS였을 수도 있고 그러한 방식이 올바른 CSS 사용법으로 적합하다고 알고 있는지도 모르겠지만 stubbornella의 OOCSS(객체지향CSS) 에서 강조하는 몇 가지 사항은 이렇다.

OOCSS를 위해 권장하는 것들

  • 재사용을 위한 component library를 만들어라
  • 스타일을 정의할 때 의미있고 일관되게(모순없이) 정의해라
  • grid를 활용해라
  • 유연하게 만들어라
  • 구조와 표현을 분리해라
  • 박스와 내용을 분리해라
  • 다수의 class를 사용하되 속성의 중복은 피하고 속성의 종류는 확장해라

OOCSS를 하기에 적합하지 않는 것들

  • 위치에 독립적인 스타일은 피해라
  • div.style01과 같이 tag에 class를 지정하는 방식을 피해라
  • 본문안쪽 영역은 ID로 style 하는 것을 피해라
  • 불규칙한 배경(불규칙무늬, 그라데이션)이라면 그림자나 라운드코너 박스를 피해라
  • 높이를 이용한 줄맞춤(간격설정)은 피해라
  • 원본은 언제나 텍스트라는 것을 잊지 말아라(이미지만으로 표현하지 마라)
  • CSS 설정이 중복되지 않게 해야 한다
  • 성급한 최적화는 피해라(충분한 테스트가 필요하다. 장담할 수 있는가?)

이런 내용만 봐도 객체지향CSS가 무엇을 말하려고 하는지 대충 짐작은 된다.
하지만 짐작만으로는 뭔가 시원하게 풀리지 않기에 위 사이트에서 말하는 CSS를 보다 완벽하게 구축하기 위한 상세한 내용을 살펴보면 아래와 같은 내용이 있다.
(사실 내용을 살펴보면 CSS에 대한 그리고 웹 개발에 대한 올바른 인식과 소통법에 대한 충고이거나 격언을 말해주는 부분 이기도 했다.)

CSS에 대한 인식
CSS는 전문적이여야 한다는 것을 말 하고자 한다.
(그렇다고 완벽함을 바라는 것은 아닐 것이다.)
웹 개발 실무자들 사이에서 CSS에 대한 인식이 얼마나 있을까? 현재까지 전문적인 직업으로 여기는 사람들이 그리 많지 않고 개발, 디자인 사이에서 아직까지 애매한 역할을 하고 있는 것이 사실이다.
그렇기 때문에 더욱 명료하고 전문적인 코드가 될 수 있을 법한 CSS가 대충 아무렇게나의 코드가 되는 것은 아닐까? 라는 생각이 든다.

분리
웹 표준에서 항상 강조하는 것이 구조와 표현을 분리하는 것이라고 말하고 있다. 그러나 객체지향 CSS를 위해서는 내용과 내용을 담는 컨테이너도 분리하는 것이 좋다고 말하고 있다.
내용과 컨테이너를 분리하므로 해서 내용이 특정 위치에 있을 때만 스타일링 되는 것이 아니라 페이지의 어느 곳에서도 표현(위치)하기에 자연스러울 수 있도록 하기 위한 규칙이 아닐까 생각된다.

재사용
디자인에 필요한 component library를 만들어 놓아야 한다.
다양한 페이지를 만들기위해서는 미리 만들어진 구성요소들을 이용해서 조합할 수 있는 것이 가장 중요할 것이다.
어쩌면 이것이 핵심이라 생각된다. YUI를 보자면 객체지향CSS가 무얼 말하는 것인지 단번에 떠오르지 않을까? 일단 모든 구성요소가 정의되면 필요한 디자인은 페이지 마다 필요한 구성요소를 가져다 쓰기만 하면 된다.
(준비된 Lego를 이용해서 다양한 모형을 만드는 것을 비유하고 있는데 꾀나 적절해 보인다. :D)
그러나 재 사용할 수 있는 코드가 있더라도 현실적으로 재 사용이 잘 이루어 지고 있지 않다.
왜냐하면 대부분의 개발자들은 다른 개발자의 코드를 잘 신뢰하지 않기 때문이다.
물론 그로 인해 CSS 코드가 추가되지만 실제로 이런 추가코드는 대부분 별 문제가 없겠지 라고 느끼는게 대부분이다.
하지만 지속적인 CSS의 추가는 그 만큼 파일 사이즈도 증가한 다는 것을 알아야 한다.

곤란할 수 있을 요소를 없애라
만약 h3선언과 h5선언이 똑같은 역할을 하고 있다면? 만약 가변적인 박스에 수직,수평의 변화되는 배경이 깔리거나 라운드 박스 뒤 배경이 변화되는 이미지라면?
웹페이지를 구성하면서 가장 불필요한 시간을 잡아먹는 것이 있다면 이런 곤란한 요소들 때문에 고뇌하고 또 고뇌하는 게 아닐까 생각된다.
정말 필요한 경우가 아니라면 미리 자주 일어날 법한 곤란한 일들은 미리 체크하고 피하는 것이 좋다. 이런 일들은 주로 경험에서 많이 나온다. 그럴때 마다 체크하고 다음 프로젝트를 위해 유용하게 사용될 수 있도록 기록하는 것은 중요한 정보가 될 수 있다.
여기서 말해주는 몇 가지 리스트도 참고할 만 하다.

  • 중복되는 스타일 설정을 피해야 한다.(규칙을 겹쳐쓰지 마라)
  • 표제는 순서대로 선언해야 한다. 잘 못 측정 하면 처음부터 끝까지 계속 잘 못 된다.
  • 어림짐작을 피해라.
  • 일관적인 의미의 스타일을 사용해야한다.
  • 표제가 페이지의 다른곳에 위치하면 안된다.

사실 위 내용을 읽으면서도 어떻게 해야할 지 대략적인 그림이 머리에 그려는 지지만 실현되지 않는 현실때문에 항상 이상으로 남는 것이 대부분이라 생각된다.
하지만 이런 내용들을 CSS를 제작하는 사람들만 알고 있다면 아무것도 해결 되진 않는다.
CSS는 아직 완벽하지 않기 때문에 Grid를 이용하여 레이아웃과 구성요소의 범위 구성을 미리 디자이너, 기획자와 함께 맞춰보고, 디자이너와 개발자에게 CSS에 대한 정보도 공유된다면 유연한 CSS개발에 한걸음 더 올라설 수 있지 않을까 생각해본다.

참고

Grid 디자인을 도와주는 Boks

웹 페이지를 제작하기 전 시각적인 Grid를 우선 잡아보고 컨텐츠의 범위나 요소의 배치를 대략적이라도 알 수 있게 해주는 어플리케이션이 나왔다.
비슷한 류의 blueprint 처럼 규격화된 Grid를 기준으로 요소별 템플릿들을 제공해주는 프레임웍이 있었지만 Boks라는 프로그램은 미리 그리드를 짜 볼 수 있고 실제 html 과 css 파일로 저장할 수 도 있다.
air로 되어 있는데 이젠 플레시 플레이어가 낮으면 이런거 설치도 힘들겠네 ㅋㅋ;

boks 예제

컬럼을 규칙적으로 분배하여 짜여진 판에서 컨텐츠를 그려보는 건 html 과 css를 이용하여 페이지를 제작하는 입장에서 계산하는 수고를 많이 덜 수 있는 매우 필요한 부분이다.
사실 이런 방법들은 디자이너도 함께 알면 금상첨화인데.. 미리 디자인을 짜기전에 사용해 본다면 좋지 않을까 싶다.
screen, print, IE 용 css를 별도로 분리해서 제공해주는 센스를 발휘하고 있다..-_-ㅋ

관련 링크 : http://www.thegridsystem.org/

Acid2 Test 통과한 IE8은 이제 한걸음 걸었을 뿐이고..

곧 정식 버전이 출시될 IE8은 처음 beta 버전이 배포되고 현재 RC1까지 많은 기사와 블로그 글들에서 성능 향상과 Acid2 Test를 통과해 웹 표준을 준수한 브라우저라는 이야기를 많이 실어놓고 있다.
Acid2 Test는 웹 페이지를 웹 표준에 맞게 제작했는지 검증하기 위해 HTML, CSS 검증기를 통과하는 것과 마찬가지로 브라우저가 얼마만큼 웹 표준 규격에 맞춰서 제작되었는지를 알아보는 방법 중에 한 가지라고 할 수 있다.
물론 가장 좋은 방법은 W3C에서 필요한 최소한의 권장사항을 모두 준수한 브라우저라고 하고 그것을 증명할 문서와 브라우저가 출력하는 결과로 증명할 수 있다면 속 시원하겠지만 그렇게 잘 차려진 밥상은 찾을 수 없으니..(사실 잘 못 찾겠다. 누가 좀..;)

그렇다면 Acid2 Test는 어떤 것을 검사를 할까?
acid2 test

이미 Acid2 Test는 작년, 제작 년에 줄기차게 다른 브라우저들이 통과하면서 많이 다뤘던 내용이라 좀 식상하지만..
IE8은 이제 처음 통과 한 것이니 다시 정리 해보면 Web Standards Project에서 제공하고 있는 Acid2 Test는 크게 대략 11가지 항목을 검사한다고 한다.

  • png요소 : 테스트 결과 중 눈 부분에 사용된 이미지가 png이며, 이미지가 제대로 출력 되는지 테스트 한다.
    acid2 test png
  • object요소 : 오브젝트 요소를 인식 하는지 테스트를 하며 오브젝트 안에 대체 컨텐츠(object포함)역시 인식하는 것을 테스트 한다. 이 테스트가 통과되면 IE8에서는 중첩 object와 object 안에 대체 이미지 및 컨텐츠를 표시해 줄 수 있다.
  • absolute, relative, fixed position : 레이아웃에 자주 쓰이는 position속성이 가능한 정확한 위치를 잡을 수 있는지를 테스트 한다. 이 테스트가 통과되면 더 이상 다른 브라우저와 position 위치 차이로 인해 css hack을 사용하지 않아도 된다.
  • box model : 기존 css box model 모델을 기준으로 한 테스트에서 width, height, max-width, min-width, max-height, min-height 항목을 추가한 테스트 이다.
  • css table : 테이블 태그를 이용한 레이아웃은 잘 못 된 표현방법 이기 때문에 css에서는 table처럼 레이아웃을 구성할 수 있도록 속성이 준비되어 있다. 기존 IE에서는 이 속성이 지원되지 않았지만 IE8에서는 이제 속성이 지원 되므로 의미는 더 명확하게 정할 수 있고 표현은 더 자유롭게 할 수 있게 되었다.
    acid2 test diaplay table
  • 여백 : css를 이용한 여백 계산이 얼마나 정확한지 테스트 한다.
  • 컨텐츠 생성 : 마크업을 수정하지 않고도 장식이나 주석을 추가할 수 있는지에 대한 테스트 이다. 이 항목은 확실하지 않지만 아마도 before, after, content 속성 지원에 대한 테스트를 말하는 것 같다.
  • CSS 파싱 : 알려지지 않은 css에 대해 무시할 수 있는지 테스트를 한다고 나와 있다. 그래서 그런지 이전 IE용 css hack은 더 이상 인식하지 않는다.
  • 표현 순서 : 표현에 있어 겹쳐지거나 중복되는 컨텐츠에 대한 표현 순서를 올바르게 지정 할 수 있는지에 대한 테스트 이다.
  • Line Height : inline요소의 box model중 일부 속성들의 브라우저 독립적인 속성값에 대한 테스트 이다. 이 테스트에서 일부라는 게 어떤 것 인지 정확하게 알 수 없지만 line-heigh와 vertical-align에 대한 테스트가 아닌가 생각된다.
  • 마우스 효과 : Element의 :hover class 속성이 적용 되는지 테스트 한다. 결과 페이지에서 코 부분에 마우스를 대면 색이 변하게 되는 것 인데 아마 이 부분에 대한 테스트가 아닌가 생각된다.
    acid2 test :hover
    IE8은 이 속성을 비롯해서 기타 다른 pseudo-class에 대한 지원범위도 넓어 졌다. 더 자세한 내용을 보려면 IE CSS 지원 차트를 확인하면 된다.

IE8이 Acid2 test는 통과 했다고 하지만 Firefox나 safari, opera 보다 사용율이 높은 IE 하위 브라우저들에 대한 대응은 계속 해야 한다는 문제가 남아 있다.
어찌 보면 또 하나에 브라우저가 더 추가되었다는 느낌 밖에 들 수 없을 테고 하위 브라우저 이용 율이 어느 정도 유지되는 동안은 IE8의 개선된 기능에 맞는 속성을 무턱대고 사용하는 것은 컨텐츠 접근이나 사용에 문제가 될 수 있으니 IE conditional comment 와 같은 방법을 사용하거나 충분한 테스트 후 페이지를 제작하는 것이 바람 직하다 할 수 있겠다.

이와 더불어 IE8에서 개선(?) 달라지는 사항들을 정리해 보면.. 아래와 같은 내용도 있다.

Haslayout 삭제
CSS2.1을 모두 지원하고 Acid2 Test를 통과 함으로 IE 자체 레이아웃 방식인 Haslayout기능은 더 이상 사용 하지 않는다고 한다.
이로 인해 IE8에서는 float으로 발생되는 버그나 박스 모델에서 width, height 값 인식 버그, margin 겹침 문제, position 위치가 다른 문제 등이 더 이상 발생 하지 않게 되었다.

Charset에 따라 글 간격 달라지는 문제 해결
IE(5,6,7)에서는 charset의 종류에 따라 글 간격(행간)이 달라지는 문제가 발생한다.
이 경우 가장 대표적인 문제는 텍스트 언더라인 문제와 상하 여백 문제인데 IE8에서는 Charset에 따라 텍스트 간격 차이가 없어 졌다.
하지만 텍스트 언더라인과 텍스트가 붙는 문제는 여전히 발생을 하는데 이 부분은 폰트 고유의 문제이며 중대한 문제가 아니라고 판단되는지 개선하지는 않고 있다.

브라우저 모드, 문서 모드 설정
표준을 준수한 IE8은 하위 브라우저와의 여러가지 차이가 발생 할 가능성이 있다.
이로 인해 개발자들과 사용자들에게 혼란을 줄 수 있기 때문에 하위 브라우저 호환성을 유지할 수 있는 설정 방법이 있다.
하지만 사용자 역시 브라우저에서 기본으로 제공되는 개발도구를 열어 브라우저 모드나 문서 모드를 마음대로 조작 할 수 있기 때문에 하위브라우저와 IE8을 모두 대응하기 위한 방법을 찾는 것이 더 좋을 것 같다.
(물론 사용자 조작으로 인한 변화의 책임은 사용자의 몫 이겠지?)

form 컨트롤러 자체 여백 문제 해결
모든 요소의 자체 여백은 해당 브라우저에 종속적이고 form 컨트롤러는 OS와 브라우저의 영향을 받는 부분이다.
하위 IE 브라우저에서는 다른 브라우저와 달리 form컨트롤러들이 css초기화를 하였음에도 불구하고 보이지 않는 자체 여백을 계속 지니고 있었지만(1px 테두리라고 해야 할까..) IE8에서는 이 부분이 개선되어 더 이상 자체 여백은 가지지 않는다.

Printing css 지원
기존 IE 브라우저는 프린트 페이지 여백 설정이 화면과 다른 결과로 출력 되었다.
이 때문에 미리보기나 출력을 하면 원하는 결과를 볼 수 없었는데 IE8에서는 이런 여백 문제가 개선되었을 뿐만 아니라 CSS2.1을 지원하기 때문에 print style 속성을 지원한다. 이 기능으로 인해 IE8브라우저에서는 프린트 페이지의 여백 설정이나 페이지를 나누어서 표현하는 다단기능과 같은 기능도 사용 할 수 있다.

IE8 확장 CSS 지원
IE8에서 자체적인 css 확장 속성을 제공하고 있다.
이 속성들은 현재 IE에서만 지원하는 css속성과 css3에서 지원될 속성 들을 IE8에서 사용할 수 있도록 하는 속성들이며, IE8만을 위한 전용 css로 사용 된다고 생각 할 수 있다.
아직 완전히 지원되고 있지는 않지만 내용 확인은 가능하다.
microsoft css vendor extensions
IE CSS Extension?

링크 url 값에 따라 :visited 인식안됨 문제
이 문제는 IE7부터 발생하던 문제였지만 IE8에서도 개선되지는 않고 있다.
방문한 url에 따라 :visited 인식이 되어야 하는 것은 당연하다고 생각하지만 IE7과 8은 url의 값이 스크립트로 구성되어 있거나 #이 들어가 있을 경우 디자인보안 문제로 인해 고의로 막았다고 하니 조금 힘이 빠지네..
링크의 :link와 :visited에 대한 구분 기준은 있지만 url의 어떤 값에 대한 정의는 특별히 없기 때문에 이 문제에 대한 정확한 정의를 내릴 수는 없어서 이런 문제가 생기는게 아닌가 싶고, 그다지 보편적으로 큰 이슈가 될 만한 문제가 아니라 생각되어서 그런지 이 부분도 역시 바뀔 것 같지는 않다.
하지만 방문 했다는 기준에 대한 :visited는 정의 내려야 하는 게 맞지 않나 생각된다.

여전히 하위 IE 브라우저 때문에 고생하고 있을 분들에게는 IE8의 출시가 어떤 영향을 줄지 궁금하지만 조금씩 더 나아지고 있는 IE와 점점 사용층이 IE6 에서 IE7 로 바뀌고 있으니 곧 IE8도 대중화 되길 바라는건 내 바램만은 아닐 것이다.
웹 표준 뿐만 아니라 기능향상과 IE8의 새로운 기능과 내용에 대해 궁금한 부분이 더 있다면 이 세미나에서 더 많은 내용을 얻을 수 있을 것이다.