사파리의 앵커 버그

둘다 같은 me2day의 특정 글을 가르킨 것인데 Firefox는 제대로 나오고 Safari는 해맨다. 절대 me2day의 버그가 아니라 Safari의 버그이다. 왜냐면 같은 페이지 내의 앵커는 제대로 표시되기 때문이다.(리로딩이 없는 경우)

사실

<a name="23:31:22"></a>

이런 식으로 me2day는 앵커를 만들고 있는데 Empty block의 경우 실제 랜더링 영역을 잡지 못하기 때문에 여러 버그를 일으키고는 한다. 아무 내용도 없는 영역은 최적화를 위해 계산을 대충하는 경향이 있어서 문제를 쉽게 일으킨다.

겐도는 땜빵으로 &nbsp; 트릭을 알려주기도 한다. 공백이라는 문자가 존재하는 것이다. 이때는 이 공백을 출력하기 위한 영역을 잡는다. 허나 이것은 정말 땜빵이라는 점을 기억하기 바란다. 아침해가 떠오르는데 모두 정신이 오락가락할 때 쓰기 바란다. 그리고 사우나 갔다와서 제대로 고쳐야 한다.

URL에 앵커가 들어간 경우 즉 # 뒤에 앵커가 지정된 URL이 입력된 경우 브라우저는 로딩이 끝나기 전이라도 해당 앵커가 위치한 부분을 보여주는 작업을 하는게 일반적이다. 반대로 로딩이 끝나도 이 노력은 계속 되어 Textcube에서 "#void"로 href를 지정하고 onclick 이벤트로 실제적인 작업을 할때 JS에서 처리 후 "return false"로 앵커 작업을 취소하지 않으면 이후의 JS 동작이 먹통이 되던 버그가 발생하게 된다.

앵커에 href와 onclick이 같이 지정되고 onclick의 JS가 끝난 후 페이지가 실제로 이동할 필요가 없다면 일단 return false를 적고 보는 습관을 가지는 것을 추천한다. 근본적으로, 웹페이지는 싱글쓰레드로 돈다는 생각을 하면 된다.

더불어 알아둘 사실은 브라우저중에 많은 수가 로딩 중과 로딩 후의 처리가 다른 경우가 많다는 것이다. 같은 기능을 하는 것이라면 공통모듈로 만들면 좋겠지만 최적화라던가, 담당하는 개발자가 다른 경우 별도의 모듈로 분리되기도 하고, 같은 모듈이라 하더라도 타이밍-지금 어떤 상황인가-에 따라 분기되는 경우가 있어서 동작이 영 틀릴때가 있다. 대표적으로 IE는 로딩중과 로딩후의 엔진이 다르다는 설이 있을 정도다. (특히 IE8에서 DOCTYPE을 기술할때와 안할때의 엔진이 다르다거나 "벨리데이터는 벨리데이터일뿐"글에서 언급했던 뭔가 문제가 생겼을때 오류 복구 모드로 빠지면서 엔진 특성이 약간 바뀜도 알아야 한다. 사실 이런 점 때문에 발로 막 짜지 말고 DTD는 최소한 준수하라고 조언하는 이유기도 하다.)

아무튼 억울하게 브라우저의 버그로, 그리고 내가 만약 무지한=일반적인 사용자라면,  "이게뭐야~, 이 서비스 버그아냐? 언능 고쳐주셈"이라고 외치고는 개발자에게 투덜거릴 것이다. 그런것이 현실이다. 전 인류를 전문가로 만드는 노력보단 이런 부분들을 미리 알아내고 처리하는 것이 전문가가 할 일이라 본다.

"미투데이버그"도 아직 안고쳐 진거 같은데 아무튼 이 글에선 난이도 별 10개쯤 되는(만점이 5개 --;) 이야기를 하는지도 모른다. 만박님은 어서 개발진 전체에게 양주 쏘고 나서 쪼시든지 꽃띠앙님이 맥을 지르시던지 아니면 이 문제는 사파리 버전업데이트를 기다린다로 결정 내리셔도 될 것 같고...

이 글에서 하고 싶었던 말은, 웹이란 플랫폼이 상당히 불안하니 개발집단의 리더 혹은 테크니컬 리더 내지 테크니컬 코디네이터라면 이런 부분이 있음을 인지하기 바람과 더불어 개발과 상관은 없지만 개발집단의 명줄을 쥐고 있는 위치의 사람이라면 아부 잘하고 제시간에 프로젝트 완성하는 사람도 중요하지만 이런 부분들을 리딩할 수 있는 사람이 필요하다는 것이다.

