wystan's tales

내용 바로가기

사이드바 바로가기

댓글 바로가기

페이지 하단 바로가기

home

about

archive

theme

from web 2007-05-27

XHTML 이 어떤 마크업 언어이고, 어떤 한계를 가지고 있는지를 앞선 글에서 알아봤습니다. 그렇다면 HTML 대신 XHTML 을 사용하는 것은 과연 옳은 선택일까요? 이 주제에 관해서 포스팅하게 된 동기가 되었던 Tommy Olsson의 글 에서는 이 문제에 대해서 부정적인 입장을 취하고 있습니다. XHTML 이 실제로는 HTML 과 거의 동일하게 취급되므로 구태여 XHTML 을 사용할 필요가 없다는 주장이지요.

하지만 XHTML 을 이용한 홈페이지 와 블로그 를 만들고 운영하는 제 생각은 그와는 다릅니다. XHTML 이 HTML 대신 사용되는 것을 굳이 말릴 필요는 없다고 생각하거든요.

물론 이 문제에는 정답이 없습니다. 각자가 생각하고 판단해야 할 문제니까요. 그 판단을 돕기 위해서 각각의 주장에 대해서 자세히 설명하려는 것이 이 글의 목적입니다.

그리고 이 글은 XHTML 1.0과 HTML 4.01 규격을 비교하는데 중점을 두겠습니다. 하위 호환성을 보장할 수 없는 XHTML 1.1 규격을 특별한 목적 없이 사용해서 얻을 수 있는 것은 최신 규격을 지켰다는 심리적 만족 외에는 없다고 생각하므로 이 규격에 대해서는 언급하지 않겠습니다. 많은 사람들이 W3C 의 권고안, 즉 표준을 완전무결한 기준으로 받아들이는데 그런 생각은 W3C의 권위가 불러오는 함정이 될 수 있습니다.

먼저 Tommy Olsson의 글 을 일부 인용하겠습니다.

“ XHTML 과 HTML 중에서 어느 것을 선택해야 하는지에 관한 절대적 기준은 없으며, 이 문제에 관한 여러가지 기술적인 문제들을 생각했을때 간단히 답할 수 있는 문제가 아니다. 하지만 현실적으로 가장 호환성이 높은 W3C의 마지막 표준은 HTML 4.01이라 말할 수 있다. 당신이 실제로 HTML 로는 불가능한 XHTML 의 기능을 사용해야 하는 경우를 제외하면 기술적인 면에서 XHTML 을 사용해야 할 이유는 전혀 없다.” “ XHTML 을 사용해서 실익을 얻으려면 XHTML 과 HTML 의 근본적인 차이점을 이해해야 한다. 하지만 XHTML 을 제대로 사용하는 사이트를 이용할 수 있는 것은 전체 웹 사용자들의 일부일 뿐이다.” “일부 웹 디자이너와 개발자들은 XHTML 의 문법 규칙을 선호한다. 특정한 지침을 따른다면, XHTML 의 기술적인 면을 전혀 사용하지 않고서도 XHTML 의 문법을 사용할 수 있다. 이런 접근 방식에는 잠재적인 문제점이 있지만, 태그 대신 반드시 태그를 사용하기를 원한다면 그 방식을 따르면 된다.” “당신의 문서가 미래의 환경에서도 유효하려면(future-proofing) XHTML 과 HTML 에서 어느 것을 선택하느냐 보다 Transitional 대신 Strict DOCTYPE 을 사용하는 것이 훨씬 중요하다.”

“ XHTML 을 사용해서 실익을 얻으려면 XHTML 과 HTML 의 근본적인 차이점을 이해해야 한다. 하지만 XHTML 을 제대로 사용하는 사이트를 이용할 수 있는 것은 전체 웹 사용자들의 일부일 뿐이다.”

