[펌] 웹표준의 이해 - 웹표준 HTML

[출처] 웹표준의 이해 - 웹표준 HTML|작성자 웃자웃자

hoons.net에 올렸던 글입니다.

블로그같지 않은 블로그인데... 그래도 글 읽어주시는 분들이 이따금씩 계셔서 여기에다도 씁니다.

이번 이야기는 중요한 이야기이니 초보 개발자분들에게 많은 도움이 됐음 합니다.

 

오늘은.. 웹표준에 대한 이야기를 아는 만큼만 해보도록 하겠습니다.

아마 도움이 많이 되실 꺼라 확신하며... 돈도 될꺼라 확신해 봅니다. 아니다면 죄송 ㅋㅋ...
 
ASP.NET(MVC말고) 개발자들은... 아마 웹표준이 뭥미? 하시겠죠?
아니... JAVA개발자 역시 HTML코딩에 대해 정확히 이해하고 잘 하는 사람은 드뭅니다.
특히 JAVA같은 경우 소규모 프로젝트보다는... 약간 규모가 있는 SI쪽에서... 밀어 붙히는 플랫폼이다 보니...
업무 분리가 잘되어 있는 편이죠. 그래서 HTML에 대해 잘 모릅니다.
헌데 경험상 웹개발자라면... 말이죠... 웹코딩 잘해야 합니다. 웹코딩(HTML)은 디자이너의 영역은 아니라는 거죠.
디자이너와 개발자 중간자적 위치의 포지션인데... 현실은... ^^; 그나마 둘중 누가 해야하느냐 라고 따진다면...
개발자에게 맞는 업무가 아닐까 싶습니다. 일단 텍스트로 되어 있으니깐요...
사실 또다른 포지션이라 함이 맞습니다. 그만큼 어렵고 복잡한게 사실입니다.
최근 웹표준 이슈가 불거져 나오면서 더욱더 중요하게 대두되었고...
웹표준 코더가 없다는 사실 때문에 몸값이 장난아닙니다.
이론적으로 알더라도 실제로 코딩을 해보면... 난점이 한두가지가 아니지요.
이건 뭐 국내뿐만 아니라 미국도 마찮가지지요. 몸값이 장난이 아닙니다.
 
여튼 웹개발자는 웹을 이해하고 있어야 합니다. 여기서 말하는 웹이란 HTML 을 이야기 합니다.
항상 말씀드리지만요... 사용자(고객)에게는... 서버 기술이 뭔지는 전혀 중요하지 않습니다.
호랑이 담배피던 시절 ASP, PHP, JSP든, 최근의JAVA+프래임워크든, ASP.NET이든... 그게 무슨 상관이겠습니까?
개발자에게만 중요한 이야기인거죠.
서버가 토해내는 것이 HTML이라는 것이 중요한거지요.
결과가 무조건 HTML 문자열이라는 것... 이것이 웹 개발의 가장 중요한 개념입니다.
그래서 쉬운 편입니다. 결과가 문자열이기 때문입니다.
계산을 통해 행렬을 돌출해야 하는 3D어플이라든지, 최대한 파일을 빨리 만들거나,  이미지 프로세싱을 빨리하기 위한, 정렬을 빨리해야한다거나 하는 머리복잡한 알고니즘 등이 들어가지 않으니... 상대적으로 쉬울수 밖에 없습니다.
물론 최근의 API들이 워낙 잘나와 개발이라는 업무자체가 그닥 어렵지는 않습니다.
그렇다고 웹개발자를 저평가해서는 안됩니다. 저역시 이일로 먹고 사는 중이니깐요.^^;
웹개발자가 어려운것은 알아야 하는 지식과 기술이 너무 많다는게 문제입니다.
웹개발자가 알아야 할 기술들에 대해서는... 다시 이야기하도록 하겠습니다.
JAVA계열보다는... MS쪽 플랫폼 개발자들이 이런 잡다한 지식에 관심이 많습니다. 경험상 말이죠.
여튼... 서버 기술은 중요하지 않다는 말씀을 드리려다... 삼천포로..^^; 
사용자에겐... 개발자들의 잘난척 거리인 OOP라든지 알고 있는 한두가지 디자인패턴 등...이 중요한게 아니란거죠^^;
 

