W3C 투덜투덜... 레이아웃 문제로 보는 웹

[천하귀남]

올해 중반부터 와이브로등의 광역 무선인터넷이 가능해지는것에 많은 기대를 걸고 있는 웹개발자 입니다.그래서 파일럿 프로젝트 겸 개인적인 목적을 겸해서 위키와 비슷한 메모장과 서버의 사진/파일을 열람/다운받을수 있도록하는 프로그램을 웹기반으로 만들고 있습니다.


만든지는 제법 되었지만 작년중반 AJAX를 접하고 올해 웹표준에 관심을 가지면서 사이트를 리뉴얼 중입니다. 지금은 불여우, 익스 양쪽에서 잘 동작하는 사이트가 되었습니다.

그런데... 만들면서 느끼는것이 W3C의 표준안이 구닥다리 같다는 느낌이 많이 들게 됩니다. 그도 그럴것이 협의 하는데 몇년, 권고안이 나와도 이게 적용되는데는 못잡아도 일년은 걸리는데 컴퓨팅 환경의 변화가 너무 빠른게 아닌가 합니다.

특히나 W3C표준안의 문제는 레이아웃 관련 요소에대해서 너무 신경을 안쓴다고나 할까요? 웹페이지 라고 해도 일종의 문서의 개념으로 보는 경우가 많은데 문서/출판쪽의 개념이 너무도 모자랍니다.

예를 든다면 HTML 4.0권고안에서 제거된 XMP 태그입니다. 택스트 내용을 그대로 보여주던 태그인데 삭제해 버렸군요 같은 W3C의 XML권고안의 경우 <![CDATA[ ]]>를 통해서 태그로의 해석을 막는것이 있는데도 오히려 제거해 버리는 군요 지금 불여우나 익스 양쪽에서 동작은 하는 태그입니다만 나중에 어찌될지 모르겠군요

페이지 리뉴얼을 하면서 레이아웃적인 면에서 웹표준이 모자라는 점때문에 투덜거려 봅니다. 개목걸이도 문제지만 빈 밥그릇도 문제군요

[빛알갱이]

<p>특히나 W3C표준안의 문제는 레이아웃 관련 요소에대해서 너무 신경을 안쓴다고나 할까요? 웹페이지 라고 해도 일종의 문서의 개념으로 보는 경우가 많은데 문서/출판쪽의 개념이 너무도 모자랍니다. </p>

http://www.w3.org/Style

을 보기는 하셨나요?

[천하귀남]

저 CSS가 100% 구현된것도 아니고 동작도 브라우져 마다 차이가 있지요 그리고 실제로 저것으로 완벽한 레이아웃 구현이 가능한지요 가능하다 하더라도 상당한 코드삽질이 요구되기도 합니다. 공연히 레포팅 툴이 존재하는것이 아니지요

제가 이야기하려는 것은 W3C의 대응이 공통의 협의라는 요소에만 치중해 느린게 아닌가 하는겁니다. 표준안이 나와도 구현하는데는 오랜 시간이 걸리다보니 브라우져 업체들은 제멋대로 만든다고 할수도 있지만 표준에 없는건 만들어 쓸수밖에는 없습니다. 하지만 각사가 제멋대로 만든뒤에도 이것에대한 통합이나 수정논의가 오래걸린다면 나중에 고치기는 갈수록 어려워지겠지요

W3C기준으로 간다면 innerHTML대신 createElement(''); 나 createTextNode(''); 등을 쓰겠지만 여러조건에 따라 결정되는 레이아웃이라면 저것으로 구현하기가 얼마나 힘든지 알아 주셨으면 합니다.

[zotoon]

저 CSS가 100% 구현된것도 아니고 동작도 브라우져 마다 차이가 있지요 그리고 실제로 저것으로 완벽한 레이아웃 구현이 가능한지요 가능하다 하더라도 상당한 코드삽질이 요구되기도 합니다. 공연히 레포팅 툴이 존재하는것이 아니지요

제가 이야기하려는 것은 W3C의 대응이 공통의 협의라는 요소에만 치중해 느린게 아닌가 하는겁니다. 표준안이 나와도 구현하는데는 오랜 시간이 걸리다보니 브라우져 업체들은 제멋대로 만든다고 할수도 있지만 표준에 없는건 만들어 쓸수밖에는 없습니다. 하지만 각사가 제멋대로 만든뒤에도 이것에대한 통합이나 수정논의가 오래걸린다면 나중에 고치기는 갈수록 어려워지겠지요

브라우저마다 차이점은 검색해보면 대응책도 다 나와있습니다.

혹시 완벽한 레이아웃이 테이블 레이아웃을 말하는 건가요? 디자이너 관점에서 테이블식 그리드에 꽉 막혀서 제작할 수 밖에 없는 테이블 레이아웃이 엄청 구린 레이아웃입니다.

