miniworkshop1st [Standard Magazine

날짜 : 2008. 6. 27 늦은 0730 ~ 0920 / 뒷풀이(0930 ~ )
장소 : TOZ 신촌 본점
의장 : 신현석
도움 : deute
서기 : 봄눈
참석 : bitty, 서정민, 혜윰, 봄눈, hwzzang, nothinking, 루미렌트, hobread

bitty: 여러 브라우저로 인해 가끔 CSS의 핵을 쓸 때가 있는데 다들 어떻게 해결하고 계신지, 핵을 안쓰고 싶은데 그게 잘 안된다.

신현석: 핵을 쓰면 수정이 불편하다. 표준 스펙을 제대로 다 쓸 수 있으면 좋지만, 현실적으로 그렇지 못하다. 일부 핵을 쓸 수 밖에 없는 상황 때문에 나온 것인데 이 자리에서 계신 분들은 자연스럽게 (핵을 피해서 CSS를 작성하는 수준으로)이동이 된 것 같은데 처음에는 가지고 있는 속성들을 다 사용하고, 마진이나 패딩 등을 직관적으로 쓰게 되는데 점차 작업을 하다보면 각 브라우저별로 사용해도 안전한 속성들만 골라서 쓰게 되는 형태로 바뀌게 된다. 그것을 알아가는 과정이 노하우인 것이고, 표준 스펙만 가지고는 알 수가 없는 것이다. 디자인에 따라서 페이지를 구현하다 보면 디자인에 대해 특징적으로 그 방법이 달라져서 거기에 들어가는 속성들이 차이가 나올 수 있다. 그것은 경험을 많이 해보지 않고서는 무엇으로 어떻게 구현해야 할지 잘 알 수 없게 된다. 여기서 다른 사람의 코드를 보는게 중요하다. 하지만 실제로는 많은 분들이 그러지 못하고 계신것 같다. 다른 사람의 코드를 참조하거나 외국의 사이트를 확인해 보면서 공부해 보신 분 계신가요? (3분 정도 손 들음)

그런데 요즘 보면 거의 대부분 자기가 알고 있는 CSS 스펙만 사용하고, 최악의 경우 IE7 기준으로 작업을 해서 사용해도 안전한 속성들에 대한 -혹은 효과적으로 구현하는 방법에 대한- 그러한 사전적인 경험이 쌓이지 않은 상태에서 작업하게 되고, 때문에 핵을 남발할 수 밖에 없게 되는 것 같다. 가장 최악의 경우가 IE7 기준으로 작업을 하는 경우가 될 것이다. 그것을 맞추려면 CSS핵을 사용할 수 밖에 없다. 그래서 가장 중요한 것은 최소 요구 사항 브라우저가 무엇인지, 그래서 최소 요구 사항 브라우저에서 가장 표준지원이 안되는 브라우저가 무엇인지를 확인해야 한다. 보통은 IE6이죠? IE5.5가 포함되면 IE5.5를 기준으로 작업해야 한다. 상위 레벨의 브라우저는 낮은 레벨의 브라우저에서 지원하는 스펙을 지원한다.

또, 이 주제에 대해서 하실 말씀 있으신가요? 힘든 문제다. 1차적으로 핵을 쓰지 않는 방향으로 해야 하고, 그렇다 보면 사용할 수 있는 것이 몇가지 없다. 마진이나.. 플롯트가 굉장히 자유로운것 같지만 Float를 적용해야 하는 모델에도 정형화가 됩니다. 이런 레이아웃에서는 DIV를 이렇게 넣어야 하고, 이런식으로 Float 해야 하고, 그런게 없이 왼쪽, 오른쪽 띄우다 보면 다 꼬여버리게 된다.

이 문제는 이 자리에서 결론을 내기가 어렵다. 케이스가 워낙 다양하기 때문이다. 브라우저를 여러개 열어 놓고 코드를 한줄씩 테스트 해 보면서 차이점을 확인해서 차이가 발생하면 그 속성을 사용하지 말아야 한다. 다른 방법으로 구현을 해야 한다.

서정민: 처음 에이젼시를 접할 때 신규 사이트를 시작하기보다 유지보수 쪽에서 경험을 쌓는 것이 개인적인 스펙을 높일 수 있는데 도움이 된다. 초보가 에이젼시에서 신규 사이트에 투입이 되면 (일정에 쫓겨) 핵을 남발하는 잘못된 습관을 갖게 된다.

서정민: 각자가 생각하는 퍼블리셔의 역할 및 현 (X)HTML의 스팩의 오해에 대한 주제를 던졌다. XHTML 2.0 이나 HTML 5 등 앞으로 나올 새로운 스펙들에서 사라질 것으로 보이는 요소와 속성들에 대해서 사용하지 말라고 권장하는 분위기가 있는데 옳은 것인지 모르겠다. HTML 5나 XHTML 2가 나오더라도 DTD 설정은 HTML 4.01이나 XHTML 1.0인데 굳이 사용하지 말라고 하는 것이 문제가 있는 게 아닌가? 새로운 스펙이 나오더라도 이미 제작된 문서의 DTD를 바꿀 수는 없지 않은가? 현재의 DTD에 맞게 응용해서 사용되어야 하는 게 아닌가? 예를 들어 DL, DT, DD 에 대해서 논란이 많다. DTD문서를 열어본 것과 W3C 스펙과 상이한 부분이 있어 어느 것을 맞춰야 하는지도 알기가 어렵다.

신현석: DTD는 스펙을 온전하게 구현하지 못했다. (HTML에는) 워낙 예외사항이 많아서 완벽하게 DTD로 구현하기가 어렵고, 따라서 HTML Validation도 완벽하게 검증해 준다고 보기 어렵다.

서정민: DL에 대해서 HTML 5.0과 4.01의 내용이 다르기 때문에 어떤 식으로 적용해야 옳은지 판단이 어려울 때가 있다.

신현석: 외국에서도 논란이 되고 있는 요소이기 때문에 DL 요소 자체를 없앤다는 의견도 있었다.

듀트: HTML 5나 XHTML 2와 같이 새로운 스펙에서 없어지는 요소와 속성이 있는데 하지만 여전히 <b>와 같은 요소는 사용될 것이다. 어차피 새로운 스펙이 나와도 하위 호환성을 가지고 있기 때문에 브라우저에서도 다 지원해주긴 할 것이다. 하지만 중요한 것은 DTD는 대부분 XHTML을 사용하고 있음에도 여전히 사라진 요소와 속성을 사용하고 있는 것을 보면, 새로운 스펙이 나와도 그 요소와 속성을 계속 사용하게 될 것이다. 우리가 선택한 DTD에서 사용하면 안되는 요소와 속성을 아는 것이 어려운 것이 아닌데 주의를 기울이지 못해서 계속해서 사용하는 실수를 범한다.

서정민: HTML 5가 아직 나오지는 않았는데 현재 HTML 4나 XHTML 1.0을 사용하면서 왜 HTML 5에서 사라지는 요소와 속성을 미리부터 사용하지 말라는 이야기들을 하는지 이해가 안된다.

신현석: 중요한 게 태그가 먼저가 아니라 만약에 그것을 썼으면 DTD를 그거에 맞게 쓰면 된다. 그래서 항상 그 그 그.. Strict DTD를 쓰는 분들이 간혹 있다. 사실 Strict DTD를 쓴다는 것은 그냥 문서 스타일인 경우에 적당하지 일반적인 비주얼 웹사이트는 적당하지 않다. 그러한 용도로 태그를 써야 된다면 XHTML을 사용하면 안되고, 그리고 기존에 저장된 컨텐츠가 있을 것인데 그것에 맞게 HTML4.01을 써야한다. 그런 관점이 아닐까요. (서정민씨가) 말씀하신 것 같이 (사라질 요소나 속성에 대해서) 쓰지 말라고 했다는 것은 심한 것 같다.

서정민: 어느 웹퍼블리셔가 웹표준화를 적용하게 되면 시간이 많이 걸린다는 이유를 내고 싸움이 벌어져서 '웹퍼블리셔의 역할'에 대한 고민 해봤다.

신현석. 너무나 하위평균적인 생각인 것 같다.

서정민: 그것도 많이 큰 업체에서 그런 일이 벌어졌다.

신현석: 그런 사람들도 있는 것이겠죠.

듀트: 더 노력해야 할 것 같다.

혜윰: 저는 디자이너입니다. 레이아웃에는 헤더와 풋터, 컨텐츠와 사이드 등으로 이루어져 있는데 마크업시 컨텐츠 영역이 먼저인가 메뉴가 먼저인가에 대해서 이야기해 보고 싶다. 글로벌 프로젝트를 진행중인데 벤치마킹을 하다보니 외국의 사이트들 중에 컨텐츠 영역이 메뉴보다 먼저 마크업되는 경우가 많은 것 같다. (우리와는 다른 모습인데) 컨텐츠를 먼저 마크업하는 것이 좋은 것인가? 일전에도 비슷한 토론이 있었는데 우리의 경우에는 기본적으로 메뉴를 먼저 마크업하는 경우가 많고, 한 분 정도만이 컨텐츠를 먼저 마크업한다고 했다.

서정민: 예전에 CDK에서도 한번 논의가 되었던 것인데 결론은 “스킵 네비게이션을 넣자”였다. 장애인들이 컨텐츠를 접근하기 위해서 메뉴를 여러번 접근하게 되는 문제가 있어 스킵 버튼을 제공해서 해결하는 것으로 결론이 났던 것으로 안다. 컨텐츠를 먼저 마크업하고 css를 이용해서 위치를 잡아주는 작업이 상당히 힘든 작업이다. 그 작업을 하느리 차라리 스킵 버튼을 만들어 주는 것이 훨씬 효과적이다. (http://forum.standardmag.org/viewtopic.php?id=1426 (참고)추가(#ID가 아닌 #name 으로도 접근가능)

신현석: 또 하나 생각해야 할 것이 왼쪽에서 오른쪽으로 글을 쓰는 언어의 사이트 같은 경우는 사람의 시선도 그대로 따라간다. 콘텐츠를 소스 코드 레벨에서도 사람의 시선이 움직이는 - 물론 시선은 어디 찍힐지 모른다고 얘기는 하지만 - 화면에서 보면 왼쪽 오른쪽, 위에서 아래 그 기준을 크게 벗어나지는 않는다. 선형화 했을 때 컨텐츠에 대한 이해도가 더 떨어질수도 있다. 사용자가 더 당황할 수 있다고 한다. 특히나 탭으로 컨텐츠를 이동하다 보면 위에 내용을 검색하고 당연히 왼쪽으로 가야 하는데 그렇게 되면 컨텐츠 영역으로 먼저 가고 오른쪽(메뉴)으로 가게 되거든요. 그렇게 되었을 때 문제가 될 수 있고. 그리고 결론이 내릴 수 있을 것 같지는 않은데 개인적인 의견은 왼쪽 오른쪽, 위 아래의 기준을 따르는 게 좋을 것 같다. 컨텐츠가 중요하다고 해서 앞으로 빼는 것은 페이지 전체의 구조를 흩트려뜨리는게 아닌가 한다. 흐름과 중요도를 복합적으로 고려해서 한다. 케이스별로 다를 수 밖에 없다. 단, 서브 섹션 메뉴 같은 경우는 컨텐츠보다 먼저 나와도 충분히 가능하지 않은가 싶다.

혜윰: 모두에게. 컨텐츠를 먼저 하시나요. 사이드 메뉴를 먼저 하시나요?

모두: 사이드 메뉴를 먼저 한다.

서정민: 나라(언어와 문화)에 맞춰서 해야 하지 않을까. 다이나믹드라이브(http://www.dynamicdrive.com/)에서 제공하고 있는 레이아웃 중 일부가 컨텐츠를 먼저 마크업하는 예를 볼 수 있었다. (확인했으나 일부 확인된 레이아웃에서는 메뉴가 먼저 나옴)

봄눈: 사이트 단위가 아니라 페이지 단위로 보았을 때 사용자가 인덱스나 메인이 아닌 해당 컨텐츠 페이지로 직접 접근했을 경우에는 메뉴보다 컨텐츠가 더 중요하게 판단될 수도 있지 않을까.

신현석: 상위 개념을 앞에 놓는다는 게 중요하지 않을까 합니다. 반대로 컨텐츠 외의 것들을 굳이 하단으로 내려버릴 근거도 뚜렷하게 없지 않은가. 컨텐츠를 앞으로 뺀 사이트는 css로 이런 것이 가능하다는 것을 보여주기 위해서 적용되었을 수도 있지 않을까 생각해본다.

봄눈: SPAN과 DIV요소는 스펙상 의미를 갖지 않는 요소인 것으로 알고 있다. 하지만 라운드박스 등 여러가지 비주얼을 위한 마크업시 사용되는 경우 불필요한 요소라는 관점에서 사용을 제한당하고 있다. 나 역시 기본적으로 마크업을 줄이는 것이 좋다라고 생각하지만, 조금은 이율배반적이지 않나 싶어서 특별한 기준이 없는 이 문제를 주제로 올렸다.

서정민: 둘다 디자인 요소지 않나.

신현석: 정확히는 스트럭처 요소(HTML, the Foundation of the Web, http://www.wpdfd.com/issues/86/html_the_foundation_of_the_web/)다. 스트럭쳐 요소 중 가장 큰 요소다. SPAN은 인라인 요소라서 멸시당하는 부분이 없지 않지만 DIV와 거의 동등한 역할을 한다.

봄눈: 한국적인 이슈일 수 있는데 국내 웹사이트의 디자인에는 라운드 박스와 같은 비쥬얼 요소들이 많고, 때문에 다양하게 라운드박스를 제작하는 방법들이 고안되었고, 자바스크립트와 DOM을 이용한 방법도 나와있다. 그러한 작업들이 방법에는 차이가 있을지 모르지만 결과적으로는 HTML 문서 안에 비주얼을 위한 빈 DIV를 여럿 포함하게 되는데, 상대적으로 마크업의 경량화 등 불필요하게 생각될 수 있는 DIV 요소의 최소 사용을 요구하기도 한다. 이 점이 다소 맞부딪히고 있지는 않은가 해서 올린 질문이다.

신현석: DIV나 SPAN이 추가되는 것이 항상 불필요한가? 필요한 상황인 경우에 넣어서 유의미하게(빈 DIV나 SPAN이 아닌) 만들 수도 있다고 본다. 근본적으로는 CSS 3가 나오면 해결된다고 본다. CSS 2.1의 스펙이 미완성인 점, 충분히 발전되지 못한 까닭이 크지 않을까 싶다.

서정민: 컨텐츠를 전체를 감싸는 라운드는 헤딩의 BG로 처리해서 가능한 불필요한 DIV는 만들필요가 없다.

신현석: 물론이다. 뺄 수 있는 건 최대한 뺄 수 있는데, 좌우까지 고려하면 들어갈 수밖에 없다. 개인적으로는 넣어도 된다고 본다. 실제로도 넣기도 한다. 그렇다고 해서 그것을 자바스크립트로 생성해서 만들어 넣는 것도 불필요하다고 본다.

봄눈: 일부 사이트에서 DOM과 자바스크립트를 이용해서 라운드박스를 처리하는 기술을 선보이 적도 있고, 그러한 기술이 여기저기서 사용되기도 했던 것 같다.

듀트: DOM을 스타일을 입히기 위해서 많이 하는 것 같다. 그런데 그것도 어차피 똑같다. 소스보기에서 보이느냐 안 보이느냐의 차이지 결과 자체는 같다. 결국 사용자 입장에서는 같은 것일 수 밖에 없다. DOM을 위해 렌더링을 돌리느니 처음부터 태그를 추가해서 처리해 주는 것이 더 나을 수도 있다. 같은 요소를 여러 번 사용하는 업무의 효율을 위해서라면 모르겠지만 그것이 아니라면 도를 넘지는 않는 것이 좋다. 적절한 선에서 타협하는 것이 중요하다고 생각한다. 공부를 할 때는 굉장히 열심히 하고 작업을 할 때는 냉정하게 하는 것이 중요한 것 같다.

신현석: 어플리케이션 UI를 디자인하는 것을 보면 이런 고민을 안 한다. 이미 제공되고 있기 때문에. 제 생각에는 CSS 가 불완전하기 때문에 어쩔 수 없다고 보는 것이 맞는 것 같다. 그렇다고 자바스크립트를 이용하는 것도 개인적인 성취감은 있겠지만 실제로는 큰 도움은 되지 못할 것 같다.

hwzzang: 메일링을 올바르게 마크업하는 방법, 메일링을 코딩 할 때 테이블로 안 하면 제대로 보이지 않는 경우가 많아서 질문을 올렸다.

듀트: 고민을 해봐야 하는 문제죠. 메일을 보낼때 HTML 마크업을 사용해야 하는가?

서정민: 파란쪽에서는 DIV를 풀어 준다는 이야기가 있다.

호브레드: 메일의 헤더 정보를 메일 서비스회사가 가지고 있기 때문에 제작자의 DTD나 마크업이 제대로 지원되지 않는 것으로 알고 있다.

서정민: 각 메일 서비스 회사마다 지원하는 CSS를 정리해서 올려놓은 블로그들이 있다. 야후 등 일부 서비스에서는 공통적으로 포지션과 플롯은 지원되지 않는 것 같다. (메일관련 : http://www.campaignmonitor.com/blog/archives/2006/03/a_guide_to_css_support_in_emai.html (국외)

봄눈: 온라인 광고 대행사에서 근무를 하다보니 뉴스레터와 이벤트 페이지 등을 많이 작업하게 된다. 실무적으로 뉴스레터는 신속하게 제작되고 발송되는 경우가 많아서 표준 마크업과 CSS를 제대로 테스트하고 제작하는 것이 쉽지 않다. 또한, 여러 웹메일 서비스나 어플리케이션 프로그램들이 서로 허용하는 HTML고 CSS 속성이 다르기 때문에 효율적이지 못한 경우가 많다. 아쉽지만 이미지를 슬라이스 한 후 alt 속성에 대체 텍스트를 충실히 넣어주는 것이 가장 좋은것 같다.

신현석: 메일의 가장 큰 문제가 웹사이트 만들 땐 브라우저 4개만 테스트해보면 되는데 메일은 메일서비스 사이트 수 만큼 확인해 봐야하고, 유저에이젼트 수 만큼 확인해 봐야 한다는 게 어렵다. (호브레드님이) 말씀하신 것과 같이 헤더 정보를 (메일서비스 회사에서) 빼는 곳도 있고, 빼지 않는 곳도 있다. 사용가능 한 요소들만 추려야 하는 문제가 있다. 저 같은 경우는 포지션 속성만 빼면 왠만해서는 되었던 것 같다.

루미렌트: 아웃룩2007은 백그라운드가 지원되지 않는다. 인라인 스타일로 지정해도 안되고, 태그 속성으로 지정해도 되지 않는다. 아예 지원되지 않는 것 같다. 옵션의 문제도 아니다. 디폴트 설정인 상태에서 그렇다.

듀트: MSDN 검색 결과(http://msdn.microsoft.com/en-us/library/aa338201.aspx) 아웃룩 2007에서는 백그라운드를 지원하지 않는다.

호브레드: 포지션, 플롯 제외하고 테이블로 코딩을 하는가?

루미렌트: 테이블로 화면을 조각내서 작업을 한다.

신현석: 테이블로 하더라도 배경색이 전경색이 적용될 경우 문제가 되지 않은가?

루미렌트: 이미지를 최대한 슬라이스해서 작업을 해야 한다.

신현석: 포토샵에서 슬라이스해서 익스포트하면 끝이겠다. 가장 좋은건 그거 같아요. 제 경우에도 이미지를 가로로만 슬라이스 해서 대체텍스트를 넣어주는 방법을 사용한다.

루미렌트: 웹 최적화를 위한 퍼포먼스 요소와 모바일웹의 이슈에 대해 의견 나누고 싶다. 첫번째로 모바일웹에 대한 이슈가 많은데 테스트하는 환경이 있는지 어떻게 할 수 있는지 알고 싶다.

신현석: 일단은 테스트 필요성을 느끼지 못한다. 브라우저가 하나(OZ)밖에 없고, 인프라웨어 것이 좋다. 현시점에서 모바일웹에서 문제가 생긴다고 문제제기를 할 사람이 없다. 사용할 수 있는 사이트가 별로 없다.

루미렌트: 앞으로는 문제가 되지 않겠나

신현석: 그것을 고민하기보다는 브라우저나 모바일UI가 더 빨리 발전할 것이다. 다시 말해 모바일이라는 것을 별도로 고민할 필요가 없게 될 것이다. 사파리의 경우도 PC용 사파리와 크게 다르지 않기 때문에 따로 떼어놓고 고민할 필요는 없을 것 같다. 모바일OK(http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/)에서 전송속도까지 체크하고 있기는 하지만 앞으로는 무의미해질 것이다. 모바일웹에서 사용되는 엔진이 오페라와 웹킷, 표준을 잘 준수하는 인프라웨어 정도뿐이다. 일단 풀브라우징이 지원된다면 일반 웹과 모바일 웹을 따로 떼어놓고 고민할 필요가 없을 것 같다. 기술의 발전이 더 빠를 것으로 기대한다. 또한, 표준을 잘 준수한다면 모바일 웹에서도 잘 표현되리라 생각한다.

듀트: 예전에는 오히려 CSS의 핸드핼드 스타일 속성에 대한 고민들을 많이 했다. 기술이 발전하면서 그런 이야기들도 많이 들어갔다.

신현석: 일부에서 핸드핼드 스타일에 대한 논의를 하고 있는데 큰 의미는 없지 않은가 싶다. 핸드핼드는 가장 구현이 되지 않은 스타일 속성인데 표준 구현이 되지 않는다면 어차피 필요가 없지 않은가 한다.

루미렌트: 모바일 웹을 원활하게 사용하기 위한 UI적인 요소에는 어떠한 것들이 있을까?

신현석: 고민을 해보지 않은 부분이다. 모바일에서 자동로그인과 같이 유용한 UI를 말하는 것인가?

듀트: 복사와 붙여넣기가 되었으면 좋겠다.

신현석: 복사를 모바일웹에서 지원할 수 있을까.

서정민: 자바스크립트에서 키 값을 가지고 해결해볼 수 있지 않을까 싶다

신현석: 일단 onStartDrag 이벤트가 되지 않는다. 그 이벤트를 발생시킬 수 있는 것이 없는 것 같다.

루미렌트: 퍼포먼스 측정과 관련해서 YSlow(http://developer.yahoo.com/yslow/)와 Fiddler(http://www.fiddlertool.com/fiddler/)를 사용중인데, 어떠한 기준으로 최적화 작업을 해야 할까?

신현석: 기준은 없는 것 같다.

서정민: 노하우가 있을 것 같다. 경험적으로 쌓인 노하우를 통한 자기만의 기준을 잡는 것이 좋을것 같다.

신현석: 모바일 쪽은 있다. 웹사이트의 속도개선을 위한 기준이 있고, 체크를 하고 있는 것으로 알고 있다. 일반 웹에서는 줄일 수 있을때까지 줄일는 것이 방법일 것이고, 특별한 기준은 갖기가 힘들 것 같다.

듀트: 작년의 넥슨닷컴(http://www.nexon.com/)의 경우 경쟁사와의 비교를 통해서 최적화 작업을 진행하는 경우가 많았다. 이미지를 합쳐서 작업하는 것이나 http call을 줄이는 등의 방법을 사용한다. 서정민씨 말씀처럼 자기만의 노하우를 가져가면서 최적화를 진행해볼 수 있을것 같다. 그것이 회사의 표준이 될 수도 있을 것이다.

루미렌트: 예를 들만한 사이트가 있나?

듀트: 구글이 좋은 예다. 구글의 메인에 컨텐츠가 없어서가 아니다. 최근에 이미지 아이콘이 추가되었는데 하나의 이미지로 작업이 되었는데 최적화를 위한 것이었고, 구글의 경우 확실한 효과를 볼 수 있는 것이었다. 좋은 예가 된다. 하지만 대부분의 경우 줄여서 얻을 수 있는 것보다 인력과 비용등의 문제를 고려해 봐야 할 것 같다.

신현석: 구글은 그러한 최적화 작업의 효과가 있는 것이다. 하지만 일반적인 웹사이트에서는 큰 의미를 갖기는 어렵지 않을까 싶다.

루미렌트: YSlow나 Fiddler는 사용하는가?

신현석: 둘 다 사용해보지 않았다.

듀트: Fiddler는 써봤다. Fiddler는 스니핑 기법을 이용한 것으로 문제가 있을 수 있다. 모든 HTTP를 걸러서 체크한다. AJAX 통신이 제대로 되지 않는 경우가 생긴다. 사이트의 속도측정보다는 오류체크나 컨텐츠타입을 확인하기 위한 툴인 것 같다.

루미렌트: YSlow에서 제시한 방법들은 웹서버의 환경을 설정하는 부분이 비중이 더 크다. 웹퍼블리셔 입장에서 그러한 체크를 어디까지 해야한다고 보는지 알고 싶다.

신현석: 하면 좋다. 자신의 몸 값을 올리는 방법이 될 수도 있다. 하지만 보통은 업무롤이 명확하게 나누어져 있기 때문에 하기가 어렵다. 그 영역은 서버 엔지니어의 영역인 것 같다. gzip이나 CDN까지 작업을 해야 한다면 웹퍼블리셔가 서버 엔지니어의 역할까지 하게 되는 것이라고 본다.

봄눈: YSlow를 사용하고 있지만 단순히 확인해보는 정도의 목적이지, 실제로 최적화를 위해서 사용하기는 어려운 것 같다. 체크 항목 자체가 서버측에서 처리해야 하는 것들이 많기 때문에 웹퍼블리셔 입장에서 할 수 있는 것들은 아니라고 본다.

신현석: Firebug의 Net 기능 정도만을 활용해도 (웹퍼블리셔 입장에서) 최적화를 위한 역할을 해볼 수 있다고 생각한다.

듀트: 다 알 필요는 없을 것이다. 하지만 놓치는 말자. 계속해서 인지는 하는 것이 좋다. 작업을 실제로 하고는 있지는 않지만 지식을 유지한다면, 관계자들과 소통할 수 있는 무기가 될 수 있다.

호브레드: 테이블을 대체하는 태그로 loop를 돌렸을 경우 각 브라우져 별로 생기는 문제점과 대처방법에 대해 이야기를 나누어 보고 싶다. (UL 요소로 리스트를 만들었을 때 목록이 두줄 이상으로 되고, 각각의 LI 요소의 높이가 달라질 때 어떻게 처리를 해야 하는가?)

서정민: 글자수가 픽스되어서 나와야 하지 않은가?

호브레드: 클라이언트가 글자의 제한을 두지 않는다.

신현석: 스크립트로 처리할 수 있기는 하지만 문제점이 있다. 줄을 자동으로 맞춰주는 기능이다. 하지만 테이블로 작업을 하는 것이 보다 효율적이다. 스크립트는 계속해서 돌린다면 퍼포먼스 저하의 문제를 가질 수 있다. 테이블을 레이아웃으로 사용하는 것이 개인적으로는 어느정도 까지는 문제가 없다고 생각한다. 테이블 레이아웃을 사용한다고 해서 웹사이트의 퀄리티가 심각하게 떨어지는 것도 아니고, 사용하는 것 자체에 대해서 부정적으로 볼 필요는 없을 것 같다.

호브레드: 좌우측에 버튼이나 탭과 같은 컨텐츠 요소가 있고, 우측으로 플롯트된 요소를 가변적으로 처리하는 방법이 무엇인가?

신현석: UL 요소를 우측 플롯을 하고, LI요소를 좌측 플롯을 주면 해결할 수 있을 것 같다.