FF VS IE : 브라우저 디버거 전쟁!

파이어 폭스 일명, FF 로 통하는 이 브라우저에는 엄청난 디버거 툴이 있다.
바로 FireBug 라는 놈인데, 플러그인으로 붙어서, 갖가지 일을 해준다.

내가 이제까지 써본 디버거 중의 최고는 단연 비쥬얼 스튜디오 2005 였지만,
브라우저라는 특이한 상황에서는 역시, FireBug 만한게 없는거 같다.

반면, MS 계열의 인터넷 익스플로러는 스크립트 디버거 라는 놈이 존재한다.
사실 스크립트 디버거는 쓸모딱지가 없고, 스크립트 에디터라고 오피스 프로그램에 탑재된 놈이있다. 이것을 깔면, 약간은 비쥬얼 스튜디오 틱한 디버거 환경을 사용할수있다.

머, 내가 오늘 왠만한 UI 개발자라면, 다 아는 얘기를 꺼내놓고 싶어서 떠드는건 아니다.
그냥 오늘 하루종일 삽질한, 그 민감한 사안에 대해 얘기해보고자한다.

당신의 주무기는 무엇입니까?

나는 주로 IE6 기반에서 개발을 시작한다. 왜냐면, IE6이 가장 많은 브라우저 점유률..
특히 우리나라에서는 거의 95% 이상의 IE계열이고, 그중에서 IE6이 또 가장많은 점유률을 찾이 하고 있으므로, 어떻튼간에 난 IE6을 지원해야하는 수밖에 없다. 그게 내가 하는 일이니까..

그런데, 요며칠, 그놈의 IE8 때문에, IE8 beta2를 깔고 나면서 부터, 평소 하던 개발 스타일에 변화가 생겼다. IE8에 엄청난 브라우저 버그들을 탑재하고 있어서, 아무리 좋은 개발툴을 IE8이 기본으로 장착하고 있어도, 사용을 할수가 없었다.

그래서, 어쩔수없이.. 주무기를 FireBug로 갈아탈수밖에 없었다. IE8을 깐이상 지우기전까지는 IE6으로 돌아갈수도 없었다.

파이어폭스 과연 얼마나 똑똑한가?

그렇게 한참을 개발하고, QA에 임박한 상황이다. 그러나…그런데.. 흐흑…
FF 계열에서 잘 돌아가던 놈이, IE6에서 돌아가지 않는다. (결국 IE8은 지워버렸다..)
이놈때문에 하루 종일 삽질했다. –

결론, 문제는 이놈의 FireFox 가 너무나 똑똑해서,.. 혹은 반대로, IE가 너무나 민감해서..
라는 결론이 난다.
즉, FireFox에서는 대표적으로 아래와 같이 배열의 마지막에 콤마를 찍어도 문제가 없다.

배열 = [  A, B, C, D, ]

하지만 위처럼 마지막 인덱스에 콤마를 찍어버리면, IE에서는 어김없이 에러는 내버린다.

이런 특성, 어떻게 봐야하나? 누가 더 좋다고 할수있나?…
저 콤마때문에 빈번히 삽질을 하는경우가 많다. 특히나, JSON으로 통신을 하다보면,
서버쪽에서 실수로 저런 콤마를 하나 넣었을경우, 그 사실을 모르는 우리들은 하루중일 원인을 파악하느라.. 삽을 들수밖에 없다.

두번째,..
비슷한 내용인데, 이번에 태그와 관련이 있다.

파이어폭스에선, 아래와 같이 사용해도, 특별한 문제없이 랜더링을 해준다.

<a href=”#” class=’nvc_happy ><span></span>이거 문제 없어요.!!</a>

하지만, IE에서 위와같이 쓸경우, 역시나 에러는 아니고, 랜더링을 제대로 못해준다.
왜냐,.. class 이름을 적을때, 닫는 싱클쿼트 하나가 빠져있기 때문이다.

FireBug로는 저런 문제를 잡아낼수가 없다. 왜냐? FF에서는 문제가 안되기때문이다.

