deutism

제가 Opera software를 다니면서 생활에 가장 큰 변화가 생긴것은 주 브라우저가 Opera로 바뀌 었다는겁니다. 사실 Opera software를 다니면서 사용하게 된것도 크지만, 때마침 주로 사용하던 Firefox가 좀 무거워진 느낌을 받았기 때문입니다.(그냥 개인적인 생각입니다.^^; 민감하게 반응하지 마시길; )

그런데 쓰다보니 Opera Desktop Browser에는 좋은 기능들이 꽤 있는것 같더라구요. 그중에서 제가 제일 잘쓰는 기술은 검색엔진 만들기 입니다.
주소창에 예약어 + 검색할 string 이렇게 쓰는것이죠. 예를들어 구글에서 “deute”를 검색하고 싶다면 주소창에 “g deute” 라고 입력하면 그냥 구글에서 검색이 되는것입니다.

다음과 같이 구글 검색 결과 페이지로 이동이 되며 제가 입력한 deute로 검색이 되는것을 알수있습니다.

Opera Desktop Browser 10.10을 설치하면 다음과 같은 예약어가 기본적으로 구성되어 있습니다.(google, ask, yahoo!, amazon.com, Wikipedia, Ebay.com, Shopping, 방문목록에서 검색, 페이지에서 찾기)

그러나 사실 저중에 제가 쓰는건 google이랑 Wikipedia 정도밖에 없는데요. 우리나라 실정에 안맞기는 합니다. 그래서 저는 몇가지 예약어를 추가를 하지요. 그 방법에 대해서 알아봅시다.

먼저 네이버 통합검색을 “n”을 예약어로 지정하여 추가를 해봅시다.

1. 일단 네이버 메인 페이지로갑니다.
2. 그리고 검색 input에 마우스 오른쪽 클릭을 합니다.
3. 메뉴에서 검색엔진 만들기를 누릅니다.
   
4. 예약어를 설정합니다.
   

이렇게 하면 주소창을이용해서 간편하게 네이버를 검색할수있습니다. 다음도 같은 방법으로 이용 할 수 있겠죠. 그래서 제가 주로 쓰는 검색들을 하나하나 다추가 해놓으면 정말 편리 하지요. 제가 추가해둔 검색들은 다음과 같습니다.

• 네이버 통합검색 (예약어:n)
• 다음 통합검색 (예약어:d)
• CDK forum 검색어검색 (예약어:sm)
• CDK forum 유저검색 (예약어:smp)
• 구글 언어도구 영어에서 한국어로 (예약어:tre)
• 구글 언어도구 한국어에서 영어로 (예약어:trk)
• 기타 회사에서 사용하는 인트라넷등등등

이 정도면 편하게 검색이 가능해 지더라구요. 물론 옆의 검색탭에도 모두 추가가 됩니다.

또 한가지 특징은 검색 당시의 각종 옵션도같이 지정이 가능하다는겁니다. 예를 들어 저는 구글 번역을 많이 쓰는데요. 영어에서 한국어로 한국어에서 영어로 해볼때가 많은데 이것을 하단의 옵션만 변경해서 따로 저장하면 tre,trk 처럼 구분해서 사용을 할 수 있게 됩니다.

검색어를 만들어주는 방식은 form을 input 과 submit 이 있으면 가능한데요… 제가 즐겨쓰는 다음의 영어사전은 검색 엔진을 만들수 없더라구요.. 그래서 분석을 해봤더니. form에 action이 없어서 검색 쿼리를 보낼수 없게 되어 있었습니다. form 태그는 action 속성을 필수적으로 구성해야 합니다. 그런 지침이 있기 때문에 각종 어플리케이션을 만들때는 값이 적절함을 가정하고 기능을 만드는것이겠죠.
암튼 얘기로 돌아와서 물론 수동으로 쿼리를 만들면 검색엔진을 만들수 있습니다만 쉬운방법은아니죠.

