웹 개발시 저지르는 실수들

CSS, HTML, JavaScript, Quotes, Web Accessibility, Web Development, Web Standards 댓글 달기

여기에 옮긴 글은 웹 개발 시에 항상 주의해야 할 비교적 긴 몇 가지의 항목들을 열거해 놓았다. 여기에 나열된 실수들을 모두 피할 수만 있다면 그것은 무난한 웹 개발이 잘 진행되고 있다는 뜻일 것이다. 고백하자면, 과거에는 나 자신도 이들 중 적어도 몇 가지는 같은 실수를 범했을 수 있으나, 이 항목들을 참고로 앞으로는 적어도 같은 실수를 피하는 데 도움이 되었으면 한다.

DOCTYPE의 혼동
완전히 빠져있거나, 아님 틀렸거나, 혹은 엉뚱한 위치에 붙어 있음. 종종 HTML 4.0 Transitional이 사용된 문서에서 XHTML markup 혹은 <frameset>이 쓰이거나, DOCTYPE 선언문이 첫 <html> 꼬리표 뒤에 오고, 완전하지 않은 DOCTYPE들을 목격하곤 한다.
왜? 두 가지의 이유가 있다. 첫 쨰로, 이것은 W3C HTML 4.01 spec과 W3C XHTML 1.0 spec에도 언급되어 있듯, 필수 항목이다. 두 번째로는, 요새 나오는 웹 브라우저들은 지정되어 있는 DOCTYPE을 가지고서 웹 페이지 표시 방식들 중에 어느 것을 사용할 것인지를 결정한다. 이것은 소위 “DOCTYPE 전환”이라고도 알려져 있다. 여러 웹 브라우저들 간의 동일한 결과를 보여주기 위해, 특히 CSS를 사용할 경우에는, 브라우저가 “표준 준수 방식”을 사용하길 원할 것이다. DOCTYPE 전환에 관한 더 자세한 정보는 웹 사이트의 DOCTYPE을 올바로 고치자와 DOCTYPE 선언을 이용한 올바른 표시 방식 활성법의 글에서 확인할 수 있다.
광적인 <span> 사용
CSS를 가지고서 어떤 것의 모양새를 바꿀 때 일반적으로 사용되는 방법으로, class 속성이 포함된 <span> 요소로 둘러싸서 이것으로 모양을 바꾸는 방법이 사용된다. 여러분은 <span class="heading"> 그리고 <span class="bodytext">와 비슷한 것들이 사용된 것을 종종 보아왔을 것이다.
왜? 이것은, 대부분의 경우, 완전히 불필요한 것이며, 또한 어떠한 의미도 내포하고 있지 않고, 단지 전체 구조를 지저분하게만 만들 뿐이다. 머릿말에는 머릿말 요소(<h>)를 사용하고, 문단에는 문단을 위한 요소(<p>), 그리고 항목 표시를 위해선 HTML의 항목 표시 요소들(<li>)을 사용하면 될 것이다. 그리고서 CSS는 이들 요소들의 모양새를 꾸미는데 사용하면 된다. 만약 필요하다면, class 혹은 id 속성들을 추가해주면 된다.
(지나친) 가시적 요인들의 집착
웹을 WYSIWYG로만 여기는 것 – 처음부터 구조적 측면을 먼저 생각하는 대신 어떻게 보여줄 것인지에 초점을 맞추고, 나중에 그 외의 구체적 전달 방법을 고려하는 것.
왜? 대부분의 사람들은 웹의 겉모습만 인지하고 사용할 것이라 여기지만, 실제로 모두가 그렇지는 않다. 그리고 웹을 WYSIWYG 하게 만들 수도 없는 노릇이다. 사람들이 각기 다른 브라우저들, 운영 시스템, 모니터 크기, 화면 해상도, 창 크기, 색깔 설정, 그리고 여러 글꼴 크기들을 사용하는 한은 제각기 다른 여러 편차들은 항상 존재할 것이다. 웹은 인쇄된 종이 혹은 텔레비젼이 아니다. 그러므로, 디자인은 항상 융통성을 지니고 있어야 한다.
의미론적인 뜻의 결핍
의미없는 (혹은 잘 못 사용된) HTML 코드. HTML의 각 요소들에 대한 코드 사용의 취사 선택에 있어서 각 요소들이 갖고 있는 의미 대신에, 대부분의 브라우저들에서 보여질 겉모양을 기준으로 선택하기 때문.
왜? 이 실수는 “광적인 <span> 사용”과도 밀접한 관련이 있어서, 기존 HTML 요소들을 적절히 사용하지 않음으로 해서 그 속에 포함하고 있는 내용의 의미를 올바로 표현하지 못 하는데 있다. 또한, 무의미하게 사용된 HTML 코드는 시각적이지 못한 글자 해석기(user agents)들이 그 속 내용을 파악하는 데에도 어려움을 준다. 반면, 의미론적으로 올바르게 사용된 HTML코드는 CSS를 가지고서 겉모양을 꾸미기에도 한결 손쉬워 진다.
글자 인코딩 불일치
서버에서 보내온 HTTP header 부분에 지정되어 있는 글자 인코딩과, 도큐멘트의 것이 서로 다르게 사용됨. 이것은 브라우저들에게 혼동을 불러일으켜서 도큐멘트를 올바로 표시해주지 못하게 한다.
왜? 물론 여러분은 방문하는 모든 사람들에게 내용이 제대로 전달되길 원할 것이기 때문이다.
잘못된 alt 속성
빠져있거나 쓸모가 없다. 빠져있는 alt 속성을 가진 <img> 요소들은 웹에서 셀 수도 없이 목격할 수 있다. 또한, 일반적이지는 않지만 가끔은 “전체 외형을 좋게 보이게 할 목적으로 사용된 공백을 채우는 GIF”, “그림자가 더해진 커다란 파란색 문단점”, 그리고 123 KB 짜리 “JPEG 그림”들을 볼 수 있다. 명심할 것은, alt 속성은 <img>와 <area> 요소들에서 사용될 때는 꼭 필요한 것이라는 점.
왜? 당연 이것은 필수항목이고, 이것이 없을 경우에는, 그림이 갖고있는 어떠한 정보도 화면 해독기, 글자 위주의 브라우저들, 검색 엔진의 로봇들, 혹은 그림 표시 기능을 끈 사용자들에게는 보여질 수 없을 것이다. 여기서 설명 글은 그림과 관련된 내용으로 되어 있어야 하며. 겉모양을 꾸미기 위해 사용된 그림들에는 설명 글이 지정하지 말아야 한다. 이럴 경우에는, alt=""와 같이 그냥 비워둘 것.
틀리게 사용된 id와 class 속성들

