레이블이 CSS인 게시물을 표시합니다. 모든 게시물 표시
레이블이 CSS인 게시물을 표시합니다. 모든 게시물 표시
2021년 9월 26일 일요일

2020년 CSS 사용 경향

The State of ~ 시리즈의 2020년 자료를 조금만 훑어보고 정리하자. 시간이 조금 지났기는 했지만 지금도 유의미하게 도움이 될 것이다.

The State of CSS


먼저 The State of CSS다. 2020년도에 CSS 개발자들의 생각을 다양한 통계를 통해서 엿볼 수 있다.


우선 The State of CSS 설문에 참여한 사람들 대부분은 영미권에서 CSS를 다루는 개발자들이다. 이를 감안하고 아래의 통계를 들여다 보자.


설문에 참여한 사람 절반 정도가 프론트엔드엔지니어였다. 그 다음 27.5%가 자신을 풀스택 엔지니어라고 했으며 세번재로는 17.2%의 사람들이 웹개발자였다.

예상대로 프론트엔드엔지니어들은 CSS를 능숙하게 다루어야 하니 가장 많은 사람이 CSS를 쓴다고 했다. 백엔드 개발자들은 고객과 만나는 최접점에 있는 화면단 기술인 CSS에는 무관심하였다. 의외로 UI/UX 디자이너들이 CSS를 다루는 사람이 적었다. 영미권에서도 이들은 그래픽 도구로 그림이나 화면 그리기만 끝내고 자신들의 할일을 끝내나보다.


70%에 가까운 사람들이 2010년 이후에 CSS를 다루기 시작한 사람들이다. 확실히 프론트엔드 쪽의 인기는 젊은 사람들에게 높다. 주니어들이 시니어들보다 더 잘 하는 분야이기도 하다. 10년에서 20년 정도 경력이면 나이대가 30대 후반에서 50대 초반인텐데 오랫동안 짬밥을 먹은 시니어들이다. 20년 이상인 사람들은 WWW이 시작할 때부터 이 분야에서 밥벌이를 한 사람들이다. 노년기에 접어든 사람들이 많을텐데 여전히 현역에서 뛰고 있는 게 대단하다. 우리나라도 이렇게 변해야 한다고 생각한다.


CSS 마스터 레벨 즉, CSS의 모든 선택자와 규칙에 대해서 90~100% 수준으로 다 알고 있다고 답한 사람이 5.5%나 된다. 정말 대단하다. CSS 마스터라고 자부하는 나도 가끔 신기한 선택자와 규칙들을 발견할 때가 있다. 그래서 100% 다 안다고는 절대로 말하지 못한다. 그런데 100%라고 대답하는 분들이 저렇게나 많다니 역시 세상은 넓고 고수는 많다.

지표를 보면 많은 CSS 개발자가 CSS의 전체 규칙 중에서 절반 조금 넘어서는 수준만을 알고 있거나 이해하고 있는 듯 하다. 물론, 실무를 하다보면 모든 걸 알아야 할 필요는 없다. 자주 사용하는 규칙들은 대부분 정해져 있고 한정적이다. 그래서 저 정도만 안다고 해서 특별히 실무를 하는데 큰 장애는 없을 것이다. 다만 하나라도 더 알면 어렵게 처리할 작업도 손쉽게 끝낼 수 있을 것이다.


분야별로 많이 쓰는 기능들을 묶은 것이다. 희미한 부분은 '기능을 사용하는 방법에 대해 알고 있다'는 것이고 그 안에 진하게 칠해진 것은 '실제 실무에서 사용한 적이 있다'는 것을 표시한다.

좀 의외인데 CSS를 다루는 사람들 대부분이 애니메이션과 관련된 기능을 굉장히 많이 알고 있고 또, 잘 쓰고 있다는 것이 놀랍다. CSS의 주된 기능은 일단 애니메이션 기능이 아니기 때문이다. 시맨틱하게 잘 구성된 네이키드 HTML 문서를 이용자들이 보기 좋게 옷을 입히는 것이 CSS 사용의 주된 목적이다.

그래서 기본적으로 당연히 사용해야 하는 font-family나 예전에는 float로 처리했지만 요즘은 레이아웃을 잡는데 flex를 많이 사용하니 저것들의 사용량이 높고 CSS 개발자들의 지식 수준이 높은 것도 이해는 한다. 애니메이션은 정말 의외였고, CSS를 이용해서 사용자 인터렉션이나 동적 효과를 주기 위해서 애니메이션을 조금 더 적극적으로 활용할 필요가 있겠다고 느꼈다.

Transitions, Transforms는 94%가 넘는 높은 사용률을 보였다. Animations도 91%가 넘는 이용자가 이용했다.