HTML스펙이 정해진 후 현재의 XHTML이라는 개념은 1999년도에 이미 생겼습니다.
헌데... 당시 브라우저는 XHTML 스펙을 해석해내지 못했지요. CSS 역시... 해석해 내지 못했습니다.
그시절 브라우저는  테이블만큼은 기가 막히게 해석해 냈지요. 물론 브라우저마다 약간 다르게...
-그래서 말인데요... 호랑이 담배피던 그 시절에는 넷스케이프와 IE와 반반이어서...
접근성 강화를 위해 두 브라우저에서 모두 사용할 수 있도록... 홈페이지를 두개 만들고... 인트로 화면을 두어...
IE용 넷스케이프용 홈페이지를 링크한다거나...
화면 해상도가 완전 별로인 사람도 있고 조금 좋은 사람도 있어서 해상도에따라 홈페이지를 만들고 인트로 화면을 두거나 하는 그런 헛짓을 했었답니다.-
 
여튼 테이블이 부담없이 레이아웃을 작성할 수 있는 유일한 길이었기에...
테이블 레이아웃이 유행하게 됐지요. 여전히 테이블 레이아웃은 유효하고 접근성 좋은(장애인말고...) 나쁘지 않은 레이아웃임은 분명합니다. 적어도 CSS핵같은 브라우저 버그를 이용하는 퐝당한 짓은 안해도 되니깐요.
 
테이블 레이아웃이 인기있게 된 또 다른 이유는 웹발전기(.COM 1990년대 후반)에 모뎀을 사용하는 사람이 많았다는 겁니다. 제 기억으로는 두루넷은 한정적인 지역에서 서비스했으며(1997년), 하나로통신은 1998년쯤에 출범했었으니, 당연히 인터넷 인구도 별로 없었고(이시절 게임방이 뜬 이유입니다.)... 방법은 모뎀뿐이었죠. 그 때는 이미지 하나 받기가 부담스러웠던 시절이죠.
1024*640 이미지를 한꺼번에 받아서 보기에는 부담스럽다 보니 이미지를 쪼개게 됩니다. (pc사양때문이 아닙니다. 단순히 네트워크속도 때문입니다.)그리고 테이블로 레이아웃을 만들어 이미지 하나를 완성하게 되지요.
적어도 사용자가 지루하지 않게 하기 위한 좋은 방법이었습니다. - 조각난 작은 이미지를 불러오면서 불러진 것부터 표시했으니깐요-
이방법으로 메뉴도 만들게 되고...홈페이지 전체를 구성하는 경지에 이르게 되지요.
여전히 테이블 기법을 많이 사용하는 이유는 웹의 발전을 이끌었던 저같은(?) 리더(?)들에게 너무나도 익숙한 당연한 방법이기 때문이죠.
 
IE5까지도 여전히 CSS는 제대로 해석되지 않았습니다. IE6이 나오고 파이어폭스가 나오고 크롬이 나오고... 그러면서 제프리젤드만 같은 사람들이 웹표준에 대해 강력히 주장하게 되면서 브라우저 제작사들이 웹표준에 대해 관심을 갖게 되지요.
때마침 미국에서 재활법 508조(section 508이라고 합니다.)가 재정되면서... 장애인에게도 웹에 접근할 수 있는 즐거움을 주라고 강재하게 되지요.
이것을 웹 접근성이라고 합니다. 웹접근성은 W3C WAI(웹접근성발안)을 통해 WCAG 1.0(웹콘텐츠접근성가이드라인)으로 이미 1999년도에 구체화되어 있었습니다. 헌데 지켜지질 않았던것 뿐이지요.
W3C의 권력은... 제조사에게 압박도 못줬던 모양입니다.
 
과거가 어찌 되었던, 국내에서도... SI업체들의 로비아닌 로비로...(단가를 올려보겠다는 심산) 웹접근성이 중요하게 대두되어 2년전부터 웹표준 코딩에 대한 관심이 많아지게 됩니다.
네이버 다음... 심지어 쇼핑몰(지마켓/11st 등)까지 웹접근성을 위해 조금이나마 노력하는 모습은 바람직하다 하겠습니다.
 
웹표준/웹접근성... 이제 브라우저도 이런 요소를 잘 처리해주다보니... 그저 보여주기 위한 HTML 시대는 지났다고 보시면 되겠습니다.

웹브라우저가 웹표준을 비교적 제대로 준수해주는 현재는 접근성의 시대입니다.
 