id 속성들에 사용된 값이 중복됨. id와 class 속성, 그리고 CSS 선택자에 사용된 글자들이 틀렸음.

CSS의 경우 (CSS 2.1 문법과 기번 데이타 형식들):

CSS 2.1에서는, 식별자들(identifiers)의 경우 (각 요소의 이름들, 클래스, 그리고 식별자들의 ID들을 포함해서) [A-Za-z0-9]의 글자들과 ISO 10646 글자들 중 U+00A1 이상, 그리고 하이픈(-)과 밑줄(_)들만 포함될 수 있다; 점으로 시작될 수는 없음.

HTML의 경우 (기본 HTML 데이타 형식들):

ID와 NAME 표식은 글자([A-Za-z])로 시작해서 아무 글자나, 숫자([0-9]), 하이픈(“-“), 밑줄(“_”), 콜론(“:”), 그리고 점(“.”)으로 채워질 수 있다.

왜? 위의 지침을 따르지 않는다면, 브라우저들은 의도하는데로 문서를 표시해주지 못하게 된다. 만약 문서에 같은 id 값이 여러 개 있다면, 그 값을 사용하는 JavaScript 코드는 실행되지 안거나 예측하기 힘든 결과를 보여줄 수도 있다.
브라우저 염탐
서버든 혹은 클라이언트 쪽에서든, 스크립트를 사용해서 방문자의 브라우저 종류를 탐색해서, 브라우저별 특색을 타는 코드를 실행하거나 보내는 것. 새로운 브라우저들의 경우에는 자기의 정체를 속이는 기능들이 있기 때문에 이런 짓은 소용이 없고 실패하기 마련이다. (Opera는 기본적으로 자신의 정체를 숨긴다).
왜? 이것은 불필요하게 복잡한 상황만 만들고, 또 결국에는 실패하기 마련이다.
CSS에 빠져있는 단위들
영의 값을 제외한, CSS에서 사용되는 길이 값(수평 혹은 수직 측정값들)은 단위를 써주어야만 한다. HTML에서 그냥 width="10"처럼 써줄 수 있는 것과는 달리, CSS의 경우에는 width:10px;와 같이 사용 단위가 함께 지정되어 있어야 한다.
왜? 표준에 명시된 사항들을 따르는 브라우저들에서는 제대로 작동될 수 없기 때문.
특성을 타는 CSS.
스크롤 막대 모양의 꾸밈, expressions, 필터 등. Internet Explorer에서만 작동되는 특화된 CSS. 물론, 이것은 표준과도 거리가 멀다.
왜? 특정 브라우저에서만 작동하기 때문. 만약 정말로 IE만을 위한 CSS를 써야만 한다면, 개별 파일에 옮겨놓고 조건부 주석을 달거나, 기타 다른 방도로 IE만을 위한 변형된 용법들을 볼 수 있도록 할 것.
지나친 JavaScript 의존
JavaScript에만 의존하는 사이트. 추측보단 더 많은 사람들이 JavaScript를 지원하지 않는 브라우저를 사용하거나, 아예 JavaScript를 꺼 놓은 경우도 있다. 현 통계치들(W3Schools의 브라우저 통계, TheCounter.com)을 보면, 웹 사용자들 중 약 8-10 퍼센트 정도를 차지하고 있다. 현재 검색 엔진의 로봇들은 JavaScript를 제대로 해독하지 못하며, 그나마 Google에서는 그들의 Googlebot이 JavaScript를 지원할 수 있도록 할 예정이라고 한다. 만약 당신의 사이트가 페이지 이동을 위해 JavaScript를 사용한다면, 높은 검색 엔진 순위를 기대하지는 말아라.
왜? 접근이 어렵거니와 검색 엔진 순위에서도 불리함을 갖게된다.
지나친 Flash 의존
모두가 Flash를 설치했으리라는 추측. 다는 아니다. 또한 대부분의 검색 엔진 로봇들도 상황은 비슷하다. (Google은 Flash 파일들도 색인될 수 있도록 하는 실험을 하고 있다고는 하나, 모든 글의 내용과 이동은 HTML 파일들로도 제공될 수 있도록 할 것을 권장하고 있다.) 그래서 전체 사이트, 혹은 사이트 이동을, Flash에만 의존하고 있다면, 이것 또한 검색 엔진 순위에서 불리함으로 작용할 것이다.
왜? 접근이 어렵거니와 검색 엔진 순위에서도 불리함을 갖게된다. 이것은 Flash를 전혀 사용하지 말라는 말이 아니라, 현명하게 사용하라는 것이다.
글자를 대신한 그림 사용
글자를 대신해 그림을 쓰면서, 더 접근 용이한 차선책을 제공하지 않는 것. 글자 대신 그림을 내려받을 때는 시간이 더 오래 걸릴 뿐만 아니라, 모든 방문자들에게 글자를 복사할 수 없게 만들고, 크게 확대할 수도 없게 만든다.
왜? 접근의 어려움, 읽어들이는 시간의 증가, 검색 엔진 순위에 불리 영향을 끼침.
엉성한 폼(form)들
접근이 어렵고, 사용하기 어려운 form들. <label>, <fieldset>, 그리고 <legend> 요소들을 적절하게 사용하는 법을 알아둘 것. 그리고 “Reset” 단추의 사용은 피할 것.
왜? 접근이 어렵고, 사용 용이성을 감소시킨다. 접근성과 사용 용이한 폼(form)들을 만드려면 Creating Accessible Forms, Better Accessible Forms, 그리고 Reset and Cancel Buttons를 읽어 볼 것.
옛날 학교에서나 가르쳤던 HTML
여러개로 중첩된 테이블들(tables), 공백들을 채우기 위한 GIF들, <font> 요소들, 겉모양만을 염두에 둔 markup. 이런 것들은 너무나도 많아서 일일이 여기에 열거할 필요도 없다.
왜? 더 복잡하게만 만듦, 부풀려진 페이지들, 느리고, 접근이 어려우면서, 검색 엔진 순위에서도 밀려나기 마련.
IE 위주의 코드
먼저 IE/Win 만을 위해서 코드를 짜고, 나머지는 시간이 나면 적당히 조절한다.
왜? 시간도 많이 걸리거나와, 엉성한 코드를 짜게되기 마련. IE/Win는 여러 꽁수들과 불규칙한 HTML을 허용하는 것으로도 유명해서, 결국 다른 많은 브라우저들에서는 작동할 수 없게 만듦. IE는 올바로 짜여지고, 표준을 따르는 HTML도 잘 인식하기 때문에, 표준에 맞는 HTML을 쓰면 모든 브라우저들에서 잘 보여지게 할 수도 있으며, 이것은 시간을 더 많이 들여야 하거나 비용이 더 들지도 않는다. The IE Factor 참고.
틀린 HTML 속성들
marginwidth, leftmargin, language, <table> 요소들에 사용된 height, <img> 요소들을 위한 border 등, 더 이상 사용되지 않거나 브아우저의 특성을 타는 속성들을 사용함.
왜? 틀리고 불필요하다. 대신 CSS를 쓸 것. <script> 요소들의 경우, 스크립팅 언어(대부분이 JavaScript)를 지정할 때에는, language 말고, type을 써라.
인코딩 되지 않은 앰퍼샌드
많은 URI들이 인코딩 되지 않은 앰퍼샌드(&)들이 포함된 기다란 큐어리(query) 문장으로 되어 있음. 이것은 틀린 것이며, 문제를 일으킬 수도 있다. 앰퍼샌드는 &amp;로 쓰여야 한다.
왜? 그 이유와 발생할 수 있는 문제의 한 예는 Ampersands and validation에서 얻을 수 있다.
프레임(Frames)
프레임들을 사용해서 브라우저의 시점을 여러개의 단일 문서들로 나누어 놓는 것.
왜? 먼저, 프레임들이 올바로 사용된다면, 인트라넷이나 특정 웹 어플리케이션들에서는 유용하게 사용될 수도 있다는 점을 얘기해 두고자 한다. 하지만, 일반 공개 웹사이트의 경우에는 프레임들은 너무나도 많은 접근성과 사용성에서의 문제들을 안고 있다. 프레임을 사용하면 책갈피할 때의 곤란함, 인쇄의 어려움, 깊숙이 숨어있게 되는 링크들, 검색 엔진들을 위한 꽁수들의 사용 등을 포함한, 여러 불리함들을 안고 있다,
접근이 어려운 데이타 테이블(tables)
산출 데이타들을 포함하고 있으면서, 테이블 구조는 겉모양 만을 꾸미기 위한 코드로 생성되어 있어서, 테이블의 구조와 접근을 용이하게 할 수 있는 여러 요소들과 속성들은 전혀 사용되지 않음.
왜? 화면 해독기와 기타 여러 보완 기술들은 테이블이 올바로 짜여져 있지 않는 한은 데이타 테이블을 해독하는 것이 불가능하다. 데이타 테이블을 어떻게 짜야 하는지에 관한 많은 글들은 Web Standards Project의 A table, s’il vous plaît에서 확인할 수 있다.
div와 class들의 남용
광적인 <span> 사용과도 관련이 있다. 불필요한 div과 class 속섣들의 사용.
왜? “광적인 <span> 사용”과 “의미론적인 뜻의 결핍” 참고.
너무나도 넓게 고정되어 있는 너비
만약 고정된 너비의 디자인을 사용한다면, 너무나 넓게 하지는 마라. 알림: 고정된 너비와 가변 너비에 대한 여러 논란들에 관해서는 이 곳에서 말하지는 않겠다.
왜? 만약 지정해 놓은 너비가 방문자의 모니터 크기보다 넓다면 가로 스크롤(scroll)이 강요될 것이며, 이것은 사용성 측면에서는 아주 나쁜 것이다.
애매하거나 겉모양에만 의미를 둔 class와 id 이름들
class 혹은 id 이름을 지을 때 해당 객체가 무엇을 하는지가 아니고 어떻게 보여지는가에 따라 이름을 붙이는 것.
왜? 이렇게 하면 나중에 다시 디자인할 때 혼동을 일으킬 수 있다. largeblue라는 이름의 class는 정작 글자를 작고 빨갛게 하는데 사용되어지는 불상사가 발생할 수도 있다. 또 id 이름이 leftcol로 되어있더라도 오른쪽으로 치우치게 보여지는데 사용되지 말라는 법은 없다.
배경 색깔이 없음
body 요소에 배경 색깔을 지정해놓지 않음.
왜? 많은 사람이 결코 같은 배경 색깔을 브라우저에 지정해서 사용하지는 않는다.
제대로 된 모양을 갖추지 못한 XHTML
XHTML를 쓰지만 제대로 된 모양을 갖추지 못함.
왜? 만약 XHTML이 올바른 “application/xhtml+xml” 형태로 전달된다면, Mozilla에 기반을 둔 브라우저들에서는 올바른 형태의 XHTML을 표시하지 못한다. 현재 이 곳의 모든 문서들은 “application/xhtml+xml” 행태로 전달되고 있지는 않으며, 그 이유는 Content negotiation의 글에서 찾을 수 있다.
글자 입력 칸들에 충분하지 못한 색깔 지정
폼(form) 필드들에 단지 배경 혹은 글자 색깔만 지정하는 것, 특히 한 줄 혹은 여러 줄의 글자 입력 칸들 (input type="text" 그리고 textarea).

