1.1 RC3을 출시하고는 (
관련발표) 비가 그치기를 기다리면서 주절주절.
주로 내부 PHP 함수와 QA만을 전담하다 이번에 CSS와 JS까지 손보는 작업까지 하면서 나름대로 세운 기준들을 적어볼까 합니다.
1. Static과 Dynamic의 분리
이번에 사이드바 ajax 코드를 넣으면서 고민 되었던 것은 로딩 시간입니다. 최초 로딩이야 어쩔 수 없다지만 매번 10년씩 걸리면 문제가 생길 수 밖에 없죠. CSS도 커지고 JavsScript의 양도 데이터를 능가할 정도로 커졌습니다. 말 그대로 사이트가 2~3배 느려질 수 있는 요소입니다.
JS와 관련해서는 좀 쓸데없이 함수를 부르는 경향이 커지더라도 스태틱한 JS 부분을 만들어 외부 파일로 빼는 것이 좋은 것 같습니다. PHP에서 생성해야 하는 JS부분도 가능한한 인자로 뽑아서 브라우저상에서 도는 부분이 많도록 하는 것이 로딩 속도 개선에 도움이 될 것입니다. 역시 IO가 가장 느리죠.
다만 브라우징 컴퓨터에 부하가 높아져서 페이지의 변신과정을 0.5배속으로 보는 현상도 발생합니다. 적당한 트레이드 오프도 필요하겠지만 이경우 오히려 JS 없이도 모든 기능이 동작하게 하는 것도 방법입니다.
2. HTML, CSS, JS / Data, View, UI 삼권 분리
흔히들 시멘틱 웹이라 하면 CSS랑 JS를 꺼도 뭔가 보이는 웹페이지를 의미한다라고들 하지만 현재 저의 생각은 그렇게 하나 안하나 구글 로봇은 저의 테이블 떡칠 블로그도 잘 퍼간다입니다. 아무리 XHTML에 맞춰 데이터를 기술한다 해도 파싱이 쉬울 뿐 시멘틱의 발견은 전혀 다른 예기가 됩니다. 제 글중에서 책 그림, 제목, 서평을 찾아 내기 위해선 결국 데이터의 설명이 별도로 필요합니다. RSS나 다른 데이터 교환 스펙들이 오히려 정확합니다.
다시 CSS와 JS의 이야기로 돌아와서, CSS를 끄면 당연히 블로그 화면은 사람이 읽기 어려운 상태로 바뀔 것이고 JS를 끄면 몇가지 동작이 제한 될 것입니다. 어떤 사람들은 일부 브라우저 환경에서는 이것을 사용하지 못할 때도 있으니 없어도 동작하게 만들어야 한다고 하지만 이는 자칫 CSS로 해야 할 일을 HTML로 하게 되고 JS가 해야 할 일을 CSS로 하게 만드는 부분이라고 보입니다.
정확히 HTML 혹은 XHMTL를 출력할 때는 페이지에서 보여주어야 할 데이터에 대해 고민하고 CSS는 화면의 표시, 그리고 JS는 일반적인 HTML 컨트롤만 사용하는 제한적인 사용자 인터페이스를 좀더 다양하게 확장해 주는 역할을 해야 한다고 보입니다. 완전한 3개의 기능 분리가 일어나면 당연히 JS 없이도 대충 사용하는데 지장없고 CSS가 가출을 해도 사용자 CSS를 입히면 대애충 작동에 문제가 없게 되겠지만 그것을 노리고 삼권불리를 하는 것은 아닙니다.
실제로 이번에 작업을 해 보면서 데이터의 문제와 보여지는 문제, 그리고 사용자 인터페이스의 문제는 구분이 됩니다. 삼권 분리가 잘 된 상황에서는 해당하는 계층(Layer)만 손을 보면 되지만 태터의 "글목록"같이 데이터베이스까지 달려갔다 오는 곳의 경우 버그 하나에도 많은 시간이 소요되는 것은 물론이고 새로운 기능이 추가되려 할 때 상당한 복잡도를 가져다 줍니다. 더불어 QA 과정에서도 기능이 여러 레이어에 걸쳐 있는 것은 테스팅이나 검증에서도 악영향 입니다.
성격이 다른 레이어는 구분하는 것이 좋다는 것은 개발/유지 보수 측면에서 많은 장점들을 주고 비지니스 기회를 잡아나가는 데 적절한 대응을 할 수 있다는 것은 쉽게 예상할 수 있을 것입니다. JS를 끄고도 잘 동작하게 HTML을 개조하라는 것이 아닌 버튼을 누르면 폼 전송이 일어나는 것을 드래그엔 드랍으로 사용자가 쉽게 사용할 수 있도록 하는 것입니다.
3. inline style은 댓가를 치른다. 더불어 CSS의 id 기술자도 만만치 않다.
몇 웹 표준책을 보면 inline 스타일에 대해서 위급할 때 쓰게 되겠지만 이후에 댓가를 치른다는 말이 나옵니다. inline은 너무나 강력하여 inline이 아니고서는 그 효과를 변경할 수 없습니다. 그래서 태터도 많은 부분을 inline이 아닌 class로 스타일을 기술하도록 변경하였습니다. 헌데 CSS에서 ID의 사용도 만만치 않음을 알게 되었습니다.
CSS의 기술자(Specifier)에서 ID를 사용하는 것은 상당한 힘을 가지고 있습니다. 한번 이것으로 선언하면 다시 ID에 클래스 몇개를 더 붙여야 오버라이딩이 가능합니다. 반대로 ID는 한번에 자신이 원하는 엘리먼트를 정확히 집어내므로 쉽게 유혹에 빠집니다. 결과는 inline과 동일하게 important라는 극약 처방을 쓰게 됩니다.
최근에 생성된 페이지나 데코레이션의 경우 ID는 정말 마지막에 쓰도록 권장되었습니다. 가능하면 태그로 접근하고 큰 부분들을 클래스로 접근하도록 하였습니다. ID는 정말 특이한 놈이고 작은 단위인 경우에만 쓰며 반대로 HTML을 기술할 때 JS에서 접근하는 용도로나 선언되지 왠만해서는 class만 제공하는 식으로 하였습니다.
바퀴벌레를 잡는데 핵폭탄을 쓰는 편이 가장 확실할지 모르겠지만 역시 적절한 양의 살충제가 더 효율적이고 사이드 이펙트가 적겠죠.
이번에 실제로 작업하면서 많은 것들을 배웠고 아마 다음 개비(?)때 이런 것들이 반영되어 좀더 깔끔한 구조의 결과물들을 만들 수 있게 될것입니다.
보너스. href와 onclick
사실 이 글을 쓰게 된 것이 최근에 오베 들어간다는 사이트의 코드를 보고는 양복입고 스폿라이트를 받으면서 잘난채 하고 있는 영업/경영인들을 위해 날밤까고 있는 개발자 분이 생각나서 혹시나 도움이 될까 때문입니다.아직 제가 웹쪽을 시작한지 몇달 되지도 않아 도움이 될 가능성은 낮아 보이지만 저 코드들 다 디버깅 하고 안정하 시키려면;;; 무섭군요.
흔히 anchor element를 만들고 href는 엄한곳을 가르키게 하고는 onclick으로 많은 것을 합니다. 장점은 커서를 가져다 대면 밑줄도 그어주고 커서도 바뀐다라는 것들. 발표회 자료를 보니 CSS 꺼도 잘돈다 하길래 JS를 껏더니 거의 모든 기능 링크가 죽어버리더군요.
개인적인 견해는 href와 onclick은 항상 듀얼로 정상 동작하게 만드는 것이 좋다입니다. 우선 해당 버튼이 클릭되었을 때 어떤 화면이 보여져야 하는 것은 href가 가르키는 URI에서 명확히 할 수 있습니다. onclick을 통해서 HTTPRequest를 하고나서 화면을 성형수술 한 후 결과물은 바로 해당 링크의 결과물과 비슷해야 겠죠. JS가 꼬여서 문제가 발생한다 치면 onclick만 없애버리면 당장 서비스에 문제는 없습니다.(위에서 말한 삼권 분리와 연관됩니다.) 또한 간단한 변화가 아닌 "대 운하공사"급의 경우 URI의 결과물을 JS에서 이용할 수도 있습니다.
보너스로 상태줄에 링크가 표시된다라는 점, 그리고 어떤 이유에서든지 JS가 에러가 나서 더이상 수행이 불가능한 타이밍에도 기능이 동작될 수 있다라는 것을 들 수 있을 것입니다.
( 참고로 JS의 런타임 에러는 아무리 코드가 정상적이어도 통신 문제나 타이밍, 클라이언트의 다른 프로그램-백신이나 보안 설정등-에 의한 영향에 의해 쉽게 발생됩니다.)
PS.
이번에 1.1 RC3을 내면서 개발자로서 부끄럽다고 생각되는 부분이... JS에 문제가 생겨 사파리에서 파일 업로드가 안되게 되었다는 것. 사실 JS 걷어내면 오히려 업로드가 될지도 모르겠습니다. 오페라.. 한번도 테스트 못해봤습니다. 컴터에 깔아는 놨는데;;;
파폭은 한글입력과 관련하여 너무 문제가 많더군요. 특히 맥OS X상에서 FF는 몇가지 버그 현상을 일으킵니다. 도저히 못잡겠다는;;;
PS2.
위의 견해는 이제 막 웹프로그래밍 걸음마 때는 사람의 글이므로 공개적으로 망신 주셔도 괜찮습니다. 뭐 지금까지도 워낙 구박 받으며 살아온 인생이라;;;
이런 메뉴가 추가됩니다.
여기서 FF의 FireBug처럼 엘라먼트의 스타일을 바로 수정할 수 있습니다.
그외 기능으로 패스워드창에 CapsLock 상태 아이콘이 나옵니다.
사파리에서 깨지는 티스토리 로긴창이긴 합니다만(언제 고칠건데 박군!) 아무튼 패스워드창에 포커스가 있을 때 CapsLock이 켜져 있는 경우 느낌표가 나옵니다.