“일부 웹 디자이너와 개발자들은 XHTML 의 문법 규칙을 선호한다. 특정한 지침을 따른다면, XHTML 의 기술적인 면을 전혀 사용하지 않고서도 XHTML 의 문법을 사용할 수 있다. 이런 접근 방식에는 잠재적인 문제점이 있지만, 태그 대신 반드시 태그를 사용하기를 원한다면 그 방식을 따르면 된다.”

“당신의 문서가 미래의 환경에서도 유효하려면(future-proofing) XHTML 과 HTML 에서 어느 것을 선택하느냐 보다 Transitional 대신 Strict DOCTYPE 을 사용하는 것이 훨씬 중요하다.”

그의 주장의 바탕이 되는 이유는 앞선 글에서 설명했던 브라우저의 XHTML 호환성 문제 때문인데 이에 관한 설명은 브라우저가 XHTML 을 해석하는 방식 을 참고하시기 바랍니다.

마지막 문장에 대해서는 XHTML 과 HTML 의 차이 에서 이미 다루었지만, 중요한 의미가 있어서 다시 한번 짚고 넘어가겠습니다.

많은 사람들이 XHTML 을 사용하면 문서의 ‘구조’ 와 ‘표현’ 을 HTML 보다 잘 분리해서 보다 ‘의미 있는’ 마크업을 할 수 있다고 생각하지만 이것은 사실이 아닙니다. 이런 면에서 두 규격은 서로 대등하니까요. 동일한 Strict DTD 로 정의된 XHTML 1.0과 HTML 4.01 문서는 사용할 수 있는 요소(element)와 속성(attribute)에 차이가 거의 없습니다. 단지 태그 대신 태그를 사용하는 것처럼 문법 규칙이 다를 뿐이지요.

CSS 를 사용하는 것도 마찬가지입니다. XHTML 과 HTML 모두 동일하게 적용되지요. 그러므로 XHTML 로 가능한 문서의 ‘구조’ 와 ‘표현’ 의 분리는 HTML 로도 똑같이 할 수 있습니다 .

하지만 점점 더 많은 사람들이 HTML 대신 XHTML 을 사용해야 한다고 주장합니다. Tommy Olsson은 그 이유를 다음과 같이 밝히고 있지요.

“많은 웹 디자이너와 개발자들이 XHTML 1.0의 발표에 환호했다. XHTML 은 당시에 크게 유행했던 XML 이었고 HTML 처럼 쉽게 사용할 수 있었으며 모든 브라우저에서 잘 동작했다. 사람들은 XHTML 의 확장성에서 많은 가능성을 발견했고, W3C가 더 이상의 HTML 규격은 아마도 없을 것이라고 발표하면서 XHTML 이 미래 환경을 위한 유일한 대안이라고 생각하게 되었다.” “시간이 흐르면서 XHTML 사용의 문제점과 확장성의 한계가 밝혀졌지만 XHTML 에 대한 장밋빛 환상만큼 널리 알려지지는 않았다. 이 사실을 알지 못하거나 개인적인 선호 때문에 많은 사람들은 여전히 HTML 보다는 XHTML 을 사용해야 한다고 주장하고 있다.”

“시간이 흐르면서 XHTML 사용의 문제점과 확장성의 한계가 밝혀졌지만 XHTML 에 대한 장밋빛 환상만큼 널리 알려지지는 않았다. 이 사실을 알지 못하거나 개인적인 선호 때문에 많은 사람들은 여전히 HTML 보다는 XHTML 을 사용해야 한다고 주장하고 있다.”

여기서 말하는 XHTML 은 XML 의 기능이 사용되지 않아서 HTML 로도 충분히 처리가 가능한 마크업을 말합니다. XML 의 기능이 꼭 필요하다면 당연히 XHTML 을 사용해야겠지요. 하지만 이 글을 읽으시는 분들 중에서 XML 을 사용했기 때문에 인터넷 익스플로러로는 접근할 수 없는 그런 페이지를 단 한번이라도 보신 적이 있는지요?