왜? 어떤 사람들은 그들의 브라우저 혹은 운영 체계에 반전된 색깔들을 지정해서 사용하곤 한다. 이렇게 하면, 글자 입력은 기본적으로 하얀 바탕에 검은색 글자 대신에 검색은 바탕에 하얀색 글자로 표시가 된다.

이렇게 되면 지정한 한 가지의 색깔이 배경의 색깔과 구별하기 어려운 상황이 될 수도 있으므로, 글자 입력 칸들에는 항상 글자와 배경을 위한 색깔들을 동시에 지정해서 사용하거나 아니면 그대로 놓아두어야 한다.

– Web development mistakes, redux | 456 Berea Street의 글을 옮김.
(이 글에 달린 댓글들 또한 흥미롭고, 빼 놓지 말고 읽어야 할 것.)

관련 참고 글들

꼬리표:

관련된 주제의 글

“웹 개발시 저지르는 실수들”에 달린 4개의 댓글

음, 브라우저 염탐이 브라우저 버전, 종류, 렌더링 엔진을 체크하는 것을 의미하나요?
저 같은 경우에는 ‘css 핵을 최대한 자제해야 한다’라고 알고 있어서
브라우저 별로 체크해서 따로 클래스를 주는 방식으로 페이지를 만드는데 말이죠.
브라우저 설정에서 자신의 브라우저 정보를 숨기는 그러한 기능도 있나요…?
그렇게까지 쓰는 유저를 위해서라면 css핵으로도 어떻게 버전을 체크할 방법이 없지 않나요?