CSS2.1이 표준으로 추천된게 1999년입니다. 우리나라에서 css2를 제대로 작업할 수 있는 디자이너가 얼마나 있는지 모르겠군요.

마지막으로 W3C 권고를 안지킨 브라우저의 미래는 어둡습니다. IE와 NN의 브라우저 전쟁에서 NN이 쓰러진 점은 W3C의 권고안을 무시하고 자사 태그를 사용한 점도 한 목있답니다.

[hiphapis]

혹시 완벽한 레이아웃이 테이블 레이아웃을 말하는 건가요? 디자이너 관점에서 테이블식 그리드에 꽉 막혀서 제작할 수 밖에 없는 테이블 레이아웃이 엄청 구린 레이아웃입니다.

이 말씀에는 동의하기가 힘드네요..

[빛알갱이]

CSS2.1이 표준으로 추천된게 1999년입니다. 우리나라에서 css2를 제대로 작업할 수 있는 디자이너가 얼마나 있는지 모르겠군요.

W3C가 빨리 간 부분도 있고, 느리게 간 부분도 있습니다. 말씀하신 대로 CSS 등은 브라우저 제작 업체가 아주 늦게 갔지요. Firefox 등이 선풍을 일으키지 않았다면 아마 CSS 2.x는 실질적으로 문서 상의 표준으로만 남아 있을 것입니다. MS가 IE를 뜯어 고칠 유인이 거의 없었을테니까요. (독점의 폐해를 보여 주는 단적인 보기입니다.) IE 7의 최근에 나온 시험판은 매우 향상된 CSS 지원을 한다고 합니다.

느리게 간 부분은 Web을 통한 응용 프로그램 개발 부분이고요.

마지막으로 W3C 권고를 안지킨 브라우저의 미래는 어둡습니다. IE와 NN의 브라우저 전쟁에서 NN이 쓰러진 점은 W3C의 권고안을 무시하고 자사 태그를 사용한 점도 한 목있답니다.

1990년 대 중반에는 양쪽이 다 마찬가지였지요. . 1998년에 소스 공개한 이후에 Mozilla 1.0이 나오기까지 공백이 너무 길었던 게 (1998년 하반기에 나올 수 있었던 Netscape 5.0을 죽여 버리고) 상당히 컸지요.

[jiyoon]

IE7이 출시되기 전인 지금까지는 기존 테이블 관점에선 그런 생각이 들 수 있겠습니다만, CSS2 spec을 하나의 언어라고 봤을때 여타 언어보다도 쉽고 직관적이라고 생각됩니다. 이는 디자이너들이 쉽고 빠르게 작성할 수 있도록 잘 고안되어졌다고 보여지는데, 이러한 부분들이 아무 고찰이 없이 사용자 혹은 기업들이 당장 입맛에 원한다고 해서, 요구하는대로 모두 수용해버린다면 뭔가 이상하고 지저분한게 나올것이라 예상됩니다. 넷스케이프와 인터넷 익스플로러 시절때 처럼 말이죠.
W3C는 공공적인 성향을 띄므로 여러가지 요건을 잘 따져서 스펙을 내놓아야 할테니 그만큼 시간이 걸릴테구요. 브라우저 개발사들은 자사 이익을 기반으로 업계표준을 형성하겠죠. de jure와 de facto 사이엔 미묘한 차이게 있겠지만 서로 상호 보완하는 관계라고 생각됩니다. de jure가 가장 우선시 되는것이 혼돈을 피하는 방법이겠고 가장 지향해야할 방향이라고 생각합니다.
얘기가 잠시 다른쪽으로 흘렀는데, 다시 CSS2를 얘기하자면 현재 스펙만으로 충분히 멋진 UI를 만들 수 있습니다. 앞서 zotoon님이 말씀하신 것 처럼 제대로 활용할 인력이 국내엔 열손가락도 안될것이란 문제입니다.
국내 디자인 경향 또한 해외완 다르게 테이블적인 디자인에서 벗어나질 못하고 있구요.
브라우저마다 달리 보인다는 것도 w3C의 스펙이 불만적으로 느껴질 수 있는건 사실입니다. 사실은 브라우저 개발사... 딱 집어서 말하자면 다른 브라우저들은 90% 잘 보여진다고 봐야하고, IE6는 나잇살 먹은 망나니라서 코딩하는 사람이 무지 피곤해집니다.
웹표준 하자고 얘기를 꺼내기가 내심 무서운게 이런 점들 때문이죠. 하지만, 웹표준은 개개인의 노력과 관심의 여하에 따라서 얼마든지 극복할 수 있는 문제이고, 이게 올바르고 모두를 위한 것이란걸 알기에, 늦은 시간까지 IE6 버그와 씨름하는 사람들도 많습니다.
개인적으로 IE7+에 대한 기대가 크고, marketshare에서 Firefox 보다도 IE7+이 사용자들에게 더 많이 설치되면 좋겠습니다. 그리고 W3C의 XML기반 스펙 뿐만 아니라 WHAT-WG의 Web Applications 1.0(HTML5)나 Web Forms 2.0 스펙도 있으니 각자 경쟁 혹은 협동체제에서 좋은 스펙들이 (옛날처럼 엉망진창이 아닌) 빠르게 등장할테니 너무 다급해하지 않아도 될거 같습니다.
두서없는 글 읽어주셔서 감사합니다.

