Mozilla 한국 커뮤니티

한국 소프트웨어 진흥원에서 의뢰해서 작년에 한참 작업한 Cross Browsing 가이드를 웹버전으로 만들었습니다. 이 가이드는 여러 웹브라우저이 차이점을 살펴보고 표준적인 방식을 통해 접근성을 높일 수 있도록 웹개발자나 웹디자이너를 위해 쓰여진 가이드 입니다. KIPA에서는 이 가이드를 각 공공기관에 배포할 예정입니다.

KIPA에서 가이드가 나올때 까지 기다렸다 배포하려고 했는데 너무 늦어지는 군요.
우선 웹 표준 제작 TIP 가이드를 만들기 전에 참고할 문서로 적당할 것 같습니다.

틀린 부분이나 더 넣었으면 하는 부분이 있으면 꼭 집어 주십시오.
http://www.mozilla.or.kr/docs/web-developer/standard/

차니

체계적인 피드백은 아니고, 그냥 눈에 띈 것 몇 개만 씁니다.

가. 용어 정리
1. 문자셋, 문자 코드, 문자 코딩 등이 섞여 있습니다. W3C에서 Character Encoding이란 용어를 일관성 있게 사용하므로 이 문서에서도 문자 인코딩이라고 하는 것이 좋겠습니다. W3C I18N WG의 CharMode 문서를 참고하세요.

2. 'W3C DOM 레벨 1 권고'는 단어를 1:1로 옮겼네요. 'W3C DOM 1 수준 권고안'이라고 하는 게 낫겠지요?

3. 문서의 어느 부분에서는 javascript라고 했다가 다른 부분에서는 ECMAscript라고 해서 독자를 헛갈리게 합니다. 처음 도입할 때 둘의 관계를 설명하고, 그 이후에 일관성

3. 문서의 어느 부분에서는 javascript라고 했다가 다른 부분에서는
ECMAscript라고 해서 독자를 헛갈리게 합니다. 처음 소개할 때
둘 사이의 관계를 설명하고, 그 뒤에는 한 가지만 사용하거나
계속 ECMAscript/Javascript라고 쓰십시오.

4.

나. 참고 문헌

문서 중간 중간에 참고 사이트가 흩어져 있어서 혼란스럽습니다. 중간에
언근했다고 해도 문서 맨 마지막에 정리해 놓으면 좋을 것입니다. 또,
인용한 W3 문서의 한국어 번역판에 대한 링크도 넣으세요.

<a href=http://www.w3.org/WAI target=_blank>http://www.w3.org/WAI</a> : 개별 문서만 언급하지 말고,
WG 홈페이지를 언급할 필요가 있음.
<a href=http://www.w3.org/International target=_blank>http://www.w3.org/International</a> : W3C I18N WG
(국제화 관련 FAQ와 팁 모음)
<a href=http://www.w3c.or.kr/Translation target=_blank>http://www.w3c.or.kr/Translation</a> (W3C 문서 번역 모음)
<a href=http://www.gregshin.pe.kr target=_blank>http://www.gregshin.pe.kr</a> (WAI 관련 한국어 번역판과
웹 접근성 관련 다른 자료)
<a href=http://www.anybrowser.org target=_blank>http://www.anybrowser.org</a> (any browser campaign site)
<a href=http://www.webstandards.org target=_blank>http://www.webstandards.org</a> (웹 표준 준수 운동)
<a href=http://www.cross-browser.org target=_blank>http://www.cross-browser.org</a> (cross browser용 라이브러리)

W3C validator에 대한 링크가 잘못 되어 있습니다. validation.w3.org가
아니라 validator.w3.org로 해야 합니다.

또, 문서 끝에 용어집을 넣을 수 있으면 좋겠습니다.


다. 잡다한 몇 가지

1. Tim Berners-Lee가 장치 독립성, 상호 운용 가능성, 웹 표준 준수의 필요성에
대해 한 말을 두어 가지 인용하는 것도 좋겠지요.

"Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network."

-Tim Berners-Lee in Technology Review, July 1996
2. 글꼴 설정을 할 때, 한국어판 Windows 사용자 기준으로 '굴림, 돋음' 등만
쓰는 것은 문제가 있음을 언급하십시오. 즉,