다른 건 나도 종종 쓰고 익숙한데 perspective라고 하는 신기한 프로퍼티가 보인다. 원근법이라고 하는데 완벽한 3D 기능을 구현할 수 있는 건 아니지만 이 기능을 사용하면 Z 축을 하나 만들어서 거리감을 표현할 수 있게 도와주는 것 같다. 나도 아직 완벽하게 이해는 안됐지만 대충 그런 것 같고 따로 시간을 내서 이 프로퍼티에 대해서 공부를 해봐야 할 것 같다. 잘 쓰면 재미있는 효과를 낼 수 있겠다. MDN Web DOC에 소개된 perspective


@font-face는 외부 폰트를 쓰려면 사용해야 하니 거의 대부분의 프로젝트에서 사용되는 듯 하다. line-break 프로퍼티는 CSS3에서 새로 추가된 것인데 CJK(한중일) 문장의 줄바꿈을 할 때 유용하다. 글자나 문자가 애매하게 잘리면 보기 싫게 되기 때문에.


calc()의 사용률이 92%에 육박할 정도로 올라왔다. 이제는 CSS 개발자들도 calc()를 능숙하게 쓰는 듯 하다. 예전에는 자바스크립트를 써야 했던 일부 계산을 calc()를 사용하면 CSS로 바로 처리할 수 있다. 예를들어서 가변적인 너비를 가진 컨테이너 안에 들어있는 block 엘리먼트의 너비가 컨테이너보다 항상 20픽셀 작은 상태에서 변동하길 원한다면 width: calc(100% - 20px)이라고 사용하면 된다. 정말 간단하다. +, - 기호 사이에는 공백이 있어야 한다.


사용하는 치수 단위는 당연하게도 고정값을 위한 px와 유동값을 위한 %가 가장 많다.

그 다음 vh, vw, em, rem은 모바일 기기나 반응형 웹에 대응하기 위해 많이 사용하는 치수들이다. vh와 vw는 각각 높인와 너비를 100등분 하여 기기의 높이나 너비 대비 얼마의 치수를 만들 것이냐 하는 것이고, em과 rem은 루트 엘리먼트의 폰트 크기로 부터 폰트 사이즈를 상속받아 폰트 사이즈를 반응형으로 대응하는데 사용된다. 실제로 모바일 페이지를 만들 때, px와 em, rem이 표현하는 방식이 매우 다른데, 각자 장단점이 있으니 프로젝트 특성에 맞게 사용하면 된다.

vmin과 vmax는 브라우저 지원이 아직은 불안정하다. 그래서 사용률이 확 떨어지지만 잘 알고 있으면 유용하다. 너비와 높이 중 더 긴 것을 vmax, 더 짧은 것을 vmin에 대응한다. 따라서 너비 300픽셀, 높이 1000픽셀의 기기가 있다면 1vmin은 3픽셀 1vmax는 10픽셀을 반환한다. 다양한 기기에 대응해야 하고 이 기기들의 정확한 높이와 너비에 맞는 div를 씌우고자 한다면 100vmax, 100vmin을 적용하면 된다. 사용하기 까다로운 height: 100% 같은 것을 사용하지 않아도 되고, 스크립트를 쓰지 않아도 된다.


역시 Pseudo Element 중 가장 많이 사용하는 것은 :before와 :after다. 과거에는 브라우저 지원이 미비해서 무작정 사용하기가 애매했지만 이제는 대부분의 최신 브라우저에서 잘 지원한다. :before와 :after를 잘 사용하면 불필요한 마크업 낭비를 줄이고 다양한 기교를 부리고 가상의 디자인적 요소를 표현할 수 있다.


이 부분은 CSS의 이름에서 알 수 있듯이 Cascading의 핵심인 부분이다. 자손 연결자는 당연히 100%가 사용되어야 하는 거 아닌가 하는 생각이 들었지만 사용률이 98%였다. 나머지 2%의 사람들은 그냥 직접 클래스나 아이디 선택자를 사용하고 자손 연결자는 사용하지 않는 것 같다

직속 자식만을 선택하는 > 선택자는 진짜 오래전에 브라우저들이 CSS의 기능들을 어설프게 지원할 때 후임 한명이 저걸 쓰길래 쓰지 말라고 엄청 혼냈었던 기억이 난다. 이제는 브라우저들이 잘 지원하기 때문에 자유롭게 써도 된다.

마크업을 잘 구성하고 CSS 설계를 잘 하면 +와 ~를 사용할 일은 거의 없지만 알아두면 급할 때 요긴하게 쓸 수 있을 것이다.