† 인용한 문장에서는 HTML 4.01이 W3C의 마지막 HTML 표준이 될 것이라 생각하는데, 이것은 Tommy Olsson의 원문이 2006년 6월에 씌여졌기 때문입니다. 현재 W3C에서는 HTML 5 와 XHTML 5를 위한 워킹 그룹이 새로운 표준의 밑그림을 그리고 있습니다. HTML 5는 애플 , 모질라 , 오페라 진영의 사람들이 모여서 설립한 WHATWG 에서 자신들이 개발중인 규격을 W3C의 새로운 HTML 규격을 위한 초안으로 채택해줄 것을 제안했고, W3C가 이 제안을 받아들이면서 세상에 그 이름을 알리게 되었습니다(2007년 5월). 현재 이 워킹 그룹의 편집 책임자는 구글 의 Ian Hickson과 애플 의 David Hyatt입니다.

Tommy Olsson은 XHTML 이 HTML 과 다를 바 없으므로 HTML 을 사용하는 것이 더 나은 선택이라고 주장합니다. 하지만 역설적으로 그렇기 때문에 XHTML 을 사용하는 것이 아닐까요? 다시 말해서 HTML 대신 XHTML 을 사용해서 얻을 수 있는 이점은 없지만, 그렇다고 해서 특별히 단점이 있는 것도 아니니까요.

XHTML 을 HTML 처럼 사용하는 것이 잠재적인 문제점(potential pitfall)을 안고 있다고 하지만 그것은 어디까지나 브라우저 같은 사용자 에이전트(user agent)의 내부적인 처리 방식의 문제입니다. 결과적으로 XHTML 은 HTML 과의 호환성을 유지하고, XHTML 문법 규칙은 혼란을 일으키지 않을 만큼 충분히 명확하기 때문에 사용자에게는 아무런 문제가 되지 않습니다.

또한 XHTML 을 사용하면 HTML 보다 양식화된(well-formed) 문서 를 작성할 수 있는데 이것은 브라우저가 아닌 사용자 입장에서 특히 유익합니다. 브라우저는 태그가 없어도 문단이 어디서 끝나는지 명확하게 알 수 있지만, 사용자는 그것을 알기가 어려우니까요.

물론 HTML 을 사용해도 동일하게 양식화(well-formed)된 문서를 작성할 수 있습니다. 태그는 생략할 수 있는 것이지 생략해야 하는 것이 아니기 때문입니다. 하지만 XHTML 을 사용하면 마크업 검증기(validator)가 문서의 양식을 더 꼼꼼하게 확인합니다. 따라서 XHTML 마크업을 작성하고 검증해보는 것이 양식화된 마크업을 익히는데 유리합니다.

미래의 웹 환경이 어떻게 달라질지 예상하는 것은 어렵습니다. 하지만 단시일 내에 모든 브라우저들이 완벽하게 XML 을 지원하리라고는 믿지 않습니다. 개인적으로는 XHTML 문서를 나타내는 .xhtml 확장자가 지금의 .html 확장자 만큼 익숙해져야 XHTML 문서가 그 힘을 발휘할 수 있다고 생각하는데 그 때를 대비해서 XHTML 을 써야한다고 주장하는 것이 아닙니다. 앞서 말씀드렸듯이 지금 작성되는 대부분의 XHTML 문서에는 XML 만의 기능이 들어가 있지 않으니까요. XHTML 의 하위 호환성을 고려했을 때 HTML 대신 사용해도 무방 하다는 것이 제 의견의 요지입니다.

XHTML 과 HTML 규격의 차이점을 다루는 글을 쓰게 된 동기는 ‘웹 표준’ 과 XHTML 사용을 동일하게 받아들이는 일부의 시각 때문입니다. HTML 4.01 규격도 엄연히 W3C가 제정한 표준 권고안임에도 불구하고 XHTML 과 CSS 를 사용해야만 웹 표준을 지킬 수 있고, 그것이 무조건 더 좋은 방법이라고 생각하는 분들이 있는데 절대적으로 틀린 생각입니다.

