주제: 웹표준과 관련한 나니님의 의견 ^^
굉장히 장문입니다. 원문은 http://sangsangbox.net/587 에서 보실 수 있습니다.
저는 사실 봐도 무슨소린지 모르겠군요 ^^^ daybreaker 님이 해결하시겠다라는 범위안에 들어가있는지 궁금합니다...
일단은 daybreaker 님이 시험을 끝내시기를 기다려봐야겠군요...
^^
아직 로그인하지 않았습니다. 로그인 또는 회원 등록을 해 주시기 바랍니다.
굉장히 장문입니다. 원문은 http://sangsangbox.net/587 에서 보실 수 있습니다.
저는 사실 봐도 무슨소린지 모르겠군요 ^^^ daybreaker 님이 해결하시겠다라는 범위안에 들어가있는지 궁금합니다...
일단은 daybreaker 님이 시험을 끝내시기를 기다려봐야겠군요...
^^
그런데 원문에서 원하시는 완벽한 (Strict) 표준 준수가 그렇게까지 중요한가요??
Validator에서 OK 사인이 뜨는 것을 보는 희열이외에는 큰 의미는 없다고 봅니다만....
(그리고 솔직히 Validator를 돌려보면 한 숨 나옵니다.... 누가 이렇게까지 골아프게 코딩을 해야한단 말입니까.... orz)
건더기님 제 기분을 상당히 무시하는 발언을 하셨네요 ^_^
건더기님은 아무런 느낌을 못 받으실 지 모르지만 저에겐 큰 희열감을 느끼게 해줍니다.
그리고 다른 분들에게는 모르지만 저에게는 vailder 통과여부 매우 중요합니다.
vailder에 통과하느냐 안통과하느냐에 따라서 달라지는 몇몇 이벤트에 도전하고 있고
이 세상의 모든 사이트들이 웹표준화 되는 세상을 꿈 꾸기 때문에 저에겐 매우 중요한 사안입니다.
그런 식으로 무시하지 마세요 ^_^
건더기님 제 기분을 상당히 무시하는 발언을 하셨네요 ^_^
건더기님은 아무런 느낌을 못 받으실 지 모르지만 저에겐 큰 희열감을 느끼게 해줍니다.
그리고 다른 분들에게는 모르지만 저에게는 vailder 통과여부 매우 중요합니다.
vailder에 통과하느냐 안통과하느냐에 따라서 달라지는 몇몇 이벤트에 도전하고 있고
이 세상의 모든 사이트들이 웹표준화 되는 세상을 꿈 꾸기 때문에 저에겐 매우 중요한 사안입니다.
그런 식으로 무시하지 마세요 ^_^
에공.... 죄송합니다....
(무시까지는 의도하지 않았는데...^^;;;;;)
일반적인 상황에서는 validator가 잡아내는 티끌 하나가 그리 영향을 주지는 않더라구요....
제가 불평을 한 것은 단지 너무 표준이 Strict하여 코딩하는 사람만 물먹는게 거시기하여서....ㅡㅡ;;
(솔직히 이미지마다 alt를 하라는 것은 좀...ㅡㅡ;;)
건더기 (2006-04-28 21:21:58)에 의해 마지막으로 수정
모두가 바라는 방향이 다른만큼, 다른분의 의견은 소중히 해야겠지요 ^^
표준준수는 그 어떤 이유를 막론하고라도 큰 의미가 있는 작업입니다...
daybreaker 선수님의 중간고사가 끝나기를 기다려보지요 ㅎㅎㅎ
나니님도 포럼에 오신것을 환영합니다.
그런데 원문에서 원하시는 완벽한 (Strict) 표준 준수가 그렇게까지 중요한가요??
Validator에서 OK 사인이 뜨는 것을 보는 희열이외에는 큰 의미는 없다고 봅니다만....
(그리고 솔직히 Validator를 돌려보면 한 숨 나옵니다.... 누가 이렇게까지 골아프게 코딩을 해야한단 말입니까.... orz)
적어도 이 발언은 조금 심하다고 생각합니다.
조금 다르게 생각해보면, 누가 버그 심한 태터툴즈를 사용한다고 생각하겠습니까?.
조금 더 쉽게 꾸밀 수 있고, 조금 더 편하게, 좋게 꾸밀 수 있는 블로그 서비스는 많이 있습니다.
게다가, 표준 준수를 잘 지키고 있는 블로그툴도 많이 나오고 있는 시점에서..
위와 같은 발언은.. 스스로 태터를 깍아먹는 말입니다.
포럼에서 개발에 또는 태터에 도움이 된다고 해서 다른 사용자를 무시(?) 하는 말을 해서는 안됩니다.
여기 모인 분들은 태터의 친구들이지, 태터의 주인은 아닙니다.
태터의 진정한 주인은 태터 유저들입니다.
태터로 자신의 브랜드를 만들고 있는 사용자들이 바로, 주인입니다.
여기서 모두 열심히 하고 있는 것을 알고 있습니다.
저 또한 별볼일없는 도움이라도 주기 위해 여러가지;;;;; 하고 있지만,
정말 수고하시는 분들도 많습니다. 그 분들이 돈 받고 하는 일도 아니고,(나중에는 돈 받을지도 모르겠지만)
지금은 스스로 하길 원해서 많은 시간과 노력을 들여서 애쓰고 계시지요..
그러한 노력이 한낱 말에 의해 깍아버리는 행동은 여기 계신 모두 자제해야 할 것 같습니다.
포럼이 생긴 이유?.. 바로 나니님과 같은 그런 포스팅을 귀담아 기울이고, 나니님이 "아 이런 것 쯤... 한낱 개인만족일 뿐이야" 라고
하신다고 해도 TnF에서는 더욱 신경써서.. 관심을 기울여야 된다고 판단했기 때문에 생기지 않았을까요?.
제 말이 조금 신경에 거슬린다고 하더라도, 이 점은 정말 중요하다고 생각합니다.
그리고, 미리 사과를 드립니다. 신경에 거슬리는 글을 남긴 것에 대해 ^^;;
유마 (2006-04-28 21:59:30)에 의해 마지막으로 수정
에헤.. 웹표준 그런거 잘 모릅니다.
지키면 좋은거구 안지키면 나쁜거다.. 그렇게 말하는 사람들이 이상한거지.
꼭 지켜야 된다고 말하는 사람이 이상해 보일뿐입니다.
어디까지나 웹 2.0이다 어쩌다 하지만,
개인에게 편한게 좋은거구 그게 웹표준에 어긋나면 또 어떻습니까.
다 같이 잘 보이면 그게 웹표준이 될수도 있는거구.
서로 좋자구 잘 살아보자구 하는건데.
저는 귀찮은거 딱 싫어합니다만.
웹표준 논할때마다 말하는거지만 닭이 먼저다 알이 먼저냐 그거 따지는 식이지만,
누가 더 맞다고 장구치기도 머하고.
서로 서로 말씀하시면서 기분 상하실 필요도 얼굴 찌푸릴 필요도
왜 그걸 그렇게 말하냐 할 필요도 없다고 봅니다.
어디까지나 흐름의 한 부분일뿐.
안지킨다고 죽는거 아닙니다.
저는 그렇습니다.
태클은 자유지만, 흥분은 하지 마세요.
저도 웹표준 지키자.. 머 그런쪽은 사실 싫습니다.
나니님을 빗대어서 하는 말은 절대 아님을 먼저 말하고 말하자면
웹표준을 따지는 분들의 대부분이 자신만이 그걸 지키고 자신만이 웹 표준을 젤 잘아며, 다른 사람은 그걸 안지키면 절대 안된다 안지키면 그 사람 무시할꺼다 그런 분들이 많다는겁니다.
그래서 더 서로 기분이 상하는거죠.
감정적인 부분은 많은 분들이 말씀하시니 기술적인 이야기만 드리겠습니다
우선, 저는 W3C의 웹표준 권고안에 대해서 근본주의자쪽에 가깝다는 말씀을 미리 드리고 시작하겠습니다.
개인적으로는 validator가 valid 결과를 내놓는 것을 넘어, 권고안에 비추어 valid하더라도 그 안에서 내용과 디자인의 분리가 제대로 되어있어야 한다고 생각하고 있습니다. 그리고 동시에 그렇지 않으면 큰 의미가 없다고 생각하고 있습니다. 아마 이 의견은 daybreaker님도 저와 마찬가지일 겁니다.
(사실 얼마나 valid한가의 문제는 태터툴즈의 문제보다는 스킨의 문제가 큽니다. valid마크를 달고 있는 경우에도 소스를 눈으로 읽을 수 없는 스킨이 대부분입니다. 또한 valid하다고 하면서도 내용이 디자인과 분리되어 있지 않은 스킨들 -특히 가장 흔한 예로 테이블을 레이아웃 등 표 이외의 부분에 사용하는! 그건 xhtml 스펙 초안의 처음에 나온 설명을 무시하고 껍데기만 가지고 표준이라고 주장하는거죠- 도 돌아다녀 보면 천집니다.)
여기까지 읽으셔서 많은 분들이 느끼셨겠지만, 네 그랬습니다. 저도 2년 쯤 전에는 현실을 보면서 아주 눈이 뒤집히고 그랬습니다. 그런데 지금은 생각이 많이 변했지요. 제가 글을 쓸 때 꼭 표준'권고'안이라고 쓰는 이유입니다. W3C는 권고안일 뿐 표준은 아니죠. 다양한 이유가 있을 수 있습니다. 그러한 이유가 태그 실수에 대하여 포용성이 좋은 IE에로의 종속성 때문일수도, HTML4가 너무 광범위하게 퍼진 현실 때문일수도, 눈에 보이는 쪽에 주로 관심을 두는 트렌드 때문일 수도 있습니다. 어떤 이유에서이건, 사실 모든 사람이 그 표준안에 맞출 필요는 없습니다. 이상이 구현되어 현실을 발전시키지만, 현실은 그 자체로 생명이 있습니다.
여기 포럼에도 다양한 사람들이 있습니다. 제각기 '웹 그 자체' 에 대한 생각은 모두 다를겁니다. 건더기님처럼 실용적인 입장에서 생각하시는 입장도 있고, 나니님처럼 중간적인 입장도 있고, daybreaker님이나 저처럼 구조와 내용 분리 그 자체까지 생각하는 입장도 있습니다. 어떤 입장도 맞거나 틀린 것은 없습니다. 주장에 대한 이유들이 모두 맞기 때문이지요.
그래서 이전에 XHTML준수에 대한 티켓을 등록하였습니다. 다양한 의견들이 있을 수 있지만, 적어도 태터툴즈가 사용자 각각의 선택을 방해해서는 안된다는 생각에서였습니다. 개인적으로 태터툴즈는 '사람을 담아내는 그릇' 이라고 생각하고 있습니다. 그렇다면 '어떤 식으로 표현하고 싶은가' 에 대한 자유는 최대한으로 주어야되지 않을까, 그러기 위해서는 역시 태터툴즈 소스라도 표준안을 strict하게 지켜가는 쪽이 모든 경우를 포용할 수 있는 것이 아닐까 하고 생각하고 있습니다.
그런 의미에서는 건더기님 말씀이 맟습니다. 스킨을 만들거나 할 경우는 골치 아프게 모두 지킬 필요도 없고, 표로 레이아웃을 짠다거나 다양한 요소를 배치하는데 쓴다던가 해서 내용과 형식이 분리되지 않아도 상관 없습니다. 중요한 것은 '자신을 얼마나 잘 표현하는가' 입니다. 표준권고안은 굉장히 strict하고, 실제로 사용자들이 그걸 다 지켜서 만들기는 힘듭니다. 그렇지만, 나니님이나 아침놀님, 저와 같이 "최대한 다양한 사용자들" 에게 선택의 기쁨을 주기 위해서는 태터툴즈 소스 부분에서는 W3C의 XHTML 표준 권고안을 지켜가는 것이 좋을 것 같다고 개인적으로 생각합니다.
덧) 현재는 1.0 transitional이 기준입니다만, 나중에 1.1 strict기준으로 가자고 하면 돌 맞겠죠? (ㅠ_ㅠ) frame도 없고 링크 속성에 target도 없고...
개인적으로는 나니님이 좀 과민반응하고 계신거 아닌가 싶습니다.
저도 strinct valid 를 추구하는것만이 정답이라고 생각하지는 않습니다.
언제나 느끼는 거지만 말이라는건 정말 어렵다고 생각이 드네요.
건더기님께서는 그럴 의도가 아니었던거 같은데 나니님께서는 기분이 조금 상하신거 같네요.
일단 기분 먼저 푸세요.
그럼 제 생각을 말씀드리겠습니다.
(제 생각일 뿐이니 기분 나빠하시는 분은 안계셨으면 합니다. )
표준이라는 것은 결국 사람이 사용하기 편하기 위해서 만들어진 기술을 누구나가 똑같이 사용할 수 있도록 하기 위해 존재한다고 생각합니다.
아무리 뛰어난 기술이라도 사용하는 사람이 없다면 사라질 수 밖에 없습니다.
(정확하게 기억은 안나지만 실제로 그런 경우가 있었던걸로 알고 있습니다.)
결국 제 생각은 사람 > 기술(표준) 이라고 생각한다는 것이죠.
그렇다고해서 표준을 지킬 필요가 없다고 생각하지는 않습니다.
오히려 저는 표준은 가능한한 꼭 지켜야 한다고 생각하고 있고요.
'어떤 식으로 표현하고 싶은가' 에 대한 자유는 최대한으로 주어야되지 않을까, 그러기 위해서는 역시 태터툴즈 소스라도 표준안을 strict하게 지켜가는 쪽이 모든 경우를 포용할 수 있는 것이 아닐까 하고 생각하고 있습니다.
특히 위의 말에는 100% 동감합니다.
모든 분을 만족시키기 위해 태터툴즈에서 취할 수있는 유일한 방법이라고 생각되고, 그정도의 수고(?)는 할 필요가 있다고 생각합니다.
그리고 inureyes님께서 mvc 모델에 대해서 적어주신 것 같은데, 개인적으로는 과연 웹에서 완벽한 mvc 모델의 적용이 가능한가에 대해서 의문을 가지고 있답니다.(사실 제 경험이 부족해서인지 제가 느끼기에 완벽한 mvc 모델을 구경해본 적도 없지만요.)
술 한잔하고 와서 쓰다보니;; 두서없이 쓴거 같은데 이해해주세요. T_T
ps. 사실 저는 "frame도 없고 링크 속성에 target도 없고..." 쪽을 지지합니다.
흠...
저도 처음에는 validator 통과를 상당히 자랑스럽게 여기는 쪽이었습니다만, 요즘은 그렇게 엄격하게 생각지는 않습니다. (뭐 그 당시 습관이 그대로 남아서 제가 직접 짜는 php, xhtml 코드들은 웬만하면 다 통과가 됩니다만...-_-) 그저 웹브라우저가 해석하는 데 문제가 없다는 걸 보장해주는 정도로만 생각하고 있습니다. (그러나 항상 문제는 IE 때문에 발생하지요.. orz)
태터툴즈의 경우는 inureyes 님의 말처럼, 표준을 별로 개의치 않는 분과 함께 표준을 매우 중요시 여기는 분들을 모두 만족시키기 위해선 태터툴즈의 기본 틀이라도 표준을 준수하는 방향이 옳다고 생각합니다.
일단 현재는 XHTML 1.0 Transitional입니다만, Strict까지 가는 건 손을 상당히 봐야 할 겁니다. sandbox 실험본을 가지고 기본 스킨을 적용한 상태에서 태터툴즈 자체의 코드에 의해 발생하는 문제점들 위주로 편집을 해보겠습니다.
ps. 하지만 전 내용과 디자인의 분리는 되도록이면 지켜졌으면 좋겠다고 생각합니다. 물론 스킨 시스템이라는 것이 있어서 스킨을 어떻게 만드느냐에 따라 달라지지요. 태터툴즈 그 자체로 봐서는 꽤 잘 지켜졌다고 생각이 되구요(관리자 화면만 제외하면), 문제는 스킨을 어떻게 만드느냐겠지요.
daybreaker (2006-04-29 00:10:52)에 의해 마지막으로 수정
원문을 읽어보았습니다.
그래서 태터툴즈 운영자의 친절한 답변에 따라 친절히 category_list 치환자를 써 보았어.
근데 여기서 또 발생하는 문제가 단순히 ul, li 만 사용함으로 인해
엄청나게 디자인이 컨추리해지는거야. 그래서 ul, li태그에 각각 따로
ㅡ 각각의 서브 카테고리에 서로 다른 캐스캐딩을 주어서 꾸미고 싶어서 ㅡ
class나 id 애트리뷰트를 추가하게 하면 안되겠느냐,고
또 문의를 했는데 이번엔 철저히 씹혔고.
이 부분은 반영할 수 있도록 노력하겠습니다.
사실 저도 "있지도 않은 애트리뷰트를 써야 하는가" 하는 부분은 어떻게 결론 지어야 할 지 모르겠습니다. 표준 준수를 위해서라면 안 쓰는 게 맞겠지요. HTML이 아닌 XML이라면 쉽게 가능하겠지만 기반이 HTML인 이상 custom attribute로 인한 오류는 어쩔 수가 없는 부분이라 생각됩니다.
애초부터 해당 속성을 사용하지 않는 방법이 있을런지는 잘 모르겠지만, input type="hidden" 같은 걸 쓰면 해결할 수 있을 것도 같습니다. (input 태그가 form 태그 안에 있지 않아도 validation이 됩니다. 다만 태터 자체의 작동에 영향이 없도록 해야겠죠.)
그리고, favicon을 표시하는 부분의 onerror 속성 문제.. 이건 참 난감하지요. 아직 저도 뚜렷한 해결책은 잘 모르겠습니다. -_-; 좀더 자료 조사를 해봐야겠네요.
ps. 하지만 현재의 category list로도 ul, li를 적절히 중복시킨 selector를 이용하면 원하는 디자인 구현에 큰 문제는 없을 것 같은데... 이 부분은 직접 테스트보겠습니다. -> 아, 각 서브카테고리별로 다른 디자인을 주고 싶다면 id, class가 필요하겠군요.;
daybreaker (2006-04-29 00:31:48)에 의해 마지막으로 수정
ps. 하지만 현재의 category list로도 ul, li를 적절히 중복시킨 selector를 이용하면 원하는 디자인 구현에 큰 문제는 없을 것 같은데... 이 부분은 직접 테스트보겠습니다. -> 아, 각 서브카테고리별로 다른 디자인을 주고 싶다면 id, class가 필요하겠군요.;
현재 제 블로그에서 카테고리가 들어있는 div의 ul, li속성을 적당히 조절해서 디자인에 구현해서 쓰고 있습니다. 스킨에 따라 저 div의 이름이 다를 수 있으니, 트리 스킨을 그대로 가져다 쓰는 것은 조금 힘들겠네요.
아예 태터에서 파싱을 할 때 특정한 id를 가진 div로 category_list를 감싸게 하고 그 id의 ul, li 속성을 조절하는 방법은 어떨까 생각됩니다. 이 경우 기존의 트리 스킨을 list 방식에서도 사용할 수 있겠군요. 괜찮다고 생각하신다면 한 번 만들어 보겠습니다.
일단 category_list 치환자를 썼을 때 div id="categoryList"로 감싸주는 것이 필요하겠네요.
하지만 나니 님이 말씀하신 것처럼 카테고리별로 다른 디자인을 주기 위해서는 ul 별로 id를 주어야 할 것 같습니다
<div id="box">
<div id="categoryList">
<ul id="category1">
...
<ul id="category1_1">...</ul>
<ul id="category1_2">...</ul>
...
</ul>
<ul id="category2">...</ul>
</div>
</div>
기존 테이블 방식의 Tree Skin을 사용하려면 태터툴즈가 style 속성을 직접 넣어주거나 php로 생성한 css 파일을 포함시킬 수 있겠군요. 그렇지만 이 경우 스킨에서 정의할 수 있도록 옵션을 줘야 할 것 갈습니다.
daybreaker (2006-04-29 00:57:34)에 의해 마지막으로 수정
daybreaker님께서 TT 개발을 돕고 계시는줄 몰랐군요 ^^;
웹표준에는 저도 관심이 많고해서,, 키보드에 손을 댑니다.
사실 모든 사람이 그 표준안에 맞출 필요는 없습니다. 이상이 구현되어 현실을 발전시키지만, 현실은 그 자체로 생명이 있습니다.
라고 inureyes님께서 말씀하셨듯이 웹표준 이라는것 자체가 강요가 아닌 일단 권고안 이라는것입니다. 옛날 어느 포털사이트에서 웹표준에 맞추려 해도 지원하는 언어에서 output 자체가 표준에 어긋나고 있었기때문에 골치아파 하시길래 "하지마세요" 라고 말씀드렸습니다. ㅡㅡ
"웹표준 준수" 라는것이 html4.01 로 준수하더래도 준수 하는것 이라고 생각합니다. 물론 w3에서 권하는것은 strict 모드이긴 하지만 말입니다. 하지만 브라우저의 기술들도 제대로 변화되지 않았고, (아직도 죽쓰고 있는 ie) 표준 지원에 방해가 되는 언어들도 아직 있기때문에 최대한 변화할수 있는 한에서 그리고 지킬수 있는 안에서 하라는 것이지 무조건 1.1 버전을 준수하라는건 절대 아닙니다. 뭐 eric meyer 는 브라우저에서 각각 다르게 보여도 괜찮다고 하지만, (워낙 그분은 정보전달에 우선순위를 두는,,) 디자인을 하는 사람들에게는 그건 아니니까요.
전 TT 의 노력으로 최대한 '웹표준' 이라는것의 걸음은 맞추려고 노력하시는것 멋지다고 생각됩니다. 그래서 1.1의 준수까지 가시는거 막지는 않습니다만 제 경험에 의하면 노력에 비해 결과는 별로라고 생각하고 있습니다. 제 홈같은 단순한 집에서야 1.1이 괜찮긴 합니다만,, 1.0 tradition 에도 감격이라고 말씀드리고 싶네요. 위에서 언급하셨듯이 문서와 프레젠테이션 분리는 필요하겠으나 너무 집착때문에 머리털이 빠지시면 "마이너스"라고 생각됩니다.
덧붙이자면,,
daybreaker 님께서 생각하시는 각각의 ul 에 id 를 주시는건 음,,, 정말 정교한 디자인을 원하시는 유저가 아니라면 솔직히는 필요없다고 생각이 됩니다. 그리고 그럴만한 이유도 적다고 생각이 됩니다. 카테고리 부분은 어느정도 패턴이 동일해야 되기 때문에 그정도의 부분까지 한다면 오히려 역효과가 나올수도 있겠네요.
일단 카테고리 제어가 CSS 에서
메인 카테고리 선택 에는 #category_list ul li {어쩌구} 와
sub 카테고리 선택에는 #category_list ul li ul li {어쩌구}
로 선택이 가능하니 일단은 큰 어려움은 없다고 생각이 됩니다.
주절주절 썼네요 아무튼 수고들 하십니다
일단 category_list 치환자를 썼을 때 div id="categoryList"로 감싸주는 것이 필요하겠네요.
하지만 나니 님이 말씀하신 것처럼 카테고리별로 다른 디자인을 주기 위해서는 ul 별로 id를 주어야 할 것 같습니다
<div id="box"> ... </div>
기존 테이블 방식의 Tree Skin을 사용하려면 태터툴즈가 style 속성을 직접 넣어주거나 php로 생성한 css 파일을 포함시킬 수 있겠군요. 그렇지만 이 경우 스킨에서 정의할 수 있도록 옵션을 줘야 할 것 갈습니다.
이 방식으로 각각의 카테고리에 속성을 다르게 주어 구현할 경우 id가 너무 많이 남발됩니다...
차라리 2단계까지의 ul/li 에 속성을 주는 식으로 단순화 시키는게 어떨까요? 그리고 정말로 전부 다른 속성의 목록그림이 필요하다면 id를 모두 주는것 보다는 차라리 출력할 때 ul과 li에 직접적으로 style 속성을 주는게 나을 것 같습니다. (엄청 안 내키지만 말이죠 =_=)
전 TT 의 노력으로 최대한 '웹표준' 이라는것의 걸음은 맞추려고 노력하시는것 멋지다고 생각됩니다. 그래서 1.1의 준수까지 가시는거 막지는 않습니다만 제 경험에 의하면 노력에 비해 결과는 별로라고 생각하고 있습니다. 제 홈같은 단순한 집에서야 1.1이 괜찮긴 합니다만,, 1.0 tradition 에도 감격이라고 말씀드리고 싶네요. 위에서 언급하셨듯이 문서와 프레젠테이션 분리는 필요하겠으나 너무 집착때문에 머리털이 빠지시면 "마이너스"라고 생각됩니다.
저도 그렇게 막 집착하고 싶지는 않습니다. 그래도 완벽한 validation을 원하는 분들이 있기 때문에, 툴 수준에서는 지켜주면 좋지 않겠나 하는 것이지요. 쩝.. 빈 ol 태그와 빈 ul 태그 같은 문제는 그냥 넘어가야 할 것 같습니다. -_-a 말씀마따나 이 잡다가 초가삼간 태우는 격이 될 것 같다는...;;
덧붙이자면,,
daybreaker 님께서 생각하시는 각각의 ul 에 id 를 주시는건 음,,, 정말 정교한 디자인을 원하시는 유저가 아니라면 솔직히는 필요없다고 생각이 됩니다. 그리고 그럴만한 이유도 적다고 생각이 됩니다. 카테고리 부분은 어느정도 패턴이 동일해야 되기 때문에 그정도의 부분까지 한다면 오히려 역효과가 나올수도 있겠네요.일단 카테고리 제어가 CSS 에서
메인 카테고리 선택 에는 #category_list ul li {어쩌구} 와
sub 카테고리 선택에는 #category_list ul li ul li {어쩌구}
로 선택이 가능하니 일단은 큰 어려움은 없다고 생각이 됩니다.
사실 저도 이렇게까지 id를 주어야 하나 하는 생각이 듭니다. 하지만 나니 님의 경우는 그걸 강력히(?) 원하시는 유저시기 때문에..-_-; 그래서 li 까지 주지는 않더라도 ul 정도까지는 괜찮지 않을까 하는 생각입니다. (사실 이것도 CSS 3에 있는 n-th element selector가 나온다면 필요 없어질 텐데 말이죠 -_- 생각 같아서는 CSS3나 CSS4 정도에서 정규표현식을 이용한 태그 속성 검색까지 해준다면 얼마나 좋을까 한다는...)
daybreaker (2006-04-29 03:56:32)에 의해 마지막으로 수정
음 일단 왜 ul 부분에 id 가 필요 없는지에 대해는 위에서 설명드렸듯이 디자인에 큰 영향을 미치는 부분은 아닙니다.
그리고 이미 위에서 말씀드린 소스로 나니님의 문제는 도와드렸습니다. 제가 수많은 테마제작이나 사이트 제작을 해봤지만 메뉴부분에서 하위 ul 까지 id 로 정해준다는건 약간은 지나친세심함 입니다. 1px, 1px 조절하여 구현해야하는 부분이라 하더래도 리스트의 조절은 상위 선택자부터 시작하여 잡아주는것이 원칙아닌 원칙입니다.