모질라용 코딩
문서양식
스타일
스크립트
- 자바스크립트
  핵심 자바스크립트
  핵심 자바스크립트
- 모질라 객체모델
  모질라에서 문서 객체모델
- Mozilla DOM 참고자료
  자바스크립트 지침
  자바스크립트 참고자료
  자바스크립트 작성자료
- W3C DOM Level 1
  DOM Level 1설명서
  DOM Level 2 핵심내용
  DOM Level 2 HTML핵심
  DOM Level 1 표준지원
  HTML DOM Level 1 표준지원 DOM Level 1 사용
  DOM에서 공백
  다양한 HTML 테이블표현
  DOM 예제
- W3C DOM Level 2
  DOM Level 2 Style설명서
  DOM Level 2 Events설명서
  자바스크립트 CSS1 코드작성기

모질라 웹개발자 FAQ

이 문서자료는 모질라를 이용할 때 특히 자주 제기되는 질문에 대한 답변 자료입니다. 이 문서 마지막에 더 일반적인 웹저작에 관한 FAQ 링크를 제공합니다.

This document answers questions that Web authors ask frequently specifically in connection with Mozilla. There are links to more general Web authoring FAQs at the end of this document.

쿼크 방식과 표준방식은 무엇인가?

What are the Quirks mode and the Standards mode?

모질라는 2와 1/2모드가 존재합니다: 쿼크, 준표준 그리고 표준방식이 그것입니다. 표준모드에서 모질라는 세계웹연합(World Wide Web Consortium)의 추천사항을 준수하여 제작된 문서를 처리하는 데 목적을 두고있습니다. 쿼크모드는 오래된 호환성처리를 목적으로 한 것으로, 모질라는 W3C설명서에 상반되는 W3C 권고사항을 따르는 문서를 처리할 수 있게끔 이전 브라우저의 처리방식을 흉내냅니다. 준 표준방식은 전통적 방식에서 테이블 셀을 이미지로 처리한다는 다음의 질문의 문제를 기술하는 것을 제외하고는 표준방식과 같습니다. 해당 방식은 HTML 문서의 시작부분에서 문서형식 선언에 근거하여 선택됩니다.

Mozilla has two and a half layout modes: Quirks, Almost Standards and Standards. In the Standards mode Mozilla aims to treat documents authored in compliance with the Recommendations of the World Wide Web Consortium according to the W3C Recommendations. In the Quirks mode--for the purpose of backwards compatibility--Mozilla mimics some behaviors of legacy browsers in ways that could cause W3C Recommendation-compliant documents to be handled against the W3C specifications. The Almost Standards mode is like the Standards mode except it addresses the issue of the next question by rendering table cells with images in the traditional way. The mode is picked based on the doctype declaration (or the lack thereof) at the beginning of an HTML document.

● HTML을 표준방식으로 사용할 수 있는 지 확인하는 가장 쉬운 방법은 다음과 같은 문서형식선언을 사용합니다:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
The easiest way to make sure that the Standards mode is activated for HTML, is to use this doctype declaration: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

● HTML을 준표준방식으로 사용할 수 있는 지 확인하는 가장 쉬운 방법은 다음과 같은 문서형식선언을 사용합니다 : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
The easiest way to make sure that the Almost Standards mode is activated for HTML, is to use this doctype declaration: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

전자의 선언문은 어떤 표준에 반대되는 마크업을 포함하지 않는 문서를 위한 것입니다. 후자는 표준에 반대되는 마크업을 포함하는 문서를 위한 것입니다. 어느 경우이든 해당 문서는 CSS2레이아웃 모델를 유효하게 처리하며 호환될 수 있어야 합니다.

The former declaration is for documents that don’t include any deprecated markup. The latter is for documents that may include deprecated markup. In either case the document should validate and be compatible with the CSS2 layout model.

HTML을 쿼크모드로 사용할 수 있는 가장 쉬운 방법은 문서타입 선언을 빼버리는 것입니다. 그러나 쿼크모드에 의존하는 새 문서를 작성하는 것은 바람직하지 않습니다.

The easiest way to activate the Quirks mode for HTML is to omit the doctype declaration. However, authoring new documents that rely on quirks is discouraged.

준표준방식은 모질라 1.1 베타와 모질라 1.0.1에 도입되었습니다. 지금은 준표준방식을 사용하는 이전 버전의 문서타입선언은 표준모드를 사용하였습니다.