웹 페이지를 만들때 이 페이지가  어떤 환경에서 사용 될지 모든 환경을 미리 알수는 없습니다. 그렇기 때문에 웹 표준을 준수하고 웹 접근성을 준수해서 웹 페이지를 만드는것이 그만큼 중요합니다.  이에 대한 얘기는 웹 접근성 지침에도 물론 있습니다.

암튼 다음 영어사전 만드시는분들 수정좀 해주세요 >_<

검색 용도로의 오페라 좀 쓸만하죠? 다들 오페라로 즐거운 검색생활 하시길 바랄께요 잇힝

제가 요즘 여러사이트를 둘러볼 일이 많은편인데요. 둘러보니 그동안 많은 웹사이트가 웹2.0이다 Ajax 다해서 많은 발전을 하고 있는것같아요. 많은 클라이언트 기반 웹 기술들이 사용자를 위한 발전을하고 있고 실제로 많은 사이트들이 사용성 이나 편의성이 많이 좋아진것같아제가 요즘 여러사이트를 둘러볼 일이 많은편인데요. 둘러보니 그동안 많은 웹사이트가 웹2.0이다 Ajax 다해서 많은 발전을 하고 있는것같아요. 많은 클라이언트 기반 웹 기술들이 사용자를 위한 발전을하고 있고 실제로 많은 사이트들이 사용성 이나 편의성이 많이 좋아진것같아

하지만 기술의 발전에 비해 내용의 발전은 아직 많지 않은것 같아요. 꼭 필요할 것 같지 않은 요소들이 남발이 된다던가 그냥 고민 없이 해오던대로 페이지를 구성한다던가 하는일들이 무식한 제가 보기에는 많이보이는것 같아서요 혹시 이글을 보시고 현답을 주실분이 있다면 좋을것 같네요.

각종 사이트를 원할하게 사용하려면 거의 대부분이 회원 가입을 하고 로그인을 한뒤 사이트를 이용하게 되는데 회원가입 하는게 쉬운일이 아니죠. 보통 회원가입시 받는 정보들을 살펴보면 이름, 주민등록번호, 닉네임, 아이디, 주소, 전화번호, 휴대전화번호 등등 완전 호구 조사가 따로 없어요. 주민등록번호 입력은 그중 제일 이해 안가지만 뭐 다들 고집을 하니 넘어가도록 하고 그다음으로 이해안가는 항목이 하나 있다면, 주소를 입력받는건데요. 이 정보가 왜필요한지모르겠어요 쇼핑몰 같은경우 주소가 필요 할수도 있겠지만, 다른 경우에는 별로 안필요할것 같은데요 경품을 줄때이용 할수도 있을거라 생각해봐도 보통 경품 보내줄때는 주소 정보를 수동으로 관리하고 수집하더라구요 입력하는 사람도 정말 귀찮은 일이 아닐수없는데요. 게다가 대부분 우편번호까지 입력해야하니 정말 귀찮아요. 이용할때도 없고 입력하기도 귀찮은 이 항목이 왜 회원가입 항목에 있는질 모르겠어요.

대부분 위와 같이 입력해 보신적 없나요?

또 하나 걸고 넘어져 보면, 대부분 회원가입시에 메일주소를 입력받는데요. 많은 사이트들이 많이 사용되는 메일의 도메인을 미리 리스트업해놓고 그중에 선택하던가 직접 입력하던가 할수 있게 하는데요. 돌려 쓰는건지 퍼와서 사용하는건지는 모르겠으나 도메인이 상당히 오래되어서 서비스 되지않는 도메인이 있는경우도 보이더라구요. 개인적인 생각 으로는 그냥 메엘주소를 도메인 포함해서 입력하는게 더 편하다고 생각 하는데 이건 뭐 개인차가 있을것 같네요.

회원 가입시에 저같으면 정말 최소의 정보만 받을것 같은데 사이트마다 나름의 이유가 있겠죠?

