Comments

• 그로커 2009-11-13

  HTML 엘리먼트의 존재이유를 잘모르는 무지함에서 생기는 문제가 아닐까 합니다. 게다가 저 결과물의 용역을 줬을 갑(?)의 누군가는 "웹표준화에 맞지않는 테이블은 절대사용하시면 안됩니다" 라고 말했을수도.. 공감이 가는 글입니다.

• 입명이 2009-11-13

  ㅋㅋ

• rill55 2009-11-13

  처음 웹표준을 시작하게되면 제일 먼저 하는것들이 그동안 도배질한 table 코드에 대한 회의와 "너없어도잘할수있다" 라는것을 보여주기라도 하듯 table코드를 모두 div 또는 리스트로 대체하는 작업을 많이들 하게 되는것 같습니다. 배워가는 재미도 쏠쏠하니.... 하지만 나중에 만사 귀찮아지면 목록은 table 아니면 안되겠다 라는것을 느낄테죠; table!! 이 얼마나 멋집놈입니까!!

• 신승식 2009-11-13

  표준에 대한 잘못된 이해에서 비롯된 놀라운 응용력(?)이로군요. 무엇이든 갑이 요구하면 만들어내는! 한국 개발자들의 비애가 느껴지기도 하고~

• 지나가던이 2009-11-16

  tbody의 첫번째 column 을 제목으로 보고 th 로 하건 좀 의문이네요, 시맨틱적인 의미로도 th가 제목으로 보는것도 명확하지 않고, 스크린리더 입장에서도 별로 좋은 방식은 아닌듯 하네요. 저같으면 그 컬럼을 강조하고 싶다면 차라리 strong 을 추천하고 싶습니다.

• 마약 2009-11-16

  여쭙고 싶은게 생겼습니다. 저는 게시판이 꼭 테이블이여야 하나? 라는 의구심이 생겼습니다. 최근에 보편적인 코딩방식을 보면 "게시판은 무조건 테이블이다" 라고 인식되고 있는 실정인것 같습니다. 저는 게시판과 테이블은 다른거라고 생각하거든요. 테이블은 데이터를 표로써 나타내기 위한 도구이고, 게시판은 말 그대로 게시물을 출력해주는 것인데... 제 생각은 이렇습니다. 테이블은 어떤 통계나, 비율, 누적수치등... 을 나타내기에는 더없이 적합한 태그라고 보여지는데요. 특정 커뮤니티 게시판에 어떤 사람이 글을 썼다고 가정했을때, 그것이 과연 "데이터로써의 가치가 있는가?" 라는 의견입니다. 이런 상황에서는 오히려 목록태그가 더 적합하다고 봅니다. 사실, 윗분께서는 div로 행을 감싼거는 조금 의미가 잘못되었다고 보여지네요. div는 섹션을 나누는 태그인데, 하나의 의미를 가지는 컨텐츠를 여러 섹션으로 나누는게 잘못됐다고 봅니다. 굳이 스크린리더기가 제목행과 내용행을 분리해서 낭독해야만이 시각장애인이 컨텐츠를 이해할 수 있을까요? 제목행이 충분히 인지가 되었다면, 그 다음은 그냥 쿨하게 목록별로 쭈욱~ 읽어주면 될 것 같습니다. 따라서, li ul li /li /ul li li 이런식이 되겠죠. 게시판 = 테이블이라면, html5 에서는 신규엘리먼트 [datalist] 태그를 왜 ol li로 권고했을까요? 게시판은 테이블이다라는걸 제가 어떻게 해야 납득을 할 수 있을까요? 정말 몰라서 그러는거예요. 사실 저도, 아무생각없이 발코딩할때는 summary, thead - th, tbody - th 또는 td 이런식이었습니다만...왠지 이건 아닌거 같더군요... 집나간 제 개념을 다시 찾고 싶습니다 ㅠㅠ 도와주세요.

• 신현석 2009-11-16

  지나가던분 말씀을 듣고 자료를 좀 찾아봤는데, 이 글에 있는 테이블의 경우에는 이미 thead 에서 제목을 명시했기 때문에 tbody에서는 th를 사용안해도 될 것 같습니다. tbody 영역에서 th를 사용한 경우는 thead에서 맨 앞칸을 빈칸으로 두어서 제목을 표시하지 않는 경우에만 사용했더군요. 그리고 자료를 보다가 또 발견한 것이, 저는 지금까지 th에만 scope를 사용하는 줄 알았는데 위와 같은 경우에는 td에서 scope를 사용해서 제목역할을 할 수 있게 표시하는 경우도 있더군요. 덕분에 테이블에 대해서 좀 더 깊이 알게 되었습니다. 지적해 주셔서 감사합니다.