여기서 접근성이란... 어떤 기기에서도 사용할 수 있는 웹을 의미합니다. 
모든 브라우저에서는 당연지사... 시력장애를 가진 사람들에게는 읽어주는 웹브라우저... 
그리고 점자 표시 웹브라우저... 
마우스를 사용하기 힘든 사람들에게는 단축키로 접근가능한 컨텐츠... 동영상에 자막은 필수 등등...
 
장애를 가진 사람이 접근할 수 있는 웹이라면... 나이드신 분들뿐만 아니라 그냥 일반 정상인들도 접근하기 편한것은 지당한 결과입니다. 운전하면서... 리더기가 읽어주는 콘텐츠를 들을 수도 있을테고... 음성인식기를 통해 명령을 내릴 수도 있다는 거지요.

그리고 이 시대의 최고 멍청한 녀석.... 검색엔진 수집기....(얘는 기계입니당.) 이친구가 알아먹기 쉬운것이 접근성 좋은 웹이라 라고 이해면 될 것 같습니다.

 
웹표준코딩이라는 것은 결국 웹접근성 향상을 위한 코드라고 개인적으로 정의내릴 수 있겠습니다. 
재미있는 개념이죠?^^; SEO(검색엔진 최적화)는 자연스럽게 그냥 따로온답니다.
 
예전에는 HTML이라고 했으나 지금은 XHTML이라고 합니다. XML에 입각한 HTML이라는 거지요. 즉 웰폼드하게 만들자라는 거에요. 태그 열었음 닫아라~ 라고 이해하시면 될 것 같습니다.웰폼드한 XML은 온전한 하나의 포멧을 의미하지요.

아직은 XHTML로 넘어가는 과도기입니다. 기존의 HTML로 서비스 되는 곳이 90%가 넘을 겁니다.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
위 문장은 HTML 에서 가장 위쪽에 넣는 거네요. 많이 보셨죠?
Transitional 이라는 게 보이는군요. [과도기] 이런뜻이지요. 엄격한(Strict)으로 바꾸면 참 많은 오류가 나올겁니다. 
현재는 Transitional을 지원하지만 2.0으로 가면 Strict만 써야 합니다. Transitional의 다음 버전은 불행히도 없습니다.
즉 상위 호환성(옛날 버전 말고 앞으로 나올 버전)을 위해서는 Strict로 바꿀 필요가 있다는 이야깁니다.
 
어떤가요? 기존의 방식이 미래에는 없어진다는 말 하나로 웹표준에 대해 어느정도 이해하고 있어야 할것 같지 않습니까?
알아야 합니다. 웹을 업으로 살아가려면요.
 
웹접근성을 용이하게 만드는 웹을 웹표준이라고 정의할 수 있다고 했습니다. 웹접근성을 용이하게 하면... 표준을 지킬 수 밖에 없기 때문입니다.
 
WCAG2.0초안(언제 정식이 발표될지는 모르겠네요)은 1.0에 비해 정리를 해 놨습니다. 
인식의용이성, 운용의 용이성, 이해의 용이성, 신기술 등 4가지로 나누었죠. 
국내에서는 아직 확정되지도 않은 2.0 초안으로 2005년에 한국 웹접근 가이드라이으로 만들어버렸더군요--; 하학... 
http://www.wah.or.kr/index.asp 여기 가시면 확인하실 수 있습니다.^^; 
그나마 1.0이 아니라 2.0으로 만들긴 했는데... 이건 뭐 2.0 해석해 놓은듯한 인상이... ㅠ.ㅠ
이래놓고 월급받으니... 얼마나 편할까요? (물론... 부럽다는 이야깁니다.)

서두는 이정도 이제 실무적인 이야기로 넘어가겠습니다. 

 웹표준 HTML의 가장중요한 원칙은 이것입니다.
의미에 맞는 태그를 써서... 구조화된 문서를 만들고...
디자인은 CSS로만 처리하자.
 
CSS를 제거해서 HTML을 읽어주는 것이 스크린리더기라고 했을 때...
CSS를 제거해도 콘텐츠를 잘 인식할 수 있어야 한다는 거지요.(인식의 용이성)
 
의미있는 태그란...
우리가 잊고 살았던 태그들입니다.
처음부터 웹을 하지 않았던 사람들은 아예 써보지도 않았을 태그들이군요.
<h1>~<h4>
<p>
<address>
<img src="" alt="무조건 넣어"> (스크린리더기는 이미지는 읽지 못하나 alt의 문자를 읽어냅니다.)
<ul><li/></ul>
<ol><li/><ol>
<dl><dt/><dd/></dl>
또 뭐가 있나... 대략 이정도면 되겠군요. 나머지는 번외편...


