Category Archives: web developer

웹개발

객체지향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개발에 한걸음 더 올라설 수 있지 않을까 생각해본다.

참고

웹 접근성을 고려한 신기술 콘텐츠 제작기법 공유

한국정보문화진흥원에서 “웹 접근성을 고려한 신기술 콘텐츠 제작기법” 이라는 가이드를 공개 했습니다.

이 가이드는 RIA콘텐츠를 개발하기 위하여 고려해야 하는 규정과 예를 제시하고 있다고 합니다.
HTML과 CSS만으로 표현하던 예전과 달리 콘텐츠의 상호작용을 동적으로 하고 데스크탑 프로그램과 같이 복잡한 기능구현을 가능하게 해주는 RIA기술을 요즘 많이 사용하고 있지만 기존의 콘텐츠 접근성 표준지침은 RIA기술을 이용하여 구축한 동적 콘텐츠에 대하여 표준 기준을 적용할 수 없게 되어 있었지만 이 가이드로 부가어플리케이션의 접근성이 좀 더 좋아 지길 기대해 봅니다.

국내 지침에는 실버라이트 내용이 없어서 실버라이트 개발자나 MS분들은 씁쓸하겠네요…;;
RIA 개발자분이라면 한번쯤 읽어 보시면 좋을 것 같습니다. 🙂

관련 W3C 자료

IE8 신규기능

올초 3월부터 시작된 IE8 beta1과 8월에 beta2, 9월 한국화버전까지 MS의 Internet Explorer(IE)도 버전업그레이드와 브라우저 변화에 노력중이다.
변화의 대표적인 예로 크로스브라우징을 맞춰야 하던 분들이 골머리를 앓고 있던 IE만의 렌더링 방식인 haslayout지원을 IE8에서는 더이상 적용되지 않도록 버리고 표준모드와 Quirks mode의 렌더링이 제작자의 의도와 맞도록 맞추고 있고, Firebug와 같은 디버그 툴의 사용 용도가 높아서 인지 IE8에서는 기본으로 기존에 개발자도구(Developer Toolbar)를 탑제해서 설치되고 있다.
이외 브라우저 충돌시 자동으로 복구를 해주는 기능이 있는데 개인적으로 이 기능은 좋은 인상을 주지 못하고 있는것 같다. 다음과 같은 상황이 있다면 말이다.. 예를들어 사이트에 들어가자마자 충돌이 나는 사이트가 있다면 브라우저를 자동으로 복하기 때문에 브라우저가 복구 된다고 한들 또 오류가 나고 또 복구 하고…. 무한으로 반복하기에 결국 브라우저를 종료시키지 않고서는 상황이 끝나지 않을것 같기 때문이다.
좋고나쁨을 아직까지 정확히 판단하기는 어렵지만 beta인 만큼 여러 시도로 다양한 기능과 개선사항을 보여주고 있는것 만은 사실이기에 기대가 되기도 한다.

신규기능
최근 브라우저들은 속도개선을 주로 내세우며 사용자들이 보다 더 빠르게 브라우저를 이용할 수 있는 것에 집중을 하고 있다.
IE브라우저는 웹표준도 웹표준이지만 이런 면에서도 유난히 좋은 인상을 주지 않는 것이 사실이지만 사용자의 이용율을 무시할 수는 없는 거의 절대적인 비율이기 때문에 이런 추가되는 기술이나 신규기능에 대해서 민감하지 않을 수는 없다.
IE8에서 내가 관심있는 신규기능은 Accelerator, Webslices이며, 두 신규 기능에 대한 간단한 설명과 현재 서비스에서 적용시 고민해 봐야할 문제에 대해 이야기 해보려 한다.
참고로 추가되는 새로운 기능이나 기술은 IE8 백서에서 더 자세히 찾아볼 수 있다.

Accelerator
Accelerator(액셀러레이터)는 beta1에서 Activity로 소개되었던 기능에서 이름이 변경된 것이다.
정보를 하나의 서비스로만 이용하지 않고 서비스 제공자가 규격화 된 xml코드를 이용해서 제공해 놓은 다양한 서비스들로 다르게 접할 수 있도록해주는 기능이다.
쉽게 이야기해 정보서비스를 이용함에 있어 사용자가 다양한 서비스를 끊김없이 이용할 수 있도록 제공해 주는 기능이다.

Accelerator 데모화면