:first-child, :last-child, :nth-child()도 이제는 정말 많이 쓰인다. 모두 90%가 넘는 사용률을 보인다. 불과 몇년 전 까지만 하더라도 여전히 구형 브라우저를 사용하는 사람들이 많았다. 그래서 이게 편리하고 좋은 걸 알면서도 쓰지 못했다. 그래서 불필요하게 클래스 네임을 지정해서 별도로 스타일시트 구문을 추가하거나 스크립트로 컨트롤을 해야했다.

그러나 이제는 간단하게 가장 첫번째 요소, 마지막 요소, 그리고 원하는 순서의 요소, 특정한 순서 패턴의 요소들을 CSS만으로 간단하고도 자유롭게 컨트롤 할 수 있게 되었다.

아래의 의사결정 클래스들도 정말 유용한 것이 많지만 아직 사용률이 낮은 것은 그만한 이유가 있다. 다양한 기기와 브라우저 대응이 아직은 어렵기 때문이다.


엘리먼트의 속성에 접근하는 선택자도 이제는 정말 많이 쓴다. ele[foo="bar"]의 사용률은 95%가 넘는다. ele[foo]도 브라우저 지원율이 높지만 ele[foo="bar"]가 더 많이 쓰이는 이유는 폼의 동적인 부분을 스크립트로 처리하지 않고 CSS만으로 처리할 수 있기 때문이다.

체크박스나 라디오버튼을 예로 들면, 박스가 체킹 되었을 때와 체킹이 해제되었을 때 디자인을 따로 적용할 수 있는데, 예전에는 이런 부분을 별도 CSS클래스를 작성하여 스크립트로 처리하였다.

그러나 지금은 checkbox[checked="checked"]와 같이 체크가 되었을 때 상태 한줄만 추가하면 된다. 폼 요소의 경우 이것마저 줄일 수 있는데 :checked로 간단하게 컨트롤이 가능하다.

이와 같은 방법으로 스크립트로 처리할 부분의 상당 부분을 CSS에서 처리할 수 있으니 UI 드로우 처리가 훨씬 빨라질 수 있고 개발도 편리하다.


:link, :visited와 같은 선택자는 설명할 것도 없이 유명하고 앵커 태그 등에서 웹 초창기부터 자주 쓰이던 고전적 선택자다. 


:hover, :focus:, :active 클래스는 엘리먼트가 마우스의 위에 올라 가 있는지, 엘리먼트에 포커싱이 되어 있는지를 감지하여 스타일링을 할 수 있다. 이 역시 오래도록 애용되고 있는 고전적인 선택자다. 앵커 태그에서는 상당히 잘 작동하지만 앵커 태그 이외의 엘리먼트에서는 일부 브라우저에서 동작이 되지 않을수도 있으니 체크하면서 작업을 해야한다.


폼 요소들의 상태를 체크할 수 있는 CSS 선택자들이다. :checked와 같은 것은 널리 쓰이고 있으며 자바스크립트를 사용하지 않고도 라디오 버튼이나 체크박스의 상태를 자유롭게 디자인 할 수 있기 때문에 편리하게 사용할 수 있다.

폼의 활성 상태를 체크하는 :enabled, :disabled와 같은 선택자도 유용하게 쓸 수 있으며 기본 요구사항을 감지하는 :required와 같은 선택자도 유용하게 사용할 수 있다. 대부분의 브라우저에서 잘 지원한다. 그러나 일부 선택자는 11이상의 높은 버전의 브라우저에서도 지원되지 않을 수 있으니 확인을 해가면서 사용을 할 필요가 있다.

폼 요소들의 상태를 체크하는 CSS 선택자는 잘 알아두고 활용하면 스크립트 작업 노가다 시간을 많이 줄일 수 있다.


Sass의 경우에는 설문에 참여한 대부분의 CSS 개발자가 만족하고 있으며 사용하고 있는 기술이라고 답변했다. 이것을 보면 이제는 단순한 퍼블리싱이든 전문 FE를 하던 세계적 추세는 FE 환경에서 CSS를 개발하고 또 Sass와 같은 전처리기를 쓰는 것이 대세를 넘어 기본이 되었음을 알 수 있다. Sass를 아직 안 써 본 CSS 개발자는 없겠지만, 혹시 계시면 써 보시길 추천한다. 정말 끝내준다! 한번 사용하면 CSS 날코딩의 세계로 돌아갈 수 없다.

한때 대세로 여겨졌던 BEM 방법론은 만족하는 사람이 많지만 모든 사람이 BEM 방법론을 따르는 것은 아니다. 부트스트랩 CSS 프레임워크는 아주 많은 사람들이 사용해 본 적이 있지만 만족도는 지극히 낮았다.

눈여겨 볼 것은 PostCSS와 Tailwind CSS다. 사용해 본 사람들은 만족도가 아주 높다고 답했다. 그러나 아직 덜 알려져 있어서 이를 사용해 보았다는 사람은 매우 적었다.