제가 초천재님과 아이폰을 사러 대리점에 갔을때 개인정보를 여기저기 뿌리는것에 동의 하라고 안하면 아이폰을 가입할수 없다고 하던 고속터미널의 모 대리점이 생각이 나는데요 설마 사이트도 그런건 아니겠죠?

웹 바닥에서 굴러 먹은게 9년이나 되었지만, 실제로 웹 사이트를 만드는 일은 얼마 하지 않았기 때문에, 어느 분야던지 프로훼쇼날 하지 않다고 개인적으로 생각하고 있는데요.

그냥 살다보니 슈퍼 울트라 초 특급 경력 개발자, 퍼블리셔분들도 실수를 조금씩 하시는것 같아 때때로 마음이 아픕니다. 그래서 많은 선배님, 스승님 등등 분들께 몇 가지 부탁을 드립니다.

HTML 태그를 쓰실때는 좀 닫아주세요… “너네들이 내가 실수했는지 얼마만에 알아 채는지 볼라고 그런거야” 이런 말씀 하지 마시고 HTML 태그는 잘 열고 잘 닫아주세요. 인생은 뒷처리가 중요한거랍니다. 똥 싸러가서 다싸고 뒤처리 안하면 좀 드러워져요.

HTML 4.01에서는 일부 태그는 안닫아도 된다고 하시는 분들 정확한 DTD 를 사용하시던가 그래도 그냥 닫아주시면 마음이 편안해요.. 역시 똥싸고 뒷 처리가 중요 하니까요..

또 태그 닫는 순서 좀 지켜주세요. 똥쌀때 바지벗고 팬티 내려 싼 다음 바지입고 팬티 입는거아니잖아요.. 상식적인건데 왜들 그러세요.. 바지입고 비데하는거 아니잖아요… 좀 순서를 지켜주세요~ 어렵지않구요. 해치지 않아요.~

즐거운 배변하시고, 즐거운 마크업생활하세요~

역시나 웹 표준 지인들과 술을 먹다가 CSS Zengarden에 대한 얘기가 나왔고, 우리도 이런게 있으면 좋겠다고 얘기했었어요.

그 담날부터 바로 만들기 시작했는데  3년이 지나고 나서야 그나마 좀 볼 수 있는 상태가 되었네요. 그 간에 만드는 도중에 황송하게도 일몰님이 디자인을 주시기도 하셨고, 여러분들이 격려를 해주시기도 했습니다.원래 기획시에 CSS Quiz도 하려는 계획이 있었는데 이건 이미 정찬명님께서  진행하고 계시네요:)

CSS 놀이터는 기본적으로는 CSS의 위대함을 알리는것이 목적입니다. 세상은 계속 창조적인 디자인이 나오고 있습니다. 웹 표준이 창조적인 디자인과 잘 어울린다는것을 알리는데 조금이나마 도움이 되었으면 하는 바램입니다.

또한 많은 디자이너가  웹 표준을 어려워 하는데, 디자인을 해보면서 또한 CSS를 다뤄보면서 CSS와 친숙해지는 진정한 웹 디자이너가 되는데 도움이 되는 계기가 되었으면 하는 바램도 있습니다.

공개된지 얼마 되지않았는데 벌써 4분이 자신의 창작물을 제출해 주셨습니다. 하나하나 고민을 거듭한 CSS 코드가 돋보이는 작품입니다. 조만간 작은 이벤트를 진행해볼까 합니다.

많은 분이 CSS 의 위대함과 즐거움을 CSS 놀이터에서 느끼실 수 있으면 좋겠습니다. 좋은서비스가 되도록 저도 노력하겠습니다.

CSS 놀이터는 Css Design korea의 서비스로 귀속 하겠습니다.(운영자맘 캬캬캬)

글을 세달이나 넘게 안쓰다보니 글을 쓰기도 두려워 집니다.