웹 표준을 잘 지키고 그 장점을 누리기 위해서는 XHTML 과 HTML 의 차이가 아니라 Strict와 Transitional DTD 의 차이를 아는 것이 훨씬 더 중요 합니다. 이 주제에 관해서는 나중에 다루도록 하고, XHTML 과 HTML 규격의 차이점에 관한 글은 이것으로 모두 마칩니다.

XHTML 과 HTML 의 차이

브라우저가 XHTML 을 해석하는 방식

XHTML 1.1 규격의 용도와 호환성

XHTML 을 사용하는 이유

댓글 8개가 달렸습니다. 태그: W3C , web standard , XHTML

1UP | 2007-05-27 16:55 두루뭉술한 마크업도 포용하는 HTML 에 비해 보다 명확하고, 군더기 살 없이 날씬한 XHTML 이 더 섹시하게 느껴져요. 게다가 저는 XHTML 로 넘어오지 않았더라면 아직까지도 의미없는 마크업을 남발했을지 모르기 때문에 XHTML 에 한표를 줄 수 밖에 없어요.ㅋㅋ

두루뭉술한 마크업도 포용하는 HTML 에 비해 보다 명확하고, 군더기 살 없이 날씬한 XHTML 이 더 섹시하게 느껴져요. 게다가 저는 XHTML 로 넘어오지 않았더라면 아직까지도 의미없는 마크업을 남발했을지 모르기 때문에 XHTML 에 한표를 줄 수 밖에 없어요.ㅋㅋ

wystan | 2007-05-27 18:07 재밌는 비유네요~ ^^ 저는 XHTML 로 홈페이지를 만들면서 직접 태그를 마크업하는 즐거움을 알았습니다. 문서의 ‘표현’ 에 사용되던 요소들을 모두 분리시켰기 때문에 가능한 일이었지요. 물론 HTML 로도 같은 효과를 얻을 수 있지만, 기존의 방식에 익숙한 분들에게는 이런 전환이 쉽지 않았을 겁니다. 새롭기 때문에 새로운 방법과 함께 사용되어야 할 것 같은 느낌을 주는 것이 웹 표준의 관점에서 XHTML 이 갖는 장점이 아닐까 생각합니다.

재밌는 비유네요~ ^^

저는 XHTML 로 홈페이지를 만들면서 직접 태그를 마크업하는 즐거움을 알았습니다. 문서의 ‘표현’ 에 사용되던 요소들을 모두 분리시켰기 때문에 가능한 일이었지요.

물론 HTML 로도 같은 효과를 얻을 수 있지만, 기존의 방식에 익숙한 분들에게는 이런 전환이 쉽지 않았을 겁니다. 새롭기 때문에 새로운 방법과 함께 사용되어야 할 것 같은 느낌을 주는 것이 웹 표준의 관점에서 XHTML 이 갖는 장점이 아닐까 생각합니다.

vervain | 2007-06-08 23:47 좋은 글이네요. 현재 웹 표준, 접근성하는 많은 의미들이 단지 “View”의 관점에서만 접근하고 있다는 점도 조금 안타까운 점입니다. 가장 마지막으로 어떤 대상의 의미를 해석하는 것은 우리의 생각입니다. 그러한 우리의 인지까지 접근하는 경로는 비단 보는 방법만이 있는 것이 아니죠. 그런 의미에서 넷상에 돌아 다니고 있는 많은 “정보”가 우리에게 받아 들여지기 까지의 경로중 이용되는 수 많은 도구와 규칙을 가지고 인지까지 이루어 내기 위해 고려된 방법들이 단지 몇 가지 메인 스트림에 집중되고 있다는게 중요한 문제인 것을 단지 보이는 것의 “통일성”에 집중하고 있는 인식이 안타깝습니다. 표준은 궁극적으로 인지의 통일성을 이루어 내기 위해 존재한다는 점을 많은 사람들이 깨닫고 고민하였으면 하는 바램입니다.

