w3c 권고안 과연 지켜야 하나?

richebm의 이미지

엠파스가 리뉴얼하고 플레쉬 관련 부분이 불여시에서 제대로 나타나지 않길래
w3c 의 html validator 로 검사를 해 보았습니다.
not valid로 나오더군요. 혹시나 해서 비슷한 네이버를 검사해 보았죠.
역시 마찬가지 더군요.그래서 역시 '우리나라 사이트 들이란' 하고 생각을
했죠.
이쯤에서 호기심에 kldp를 검사해 보았습니다.
헉 !!! not valid 로 나오더군요. 엥? 이런 데비안 사용자 모임을
검사해 봤습니다. 역시 not valid. 그놈 사용자 모임도 역시나 였습니다.
흔히 익스플로러에서 나오는 사이트가 불여시등에서 제대로 안나오면
저희 쪽에선 이런식으로 말을 하곤 하죠. w3c 표준을 지키라고.
뭐 묻은 개가 뭐 묻은 개 나무라는 식이었습니다. 헐...
외국 사이트도 조사해 봤습니다.
yahoo, aol, google, amazon 어느 하나 마찬가지 더군요.
vaild 라고 자랑스럽게 나오는 사이트가 2개 있더군요.
gnu.org 랑 w3.org
이걸 어떤식으로 해석 해야 할 지 당황스럽네요.
모두가 지키지 않는다면 그게 무슨 표준인가요?

khris의 이미지

적어도 웹 개발자들이 '표준'을 지키려고 노력하면 익플이던 파이어폭스던 죄다 잘 보일수 있다는데서 그 의의가 있다고 생각합니다.

───────────────────────
yaourt -S gothick elegant
khris'log

cdpark의 이미지

당연히 지켜야죠!

MoniWiki는 W3 표준을 준수하는데, wiki.kldp.org는 W3 표준에 어긋나네요.
살펴보니 옆쪽의 스폰서 링크에 IMG의 end tag가 빠져 있군요.

phpbb는 W3 표준을 그럭저럭 지키는 듯 싶은데, TITLE 부분에 한글이 들어가면 W3 validator가 싫어하는군요. bbs.kldp.org는 </span> 하나가 남아도는 듯 싶고요.

그밖에 살펴보니 수정 Blog는 W3 표준을 준수하는 듯 싶은데, 사용자들이 쓰는 글이 W3 표준에 어긋나는지까지 체크하지 못하네요. 직접 HTML을 사용자가 작성해서 올리는건가요?

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

cdpark wrote:
당연히 지켜야죠!

MoniWiki는 W3 표준을 준수하는데, wiki.kldp.org는 W3 표준에 어긋나네요.
살펴보니 옆쪽의 스폰서 링크에 IMG의 end tag가 빠져 있군요.

phpbb는 W3 표준을 그럭저럭 지키는 듯 싶은데, TITLE 부분에 한글이 들어가면 W3 validator가 싫어하는군요. bbs.kldp.org는 </span> 하나가 남아도는 듯 싶고요.

그밖에 살펴보니 수정 Blog는 W3 표준을 준수하는 듯 싶은데, 사용자들이 쓰는 글이 W3 표준에 어긋나는지까지 체크하지 못하네요. 직접 HTML을 사용자가 작성해서 올리는건가요?

soojung은 text (html 포함), html (위지윅 에디터), bbcode를 지원합니다. 그래서, 직접 HTML로 작성한 경우에는 틀릴 가능성도 있습니다. :p

익명 사용자의 이미지