예를 들자면..
기존에는 현재 보고 있는 웹페이지에서 다른 관련된 정보나 서비스를 이용하기 위해서 관련 키워드나 웹사이트 주소를 복사하거나 외워서 브라우저 주소창에 치거나 검색폼에 작성후 검색하고 원하는 서비스 페이지로 이동하는 방식이였다.
하지만 액셀러레이터 기능을 이용한다면 이런 절차를 줄여줄 수 있다. 액셀러레이터는 현재 페이지에서 관련 키워드나 페이지 그 자체를 자신의 브라우저에 추가된 액셀러레이터를 이용해서 바로 이용할 수 있도록 하고있기 때문이다.
위에서 이야기 했던것 처럼 사용자가 정보를 이용함에 있어 불필요한 절차를 조금이라도 줄여줄 수 있도록 해 주는 기능이라 할 수 있지만 이 기능에도 약간에 문제가 있다.
하나는 해당 서비스를 제공하기 위해 서비스 제공자는 서비스 페이지 어딘가에는 액셀러레이터를 설치할 수 있는 링크를 제공해야 한다. 한번은 설치를 해야 한다는 것이다.
다른 하나는 마우스 오른쪽 클릭이 제한된 곳이나 드래그로 컨텐츠의 하이라이트가 제한된 곳에서는 제한을 풀어야 할지 말아야 할지에 대한 고민이 생기게 된다는 것이다.
액셀러레이터는 키워드를 드래그 했을때 액셀러레이터 버튼이 활성화 되거나 마우스 오른쪽 버튼을 이용해서 사용하거나 브라우저 상단 페이지 메뉴에서 이용할 수 있게 되어 있다. 일반 적으로 가장 편한 방식이 키워드를 드래그 후 나타나는 메뉴를 이용해서 사용하는 것이 가장 좋겠지만 어떠한 이유에 의해 이런 기능을 막아놓은 사이트라면 액셀러레이터를 위해서 풀지 고민이 생기게 될 것이다.
액셀러레이터는 검색,사전,지도,메일 등 카테고리의 구분만 명확하다면 다양한 서비스와 연동을 할 수 있기에 그 매력이 상당히 높아 보이지만 위의 사항에 문제가 생긴다면 쉽지 않은 고민이 생길거라고 생각된다.

Webslices
Webslices(웹슬라이스)는 MacOS의 Webclip widget과 똑같다는 생각이 들었다.

Webslices 데모화면

hAtom 마이크로포맷 기술을 이용해서 서비스 제공자가 사용자에게 이용하고 싶은 콘텐츠만 쉽게 전달할 수 있도록 해주는 기능으로 사용자 입장에서는 즐겨찾기와 유사하게 취급되나 RSS의기능과 같이 정보갱신을 인식해 항상 최신정보를 유지하며 정보를 이용할 수 있게 해주며 정보제공자는 기존 마크업을 이용해서 제공할 수도 있다는 장점이 있다.
단순히 html만을 이용해서 제공할 수 있기 때문에 편리하지만 웹슬라이스 역시 고민해야할 점이 없는것은 아니다.
첫째로 기존 html 구조가 웹슬라이스를 제공하기위해 적합하지 않은 구조라면 웹슬라이스를 구현하기 위한 최소한의 골격을 마춰야 하는 단점이 있다.
두번째 문제는 사이트를 접속하지 않고 원하는 정보만 볼 수 있다는 장점은 사이트 접속으로 인한 수익(광고나 연동되는 기타서비스)을 추구하던 서비스에서는 그리 적합하지 않은 기능이기 때문이다.
때문에 ebay와 같은 상품의 꾸준한 정보갱신을 원하는 사용자가 많은 서비스라면 꾀나 적합한 기능이라 생각되지만 다양한 정보를 한곳에 다 표현하고 있어 정말 필요할것만 같은 한국의 포털메인 사이트와 같은 곳에서도 과연 좋은 기능일지 고민해봐야 하지 않을까 생각된다.

끝으로
Accelerator와 Webslices가 매우 매력적인 기능인건 분명하다.
beta지만 벌써부터 대응하고 있는 사이트도 생기고 있고.. 이런 현상은 IE가 단순히 사용율이 높기 때문만은 아닐 것이다.(정말 이런 기능이 필요했던 사이트도 있을 것이고…)
지금은 접목하기 힘든 서비스라도 기존 서비스를 잘 연구한다면 좋은 방향으로 사용할 수 있지 않을까 생각된다.
참고로 ebayAuction에서는 벌써 대응을 하고 있는중이고 꾀 잘 사용하고 있다고 보인다.