PostCSS는 300여개에 달하는 플러그인을 사용할 수 있도록 도와주는 도구인데 CSS의 문법을 확장하거나 CSS 코딩을 매우 편리하게 만들어주는 도구들을 지원한다.

Tailwind CSS는 부트스트랩과 비슷한 CSS 프레임워크다. 정해진 디자인이 일관적이라 유틸리티 퍼스트 개발에 유리하고, 부트스트랩에 비해서 커스타마이징이 용이해서 만족도가 높다.

이 부분에서 새롭게 공부할 기술들이 몇가지 추가되었는데, PostCSS에 대해서는 꼭 한번 들여다 봐야겠다.


전처리기를 사용하였다는 의견은 전반적으로 다 높아졌다. 갈수록 CSS 작업을 할 때 날코딩이 아니라 전처리기를 거치는 것이 자리 잡고 있음을 느낀다. Less를 제외한 Sass, Stylus, PostCSS가 모두 사용한다는 응답이 늘었으며 특히 PostCSS의 사용량이 빠르게 증가하고 있다.


전처리기 사용 만족도는 Sass보다 PostCSS가 더 높았다. 전처리기 사용을 한다면 Sass 또는 PostCSS를 사용하는 것이 좋겠다. 특히, PostCSS는 Sass의 만족도가 소폭 감소한 상황에서도 되레 만족도가 더 높아지는 경향을 보여주었다. PostCSS 공부 욕구가 뿜뿜하지 않는가?


CSS 개발자들은 Sass에 대해 거의 대부분 인지를 하고 있었고, PostCSS에 대한 인지도가 빠르게 올라오고 있는 것도 확인할 수 있다. 조만간 PostCSS가 Sass의 인기를 밀어낼지도 모르겠따. 둘은 특성이 조금 다르기는 하지만 교집합도 많다.


개인적으로 CSS 프레임워크를 사용하는 것은 좋아하지 않는다. 밑단부터 하나하나 만들어 올라가는 걸 좋아하는데 의외로 CSS 프레임워크도 많이들 사용하는 것 같다. 우선 앞에서도 이야기가 잠깐 나왔던 테일윈드 CSS 프레임워크의 만족도가 높다.


인지도만 놓고 보면 부트스트랩이 단연 압도적인데 사용 후 만족도는 높지 않았다. Tailwind CSS는 최근에 인지도를 급격히 키워나가고 있다. functional한 CSS 이용이 가능한 프레임워크라서 이 트렌드에 올라탄 것으로 보인다.


프로젝트에서 테일윈드를 사용했다는 응답이 2019년 6%에서 2020년에 무려 26%로 20%p나 증가했다. 만일 CSS 프레임워크를 도입할 예정이라면 현재 시점에서는 테일윈드 CSS에 대해서 검토해 보는 것이 좋겠다는 생각이 든다. 가볍게 잘 만든 프레임워크인 것 같다. https://tailwindcss.com/

물론 나는 CSS 프레임워크를 쓸 생각이 없지만.


현재 가장 널리 알려져 있고, 많이 사용되는 CSS 코딩 방법론은 BEM 방법론이다. 어느 정도 규율이 있는 개발팀이라면 BEM 방법론을 도입한 곳이 많을 것이다.


그런데 CSS개발자들이 가장 만족감을 느끼는 방법론은 Atomic CSS 방법론이라는 서베이 결과가 나왔다. 물론 만족도는 BEM 방법론도 이에 뒤지지 않게 높았다.

Atomic CSS 방법론은 최근에 주목 받고 있는데 간단히 몇가지 특징을 언급하면 다음과 같다. Atomic CSS 방법론의 철학은 마크업과 CSS 파일이 애초에 분리된 게 이상하지 않느냐? 기본으로 돌아와서 템플릿 작업을 하면서 한꺼번에 스타일 작업도 하는게 논리적으로 맞지 않느냐는 가치관을 가지고 있다.

클래스 하나에 CSS 밑단 속성 하나가 대응된다. 검정색 1픽셀 선을 표현하는 border: 1px solid #000이라는 속성이 있다고 하면 이것을 .b10이라는 형태의 클래스로 만들고, 이것을 템플릿에서 직접 사용하는 것이다. 클래스 하나에 두가지 이상의 스타일시트 속성이 들어가면 Atomic CSS 규칙 위반이다.

장점은 CSS 작업을 할 필요없이 템플릿 작업과 동시에 스타일 작업을 할 수 있다는 것이다. 그리고 죽은 CSS 코드가 거의 발생하지 않고, CSS의 크기도 줄일 수 있다. 그리고 functional 하기 때문에 직관적이다.

단점은 구현하고자 하는 CSS 스타일이 미리 다 구현이 되어 있어야 한다는 점이다. 그리고 사용하고자 하는 속성에 대응되는 클래스 이름을 모두 사전에 인지하고 있어야 하므로 익숙해 지기 전까지는 러닝 커브가 높다는 점이다.