요즘 신종플루가 유행이라던데.. 저는 감기에 걸려서 고생중입니다. 체온이 그리 높지 않은걸로 보아 별일은 없는것 같습니다. 환절기다보니 여기저기 감기 소식이 들려오는데 다들 감기조심하세요…
참 저는 4년 반 동안 다니던 넥슨을 그만두고 회사를 옮겼습니다. 아시는분들도 꽤있습니다만 제가 다니게된 회사는 Opera Software ASA라는 회사입니다. 저는 신현석님과 함께 QA Engineer로 일하게 되었습니다.
이 회사는 제가 너무나도 가고 싶었던 회사였고, 또한 마음이 잘맞는 사람과 일을 하고 싶다는 생각을 계속 해왔는데 이번에 좋은 기회가 와서 덥썩 물었습니다. 예상대로 참 훌륭한 마인드를 가진 회사라는것과 구성원들이 하나같이 배울점이 정말 많다는 생각이 드는 회사였습니다. 넥슨에서도 참 배울점이 많았었는데 저는 직장운이 참 좋은것 같아요.

Opera는 노르웨이에 본사가 있는 회사인데요. 웹 표준이 너무나도 당연시 되는 그런 회사입니다. 구성원 모두가 opera에 대한 자긍심이 크고 꿈이 느껴지는 그런 회사였습니다.
저도 회사 수준에 맞는 능력을 빨리 갖춰야 할텐데 말이죠. 큰일입니다. 일에 대한 실력말고도 언어의 장벽이 크게 느껴집니다. 회사 자체가 글로벌 기업이다 보니 당연히 모두들 영어로 대부분의 일을 처리하더라구요. 그 덕분에 영어 공부 안한 저를 한스럽게 하더군요. 늙어서 영어공부 하려니 이만저만 힘든게 아니네요.(영어공부하는데 초천재님이 많은 도움을 주고 있는데 정말 고맙더라구요.)

제 자신의 이런 저런일 때문에 해야하는 커뮤니티 활동을 잘못하고 있는데요. 웹 표준 경진대회도 얼릉해야 할텐데 말이죠. 제 능력이 미천해서 진행하기가 쉬운게 아니네요.. 도움 주실분 있으면 언제든지 환영합니다. 저 또한 열심히 하겠습니다.

아 그리고 한국형 CSS Zengarden을 표방한 CSS Playground도 오픈이 되었습니다. 여러가지 마무리지어야 할일이 많이 있지만, 사용하는데는 무리가없습니다. 조만간 이벤트도 할 예정이니 많은 관심 가져주세요.

요즘 대부분의 게시판이나 블로그툴에는 HTML에디터라고 불리우는 Online Rich Text Editor(이하 RTE) 가 사용되고 있지요.
우연히 허접한 실력으로 만들 기회가 생겨 회사 게시판에 사용되는 에디터를 만들게 되었고 만들면서 느낀점들을 한 두개 정도 공유하려 합니다. 에디터를 만들어 보신분이라면 볼필요도 없는 내용이 될것이고, 저처럼 온갖 삽질을 하던사람에게는 조금 도움이 되지 않을까 생각해 봅니다.

일단 작업을 시작했을때 생각보다 자료가 별로가 없었고, 그 마저도 크로스 브라우징 논의 자체가 없었습니다. 그와중에도 이미 Xquared나 Smart Editor 같은 훌륭한 에디터가 나와 있었으나, 소스가 너무 어려웠어요 =_=;;;;

• openmaru의 Xquared 는 깔끔한 코드를 산출해준다는 장점이 있었습니다. 기존의 에디터는 대부분 HTML4.01를 기준으로 태그를 생성해 주거든요. 그런데 Xquared의 경우는 상당히 깔끔한 XHTML 1.0 베이스의 코드를 만들어주는데 그 장점이 있었습니다. 별것 아닌것처럼 보일지 모르겠지만 저는 아직 그 방법을 완벽히 찾지는 못했거든요. 그외에도 여러 좋은 기술들이 있지만 일단 그 당시 생각한건 저정도…;
• NHN의 Smart Editor는 지도나 책 같은 다양한 부가 기능 지원과 레이아웃 지원등 최고의 서비스 회사답게 에디터에 많은 서비스를 담아내었습니다.
• 외산 에디터도 많습니다만 뭐 FCK Editor가 제일 좋다는 얘기만 들었는데 저는 정이 안가더라구요..(English………….)