• 신현석 2009-11-17

  저도 마약님처럼 어떨때 테이블을 써야 하고 어떨때 리스트를 써야 하는지 헷갈릴 때가 많습니다. W3C에서는 테이블을 아래처럼 말하고 있습니다. The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells. 테이블을 사용하면 열과 행으로 데이터를 정렬할 수 있게 해 준다고 하는데, 거꾸로 생각하면 열과 행이 있는 데이터는 테이블을 이용해서 잘 표현할 수 있다고 할 수 있습니다. 각 게시물의 제목, 작성자, 작성일 등도 수치데이터는 아니지만 W3C에서 언급한 텍스트 데이터이기 때문에 테이블이 가장 적절한 테그라고 생각됩니다. 리스트 태그를 써서도 비슷한 형태로 정보를 전달할 수 있겠지만, 테이블로 구성하면 행과 열의 관계가 더 명확해지기 때문에 리스트 보다는 더 적합한 것 같습니다. 만약 중첩된 하위 리스트 항목이 다른 하위 리스트와 갯수가 다르거나 항목이 다를 경우에는 테이블로 구성할 수 없고 리스트로 구성해야만 할 것입니다. 하지만 게시판 리스트는 정확히 2x2로 구성된 데이터이기 때문에 테이블이 더 데이터를 잘 표현해 주게 됩니다. 사실 리스트도 굉장히 오용이 많이되고 있는 태그입니다. 리스트의 의미를 크게 확장해서 사이트를 통째로 리스트로 만드는 것은 어떻냐는 얘기도 있을 만큼 리스트를 너무 확대해서 생각하는 경우가 많은 것 같습니다. 트리구조로 표현되는 데이터의 경우를 제외하고는 되도록 너무 중첩하지 않는 것이 좋을 것 같습니다.

• 마약 2009-11-17

  객관적이고 친절하신 답변 진심으로 감사드립니다. ^^ 지금까지 정말 아무 생각없이 게시판류는 테이블로 구성했는데, 조금은 구분해서 사용할 수 있을 것 같습니다. 실무에 잘 반영하도록 하겠습니다~~

• 해빠 2009-11-17

  테이블에 대한 좋은 정보 감사합니다. 웹개발자는 아니지만 제게도 정말 좋은 글이었습니다. ^^ 혹, 스크린리더가 테이블을 어떻게 읽는지 궁금하신 분은 아래 포스트를 참고하세요. http://haeppa.kr/28

• nayun 2009-11-19

  테이블에 대한 새로운 관점 생겨 테이블을 다시 보게끔 했네요. 그렇지만, 내부 사정을 모른체 판단하기엔 조금 앞선 거 아닐까란 생각이 드네요. UI개발자분이 따로 계실지도 모르고, 재미? 로 그랬을 수도 있고..

• caost 2009-11-20

  <ul> <li> <dl> <dt class="co1">법령종류</dt> <dd class="co1">부령</dd> <dt class="co2">법령명</dt> <dd class="co2"><a href="/lawinfo/RecentRevisionLaw.mo?no=10" title="예비군부대 지휘관 선발에 관한 규칙">예비군부대 지휘관 선발에 관한 규칙</a></dd> <dt class="co3">소관부처</dt> <dd class="co3">국방부</dd> <dt class="co4">공포일</dt> <dd class="co4">09.11.12</dd> <dt class="co4">시행일</dt> <dd class="co4">09.11.12</dd> </dl> </li> <li> <dl> <dt class="co1">법령종류</dt> <dd class="co1">부령</dd> <dt class="co2">법령명</dt> <dd class="co2"><a href="/lawinfo/RecentRevisionLaw.mo?no=10" title="예비군부대 지휘관 선발에 관한 규칙">예비군부대 지휘관 선발에 관한 규칙</a></dd> <dt class="co3">소관부처</dt> <dd class="co3">국방부</dd> <dt class="co4">공포일</dt> <dd class="co4">09.11.12</dd> <dt class="co4">시행일</dt> <dd class="co4">09.11.12</dd> </dl> </li> </ul> 이런 식으로 구성하는 것은 어떤가요?

• 쏭군 2009-11-20

  옳은 지적입니다. 표형식의 데이터는 테이블을 사용하는게 옳겠죠. 그리고 table 마크업시 caption 요소 꼭 사용해주시고. class명을 co1, co2, co3... 이런것 보다는 의미를 부여해서 지어주는 것이 좋겠습니다.