역시 에디터는 Visual Studio Code가 대세!


브라우저 테스트는 역시 크롬 사용률이 압도적이다. 여전히 파이어폭스를 개발 테스트용 브라우저로 많이 쓰는 것은 신기하다. 익스플로러는 이제 거의 사장되어 가는 분위기다. MS에서도 더 이상 지원을 안한다고 하였으니. 여러모로 프론트엔드 개발자들에게는 다행이고 신나는 시절일 것이다. 옛날에 IE 6, 7, 8 맞추던 시절이 정말 최악인 시절로 기억될 것이다.


2020년 4월 1일 수요일

a와 button을 용도에 맞게 사용하기

출처 : unsplash.com

오랜만에 개발 관련 글을 쓴다. 아주 기초적인 부분인데 놓치고 있던 부분이 있어서 기록으로 남겨둔다. 코딩하는 습관은 한번 익숙해지면 고치기가 어렵다. 나는 여러가지 안 좋은 습관을 가지고 있다.

그 중 제발 좀 고치자 싶어서 노력하는 부분이 하나 있다. 바로 링크가 아닌 곳에서 <a>태그의 사용을 지양하는 것이다.

앵커 태그


WWW의 근간을 이루는 기술 중 하나는 HTML이다. HTML이라는 이름에도 들어 있듯이 HTML문서는 '하이퍼텍스트' 문서다. 하이퍼텍스트의 근간은 하이퍼 링크이며 이 하이퍼링크를 위해 존재하는 것이, 기본적으로 <a>태그이다.

<a>태그는 'href' 요소와 결합하여 하이퍼링크를 만든다.

따라서, <a> 태그는 페이지 간의 이동을 위해 링크를 생성할 때만 사용해야 한다. 기본중에 기본인데 과거에는 <a>태그에 href="#"을 넣거나, javascript:; 와 같은 것으로 페이지 링크와 스크립트 호출을 막아놓고, 동적 UI를 만들 때 버튼 기능으로 많이 사용했다. 이것이 시간이 흐르고 손에 굳어버리니 계속 이 방법을 고수했다. 이는 의미에 맞지 않는 매우 잘못된 마크업 사용법이므로 하이퍼링크 생성 이외에 페이지 내의 동적 UI 작성을 할 때는 <a> 태그의 사용을 지양하자.

버튼 태그


2000년대 중반부터 AJAX 기법이 널리 확산되었다. 그리고 나중에는 모바일 시대가 열리면서 SPA 앱 개발 방식도 널리 사용되었다. 웹페이지나 모바일 페이지는 심플하면서도 복잡해졌다. 어떤 인터렉션이 있기전에는 심플해졌고, 거기서 무언가 인터렉션이 발생하면 점점 복잡한 속살을 드러낸다.

지금의 웹페이지나 모바일웹 사이트들은 페이지 이동을 하지 않은 상태에서 수 많은 동작과 인터렉션을 요한다. 이런 페이지 내 기능들을 사용할 때 <a>태그 대신 <button> 태그를 사용하는 것이 조금 더 논리에 맞지 않을까 생각한다.

버튼 태그는 기본적으로 <input> 요소로 구현이 가능하다. 이 경우에는 form의 submit이나 reset 기능도 사용이 가능하다.

다만, <a>태그 대용으로 사용할 경우에는 이렇게 사용하지 말고 <button>..</button>으로 독립적 마크업을 사용하자. 이렇게 사용하면 버튼 안에는 이미지를 비롯해서 <span>등 다른 요소를 넣어서 조금 더 디테일한 스타일링도 가능하다.

W3C 링크


앵커 태그 명세 : https://www.w3.org/MarkUp/1995-archive/Elements/A.html
버튼 태그 명세 : https://www.w3.org/TR/2011/WD-html5-20110525/the-button-element.html#the-button-element

2020년 4월 1일
송종식


2013년 3월 2일 토요일

왜 웹표준인가?

'쏭군'이라는 닉네임으로 2007년도에 썼던 글 입니다. 웹표준이나 웹접근성에 대한 관심이 서서히 생겨나고 있던 시절이었습니다. 워낙 시간이 오래 흘러서 업데이트 되어야 할 부분도 많고, 개략적인 내용만 다룬 글 이지만 지금 현재까지도 많은 분들께 도움이 되리라 생각되는 글이라 특별히 이 블로그에 백업해 둡니다. 고맙게도 당시에 수백개의 댓글이 달리고 업계 종사자분들이 여기저기 퍼가기 하면서 업계에서는 꽤 많이 읽힌 베스트리딩 글 이었습니다. 누적 조회수는 5만회가 넘었었습니다.

