WHATWG FAQ

WHATWG의 FAQ 일어로 번역한 문서를 재번역한 문서입니다. 원문에서 최근에 추가된 내용과 일부 내용은 원문을 참고하여 재번역하기도 했습니다. 또한, 본 문서는 수시로 변경될 수 있습니다. 정확한 내용을 확인하기 위해서는 가급적 원문을 함께 참고해 주세요.

개요

WHATWG가 공개하고 있는 HTML5의FAQ입니다. HTML5의 목적이나 존재 의미 같은 큰 주제부터 요소의 작성방법같은 세세한 얘기까지, 다양한 방면의 질문에 답하고 있습니다.

차례

1 WHATWG

1.1 WHATWG 란 무엇입니까?

웹 하이퍼 텍스트 애플리케이션 테크놀로지 워킹그룹The Web Hypertext Application Technology Working Group(WHATWG은 웹 개발에 관심이 있는 사람들이 모여서 만든 커뮤니티입니다. 주로 HTML과 웹 애플리케이션에 필요한 API 개발에 초점이 맞춰져 있습니다.

WHATWG은 2004년에 W3C 워크샵 후에 Apple, Mozilla Foundation, Opera Software의 몇몇 사람들에 의해서 설립되었습니다. Apple, Mozilla, Opera는 W3C의 XHTML의 방향성, HTML로의 관심의 부족, 현실에서 웹 제작자의 목소리에 대한 무관심을 우려하기 시작했습니다. 그로 인해 3사는 이러한 우려를 해결하기 위한 임무에 착수하였고 The Web Hypertext Application Technology Working Group이 탄생하였습니다.

1.2 WHATWG는 무엇을 하는 곳입니까?

WHATWG는 주로 HTML5에 초점이 맞춰져 있습니다. WHATWG는 Web Workers와 관련된 일도 하고 있습니다. 때로는 WHATWG의 영역 외의 일이 WHATWG의 메일링 리스트에서 의논되는 경우도 있습니다만 적절한 것이라면 답장을 하기도 합니다.

이전에는 Web Forms 2.0과 Web Controls 1.0에도 집중했었습니다. Web Forms 2.0은 HTML5에 통합되었고 Web Controls 1.0은 현재 버려졌습니다. XBL 2.0이 우리에게 어떠한 것을 가져올지를 기다리고 있습니다.

1.3 어떻게 하면 참가할 수 있습니까?

다양한 방법이 있습니다. What you can do를 참고해 주시길 바랍니다.

1.4 무료로 참가 할수있습니까?

네. 누구나 무료로 참여할 수 있습니다. 참가에 관해서 회원 비용은 필요 없으며 절차가 공개되어 있습니다. 간단하게 WHATWG 메일링 리스트를 신청할 수 있습니다. 또한 복잡한 절차를 거쳐야 하지만 W3C의 새로운 HTMLWG에 참가할 수도 있습니다.

2 WHATWG의 프로세스

2.1 WHATWG는 어떻게 활동하고 있습니까?

메일링 리스트에 메일을 보냅니다. 에디터는 그 피드백을 읽고 조사나 연구를 합니다. 다양한 리소스(블로그, 포럼, IRC등)를 참고로 검증하고, 언어의 일관성을 유지하면서 가능한 많은 사람의 요구를 수용하면서 언어를 설계합니다.

이것은 피드백이 올 때마다 반복됩니다. 그리고 에디터가 더 이상 사양을 갱신할 필요가 없다고 판단할 때까지 계속됩니다. (예를 들어 두사람이 상반된 요청을 할 경우에는, 에디터는 입수 가능한 모든 정보를 고려해서 두개의 제안 중 어느 쪽이 나은가를 판단합니다.)

이것은 대다수의 합의에 의한 접근은 아닙니다. 모두가 만족할 수 있다는 보증도 없습니다. 또한 투표 같은 것도 없습니다.

만약 에디터가 잘못된 판단을 내릴 경우엔 그 에디터를 교체할 권리를 가진 작은 감시위원회(“WHATWG members”로 알려져 있습니다 charter를 참고해주세요.)가 있습니다.

현재의 에디터는 Ian Hickson 입니다.

2.2 툴 개발자, 스크린리더 개발자, 브라우저 벤더, 검색엔진 벤더, 그 밖의 실무자는 어떤식으로 WHATWG에 관여해야 할까요?

기능에 관련된 피드백은 whatwg@whatwg.org(사전에 메일링리스트에 참가해야 합니다) 또는 ian@hixie.ch에 보내주세요. 모든 피드백은 오래지 않아 답장드립니다.

혹시, 당신이 어떤 기능에 관련된 일을 하려고 이전의 모든 피드백을 고려하기 위해 사양을 업데이트할 필요가 있다고 판단되어 가능한 빨리 취급해 줬으면 하는 경우에는 에디터(ian@hixie.ch)에게도 메일을 보내서 알리거나 IRC(Freenode에서는 HIxie)에서 그를 만날 수 있습니다.

피드백을 다루는 내용에 대해서는 외부에 알리지 않습니다. 당신이 그 기능에 관여하고 있다는 것을 다른 브라우저 벤더가 아는 일은 없을 것입니다.

확인을 위한 질문이나 요청은 메일링리스트나 IRC(Freenode의 #whatwg 채널)에 문의 해주세요.

2.3 사양에서 나쁜 아이디어를 제외시키는 프로세스는 있습니까?

사양에서 나쁜 아이디어를 제거하는 프로세스가 있습니다.

  • 일상적으로 특별히 확실한 코멘트가 요청되면 우리들은 모든 섹션을 조사해서 제거할 필요가 있는 것으로 표시 합니다. 예를 들면 이러한 문제는 2008년 초에 데이터 템플릿, 블럭 반복, DFN 요소의 상호 참조에서 발생했었습니다.
  • 그러한 기능들을 가지고 있어야만 하는 강력한 이유가 없다면 그것들은 최종적으로 정리되어 제거 됩니다.
  • 누구나 기능의 제거를 요청할 수 있습니다. 그러한 피드백은 다른 모든 피드백과 동일하게 취급됩니다. 그리고 제출된 근거의 메리트에 근거합니다. 브라우저가 폭넓게 기능을 탑재하고 있지 않다면 혹은 웹 제작자가 그 기능을 사용하지 않는다거나, 그 기능의 이용이 논리적이지 않고 근본적으로 틀려서 피해를 일으킨다면 검사 후에 그 기능은 제거됩니다.

기능의 제거는 사양 개발에서 중요한 부분입니다.

2.4 사양에 새로운 기능을 추가시키는 프로세스는 있습니까?

이 프로세스는 상당히 변칙적입니다만, 기본적으로는 요약하면 다음과 같습니다:

  1. 웹 제작자 또는 실무자와 그 문제를 의논해 주세요. 이용사례와 요건을 조사해주세요.
  2. 해결해야 하는 문제의 명확한 설명을 생각해주세요.
  3. 당신의 제안을 웹 제작자나 실무자와 의논해주세요.
  4. 답신을 읽고 피드백에 귀를 기울여주세요. 당신의 아이디어가 이용사례나 요건에 대해 좋은 해결책인가를 검사해주세요.
  5. 여기서의 의논은 공개로 이루어져야 합니다. 예를 들면 아카이브될 수 있는 공개 메일링 리스트나 블로그에 게시되는 등.
  6. 실무자에게 그 기능을 구현하는 것을 승인 받아 주세요.
  7. 혹시 당신이 여러명의 실무자에게 그 기능의 구현을 부탁하기 어려운 경우에는 실험적으로 최소한 하나의 사용자 에이전트로부터 구현을 하도록하여 주세요. 실험적인 구현은 공식적으로 이용 가능해야 합니다.

그 실질적인 구현이 에디터의 주목을 받을 수 있도록 하여 주세요. 그 경험으로부터 얻은 정보를 문서화하여 어느 실무자든지 알 수 있도록 해 주세요. 이용사례, 초기단계에서 발견된 요건 등 그 설계가 의존하고 있는 데이터입니다. 그 문제의 중요성을 시연해주세요. 그 해결책이 당초의 문제를 해결하기에 충분히 올바르게, 그리고 널리 이용될 수 있음을 시연해주세요. 그 후에도 계속해서, 그 제안의 모든 것을 신중히 검토해 주세요. 그리고 그 설계에 관한 논의에 참가해 주세요. 일반적으로 이 단계에서 당초의 설계는 무너지고 정말로 좋은 설계가 개발됩니다. 이전의 조사, 최신의 조사, 구현, 실험적인 구현 등을 통한 웹 제작자의 경험을 통해 통지됩니다. 경우에 따라서는 그 아이디어는 이 단계에서 삭제 될 수도 있습니다.

아이디어가 앞서 언급한 프로세스를 거쳐 남았다면, 최종적으로, 사양은 그 아이디어를 반영한 것으로 업데이트 됩니다. 그 시점에서 구현은 새로운 설계를 반영하도록 업데이트될 것입니다. (만약 그렇지 않다면, 그것은 새로운 설계가 좋지 않다는 것을 의미하는 것이므로 그 설계는 수정되거나 제거될 것입니다.) 사양은 웹 제작자나 실무자에 의해 발견된 많은 문제를 수정하면서 업데이트 됩니다. 몇 년의 기간에 걸쳐 더 많은 웹제작자나 실무자가 그 설계를 음미 하게 됩니다. 최종적으로 많은 구현이 널리 퍼지게 됩니다. 이 시점에서 그 기능의 개발은 일단 종료된 것입니다.

포괄적인 테스트 시트를 작성하는 것도 중요한 단계입니다. 그것은 사양에 쓰여진 것이 구현되기 조금 전에 시작하지 않으면 안됩니다. (테스트 시트는 보통 그들이 사양을 사용해서 하는 것과 같은 만큼, 구현을 이용한 많은 문제를 발견합니다.) 우리들은 테스트 시트에 대해서 아직까지 좋은 얘기를 들어본 적이 없습니다. 당신이 우리를 도와 주실려면, 메일리스트를 통해 알려 주시면 좋겠습니다! 하지만 그것은 엄청난 일이 될 것이기 때문에 양해해주시기 바랍니다.

3 HTML5

3.1 HTML5란 무었입니까?

HTML5는 WHATWG 커뮤니티가 주로 다루고 있는 것으로, W3C HTML Working Group도 마찬가지 입니다. HTML5는 HTML4와 XHTML1과 DOM Level 2 HTML의 신버젼입니다. 이러한 사양들의 많은 문제의 해결을 목표로 작업 중에 있습니다. 아울러 웹 애플리케이션을 보다 적절하게 사용할 수 있도록 (X)HTML을 확장하고 있습니다. HTML(HTML5)과 XML(XHTML5)의 어느 쪽이든지 쓸 수 있는 마크업 언어를 정의할 뿐 아니라, 웹 아키텍쳐의 기본적인 부분부터 많은 API도 정의하고 있습니다. 이러한 API중 몇몇은 DOM Level 0 으로 알려진 것들입니다만 아직 문서화 되지는 않았습니다. 이것들은 브라우저 벤더가 현존하는 웹 콘텐츠를 지원하고 웹 제작자가 웹 애플리케이션을 구축 할 수 있도록 한다는 측면에서 매우 중요합니다.

3.2 어떻게 하면 사양의 갱신을 알 수 있습니까?

사양에 변경 내용을 추적하는 방법에는 여러 가지가 있습니다.

3.3 사양의 여러 버전은 무엇입니까?

WHATWG의 모든 활동은(아주 큰) Web Applications 1.0 문서에서 수집됩니다.

WHATWG HTML은 HTML 사양의 부분일 뿐입니다. 이것은 A4 레터 타입의 PDF에서 뿐 아니라 single-page multi-page에서도 유효합니다.

개별 사양에 대한 표:

WHATWG Specifications (and sections therein) Section links for Web Applications 1.0 W3C/IETF Specifications
HTML5 only (excluding newer features) Single-page, Multi-page(HTMLWG)
Microdata 2 In WHATWG HTML Microdata Microdata (HTMLWG)
2D Context 3 In WHATWG HTML 2D Context 2D Context (HTMLWG)
Communications – Cross-document messaging 4 In WHATWG HTML Cross-document messaging Communications (HTMLWG)
Communications – Channel messaging In WHATWG HTML Channel messaging Communications (HTMLWG)
Device Element In WHATWG HTML Device HTML Device (HTMLWG)
Web Workers 5 Web Workers specification Web Workers Web Workers (WebApps WG)
Web Storage Web Storage Web Storage (WebApps WG)
Web Sockets API 6 Web Sockets API Web Sockets API (WebApps WG)
Web Sockets Protocol Web Sockets Protocol The Web Socket Protocol (IETF)
Server-Sent Events 7 Server-sent Events Server-sent Events (WebApps WG)
Web SQL Database (stalled) 8 Web SQL Database (WebApps WG)

위 내용은 소스 문서를 통해서 정리된 것입니다.

3.4 사양의 버전은 제작자에게 특화되어 있는 버전인가 아니면 구현자에게 특화되어 있는 버전인가?

제작자author 9 아니면 구현자implementor 10에게 특화되어 있는 사양이란 없습니다. 그러나 WHATWG HTML 그리고 HTML5 사양은 사용자-에이전트-특화요소를 강조하거나 숨기는 등 변경하는 것이 가능합니다. 이런 모드는 문서의 우측 상단에 있는 라디오 버튼을 통하여 선택이 가능합니다.

URL을 바꿈으로 인해 모드를 변경할 수 있으며, 다수의 페이지의 WHATWG HTML 사양을 위한 사례는 여기 있습니다:

3.5 우리는 언제 새로운 기능들을 사용할 수 있습니까?

이제 기능 중 일부는 사용할 수 있습니다. 이외의 것들은 폭넓게 적용이 되는 수년 후에 사용하는 것이 가능합니다. 여기 당신이 수년 사이에 사용이 가능하도록 도와주는 사이트들이 있습니다.

만일 도움을 줄 수 있는 더 많은 사이트를 알고 있다면 리스트에 추가를 하자! 만약 리스트 상에서 불필요하고 도움이 되지 않는 내용이 있다면 지워버려라!

3.6 HTML5는 언제 완성됩니까?

“완성” 이라고 하는 것은 엄청난 일입니다. 당신은 그때가 오기 전에 HTML5를 사용하실 수 있습니다. 우리는 언제 새로운 기능들을 사용할 수 있습니까?를 참고해주세요. HTML5는 2012년 중에 W3C 권고후보의 단계에 달할 것이라고 에디터는 보고 있습니다. 이것은 그 시점에 달할 때까지 이 기능들을 쓸 수 없다는 것은 아닙니다. 사양의 부분에 따라 완성도가 다릅니다. 어떤 섹션은 이미 비교적 안정되어 있기도 하고, 완성을 위해 완전히 마무리가 된 구현도 있습니다. 이러한 기능은 지금이라도 당장 사용할 수 있습니다. (예를 들면<canvas>). 그러나, 아직 활발하게 작업이 이루어지고 있어서 정기적으로 변경되는 섹션이 있고, 아직 사양이 설명조차 되지 않은 것도 있습니다.

각 섹션의 대략적인 안정도는 여백부분에 게재된 주석에 쓰여 있습니다.

다음 중 하나에 해당됩니다:

  • Idea; 아직 사양이 되지 않았다 – 그 섹션은 플레이스 홀더빠져 있는 다른 것을 대신하는 기호나 텍스트의 일부입니다.
  • First draft – 초기 단계
  • Working draft – 초기단계이지만, “first draft” 보다는 완성도가 높다.
  • Last call for comments – 그 섹션은 완성 직전입니다만 아직 진행중인 피드백이 있을지도 모릅니다. 당장이라도 피드백을 보내주세요. 그렇지 않으면 늦을지도 모릅니다.
  • Awaiting implementation feedback – 그 섹션은 기본적으로는 완료입니다만 실무자로부터의 피드백의 대응으로 변경될지도 모릅니다. 혹시 그 기능이 사양화되어버린다면 정말로 잘 작동하지 않는 기능이 발견되지 않는 한 이 시점 이후에는 크게 변경되는 것은 없습니다.
  • Implemented and widely deployed – 그 기능은 사양화 완료되었습니다. 일단 섹션이 상호이용가능하게 구현된다면 그것은 상당히 안정되어서 크게 변경되는 것은 없습니다. 만약 그 기능의 이용이 이미 널리 퍼져있다면은 설령 변경이 있다고 하여도 실제는 편집상의 변경일 뿐입니다.

또한 2개의 특별한 상태가 있습니다:

  • Being edited right now – 그 섹션은 매우 불안정해서, 활발히 편집되고 있습니다. 만약 피드백이 있다면, IRC에서 Hixie에 연락해주세요.
  • Being considered for removal – 무슨 이유가 있어서, 그 섹션은 폐지가 검토되고 있습니다. 결정에 도움이 되는 것이라면 빨리 피드백을 보내주세요.

여기서 말씀드리고 싶은 것은 당신은 전체 사양의 상태에 지나치게 지연하는 행동을 하지 말아야 한다는 것입니다. 당신은 각 섹션의 개별의 안정도와 완성도를 고려하면 좋을것입니다.

다시 말씀드립니다만, 에디터에 의하면 HTML5는 2022년 이후에 W3C권고에 달할 것으로 보입니다. 이것은 2004년 중반에 개시되어 약 18년에서 20년의 개발이 걸립니다. 그러나 그것은 그렇게 이상한 일이 아닙니다. HTML4의 작업은 90년대 중반에 개시되었습니다만 10년 이상 지났음에도 불구하고 아직까지 우리가 HTML5로 도달한 수준에 이르지 못하고 있습니다. 제대로된 테스트 시트가 없을뿐 아니라, 실제의 구현에는 부족한 사양이 많이 있어서 상호 운용이 가능하지 않은 부분도 있습니다. 그리고 몇 천 까지는 아니지만 몇 백 정도의 알려진 오류가 수정되지 않았습니다. HTML4가 등장한 당시는 권고라는 것이 현재 정도의 흥분은 아니였습니다.

사양이 권고에 이르기 위해서는, 100%의 완성도와 완전히 상호 운용이 가능한 구현의 두가지가 요구 됩니다. 말 그대로 몇 천이나 되는 사례(사양 전체에서는 적게 잡아도 20,000건)들을 성공적으로 통과해야만 합니다. 그 사례를 만드는 것에 얼마나 시간이 걸릴지 각 기능의 구현하는 것에 얼마나 시간이 걸릴지를 생각한다면 왜 기간이 그렇게 오래 걸리는지 이해하실 수 있으리라 생각됩니다.

(까놓고 말해서 W3C의 공식 견해로는 HTML5의 사양은 2010년 후반에 상호운용 가능한 구현을 가지고 완성될 것으로 되어 있습니다. 하지만 그 스케줄 11에는 공개 초안 초판(FPWD)의 년 월이 게제되어 있습니다만. 그것은 8개월 정도 앞서 있습니다. 그리고 W3C의 권고 후보(CR)는, 3번째의 마일스톤에 예정시기로 쓰여져 있습니다만 아직까지, 두번째 마일스톤인 최종초안(LC)에조차 이르지 못했습니다. W3C의 스케줄의 신빙성에 대해서는 당신의 판단에 맏기겠습니다.)

3.7 Microsoft와 Internet Explorer에 대해서는 어떻습니까?

Microsoft는 이미 IE8에서 HTML5의 일부를 구현하고 있습니다. 그러나 HTML5는 현존하는 브라우저(IE를 포함해)와 호환성이 보장될 수 있도록 배려하며 개발되고 있는 중입니다. 많은 기능은 자바스크립트를 사용하여 대체하여 구현 12할 수 있습니다.

3.8 설계의 근거는 문서화 됩니까?

어느 정도는 됩니다. 메일링 리스트나 IRC 채널의 아카이브로 문서를 볼 수 있습니다. 공식적으로는 문제가 제기되어 해결 방법이 그 이슈 로그에 기록되는 경우도 있습니다. 경우에 따라서는 예외도 있습니다만, 이것저것 다 문서화 시켜버린다면 사양이 눈덩이처럼 불어날 것입니다.

누군가가 시간을 들여 문서화한 몇가지 정보를 다음에서 보실수 있습니다:

4 HTML5 구문 이슈

4.1 HTML5는 text/html의 XHTML 논쟁에 종지부를 찍는 것입니까?

네. HTML4나 XHTML1과는 다르게 HTML이냐 XHTML이냐의 선택은 DOCTYPE이 아니라 MIME 타입의 선택에 의존합니다. HTML vs. XHTML를 참고해 주세요.

4.2 DOCTYPE은 어떻게 되는 것입니까?

HTML 의 경우:

<!DOCTYPE html>

XHTML의 경우:

DOCTYPE은 필수는 아닙니다. 보통은 필요치 않습니다. 넣고 싶으면 넣어도 상관 없습니다. (다음 질문을 참고해 주세요) 상기는 잘 정형화된 XML입니다. 때문에 이것이 XHTML 문서에 들어갈 수 있습니다. HTML의 출력을 위해서 종래의 생성기와의 호환성을 위해서 앞서 얘기한 DOCTYPE을 간단히 출력할 수는 없습니다만, 대체될 legacy-compat 버전 13이 사용될지도 모릅니다.

<!DOCTYPE html SYSTEM "about:legacy-compat">

이것은 종래의 브라우저에 관한 상호 호환성 문제에 관한 것을 가정한 것은 아닙니다. 종래의 저작 도구에 한합니다.

문자열 “about:legacy-compat”를 제외하고, DOCTYPE은 HTML에 있어서 대문자, 소문자를 구별하지 않습니다. XHTML에서는 구별되므로 앞서 얘기한 것 중에 어느 것과는 매칭되어야 합니다. 이러한 이유로 DOCTYPE은 <!DOCTYPE HTML> 또는 <!doctype html>로 구분하여 쓰는 것보다 위에서 예를 든 것과 같이 사용하는 것이 권장됩니다.

다음에 이어지는 기준을 만족시키기 위해서 위의 것들 중의 하나가 선택되었습니다.

  • 현재의 브라우저에도 종래의 브라우저에도 모두 이것들에 의해서 표준 모드가 됩니다.
  • 이것들은 XML에 있어서 정형식이고, XHTML 문서에 집어 넣을 수가 있습니다.
  • 이것들 중 적어도 하나를 출력하는 것이 가능합니다. 어느 쪽도 불가능하다면 현존하는 마크업 생성기를 쓸 수 있습니다.
  • 이것들은 의도적으로 언어 버전의 식별자를 포함하고 있지 않습니다. 이 DOCTYPE은 HTML의 종래의 버전에서도 이용할 수 있도록 하고 있습니다.
  • 전자는 짧고 기억하기 쉽습니다.
  • 하위 호환 DOCTYPE은 의도적으로 매력이 없는 것으로 취급하고 불필요한 것에서 쓰이는 일이 없도록 자기기술식으로 하였습니다.

4.3 XHTML에서는 DOCTYPE이 어떤 조건하에 사용되어져야 합니까?

일반적으로 XHTML에서 DOCTYPE을 쓸 필요는 없습니다. 그러나 DOCTYPE이 필요한 경우가 있습니다:

  1. 해당 문서가 HTML과 XHTML의 어느 쪽 타입으로도 제공될 수 있는 혼합형 문서가 되도록 가정되어 있는 경우입니다.
  2. 문서 내에서 이용을 위해 엔티티 참고를 선언한 경우. 대부분의 브라우저는, 내부 서브셋만 읽고 외부 엔티티를 참고하지 않음을 주의해주세요.(이것은 HTML과 호환성이 없습니다. 뿐만 아니라, 혼합형 문서에 대해서는 적절하지 않습니다.)
  3. 여러 종류의 DTD에 대해서 사용자 선택의 DTD를 사용하고 싶은 경우. 단, 어느 DTD가 틀렸는가하는 것에 대해서는 주의해 주세요.

4.4 제정이 완료되지 않은 HTML5로 만든 문서를 어떻게 파싱하나요?

text/html 미디어 타입을 사용하는 문서 모두(즉, DOCTYPT을 사용하지 않은 문서나, HTML2.0, HTML 3.2, HTML4, XHTML1의 DOCTYPE을 사용한 문서를 포함합니다)는 HTML5에서 정의되어진 것과 같은 파싱 알고리즘을 가지고 파싱됩니다. 이것은 웹 브라우저가 지금까지 HTML 문서에 대해서 처리해온 것과 일치합니다. 그리고 코드의 복잡도를 저하시킵니다. 그것은 보안에 대해서도 굉장히 좋습니다. 일반적으로 버그가 줄어 들어 갑니다. 그것 뿐 아니라 HTML5의 HTML 구문은 새로운 파서를 필요로 하지 않습니다. 예를 들면 HTML4의 DOCTYPE을 사용한 문서도 HTML5 파서를 사용해서 파싱될 것입니다.

검증 도구Validator는 이전 레벨의 HTML에 대해서 다른 코드 패스를 가지는 경우가 있습니다.

4.5 DTD가 없다면 어떻게 자신의 페이지를 검증(Validation) 할 수 있습니까?

HTML5 검증 서비스를 사용해 주세요.

4.6 HTML 직렬화란 무엇입니까?

HTML 직렬화란, HTML5에서 규정된 HTML 문서의 구문을 가리킵니다. 그 구문은 이전 버전의 HTML에서 SGML 구문과 조금이지만 XML, 그리고 웹 상에 이미 널리 퍼져 있는 실제 콘텐츠에 의해서 검증된 것입니다. (예를 들면, 빈 요소에 종료 태그를 나타내는 슬래시를 넣을 수 있다든지, xmlns 속성 등.)

MIME 타입이 text/html라고 판정된 구문은, HTML 직렬화라고 인식되어 HTML 파서를 이용하여 파싱해야만 합니다.

4.7 XML(또는 XHTML) 직렬화란 무엇입니까?

XML 직렬화란, XML 1.0에서 규정된 구문과 XML 1.0의 네임스페이스를 가리킵니다. application/xhtml+xml나 application/xml이라고 하는 XML의 MIME 타입을 가진 리소스는 XML문서입니다. 만약 HTML 네임스페이스의 요소를 사용하면 그것은 XHTML을 포함한 것이 됩니다. 만약 루트 요소가 HTML 네임스페이스의 ‘html’ 이라면, 그 문서는 XHTML문서로서 참조됩니다.

4.8 HTML5 에서는 어떤 MIME타입을 사용합니까?

HTML 직렬화는 MIME 타입에 text/html을 사용하여 제공해야만 합니다.

XHTML 직렬화는 application/xhtml+xml나 application/xml같은 XML의 MIME 타입을 사용하여 제공해야만 합니다. XHTML1과는 다르게 XHTML5는 text/html로 제공하면 안됩니다.

XHTML에 잘못된 MIME 타입text/html)을 사용하면, 그 문서는 HTML의 해석 요건에 따라 해석될 것입니다. 다시 말하면, 그것은 태그 스프Tag soup로 취급 당할것입니다. 브라우저에서 확실하게 XML으로 처리하고자 한다면 XML MIME 타입을 사용해야 합니다.

4.9 빈요소는 /> 로 닫습니까? 아니면 >로 닫습니까?

HTML에서는 빈 요소(예를 들면 br, img, input 요소) 끝에 슬래시를 넣을 필요는 없습니다. <br/> 대신에 <br> 이라고 쓰면 됩니다. 이것은 HTML4와 같습니다. 그러나 XHTML1이 널리 이용되고 있기 때문에 꽤 많은 페이지에서 종료 슬래시가 사용되고 있습니다. 때문에 XHTML1에서 HTML5로의 이행을 쉽게 하기 위해 종료 슬래시의 구문을 사용할 수 있습니다.

HTML5는 또한 MathML 요소를 포함할 수 있게 되어 있습니다. Math 요소의 안에 있는 요소에 종료 슬래시를 넣으면, 그것은 XML 용법과 같은 의미를 가집니다. 즉, 그것은 요소를 닫는 의미입니다. 그러나 이것은 그 컨텍스트 안에서만 적용되어 통상의 HTML 요소에서는 작동하지 않습니다.

4.10 HTML 문서에서 사용하는 문법에 주의하면 XML 파서로 처리하는 것이 가능합니까?

안됩니다. HTML과 XML은 특히 구문 해석에 있어서 많은 차이가 있어 다른 것들을 위해 설계된 툴을 사용한 직렬화를 처리하는 것은 할 수 없습니다. 그러나 HTML5는 DOM과 관련해서 규정되어 있기 때문에 대부분의 경우 HTML과 XHTML의 직렬화의 양쪽 모두를 이용해서 같은 문서를 표시할 수 있습니다. 그러나 뒤에 설명이 나오겠지만 몇몇 다른점도 있습니다. 정확하게는 XHTML로 표시할 수 없는 HTML도 있고 그 반대의 경우도 있습니다.

만약 HTML문서를 XHTML로서 처리하고 싶다면 먼저 그것을 XHTML로 변환할 필요가 있습니다. XHTML을 HTML로서 처리하고 싶은 경우에는, HTML로 변환할 필요가 있습니다.

4.11 네임스페이스 선언은 무엇입니까?

XHTML에서는 네임스페이스를 지정하지 않으면 안됩니다.

<html xmlns="http://www.w3.org/1999/xhtml">

HTML에서 현재는 xmlns 속성을 어느 HTML 요소에서도 사용할 수 있습니다만, 현재 가질 수 있는 값은 ‘ http://www.w3.org/1999/xhtml‘ 뿐입니다. 이것은 아무 작용도 하지 않습니다. XHTML1로부터 이행을 간단히 하는 정도일 뿐입니다. 실제로 이것은 HTML에 사용할 수 있는 네임스페이스 선언은 아닙니다. 왜냐하면 HTML은 아직 네임스페이스를 지원하고 있지 않기 때문입니다. HTML에 네임스페이스 지원은 있습니까? 를 참고해 주세요.

4.12 HTML에 네임스페이스의 지원은 있습니까?

HTML5에서는 DOM을 규정하고 있어 text/html의 파싱에서 모든 HTML 요소는 HTML 네임스페이스 http://www.w3.org/1999/xhtml를 자동적으로 가지게 됩니다. 그러나 XHTML 직렬화와는 다르게 HTML 직렬화에서 이용할 수 있는 진짜 의미의 네임스페이스 구문은 아닙니다. (앞의 질문을 참고해 주세요.) 즉, XHTML처럼 HTML 마크업 안에서 네임스페이스를 선언할 필요는 없습니다. 하지만 값은 ‘http://www.w3.org/1999/xhtml‘뿐이지만 각각의 HTML요소에 xmlns 속성을 넣을 수는 있습니다.

거기다 HTML 구문은 MathML이나 SVG의 요소를 집어 넣는 방법도 제공하고 있습니다. Math나 SVG의 컨테이너 요소 안에 들어가 있는 요소는 파서에 의해 자동적으로 각각 MathML 네임스페이스나 SVG 네임스페이스에 들어가게 됩니다. 네임스페이스 구문은 필수는 아닙니다만 값이 적당한 네임스페이스가 있다면 xmlns 속성을 재사용 해도 상관없습니다.

결론적으로 HTML5에서는 XML 네임스페이스 구문을 사용하는 것은 할 수 없지만 MathML이나 SVG를 집어넣을 수 있는 방법이 있으며, xmlns 속성을 어느 요소에나 사용할 수는 있습니다. 단지 지정희 제약을 기초로 그것이 DOM 레벨에 부적합하지 않아야 한다는 조건이 있습니다.

4.13 어떻게 문자 인코딩을 지정하면 좋습니까?

HTML에서는 HTTP의 Content-Type 헤더를 사용하여 인코딩을 지정하는 것이 강력 추천됩니다. 적절한 헤더를 송신하도록 서버를 설정하는 것이 불가능할 경우에는 meta 요소를 사용할 수 있습니다.

<meta charset="UTF-8">

문자 인코딩 선언에는 다음의 제한이 적용됩니다:

지정하는 문자 인코딩 이름은 그 파일을 직렬화하는데 사용되는 문자 인코딩의 이름이 아니면 안됩니다. 그 값은 유효한 문자 인코딩 이름이 아니면 안되고 그 인코딩에 대한 추천명이여야 합니다. 문자 인코딩 선언은 문자 참조나 문자 이스케이프같은 종류를 쓰지 않고 직렬화되어야만 합니다. 이 목적을 위해서 쓰이는 META 요소는 그 파일의 시작 부분으로부터 512 바이트 이내에 위치 해야만 합니다. 이 요소를 HEAD 요소의 최초의 인자로 해서 가능한 파일의 앞쪽에 위치하도록 하는 것이 좋을것입니다.

HTMLXHTML 어느 쪽이든지 제공할 수 있도록 한 혼합형 문서에 대해서는 XHTML 문서에도 그것을 넣을 수 있습니다. 그러나 그 인코딩은 “UTF-8″의 경우에만 가능합니다.

앞서 제시한 것이 추천되는 구문입니다만, HTML4에서 HTML5로 간단하게 이동할 수 있도록 다음과 같이 하는 것도 가능합니다. (이것은 XHTML이나 혼합형 문서에는 쓸 수 없습니다.)

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

XHTML에서는 XML의 문자 인코딩의 결정의 규칙이 적용됩니다. META 요소를 XHTML 문서의 인코딩을 결정하기 위해 사용해서는 안됩니다. (그러나 그것은 UTF-8에 인코딩된 XHTML 문서에 집어 넣는 것은 가능합니다). 당신은 HTTP의 Content-Type헤더가 혹은 인코딩을 지정하는 XML 선언 중 어느 것인가를 써야합니다.

<?xml version="1.0" encoding="UTF-8"?>

그렇지 않다면, 당신은 디폴트의 UTF-8 혹은 UTF-16을 사용해야 합니다. 추천은 UTF-8입니다.

4.14 HTML과 XHTML의 차이는 무엇입니까?

Wiki에 있는 differences between HTML and XHTML 한글를 참고해 주세요.

4.15 HTML DOM과 XHTML DOM을 양립시킬 수 있는 최선의 방법은 무엇입니까?

HTML과 XHTML의 동일한 DOM이 생성될 수 있도록 생각은 하고 있습니다만. HTML DOM과 XHTML DOM은 동작에 다소 차이가 있습니다.

대문자, 소문자의 차이의 상식:

될 수 있는 한, Element.tagName 와 Node.nodeName의 테스트는 피해주세요(또는, 테스트 전에 toLowerCase()를 사용해주세요). 요소를 생성하기 위한 네임스페이스를 지정하는 버전의 이용:Document.createElementNS(ns, elementName)

4.16 어째서 HTML5는 태그 스프(tag soup)를 용인하는겁니까?

아니오, 사실 용인하지 않습니다. 그것은 문서의 적합성 요건과 사용자 에이젼트의 요건과 혼동하여 나온 오해입니다.

현재의 콘텐츠를 지원한다고 하는 기본설계의 원칙의 결과, 문서가 적합한지 어떤지에 상관없이, HTML을 처리하는 방법을 사양에서 규정하지않으면 안됩니다. 그런 이유로 사양에서는 처리방법이나 태그 스프로 보여질 수 있는 잘못된 마크업을 회복하는 방법을 정확히 규정하고 있습니다(혹은 할 것입니다).

예를 들면, 사양에서는 올바르게 중첩Nesting되어 있지 않은 태그같은 구문 에러를 처리하기 위한 알고리즘을 규정하고 있어서, 틀림 없이 잘 구성된 DOM 트리가 생성될 수 있을 것입니다. 브라우저사이의 상호 운용성을 달성하고, 상호 리버스 엔지니어링에의 의존을 하지않을 수 있는 날을 맞이하기 위해서도 그것을 규정하는 것은 불가결합니다. 그러나 웹 제작자를 위한 적합성 요건은, 처리 요건과는 분리하여 규정되어 있습니다. 브라우저는 잘못된 콘텐츠를 처리하는 것이 요구되기 때문에 그러한 마크업의 적합 정도를 체크하지 않습니다.

예를 들면 사용자 에이전트는 marquee 요소를 지원하지 않으면 안됩니다. 그러나 웹 제작자는 적합한 문서안에서 marquee 요소를 사용하면 안됩니다. 사용자 에이전트에 적용되는 규칙과 적합 문서를 작성할 때의 웹 제작자에 적용되는 규칙을 구별하는 것이 중요합니다. 이것들은 완전히 다른 것입니다.

위키피디아에서 Tag soup 설명

5 HTML5 기능 제안

5.1 HTML5는 다양한 요소에 href를 지원해야 한다

사양에서는 <a>가 블럭을 포함할 수 있습니다. 그러나 모든 요소에 href=”"를 넣는 것은 지원하지 않습니다. 모든 요소에 href를 지원해 버린다면 그로 인해 여러가지 문제가 발생하여 HTML5에서의 지원이 어려워집니다. 가장 큰 이유는 브라우저 벤더에 의해서 구현이 굉장히 복잡해진다고 보고되었기 때문입니다. 우리가 그들에게 그것을 구현하라고 이야기해도 의미가 없습니다.

  • 게다가 기존의 브라우저와 하위호환성이 없습니다.
  • <a>요소나 약간의 스크립트를 사용해서 할 수 없는 신기능을 더 할 수 없습니다.
  • 모든 요소에 지원하는 것은 의미가 없습니다. INPUT이나 BUTTON같은 인터렉티브한 요소에서 href를 이용하다가 그것들이 가지고 있는 일반적인 기능을 저해할지도 모릅니다.

몇몇 경우에서 웹 제작자의 타이핑이 줄어든다는 정도의 이점이 있습니다. 그러나 이정도로는 또는 다른 이유를 생각해 보면 그것을 지원할 이유로서는 충분하다고 할 수 없습니다.

블럭을 <a>태그로 감싸면 대부분의 경우에는 해결됩니다. 다만 테이블의 행을 링크 안에 넣는 것은 할 수 없지만 다음과 같은 방법으로 해결 할 수 있습니다.

 <tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>

5.2 HTML5는 리스트 헤더를 지원해야한다

<figure>와 <legend>태그를 사용하면 리스트에 헤더를 쓸 수 있습니다.

<figure>
  <legend>Apples</legend>
    <ul>
      <li>Granny Smith</li>
      <li>Evil Apple of Knowledge</li>
      <li>Apple, Inc</li>
    </ul>
</figure>

정의 리스트를 사용해서 리스트의 그룹을 레이블링 할 수도 있습니다:

<dl>
  <dt>Dry:</dt>
  <dd>
    <ul>
      <li>1c flour</li>
      <li>1/4c sugar</li>
      <li>1tsp baking soda</li>
    </ul>
  </dd>
  <dt>Wet:</dt>
  <dd>
    <ul>
      <li>1 egg </li>
      <li>1/2c milk</li>
      <li>1tsp vanilla extract</li>
    </ul>
  </dd>
</dl>

이러한 기술은 과거에 HTML3 사양에서 제안되었던 <lh>태그에 해당하는 것입니다. <li>태그의 직전에서 파싱한다고 하는 것은 곤란한 문제가 있기 때문입니다.

5.3 HTML5는 누구든지 새로운 요소를 고안할 수 있도록 해야한다

실제로 HTML의 확장을 고안하는 방법은 사람에 따라 천차만별입니다.

  • 웹 제작자는 보다 합당한 기존의 “실제” HTML 요소를 쓰면서도 class 속성을 사용하여 요소를 확장할 수 있습니다. 그러게 함으로서 그 확장을 모르는 브라우저나 그 밖의 툴에서도 어떻게든 그 요소를 지원할 수 있습니다. 예를 들면 이것은 Microformat에서 채용되고 있는 방법입니다.
  • 웹 제작자는 data-*=”"속성을 사용하여, 스크립트로 데이타를 넣을 수 있습니다. 브라우저는 이것들에는 일절 접근할 수 없습니다. 그렇기 때문에 스크립트로부터 HTML 요소에 데이타를 넣고 뒤에서 그것들을 찾아 처리할 수 있게 됩니다.
  • 웹 제작자는 <meta name=”"contsnr=”"> 메카니즘을 사용하여 페이지 전체의 메타 데이터를 넣을 수 있습니다. 이름은 wiki의 MetaExtension페이지에서 등록해 주세요.
  • 웹 제작자는 rel=”" 메카니즘을 사용하여 링크에 특정의 의미를 부여할 수 있습니다. 이것은 Microformat에서도 이용되고 있습니다. 이름은 wiki의 RelExtensions페이지에서 등록해 주세요.
  • 웹 제작자는 <script type=”">메카니즘을 이용하여 독자의 타입을 지정하는것으로 raw 데이타를 구성할 수 있습니다. 게다가 스크립트로부터 사용할 수도 있습니다.
  • 웹 제작자는 플러그인을 생성하여 <embed> 요소를 사용하여 그것을 불러낼 수 있습니다. 이것은 Flash의 동작 방식입니다.
  • 웹 제작자는 JS prototyping 메카니즘을 사용하여 API를 확장할 수 있습니다. 이것은 스크립트의 라이브러리 등에서 자주 사용되고 있습니다.
  • 웹 제작자는 microdata 기능을 사용할 수 있습니다. (item=”"와 itemprop=”"속성). 이것을 사용하여 중첩된 name-value 페어의 데이타를 구성하여 다른 애플리케이션이나 사이트와 공유할 수 있게 됩니다.
  • 웹 제작자는 새로운 요소나 새로운 속성을 워킹 그룹에 제안할 수 있습니다. 만약 커뮤니티가 노력의 가치가 있는 제안이 찬성하면, 그 제안이 언어Spec에 추가 됩니다.

현재, 사용자 에이전트의 벤더나 웹 커뮤니티와 그 확장에 대해서 의논하지도 않고, HTML 문서에 독자의 기능(새로운 요소나 새속성)을 도입하는 메카니즘을 넣는 일은 없습니다. 이것은 의도적으로 그렇게 하고 있습니다. 우리는 “오래된 안좋은 시대” 체험, 관계 그룹과 좋은 설계가되도록 의논도 하지 않고 독단으로 사용자 에이전트에 독자의 요소나 속성을 고안해주길 바라지 않습니다.

우리는 워킹 그룹과도 논의해서 그 제안의 관련의 그룹과 의논하지 않고 새 요소나 새 속성을 고안해서 추가하지 않도록 부탁드리고 있습니다.

5.4 HTML5는 <dl>안에서 <dt>와 <dd>를 그룹화 해야한다

이것은 스타일링의 문제로 CSS로 대처해야 합니다. HTML에 그룹화의 요소를 추가할 이유는 없습니다. 의미가 모호하기 때문입니다.

5.5 어째서 <b>, <i>, <small>와 같은 시각적인 요소를 아직까지 넣어둔 것입니까?

이러한 요소는 지금까지의 사용 방법을 답습한 것처럼 실용적인 사례나 특정 요소에서는 다룰수 없는 사례를 상정하고 있습니다.

강조(em), 인용(cite), 정의(dfn), 변수(var) 같은 특정 요소에서 이용할 수 있는 이텔릭기울어진 서체을 적용한 일반적인 사례가 많이 있는 한편 이러한 요소에서는 잘 다룰 수 없는 사례도 많이 있습니다. 예를 들면, 분류상의 정의, 기술 용어, 다른 언어로부터의 관용구, 생각, 배의 이름 등 입니다.

마찬가지로 중요성(strong), 머릿말(h1-h6), 테이블 헤더(th) 처럼 특정 요소에서 다룰 수 있는 볼드굵은 서체의 텍스트를 위한 일반적인 사례도 많이 있습니다. 그러나 그렇지 않은 것도 있습니다. 예를 들면, 문서의 개요에 사용되는 키워드나 리뷰 안에 사용되는 상품명입니다.

이러한 경우에는 span 요소에 적절한 class명을 부여해서 스타일시트에 관련지어 사용되야 한다고 주장하는 사람도 있습니다. 그러나 b요소나 i요소는 어떤 환경에 있어서 그에 상응하는 폴백 스타일링을 제공하는 것입니다. 그런 환경이란, 스타일시트를 지원할 수 없는 환경이나 비주얼로 렌더링 할 수 없는 환경입니다. 예를 들면 스크린리더 등 입니다. 또한, 이것뿐 아니라 이러한 요소는, 그 텍스트는 그 전후의 콘텐츠와 어떠한 구별이 되고 있다는 것을 나타내는 것입니다.

기본적으로, 이러한 요소는 구별을 전달하는것입니다만 특별한 의미를 갖지는 않습니다. 그 의미는 독자가 문맥으로 판단해서 결정하는 것이 됩니다. 다시 말하면, 이러한 요소는 스스로 특정 의미를 전달하는 일은 없지만 콘텐츠 앞뒤 문맥상 어떠한 구별이 되어 있고 그것을 독자에게 의미 있게 해석되도록 요구된다는 것입니다.

이것과 관련해서는 The <b> and <i> Elements에 자세히 설명되어 있습니다.

마찬가지로 small요소는 일반적으로 콘텐츠 내에서 작은 문자로 렌더링되는 문자열을 위해 정의된 것입니다. 이것은 파인 프린트로 알려져 있는 것입니다. 이것은 통상은 문서의 마지막에 게제되는 저작권 표시나 면책조항이나 법률적 텍스트를 포함합니다.

5.5.1 그래도 역시 이것들은 표현이다

역사적으로 <b>, <i>, <small>은 표현을 위한 것이었습니다. 하지만 HTML5는 이 요소들을 미디어에 의존하지 않는 형태로 정의하고 있습니다. 예를 들어 <small>은 라디오 광고에서, 마지막에 조금 이야기되는 부분에 해당합니다 14(이러한 요소는 비주얼 브라우저에 적용할 수는 있어도 음성 브라우저에서는 적용할 수 없습니다.)

5.6 <cite>요소로 사람의 이름을 마크업할 수 있도록 해야한다

지금까지 <cite>는 대부분 ‘이탤릭’을 의미하는데 사용되고 있었습니다. 신중한 웹 제작자는 이 요소를 이름이나 타이틀을 마크업 하는데 사용하고 있지만 개중에는 인용 콘텐츠를 마크업하는 것과는 거리가 먼 방법으로 사용하는 사람도 있습니다.

때문에 이 요소는 우리가 지금까지 해온 것처럼 과거의 실적에 기초해야 한다고 결정할 수가 없습니다.

만약 우리가 계속 그렇게 한다면, 이것은 그 요소의 가장 유용한 사용 방법은 무엇인가하는 기본 전제로부터 멀어지게 됩니다. 현재 <cite>의 가장 유용한 사용법은 타이틀이라는 의미를 넘어서 인증 표현 컨트롤을 허용하는 것이라는 결론에 달하게 됩니다. 왜냐하면 그것들은 자주 이탤릭으로 표시되는데 그 의미는 그것이 이전의 버전에서 의미했던 것에 보다 가깝고, 그 요소를 어느 쪽에도 적용한다는 것은 인증 표현에 있어서 혼란을 야기시키기도 합니다.

만약 정말로 이름이 필요하다면, 이미 그것을 마크업하는 방법은 많이 있습니다. (예를 들면, hCard microformat, microdata vCard vocabulary, <span>, class 등)

주의: 화자(예를 들면 인용등의)의 이름을 마크업하기 위해서(cite)요소의 이용을 지원한다는 것에 대해서 조사나 의견을 모으고 있습니다. 여러분의 협력부탁드립니다.

5.7 <time>요소로 의미 있는 시간(‘March’)이나 역사적인 시간을 마크업 할 수 있도록 해야한다

이것은 몇 번이나 의논을 해 왔습니다. 이 토픽의 개요는 밑의 e-mail을 참고해 주세요.

현재, 두번째 메일에서 의논되고 있는 대로 전진을 위한 가장좋은 방법이란, 이 문제를 해결하는 것에 흥미를 가진 커뮤니티가 있음을 나타내는 것입니다. 그것의 해결을 위해 Microdata 등 기존의 기술을 사용하는 것입니다. 만약 하나의 해결책이 높은 보급률을 달성한다면, 그것은 제안의 강함을 대폭 증강할 것입니다.

6 WHATWG 와 the W3C HTML WG

6.1 그룹을 통합하려는 계획은 있습니까?

특별히 없습니다. 몇몇 이유로 W3C 그룹에 참가할 수 없는 사람이 있고, 또 WHATWG 그룹에 참가할 수 없는 사람도 있습니다. 에디터는 어느 그룹에도 속하고 있고ㅡ 모든 제안을 다루고 있습니다. –그리고, 이러한 2개의 메일링 리스트뿐 아니라, HTML5에 관한 제안을 보낼 수 있는 곳이 이 밖에도 많이 있습니다. (예를 들면 블로그, www-html@w3.org, 포럼, 직접 보내는 메일, 미팅 등).

6.2 어느쪽 그룹이 의논에 있어서의 권리를 가지고 있습니까?

에디터는 모두로 부터의 피드백을 다루고 있습니다. 기술적인 의논을 위해 이야기의 출처를 보는 것은 없습니다.

6.3 HTML의 경위는 어떻게 되어 있습니까?

HTML의 경위의 상세가 게제된 문서가 몇개가 있으므로 참고해 주세요.

7 Web Workers

WHATWG은, HTML5뿐 아니라, Web Workers의 작업도 하고 있습니다. 이것은, W3C WebApps워킹 그룹과 함께 작업하고 있습니다.

8 메일링 리스트

8.1 탑포스팅해야합니까? 아니면 인라인으로 답신해야합니까?

인라인으로 답신하거나, 완결하는 형식으로 답신해 주세요.

기본적으로는, 당신이 쓴 최후의 뒤에는 아무 것도 넣지 말아주세요. 그렇게 함으로 당신이 쓴 부분을 발견해 내기 위해 스크롤하지 않아도 되게 됩니다. 당신의 e-mail이 읽기 쉬워 집니다. 그렇지 않으면, 몇 년인가 지나서 문맥을 알 수 없게 될지도 모릅니다.

즉, 이렇게 답신해 주세여:

Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!

절대로 다음과 같이 답신해서는 안됩니다(당신의 e-mail을 거슬러 올라가 읽지 않으면 안되기 때문입니다) :

No

Ian wrote:
> Is this a good example of how to post e-mails?

또한, 다음과 같이 답신하는 것도 하지 말아 주세요(당신이 쓴 곳보다 밑에도 뭔가 있는 것은 아닐까 생각하게 되기 때문입니다) :

This is a bad way to write e-mail.

Ian wrote:
> Is this a good way to write e-mail?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text

또한 다음과 같이 답신하는 것도 하지 말아 주세요 (전혀 문맥이 없다). 독자가, 당신이 무엇에 대해서 언급하고 있는지 알 수 없기 때문입니다:

No, I think that's a bad idea. It wouldn't be good for the readers, for instance.

원본 문서를 잘 인용해 주세요. 혹은 당신 스스로 개요를 설명해 주세요.

만약, 당신이 Outlook이나 Outlook Express를 사용하고 있다면, Outlook-QuoteFix OE-QuoteFix를 사용할 수 있습니다. 이러한 플러그 인은 Outlook의 몇몇 문제를 수정해서 email을 절적하게 포맷한 상태에서 송신해 줍니다.


이 문서는 원문이 수시로 업데이트되고 있습니다. 번역된 문서와 일부 다른 내용 또는 추가된 내용이 있을 수 있습니다. 되도록 원문을 읽어 주시고, 번역된 이 문서는 참고용으로 사용해 주세요. 또한, 번역상의 오류는 아래 의견란을 통해서 알려 주시면 감사하겠습니다. 또한, 원문을 이미 읽었거나 읽고 계신분들 가운데 위 번역된 내용에 잘못된 부분을 찾으신 분들은 꼭 의견란에 오류를 지적해 주시면 감사하겠습니다.

  1. SVN, 버전관리
  2. Microformat, 시멘틱 데이터 정의를 범용적으로 만든 것. RDFa와 함께 논의 중에 있음
  3. Canvas 요소 내 각종 객체를 회전, 변환하고 그레디언트, 이미지 생성 등 각종 효과를 주는 기능 부분을 기술.
  4. 이 스펙은 기존 Ajax의 단점으로 알려진 크로스 도메인 문서 접근을 가능하게 해 주는 스펙
  5. 웹 애플리케이션이 주 문서와 병렬적으로 스크립트를 백그라운드로 수행할 수 있게 해 주는 API
  6. 한 웹 페이지에서 서로 다른 서버에 있는 웹 페이지에 양방향 통신을 할 수 있는 별도 프로토콜을 정의할 수 있는 API
  7. 웹 서버로 부터 전달(Push)되는 데이터 예를 들어 SMS 같은 것을 받을 수 있도록 EventSource를 정의하고 이벤트를 기다릴 수 있도록 하는 API
  8. 자바 스크립트를 이용해 웹 브라우저 내장 데이터베이스에 SQL을 통해 질의하는 API
  9. 웹사이트의 제작자
  10. 브라우저 제작자
  11. HTML Working Group
  12. 시뮬레이팅
  13. 구형과 호환되는 버전
  14. 역주: 어떤 상황인지 잘 모르겠습니다
이 글을 다 읽어주셨다면, 댓글을 남겨주세요. 좋았다라는 격려도 좋고, 잘못된 부분을 지적해 주시는 것도 좋습니다. 마음에 드셨다면 아래 Like 버튼을 눌러서 페이스북과 트위터로 소개해 주시면 더욱 좋겠습니다.

Comments are closed.