font-family: 돋음

이라고 하면 안 되고, 다음처럼 해야 합니다.

font-family: 돋음, Dotum, Baekmuk Dotum, Undotum, Apple Gothic,
Latin font, sans-serif

꼭 맨 끝에 CSS generic family 이름을 더해야 합니다. 돋음과 Dotum을
같이 써야 하는 이유는 비한국어 Windows (최소한 9x/ME)에서는 MS IE조차도
'돋음'을 인식하지 못 하기 때문입니다. Apple Gothic은 Mac OS X에
들어 있는 sans-serif에 해당하는 한국어 글꼴 이름입니다. 표 4에서
라틴 글꼴을 비교한 표가 있는데, Windows Corefonts는 다른 OS에서도
사용할 수 있습니다. (<a href=http://corefonts.sf.net)
target=_blank>http://corefonts.sf.net)
</a>

3. 접근성 향상에 대한 절에서 한국어 번역판 문서
(<a href=http://www.gregshin.pe.kr/wcag)에 target=_blank>http://www.gregshin.pe.kr/wcag)에</a> 대한 링크를 걸고,
거기 있는 내용은 좀 줄이는 것이 좋겠습니다.

4. 2.3 절의 맨 마지막 문장은 해석을 못 하겠는데요
> 브라우저의 특이성은 당연히 존재하는 것이며 이러한 특징들을 알아두고
> 확인하여 최대한 표현하고자 하는 컨텐츠 형태로 출력하는 것 이 중요하다.

내용과 표현 방식 분리의 중요성에 대한 언급이 빠진 듯 합니다. 이 점을 강조할 필요가 있습니다.

5. 2.4에서 다음 구절 :

컴퓨터 과학 연구소(MIT LCS), 유럽의 정보수학유럽연구컨소시움(ERCIM)

이미 모질라 번역에서 지적한 바와 같이 명사를 연달아 쓸 때 - 특히, 기관명
등에서 - 붙여 쓰는 것을 (원칙은 아니지만) 허용합니다. 하지만, 바로 앞뒤에
나오는 두 기관 이름을 쓰면서 하나는 단어별로 띄어 쓰고, 다른 하나는 몽땅
다 붙여 쓰면 일관성이 없지요. '유럽 정보 (과학) 및 수학 연구 컨소시엄'이라고
하면 좋지 않을까요? 그리고, 약어나 acronym을 쓸 때에는
acronym이나 abbr을 쓰고 title 속성에 풀어 써 주어야 합니다. (WCAG 1.0에
있는 내용입니다.)

> 웹에 관련한 표준에는 우리가 흔히 말하는 표준(Standard)은 존재하지 않으며,
> W3C의 토론을 통해 나온 권고안(Recomendation)이 가장 최상위 이다.

'흔히 말하는 표준'이 모호하지 않나요? ISO나 ECMA, KSA, JIS, ANSI, DIN
등 국제 및 국가별 표준 기관에서만 표준을 만들 수 있다고 하면
IEEE, Unicode Consortium, IETF, W3C 등에서 만든 수많은 표준은
뭐냐는 얘기가 나오거든요. W3C의 권고안은 IEEE, Unicode, IETF
등에서 만든 표준이 표준인 것과 마찬가지 의미에서 표준이라고 해야할
것입니다.

> 표준의 종류에는 제안된 표준(Draft), 작업하는 표준 (Working Draft, WD),
> 확정될 권고안(Candidate Recommendation, RC), 확정된 권고안(Recommendation)이
> 있다.

Working draft를 '작업하는 표준'이라고 하는 것은 이상합니다.
더구나, 정작 최종 표준인 Recommendation은 '권고안'이라고
하면서 'working draft'를 '작업하는 표준'이라고 '표준'이라는 단어를 사용하면
안 되지요. 또, 표준의 '종류'라는 표현은 이들 모두가 표준인 듯한 인상을
주고 있습니다. 다음 단락에서 최종 권고안 제정 절차를 설명하고 있으니까,
위 단락은 아예 없애는 편이 낫겠습니다. 혼동과 오해의 소지가 많습니다.

> IE는 지원하는 표준의 종류만을 보자면, 다른 두 가지 브라우저보다 더
> 뛰어납니다. 그러나, 지원하는 표준이 Recomendation이 아니라는 데 문제가 있다.

첫번째 문장의 보기를 들어 주시겠어요? 그리고, 최종 권고안을 지원하지
않는다면 그것은 표준을 지원하는 것이 _아닙니다_. 즉, MS IE는 표준을
제대로 지원하지 않는 셈입니다.

> Javascript는 표준으로 제정된 것은 아니다. 또한, 모든
> 웹브라우저 사용자가 JavaScript를 볼 수 있는 것은 아니다.

Javascript는 모든 브라우저가 지원하지 않으므로
대안을 마련해야 한다는 얘기는 맞지만, 첫번째 문장은 전적으로
맞는 것은 아니지요. ECMA가 ECMAscript로 언어를 표준화했고, ECMA
262는 (<a href=http://www.ecma.ch) target=_blank>http://www.ecma.ch)</a> ISO 표준으로 채택되었습니다.

> 통상적인 웹브라우저는 meta 태그를 통해 선언되어
> 있지 않더라도 문자코딩을 자동적으로 감별하여
> 표시하지만 Mozilla는 그렇게 하지 않는다. 따라서
> meta태그의 charset을 euc-kr 등으로 아래와 같이 지정해 주어야 한다.

이것은 모질라에만 해당하는 얘기가 아닙니다. 모질라 역시 인코딩
자동 감별을 합니다. View | Character Coding | Autodetect 메뉴를 보세요.자동 감별을 하든 하지 않든 문자 인코딩을 적시하는 것은 대단히
중요하고, 꼭 해야 할 일입니다. 왜냐하면, 통계적 방법을 쓴
문자 인코딩 감별은 항상 성공하리란 법이 절대 없으니까요. Basis
Tech 등에서 만든 전문 상업용 인코딩 감별 프로그램은 99% 성공한다고
하지만, 브라우저에서는 그런 프로그램을 채택할 수 없습니다. 어쨌든,
100% 성공한다고 해도 명시해 주어야 합니다. 그렇지 않으면 유효한
html/xhtml로 여겨지지 않습니다. 또, CSS에서 문자 인코딩 지정
방법도 언급하시기 바랍니다. 마찬가지로 xhtml/xml에서 지정 방법도
언급하세요.


> 자바스크립트를 사용할 때는 script 태그에 LANGUAGE="JavaScript"를 선언해
> 주거나 type="text/javascript"를 사용해 준다

두 개 중 하나만 사용하려면 후자만 사용해야 합니다. 전자는 HTML 4.x strict
에 들어 있지 않습니다. 옛 브라우저를 위해서 둘 다 사용하는 것이 좋은
생각입니다.

> IE와 다른 브라우저 사이에 흔하게 발생되는 에러는
> W3C DOM이 아닌 MS DOM을 사용하는 경우 때문이다. 특히,
> 객체를 구별할 때 쓰이는 document.layers[] (Netscape4 사용),
> document.elementName (예를 들면 , 요소 <p name="yooneek" /> 에의
> 참조를 취득하는 경우 document.yooneek), document.all[] (IE에서
> 사용) 하는 방법은 W3C DOM이 모두 지원하지 않는다. 표준
> 방식은 document.getElementById("yoone")을 사용하여 구별한다.

한국 웹 개발자가 옛 브라우저를 얼마나 고려할 지 모르겠지만, MS IE 4와
NS 4.x에서는 getElementById()를 지원하지 않으므로, 대안을 제시하는
것도 좋은 생각이고요.

또 다른 것도 썼는데, 잊어 버렸네요. 생각나면 또 적지요.

유용한 페이지입니다마는 역시 다루는 주제가 광범위하니 잡다하게 될 가능성이 크네요.

- 크로스 브라우징은 거시적으로 볼 때, 표준을 엄격히 준수함으로써 이루어질텐데, 전체적인 글의 뉘앙스가 IE의 비표준에 대해 관대한 반면, 그 외의 브라우저엔 엄격하네요.

- Netscape에 대한 (특히 6이상의 버전) 언급은 삭제하고, 모질라로 대체했으면 합니다. 이름값은 있지만 Netscape는 죽었습니다.

사소한 띄어쓰기 오류나 오타 외에, 저도 몇 가지 수정하고 싶은 부분이 있는데, 위키 페이지로 만드시면 좋을 듯합니다.

예, 위키가 있으면 매우 편리하겠군요.

자잘한 문제점 몇 가지 더 지적합니다. :

표 1이나 다른 곳에서 보면 netscape를 가리킬 때 NS와 NN을 섞어 쓰고 있습니다. 한국 이외의 곳에서 NN을 쓰는 걸 본 적이 없습니다. NS로 통일하는 편이 좋겠습니다. Mac용 IE는 Windows용 IE와 상당히 다릅니다. Mac용 IE를 표 1에 넣어야 합니다. gif89가 표 1에 들어 갔는데, 그렇다면 png도 넣어야겠지요. 또, 표 1에서 'JScript'도 'javascript'로 바꾸세요. CSS의 경우 단순하게 지원 여부 정도만 표시해서는 안 되겠지요. 전혀 지원하지 않음, 초보적 지원, 비교적 잘 지원, 아주 잘 지원 정도로 나누세요. 또, 표 1에 모든 내용을 담을 수 없으므로 브라우저 기능 비교를 아주 상세하게 해 놓은 사이트를 참고 문헌에 넣어 줄 필요도 있고요.

> 최신의 HTML 표준은 4.01이며, HTML을 XML과
> 결합한 XHTML이 권고안으로 나와 있다.

위 문장만 보면 HTML은 '표준'이고 XHTML은 그보다 못한 '권고안'인 것 같은 잘못된 인상을 줍니다. 사실, HTML 4 최종 권고안을 발표한 지가 이미 5년이 넘었고, XHTML 1.0도 꽤 오래 전에 나왔지요.

> 오페라도 비슷한 정도로 표준을 지원해 주지만, 빠른 > 속도를 유지하기 위해 MathML 등을 제대로
> 해석하지 못하기도 한다.

속도와 MathML 지원 여부는 거의 상관이 없는 문제 같은데요. (설령 상관 있다고 해도 MathML을 쓴 페이지가 과연 전체의 몇 퍼센트나 되겠습니까?) Opera가 MathML을 지원하기는 합니까? MathML을 native하게 지원하는 브라우저는 모질라와 W3C의 Amaya 밖에 없는 줄 알았는데요.

졸작에 진심어린 충고 감사합니다. KLDP DOC에 올려보도록 하겠습니다. 거기서 좀 수정을 하도록 하죠~

KLDP의 어디에 올리셨나요?

KLDP Wiki로 이름이 바뀌었고, 위 내용은 벌써 상당 시간이 지났는데 수정 여부에 대한 첨언이 없는 것 같습니다.

문서를 잠깐 보니 위의 몇가지 제안이 받아들여지지 않은 것 같습니다.

어떻게 되었나요?

http://www.dithered.com/javascript/

이 라이브러리가 매우 유용한 것 같습니다. Creative Commons License라서 쓰는데 제약도 적고요. DOM과 event를 다룰 수 있는 cross-browser library입니다.

DOM과 Javascript 에서..

흔히 위와 같은 FORM 객체를 사용할 때 document.forms("userid")으로 표현하는 실수를 할 때가 있 다. document.form은 메소드가 아니라 배열이기 때문에 document.forms[0]로 표현하는 것이 정확하다. 또는 document.form.userid로 표현한다.

document.forms 와 document.form 가 혼용되어 사용되고 있습니다.
네군데 모두 document.forms 가 올바른 것으로 알고 있습니다.
확인 부탁드립니다.

해킹 당한 듯..
링크를 클릭하면..

r00t_System INSIDE by LordX owned mozilla hehehe help? lordxdfv[a]gmail.com or rsy in gigachat.net

이런 게..

http://www.mozilla.or.kr/docs/web-developer/standard/ 여기 크랙당한 듯 합니다. 얼른 복구해주시길...

http://www.mozilla.or.kr/docs/web-developer/standard/
클릭하면
Simies Crew ownz u viva os macacos
처럼나옵니다.

해킹당한건가요?

복구해주실수 있을까요;?

차니 wrote: http://www.mozilla.or.kr/docs/web-developer/standard/

2005년도 개정판이 나왔습니다. 많이 참고 해 주세요.

차니 wrote:

차니 wrote: http://www.mozilla.or.kr/docs/web-developer/standard/

2005년도 개정판이 나왔습니다. 많이 참고 해 주세요.

수고 많으셨내요. 별도 게시물로 올리거나 메인 화면쪽에서 쉽게 접할 수 있었으면 합니다.

그리고 대충 살펴보았는 데, 일부 단어의 경우 번역이 아닌 [발음표기] 방식으로 했더군요.

[인덴트]의 경우는 들여쓰기를 말한 것같았고 [수도]는 유사/의사로 하거나 영문과 함께 표기하여 혼란을 줄여주면 초보자나 개발자에게 도움이 될 듯합니다.

인덴트(Indent)와 수도(Pseudo)

이 작업에 참여하신 모든 분들에게 감사드립니다.

올 한해 한국내 모질라 커뮤니티의 성과는 [웹표준화 관련 실무 자료집]이 여러 형태로 그리고 만박님의 도서출간 등, 웹표준을 위한 기반 작업을 하였다는 점에서 [의미있는 한 해]인 듯합니다.

차니 wrote:

차니 wrote: http://www.mozilla.or.kr/docs/web-developer/standard/

2005년도 개정판이 나왔습니다. 많이 참고 해 주세요.

급하게 배포하느라고 교정할 틈이 없어서 오탈자가 좀 눈에 띄네요. 시간 날 때 같이 고쳐야겠습니다.

한두 가지 눈에 띈 점 (배포 전에 얘기하려고 했는데, 깜박 잊고 얘기하지 못 했습니다.)이 있어 적어 봅니다. Javascript 부분에서 event 처리를 브라우저 독립적으로 해 주는 라이브러리에 대해 언급했으면 좋겠습니다. 또, modal window를 띄울 때, showModalDialog를 MS IE만 지원하는 문제를 해결하기 위한 방법도 소개했으면 좋았겠지요. 아래에 있습니다.

viewtopic.php?t=2478

viewtopic.php?t=2236

HTML 커멘트를 다는 방법(혹은 잘못된 관행)은 Javascript 부분이 아니라 HTML 부분으로 옮기는 게 나을 것 같고요. 또, CSS, Javascript, HTML, XML에서 커멘트를 다는 방법을 해당 부분에서 설명하고, HTML 커멘트 방식을 CSS에서 쓰는 일(또는 반대)이 없어야 한다고 언급하면 좋겠습니다.

참, PDF를 만들기 전에 MS Word 문서에서 장, 절 등의 제목에 어떤 스타일을 사용하셨나요? HTML의 H1, H2 등에 대응하는 Word의 '뭔가'를 썼다면 Distiller가 자동으로 알아서 장, 절 등에 책갈피를 만들어 준다고 하던데, 현재 PDF 판에는 그게 없는 것으로 보아서 뭔가 따로 만드신 모양입니다. H1, H2에 해당하는 것으로 바꿔서 Distiller를 다시 한번 돌리면 좋겠습니다.

참, 얼마 전에 관련된 글을 썼는데, 다음에 개정할 때에는 Prince를 써서 만들면 좋겠습니다. 이것을 쓸 경우 HTML+CSS로 웹용과 인쇄용을 쉽게 만들 수 있습니다. 한글도 잘 처리하더군요. (저 혼자 쓴다면 그냥 DocBook이나 LaTeX으로 하겠지만, 그것은 좀 무리일 듯 싶고, HTML+CSS라면 좋은 공통 분모일 듯 싶습니다.) 그 얘기를 하다 보니까 생각이 났는데, 색인이 없는 것도 아쉽군요. MS Word로 색인을 넣기가 힘든가요? LaTeX이라면(DocBook도 아마 쉬울 것입니다.) 쉬운데....