여러분 가게에 물건 구경하겠다는 손님을 그냥 내쫓겠습니까?
손님이 시각장애인이라는 이유로 물건을 팔지 않겠습니까?

웹표준을 지키지 않으면 알게 모르게 놓치는 것들이 많습니다!

웹표준? 웹접근성? 그게 뭐길래?


웹표준을 지킨다 , 웹접근성을 높인다는 말은 무엇이고.
웹표준을 지키면 뭐가 좋길래 사람들이 웹표준, 웹표준 할까요?
똑같은 데이터를 가지고 있는 웹사이트가 있습니다.


웹표준을 지키면 검색엔진 노출이 됩니다. 반면 그렇지 않으면 검색엔진 노출도 힘들어 집니다. 또한, 웹표준을 지키지 않으면 어렵사리 찾아온 고객을 내쫓는 경우도 발생합니다.

웹표준을 지키면 브라우저나, 장치, 기기에 관련없이 조금더 많은 사람에게 정보전달을 있습니다. 또한 검색엔진 유입량도 늘어납니다. 웹표준을 지키지 않으면, 우리 웹사이트에서 가지고 있는 정보가 모두에게 전달될 없습니다. 제한된 일부 사람들에게만 전달될 뿐이지요. 이것은 매우 비효율적 입니다. 똑같은 데이터를 가지고 있는데 웹표준을 지원하고 안하고는 웹사이트의 정보를 더욱 많은 사람에게 전달할 있고 못하고의 차이를 가져옵니다. 이외에 웹표준을 지키면 다양한 장점이 있습니다. 장점들을 소개해 드리겠습니다.

크로스브라우징


혹시 익스플로러에 최적화하여 사이트를 제작하셨습니까? 파이어폭스나, 사파리, 오페라 다른 브라우저에서 웹사이트 레이아웃이 문제없이 출력되며, 문제없이 작동되는지 확인해보셨나요? 웹표준을 지킨 웹사이트는 일단 크로스브라우징을 가능하게 해줍니다. 내가 만든 웹사이트를 방문하는 방문객이 익스플로러를 사용하든, 파이어폭스를 사용하던, 사파리나 오페라 등의 특이한 브라우저를 사용하든 한결같은 모습을 보여줍니다. 아래의 그림을 보시면 이해가 쉽게 되시리라 생각됩니다.


물론 익스플로러의 점유율에 비하면, 아직은 보잘것 없는 파이어폭스나 사파리등의 점유율 입니다. 그렇지만, 명이라도 방문객을 유치하기 위해서라면 웹표준은 반드시 지켜야겠지요.

데이터와 디자인의 분리?!


말은 처음 웹표준을 접하는 분들께는 언뜻 이해하기 어려운 개념일 있습니다. 하나의 웹페이지를 흔히 우리가 다루는 A4 용지의 문서처럼 하나의 문서라고 가정합시다. 그렇다면 해당 웹페이지는 디자인을 배제하고 기본적으로 문서의 형태를 띄고 있어야 합니다. 기본적인 문서의 형태를 띄면서 데이터를 가지고 있는 것이 HTML 입니다. 그리고 HTML 페이지를 다양하고 보기좋게 디자인 해주는 역할을 하는 것이 바로 CSS입니다.


CSS Zen garden 웹사이트 입니다. HTML 문서를 보세요 제목부터 작은 제목그리고 단락별로 들어가는 내용까지... HTML 문서의 구조화가  되어있지요? HTML 파일에는  하나도 안대고, CSS  교체하여 전혀 색다른 느낌의 웹사이트 디자인을 만들  있습니다잊지마세요. HTML 문서!(데이터) CSS 디자인 속성 저장!

모바일 기기를 위한 웹표준


CSS 지원되지 않는 모바일 기기에서 여러분의 웹사이트는 접속을 원하는 이용자에게 정보전달을 제대로 하고 있나요? HTML데이터와 CSS디자인을 완벽하게 분리하여 웹표준에 따라 작성된 웹페이지는 CSS 지원되지 않는 모바일 기기에서도 원하는 정보를 완벽하게 전달할 있습니다. (, 와이브로나 휴대폰 전용 서비스로 개발된 웹페이지 제외)


CSS 지원되지 않는 모바일기기에서 접속해도 충분히 원하는 정보를 얻을 있도록 데이터와 디자인이 분리되어 있는 '다음'메인페이지의 경우(우측 핸드폰 사진은 합성한 것입니다)