첫번째 제 목표는 크로스 브라우징이 었습니다. 마침 4대 브라우저에서(IE5.5, Opera 9.5, Firefox 2+ and Safari 3) 모두 에디터를 만들 수 있다는 소식을 들었거든요.
firefox 에서는 midas라는 코드네임을 가진 프로젝트의 형태로서 지원을 했습니다. 저는 데모화면을 보면서 희망을 가지기 시작했어요.

이제 에디터가 무엇이라는것은 알았으니 맨땅에 헤딩만 하면되겠죠? 자 이제 삽질 시작됩니다.
제가 좀 찾아보니 에디터는 자바스크립트를 이용하여 페이지의 designmode 라는 속성으로 출발을 하게 됩니다.
쉽게 말해서  문서를 직접 디자인 할수있게 만들어 주는 속성이 랄까요? designmode는 HTML의 속성은 아닙니다. 표준속성도 아닐거구요. 그래서 스크립트로 접근을 해주어야 합니다.
iframe을 designmode 로 변경을 해줌으로써 iframe내의 문서를 편집 할 수 있게 되는거죠. 자바스크립트를 잘 모르시는분들도 차근차근 따라하면 쉬울것이라 생각되는데요?
만약에 iframe의 id속성 값이 “editWindow” 라고 한다면, 일단 iframe에 접근을 해야하니 제일많이 보는 getElementById()를 이용하는게 속편하겠죠?

document.getElementById(“editWindow”) //iframe으로 접근!

iframe 안에 우리는 글을 쓸것이니 프레임내의 document 부분으로 접근을해야겠죠? iframe내의 document는 접근하는방법이 약간다릅니다. 아래의 코드가 정답이라고 보시면됩니다.

document.getElementById(“editWindow”).contentWindow.document.designMode = “on”;

로 지정을 해주면 해당 iframe은 수정 할 수 있는 iframe, 즉 에디터가 됩니다. 쉽죠? 에디터가 이렇게 완성되었습니다. =_=/
참고로 풀소스를 한번볼까요?

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”    “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html>
<head>
<title>에디터 만들기</title>
<style type=”text/css”>
iframe { width:500px;height:400px; }
</style>
</head>
<body>
<iframe id=”editWindow”></iframe>
<script type=”text/javascript”>
document.getElementById(“editWindow”).contentWindow.document.designMode = “on”;
</script>
</body>
</html>

아 진짜 간단합니다.

참고로 contentWindow는 frame이나 iframe의 window를 나타나는 개체입니다. IE의 경우에는 생략이 되어도 상관없지만 기타 브라우저에서는 꼭 필요한 속성 입니다. 이걸 몰라서 에디터는 IE만 된다고 하는사람도 있었을 정도니까요:)

이제 에디터 영역은 만들었으니 각종 스타일이나 이런것을 넣을수 있어야 겠죠?
그건 다음시간으로 넘어갑시다~ 캬캬캬캬캬캬캬캬

참고로 이글은 에디터를 만드는데만 포커스가 맞춰져있습니다. 에디터에 대한 즐거운 생각, 더나은 에디터의 컨셉 등은 다음글을 보시는게 도움이 될듯합니다.

1. [2008년 3월 13일] 웹 에디터, 어떻게 만들어야 할까 III
2. [2007년 9월 20일] 웹 에디터, 어떻게 만들어야 할까 II
3. [2007년 8월 22일] 웹 에디터, 어떻게 만들어야 할까 I