좋은 글이네요.

현재 웹 표준, 접근성하는 많은 의미들이 단지 “View”의 관점에서만 접근하고 있다는 점도 조금 안타까운 점입니다.

가장 마지막으로 어떤 대상의 의미를 해석하는 것은 우리의 생각입니다. 그러한 우리의 인지까지 접근하는 경로는 비단 보는 방법만이 있는 것이 아니죠. 그런 의미에서 넷상에 돌아 다니고 있는 많은 “정보”가 우리에게 받아 들여지기 까지의 경로중 이용되는 수 많은 도구와 규칙을 가지고 인지까지 이루어 내기 위해 고려된 방법들이 단지 몇 가지 메인 스트림에 집중되고 있다는게 중요한 문제인 것을 단지 보이는 것의 “통일성”에 집중하고 있는 인식이 안타깝습니다. 표준은 궁극적으로 인지의 통일성을 이루어 내기 위해 존재한다는 점을 많은 사람들이 깨닫고 고민하였으면 하는 바램입니다.

wystan | 2007-06-11 02:25 메인 스트림에 집중하는 이유는 그것이 메인 스트림이기 때문이 아닐까요? :-) 일반적인 경제 논리로 이해한다면 당연한 일이겠지만, 현대 사회의 정보화에 있어서 웹이 차지하는 위상을 생각한다면 잘못된 시각임이 분명합니다. 웹의 창시자로 알려져 있는 팀 버너스 리(Tim Berners Lee)가 특허를 신청하지 않았던 이유도 공익적인 가치 때문이라고 하더군요. W3C가 ‘평등한 웹’ 을 목표로 만든 표준도 그런 의미에서 당위성을 갖는다고 생각합니다. 그들의 고심이 담긴 작품이라고 볼 수 있겠지요. 하지만 많은 사람들이 ‘웹 표준’ 과 ‘접근성’ 이라는 용어에 담긴 의미를 너무 쉽게 받아들인다는 생각이 듭니다. 유효한 마크업을 하고(valid html) 접근성을 향상시킬 수 있는 몇 가지 기법을 적용했다고 해서 “웹 표준을 준수했습니다.” 라고 말하기보다는 “웹 표준을 지키려고 노력했습니다.” 라는 표현이 훨씬 더 적합하지 않을까 생각한답니다. 진정한 웹 표준을 지키기 위해서는 기술적인 문제보다 열린 마음이 더 중요하다고 생각합니다. 물론 쉬운 일은 아니겠지요. 하나의 유행이 아닌 ‘평등’ 의 관점에서 웹 표준을 받아들이는 것이 그 시작이 아닐까 싶습니다.

메인 스트림에 집중하는 이유는 그것이 메인 스트림이기 때문이 아닐까요? :-) 일반적인 경제 논리로 이해한다면 당연한 일이겠지만, 현대 사회의 정보화에 있어서 웹이 차지하는 위상을 생각한다면 잘못된 시각임이 분명합니다. 웹의 창시자로 알려져 있는 팀 버너스 리(Tim Berners Lee)가 특허를 신청하지 않았던 이유도 공익적인 가치 때문이라고 하더군요.

W3C가 ‘평등한 웹’ 을 목표로 만든 표준도 그런 의미에서 당위성을 갖는다고 생각합니다. 그들의 고심이 담긴 작품이라고 볼 수 있겠지요.