The Almost Standards mode was introduced in Mozilla 1.1 beta and Mozilla 1.0.1. In earlier versions the doctype declarations that now activate the Almost Standards mode activated the Standards mode.

문서타입 스니핑은 text/html로 제공되는 문서에만 적용됩니다. XML로 전송되는 문서는 항상 표준레이아웃방식을 사용합니다. 여기에는 application/xhtml+xml 전송되는 문서를 포함합니다. 그에 따른 결과는 부록 C를 가장하여 text/html로 제공될 때 준표준모드로 XHTML 1.0 문서를 처리하게 되지만 application/xhtml+xml로 제공될 때는 표준모드로 처리합니다.

Doctype sniffing only applies to documents served as text/html. Documents sent as XML always activate the Standards layout mode. This includes documents sent as application/xhtml+xml. The consequence is that XHTML 1.0 Transitional documents are rendered in the Almost Standards mode when served as text/html under pretext of the Appendix C but in the Standards Mode when served as application/xhtml+xml (as they should be).

왜 레이아웃엔진이 표준모드로 작동할 때 테이블의 이미지 행 사이에 공백이 있는가요?

Why are there gaps between image rows in tables when the layout engine is in the Standards mode?

CSS 상자 레이아웃 모델은에서 레이아웃 상자의 수직크기설정(vertical sizing)과 이미지의 수직정렬(vertical alignment)는 오래된 브라우저의 처리방식이 다릅니다. 해당 레이아웃의 이런 측면은 이미지의 display CSS 속성( 그리고 가능한 <a> 요성을 둘러쌀) 을 block으로 분명하게 설정하면 변경할 수 있습니다.

In the CSS2 box layout model the default vertical sizing of layout boxes and the default vertical alignment of images is different from the behavior of old browsers. These aspects of the layout can be changed by explicitly setting the display CSS property of the images (and possible surrounding <a> elements) to block.

단지 이미지만 있는 테이블 셀이 <td class="imgcell">로 표시되었다면, 필요한 CSS 규칙은 다음과 같습니다:

.imgcell img, .imgcell a { display: block; }

If the table cells that contain only an image are marked with <td class="imgcell">, the required CSS rule is: .imgcell img, .imgcell a { display: block; }

더 긴 설명자료…

스타일시트가 적용되지 않아요! 이유가 뭐죠?

My style sheet doesn’t work! Why?

아래는 점검사항입니다:

HTML 문서가 맞게 작성되었는가?
Does the HTML document validate? CSS is incompatible with tag soup.
- <link>와 <style>요소가 <head>요소 내부에 있어야 합니다.
- The <link> and <style> elements should be inside the <head> element.
CSS 스타일시트가 구문체크를 통과했는가?
Does the CSS style sheet pass the syntax check?
- 0이상의 길이는 숫자와 단위(예를 들어 1.2em) 사이에 공백없이 적당한 단위가 와야합니다.
- Lengths other than zero should be followed by a proper unit without a space between the number and the unit (eg. 1.2em).
- 속성 이름과 값 사이에 사용할 문자는 등호(=)가 아닌 콜론(:)입니다.
- The character to use between the property name and the value is the colon--not the equal sign.
- <style>처럼, HTML표시는 .css 파일에 포함되지않습니다.
- HTML markup, such as <style>, does not belong in .css files.
- font-face는 실제 CSS 속성이 아닙니다. 그에 해당하는 속성은 font-familly이며 @font-face를 사용합니다.
- font-face is not a real CSS property. The property is font-family and @font-face is an at-rule.
- @import를 사용하면, CSS 파일에서 처음에 와야합니다.[내용보기]
- If @import is used, it should be the first thing in a CSS file.
CSS 파일은 text/css를 사용해서 Content-Type HTTP header 값으로 제공되는가?
Is the CSS file served using text/css as the value of the Content-Type HTTP header?
- 표준레이아웃모드에서 text/css형태로 제공되는 파일만이 CSS 스타일시트로써 처리됩니다.
- In the Standards layout mode only files served as text/css are treated as CSS style sheets.
- 사용자의 서버가 전송하는 HTTP 헤더정보를 체크하려면 Web sniffer를 사용할 수 있습니다.
- The Web sniffer can be used for checking the HTTP headers your server is sending.
클래스 이름과 id는 대소문자를 구분합니다.
Class names and ids are case-sensitive.
요소 선택자는 XML을 함께 사용하였다면 대소문자를 구분합니다.
The element selectors are case-sensitive with XML.
구조를 처리하는 스타일시트는 XML 문서 서두에서만 허용됩니다. 또한 스타일시트는 XML 문서에서만 작동하며 text/html로 제공되는 문서에서는 그렇지 못합니다.
Style sheet processing instructions are only allowed in the prolog of XML documents. Also, they only work in XML documents--not in documents served as text/html.
폭(width)과 높이(height)는 (기본적으로)<span>과 같은 치환되지 않는(non-replaced) 요소에는 적용되지않습니다.
width and height do not apply to non-replaced inline elements such as (by default) <span>.
text-align: center; 는 블록내 문단의 내용을 중앙에 배열합니다. 이것은 블록상자 자체를 중앙에 배열하지 않습니다. 블록을 포함하기보다는 블록을 더 좁히게 하는 margin-left 과 margin-right의 값에 auto와 width를 설정하여 블록을 중앙에 배열합니다.
text-align: center; centers inline content within a block. It does not (and should not) center the block box itself. A block is centered by setting its margin-left and margin-right to auto and its width to a value that makes the block narrower than its containing block.