richebm wrote:
엠파스가 리뉴얼하고 플레쉬 관련 부분이 불여시에서 제대로 나타나지 않길래
w3c 의 html validator 로 검사를 해 보았습니다.
not valid로 나오더군요. 혹시나 해서 비슷한 네이버를 검사해 보았죠.
역시 마찬가지 더군요.그래서 역시 '우리나라 사이트 들이란' 하고 생각을
했죠.
이쯤에서 호기심에 kldp를 검사해 보았습니다.
헉 !!! not valid 로 나오더군요. 엥? 이런 데비안 사용자 모임을
검사해 봤습니다. 역시 not valid. 그놈 사용자 모임도 역시나 였습니다.
흔히 익스플로러에서 나오는 사이트가 불여시등에서 제대로 안나오면
저희 쪽에선 이런식으로 말을 하곤 하죠. w3c 표준을 지키라고.
뭐 묻은 개가 뭐 묻은 개 나무라는 식이었습니다. 헐...
외국 사이트도 조사해 봤습니다.
yahoo, aol, google, amazon 어느 하나 마찬가지 더군요.
vaild 라고 자랑스럽게 나오는 사이트가 2개 있더군요.
gnu.org 랑 w3.org
이걸 어떤식으로 해석 해야 할 지 당황스럽네요.
모두가 지키지 않는다면 그게 무슨 표준인가요?

HTML 문법적 오류가 좀 있다고 데비안 유저스나 KLDP가 W3C권고안을 지키지 않는다고 해석하는 것은 좀 억지군요. 마치 거의 모든 모범운전자가 실수로 정지선 몇번 밟아본 적이 있다고 어차피 지키지 않을 정지선 지키면 뭐하냐 말하는 것과 같습니다.

W3C권고안을 지키라는 말의 맥락을 생각해 보았으면 합니다.
교통법규는 사람의 안전과 교통편의를 위해 만들어진 것이지, 경찰에게 걸리지 말라고 존재하는 것이 아닙니다. 모범운전자라면 눈에 보이지 않는 사소한 실수는 할 수 있지만, 사람을 치거나 통행인을 위협하는 운전을 하지는 않습니다. W3C권고안 역시 최대한의 정보접근성을 보장하기 위해 만들어진 것일 뿐입니다. kldp나 데비안 유저스가 문법검사기로 w3c표준에 어긋나는 부분이 있을지 몰라도 W3C표준에 충실한 웹브라우저로 이용하는데는 어떠한 불편도 없습니다. 기계가 만든 코드가 아닌 이상 문법적 오류는 어디서나 존재할 수 있으며 그걸 두고 왈가왈가 한다는 것 자체가 아주 우스운 얘기인것입니다.

cdpark의 이미지

ditto wrote:
soojung은 text (html 포함), html (위지윅 에디터), bbcode를 지원합니다. 그래서, 직접 HTML로 작성한 경우에는 틀릴 가능성도 있습니다. :p

수정 홈페이지에 예로 든 두 사람의 blog가 모두 다 XHTML 1.1 마크는 달려있는데 실제 검사해보면 validator가 투덜대더군요. :)

html에 대해서 다시 parsing해 표시하는 건 부담이 크겠죠?

zelon의 이미지

Anonymous wrote:
richebm wrote:
엠파스가 리뉴얼하고 플레쉬 관련 부분이 불여시에서 제대로 나타나지 않길래
w3c 의 html validator 로 검사를 해 보았습니다.
not valid로 나오더군요. 혹시나 해서 비슷한 네이버를 검사해 보았죠.
역시 마찬가지 더군요.그래서 역시 '우리나라 사이트 들이란' 하고 생각을
했죠.
이쯤에서 호기심에 kldp를 검사해 보았습니다.
헉 !!! not valid 로 나오더군요. 엥? 이런 데비안 사용자 모임을
검사해 봤습니다. 역시 not valid. 그놈 사용자 모임도 역시나 였습니다.
흔히 익스플로러에서 나오는 사이트가 불여시등에서 제대로 안나오면
저희 쪽에선 이런식으로 말을 하곤 하죠. w3c 표준을 지키라고.
뭐 묻은 개가 뭐 묻은 개 나무라는 식이었습니다. 헐...
외국 사이트도 조사해 봤습니다.
yahoo, aol, google, amazon 어느 하나 마찬가지 더군요.
vaild 라고 자랑스럽게 나오는 사이트가 2개 있더군요.
gnu.org 랑 w3.org
이걸 어떤식으로 해석 해야 할 지 당황스럽네요.
모두가 지키지 않는다면 그게 무슨 표준인가요?