"부모 2.0" from Meories Reloaded

기획이 뛰어난 사이트는 당장은 기획적인 부분에 의해 스폿라이트를 받을 지 모른다. 허나 그 기획을 떠 받치고 오랫동안 유지 시켜 주는 것은 기술이다. 최근에 NHN의 독주가 계속 될 것 같다고 예상한 것도 태동기때의 뛰어난 기획자 능력도 있었고 지금도 뛰어난 기획 리더가 있음은 물론이거니와 우수한 개발자를 무자비하게 독점/포섭하고나서 그들을 밑거름으로 삼아 계속 발전하려 하기 때문이다.

개발자라면 자신이 처한 환경에 대한 기술을 끊임없이 습득해야 하고, 경영자라면(+기술 위에서 펼쳐지는 사업을 한다면) 억만금을 주고서라도 뛰어난 개발자를 포섭하거나 아니면 가진 개발자를 잘 키워 먹길 바란다.


덧1.
겐도는 학원 출신이나 SI에 잔뼈가 굵은 개발자는 일단 무시하고 본다. 경험에 따르면 그들은 주어진 조건만 고려하지 그것을 벗어나는 어떠한 환경에 대해서도 생각해 본적이 없다는 것이다. 자사의 제품을 만드는 상황에선 미래까지 고려하면 절대 경계선이 없는데 그들은 현재 지시된 제한 조건내에서만 움직이며 "좀더 생각해 보지?"란 말에 패닉을 일으키는 경우도 있다. 특히 "제한조건을 당신이 정해 보시오"하면 관리자가 할 일을 왜 자기에게 던지느냐고 덤비는 사람도 있었다.
많은 인용을 받았던 "코더로서 적응해 간다는 것"글에서의 생각처럼 그들을 비난하고 싶은 생각은 없지만, 회사는 직원을 키워먹어야 한다는 아니 직원들이 최대한의 능력을 발휘할 수 있도록 유도함으로써 최대한의 가치 발현을 할 수 있다는 생각에 따르고 있다. 더불어 개발인력이 사회의 제대로 된 인정을 받으려면 스스로가 발전을 해야 되고 그런 생각에서 난 이런 의견을 가끔식 적는 것이다. 논조 자체가 맞을수도 틀릴 수도 있겠지만 자극만이라도 할 수 있으면 미래는 지금과는 다르게, 발전할 것이라 본다.

덧2.
글을 시작할 때와 글을 마무리 할 때의 혈중 알콜농도가 곧 발행될(이 다음 글이 될듯한) 이야기에서 보듯 맥주 PT하나를 비우다 보니 마무리가 좀 격해진 감도 없진 않다.
허나 아직도 많은 IT 기업들이 이전의 글 하단의 코멘트 처럼 기술에 투자를 하지 않는다. 아니 IT를 벗어나서 사회 전반적으로 돈놀이만 관심있고 근본적인 것들엔 관심이 전혀 없다. 당장은 반짝 할 수 있을지 몰라도 장기적으로 봐서는 암울하다. 장기적인 것들을 실제로 봐줘야 할 위치에 있는 사람들이 더욱 더 단기적인 것만 보고 있다는 느낌이다. (특히 정치판!)

덧3.
지금 있는 상황이 불합리 하다고 느끼는 개발자나 디자이너분 계시면 언제든지 TNC의 문을 두드려 주세요. (관련링크)
특히 디자이너분은 여기 클릭!
이쁜 UX 기획자도 구하고 있답니다. (특히 겐도가 -ㅅ-)

덧4.
생각이 있는 개발자라면 맥북에어정도는 사달라고 사장에게 메일 보내는거다.
생각이 있는 경영진이라면 개발자가 사달라는 자산정도엔 쉽게 OK 사인 해 주는거다.
참고로 TNC는 경영지원팀에 ISBN을 전달하면 해당책이 며칠 안에 택배로 온답니다.

덧5.
정말 페트 하나를 혼자서 비웠;;;;;;

덧6.
아차 깜빡. 기술적인 코멘트 하나
anchor의 name과 id에 대하여, name에서는 ':'를 넣을 수 있지만 id에는 넣을 수 없다. 뭐 네이버의 문제에서 지적하였듯이 name과 id를 동시에 지정해 줘야 하는 상황이 발생하는데, 따라서 id에 쓸 수 없는 문자를 name에 쓰는 것은 좋지 않다.