모든 HTML 태그에는 브라우저마다 초기값으로 각 태그에 적당한 CSS를 적용해 놓습니다.
즉 style="" 어트리뷰트를 쓰지 않는다면 브라우저마다 설정된 초기값으로 표현한다는 겁니다.
결국 CSS를 통해... 디자인은 맘대로 바꿀 수 있다는 이야기지요.
/
<p>안녕</p>
<style>
p{margin:0; padding:0; line-height:.16} 
</style>
/
 
이렇게 주면... 모양새가 많이 바뀐다는 거지요.
모양은 내가 원하는대로 바꿀 수가 있으니... 용도에 맞는 태그를 쓰자... 이것이 웹표준 코딩의 기본인 것입니다. p태그는 콘텐츠에서 하나의 절을 의미합니다. </p>를 만나면 스크린 리더기는 한박자 쉬겠지요.
 css 적용이 안되는 브라우저라 하더라도 알아 볼 수 있을 것입니다.
 
접근성이라는 것은 바로\ 이런 이야기지요.
테이블 해석이 달라서 레이아웃이 깨지거나 하지 않을테고 테이블때문에 스크린리더가 버벅거리는 일도 없겠지요?
 
좋아... 알았어... 의미에 맞게 태그를 쓰겠어... 헌데... 레이아웃은 어떻게 할꺼야? 
되도록이면 테이블을 쓰지 말라며? 그럼 어떻게 하라는 거냐?
 
레이아웃 이야기가 해야겠네요.
기존 테이블 레이아웃 이야기부터 합시다.
<table>
<tr><td>홈으로</td><td>회사소개</td><td>제품소개</td><td>방명록</td></tr>
<tr>
<td colspan="4">
콘텐츠
</td>
</tr>
</table>
 
 
딱 보니깐 메뉴네요. 뭐가 문제일까요? 문제없습니다...
<th>(컬럼헤더부)를 썼다면 오히려 문제가 될것입니다. 
리더기는 테이블을 읽지 않고 홈으로~ 회사소개 같은 텍스트로만 읽어낼 것입니다.
접근성에는 별 문제가 없습니다.
다만 규약에만 문제가 있습니다. 테이블은... 레이아웃용 태그가 아니라...
표 콘텐츠를 위한 태그라는 거죠.
그리고 어느날 갑자기 디자인이 바뀌었습니다.
저 메뉴가 상단이 아니라 왼쪽에 위치해야 한다는 거지요. 수직으로 일렬로... 어찌 처리하겠습니까?
당연히.. HTML자체를 수정해야 겠네요.
문서의 구조를 바꿔야 한다는 겁니다. 위 예제는 워낙 쉬우니 그러려니 하오나...
복잡한 전체구조가 테이블로 되어 있다면... 다 바꿔야 합니다.
 
위에 것을 말이죠.
<ul>
<li>홈으로</li>
<li>회사소개</li>
<li>제품소개</li>
<li>방명록</li>
</ul>
 
이렇게 바꾸면...
ul{margin:0; padding:0; list-style:none};
ul li{backgound:url(/Img/dot.gif) 5px 5px; float:left};
CSS를 통해 얼마든지 레이아웃 변경이 가능합니다.
또한 태그 역시 의미있게... 사용을 해줬네요. 목록아니겠습니까?
CSS적용이 안된다 해도 우리는 쉽게 알아 볼 수 있습니다.
-> 이해되셨죠?
 
 
<div> <span> 등이 있습니다.
div는 style=display:block입니다. span은 inline이죠.
block은 네모 상자고 inline은 텍스트로 취급한다는 이야기입니다. 흔히 이넘들은 컨테이너라고 합니다. 

그룹화하거나... 디자인을 위한 컨테이너로 쓰일 수 있는 좋은 태그지요. 실제로... 그러라고 나온 놈입니다.
div는 division의 약자기도 합니다. 나누는 거죠. 구역을 설정하는 역할을 하는 겁니다.
 
이녀석들로 레이아웃을 만들자~~ 입니다. 물론 웹접근성에 문제가 없다면 테이블도 괜찮습니다. 테이블을 사용하지 말자가 아니라 웹접근성에 문제가 되는 부분을 제거하자 가 되다 보니 div를 쓰는게 원칙에 맞지 않느냐가 되는 것입니다.
 