HTML 문법적 오류가 좀 있다고 데비안 유저스나 KLDP가 W3C권고안을 지키지 않는다고 해석하는 것은 좀 억지군요. 마치 거의 모든 모범운전자가 실수로 정지선 몇번 밟아본 적이 있다고 어차피 지키지 않을 정지선 지키면 뭐하냐 말하는 것과 같습니다.

W3C권고안을 지키라는 말의 맥락을 생각해 보았으면 합니다.
교통법규는 사람의 안전과 교통편의를 위해 만들어진 것이지, 경찰에게 걸리지 말라고 존재하는 것이 아닙니다. 모범운전자라면 눈에 보이지 않는 사소한 실수는 할 수 있지만, 사람을 치거나 통행인을 위협하는 운전을 하지는 않습니다. W3C권고안 역시 최대한의 정보접근성을 보장하기 위해 만들어진 것일 뿐입니다. kldp나 데비안 유저스가 문법검사기로 w3c표준에 어긋나는 부분이 있을지 몰라도 W3C표준에 충실한 웹브라우저로 이용하는데는 어떠한 불편도 없습니다. 기계가 만든 코드가 아닌 이상 문법적 오류는 어디서나 존재할 수 있으며 그걸 두고 왈가왈가 한다는 것 자체가 아주 우스운 얘기인것입니다.

하지만, 발견되었다면 고치는 것이 좋을 듯 합니다. 정지선이야 다음에 안 밟으면 되지만, kldp 를 고치지 않는다면 계속 정지선을 밟고 있는 셈이겠지요. 지적된 부분을 고칠 수 있으면 고치는게 더 나은 kldp 를 만드는 길이라고 생각합니다. 불편이 없다고 틀리지 않은 건 아닙니다.

그리고 이건 좀 오버일지도 모르나, kldp 나 mozilla.or.kr 등이 국내의 웹 표준을 이끌어나가는 발판이 될 수 있는 시점에서 좀 어렵더라도 모범적인 모습을 보여준다면 개선하려는 의지를 가진 웹 개발자들에게 좀 더 좋은 모습이 될거라 생각합니다. ^^

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

익명 사용자의 이미지

저는 완벽주의적인 성격때문인지 몰라도 간단하게 고칠 수 있는 것들을 왜 안고치는지가 의문스럽더군요.

예를들면 <br /> 이런식의 태그라던지.. < a href=.. 이런거라던지 이런 태그에서 많이들 걸리던데 그거 고치는게 힘든가요? :?

Prentice의 이미지

http://bbs.kldp.org/viewtopic.php?p=243421#243421

Quote:
HTML 문법적 오류가 좀 있다고 데비안 유저스나 KLDP가 W3C권고안을 지키지 않는다고 해석하는 것은 좀 억지군요. 마치 거의 모든 모범운전자가 실수로 정지선 몇번 밟아본 적이 있다고 어차피 지키지 않을 정지선 지키면 뭐하냐 말하는 것과 같습니다.

동의합니다.

참고로 <br />는 합법적이고, <br/>에 비해 권장(?)되는 표현입니다.
-----
PS. Do I smell a troll?

bh의 이미지

zelon wrote:
하지만, 발견되었다면 고치는 것이 좋을 듯 합니다. 정지선이야 다음에 안 밟으면 되지만, kldp 를 고치지 않는다면 계속 정지선을 밟고 있는 셈이겠지요. 지적된 부분을 고칠 수 있으면 고치는게 더 나은 kldp 를 만드는 길이라고 생각합니다. 불편이 없다고 틀리지 않은 건 아닙니다.

공감..

--
이 아이디는 이제 쓰이지 않습니다.