데이터와 디자인의 분리가 되지 않은 사이트는 모바일 기기가 아예 웹페이지를 해석하지 못하기도 합니다. 또한 CSS없이 사이트를 읽어들이면 아래 사진처럼 사이트가 폭격을 맞은냥 깨져서 출력됩니다. 사이트 이용이 전혀 불가능하게 됩니다. 조사결과 웹표준을 지키는 컴퓨터학원 홈페이지는 한군데도 없었고, 홈페이지 제작업체들도 웹표준을 거의 지키지 않고 있었습니다. 명색이 홈페이지로 돈벌어 먹고 사는 사람들이 말입니다. ( 사진은 합성된 이미지 입니다)

시각장애인을 위한 스크린리더기의 지원


웹은 평등합니다. 웹은 사람을 차별하지 않습니다. 하지만 언제부턴가 우리나라는 많은 디자이너/개발자분들께서 의미를 담은 웹페이지는 신경을 쓰고 있지 않습니다. 사이트는 테이블로 통자이미지를 덕지덕지 붙여서 보여주기에만 급급한 경우가 많고, 필요없는 플래시 U.I. 남발하여 웹페이지의 의미를 알아볼 없게 만들고 있습니다. 앞을 못보는 시각장애인을 위한 사이트를 고려해보셨습니까? 웹표준을 지키면 시각장애를 가진 분들도 웹사이트를 편안하게 이용할 있게 해줄 있습니다. 그래서 웹접근성도 한층 높아집니다.


계속 강조하는 것이지만, HTML 문서를 코딩할 때는 의미에 맞는 코딩을 해야합니다.
예를 들어서, 강조하고 싶은 문장이 있는데, 해당 부분을 <b> 태그로 감싸면 글씨만 굵어질 , 브라우저나 스크린리더기는 해당 문장을 중요문장으로 취급하지 않습니다. 웹표준에 맞는 태그는 <b>태그가 아니라 <strong>입니다. 이처럼 웹표준에 부합하는 태그들이 있습니다. 숙지하시어 사용하시기를 권장합니다.

사이트 디자인 관리 시간 단축


데이터와 디자인의 분리. , HTML 페이지는 말그대로 문서상태이고, CSS 통해서 웹페이지를 디자인 합니다. 그러면, CSS 여러개 만들었을 경우, CSS 파일의 경로를 변경하는 만으로 새로운 디자인으로 사이트를 리뉴얼 있습니다. 또한 기존에는 사이트에 이미지나 스타일 하나만 변경하더라도 페이지마다 바꿔주어야 하는 번거로움이 있었습니다. 하지만 HTML CSS 분리는 이런 작업시간까지 단축시켜 주었습니다. CSS에서 코드 줄만 수정해주면, 수백~수천페이지의 디자인이 한꺼번에 변경이 가능하게 되었습니다. 이것은 추가적으로 웹사이트 관리 비용절감의 효과도 가져옵니다.

디자인을 수정해야하는 페이지가 12500페이지라면 여러분의 선택은?

검색결과 상단에 노출되고 싶으세요? 그럼 웹표준을 지키세요!
실제로 똑같이 그래픽 처리가 두개의 웹사이트가 있다고 가정합시다. 하나의 사이트는 데이터와 디자인 분리를 하지 않고 많은 사이트이고, 다른 하나는 데이터와 디자인을 완벽하게 분리하여, 웹페이지의 내용과 의미를 정확하게 담고 있습니다. 겉보기는 똑같지만 속은 완전히 다른 사이트이지요. 쪽은 페이지의 의미를 정확하게 담고 있고, 한쪽은 페이지의 의미가 해석불분명하니까요

이것은 검색결과에 상당한 영향을 미칩니다. SEO에서 웹표준은 많은 부분을 차지합니다.

검색엔진의 검색결과 상단에 노출되기 위해서 메타태그나 title 태그의 활용, 본문에서 주력 단어의 빈도수 노출 많은 부분이 널리 알려져서 활용되고 있습니다. 그렇지만 아직까지, 웹표준을 지키면 검색엔진의 검색결과 상단에 컨텐츠가 노출된다는 사실은 그다지 많이 알려져 있지 않습니다.

대표적으로 H1, H2, H3 ... 제목 태그인 h 태그의 SEO 막강합니다.


블로그 제목은 '쏭군은 열정 드리머' 입니다만, CSS 이용하여 MONOEYES라는 블로그 제목으로 이미지 치환 해두어 텍스트는 감추어 두었습니다. 보이지만 않을뿐 문서의 대제목은 '쏭군은 열정 드리머'라는 속성을 항상 가지고 있는 것입니다. 구글에서 검색한 결과 최상단에 H1 태그가 검색되어 출력됩니다.