• 흰별 2009-11-20

  저는 문제의 리스트를 작업한 퍼블리셔입니다. ^^;; 동료한테 재미있는 포스트를 보내준다고 해서 우연히 읽어봤는데 막상 제가 한 작업에 대한 접하니 만감이 교차하더군요.. 저 작업을 하기 전에 많은 고민을 했고, 그 당시에는 저렇게 코딩하는게 최선이었습니다.. 방법론적으로 더 많은 고민을 했었어야되는데.. 현재 유지보수 하는 입장에서도 저런 코딩은 문제가 많더라구요,, 조만간 테이블로 바꾸는 작업을 할 예정입니다. 그때도 관심 가져주시고요.. 여러분들의 의견 정말 감사합니다..

• 신현석 2009-11-20

  caost님 코드는 ul, dl의 과용 같습니다. 테이블을 사용하면 항목의 제목을 매번 반복하지 않고도 구현할 수 있습니다. 또, 작성하신 코드로 테이블 같은 디자인을 구현하려면 모든 dt를 다 감춰야 하는데 이또한 불필요한 작업입니다.

• 신현석 2009-11-20

  저는 흰별님같이 실력있는 분을 발견할때마다 너무 기분이 좋습니다. 법제처 사이트는 저 부분만 빼면 거의 코드가 완벽했습니다. 앞으로도 좋은 사이트 많이 제작해 주세요.

• 지나가다 2009-11-21

  법제처 메뉴를 보면 풀다운 메뉴가 아닙니다. 풀다운(pull-down) 메뉴는 우리가 일반적으로 사용하는 프로그램의 메뉴처럼 클릭하면 아래로 펼쳐지는 메뉴를 의미합니다. 공공 기관 등 국내의 대부분의 사이트들이 변태적인 메뉴를 사용하는데.. 이제는 수십년전부터 지금까지 계속 사용되는 풀다운 메뉴를 사용하였으면 합니다. firefox, IE 등의 각종 응용 프로그램의 최상단에 위치한 파일(File), 편집(Edit), 도움말(Help) 등의 메뉴 등이 풀다운 메뉴이며 윈도우 바탕화면에서 마우스 오른쪽 버튼을 클릭하면 팝업 메뉴가 나오는데 그것도 풀다운 메뉴입니다. www.sun.com 사이트를 방문하셔서 메뉴를 보시면 풀다운 메뉴로 만들어져 있으며 구글도 풀다운 메뉴로 되어 있습니다. 외국의 상당히 많은 사이트들은 풀다운 메뉴를 구현함으로써 사용자에게 편리성을 제공하지만 국내의 상당수의 웹 사이트는 클릭하면 옆으로 펼쳐지는 변태적인 메뉴를 매우 즐겨 사용합니다. 이제는 이런 변태적인 메뉴를 사용하지 않아도 되지 않을까요. 플래시로 메뉴까지 도배를 하면서 풀다운 메뉴를 구현하면 플래시 화면이 메뉴 길이 만큼 길어지는 문제 때문에 변태적으로 옆으로 펼치는 메뉴를 구현한 것으로 알고 있는데.. 이제는 이런 변태적인 메뉴를 더 이상 사용하지 맙시다. 웹 개발자들, 당신들이 사용하는 프로그램의 메뉴가 위에서 아래로 펼쳐지지 않고 왼쪽에서 오른쪽으로 펼쳐진다면 얼마나 불편하겠습니까. 게다가 이상하게 구현해서 핀트가 조금이라도 어긋나면 메뉴가 사라지기도 하는데 이제... 제발 상식적으로 생각하고 웹 사용자를 더 이상 불편하게 하는 일은 사라졌으면 좋겠습니다.

• 마약 2009-11-24

  안녕하세요~^^ 흰별님께 딴지를 걸려는 건 절대 아니구요. 사실은 한수 배울려고 법제처 소스를 보고 있어요. 현석님께서는 게시판 부분에 대해서만 언급을 하시고 나머지는 거의 완벽하다고 표현을 해주셨는데, 소스를 보니, Hn태그의 사용에 대해서 적절한지가 궁금해졌어요...퀵 메뉴에 h2가 사용되어 있더라구요... 그리고, 네비게이션에 탭키 접근시 두번째 대메뉴에 포커스가 진입하면 하위 메뉴들은 나오지 않는것이 적절한지 궁금합니다. 일부 컨텐츠 탭메뉴에서는 사용자가 원치않는 컨텐츠를 제공하면 안되므로, 이때는 포커스시에도 그냥 놔두는게 맞다고 생각하는데, 네비게이션은 다 보여줘야 하는게 아닐까 생각되어서요... 기획부분과 관련하여 폰트 사이즈 조절은 과연 필요한지도 의문이구요. ex6을 제외한 나머지 브라우저는 자체 줌인아웃이 되므로 안해도 된다고 들었는데, ex6을 위해 해야 한다면 시스템폰트뿐만이 아닌, 화면 전체가 저렇게 커지도록 하는게 맞는건지 궁금합니다. 18번 지표에서 a태그에 #을 넣지말라고 하던데, js외에는 해당 기능을 제공할 방법이 없을 경우에도 그냥 # 해놓으면 접근성 심사에서 감점 요인이 되나요? 흰별님 코드를 보고 지적하는게 아니니 기분 상하지 않으셨으면 해요^^; 사실 저는 흰별님처럼 못합니다 ㅎㅎ;; 이해해주세요.