nytereider의 이미지

참고로...

a href=...에서 href의 값에는 &등의 기호는 반드시 이스케이프를 해 주어야 한다고 하더군요. 즉, xyz.php?opt1=aaa&amp;opt2=bbb...라고 써야 하는것이 맞다고 합니다.

richebm의 이미지

검은해 wrote:

참고로 <br />는 합법적이고, <br/>에 비해 권장(?)되는 표현입니다.

의외네요. 합법적이고 권장되는 표현에대해 w3c의 오류분석기가 잘못되었다고 표시한다면 그건
분명 w3c의 오류분석기가 문제가 있는 것이고 그렇담 오류분석기로 표준에 맞네 안맞네 하는
자체가 무의미 해지는 군요.

어쨌든 설마 이글을 엠파스 관리자가 봤을리 없지만( 혹시 봤을려나 -_-; ) 지금은 불여시에서도
제대로 나오네요. 익스플로러에서 나오는 오른쪽 옆에 광고는 안나오지만 그건 차라리 안보이는게
나으니까...

사실 w3c 표준을 부각시킨건 익스플로러에 맞춘 사이트가 불여시등의 오픈소스 진영 브라우저에서
제대로 나타나지 않는데 대하여 그냥 '불여시에서 제대로 나오게 해줘요' 보다 'w3c 표준을 지키세요'
라는 말이 더 설득력이 있어서 였습니다. 하지만 현실적으로는 어려움이 있네요.

교통법규에 비유해서 익명으로 올리신 분의 글이 상당히 고무적이네요. 저도 공감가는 부분이 있고요.
하지만 문제가 없다고 보기에는 좀 심하다고 생각하는 데요.
정지선을 대통령하고 교통부장관외에는 아무도 지키지 않는다면,
그것도 모범이 되야할 국무총리 장관 사회 유명인사들 할 것
없이 모두 안 지킨다면 이 법규자체가 문제가 있어 보입니다.
국내외 유명사이트 하나 같이 표준하고는 멀게 나왔거든요.
그렇담 3가지중 하나로 결론 내려 볼 수 있네요.
첫째 w3c 표준이 너무 엄격해서 실지로 적용하는 데는 무리가 있다.
둘째 브라우저에서 제대로 나온다면 꼭 표준에 다 맞게 코딩하는 것은 시간낭비고 귀찮은 일이라고
웹마스터들은 생각한다.
셋째 w3c 오류분석기가 적지않은 버그를 가지고 있어 그걸로 판단하기보다 표준 문서로 판단해야
한다.

사실 제가 바라는 건 w3c 표준을 지키고 안지키고의 논쟁이 아니라 익스플로러 없이도 불편하지 않을
수 있다면 이수영의 노래 처럼 얼마나 좋을까 :D 입니다.
머리아픈 w3c 표준 따윈 진짜 관심도 없을수도.

progcom의 이미지

richebm wrote:
검은해 wrote:

참고로 <br />는 합법적이고, <br/>에 비해 권장(?)되는 표현입니다.

의외네요. 합법적이고 권장되는 표현에대해 w3c의 오류분석기가 잘못되었다고 표시한다면 그건
분명 w3c의 오류분석기가 문제가 있는 것이고 그렇담 오류분석기로 표준에 맞네 안맞네 하는
자체가 무의미 해지는 군요.

XHTML로 작성했을때, <br>은 오류이고, <br/>이나 <br />은 valid로 나옵니다. HTML 4를 기준으로 했을때 어떤지는 잘 모르겠군요.
(HTML 4로 했을때 <meta ... />가 오류였었니까, <br/>도 오류이려나요?)

w3c validator 자체에는 문제가 없습니다.

죠커의 이미지

richebm wrote:
검은해 wrote:

참고로 <br />는 합법적이고, <br/>에 비해 권장(?)되는 표현입니다.