그리고 ‘지나친 JavaScript 의존’에서 페이지 이동을 자바스크립트로 하면 접근도 어렵고, 검색 엔진 순위에서도 밀려난다고 말씀하셨는데요.
제가 링크를 클릭하면 어떤 특정한 효과를 한 5초 가량 보여주고(팩맨이 글자를 먹는 효과), 그 이후에 페이지가 이동하게끔 구현했는데 말이죠.
(기본적으로 a태그를 이용하되 a태그의 기본 이벤트를 제거하였습니다.)
님께서 말씀하신 것은 button이나 input type=”button”과 같이 버튼식 페이지 이동을 자제하라는 말씀이신가요?
버튼을 눌러서 페이지 이동하기를 원할 경우에는 버튼 이미지로 대체 후에 a태그로 감싸줘야 할까요?

브라우저마다 제각기 방법은 다르지만, 자신을 숨기는 기능은 있습니다. 그런데 여기서 말하는 브라우저 염탐을 자제하라는 얘기는 여기에 의존해서 사이트의 정상 작동에 문제를 일으킬 소지가 없는지 주의하라는 얘기지요. 말씀하신 것처럼 CSS 경우에도 브라우저 호환성 문제로 브라우저별로 따로 대응하기 마련인데, 유저 에이전트를 속인 브라우저까지 대처하긴 어려우므로 사이트의 특정 스타일이 흐트러지는 일은 막기 힘들겠지요. 다만, 사이트가 정상 작동하는데 무슨 브라우저를 쓰든 문제없게 만들자는 것을 강조한 얘기입니다.

그리고 말씀하신 링크 문제는, 기본 이벤트를 제거하셨다면 접근성에도 문제가 있지만, 그와 같은 상황에서 사용자 입장에선 누가 한 5초간 붙잡아 놓고 가는 길을 방해하는 상황처럼 불쾌감을 느낄 수도 있습니다. 요샌 스크롤 반응에도 민감해 하시는 분들이 많거든요. 그래서 그냥 가시적 효과라면 차라리 없애는 것이 좋을 것 같네요. a 태그와 button은 엄연히 그 사용 목적이 서로 다르므로, 다른 페이지로 이동할 목적의 것이라면 a 태그를 써주는 것이 맞겠네요.

댓글을 남겨 주세요