• melt-snow 2009-11-27

  phpschool.com의 포럼 글을 보면 아직도 table의 표와 div의 구획 나누기를 혼동하는 개발자가 많습니다. 이 개념이 확실하게 잡히고 나서 보면 당연한 건데, 그렇게 되기까지는 시간이 제법 드는 것 같더군요. 그리고 그 개념이 안 잡힌 상태에서 코딩된 html은 이도 저도 아닌 상태로 이 글의 본문에서 지적한 것과 같은 문제점이 생기게 됩니다.

• 글을 보다..발견한것 2010-02-26

  제 모니터가 안좋은건가요? 이 덧글을 보신분들 한번정도 테스트해보세요! LCD/CRT 모니터 필요 익스, 파폭, 사파리 3개 열어서 폰트 자세히 보세요. 폰트 진하기가 익스 > 사파리 > 파폭 순인데.. 파폭에서 보여지는 글씨는 거의 읽기 힘들정도로 뿌옇더군요.. 저만그런가요? 현재 제가 보고 있는 폰트가 나눔고딕인가? 같은데... 다른님들은 어떤가요? 이런 현상은 어떻게 해결하면 좋을까요?

• 자몽 2010-05-27

  제가본 포스트중에 엄청 심도있는 포스트네요.ㅎㅎ 논란(?)의 개발자분도 직접 코멘트를 날려주시고, 저는 웹표준이라한다면 "fon-size로 텍스트의 사이즈를 변경가능한데 왜 h1태그가 있는가?"를 생각하면서 작업을 진행하고있습니다 ㅎㅎ;

• dkdkdk 2011-05-02

  글쓴분은 이 문서의 스,타일(외형)의 유지보수에 대한 면을 무시하시는듯 합니다.. 물론 컨텐츠 자체만 보면 테이블이 직관적이겠지만 저 문서가 한가지가 아니라 여러군데서 표준화해서 사용하는 양식이라면 그거 유지보수를 어찌 할려구 테이블을 쓰라고하는지... 일일히 페이지를 열어서 수정해야되는데... 딱 한번 쓰이는 문서가 아니라면 저런식으로 div와 ul,li써서 코딩하는게 맞는겁니다...

• 신현석 2011-05-02

  테이블도 스타일을 사용해서 디자인을 입힐 수 있습니다. 스타일은 CSS에서 제어하는 것이기 때문에 UL을 쓰든 TABLE을 쓰든 유지보수의 용이함 정도는 동일합니다. TABLE을 쓸때와 UL을 쓸때, 어떤 부분 때문에 유지보수에 차이가 생긴다고 생각하시는지 궁금합니다.

• 구린 2011-05-12

  나타내려는 row 가 수백줄이 되고 각 row마다 mouseover 이벤트로 배경색을 바꿔주려고 합니다. 이 경우, table을 사용하면 특히 IE에서 속도가 현저히 떨어지는 현상이 있네요, 그래서 Ul/LI로 바꾸었습니다만 이 경우에 css를 잘 적용하지 못해 row가 정확히 표현되지 않는 현상이 있는데 이 부분은 css를 수정해서 해결해야 할 일인 것 같군요.

• 진영최 2020-02-27

  안녕하세요 신현석님 제 블로그 테이블 레이아웃 예제로 현재 포스트에서 도움을 받아 참고자료로 링크를 걸고싶은데 링크 첨부해도 괜찮을까요?

• 신현석 2020-02-28

  진영최님, 링크는 허가 요청 안하고 그냥 거셔도 됩니다. 링크 거는거 가지고 뭐라는 사람은 웹도 잘 모르고 저작권도 잘 모르는 사람이에요. 그리고 저작물 라이센스는 사이트 푸터에 명시되어 있습니다.

• 진영최 2020-02-28

  넵 감사합니다! 하나 더 배워갑니다~! 좋은 하루 되세용~!!