모질라를 지원하는 스크립트 만들기 어렵다?

행복한고니의 이미지

phpschool 에 있던 글을 옮겨옵니다.

이게 최초의 글...

Quote:
불여우로는 옥션이 보이질 않네요..
제품 상세보기 해도.. 나오지도 않고/...........
저만 그런건 아니겠죠?

그에 대한 답글...

Quote:
모질라 계열의 가장큰 문제점은
제품명이나 이름클릭시 왼쪽팝업식으로 나타내 주지 못한다는것이죠...
싸이월드 같은 포탈들이나 검색사이트들의 왼쪽팝업구현이 안되서 가장 큰 문제가 되고 있습니다..
제로보드도 그렇고 왠만한 게시판들도 그런 기능들이 추가가 되고 있는데 그 부분의 스크립이 지원이 안된다면 앞으로 사용자 층이 두터워 지기란 힘들듯 싶네요..

스크립지원이 부족해도 그것만은 지원이 되야 우리나라에서는 경쟁력을 가질거라 생각됨.

이제 그 아래가 코멘트들

Quote:
행복한고니
그건 스크립트 만드는 사람들이 못만들어서 그런거지 모질라의 문제가 아닙니다. 왼쪽 팝업식이라는게, 제로보드 회원이름 클릭하면 나타나는 레이어를 말씀하시는거 맞죠? 100% 만든 사람들이 제대로 만들지 못했기 때문에 발생하는 문제일 뿐입니다.

닉네임
//행복한..
근데 우리나라에서는 만들수 있는사람이 없나보죠?
싸이월드나 네이버, 옥션, 한메일등 전부 안되는데...
님이 좀 가서 알려주세요..

낭만이
알려주면 들은척이나 한답니까~
해봤는데 100이면 90정도는 이렇게 말합니다...
"익스플로러 쓰세요!"
이럼 대화가 끝난거죠~

닉네임
//낭만이 좀 상식적인 답변을 하시기 바랍니다..
저정도 국민 포탈을 만드는 사람들이 님정도 생각못해서 익스만 되게 만들었을까요? 흠...
어느 사이트든 하나만 링크해 보면 인정하겠습니다..
한게임 같은 조금 복잡한 사이트는 아예 암것도 작동이 안됩니다.
어느브라우져가 좋다 나쁘다를 따지려는게 아니라 현실적으로 모질라가 정착 되려면 해야할게 너무 많습니다...
현재로써는 단순 서핑정도입니다..

행복한고니
닉네임 // 그 사람들 정말 생각 못해서 그럽니다.
서비스 처음 시작할때만 해도 지금처럼 비IE 브라우저가 강세가 아니어서 IE만 생각해서 만들었다가, 지금은 사용자들의 요청에 조금 변하고 있는 모양이지만, 너무 더딥니다.
그 사람들이 IE만 보고 만들어낸 스크립트와 페이지 덕에 꼭 모질라 계열 브라우저가 "좋지 않은" 것처럼 인식되고 있는 것이죠. "만들 수 없는" 지는 잘 모르겠지만, 확실한 것은 "만들 의지가 없다" 는 것입니다.

간단하게 네이버 블로그에 쓰인 웹에디터만 보더라도 이미, FCKEditor 나 Gmail, HTMLArea 등에서 충분히 다양한 브라우저를 지원할 수 있음이 밝혀졌죠? 그래도 네이버에서는 여전히 쓸 수 없습니다.

예전 한때는 네이버에서 검색도 제대로 할 수 없었던 적이 있습니다.
또하나? 지금 IE로 네이버 메인에서 검색하면 추천검색어 뜨죠? 그거 이미 Google suggest 에서 몇개월 전부터 하던 겁니다. 다른게 있다면 네이버는 IE전용, 구글은 대부분의 브라우저에서 가능하다는 거겠죠.

분명 가능한 일임에도 불구하고 하지 않는 것이 바로 우리 포털의 현실입니다. 상식이 통하지 않는 사람들에게 상식을 적용하지 마세요. "상식적인 추측"을 하지 마시고, 직접 보세요.

P.S// 한게임은 어차피 ActiveX를 이용한 곳이라 서핑이 되나 안되나 똑같지 않나요?

닉네임
//행복한 고니 님말씀 처럼 뜯어 고치려고 계속 수정하다 보면 근사 값까지 갈 수 있을지 모르나 다른 기능들과의 의존성 문제로 그냥 포기해 버리는 경우가 생깁니다...
울 회사가 모질라 90% 브라우져이고 저하고 사장님만 윈입니다..
다 개발해 놓고 막판 테스트때 모질라가 작동을 잘 하지 않는 바람에 뜻어 고치는 경우가 초반에 많이 있었습니다...
지금은 처음부터 확인을 하지만 자료찾다가 시간다 보냅니다..
아니면 빠르게 할수 있어도 우회해서 한다거나 암튼...
글고 한게임은 activex를 모질라에서는 설치해서 사용할수도 없고 캐릭터든 기타 웹페이지부분이 스크립지원부족으로 나타나지도 않습니다... 님께서는 있다고 할지 모르나 있어도 너무 형편없이 돌아가는것들이 많고 또한 찾기도 힘들고 알고리즘을 아예 개발팀을 두어서 네스케입쪽으로 스크립을 만들게 해야 할겁니다..

복학생
닉네임//답답하군요. 스크립트 지원 부족이 아닙니다.
익스가 변형을 만들어낸것일 뿐이고 그 외의 브라우져는 모두 표준을 지킵니다. 닉네임님의 회사에서 막판 테스트때 모질라가 작동하지 않은것이 아니라 표준에 맞지 않는 익스에서만 가능한 코드를 사용하였기 때문입니다. 표준에 맞는 코드를 사용했더라면 익스와 모질라등등 여러 브라우져에서 모두 실행이 됩니다.

찾기 귀찮다는 이유로..그동안의 습관이라는 이유로 표준에 맞지 않는 코드를 사용해놓고 "모질라가 작동을 안하네" 라는건...ㅡㅡ;

닉네임
//복학생 논리중에 가장 답답한 논리는 증명해 보이지 못하고 말로 있다라고 말하는것이죠..
모질라쪽개발을 해 보시기나 해 봤습니까?
어느정도 되야 맞추어서 개발하던가 하죠??
천태만상 시간이 남아 도는것도 아니고..
위에 포탈사이트들도 되는데 안하는겁니까?
짜고 하지 말자고 한건가요? 우리나라 싸이트들중에 구현 되는 사이트 하나도 있지 않습니다.. 말로 떠들지 말고 링크해 보시던가... 정말 말을 굉장히 짜증나게 표현하는군요..

일단 제 주장은...
모질라에서 개발하는 거 그리 어렵지 않다. 입니다. CSS와 DOM에 대한 기본적인 이해만 있으면 충분히 가능하다고 보는데요, 포탈에서 사용하는 스크립트 중에 IE가 아니면 도저히 안될만한 거라거나(ActiveX제외), 모질라 계열에서는 너무 힘든방법으로만 되어야 하는게 있을까요? 그런게 있다면 어떤게 있을까요?

stadia의 이미지

다음 플래닛이나 블로그에 가보세요.
레이어 메뉴 잘 뜹니다.
라고 해주세요.

랜덤여신의 이미지

IE 는 뭐든지 일관성이 없어서... -_-;
짜증나요...

ctcquatre의 이미지

솔직히 만들기 어렵습니다.
제가 외국에 살면 모르겠지만.
한국에 사는이상 자바스크립트 문서들 보면 모조리 익스 전용입니다.
전적으로 제 실력의 부족이라 모질라계열에서 자바스크립트를
표준에 맞게 쓰지 못하는게 이유지만.