저걸 또 잡아내기란 쉽지가 않다. –– (난 어떻게 잡아낸걸까? ㅎㅎ)

스크립터 에디터를 통해 스택을 하나하나 밟아가며,.. 결국 찾아냈다.
IE 만세~!!

오늘부터 나 다시 IE6 + Script Editor 로 주무기를 바꿨다!!

IE8 beta2 브라우저 버그

오늘까지 발견한 4종의 버그..
1. resize 이벤트가 발생하지 않는다.
2. division의 offsetLeft 값이 이전 ie7이하 버전과는 다르게 계산된다.
3. 동적으로 생성한 노드의 DOM을 제대로 랜더링 하지 못한다.
4. display:none/block 으로 토글 할때, 처음 한번만 동작한다.

앞으로 계속 이페이지에 추가하고,
해결된 버그는 삭제할 예정~!!

제발 IE8은 지대로 만들어서, 모두 IE8로 갈아탔음 좋겠당…

스크립팅 미디어 타입 : Scripting Media Types

오늘 스터디하다가, <script type=” “></script>에서 쓰이는 type의 형태에 대해서 잠깐 언급이 되서 정확하게 무슨 차이가 있는지.. 알아보기위해 또 검색을 시작했다.

사실 내가 알고 싶었던건…
text/javascript 와 application/javascript 그리고 application/x-javascript 로 선언된것들의 미묘한 차이였다.
그래서 찾아본 문서는 IETF에서 발행한 RFC4329 문서의
Scripting Media Types 라는 원문을 참고했다.
통번역을 하려고 했으나.. 기술문서라서.. 통번역보다는 그냥 중요부분만 발췌하기로 한다.
스크립팅 미디어 타입은 아래와 같이 다양하게 존재한다.

   +-----------------------------------------------------+
      | text/javascript          | text/ecmascript          |
      | text/javascript1.0       | text/javascript1.1       |
      | text/javascript1.2       | text/javascript1.3       |
      | text/javascript1.4       | text/javascript1.5       |
      | text/jscript             | text/livescript          |
      | text/x-javascript        | text/x-ecmascript        |
      | application/x-javascript | application/x-ecmascript |
      | application/javascript   | application/ecmascript   |
      +-----------------------------------------------------+

하지만, text 라는 시작하는 타입들은 문제의 소지가 있다고 알려져 있기때문에 RFC4329 문서에서는 text/javascript와 text/ecmascript에 “obsolete” 즉, 시대에 뒤진 혹은 안 쓰이는 것으로 표기하고, 대신에 application/javascript 와 application/ecmascript 를 쓸것을 권하고 있다. 
이유는 간단히 얘기하면,.. 구현정의에 있어서.. SHOUD와 MUST의 차이..
그리고 RECOMMENDED와 REQUIRED 라는 단어의 차이다. 
application/ecmascript는 must와 required 로 정의되기때문에.. 이 스크립팅 타입을 쓰게 되면, 좀더 명확한 사용과 어디에 무슨 용도로 쓸때인지를 명확하게 정의할수 있고, 장려할수 있다는 얘기가 되고, 반대로 text/javascript 일 경우에는 너무 널리 사용되기때문에.. 편법이나, 오용할 소지가 있다는 늬앙스를 가지고 있다. 
여튼, 문서를 좀더 자세히 살펴보면, 
소스코드 해석문제, 보다 상세히 얘기하면, 바이너리 소스코드도 소스코드로 해석이 되는데, 이런 바이너리 소스코드를 엔진이 실행할때, 인코딩방법의 차이가 있단다..
그리고 보안 이슈도 있다. 
보안 이슈는 인젝션 공격이라든가, 머 이러저러한 이야기들이 문서안에 있는데…
자세한 내용은 원문을 보길 바란다.
원문을 보기 싫은 사람은 나중에 내가 번역해서 올리길 기다하시길~@@ ㅋㅋ
오늘 여기까지고 어여 자야겠다.. 쓩~!