대부분은 그렇지 않지만, 버그가 있을 수 있습니다. CSS1 설명서에 대한 모질라 버그 주석 버전를 보세요.

It is also possible, although not very likely, that you are seeing a bug. There is Mozilla bug annotated version of the CSS1 specification.

레이어가 작동하지 않아요! 이유가 뭐죠?

Layers don’t work! Why?

<layer> 는 HTML 설명서에 해당하는 않는 IE 전용 확장입니다. <layer> 는 지원하지 않습니다. <div> 요소를 대신 사용할 수 있습니다.

The <layer> element is a proprietary extension that is not part of the HTML specification. The <layer> element is not supported. The <div> element can be used instead.

자바스크립트가 작동하지 않아요! 이유가 뭐죠?

document.all와 document.layers 와 같은 일부 IE 전용 문서객체는 W3C DOM에 해당하지 않으며 모질라에서 지원하지 않습니다. 대신에 document.getElementById() 방식을 사용할 수 있습니다.

Some proprietary document objects such as document.all and document.layers are not part of the W3C DOM and are not supported in Mozilla. The method document.getElementById() can be used instead.

또한, 오래된 클라이언트 sniffer의 경우 새로운 브라우저를 봉쇄할 수 있다. 공통 API(W3C DOM) 포인트는 상호작용하며, 특정 브라우저를 점검하여 그러한 의도를 쓸모없게 만든다. DOM으로 처리할 때는 사용하려는 방식(method)와 객체가 있는 지 점검하는 게 좋다. 예를 들어 document.getElementById()가 있는 지를 다음과 같이 점검할 수 있다:

if(document.getElementById) { /* code that uses document.getElementById() */ }

Also, old client sniffers can shut out new browsers. The point of having a common API (the W3C DOM) is interoperability, and checking for a particular browser defeats that purpose. When working with the DOM, it is better to check for the existence of the methods and objects you are planning on using. For example, the existence of document.getElementById() can be checked as follows:

if(document.getElementById) { /* code that uses document.getElementById() */ }

왜 모질라는 alt 툴팁을 표시하지 않나요?

Why doesn’t Mozilla display my `alt` tooltips?

사람들이 생각하듯, alt는 툴팁이 아니라 'alternative(대체)'의 축약어이다. alt 속성값은 이미지를 대신하는 문구로 이미지를 표시하지 못할 때 표시된다.

Contrary to a popular belief stemming from the behavior of a couple browsers running on the Windows platform, alt isn’t an abbreviation for ‘tooltip’ but for ‘alternative’. The value of the alt attribute is a textual replacement for the image and is displayed when the image isn’t.

모질라는 툴팁으로써 alt 속성을 표시하지않는다. 이유는 그렇게해야 해당 속성을 오용하지 않도록 한다고 보기 때문이다.

Mozilla doesn’t display the alt attribute as a tooltip, because it has been observed that doing so encourages authors to misuse the attribute.