여기서 이제 float이라는 게 나옵니다. 위에서부터 차근차근 내려오던 박스모델들의 흐름을 바꿔버리는 거지요.
float:left;
요게 들어가면 왼쪽에 붙혀 버립니다. right는 오른쪽에...
width가 컨테이너 width보다 크면 아래...(이것때문에 IE버그가 문제가 좀 됩니다만... 1px버그라든지 3px마진+라든지)
clear:both를 만나면... 다시 float이 해제가 되지요.
 
이것으로 복잡하고 짜증나긴 하지만.. 테이블 레이아웃으로 했던 디자인은 뭐든 가능합니다. 수직 중앙정렬이 잘 안될뿐이져^^;
 
흔히 웹표준에서 나오는 오해가 디자인이 멋지지 않다는 건데.. 그렇지 않습니다.
테이블로 가능한 거라면 div float을 통해 혹은 position을 통해 뭐든 가능합니다.
이것이 CSS에서 이야기하고 싶은 핵심이군요. 
 
다만 여전히 IE6을 쓰고 있는 사람이 다수인지라... CSS만을 통해 모든 브라우저의 접근성을 향상시키는것은 쉬운 일은 아닙니다. IE6 업그레이드 운동이 그래서 일어났죠. 헌데 IE7도 그다지였습니다. IE8에서 납득할만 수준이었죠.^^; 실제로 IE8의 컨셉이 웹표준이었답니다. 웹표준 명세서가 나온지 10년이 지나서야... MS는 제대로 된 웹표준 브라우저를 제작한거지요. ㅋㅋ...
여튼... 아직은 IE6을 사용하는 사람이 많은지라... CSS 핵이라는 방법이 동원됩니다. 이 부분은 검색해보시면 될 것 같습니다. 브라우저의 버그를 이용한 어처구니 없는 방법이지만 어쩔 수 없는 방법이지요.
 
 웹표준에 대한 이야기는 여기까지 하지요.
정리하죠.
 
웹표준은 뭐다?
 
1. 사람이라면 누구나 웹콘텐츠를 사용하고 이해할 수 있도록 코딩하는 것...
2. 의미있는 태그를 사용해서 최대한 심플하게 코딩하고 디자인은 CSS로 따로 작성하는 것...
3. 되도록이면 네비게이션메뉴나 잡다한것들보다 콘텐츠가 문서 상단에 위치하도록 코딩하여 장애인들에게 콘텐츠 접근성을 조금이나마 높히는 것
4. 텍스트가 아닌 콘텐츠는 텍스트 콘텐츠를 함께 제공할 것...
5. 플래쉬, 액티브 엑스 등은 접근 불가능한 기기에서 사용될 수 있는 텍스트+이미지 콘텐츠 등... 대체 콘텐츠도 함께 제공할 것...
 
이정도로 요약해 볼 수 있겠군요.
 
 
제가 아는 웹표준이에 대한 이야기였습니다. 도움이 되셨나요? 도움이 되셨다 봅니다. 이렇게 정리된 글 찾기 쉽지 않을 겁니다.(자뻑~)
아시다시피 ASP.NET의 서버 콘트롤들은... 웹표준과 거리있는 코드를 양산해낼 소지가 있습니다.
그래서 MVC가 더 낫지 않느냐? 라는 생각도 해보게 됩니다. 사실 ASP.NET은... 생산성 측면에서는 예술의 경지지만... 웹어플리케이션에는 맞지 않은 방법론입니다. 가슴아프지만 현실입니다.
 