[천하귀남]

저같은 웹프로그래머 입장에서 가장 피하고 싶은 경우가 이브라우져일때는 이렇게 저브라우져는 이렇게 해서 if문 투성이가 되는겁니다.
CSS스펙은 크게 불만이 없지만 DOM이나 javascript쪽이 문제가 심하고 브라우져 내장객체는 제멋대로지요

프로그램을 만들다보면 별것아닌 스크립트 인데 브라우져간 차이때문에 스크립트가 복잡해지는 경우가 생깁니다. 짜면 그만 아니냐 라고 하지만 기간과 비용이 한정된 프로젝트에서 몇%의 타브라우져로 인해 상당비율의 개발역량이 투입되는건 쉽게 선택할 문제가 아닙니다.
다행히 이런 커뮤니티를 통해서 많은 정보를 얻어가고 있습니다만 몇몇문제는 간단하게 포기할수 밖에는 없더군요 앞으로도 많은 정보가 오가고 나아가 이런 브라우져간 특성없이 표준코딩으로만 해결가능한 날이 왔으면 합니다.

여러분들의 의견 정말 감사하게 받았습니다.

[딜레마]

CSS2.1이 표준으로 추천된게 1999년입니다. 우리나라에서 css2를 제대로 작업할 수 있는 디자이너가 얼마나 있는지 모르겠군요.

그 이유가 무엇일까요? 시장경제적인 측면 말고, 기술적인 측면에서의 문제는 없을까요?
디자이너에게 너무 어려운 것은 아닌가요? (디자이너를 무시하는 것이 아니고, 통상적인 영역의 차이를 말씀드리는 겁니다.)
그래서 결론이 무엇인가요? (순수한 질문입니다)
앞으로는 css가 대세고, css로 디자인을 해야한다는 가정하에서,
디자이너가 공부를 더 해야하는 겁니까? 아니면 프로그래머가 css 디자인까지 해야하는 겁니까? (물론 프로그래머도 css 공부를 해야하는 것은 마찬가지겠지만...)

답변하지 않으셔도 되지만 혹 답변하시겠다면, 링크는 사양합니다.
전문가 분들의 개인적인 생각과 의견을 듣고 싶습니다.

[hiphapis]

답은 간단합니다......
HTML Coder 의 몫이죠..

HTML Coding 을 전문적으로 하는 인력이 있다면, 코더몫
HTML Coding 을 디쟈이너가 하는 회사라면, 디쟈이너몫
HTML Coding 을 개발자가 하는 회사라면, 개발자몫

[zotoon]

그 이유가 무엇일까요? 시장경제적인 측면 말고, 기술적인 측면에서의 문제는 없을까요?
디자이너에게 너무 어려운 것은 아닌가요? (디자이너를 무시하는 것이 아니고, 통상적인 영역의 차이를 말씀드리는 겁니다.)
그래서 결론이 무엇인가요? (순수한 질문입니다)
앞으로는 css가 대세고, css로 디자인을 해야한다는 가정하에서,
디자이너가 공부를 더 해야하는 겁니까? 아니면 프로그래머가 css 디자인까지 해야하는 겁니까? (물론 프로그래머도 css 공부를 해야하는 것은 마찬가지겠지만...)

답변하지 않으셔도 되지만 혹 답변하시겠다면, 링크는 사양합니다.
전문가 분들의 개인적인 생각과 의견을 듣고 싶습니다.

저의 기준에선 서버측면을 다루는 분은 웹개발자,
클라이언트측면을 다루는 분은 웹디자이너입니다.

출판디자이너가 디자인, 인쇄(용지 선택에서 배포까지)까지 하는 것과 마찬가지로
웹디자이너는 디자인, 웹출판을 다뤄야 한다고 생각합니다.

그런 측면에서 단순히 시안만 짜는 디자이너를 웹디자이너라고 부를 순 없겠죠.

이런 생각의 근간은 xhtml, css, dom의 기반 위에서 훌륭한(사이트에 따른 최적화된) 시안이 나올 수 있기 때문입니다. 그리고, css와 xhtml은 이지웍으로 구현가능할 정도로 단순한 게 대부분입니다. dom, js는 깊이를 알 수 없죠~