대체 문구가 툴팁에 보이는 경우, 일부 제작자는 잘못된 alt 문구를 사용하는 것이다. 이유는 해당 문구가 유용한 툴팁 문구로써 의도한 것이지 이미지를 대체하기 위한 것은 아니기 때문이다. ('잘못된"이라고 한 의미는 대체 문구가 이미지를 보지못하는 사용자에겐 전혀 쓸모가 없다는 것이다)
When the alternative text is shown in a tooltip, some authors write bad alt texts, because they intend the text as auxiliary tooltip text and not as a replacement for the image. (‘Bad’ in the sense that the textual alternative is less useful for people who don’t see the image.)
대체문구는 툴팁에서 보이는 경우, 또다른 제작자는 대체문구를 전혀 제공하지 않는다. 그들은 툴팁이 나타나는 것을 원치않기 때문이다. (이렇게 하는 것은 이미지를 보지못하는 사용자에게 상황을 더 어렵게 만든다)
When the alternative text is shown in a tooltip, other authors don’t want to supply textual alternatives at all, because they don’t want tooltips to appear. (Again, making things harder for people who don’t see the image.)

모질라에서 툴팁으로 보여주는 또다른 속성이 있는 데, title이라는 것이다. 실제로 HTML 4.01 설명서에는 title 속성을 툴팁으로 표시할 수 있다고 밝히고 있다. 그러나 이런 특수한 표시 방식을 요구하지 않으며 일부 다른 브라우저는 브라우저의 상태바에 title 속성을 보여준다.

There is another attribute that Mozilla shows as a tooltip: title. In fact, the HTML 4.01 specification suggests that the title attribute may be displayed as a tooltip. However, this particular display method is not required and some other browsers show the title attribute in the browser status bar, for example.

이쯤되면 일부 사람들은 뉴스그룹 또는 버그질라에다 "그러나 IE는..."이라며 게시물을 올리려고 한다. 맥킨토시용 IE 5는 alt와 title 속성을 만나게 되면 모질라와 같은 방식으로 처리한다. 윈도우즈 IE 또한 title 속성을 툴팁으로 보여준다.

At this point some people feel compelled to post a “But IE…” rant in the newsgroups or in Bugzilla. Please note that Mac IE 5 behaves in the same way as Mozilla when it comes to the alt and title attributes. Windows IE also shows the title attribute in a tooltip.

HTML이 XML 문서에서 작동하지 않는다. 이유가 뭐죠?

HTML does not work in an XML document. Why?

XHTML 마크업은 해당 요소가 올바른 네임스페이스에 있는 경우에만 인식됩니다. XHTML에 대한 올바른 네임스페이스 URI는 “http://www.w3.org/1999/xhtml”이지 HTML 4.0 설명서의 URL가 아니다. 또한 모든 XHTML 요소와 속성 이름은 소문자로 처리되어야 한다.

XHTML markup is recognized as such only if the elements are in the right namespace. The correct namespace URI for XHTML is “http://www.w3.org/1999/xhtml”--not the URL of the HTML 4.0 specification. Also, all the XHTML element and attribute names have to be in lower case.

모질라는 다운로드가능한 글꼴을 지원하는가?

Does Mozilla support downloadable fonts?

다운로드가능한 폰트는 지원하지 않습니다.

Downloadable fonts are not supported.

다운로드가능한 글꼴은 과거 브라우저에서 적절한 지원이 없었기 때문에 글작성시스템(writing systems)을 사용하는 사이트에서 대부분은 사용되었다.ㅏ 이들 사이트(예를 들어 일부 인디언 사이트)는 엉뚱한 라틴어 표기로 텍스트를 코딩하여 브라우저와 운영시스템에는 라틴포트로 보이지만 그러나 Devanagari glyphs 형태를 글꼴을 사용한다. 이렇게해서 맞지않는 라틴어 표기는 사람이 어떤 언어로 문장을 읽도록 글꼴을 처리하는 것이다. 동일한 접근방식이 그리스 문자를 포함하는 라틴 기반의 문장으로 수학 공식을 사용하는 데 사용되고 있다.

Downloadable fonts are usually used on sites using writing systems for which proper support has been missing in browsers in the past. These sites (for example some Indian sites) code the text in Latin gibberish and then use a font that to the browser and operating system seems to be a Latin font but has eg. Devanagari glyphs, so that when the Latin gibberish is rendered with the font it seems to a human reader to be intelligible text in some language. The same approach has been also been used for including Greek letters as math symbols in otherwise Latin-based text.

분명히, 그런 땜방식처리는 유니코드를 인식하는 브라우저가 엉뚱한 라틴어를 그렇게 처리할 경우에 문제가 된다(왜냐하면 유니코드입장에서는 해당 파일로 코딩되어 있기 때문이다). 다운로드가능한 글꼴을 제공하는 대신에 모질라는 실제 문제에 대해 밝히고 있으며 다양한 유니코드를 지원하고 있다.

Obviously, that kind of ad hockery falls apart when Unicode-savvy browsers come along and render Latin gibberish as Latin gibberish (since that’s what is coded in the file from the Unicode point of view). Instead of providing support for downloadable fonts, Mozilla is addressing the real issue: support for various Unicode ranges.

그러나 일부 플랫폼에서 인도 스크립트 지원관련하여 버그가 존재한다. 예를 들어 맥 OS X에서 모질라는 시스템에 있는 Devanagari 글꼴을 사용하지 않지만 TITUS Cyberbit와 같은 제3자 글꼴을 사용할 수 있다.

However, there are still bugs related to support for Indic scripts on some platforms. For example, on Mac OS X Mozilla does not use the Devanagari font that comes with the system but can use a third-party font like TITUS Cyberbit.

모질라 유니코드 지원에 대한 많은 작업이 이루어졌다. 크로스-플랫폼 방식으로 다운로드가능한 글꼴 지원은 많은 작업이 이루어져야 할 것이며 수많은 특허문제를 살펴보아야 하는 데 그에 대한 보상은 작다는 것이다. non-ISO-8859-1 문자처리를 위해서 모질라는 이미 유니코드 지원을 제공하고 있는 데, 각 사이트에서 개별적으로 유사-라틴 다운로드 글꼴을 사용하는 것보다는 결국에 있어서는 더 나은 접근방법이다.

A lot of work has been put into Mozilla’s Unicode support. Supporting downloadable fonts in a cross-platform way would also be a lot of work and would potentially require navigating past a bunch of patents but the rewards would be small. For the purpose of rendering non-ISO-8859-1 characters Mozilla already provides Unicode support that, in the long run, is a lot better approach than using pseudo-Latin downloadable fonts separately on each site.

모질라는 XSL을 지원하는가?

Does Mozilla support XSL?

모질라는 XSLT를 지원하지만 XSL-FO은 그렇지않습니다.

Mozilla supports XSLT but not XSL-FO.

모질라 레이아웃 엔진은 CSS 포맷 모델처리하도록 만들어졌다. CSS는 구조적 마크업 HTML이나 사전에 출력기기에 대한 물리적인 속성을 알지않더라도 상호작용 프로그램 내 HTML유사 문서에 매우 적합합니다. 즉, CSS는 웹브라우저에 매우 적당합니다.

Mozilla’s layout engine is designed to work with the CSS formatting model. CSS is well-suited for styling structurally marked up HTML or HTML-like documents in interactive applications without having to know the physical properties of the output device in advance. That is, CSS is well suited for Web browsers.

모질라는 내가 의도한 대로 페이지를 처리하지 못하는 이유는 무엇인가? 페이지가 표준을 따르지않지만 괜찮은 브라우저라면 제작자가 어찌되었든 의도한대로 처리를 해야하는 것 아닌가!

Why isn’t Mozilla rendering my page as I intended? So my page isn’t standards-compliant, but good browsers should render pages as the author intended anyway!

제작자는 웹표준을 사용해서 그들의 생각을 전달해야 합니다. 그렇지 않으며 각각의 제작자의 의도를 찾아낸다고 하는 것은 소프트웨어에서는 이룰 수 없는 영적능력을 요구하게 될 것입니다. 인간소프트웨어가 그 의도를 추론할 수 있는 경우라도, 그렇게하는 것은 매우 느리며, 버그를 포함하게 되고, 어렵고 복잡해지게 됩니다.

Authors are supposed to communicate their intentions using the Web standards. Otherwise, finding out the intentions of each particular author would require psychic abilities which can’t be implemented in software. Even in cases where a human could deduce the intention, doing so in software would be very slow, bug-inducing, difficult and complicated.

대부분의 반론은 생각할 필요도 없는 것입니다. 즉 모질라는 x라는 브라우저가 하는 무엇이든 해야한다(여기서 x는 반론을 주장하는 사람이 자주 사용하는 비-모질라 브라우저를 말합니다). 그러나 생각해볼 수 있는 모든 경우에서 x라는 브라우저가 하는 무엇이든 처리한다는 것은 말로는 그렇다하더라도 그리 단순한 것이 아닙니다.

The usual counter argument is that there is no need to guess--Mozilla should do whatever browser x does (where x is the favorite non-Mozilla browser of whoever is presenting the counter argument). However, doing whatever browser x does in every conceivable case isn’t simple at all, even though it might appear to be simple when presented as a passing remark.

x라는 브라우저도 사람마다 제각각입니다. 두번째 문제는 웹제작자가 표준을 비껴가는 것도 참으로 제각각입니다. 사실, 브라우저에 쏟아넣는 내용을 헤아릴 수 없어서, 표준을 비껴가는 수는 헤아리 수 없는 정도입니다. 따라서, 모질라가 x라는 브라우저가 모든 내용을 처리하는 대로 정확하게 반응하는 지 테스트해본다는 것은 불가능합니다. (마찬가지로, 표준 자체의 다른 기능들은 연결방식의 수는 한계가 없으며, 연결방식은 소프트웨어의 품질보장을 어렵게 만듭니다.)

Different people have different ideas about what x should be. The second problem is that Web authors are very creative in coming up with different ways of deviating from the standards. In fact, since the input to the browser can be of arbitrary length, there is no upper bound for the number of distinct ways of deviating from the standards. Therefore, it is impossible to test whether Mozilla reacts exactly like browser x to every possible input. (Likewise, there is no upper bound for the number of ways different features of the standards themselves can be combined, which makes software quality assurance challenging.)

일부 표준을 따르지않는 입력내용에 대해 x라는 브라우저가 대응하는 방식이 모두 생각대로는 아니라는 것입니다. 의도한대로 나타나지 않는 것은 복잡한 프로그램내에서 알 수 없으며 생각하지 못한 상호작용 때문입니다. x라는 브라우저에 대한 소스 코드를 가지고있더라도, 프로그램내의 하나 이상의 알 수 없으며 생각지 못한 상호작용을 변경하게 되면 무언가를 변경할 수 밖에 없습니다.

Also, the ways in which browser x reacts to some standards-incompliant input are not all intentional. Some of the reactions are due to unknown and unintentional interactions within a complex program. Even if you had the source code for browser x, you couldn’t change anything without risking changing one or more of the unknown and unintentional interactions within the program.

일반적인 반론은 모질라가 모든 가능한 사례에서 x브라우저 행동을 맞출 필요가 없으며 단지 이야기되고 잇는 공통적인 경우에만 맞추면 되지않느냐는 것입니다. 그러나 모질라는 이미 그러한 공통분모를 처리하고 있습니다 모질라의 표준방식은 동일한 표준을 올바르게 처리하는 다른 브라우저와 호환되고 있다. 다른 한편으로, 모질라 쿼크방식은 일반적인 구버전의 브라우저의 처리방식 때문에 생기는 공통 비-표준을 이미 처리하고 있다.

The usual counter argument is that Mozilla doesn’t need to match the behavior of browser x in every possible case but only in the alleged common cases. However, it turns out Mozilla is doing that already. Mozilla’s Standards mode is, obviously, already compatible with other browsers that implement the same standards reasonably correctly. On the other hand, Mozilla’s quirks mode already accommodates common non-standardisms that are due to the behaviors of common legacy browsers.

역-엔지니어링에 시간과 노력을 쏟고 구버전의 브라우저를 복제하는 대신에, 표준을 처리하는 데 중점을 두는 것이 더 의미있는 것입니다. 다른 브라우저도 표준을 준수할 때 표준은 버그 투성이의 구버전 소프트웨어를 복제하는 것도 더 나은 상호작용을 할 수 있게 해줍니다.

Instead of putting time and effort into reverse-engineering and cloning legacy browsers, it makes more sense to focus on implementing standards. Standards (when implemented by others as well) promote interoperability better than cloning legacy software bug by bug.

찾고있는 답변을 못찾고 있습니다. 어디에다 질문하죠?

I didn’t find the answer I was looking for. Where should I ask?

뉴스그룹 comp.infosystems.www.authoring에 여러분의 질문을 해보세요. 여러분의 질문이 자바스크립트/ECMA스크립트 또는 DOM에 관한 것이면, 먼저 FAQ를 읽어본 후에 comp.lang.javascript에 해보세요. 모질라 개발에 대해 토론을 위도로 뉴스그룹에 웹제작 질문을 하지 말아주세요.

Try asking in the newsgroup relevant to your question in the comp.infosystems.www.authoring.* hierarchy or, if your question is about JavaScript/ECMAScript or the DOM, in comp.lang.javascript (after reading the group FAQs first, of course). Please do not ask Web authoring questions in the newsgroups intended for discussion about the development of Mozilla.

작성자 Henri Sivonen (이 주소로 웹제작 질문은 말아주세요)