의외네요. 합법적이고 권장되는 표현에대해 w3c의 오류분석기가 잘못되었다고 표시한다면 그건
분명 w3c의 오류분석기가 문제가 있는 것이고 그렇담 오류분석기로 표준에 맞네 안맞네 하는
자체가 무의미 해지는 군요.

혼동이 있으셨나 봅니다. 위에서 언급되던 Validator 오류와 <br />는 무관합니다. :-)

d3m3vilurr의 이미지

richebm wrote:

그렇담 3가지중 하나로 결론 내려 볼 수 있네요.
첫째 w3c 표준이 너무 엄격해서 실지로 적용하는 데는 무리가 있다.
둘째 브라우저에서 제대로 나온다면 꼭 표준에 다 맞게 코딩하는 것은 시간낭비고 귀찮은 일이라고
웹마스터들은 생각한다.
셋째 w3c 오류분석기가 적지않은 버그를 가지고 있어 그걸로 판단하기보다 표준 문서로 판단해야
한다.

1. w3의 xhtml 문서는 권고안의 성격이 강합니다.
실제로 일정 이상의 예외적 상황을 브라우저가 자의적으로 해독하고,
특별한 문제가 없는한 태그를 해석해 냅니다.
(간단한 예로 <img>태그나 <br>태그가 닫히지 않는다 하더라도, 원하는데로 작동한다는 이야기 입니다.)

사실 표준에 맞게 코딩을 해야 하는건 맞습니다.
w3의 표준안을 따라 코딩이 된다는 것은, 크로스 브라우징에서 우위에 있게 된다는 뜻이기도 합니다.
(예외적 처리는, 해당 브라우저를 만드는 곳의 자의적 해석에 따르기 때문에, 어떤 상황에서는 모든 브라우저에서 동일한 처리를 할 수 없기 때문입니다)

심각한 예외상황이 아니라면, 어느정도의 융통성을 가져야 하지 않나 십습니다.
google도 html 4.01 표준을 통과못하거든요:)

2. 현재 문제는 IE 중점적으로 인터넷 환경이 이뤄져 왔고, 웹프로그래머들이 IE중점적 환경에서 배워왔으며, 표준안에 대한 이해가 적기 때문이 아닌가 싶습니다.
그렇기 때문에 IE에서 나오면 다른데서도 동일하게 나올거다라는 식의 제작이 되는거겠죠.

3. w3c의 문서 체크는 큰 문제가 없는것 같습니다.
<br/>와 <br />는 둘다 맞다고 알고 있었는데 아닌가요?

PS. 중간에 수정의 언급은 여러 포멧의 혼용과, 실제 글을 쓰는 상태에 따라 많은 차이가 있는것 같습니다.
직접 html을 집어넣는 plain이나 html 모드를 많은 분들이
이용하시다 보니 더 문제가 되는것 같습니다:)
이 경우에 대해 직접적인 check method를 만든다면,
페이지를 만들어 내는 시간이 상당히 느려질것 같은데요:)
해당경우도 매우 많을 테고요..

lifthrasiir의 이미지

d3m3vilurr wrote:

심각한 예외상황이 아니라면, 어느정도의 융통성을 가져야 하지 않나 십습니다.
google도 html 4.01 표준을 통과못하거든요:)

google의 경우 웹사이트 트래픽 때문에 그럴 가능성이 높은 걸로 알고 있습니다. 그래도 google은 표준을 통과하지는 못 하지만 웬만한 브라우저에서 같은 동작을 하도록 잘 만들어 놓았으니 다행이지만요.

- 토끼군

advanced의 이미지

최대한 따르라고 하는거지 꼭 validator 에 통과하기 위해
스트레스 받을 필요는 없다고 생각합니다

XHTML 1.0 strict 통과 하려면 얼마나 고생스러운데요(?)

그런 스트레스가 표준을 증오하는 웹 개발자를 한명 더 만들수도
있습니다(자꾸 오타가 -_-)

tasy의 이미지