IE8 신규기능 개발가이드

미래 웹 포럼에 다녀오다.

지난주 금요일(3월16일)에 “글로벌 웹 기술 워크샵” 이라는 주제로 워크샵이 있었다.

처음 이 워크샵을 신청할때는 내 관심과는 좀 다른 내용으로 진행되는줄 알았지만 행사장엘 가서야 가장 궁금했으며 관심을 가졌던 부분들에 대해 발표했었다.

현재 가장 많이 알려진 브라우저 제조사(?)에서 나와서 발표를 했으며 각 대표로 나오신 윤석찬님(Firefox), 김국현님(Internet Explorer), 왕수용님(Safari), 조만용(Opera)님 외 준비하신 모든분들이 수고해주셨다.

다음날 지방으로 결혼식을 다녀오고 업무가 바쁘다는 핑계로 후기가 좀 늦은감이 있는듯하다… 빨리 놋북이나 맥북을 빨리 휴대해야 할 터인데 ㅠ_ㅠ

지루지루지루한일상

이직을 한지 어느덧 2주가 훌쩍 흘러버렸다.
회사를 옮기자마자 바로 일에 투입되어서 진행은 하고있지만 도통 내가 지금 뭘 하고있는건지..;;
전에도 사이트를 웹표준사이트로 개편한답시고 진행했었지만 내가 본 그 사이트는 새옷만 입었을뿐 알맹이는 썩어들어가는 사이트고, 지금 진행중인 사이트는 그야말로 판타지 소설을 쓰고있는중이다…

처음 사이트를 훑어 봤을땐 “아..퍼블리셔(코더)들이 좀 협업할때 뭔가 안맞았나? 스타일가이드는 완전 무시됐네?” 라고 생각했었지만 지금은 이해가 갈만하다. 난 이 프로젝트에 그리 큰 비중을 차지하지않고 관여가 덜 되어있어서 다행이지만 내가 표준코딩+css 개발 작업자였다면 현업 담당자들 한 이틀 잠도 안재우고 공부부터 시켰을지도..

자세한 전후사정은 모르지만 우선적으로 내가 본 이 프로젝트의 현헙담당자들의 표면자세는 대략 이렇다…
담당자는 웹표준에 전혀 알지도 모르고 그저 레이어코딩이라고만 알뿐이고, 스타일 가이드가 있었음에도 불구하고 이미 거의 8~90%가 진행된 프로젝트에서 디자인적 수정사항을 전혀 규칙에 맞지않게 그때그때 기분에따라 혹은 보이는 화면에 분위기에 따라 그렇게 바꿔달라고 요구하는 실정이니.. 구조와 표현의 분리에서 효율성을 전혀 생각하지않는 그저 이런식의 코딩만 머리에 떠올린 수정사항이라고 밖에 생각이 안되는것이다.

내가 예전 작업한 사이트는 공공기관사이트라서 공공기관웹접근성지침이라던지 위에서 내려오는 지침을 그대로 따라야만 했기때문에 억지로라도 지키기위해 했다고 본다면 적어도 그에 맞게 만들고나서 유지관리를 할 수 있는 자세는 되어야하지 않겠나.. 생각되고,
지금 하고 있는 프로젝트도 마찬가지다 로그인자체가 IE밖에 할 수 없도록 Active-x 로 동작하게 해놓고선 웹표준으로 작업해달라고 했다던 이유도 모르겠거니와 프로젝트가 끝났을때 유지관리할 사람도 마련되지 않은상태에서 전혀 이해가 가지않는 수정요구만 해대는 이상황에서 왜? 끝까지 css와 마크업을 분리해달라고 하는건지.. 사이트 용도가 사내인트라넷임에도 불구하고 왜 html 과 css 를 분리해달라고 하는건지..(분리를 했는데 왜 css 파일마다 100kb 가 넘어가는게 많은지..-_-;; css파일이 50가지가 넘는건 또 뭔지..)

이러다 올해 블로그 글들은 죄다 울화통 터져서 올린 글 밖에 없는거 아닌지 모르겠다..ㅠㅠ
까칠하고 답답하고 답답해서 일이 손에 잡히지 않고 한숨밖에 안나온다..
그냥 나도 현실에 적당히 마춰주며 살까나..? ㅋㅋ;
요즘은 이런 코메디같은 나날인데 의외로 지루하다..