맘에 들지 않지만 회사에서는 asp.net 을 사용 하고 있습니다. asp.net이 무슨 죄겠습니까만 제가 싫어 하는 것중의 하나가
모든 컨텐츠를 form 태그 하나로 감싸고 그안에서  모든 액션을 취한다는것이죠…
그래서 소스는 지저분해지고 script의 양만 늘어납니다. 적절한곳에 적절한 태그를 사용했으면 좋겠는데 말이에요.

엄청난 글자의 빨간부분이 데이터를 담는 부분이래요=_=;;;

암튼 그런데 띵가띵가 회사에서 미투하는 도중에 메일 한통이 날아 왔는데,
운영쪽에서 웹에서 하는 게임실행이 안된다는 리포트가 왔다는거에요…
그래서 메일을 잽싸게 봤더니 스크립트 오류가 나는거네요?

오류화면

여러가지 test를 해본 결과 flash에서 사용되는 자바스크립트 호출하는 함수인 “ExternalInterface” 가 문제 인것을 찾았습니다.
Form 태그내에서 Flash를 사용하며 그 Flash에서 ExternalInterface를 호출하면 DOM 에서 플래시를 찾지못해 스크립트가 에러가 나더라구요.
form 태그안에 왜 플래시가 들어가는지는 아까도 설명드렸죠;;

물론 Flash Player의 모든 버전에서 나는 문제는 아니고 특정 버전인 8~9초반 사이에서 나는 문제였습니다. 또한  IE에서만 발생하는 문제구요.(IE 버전과는 상관없습니다.)

해결방법은 두가지가 있습니다.

한가지는 Flash Player의 버전업을 유도합니다
보통 IE에서의 플래시 사용방법을 보면 object태그에 codebase로 Flash Player의 버전을 명시하게 되어있습니다.

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" width="980" height="216" id="MainNavFla">

저 부분을 변경해 주는거죠. 지금은 8.0이니 뭐 9.0이나 10.0으로 변경하면되겠죠?

또 한가지 방법은 플래시 오브젝트를 window의 객체에 바로 연결해주면 된다 하는군요.. (코멘트에 있습니다. jwatkins님의 코멘트)
요즘 대부분 플래시를 자바 스크립트로 활성화하니 활성화 코드뒤에

window.플래시오브젝트ID = document.getElementById("플래시오브젝트ID ");

같은 방법으로 해결을 할 수 있다고 합니다. (저는 이방법으로 해결을 했습니다.)
위의 코드로 보면 이렇게 되겠지요…

window.MainNavFla = document.getElementById("MainNavFla");

또한 ExternalInterface는 Opera 브라우저에서는 아직도 사용 할 수 없더라구요. 아예 플래시가 보이질 않아요..

저번에도 말했었지만 플래시가 가지는 웹상에서의 영향력 만큼이나, 신중하게 그리고 에러가 없게 플래시 플레이어를 배포했으면 하는 바램이 있어요..

일을 하다보면 푸터 부분을 항상 브라우저의 최 하단에 고정 시켜 달라는 디자이너의 요청이 있을때가 있죠?
예전에는 그냥그러려니 하면서 작업을 하고는 했는데 다시 생각해보니 이게 왜 꼭 붙어 있어야 하나 라는 생각이 들더라구요..

“네놈이 디자인에 대해서 뭘 아냐; 다 디자인적인 이유가 있는거다!” 라고 말하면 뭐 사실 할만은 없지만 말이죠..

이런 생각이 들더라구요.. 푸터를 항상 하단에 붙이는 건 화면의 크기가 그렇게 크지 않아서 컨텐츠의 크기가 작을때도 실제 표현되는 푸터의 위치가 크게 다르지 않았기 때문에,
통일성을 주려다보니 일부러 푸터를 하단에 붙인게 아니었을까? 하는 생각이 드는데요..어짜피 몇 픽셀 차이 나지 않을꺼 하단에 붙여 통일성을 주자라는 느낌을 가질 수 있도록 말이죠.