예전에 학회 홈페이지 만들면서 (http://jaram.org) 이 XHTML valid 문제 때문에 같이 만들던 팀원들과 논쟁이 좀 있었습니다.
전 vaild하게 만들자가 요지였고, 다른 사람들은 처음에는 그럴필요 있냐가 요지었었는데, 어떻게 다들 설득시키게 되어서 xhtml vaild한 작업을 했었습니다.

그렇게 만들다보니 귀찮은 점은 있었지만(&같은건 정말로 ㅜㅜ) 이와 해놓고 보니 브라우저도 다양하게 지원하고 여러면에서 좋은 점이 많더군요.

w3c권고안을 지키는 것은 작은 웹사이트에 좀 더 많은 가능성을 부여하는 작업이라 생각합니다. 아무도 알 수 없는 미래를 대비하는 작업일 수도 있겠죠. 그런 의미에서 가능하다면 지키는게 좋지 않을까요?

그리고 그런 의미에서 생각해보면 자그만 문법적인 실수(수정해야겠지만)나 사용자에 의해서 어쩔 수 없이 발생하게 되는 실수 들은 크게 문제가 된다고 생각하지 않습니다. 대학 입학처럼 1점 차이라 문제가 생기는 것이 아니라 많은 사람들에게 보일 수 있다는 가능성을 유지하면 된다는 생각이 듭니다.

---------
Byeongweon Moon
http://tasy.jaram.org/blog
사랑하면 알게 되고 알면 보이나니 그때에 보이는 것은 전과 같지 않으리라.

익명 사용자의 이미지

적어도 w3c validator 를 “완벽”하게 만족하려면, 상당한 노력이 필요합니다. 제대로 된 국내 레퍼런스조차 없는 상황에서요. 일일이 수정해가며 몇 십번의 시행착오를 거쳐야 하죠. 게다가 단순 html 이 아닌 동적 구성일 경우, 로직 상의 문제나 기타 애매성으로 인해 그걸 더욱 지키기 힘들어지기도 합니다.

제 생각은, validator 는 validator 일 뿐입니다. 모두 통과하면 좋겠지만, 현실적으로 그게 생각보다 쉽지 않습니다. 웬만한 페이지 손수 타이핑 하면서 직접 만들고 테스트 해보신 분이라면 느꼈을 거에요. 더군다나 아직 table layout 을 즐겨 쓰는 국내 환경과 인식에서는 더 먼 일입니다.

아마 2~3 년 뒤 -_- 에는 그나마 표준 지키는 인식도 많이 보편화 되어 있지 않을까 합니다. 3년 전에 css 와 표준에 대해서 관심을 가졌고 일부에서도 얘기가 나왔었지만, 군에서 지내다 세상으로 나와보니 여전했습니다. 그나마.... 작년 말과 올해 들어서 국내에서도 그런 인식이 아주 조금씩은, 번지고 있더군요.

그러나... 위에서 말했듯이, 완벽하게 지키는 건 아직은 힘듭니다. 자료가 대부분 외국에 있고, 또한 지식이 덜 쌓였습니다. 게다가 그 상태에선 지킬려고 하면 짜증도 많이 나고요. 현업에서 일하는 분은 여러 가지 이유 + 변명으로 아마 신경 못 쓰는 경우가 상당하리라 봅니다.

중요한 것은, validator 통과보다는 웹 접근성이라던지, 유저 인터페이스 같은 게 현실적으로 더 주목해야 할 점이라는 것입니다. 기본적으로 지킬 정도의 w3c 표준을 준수한다면, 약간의 오류 정도는 크게 지장을 끼치지 않는 한, 감안하고 넘어갈 유연성이 필요하지 않나 합니다. html 이란 게 원래 태생적으로 그런 것이고, 적절한 타협점이 필요하겠죠...

Prentice의 이미지

W3C 관련 문서를 우리말로 번역한 사이트도 있지 않나요? KLDP BBS에서 링크를 본 것 같습니다.

오라일리 코알라책, 연어책만 있으면 XHTML strict 페이지를 만드는 것 쯤은 어렵지 않습니다. 번역본 나와있습니다.

익명 사용자의 이미지

페이지가 작고, 로직 구조가 간단하면 strict 도 쉽습니다만, 동적 출력코드가 섞이고 복잡한 구성이 되면 사소한 부분에서 위반을 하게 되더군요. 정말 사소한 부분들입니다. ol, ul 요소 내의 li 내에 div 를 위치하지 않게 된다던가하는 류의..

trio 사이트 번역은 뭔가 애매해서 잘 안보게 됩니다. 그리고 처음 표준 문서에 관심가지는 사람한테는 w3c spec 이 쥐약이더군요. 뭐랄까요... 구현을 위하는 개발자에게 있어선 꽤나 학술적이라 군더더기 정보가 많달까.. 기술 구현을 위한 메타 정보가 많아서 저로선 권하기 힘드네요. 저는 http://www.w3schools.com/ 에서 참고하고, 좀 더 자세한 spec 이 필요하면 w3c 를 들릅니다. 근데 국내에서 번역말고, 스스로 이해해서 소화한 사람이 쓴 레퍼런스 사이트는 과연 언제 만들어질까요? -a-;;

progcom의 이미지

W3C의 문서가 그렇게 난해한가요? 처음 볼때는 조금 정신 없어도, 2~3번쯤 보면 이해할 수준이라고 생각합니다. 사람마다 편차는 있겠지만요. 실제 전문을 읽어봐도, 그렇게 양이 많은 것도 아닙니다. HTML도 하나의 '언어'라고 생각하면, 프로그래밍 언어를 배우는 노력에 비하면 정말 적은 양의 노력만 기울여도 충분합니다.

많이 쓰다보면 DTD만 읽어서 표준에 맞출 수 있더군요. (물론 읽는 법은 익혀야하지만요)

yser wrote:

ol, ul 요소 내의 li 내에 div 를 위치하지 않게 된다던가하는 류의..

<li>의 내부 요소는 %flow;기 때문에, <div>를 위치해도, 위치하지 않아도 상관이 없을텐데요? 정확히 무슨 뜻인지 알고 싶네요. (%flow;는 %inline;을 포함하고, %inline은 #PCDATA (즉, & < >를 바꾼 문자열)을 그대로 쓸 수 있습니다)

익명 사용자의 이미지

ol
div
/div
li
/li
/ol

이런 형태의 예였습니다 ^^; 즉 ol 내에 li 바깥에 div 가 위치한거죠. 결국 이것 덕분에 프로그램 로직 부분을 더 손봐야 했습니다. 스킨 클래스를 만들어 쓰는데, 귀찮은 처리가 늘더군요. 저런 것 말고도 템플릿 이용자는 딴 경우도 겪지 않을까 합니다. 모아놓은 게 없어서 짚어서 내놓을만한 게 없네요.

w3c 문서는 제가 처음 그랬습니다. 영어라는 점도 일조했겠지만, 저는 그 페이지에 익숙해지는데 꽤나 긴 시간이 걸렸습니다. 브라우저의 dom 구현 문서는 찾아 보는게 쉬워도, 저 문서는 왠지 거부감이 들더군요. 레퍼런스로 쓰기엔 한 페이지에 주루룩 전부 다 나와버리는 게 좀 불편하기도 하고...

DTD.. 어림 눈 짐작으로 파악한 하는 수준입니다. ^^;; 저도 많이 부족해요.
나중엔 DTD 정의할 일도 생기지 않을까 해서 제대로 봐둘 필요도 있을 듯 한데..

웬만하면 validator 를 만족하는 걸 '최소한의 요구'로 생각하고 있지만, 실 프로젝트에서는... 생각하고 싶지 않네요. -_-; 개인 페이지라면 얼마든지 할 의욕이 있지만...