변명으로 문서에 의존해서 이것저것 구현하는 관계로
어렵게 느껴집니다. :(

오늘도 자바스크립트작업을 하는데 모질라를 지원하게 만들려고 아무리
문서를 찾아보고 해도.. 힘들더군요.
결국 제가 할수있는건 alert으로 모질라사용자분들께 죄송하다는 말을 남겨놓을 뿐입니다.

물론 중요한 기능은 무슨일이 있어도 양쪽 다 되게 해야겠죠.
제가 말하는건.. 좀 사용자를 편하게 해주는 기능들에 국한.

Chaos to Cosmos,
Chaos to Chaos,
Cosmos to Cosmos,
Cosmos to Chaos.

ooti의 이미지

경험상 IE 를 제외한 다른 브라우저에서 잘 보이도록 아주 조금의 고민이라도 하는 업체는 아직까지 본적 없었습니다.

잘 보이면 다행인거고 안보이면 `IE 전용 사이트입니다` 하단에 표시하는게 전부죠.
요즘엔 이 표시도 안합니다. 당연히 IE 로 접속할꺼라 바라거든요.

지금 제 회사에서도 웹관련 개발을 하고 있지만 저만 유일하게 비 IE 브라우저를 쓰고 있습니다.

항상 건강하고 행복하세요.

May the force be with you.

creativeidler의 이미지

움. 아주 조금의 고민은 다들 합니다-_- 전 그 되는 거 하나 없다는 한게임의 웹개발 부서에서 공통 모듈 개발을 담당했었는데요. 전 주로 사내에서만 쓰는 것들을 개발했었는데 제가 만든 건 전부 XHTML Validation 100% 통과에 불여우에서 완벽하게 보였습니다. IE에서는 잘 안 보이는 경우가 있다는 리포팅이 있었지만 걍 무시했었죠-_-

안타까운 건 이걸 한게임 사이트로 확산시키지 못했다는 건데, 조금 노력은 해봤지만 현실적으로 저는 개발자고 HTML은 디자이너가 만들어서 주는 거라 부서간 업무 협조도 필요하고 복잡한 것들이 너무 많았습니다-_- 그래도 몇 번 계속 건들기는 했었기 때문에 지금은 뭔가 진행되고 있지 않을까 추측은 해봅니다-_- 그나마 한게임 레이아웃은 불여우, IE가 동일하게 보입니다. 아바타 안 나오고 로그인 좀 꽁수 써야되고 결정적으로 게임이 안되긴 하지만요-_-

이쪽으로 꽤나 많이 고민해본 사람으로서 한 마디 하자면 HTML, CSS, JavaScript의 몇 가지 기본적인 사항만 잘 알고 있다면 다 잘 보이게 만드는 거 어렵지 않다고 생각합니다. JavaScript의 기본 문법, DOM, CSS와의 연동만 잘 알면 하고 싶은 거 응용해서 할 수 있습니다. 그런데 문제는 사람들이 그 기본을 알려 하지 않고 JavaScript는 copy & paste로만 쓴다는 것이죠. 국내 대부분의 JavaScript 강좌 사이트가 그런 식이라서 그런 것도 있겠습니다만 아무래도 원리보다 공식만을 달달 외우면서 수학을 배워온 한국 교육의 문제가 아닐까 싶기도 합니다-_- 그래서 맞는 공식 못 찾으면 못 푸는 거고 그러니 어렵다는 소리 나오는 것이지요.

근데 사실 이런 기본적인 사항들에 대해서 잘 소개해놓은 사이트도 국내에선 찾기 힘듭니다. 그나마 trio.co.kr이 한가닥 빛이 되고 있긴 한데 자바스크립트 쪽은 좀 부실하고 구체적인 건 결국 영어 문서를 뒤질 수 밖에 없는 현실이죠. 그래도 잘 찾으면 기본 강좌를 더러 발견할 수는 있습니다.

실제로 표준과 권고사항을 잘 지키면서 코딩하면 PHP, JSP 등과 함께 쓰기도 훨씬 좋고 코드가 훨씬 깔끔해집니다. 하다보면 예전에 왜 그런 미친 짓을 했었지 하는 생각이 들지도 모릅니다-_-

jenix의 이미지

ctcquatre wrote:
론한국에 사는이상 자바스크립트 문서들 보면 모조리 익스 전용입니다.
전적으로 제 실력의 부족이라 모질라계열에서 자바스크립트를
표준에 맞게 쓰지 못하는게 이유지만.

자바스크립트 문서가 아니라 JScript 문서가 아닐까요?

ms vm 에 종속적인 변형 스크립트죠.

자바스크립 책보고 짜면 모질라에서도 잘 동작합니다. -_-;

Wikipedia 인용 wrote:

Due to the de facto success of JavaScript as a web page enhancement language, Microsoft developed a compatible language known as JScript. The need for common specifications for that language was the basis of the ECMA 262 standard for ECMAScript (see external links below),

자바좀 한다고 하고 JavaScript 랑 JScript 랑 구분 못하는 사람들도 꽤 되는거 같더군요.

---------------------------------------------------------------------------
http://jinhyung.org -- 방문해 보세요!! Jenix 의 블로그입니다! :D

jenix의 이미지

creativeidler wrote:

JavaScript의 기본 문법, DOM, CSS와의 연동만 잘 알면 하고 싶은 거 응용해서 할 수 있습니다. 그런데 문제는 사람들이 그 기본을 알려 하지 않고 JavaScript는 copy & paste로만 쓴다는 것이죠. 국내 대부분의 JavaScript 강좌 사이트가 그런 식이라서 그런 것도 있겠습니다만

바로 위에서도 썼지만..

JavaScript 강좌가 아니라 JScript 일겁니다 :(

---------------------------------------------------------------------------
http://jinhyung.org -- 방문해 보세요!! Jenix 의 블로그입니다! :D

정태영의 이미지

ctcquatre wrote:
솔직히 만들기 어렵습니다.
제가 외국에 살면 모르겠지만.
한국에 사는이상 자바스크립트 문서들 보면 모조리 익스 전용입니다.
전적으로 제 실력의 부족이라 모질라계열에서 자바스크립트를
표준에 맞게 쓰지 못하는게 이유지만.

변명으로 문서에 의존해서 이것저것 구현하는 관계로
어렵게 느껴집니다. :(

오늘도 자바스크립트작업을 하는데 모질라를 지원하게 만들려고 아무리
문서를 찾아보고 해도.. 힘들더군요.
결국 제가 할수있는건 alert으로 모질라사용자분들께 죄송하다는 말을 남겨놓을 뿐입니다.

물론 중요한 기능은 무슨일이 있어도 양쪽 다 되게 해야겠죠.
제가 말하는건.. 좀 사용자를 편하게 해주는 기능들에 국한.

그건 님께서 웹디벨로퍼가 아니기 때문이 아닌가요?
먹고 사는 일로 웹스크립트 개발을 하는 사람이라면... 오히려

자바스크립트 콘솔등의 강력한 디버거가 있는
모질라쪽이 개발하는데 훨씬 유리하며..

실제 현재 도는 스크립의 대부분 문제는... I.E 식 축약 표현(앞에 document. 를 안붙이는 등의 표현이죠) 과.. document.all.어쩌구 아니던가요?

싸이월드만 해도 저 두가지만 바꿔줘도.. 대부분의 링크가 동작할 거고... 마우스 오른쪽 버튼 클릭에 나오는 메뉴도 다 나올 텐데요.. 버그리폿을 해도 고치진 않더군요...

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

mirr의 이미지

하지만 결론적으로 우리나라에선 모질라계열로 제대로 웹의 모든것을 누릴
수 없는건 안타까운 사실이죠.......

M$ 소프트웨어 종속국인건가 OTz

내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.

songgun의 이미지

creativeidler wrote:
안타까운 건 이걸 한게임 사이트로 확산시키지 못했다는 건데, 조금 노력은 해봤지만 현실적으로 저는 개발자고 HTML은 디자이너가 만들어서 주는 거라 부서간 업무 협조도 필요하고 복잡한 것들이 너무 많았습니다.

이 말씀에 100% 동의합니다. 사실 저는 IE 만의 IE 를 위한 IE 의 웹 프로그래머입니다. 기반도 마이크로소프트의 IIS 위에서만 경력 7~8 년이 (휴학하고 취업한 기간 포함.) 되는 사람이죠. 다만 한 곳에만 너무 편협한 사고방식을 가지게 될까봐 두려워 몇 년 전부터 PHP 관련 한 곳, LINUX 관련 한 곳, JAVA 관련 한 곳 하는 식으로 사이트틀을 지정해 놓고 주기적으로 다니면서 다른 분들은 어떤 생각들을 하고 계시는지 다녀보고 있습니다. KLDP 에서도 많은 것을 배우고 새로운 논점을 경험하고 있구요. (이 글이 제 KLDP 첫 포스팅입니다.) ^_^

저는 대부분 기업체의 SI 시스템을 구축해주는 일을 하는데요. 제 경험으로는 이런 업무에서는 사실 IE 에만 맞추어도 큰 지장이 없습니다. 그러나 이 말을 좀 더 심화해본다면 'IE 에만 맞춘다.' 가 아니라 '해당 업체에서 표준으로 정한 특정한 브라우저에 맞춘다.' 가 맞을 겁니다. 저 역시 JSCRIPT 코드를 양산해내는 주범중의 하나이지만 몇 가지 변명을 해보도록 하겠습니다. ^_^;;

우리 기업체들에서는 정상적인 개발 기간을 찾아보는 것이 거의 힘듭니다. 또한 정상적인 개발자 (? 이렇게 표현하니 조금 이상하지만) 들로 구성된 프로젝트 팀은 거의 하늘의 별따기 입니다. 적어도 SI 에서는 그렇죠. 대략 5~6 년차 팀장 하나에 내부 1~2 년차 직원 한두 명, 그리고 대부분 잡코리아에서 건져올린 검증안된 처음보는 사람들 2, 3 명이죠. 기본적으로 프로젝트 기간은 정상적으로 필요한 기간의 절반도 안되거나 하는 경우가 비일비재하구요. 따라서 자바스크립트 뿐만 아니라 여기 명예의 전당에 올라있는 OOP 관련 토론을 비롯해서 프레임워크, 개발 방법론 등등은 거의 먼나라 학술적인 문제가 되어 버립니다. 당장 다음주가 오픈이고 아직 만들어야 할 모듈들은 3 분의 1 이상 남아있는데 팀원 한 명이 제게 이렇게 얘기한다고 생각해 보십시요.

"아무개씨가 작성한 페이지가 FF 에서 안보입니다. 다시 짜야합니다."

프로젝트 책임자의 입장에서는 정말 미칠 것 같을 겁니다. 게다가 보고라인도 밟지 않고 직접 클라이언트에게 이런 얘기를 해서 클라이언트 입에서 '다시 짜라.' 라는 말이 나오기라도 하면 속된 말로 욕이 튀어나오겠죠. 하긴 클라이언트중에 그런 이유로 다시 '잘' 만들어달라고 요구하는 클라이언트 자체가 없긴 합니다만, 아무튼 팀장 포함, 그런 직원은 당장 짤릴 겁니다. 딜레이는 뻔하고 금전적인 이익은 커녕 인건비랑 기회 비용만 날릴게 뻔하니까요. 그렇다면 가능성 있는 방법은 애초에 팀원들이 어느 정도 성숙된 인력들로만 구성되어야 하는데 이건 정말 현실성 없는 얘기죠. 핵심 모듈이 아닌 바에야 학교에서도 그렇지만 대부분 팀원 전체의 평균치 실력 정도에 기준이 맞추어지게 됩니다.

개인적으로 솔직히 어떤날은 이런 생각도 들더군요. 이런 개념들이나 방법론 등은 다 좋은데, 대학원생이나 학부생들, 또는 직업적인 강사나 컨설턴트들처럼 어느 정도 시간적인 여유가 되는 분들이나 고민해볼 수 있지 않을까 하구요. 특정 그룹을 비하하고자 하는 의도는 없습니다만, 실제로 대부분의 SI 현장이 이런 소리가 나올 정도로 공장에서 찍어내듯이 프로그램들을 찍어낸다는 말이 하고 싶은 것입니다. 이 부분은 업계 전반의 구조가 바뀌지 않는 이상 변화되기 힘들 것 같습니다.

리팩토링은 커녕 팀원들끼리 코드 리뷰도 하기 힘든 상황입니다. 프로젝트가 거의 다 끝나가는데 아무개 팀원이 만든 프로그램이 잘 돌아가는지 내부 코드는 살펴보지도 못하고, 그냥 클라이언트측 담당자가 아무 소리 없으면 넘어가 버립니다. 이런 풍토는 국내 대기업을 포함하여 그 어느 곳도 마찮가지입니다. 저도 2 년차부터 어떻게 한 번 제대로 진행되는 프로젝트를 한 번 경험해보고 싶어서 여기저기 크다는 대기업들만 골라서 프리를 다녀보기도하고 얼마전에는 싱가폴까지 나가서 S 모 사에서 1 년간 근무도 해봤습니다. 국내에서 제가 잠시나마 다녀본 곳도 S 모 전자, S 모 생명, K 타이어, M모N Korea, 60% 이상 카이스트 사람들로 구성된 벤터, 과천 청사, 농협 등등 이었는데... 제 결론은, 그리고 주변 분들의 (외국 친구들 포함) 의견은 기업체나 해당 법인이 아무리 외국계더라도 구성원의 60% 이상이 동양인이라면 국적을 불문하고 같은 패턴이라는 것이었죠.

저도 98 년 정도부터 이 일을 했기 때문에 오히려 크로스 플랫폼 스크립팅에는 더 경험이 많은 축에 속한다고 볼 수 있을 것 같습니다. IE 3.0 은 제껴두더라도 IE 4.0, NS 4.X 시절부터 양쪽에서 모두 동작하는 스크립들을 작성하느라 애먹었으니까요. 정말 농담이 아니고 그 때는 힘들어서 두 브라우저중에 하나 없어졌으면 좋겠다고 농담했을 정도입니다. 특히 NS 에서는 한글이 어찌나 밉게 나오던지... 얼마후 NS 가 나가 떨어졌을 땐 솔직히 기분 좋았습니다. :oops: 일이 반은 아니더라도 30% 는 줄었으니까요. 모든 스크립트마다 첫 번째 문장은 브라우저를 판별하는 일이었고, 그 다음에 하는 일은 한글 폰트가 양쪽에서 비슷한 레이아웃으로 나타나는지 판단하는 일이었죠. 게다가 당시에는 디자이너들도 지금과 같은 '웹' 디자이너들의 수가 절대로 부족했구요. 대부분 '미술가' 이자 '예술' 을 하는 분들이었지 웹 디자이너는 드물었습니다.

한 가지 의견을 더 말씀드리면 웬지 대부분의 분들의 분위기가 IE 는 악의 축, FF 는 선 이라는 공식을 부지불식간에 가지고 계시더라는 것입니다. 뭐 저도 완전히 부정하지는 않겠습니다. 그런데 문제는 여기 분들처럼 전후 사정을 아시고 이런 말씀을 하시면 좋은데 여기저기 사이트들을 다녀보면 전산과 관련된 분이 아니신데도 불구하고 또는 아직 어린 학생이 IE 가 무척이나 허접하고 무조건 나쁜것으로만 인식하고 계신 분들이 많이 보이더군요. 그래서 개인적으로는 조금 안타깝습니다. 뭐 저는 MS 쪽 기반에서 일을 하긴 하지만 그래서 그런것이 아니고 조금 다른 생각을 가지고 있습니다. 나름대로 IE 도 COM 과 인터페이스 수준에서 보면 잘 체계화된 구조를 가지고 있거든요. 물론 표준과 거리가 먼 부분도 있긴 하지만요. ^_^;;

아무튼 횡설수설했네요. 하지만 한 가지 확실하게 말씀드릴 수 있는건 만약 클라이언트가 "이번에 구축될 시스템은 FF 를 기준으로 해주세요." 라고 말만 한다면 그 어떤 SI 업체라도 당장 그날부터 FF 를 기준으로 삼을거라는 겁니다. 현재로서는 IE 만으로도 잘 돌아가는데 내부 직원들에게 FF 감안해서 일정잡고 인력 충원할 사장님은 없다는 거죠. 단 지금가지 말씀드린 얘기는 공공 사이트나 포탈과 같이 불특정 다수를 대상으로 하는 사이트가 아닌, 특수한 공통 분모를 지닌 사람들이 사용하는 웹 시스템에 관한 얘깁니다.

그러나 그런 SI 개발자들이 나중에 다 외부로 진출해서 그런 포탈들이나 공공 사이트를 만들게 될테니 결국은 같은 얘기군요...

행복한고니의 이미지

... 제가 드리는 말씀은 그리 어렵지 않게 상당한 부분을 표준화 시킬 수 있다는 겁니다. 그런데도 왜 항상 시간이 없다는 말만 되풀이 하는지 모르겠습니다.

불여우로 포탈 돌아다니다가 자바스크립트 콘솔 열어보십시오.
가장 많이 발생하는 오류가 뭔지 아십니까? 바로 비표준 document.all 을 사용했다는 경고메시지입니다. 이거 바꾸는게 어렵습니까? document.all 대신 document.getElementById 를 사용하거나 document.getElementsByName 을 사용하면 심각한 성능저하가 일어난다거나 레이아웃에 변화가 생기나요? 이런게 바로 게으름의 증거입니다.

너무 만들기 힘들어서, 정말 시간이 많이 걸릴 것 같아서 그렇기 때문에 시간상 넘어갔다면 그렇다고 할 수 있습니다. 직장인이라면 시간은 곧 돈이니 어쩔 수 없습니다. 그런데, 저런 간단한 것은 그런류의 문제가 아니지 않습니까? event 객체, 파이어폭스와 IE간의 호환성 유지하기가 그리 어렵습니까? 함수의 호출방법만 조금 바꾸면 될일입니다. 5줄 미만이면 끝날 일입니다. 그럼에도 불구하고 event는 아주 지겹도록 보이는 오류메시지 중 하나입니다.

저도 웹을 하는 사람이지만, 국내의 웹개발자들 솔직히 게으릅니다.
IE를 많이 쓰기 때문에, 시간이 없기 때문에 라는 것의 상당수는 핑계입니다. 다른 브라우저를 고려했다면 하다못해 기능이 구현되지 않음에 대한 안내메시지라도 남겨야 함이 정상입니다만, 현재의 상황을 보면 IE이외의 브라우저 따위는 애초에 존재하지 않는다...라는 가정을 하고 개발하는 것 같습니다.

여러 브라우저를 지원하는 것에 대해서 너무 심한 환상을 가지고 계십니다. 솔직히 일부에 대해서는 크로스 브라우징을 지원하기가 어렵다고 인정하는 부분도 있습니다만, 상당한 부분들이 게으름과 무지로 인해서 발생합니다. 바로 document.all 을 그냥 사용하는 것과 같은 부분이죠.

하다못해서...
MSDN에서조차 표준과 그렇지 않은 것을 표시해서 보여주는 판에, 왜 표준이 뭔지 비표준이 뭔지도 모르고 사는 개발자가 많은지 모르겠습니다.

__________________________________
나는 세상에서 가장 중요한 사람이다.

charsyam의 이미지

행복한 고니님 말씀을 듣고 살짝 의문이 생겼습니다.
document.all 관련 버그가 가장 많은데, 왜 아무도 불여우 엔진에서 document.all 관련을 IE 와 맞추려고 하는 노력은 아무도 하지 않는걸까요? 표준이 아니라서 그런걸까요? 흐음 궁금합니다. 그렇게 되면, 국내에서는 당연히 불여우 사용이 좀 더 많아지지 않을까요? 아니면, 국내만의 문제고, 국내에는 불여우 개발진이 없어서 생긴 문제인걸까요? 고운 하루되세요.

=========================
CharSyam ^^ --- 고운 하루
=========================

행복한고니의 이미지

charsyam //
불여우에서 document.all 지원해요. 1.0 의 가장 큰 변화가 그건데...

그래도 여전히 경고는 남습니다.
비표준인 document.all 을 사용했으니 document.getElementById 를 대신 사용하라고 친절하게 나오거든요.

__________________________________
나는 세상에서 가장 중요한 사람이다.

warpdory의 이미지

다양한 OS 를 지원한다며 jsp 로 개발해 놓고 인증은 ActiveX 로 가능하게 하는 업체도 있습니다. ---


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

charsyam의 이미지

행복한고니 wrote:
charsyam //
불여우에서 document.all 지원해요. 1.0 의 가장 큰 변화가 그건데...

그래도 여전히 경고는 남습니다.
비표준인 document.all 을 사용했으니 document.getElementById 를 대신 사용하라고 친절하게 나오거든요.

앗, 그렇군요. 저의 무지한 점을 알려주셔서 감사합니다. 고운 하루되세요. ^^

=========================
CharSyam ^^ --- 고운 하루
=========================

songgun의 이미지

행복한고니 wrote:
불여우로 포탈 돌아다니다가 자바스크립트 콘솔 열어보십시오.
가장 많이 발생하는 오류가 뭔지 아십니까? 바로 비표준 document.all 을 사용했다는 경고메시지입니다. 이거 바꾸는게 어렵습니까? document.all 대신 document.getElementById 를 사용하거나 document.getElementsByName 을 사용하면 심각한 성능저하가 일어난다거나 레이아웃에 변화가 생기나요? 이런게 바로 게으름의 증거입니다.

개인적인 입장만 말씀드린다면 '게으름' 이라는 부분에 대해서는 솔직하게 인정하겠습니다. :oops: 다만 이 문제만은 추가로 말씀드리고 싶네요. 제가 '시간' 이 없다고 말씀드린게 그냥 입으로만 시간이 없다는 뜻은 절대 아닙니다. 현업에서 일해보시면 정말 어처구니 없는 경우도 많죠. 이 경우의 시간은 document.all 이라는 12 자리 문자들을 document.getElementById 라는 23 자로 바꾸는데 걸리는 기술적인 시간을 말씀드리는 것은 아닙니다. 이런 것은 정말 Replace 만 때려버려도 되겠죠. 적게는 해당 프로젝트 팀원들의 인식을 바꾸는데 걸리는 시간, 크게는 내가 속한 업체의 인식을 바꾸는 시간, 그리고 최종적으로는 고객들의 인식을 바꾸는데 걸리는 시간을 말씀드리는 것입니다. 정말 단순하고 별거 아닌 것도 협의에 들어가면 가지각색의 의견들로 (마치 국회처럼... :wink:) 엉망이 되기 일쑤입니다. 말씀하신 그대로 심각한 성능저하가 일어난다거나 레이아웃에 변화가 일어나는 것도 아닌데 말이죠. ^_^;;

그리고 말씀하신 그대로 제가 일하는 환경 (거듭 말씀드리지만 웹 SI 쪽) 과 같은 곳에서는 일단 IE 외의 브라우저를 고민해보는 작업 자체가 일 순서 자체에서 그대로 배제되어 버립니다. 그래서 말씀드렸던 것이 특정한 사용자들만 사용하는 시스템의 경우 'IE' 가 아닌 그 집단의 표준 브라우저에 맞추게 된다는 것이죠. 그런데 대부분의 사람들이 그 '표준 브라우저' 로 IE 를 아무런 의심없이 떠올린다는 겁니다. 그 이유는 고니님께서 말씀하신 바로 그 이유입니다. '심각한 성능저하가 일어난다거나 레이아웃에 변화가 일어나는 것'도 아니므로 클라이언트들 입장에서는 별 상관이 없는 거죠. 그 분들 입장에서는 어짜피 깔려있는 브라우저 그냥 쓰면 되는 겁니다. 그리고 자연히 연쇄적으로 저희같은 하도급 업체들은 그 입장을 따라가게 됩니다.

원론적으로 고니님의 말씀이 맞다는 데에는 동의합니다. 제 생각으로는 IE 에 사람들의 인식이 고정되어져 있고, 지금까지 이러한 현상들이 지속되는 이유는 기술적인 부분 때문이 아니라 사회학적인 이유 때문이 아닐까 합니다. 한 마디로 마이크로소프트가 초기에 마케팅을 잘해서, 혹은 돈을 퍼부어서 운영체제를 장악하고 어떤 흐름을 만들어 버리는데 성공한거죠. 전 평소에 이런 생각을 하는 적이 많습니다. 장차 마이크로소프트의 몇 가지 악덕을 몰아내는 것은 기술이 아니라 마켓팅과 어떤 사회학적인 흐름이 아닐까 하구요. 그리고 그 대표적인 성과물 중의 하나가 리눅스라고 생각합니다.

개인적으로 리눅스는 단지 어떤 테크놀러지의 집합일뿐만 아니라 엄청난 인원의 사람들이 자발적인 의사를 가지고서 공동의 목표를 구현해낸 작업의 부산물이라고 생각합니다. 그 작업 자체가 더 가치있다고 생각하는 거죠. 지구의 역사 그 어디에 월드와이드 규모로, 그리고 동시다발적으로 같은 목표를 구현하기위해 이렇게 많은 사람들이 노력했던 사례가 있었을까요? 제가 고니님께 말씀드리고 싶은 것은 고니님께서 질타하시는 개발자들의 개으름, 악덕을 타파하시려면 기술적인 설명뿐만 아니라 그들의 인식을 전환시키는 위와 같은 흐름의 변화를 유발시켜야 할 것만 같다는 거죠. 과거에 모질라는 실패했고 작금에 파이어폭스는 성공한 바로 그 어떤 흐름 말입니다. 제 생각에는 그러한 흐름은 '기술' 만으로는 유발시키기 어렵습니다.

제 잛은 소견은 이렇습니다.
부디 더욱 발전하셔서 저처럼 클라이언트들에게 휘둘리는 노가다꾼이 되지 마시고, 큰 흐름을 일으키실 수 있는 진정한 개발자가 되시기 바랍니다.

죠커의 이미지

클라이언트가 관심이 없다는 것은 쉽게 말할 수 있는 부분이 아니라고 봅니다. 멀쩡한 고객을 버리는 것을 클라이언트가 제대로 이해했을 경우에도 클라이언트의 반응이 같을까요?

많은 분들이 클라이언트가 관심이 없다는 말을 하시는데 정말 클라이언트가 관심이 없는지도 솔직히 말하면 모르는 것 아닙니까? :-)

어쨌거나 요즘 한국 인터넷 문화, 환경도 점차 나은 방향으로 흘러가는 것 같아서 다행인 것 같습니다. (단 한가지 KT만 제외한다면 말입니다.)

행복한고니의 이미지

제가 지금은 학생이지만, 그래도 웹쪽에서 3년간 일하다가 올해 학생신분으로 돌아온 것입니다. 현업에서 일을 안해본게 아니라요. 아직은 부족하겠지만 나름대로는 이런저런 클라이언트도 겪어봤고, 이런저런 경험도 적잖게 해봤다고 생각하고 있습니다.

맞습니다. 클라이언트는 브라우저에 정말 아무런 관심도 없습니다.
그래서 그 클라이언트에 IE가 아닌 다른 브라우저가 설치되어있고 그 사람이 그걸 쓴다하더라도 컨텐츠의 접근에 있어 불편함이 없어야 한다는 생각입니다. 게다가 그 사람들은 스크립트의 내용에 대해서도 전혀 상관없습니다. 그래서 잘되기만 하면 IE전용이건, 표준 스크립트이건 관계없다는 말이죠. 어째서 하도급 업체라고 해서 IE전용으로 만드는게 당연시 되는 것인지에 대해서는 이해하지 못하겠습니다. 클라이언트는 그걸 모르기도 하고 관심도 없거든요. IE 전용인지 아닌지 조차요. 제가 이해하기로는 "클라이언트만 통과하면 된다"로 보일 뿐입니다(SI에선 진리이긴 하죠. 그게 웹서비스라 하더라도 말이죠).

특수기능의 경우에는 정말 시간이 더 걸리는 경우도 있을 수 있습니다. 저도 우선은 IE에 맞춰서 작업해놓고 그 다음에 조금 손보는 경우도 종종 있으니까요. 예전 기억으로는 CSS의 랜더링 차이때문에 몹시 힘들었던 기억이 있기도 하구요. 그런데 제가 문제시 삼는 것은 그렇다면 그런 특수기능들은 쓸 수 없다는 메시지라도 남겨주는걸로 넘어간다해도, 최소한 간단하고 기본적인 것들은 표준으로 쓸 수 있지 않나 하는 겁니다.

또하나, 제가 잘 몰라서 그러는데 스크립트의 경우 대부분 하나의 함수, 하나의 클래스에 대해서는 한 사람만 작성할 것 같은데, 자신이 만드는 부분에 대해서 document.all 이나 document.getElementById 로 썼는지에 대한 간섭도 있는건가요? 된다/안된다 가 아닌 세부적인 소스 차원에서의 관리도 하는건지요?

__________________________________
나는 세상에서 가장 중요한 사람이다.

익명 사용자의 이미지

불붙기 쉬운 주제죠. ^^

실제로 웹 개발 하다보면 시간이 지날수록 짠다기 보다는 긁어다 쓰게 됩니다.
원본만 제대로 해둔다면야 어느쪽이든 별로 차이는 없을겁니다.
하지만 처음에(초보때) 잘해두질 못하니까 뒤에도 계속 그렇게 되는거죠.

프로젝트 하나 잡아서 신경써두면 두고 두고 좋을텐데 실제로는 그렇게 잘 되지 않더군요.
쓰던 게시판 하나도 새로 만들기 쉽지 않으니....

경력이 늘어날수록 프로젝트에 주어지는 시간이 짧아집니다.
바쁘기는 초보때나 지금이나 매 한가지네요.

요즘 웹에이전시에서는 예전과는 달리 html 은 디자이너가 아니라 전문 코더가 짜 줍니다.
상당한 수준의 전문 코더를 몇명 경험(?)해 보았습니다만 javascript 도 웬만한건 다 짜서 넘겨줍니다.
코더가 작업하고 넘겨주는 시점에서 프로그램이 다 되어서 도는 것처럼 보일 정도죠.

코더 중에서도 파이어폭스 신경 쓰시는 분들고 계시고 그렇습니다.

그냥 이렇다 저렇다기보다 그렇다는 내용입니다..

songgun의 이미지

CN wrote:
클라이언트가 관심이 없다는 것은 쉽게 말할 수 있는 부분이 아니라고 봅니다. 멀쩡한 고객을 버리는 것을 클라이언트가 제대로 이해했을 경우에도 클라이언트의 반응이 같을까요?

그래서 말씀드린 것이 대중을 향해 공개된 사이트가 아닌 '기업체의 내부 인력들만 사용하는 시스템'에 관해서 거론한 것입니다. 말씀하신 것처럼 이런 시스템에서는 제 클라이언트가 곧 그 시스템의 클라이언트가 되겠죠. 따라서 클라이언트가 멀쩡한 고객을 버리는 상황은 아닌 것입니다. 오히려 그런 경우에는 하나의 웹 브라우저로 통합하기를 기대하시는 담당자 분들이 많습니다. 왜냐하면 그 편이 더 대응하기가 쉽거든요. 그리고 바로 그 분들이 막판에 검수 사인을 해주시는 분들이구요. 제가 가본 업체들중에 최근에는 운영체제를 어느 수준이상으로 결정해 버리시는 경우가 많았습니다. 예를 들면 작년 하반기에 잠시 일했던 과천에 위치한 K 건설은 모든 운영체제가 최하 2000 pro 이상이더군요. 98 이나 ME 같은 시스템은 전사에 존재하지가 않았습니다. 이런 경우 굳이 다른 브라우저를 설치하지 않고 IE 5.0 이상 이라는 조건으로 결정을 해버리시는 거죠.

물론 다시 한 번 말씀드리지만 저도 SI 가 아닌 대중을 향해 열려있는 포탈과 같은 시스템을 운영한다면 당연히 다양한 브라우저를 지원하기 위해 노력할 것입니다. 실제로 그런 2 년정도 경험도 있구요. 그러나 지금 제가 처한 입장에서는 그다지 급박한 요구사항은 아니라는 것입니다. 그리고 이런 저의 처지가 SI 에 종사하시는 상당수의 다른 분들과 같은 처지인 것이지 않을까 생각한다는 말이죠. 최소한 돈이 절약된다거나 기간이 단축된다거나 뭔가 절박함이 느껴지지 않는 한 말입니다. ^_^

행복한고니 wrote:

또하나, 제가 잘 몰라서 그러는데 스크립트의 경우 대부분 하나의 함수, 하나의 클래스에 대해서는 한 사람만 작성할 것 같은데, 자신이 만드는 부분에 대해서 document.all 이나 document.getElementById 로 썼는지에 대한 간섭도 있는건가요? 된다/안된다 가 아닌 세부적인 소스 차원에서의 관리도 하는건지요?

이 문제에 대해서는 저도 제 개인적인 경험만을 말씀드릴 수 밖에 없을 것 같습니다. 소스 차원의 관리를 하는 프로젝트도 있었고 아닌 프로젝트도 있었습니다만, 그렇지 않은 경우에도 문제는 있더군요. ^_^;;; 제가 PM 이 아닌 바에야 같은 직급의 프로그래머들이 작성한 스크립트까지는 책임질 수가 없지 않겠습니까? 차라리 팀원들을 컨트롤 할 수 있는 상황이면 조금더 걸러지 코드를 만들수 있습니다. 그런데 5 명의 팀원이 있다고 한다면 그 중 4 명 또는 저 포함 전부가 IE 기반의 스크립팅을 하는 상황인 거죠. 아니 차라리 그거라도 일목요연하게 정리해서 작업하는 수준도 못되는 경우도 있습니다. 그런 경우에는 그런 사람들 추스려서 사이트를 제 날짜에 오픈하기라도 하는 것이 최대의 목표가 되어버립니다. 실제로도 그랬구요. 제가 이 얘기까지 하면 제 주변분들은 절 알아보시겠지만, 작년 하반기에 들어갔던 과천 청사 프로젝트에선 PM 이 IP 와 Port 도 모르더군요. gcc 만 하셨던 분들이 회사에 등떠밀려 프로젝트에 들어오셨구요. 그런데 시스템 요구 사항은 정말 장난이 아니었습니다. 메뉴얼조차 없는 EDMS 시스템에 AD 통합까지... 그런 경우엔 정말 스크립트고 뭐고 제발 제 날짜에 끝나기만을 바라게 됩니다. 거의 매일을 차가끊길때가지 일하고도 그 모양이 됩니다. 제가 운이 없어서 그런 프로젝트만 골라다녔는지는 모르겠지만, 정말 저도 이런 짓거리 (죄송합니다. ^_^...) 를 그만 끝내고 싶네요. 전 다시는 그 업체와는 일 안할 겁니다.

제 최근 3 년간의 프로젝트들이 단 하나를 제외하고는 다 이모양입니다. 그리고 제 개인적인 경험만 이런 것은 아니라고 알고 있습니다. 그리고 먼저글에서도 말씀드렸지만 그런 프로젝트들의 고객들이 다들 이름만 대면 알만한 회사들이라는게 더 암담하죠. 번듯한 업체라 뭔가 프로젝트 운영의 묘가 있을 것이라고 기대를 한 것이 헛되었구요. 이달 21 일에 들어가서 프로젝트를 처음보는 사람들끼리 시작했는데 다음달 7일에 기능의 3 분지 1 을 시연하라고 하는 식이니까요. 그때 팀원중의 한 분은 몇 일 후 도중에 사라져버려서 나타나지 않더군요. 너무 극단적이기까지한 제 얘기만을 드렸는지도 모르겠습니다. 다른 분들을 끌고 들어가는 것은 조금 비겁해 보이니 이렇게 말씀드리겠습니다. 그런 상황에서 제가 어떻게 다른 분들보고 스크립트좀 제대로 짜자고 말씀드릴 수 있었을까요? 그저 맡은 부분만이라도 잘 짜주시기들만 말도 못하고 속으로 간절히 바라는 심경이었답니다. ^_^;;;

물론 제 사정이 이렇다고 해서 지금 논점이 되고 있는 IE 에 종속되는 스크립팅의 문제점에 면죄부가 부여되는 것은 아닐겁니다. 그러나 이렇게 살아가는 프로그래머들도 상당수 되는데 그런 분들에게 이런점에 대한 고려없이 '게으른 프로그래머들' 이라고 표현하신다면 제 입장에서는 너무 억울하다는 말입니다. '기술' 말고도 고민되는 부분들이 정말 많더군요. ^_^

감사합니다.

익명 사용자의 이미지

http://phpschool.com/bbs2/inc_view.html?id=20669&code=phorum2

크로스 브라우징에 대해.. 관심없는 사람들의 일반적인 생각을 보실 수 있습니다.(코멘트들..)
(한심하다고 해야 하나.. 최소한의 인식조차 없습니다.)
표준,비표준의 문제에 대해서도..

익명 사용자의 이미지

IE와 FF를 모두 지원하도록 프로그래밍하는 것 자체가 시간이 더 드는 것은 절대 절대 절대 절대 아닙니다. 프로그래머들이 자바스크립트의 기본 문법과 DOM에 익숙하다면 말입니다. 문제는 바로 이겁니다. 이 가정이 성립하지 않기 때문에 둘다 지원하려면 최초의 학습 곡선을 넘어서야하며 이 비용이 문제가 되는 것입니다. 그러나, 이 비용은 제가 볼 때 3시간 안팎의 세미나 한 번으로 깨끗이 해결할 수 있습니다. 이 정도 투자하고 나면 그 다음부터는 같은 시간, 혹은 더 적은 시간으로 두 브라우저를 다 지원할 수 있습니다. 마치 둘다 지원하는 게 시간의 압박이 있는 프로그래머들에게 엄청 힘든 일인 것처럼 생각하는 사람이 많은데 그건 결코 사실이 아닙니다. 그건 HTML 문법 몰라서 오래 걸린다는 말이랑 똑같은 겁니다.

물론 그런 3시간의 투자를 아까워하는 기업이 더 많습니다. 하지만 안 그런 기업도 분명히 많습니다. 그럼에도 불구하고 그런 투자를 하지 않는 것은 잘 모르기 때문이죠. SI라면 경우가 좀 다르겠지만 일반 웹의 경우에 3시간의 투자로 3%의 추가 고객을 유치할 수 있다면 거절할 CEO는 많지 않을 겁니다.

chunsj의 이미지

저도 이 말에 동의합니다. 이런 이야기를 하면 다른 브라우저에서도 되게 "추가로" 만들어야 되는 듯한 변명이 많이 나오는 것을 보게 되는데, 애초에 기본/원칙을 지켜서 만들었다면 그런 일은 거의 발생하지 않습니다. 즉 냉정하게 이야기하면 내가 지금까지 해 온 것은 다른 사람이 한 것을 복사/붙여넣기로 해 온 일들인데 표준으로 짜서 내가 복사/붙여넣기를 할 수 있는 자료는 전부 영어로 되어 있어 보기가 싫거나 읽는데 "시간이 걸리고" 한글로 되어 있는 것들은 모두 IE에만 맞추어져 만든 이전의 잘못된 어플리케이션 코드들 뿐이기 때문에 이런 현상이 생기는 것이죠.

이런 코딩이 만약 시스템 어플리케이션에서 일어났다면 어떻게 되었겠습니까? 그사람은 개발자로 인정은 커녕 바로 업계에서 "바보"됩니다. 웹 개발 인력이라는 이유로 피해갈 수 있기에 이런 현상이 용인되고 있는 것이죠. 처음에 인용된 글을 보면 이건 시간/비용의 문제라기보다 개발자의 자질의 문제라는 것을 잘 알 수 있습니다. 물론 인건비가 싸서 실력이 되는 사람은 이바닥에서 일을 하지 않으려 한다는 것도 현실적인 원인도 되겠지만 말입니다.

Anonymous wrote:
IE와 FF를 모두 지원하도록 프로그래밍하는 것 자체가 시간이 더 드는 것은 절대 절대 절대 절대 아닙니다. 프로그래머들이 자바스크립트의 기본 문법과 DOM에 익숙하다면 말입니다. 문제는 바로 이겁니다. 이 가정이 성립하지 않기 때문에 둘다 지원하려면 최초의 학습 곡선을 넘어서야하며 이 비용이 문제가 되는 것입니다. 그러나, 이 비용은 제가 볼 때 3시간 안팎의 세미나 한 번으로 깨끗이 해결할 수 있습니다. 이 정도 투자하고 나면 그 다음부터는 같은 시간, 혹은 더 적은 시간으로 두 브라우저를 다 지원할 수 있습니다. 마치 둘다 지원하는 게 시간의 압박이 있는 프로그래머들에게 엄청 힘든 일인 것처럼 생각하는 사람이 많은데 그건 결코 사실이 아닙니다. 그건 HTML 문법 몰라서 오래 걸린다는 말이랑 똑같은 겁니다.

물론 그런 3시간의 투자를 아까워하는 기업이 더 많습니다. 하지만 안 그런 기업도 분명히 많습니다. 그럼에도 불구하고 그런 투자를 하지 않는 것은 잘 모르기 때문이죠. SI라면 경우가 좀 다르겠지만 일반 웹의 경우에 3시간의 투자로 3%의 추가 고객을 유치할 수 있다면 거절할 CEO는 많지 않을 겁니다.

꼬마앙마의 이미지

글쎄요....

궁금한게 있습니다....

우선 그 기본/원칙이란 무엇인지 궁금합니다.(IE4,5,6? NN4, 6,7? MB? FF? OP?)

그리고 표준이란것이 있는지도 궁금하구요.

만약에 그 표준이란것이 있다면 표준으로 작성한 문서는 NN4에서도 잘 브라우징 되는지 알고 싶네요.

chunsj wrote:
저도 이 말에 동의합니다. 이런 이야기를 하면 다른 브라우저에서도 되게 "추가로" 만들어야 되는 듯한 변명이 많이 나오는 것을 보게 되는데, 애초에 기본/원칙을 지켜서 만들었다면 그런 일은 거의 발생하지 않습니다. 즉 냉정하게 이야기하면 내가 지금까지 해 온 것은 다른 사람이 한 것을 복사/붙여넣기로 해 온 일들인데 표준으로 짜서 내가 복사/붙여넣기를 할 수 있는 자료는 전부 영어로 되어 있어 보기가 싫거나 읽는데 "시간이 걸리고" 한글로 되어 있는 것들은 모두 IE에만 맞추어져 만든 이전의 잘못된 어플리케이션 코드들 뿐이기 때문에 이런 현상이 생기는 것이죠.

이런 코딩이 만약 시스템 어플리케이션에서 일어났다면 어떻게 되었겠습니까? 그사람은 개발자로 인정은 커녕 바로 업계에서 "바보"됩니다. 웹 개발 인력이라는 이유로 피해갈 수 있기에 이런 현상이 용인되고 있는 것이죠. 처음에 인용된 글을 보면 이건 시간/비용의 문제라기보다 개발자의 자질의 문제라는 것을 잘 알 수 있습니다. 물론 인건비가 싸서 실력이 되는 사람은 이바닥에서 일을 하지 않으려 한다는 것도 현실적인 원인도 되겠지만 말입니다.

익명 사용자의 이미지

http://www.w3.org/
여기 표준이 있지요.

ris81ryu의 이미지

꼬마앙마 wrote:
글쎄요....

궁금한게 있습니다....

우선 그 기본/원칙이란 무엇인지 궁금합니다.(IE4,5,6? NN4, 6,7? MB? FF? OP?)

그리고 표준이란것이 있는지도 궁금하구요.

만약에 그 표준이란것이 있다면 표준으로 작성한 문서는 NN4에서도 잘 브라우징 되는지 알고 싶네요.

chunsj wrote:
저도 이 말에 동의합니다. 이런 이야기를 하면 다른 브라우저에서도 되게 "추가로" 만들어야 되는 듯한 변명이 많이 나오는 것을 보게 되는데, 애초에 기본/원칙을 지켜서 만들었다면 그런 일은 거의 발생하지 않습니다. 즉 냉정하게 이야기하면 내가 지금까지 해 온 것은 다른 사람이 한 것을 복사/붙여넣기로 해 온 일들인데 표준으로 짜서 내가 복사/붙여넣기를 할 수 있는 자료는 전부 영어로 되어 있어 보기가 싫거나 읽는데 "시간이 걸리고" 한글로 되어 있는 것들은 모두 IE에만 맞추어져 만든 이전의 잘못된 어플리케이션 코드들 뿐이기 때문에 이런 현상이 생기는 것이죠.

이런 코딩이 만약 시스템 어플리케이션에서 일어났다면 어떻게 되었겠습니까? 그사람은 개발자로 인정은 커녕 바로 업계에서 "바보"됩니다. 웹 개발 인력이라는 이유로 피해갈 수 있기에 이런 현상이 용인되고 있는 것이죠. 처음에 인용된 글을 보면 이건 시간/비용의 문제라기보다 개발자의 자질의 문제라는 것을 잘 알 수 있습니다. 물론 인건비가 싸서 실력이 되는 사람은 이바닥에서 일을 하지 않으려 한다는 것도 현실적인 원인도 되겠지만 말입니다.

위의 분 지적대로 html, xhtml, dhtml, css등의 표준은 w3c에서 정의하는 것으로 알고 있습니다. 특정 브라우져에 표준이 따라가는 것이 아니라 표준이 정의되면 브라우져가 지원하는 거죠.

NN4는 점유율을 잃기 전에도 표준 지원이 그다지 뛰어나지 않았었고, 현재로서는 매우 오래된 브라우져기 때문에 html 4.01, xhtml, mathML, css 2.0 등으로 요리해낸 페이지를 제대로 보여주지는 않을 것입니다.

creativeidler의 이미지

거기에 추가로 DOM만 좀 알면 됩니다. 웹에서 자바스크립트로 보여줄 수 있는 효과란 게 HTML과 CSS를 동적으로 변경하는 것에 지나지 않습니다. JScript에 일부 안 그런 효과도 있지만 그것들도 모두 HTML, CSS의 동적 변경으로 대체 가능하죠. 그 동적 변경을 하는 API가 DOM입니다. DHTML이란 것도 결국은 DOM을 이용해서 HTML, CSS를 변경하는 기술을 말하는 것입니다.

익명 사용자의 이미지

W3C 표준은 htttp://www.trio.co.kr 에 한글 번역본이 있습니다.
하지만 '규약'이라는 특성상 당장 실무에 응용해야 할 개발자들이 이해하기가 무척 어렵습니다.

가장 큰 문제는 W3C 표준의 한글 문서가 있더라도 이걸 당장 응용할수가 없다는 겁니다.
당장 실무에 써야 하는데 규약이랍시고 읽어보니 뜬구름 잡는 소리만 하고 있다면, 그리고 그걸 이해하는데 몇시간이 걸릴 지 알 수 없다면, 그냥 비슷하게 구현한곳 찾아서 소스보기 해서 카피하는게 낫지요.
규약을 잘 이해하고 있다면 카피해서 붙이는 도중에 규약에 맞게 수정할 수 있지만(그리고 현업에서는 이렇게 조금씩 수정해 나가는게 바람직하지만..) 규약 자체를 이해못하는 상황에서 규약을 지키라고 하면 그들은 반문합니다.
"이렇게 해도 잘 돌아가는데 왜?"
(여기서의 '잘'은 '내 PC에서 문제없이'를 의미합니다.. -_-; )

개발자들이 게으르다고들 하는데, 저도 나름대로 쉽게 설명된 규약이 어디 있나 하고 찾아봤는데 한글 사이트는 요원하고 책도 구하기 어려웠습니다. 적절한 한글 문서 없이 무작정 게으르다고 비난할일은 아닌것 같습니다. (자료는 지금도 못구하고 있습니다. 자료를 한글로 정리해놓은 괜찮은 사이트나 한글 서적 추천해주시면 감사하겠습니다.)

Anonymous wrote:
IE와 FF를 모두 지원하도록 프로그래밍하는 것 자체가 시간이 더 드는 것은 절대 절대 절대 절대 아닙니다. 프로그래머들이 자바스크립트의 기본 문법과 DOM에 익숙하다면 말입니다. 문제는 바로 이겁니다. 이 가정이 성립하지 않기 때문에 둘다 지원하려면 최초의 학습 곡선을 넘어서야하며 이 비용이 문제가 되는 것입니다. 그러나, 이 비용은 제가 볼 때 3시간 안팎의 세미나 한 번으로 깨끗이 해결할 수 있습니다. 이 정도 투자하고 나면 그 다음부터는 같은 시간, 혹은 더 적은 시간으로 두 브라우저를 다 지원할 수 있습니다. 마치 둘다 지원하는 게 시간의 압박이 있는 프로그래머들에게 엄청 힘든 일인 것처럼 생각하는 사람이 많은데 그건 결코 사실이 아닙니다. 그건 HTML 문법 몰라서 오래 걸린다는 말이랑 똑같은 겁니다.

3시간 안팍의 세미나로 규약의 이해가 가능하다면 그정도 시간을 투자할만한 개발자들이 많을겁니다. (이런 기회가 있다면 저도 참석하고 싶습니다.)

하지만, 3시간만에 표준을 이해하기 위해선 비록 잘못된 문법이나마 기본 이해가 선행되어야 하는데 그 기본마저 없이 복사해서 붙이는 코더들에겐 3시간이 아닌 10시간쯤은 투자해야 할지도 모르겠습니다.
실제 세미나가 개최된다면 인원의 60% 정도는 기초가 없어서 들어도 뭔말인지 모르는 사람들이 채울겁니다.
이런 사람들은 세미나를 끝내고 현업에 돌아가도 이러저러하게 하면 된다더라.. 하는걸 알면서도 막상 자신이 해보려면 잘 안되니까(기초가 부족하니까!) 다시 옜날로 돌아갈 위험이 크겠죠.

익명 사용자의 이미지

SI업계에 몸담으신 분도 계시는것 같은데,
기업 내부 등 특정 계층 클라이언트를 상대로 SI로 구축하다보면 내 PC에서 잘되고 옆 동료 PC에서도 잘되는데 누군가 안된다면서 고치라 하면 일단 짜증부터 납니다.

'저 돌은 왜 남들 안쓰는거 써서 괴롭히냐..'

나도 잘되고 내 옆사람도 잘되고 전산담당자에서도 잘된다면 굳이 고칠 필요를 못느낍니다.
잘 돌아가는거 괜히 표준에 맞춘다고 표준도 잘 모르면서 어설프게 손대다가 망가지기라도 한다면 더 골치아프거든요.
그래서 사양을 못박아버립니다.

'우리 제품은 ie 6.0 에서만 되요. 딴데서는 책임 못져요.'

시스템을 운영할 사람들도 ie도 봐야하고 모질라도 봐야하고 사파리, 오페라도 봐야 하면 귀찮으니까 승낙해 버립니다.

'금번 새로 구축한 시스템은 ie 6.0에서만 됩니다. -전산실-'

..................................................

실은 개발자들이 발주사에게 겁을 줍니다. 그렇게 하나둘 봐주기 시작하면 끝이 없다고..
표준을 지키면 해결될 문제지만 앞서 말했듯 대부분 개발자들이 표준도 잘 모르는게 현실이고, 잘 알지도 못하면서 어설프게 손대서 망가뜨리는건 더욱 싫어하거든요. 차라리 하나만이라도 확실하게 되는 쪽을 선택하지요.

여담이지만..... 개발자도 개발자지만 디자이너는 페이지 다르게 나오는거 더 싫어합니다. 브라우져마다 렌더링 엔진에 약간씩 특색이 있음에도 불구하고 어떻게든 똑같이 맞추려고 온갖 삽질을 다 하죠. (이런 삽질은 별 보람도 없이 시간만 많이 까먹죠..)
그 이면에는 디자이너의 고집도 있지만, '왜 파이어폭스에선 다르게 보여? 똑같이 맞춰줘' 하는 발주사의 무지함에 의거한 요청도 존재하구요.
그래서 대부분 플래시 도배로 삽질의 끝을 맺게 됩니다. 플래시로 도배하면 브라우져의 렌더링 엔진의 특성을 죽일 수 있거든요. -_-;;