[hyeonseok]

저의 기준에선 서버측면을 다루는 분은 웹개발자,
클라이언트측면을 다루는 분은 웹디자이너입니다.

음...제 생각에 이미 이렇게 이분화 생각할 수 있는 단계는 지났다고 봅니다. app 개발자와 dba를 나눠 놓은 것과 마찬가지로 디자인과 퍼블리싱도 한사람이 할 수있는 단계는 지났습니다. 그리고 js와 dom도 클라이언트 측인데 포토샵만지는 사람이 이것까지 커버하기를 바라는 것은 무리 입니다. 결국은 웹개발자 영역으로 떨어질텐데 하나의 직분에 너무 많은 롤이 집중 되죠. 개중에는 분명 클라이언트쪽이나 DB에 전문인 직분이 나오게 마련입니다.

xhtml, css, dom의 기반 위에서 훌륭한(사이트에 따른 최적화된) 시안이 나올 수 있기 때문입니다.

이것은 이미 디자이너의 범주를 벗어났습니다. 웹사이트 기획의 문제지 디자인이나 시안의 문제가 아닙니다.

[딜레마]

제가 이해하는 수준에서, 지금까지의 의견을 다음과 같이 요약하면,

hiphapis -> HTML Coding 하는 사람
zotoon -> 디자이너
hyeonseok -> 개발자 or 이 분야 전문인력

결국, 상황에 따라 누구든 하게 될 수 있다는 말이군요. 정말 딜레마로군요.
서로서 자기 영역이라고 쟁탈전을 벌일까요, 아니면 다들 자기 영역이 아니라고 떠넘기기를 할까요?

[Channy]

제가 이해하는 수준에서, 지금까지의 의견을 다음과 같이 요약하면,

hiphapis -> HTML Coding 하는 사람
zotoon -> 디자이너
hyeonseok -> 개발자 or 이 분야 전문인력

결국, 상황에 따라 누구든 하게 될 수 있다는 말이군요. 정말 딜레마로군요.
서로서 자기 영역이라고 쟁탈전을 벌일까요, 아니면 다들 자기 영역이 아니라고 떠넘기기를 할까요?

아마 각자가 처해 있는 개발 환경, 조직 구조 등에 따라서 조금씩 다를 거라고 생각합니다.

웹디자이너가 개발자랑 바로 일하는 조직과, HTML 코더가 있는 조직 그리고 개발자가 HTML 코딩을 하는 조직 등등... 그런데 조직을 떠나서 현석님이 말씀하신대로 각 영역이 전문화 될 필요가 있습니다. 특히 구조(XHTM)+표현(CSS)+동작(DOM Scripting)이 전문화될 필요가 있는 것이죠.

사실 구조는 기획이 표현은 디자이너가 동작은 개발자가 맡는 것이 가장 이상적입니다. 그런 점에서 기획자와 디자이너가 조금 더 웹에 대한 기술 습득이 더 필요하다는 생각입니다. 웹 기획자이고 웹 디자이너라면 XHTML과 CSS를 이해하고 쓰는 게 그리 어렵다고는 생각되지 않습니다.

어쨌든 공유된 생각을 가진 팀웍이 웹 표준 사이트를 만들어 내는 게 좋은 안이라만... 그렇지 못한 현실에서는 누가 먼저랄 것 없이 CSS 레이아웃 기술을 익혀 두는 게 좋습니다. 언제 경영진이 웹 표준을 준수해서 사이트를 만들라고 할지 모르니까요. 그 때 가서 공부하면 주못 받을 만한 때는 늦습니다.

[eouia]

웹 퍼블리셔가 필요합니다.

1. 주어진 컨텐츠를 가지고 구조화시켜 XHTML문서로 만들 수 있다.
2. 주어진 디자인을 가지고 구조화시켜 CSS를 적용시킬 수 있다.
---> 여기까지가 최소요건
3. 주어진 기획서를 가지고 behavior등을 관장하는 JavaScript를 붙일 수 있다.
---> 이미 기존의 디자이너에게는 무리. 전문훈련을 받지 않은 개발자에게도 무리.
4. AJAX, AFLEX 등을 적용시키기 위해 서버사이드 개발자와 상의하여 인터페이스 프로토콜을 확립한다.
---> 최소한 서버사이드 개발자와 대화할 수준은 되어야겠지요.
5. 템플릿 방식의 개발방법을 따른다면 어느 정도 서버사이드 개발 스킬도 필요.


저로서는 디자이너에게는 2번정도까지나 바랄 뿐입니다.

실제로 효율상으로는 전문적으로 훈련된 퍼블리셔가 1~5를 맡아 하는게 최선이고, 차선이라면 1~2를 디자이너가, 3~5를 개발자가 맡는 정도까지는 가능하다고 봅니다.