요즘은 모니터가 사이즈가 많이 높아져서 전체 height가 많이 길어졌기 때문에 푸터를 하단에 붙인다면 컨텐츠와의 간격이 너무벌어져서 오히려 디자인의 동질성도 떨어지고 알아보기도 힘들것 같아요.

푸터가 이렇게 하단에 붙는게 좋은건 아니겠죠?(LG를 욕하는건 절대아닙니다)

다시 잘 살펴보니 요즘은 푸터를 하단에 붙이는 사이트가 그렇게 많지는 않군요 =_=; 사이트 예를 들려다보니  잘 안보입니다.
제가 모르는 “푸터를 브라우저 하단에 붙이는 이유” 어떤것들이 있을까요?

언제나 그렇듯이 보통때는 남의 말에 신경을 잘안쓰다가도 내가 관심있는 부분에는 신경이 쓰이기 마련입니다.
요즘 웹 사이트 최적화에 신경을 많이 쓰고 있어서는 그런지 몰라도 최적화에 관련된 업무메일이나 등등이 많이 나오곤 하는데요…

CSS layout이 어느정도 보편화가 되어서 그런걸까요?  어떤 사람들로 부터 테이블 태그를 이용하면 사이트가 느려지니까 사용하지 마라 였습니다.

일단 제가 생각하는 마크업 방식에 있어서의 웹 표준의 정의를 한번 말씀드려보면

각각의 HTML(XHTML) 태그에는 그에 맞는 사용법과 의미가 담겨져 있다. 그 사용법에 맞게 태그를 구성하는것을 Semantic markup 이라고 할수있다.

리스트는 ul, ol, li로 문장은 p 제목은 h1~h6  으로 각태그의 역할에 맞게 사용하자는거겠죠? 뭐 어렵지 않습니다.