하지만 많은 사람들이 ‘웹 표준’ 과 ‘접근성’ 이라는 용어에 담긴 의미를 너무 쉽게 받아들인다는 생각이 듭니다. 유효한 마크업을 하고(valid html) 접근성을 향상시킬 수 있는 몇 가지 기법을 적용했다고 해서 “웹 표준을 준수했습니다.” 라고 말하기보다는 “웹 표준을 지키려고 노력했습니다.” 라는 표현이 훨씬 더 적합하지 않을까 생각한답니다.

진정한 웹 표준을 지키기 위해서는 기술적인 문제보다 열린 마음이 더 중요하다고 생각합니다. 물론 쉬운 일은 아니겠지요. 하나의 유행이 아닌 ‘평등’ 의 관점에서 웹 표준을 받아들이는 것이 그 시작이 아닐까 싶습니다.

부침개 | 2007-11-23 22:49 한때 저는 "HTML 방식으로 마크업을 했을때 <img />, , <input /> 등의 태그작성이 DOCTYPE 가 HTML 에서 XHTML 로 바뀌면 일일히 다 어떻게 바꿔주나... 그러니 상위호환성을 위해 DOCTYPE 가 HTML 이라도 /> 이렇게 작성하는게 좋겠어" 라고 생각했었는데 요즘 나오는 에디터툴들은 DOCTYPE 가 바뀜에따라 작성된 마크업의 코드가 자동으로 바뀐다고 하더라구요 제가 알아본 툴은 드림위버 8 이였습니다. 시간이 지남에따라 기술은 이런 우려했던 것들을 조금씩 고쳐나가고 있나봅니다. 그래도 저는 되도록이면 HTML 을 사용하기보단 XHTML 을 사용하자고 주장하는 편입니다. 이유는 저도 위스턴님과 비슷하구요 표준웹을 말하면 HTML 도 충분히 가능하죠, 안타까운것은 회사에서는 아직까지 Quirks Mode 로 마크업 하고있는 일들이 꽤 많습니다. 아마도 HTML마크업과 웹개발 그리고 디자인분야 모두가 공감을 가질려면 예전 테이블 마크업을 왠만한 웹직업자들이 구사할 수 있었던 때 만큼의 시간이 흘러야하지 않을까 생각되네요.. 지금 제 바램은 작년 HTML5 의 Working Draft 진행과정과 바뀌는 스팩과 추가되는 기능들을 들었던적이 있었는데 정말 CSS3 못지않게 빨리 Recommendation 이 되었으면 좋겠다는 생각입니다. :)

한때 저는 "HTML 방식으로 마크업을 했을때 <img />, , <input /> 등의 태그작성이 DOCTYPE 가 HTML 에서 XHTML 로 바뀌면 일일히 다 어떻게 바꿔주나... 그러니 상위호환성을 위해 DOCTYPE 가 HTML 이라도 /> 이렇게 작성하는게 좋겠어" 라고 생각했었는데 요즘 나오는 에디터툴들은 DOCTYPE 가 바뀜에따라 작성된 마크업의 코드가 자동으로 바뀐다고 하더라구요 제가 알아본 툴은 드림위버 8 이였습니다.

시간이 지남에따라 기술은 이런 우려했던 것들을 조금씩 고쳐나가고 있나봅니다. 그래도 저는 되도록이면 HTML 을 사용하기보단 XHTML 을 사용하자고 주장하는 편입니다.

이유는 저도 위스턴님과 비슷하구요 표준웹을 말하면 HTML 도 충분히 가능하죠, 안타까운것은 회사에서는 아직까지 Quirks Mode 로 마크업 하고있는 일들이 꽤 많습니다. 아마도 HTML마크업과 웹개발 그리고 디자인분야 모두가 공감을 가질려면 예전 테이블 마크업을 왠만한 웹직업자들이 구사할 수 있었던 때 만큼의 시간이 흘러야하지 않을까 생각되네요..

지금 제 바램은 작년 HTML5 의 Working Draft 진행과정과 바뀌는 스팩과 추가되는 기능들을 들었던적이 있었는데 정말 CSS3 못지않게 빨리 Recommendation 이 되었으면 좋겠다는 생각입니다. :)