마지막으로 엑티브엑스 이야깁니다.
엑티브엑스는 MS Windows 운영체제의 바이너리 레벨 컴포넌트(CBD) 규약중 하나입니다.
이런이런이런 인터페이스를 만들어 놓으면 ActiveX다 라는 겁니다.
C++로 짜는게 기본이지만(인터페이스 구현이니깐요)... VB로도 짤 수 있습니다. 
.NET과는 전혀 관계가 없습니다.^^;
자바진영에서 너무나도 정적인 HTML에 생명력을 불어 넣기 위해 나옵니다.
자바애플릿... 감동적이었죠. 정적인 HTML에 삽입된 애플릿은 뭐든 할 수 있었습니다. 시스템 자원을 모두다 끌어 쓸 수 있었지요.
그것에 대항하기 위한 개념으로 MS는 자사의 컴퍼넌트 기술인 ActiveX를 웹브라우저에 삽입하도록 합니다.
헌데 ActiveX는 너무 강력했습니다. 그것이 문제였습니다.강력한게 뭐가 문제냐? 좋은거 아니냐? 하시겠지만...
웹에 접속했다고...해서 당신의 Pc를 포멧해버리거나... 바이러스를 주입한다거나... 심지어 계정도 훔칠 수 있는 무시무시한 놈입니다. 3D게임마저 웹브라우저상에서 실행할 수 있는 녀석인거죠.
너무나도 유명한 플래쉬도 SWF포멧을 읽어다가 보여주는 플래쉬 플레이어 ActiveX인겁니다.
이 강력함으로 얻는 이득보다... 실이 너무 많다보니... MS에서 버리려는 겁니다.
ActiveX때문에 애플릿의 시대가 가버렸지만... ActiveX는 스스로 자살을 꿈꾸고 있답니다.
강력함 때문이기도 하고... 접근성의 문제 때문에 말입니다.
MS의 특허기술이기에... 타 브라우저에서 삽입은 쉬우나... 구현해낼 수가 없습니다. 그래서 각각 브라우저마다 플러그인 으로 만들어야 하는겁니다.
그리고 기존에 ActiveX로 가능했던 일들이 이제는 Flash가 발전에함에 따라... 사라져가고 있습니다.
개인적으로 ActiveX가 여전히 필요한 분야는... 웹에서 바코드를 인식한다든가 하는 어쩔 수 없는 분야...
게임사이트에서 게임을 실행하는 부분...
파일 업로드를 위한 드래그앤드롭 지원... 정도...이지 않나 싶습니다.
고로 최근에는 Flash를 제외한 ActiveX는 사라져야 하지 않느냐가 대세인듯 합니다...(포탈들... ActiveX 체제 유지하려면... 타 브라우저 PlugIn도 만들어라)
Flash에 대항하여 MS는 실버라이트라는 녀석을 내놓습니다. 실버라이트 플레이어는... ActiveX로 만들었지만... 자사의 특허에 의해 다른 브라우저에 삽입될 수 없으니...
파이폭스용 사파리용... 플러그인까지 함께 개발을 할 수 밖에 없었답니다. 골때리지요?^^;
ActiveX 이해 되셨죠?^^;
 
금융권이나 쇼핑몰 결재등에 쓰이는 엑티브엑스 이야기로 넘어가죠.
아시다시피 IE만 엑티브엑스를 지원합니다. 
나머지 웹브라우저에는 플러그인이 필요합니다만.. 아마 개발된 플러그인이 얼마 없는 걸로 압니다.(있을지도)
결국 은행과 쇼핑몰은 IE에서만 해야 합니다. 법으로 제정된걸로 압니다. 여기에는 로비가 좀 있지 않았겠느냐 라는 생각입니다.^^;
페이팔을 보면 브라우저의 자체의 암호화 기술(128bit면.. 풀수 없을겁니다.)을 이용합니다. 문제없이 잘 사용하지요.
헌데 우리는 굳이 필요없는(브라우저가 지원해주는데) 암호화 전송 ActiveX를 사용하고 있습니다. 요즘은 백신도 함께 깔아주고.. 키보드 해킹 방지프로그램도 함께 깔아주죠^^;--; 아놔... 별짓을 다합니다. 돈들어가게 왜 이러나 모르겠습니다만...
뭐 많은 업체들의 돈줄이니... 그러려니 합니다. (여기서 대두되는게... 바로 IT에서의 영업이 아닐까 싶네요)
그럼에도 이런 결재 부분 빼고는 웹접근성은 필요합니다. 
쇼핑몰에서 어디서든 상품 검색은 가능해야지요.^^; 결재는 가능한 사람한테 시키면 되는거니깐요.
뭐 여튼... XHTML이 그렇듯... 웹이라는 것은 여전히... 과도기라고 할 수 있겠네요.

 

다음에는 무슨 이야기를 해야 하려나요?

이제 밑밥도 떨어져 가고... 회사일이 바빠서 시간도 없고...

주말에는 잠자기 바쁘고.. ㅠ.ㅠ

 

다음에도 초보분들께 도움이 될만한 내용으로 찾아뵙도록 하겠습니다.