이런 측면에서 봤을때 Table도 분명히 자기 자신의 역할이 있겠죠? Table 의 역할을 알아 봅시다. (http://dev.w3.org/html5/spec/Overview.html#the-table-element)

The table element represents data with more than one dimension, in the form of a table.

HTML5 에서의 table의 역할을 기술한것인데요. 대충보면 Table 앨리먼트는 표 양식에서의 하나 이상의 데이터 구성을 보여주기 위한것이다. 이다 정도 되려나요?
이문장에서도 알 수 있다시피 테이블 태그는 사용되면 안되는 태그는 아닌것 같아요. 사용되는 안되면 태그라면 사라졌겠죠

제가 섯불리 예상하자면, “table layout을 사용 하지 말자”를 오해한게 아닌가 싶기도 하네요..

물론 table layout 에대해서도 언급이 되어있습니다.

Tables must not be used as layout aids. Historically, some Web authors have misused tables in HTML as a way to control their page layout. This usage is non-conforming, because tools attempting to extract tabular data from such documents would obtain very confusing results. In particular, users of accessibility tools like screen readers are likely to find it very difficult to navigate pages with tables used for layout.

테이블 레이아웃을 사용하면 툴(컴퓨터겠죠?) 표로 인식 하고 테이터를 추출 하기 때문에 혼란스럽고 스크린리더 같은 접근성도구에서 페이지를 이동하기가 어려워진다 뭐 이런 얘기 같은데요.. (자 영어 공부합시다.)

뭐  암튼 table layout 은 사용하면 안된다는것이 명확하게 써있네요..

근데 저는 왜 그런 얘기를 들었을까요…

table 은 일단 브라우저에서 랜더링 해주기 위해 다른 태그에 비해  좀 더 로직이 추가 되게 됩니다. 각 셀의 넓이를 알맞게 맞춰 주기 위한 노력을 한다고 하면 이해가 쉬울려나요? 이 부분은 table-layout 을 정의해주고 각 셀의 크기를 적절하게 미리 계산해 정의하는 방법으로 해결 할 수 있습니다.

또한 table 안에 table 을 중첩 사용하면 랜더링이 느려진다는 얘기도 들었는데 요즘 같은 컴퓨터에서 사실 얼마나 차이나겠어요 =_=; 관련자료 알려주심감사…
차이가 있다해도 표를위한 table 사용에서는 table 중첩 사용은 거의 하지 않죠…

저같으면 표는 물론이고 달력이나, 게시판의 리스트나 정보 등에서 사용될 수 있지 않을까 싶어요…
table 사용한다고 무작정 머라하지 마세요~ 열라고민해서 태그 짠 Markup개발자 상처 받아요.

2009년 2월 7일 한국 정보 문화 진흥원에서는 세번재 웹 표준의 날이 진행 되었습니다.
약 110여명의 분들이 황금같은 토요일에 그 먼 곳까지 찾아 오셔서 행사를 참석해 주시는것을 보고 정말 감동했습니다.

저도 운좋게 한 세션을 맡아 CDK에서 진행하는 웹 표준 경진대회와 CSS놀이터에 관해 얘기하게 되었습니다. 사실 그렇게 공익적인 얘기도 하니고, 도움되는 얘기는 아니었지만, 즐겁게 들어주셔서 감사했습니다. (발표문서 다운로드)
웹 표준 경진대회와 CSS놀이터 모두 여러분이 만들어가는 서비스인것을 알리고 싶었습니다.

이번 행사에서는 발표자분들의 노고가 정말 크다고 볼수 있었습니다. 기획부터 모두 참여해 주셔서 발제도 스스로 내어 주시고.. 행사에 대한 의견도 계속 내어주시고 또 행사장에 오셔서도 굳은일을 마다하지 않고 열심히 임해 주셨거든요. 자기발표가 아닐때는 자리도 없어서 쪼그리고 앉아서 있는모습을 볼때면 정말 죄송했습니다. 이런 대접을 받아야 할분들이 아닌데 말이죠.. 다음에는 좀더 훌륭한 환경으로 모시겠습니다. 캬캬캬캬캬캬

이번에는 clearboth분들께서 자원봉사를 진행해 주셨습니다. 좀더 잘 준비된 모임이 되는데는 자원봉사분들의 노력이 컷다고 생각합니다. 세션도 듣게 해주고 그랬어야 했는데 너무 막 부려먹기만해서 죄송합니다; 복받을꺼에요 ㅎㅎㅎㅎ

이번 행사에는 참가 가능인원이 100명이었습니다. 사실 자리가 많이 비좁으셨을걸로 생각됩니다만조금 답답하더래도 옹기종기 모여서 하는 모임이 좀더 재미있거든요. 라고 위안 삼기를 추천 드립니다. 이번에 등록하신분들중 34분정도가 사전에 알리지않고 불참을 하셨습니다. (그렇다고 66분만오신건아닙니다^^) 각자의 사정은 누구에게나 있을수 있습니다. 하지만 다른사람의 기회를 빼앗은것도 사실이지요. 다음 모임에는 이번 모임의 불참자는 패널티가 부여됩니다. 패널티의 방법은 생각해 보지 않았습니다.

“선배에게 질문하세요” 세션이 생각보다 호응이 좋아서 놀랐습니다. 예전에는 뻘쭘하게 한마디도 거의 없었거든요. 다음모임에는 진짜 발제를 가지고 토론을 진행해도 되겠던데요? 많은 분들의 좋은 의견, 제안 주신분들의 하나 하나의 목소리를 모두 기억하고 있습니다.

달콤한 칭찬도, 쓴 압박도 있었습니다. 항상 느끼는것 이지만 제가 너무 부족해서 능력이 안되나봅니다. 능력이 안되는만큼 좀더 몸으로 뛰겠습니다. 올해는 핑계 대지 않는 CDK가 될 수 있도록 열심히 노력하겠습니다.

다음 행사는 5월1일 웹 표준 경진대회입니다. 많은성원부탁드립니다.
다음부터는 썰렁하지 않은 진행을 하거나 다른분에게 맡기겠습니다. 저란 인간이 막사는 인간이다 보니 좀 그렇습니다. 돌 던지지는 말아주세요..