wystan | 2007-11-25 09:26 요즘에는 XHTML에 너무 익숙해져서 HTML 문서에도 습관적으로 closing tag를 넣고는 합니다. ^^; 현재 작성하는 대부분의 문서가 XHTML이어서 문제가 되는 경우는 별로 없지만 XHTML 대신 HTML5를 사용해야 한다면 또 틀려지겠지요. 저 역시도 HTML5에 많은 기대를 갖고 있습니다. 애플, 모질라, 오페라 진영에서 주도적으로 참여하고 있다는 사실만으로도 관심을 끌기에 충분하다고 생각해요. 빨리 Recommendation되고, 주요 브라우저들이 그 규격을 제대로 지원하기만 하면 마크업의 표현 영역이 지금보다 훨씬 넓어지겠지요. 무엇보다 웹이 끊임없이 발전하고 있다는 사실이 설레임을 갖게 만듭니다.

요즘에는 XHTML에 너무 익숙해져서 HTML 문서에도 습관적으로 closing tag를 넣고는 합니다. ^^; 현재 작성하는 대부분의 문서가 XHTML이어서 문제가 되는 경우는 별로 없지만 XHTML 대신 HTML5를 사용해야 한다면 또 틀려지겠지요.

저 역시도 HTML5에 많은 기대를 갖고 있습니다. 애플, 모질라, 오페라 진영에서 주도적으로 참여하고 있다는 사실만으로도 관심을 끌기에 충분하다고 생각해요. 빨리 Recommendation되고, 주요 브라우저들이 그 규격을 제대로 지원하기만 하면 마크업의 표현 영역이 지금보다 훨씬 넓어지겠지요.

무엇보다 웹이 끊임없이 발전하고 있다는 사실이 설레임을 갖게 만듭니다.

javarouka | 2012-04-17 14:45 좋은글 잘 읽었습니다. 4부작(?)으로 쓰여진 글을 빨려들어가듯 읽었네요. 그런데 아직 XHTML의 장점이 궁금하군요. XHTML에서만 지원하는 기능이라는게 구체적으로 뭔지 예를 들어주실 수 있으신지…

좋은글 잘 읽었습니다. 4부작(?)으로 쓰여진 글을 빨려들어가듯 읽었네요.

그런데 아직 XHTML의 장점이 궁금하군요. XHTML에서만 지원하는 기능이라는게 구체적으로 뭔지 예를 들어주실 수 있으신지…

커피요쿠르트 | 2014-03-04 13:51 좋은 글 잘 읽었습니다. 시간이 흘렀지만 여전히 가치가 있네요. 고맙습니다. ^^

좋은 글 잘 읽었습니다. 시간이 흘렀지만 여전히 가치가 있네요. 고맙습니다. ^^

댓글이 닫혔습니다.

◀ previous | next ▶

blogging

misc

ultima

web

javascript

[JavaScript] 굉장한 자바스크립트 강좌(영문) 소개

[CSS3] 미디어 쿼리(Media Query)의 only 키워드

CSS 이야기: position, float, display 속성간의 관계

CSS 이야기: overflow 속성의 float 해제 효과

CSS 이야기: 마진 병합(collapsing margins)

아들부자 (컨텐츠 관리 시스템(CMS) 소개)

성민장군 (CSS 이야기: “규격을 따른다”라는 표현의 의미(conformance))

웹디자인 강좌 ([CSS3] 미디어 쿼리(Media Query)의 only 키워드)

cartes (CSS 이야기: CSS 2.1과 2의 관계)

아슈 (CSS 이야기: “규격을 따른다”라는 표현의 의미(conformance))

Textpattern

TextBook

Txp Resources

TXP Forum

울티마 가이드

valid XHTML

valid CSS

under CCL

페이지 상단 바로가기