포스팅 제목의 경우 검색엔진에서 검색되는 빈도가 많아야 하는 중요한 부분인 만큼, 문서 대제목인 H1 다음으로 H2 주었습니다. H1 보다 중요도는 떨어지지만, 단락의 대제목으로서 검색엔진 검색결과에서 만족스러운 노출을 보여줍니다. 위의 사진은 CSS 제거했을 , 포스트 제목이고, '디올 어딕트'라는 디올의 제품을 구글에서 검색했을 , 가장 상단에 쏭군의 블로그가 노출되는 것을 보실 있습니다. 문서 구조화를 위해서도 헤드라인 태그는 반드시 사용해야 하며 정확한 구조화 구성하시길 바랍니다.

DIV TABLE 논란은 문제의 본질이 아닙니다


많은 분들이 DIV=웹표준, TABLE=비표준이라는 인식을 가지고 계십니다. 문제는 DIV TABLE이냐가 아닙니다. DIV TABLE 모두 웹페이지를 작성하기 위한 '도구' 뿐이지, 자체가 '웹표준이냐 아니냐' 가늠하는 목적이 없습니다.
TABLE 데이터를 출력하기 위해 존재하지 레이아웃 짜라고 존재하는 것이 아닙니다
테이블은 말그대로 데이터들을 표형식으로 출력해야 필요성이 있을때만 사용합니다. 테이블로 레이아웃을 만들게 되면, 웹페이지의 로드 속도도 느리게 되고, 웹페이지를 수정할 곳이 생기면 자칫 페이지 전체를 뜯어내야하는 대공사가 발생될 있습니다.


TABLE 없는 DIV 장점


모듈화? 디자인을 하시는 분들께는 말이 어렵지요. 하지만 간단한 뜻입니다. 필요한 부분을 마음껏 떼어서 있게 웹사이트를 만들 있다고 생각하시면 됩니다. 예를 들어, 테이블로 웹사이트 레이아웃을 구성하면 로그인 박스 하나를 바꾸기 위해서 웹페이지의 다른 부분도 영향을 주거나, 웹페이지 전체를 뜯어내야 하는 경우가 대부분입니다. 그렇지만 DIV 작업을 하면 원하는 박스만 떼어서 디자인을 수정할 있고, 박스는 얼마든지 다른 페이지에 자유롭게 붙였다 뗐다 하면서 재활용이 가능합니다.

게다가 TABLE 레이아웃을 구성할때보다, 작업의 속도나 사이트 관리적인 측면에서 훨씬 이득을 있고, 페이지 로드도 테이블 레이아웃 보다 빠릅니다.

하지만 TABLE 필요한 곳은 테이블을 쓰세요


테이블을 이용해서 웹사이트의 레이아웃을 짜면 나쁜 입니다. 하지만 반드시 테이블이 들어가야 곳이 있습니다. 반드시 데이터형식을 표방식으로 보여주어야 하는 곳은 테이블을 쓰는편이 낫습니다.

테이블을 유용하게 활용하고 있는 올블로그와 네이버

만약 위의 프리미어리그 점수판을 표를 사용하지 않고 DIV LI 이용해서 표현했다고 가정합시다. 페이지의 CSS 지원되지 않을때 오히려 팀별로 득점이나 승점을 보기가 힘들어집니다. 이런 표형식의 데이터는 TABLE 사용하는 것이 더욱 웹표준에 부합합니다. 또한 CSS 깼을때도 점수표를 깔끔하게 출력할 있구요. 반드시 이런 데이터처리에만 TABLE 쓰시고 어지간하면 사용하지 않는 것을 권장드립니다. 더구나 TABLE 레이아웃을 짜는 비통한 일은 다시는 있어서는 되겠지요. 데이터를 표시하라고 하사한 TABLE 이거늘.. 그걸로 홈페이지 레이아웃을 만들면 원래 목적에도 어긋날 아니라 원통하기 까지 합니다.

스크립트 사용시


있으면 스크립트 사용을 자제하는 것이 좋습니다. 부득이 스크립트를 사용해야 하는 경우라면, 모든 브라우저에서 작동되는 스크립트를 사용하시고, 스크립트가 지원되지 않는 환경을 위해서 스크립트 없이도 웹사이트를 이용할 있도록 차선책을 미리 만들어 두시는 것을 권장합니다.

서버 부하를 덜어줌


디자인 정보를 CSS 저장함으로서, 관련 소스코드를 획기적으로 줄일 있습니다.
또한, CSS 캐싱되어 웹사이트에 최초 접속할 한번만 로드되므로, 서버 부하를 획기적으로 줄여줄 있고, 규모가 사이트라면 비용 절감 효과도 가져올 있습니다.

읽느라 고생 많으셨습니다. 글쓴이를 표기하신다면 문서를 상업적으로 이용하셔도 되고, 어디에나 퍼가셔도 됩니다. 웹표준을 처음 접하시는 분들께 도움이 되고자 작성한 문서인데. 조금이나마 도움이 되셨으면 좋겠습니다.

2007년 12월 20일
송종식 드림