올해 4월부터 삼성전자와 LG전자를 통하여 풀브라우징(모바일 브라우징이라고 하는 것이 더 정확)이 가능한 휴대폰이 등장하게 되었다.
게다가 아직 정확한 것은 발표되지 않았으나 LGT에서 월 1만원대의 정액 요금제를 선보일 예정이라고하니 모바일 웹의 활성화를 기대하지 않을 수 없다.
(모바일 브라우징이 시장에 끼칠 영향은 어마어마할 수 있다. 물론 LGT의 전략이 성공한다는 가정이 필요하지만..)

그런데 여기서 문제점이 하나 생기니..
그것은 바로 ActiveX와 비표준으로 도배된 우리나라 웹페이지들이다.
기사에 따르면 SKT는 자사의 멜론에서 음악을 구매할 수 없다. 바로 ActiveX로 된 결제 서비스 때문이다. 기사에서야 저렇게 써놨지만 물론 이 문제는 SKT만의 문제가 아니다.(그렇기 때문에 더 큰 문제라는 것이 안타까울 뿐이다.)

결제 관련한 모바일웹표준이 제정돼 있지 않아 통신사가 풀 수 있는 문제가 아니다

위 기사 중 위와 같은 SKT 관계자의 말을 인용한 부분이 있다.

위의 표는 ETRI에서 2007년 12월에 전자통신동향분석으로 내놓은 모바일 웹 2.0과 모바일OK 표준화 동향이라는 자료이다.

표에 나와 있듯이 모바일 웹 관련 표준인 W3C의 DDC 1.0에서는 HTTPS/SSL이 빠져있어 결제같은 보안이 필요한 서비스는 힘들지만, 한국 DDC 1.5에서는 HTTPS/SSL을 지원한다고 명시되있기 때문에 이것이 가능하다.
결제서비스를 구현하기 위해 ActiveX보다 더 악질의 꼼수(있을지는 모르겠지만..)를 쓰지 않기 위해서라도 하루 빨리 W3C DDC에 HTTPS/SSL이 포함되어 세계 표준이 되어야 할 것이다.(그러는 김에 일반 웹페이지도 바꿔주면 금상첨화고;;)
그 외에도 한국 DDC 1.5의 안은 현재의 추세를 잘 반영하고 있다고 보여진다.(언제 실제로 적용되느냐가 문제겠지만..)

그리고 위의 표에서 주목해야될 점은 마크업 언어가 현재 일반 웹페이지에서 사용되는 (X)HTML이 아니라 XHTML Basic 1.1이라는 것을 사용한다.
XHTML Basic 1.1의 명세서를 보지는 않았지만 기존의 웹페이지와 완벽한 호환이 되지 않는다면 웹표준(모바일 웹도 결국은 웹이니..)이나 크로스 브라우징에도 많은 영향을 끼칠 수 밖에 없게 된다.
실제로 출시될 단말기에 내장된 브라우저가 어떤 명세서를 적용해서 어느 수준까지 구현이 되어 있는지 아직 알 수가 없기 때문에 일단은 지켜봐야 되겠지만 만약 렌더링이 다르게 된다면 크로스 브라우징을 위해 고려해야 될 브라우저가 추가되게 될 것이다.
게다가 벤더마다 서로 다른 렌더링까지 해버리면.. 아주 난감한 상황이 오게 될지도 모른다.

제발 내장 브라우저가 표준 명세서를 충실히 지켜서 개발되었기를 바랄 뿐이다.

덧. 글이 두서가 좀 없군요. OTL;;

텍스트큐브 소스를 다시 보다 대~충 그려본 ERD.
(태터툴즈 사용하다 그냥 티스토리로 넘어가다보니 텍스트큐브를 사용할 일이 없어서 이제서야 조금씩 소스보고 있음;;)

샌드박스 R5614 기준임(텍스트큐브 1.6.1 발표 후 revision임)

FireFox에서 위와 같은 내용을 html 파일로 저장 후 select box를 선택하려고 마우스 클릭을 해보면 선택이 되지 않는다.

position:fixed; 의 값을 변경하거나, text-indent 의 값을 0 이상으로 주거나, select element의 size를 1로 주거나 없애면 정상적으로 선택이 된다.
재미있게도 text-indent의 -값이 적을 경우 일부분만 클릭이 제대로 된다.

그러니까 이 버그는 position:fixed;가 되어 있는 element 안에, text-indent 가 0 미만인 element 와 size가 2 이상인 select element가 같이 있을 경우 생기게 된다.
(조건도 참 복잡하네 -_-;)

FireFox ver : 2.0.0.11

YSlow가 공개되면서 '13가지 규칙'에 대해 관심을 가지는 분들이 계실 겁니다.

이 글은 13가지 규칙 중 첫번째인 Make Fewer HTTP Requests에 나와 있는 CSS Sprites에 관한 글입니다.


실례로 Daum의 실시간 이슈 검색어를 가지고 설명을 하겠습니다.

위의 실시간 이슈 검색어를 보면 왼쪽에 1~15까지 번호가 있는데, 이 것을 표현하기 위해 총 15개의 이미지 파일을 사용 하고 있습니다.
이 것을 하나의 이미지로 만들면 총 14번의 HTTP request를 줄이는 효과를 가져올 수 있습니다.(사실 배경 이미지만 깔고 숫자는 텍스트로 표현하는 쪽이 더 좋겠습니다만;;)

이 방식은 왼쪽의 이미지와 같이 15개의 이미지를 하나의 파일로 만들어 놓은 후, CSS의 background-position 속성을 이용하여 브라우저에 원하는 부분만 렌더링을 시켜주는 방식입니다.

Firebug 같은 Firefox의 확장 기능을 이용하여, Daum의 검색 결과 화면에서 Edit > HTML > body Element에 Edit HTML... 기능을 이용하여 아래와 같은 코드를 삽입해 보시면 어떻게 적용이 되는지 간단히 확인하실 수 있습니다.
이 방식을 실제로 사용한다면 아래의 CSS는 좀 다듬을 필요가 있습니다만 이건 어디까지나 예제이므로.. :)


위의 CSS를 보면 한눈에 보이듯이 번호가 증가할 수록 0, -11px, -22px... 등으로 background-position의 마이너스 값이 증가하게 되어 해당 위치부터 브라우저상에 렌더링 되게 되며 height에 의하여 11px만큼만 보여지게 됩니다.

따라서 여러개의 이미지 파일을 가지고 있는 것과 동일한 효과를 얻을 수 있습니다.

덧. http://google.co.kr 에서 사용하고 있는 이미지 애니메이션 효과도 이 방법을 응용한 것입니다.

위의 캡쳐 이미지에서 보듯이 4개의 브라우저 중에서 Opera가 W3C DOM을 제일 제대로 지원하고 있다.
물론 이 테스트 결과가 절대적일 수는 없다. 참고용 정도로 활용하면 될 듯..

Safari나 IE7은 어떤 결과가 나올런지 궁금하기는 하지만.. 맥도 없고; IE7을 설치할 수 있는 상황도 아니니 패스;;

테스트 URL : http://www.w3.org/2003/02/06-dom-support.html


추가 : Safari 캡쳐 이미지는 http://www.browsrcamp.com/ 이 곳을 이용하여 추가함.

기존의 1.1버전을 태터툴즈 1.1에 맞게 수정하였습니다.


태터툴즈의 검색창에 태그를 자동완성시켜주는 플러그인입니다.

자동완성이 되는 단어는 자신의 블로그에 있는 태그만 됩니다.


자동완성된 태그를 마우스로 클릭하거나 키보드의 위, 아래 키(또는 마우스로 직접 선택)로 선택을 하고 엔터를 입력한 경우 "/tag/"에서 검색을 합니다.
자동완성된 태그를 선택하지않고 직접 입력을 한 경우에는 "/search/"에서 검색을 합니다.
(단, 검색이나 search 등의 버튼이 있는 스킨의 경우에는 버튼을 눌렀을 경우 "/search/"에서 검색합니다.)

그리고 검색창이 포커스를 잃었을 경우 레이어를 자동으로 숨겨줍니다.
(포커스를 얻으면 다시 보여줍니다.)



플러그인 목록에서 사용중으로 변경한 후 옆에 있는 설정 버튼을 통하여 기본 설정을 해주시면 사용할 수 있습니다.

설정을 하지 않은 경우의 기본 설정값과 각 설정값의 입력 방법은 아래와 같습니다.

공개/전체 선택 : 공개
- 비공개/보호글의 태그는 검색되지 않게 합니다.

검색창 focus : yes
- 자동으로 focus를 주기 싫다거나, preloading등의 플러그인을 사용할 경우 no로 선택해주세요.

보여줄 최대 개수 : 5
- 한번에 나타날 자동완성된 태그의 개수입니다.

글자색 : #000
- 자동완성된 태그의 글자색입니다.

글자 크기 : 12px
- 자동완성된 태그의 글자 크기입니다.(단위까지 입력하셔야 합니다.)

글자 폰트 : Dotum
- 자동완성된 태그의 글자 폰트입니다.

배경 투명도 : 80
- 레이어의 투명도입니다.(단위는 %입니다.)

배경색 : #FFF
- 레이어의 배경색입니다.

마우스 오버시 배경색 : #ACF
- 레이어에 마우스를 오버했을 경우 배경색입니다.


※ 혹시 레이어가 위치를 제대로 찾지 못하는 경우가 있으면 TagAutoComplete.js 파일에서 111번째 줄과 117번째 줄에 주석처리가 되어있는 부분의 주석을 없애고 다시 시도해보시기 바랍니다.

이 버전은 태터툴즈 1.1의 사이드바용입니다.

태터툴즈 관리자 모드에 있는 리더에 RSS feed를 설정해 놓은 것을 관리자 모드가 아니라 메인화면에서 누구나 볼 수 있게 만든 것입니다.

이번 1.1버전에서는 여러가지의 카테고리를 보여줄 수 있도록 변경하였습니다. 또한, 스킨-사이드바 메뉴를 통하여 기본적인 설정을 할 수 있도록 제작하였습니다.

목록의 오른쪽 위의 버튼을 클릭하면 설정한 카테고리 내에 있는 RSS feed 목록들 중의 하나를 Ajax로 리로딩 없이 바로 파싱해서 보여줍니다.
파싱하는 시간이 오래 걸릴 경우를 대비해서 파싱 중에는 로딩 버튼이 보이게 됩니다.
(오래걸릴 경우 스킵을 위해 클릭 시의 이벤트에는 차이가 없습니다.)



사용방법은, 먼저 이 플러그인을 사용중으로 변경합니다.
그러면 위의 그림처럼 스킨-사이드바 메뉴에서 추가 가능한 플러그인에 RSS News::RSS News라는 플러그인이 생겼을 것입니다.
그것을 Drag하여 오른쪽 사이드바에 원하는 위치에 Drop합니다.
사이드바에 추가가 되면 편집 버튼이 생기고 그것을 클릭하면 설정창이 뜹니다.
그 곳에서 제목, 새로고침 버튼 위치, 카테고리(리더), 보여줄 갯수를 설정하고 전송 버튼을 누르면 설정이 저장되고 설정한대로 사이드바에 보여지게 됩니다.

설정을 하지 않은 경우의 기본 설정값과 각 설정값의 입력 방법은 아래와 같습니다.

제목 : RSS News
- 스킨에 맞게 html까지 입력해주시면 됩니다.(기본 스킨의 경우 <h3></h3>로 마크업해주시면 됩니다.)

새로고침 버튼 위치 : -30
- 숫자만 입력해주세요.

카테고리(리더) : RSSNews
- 태터툴즈에 내장된 리더에 있는 카테고리를 말합니다.

보여줄 개수 : 5
- 보여줄 개수를 제한합니다.



※ 1.1.1로 버전이 변경되었습니다.

1. 출력되는 목록의 마크업이 <div>에서 <ul><li>로 변경되었습니다.
2. 사이드바를 사용하지 못하는 경우를 위해 [ ##_Sidebar_RSSNews_## ] 이라는 치환자가 추가되었습니다.(양 옆의 공백은 제거해주세요.)
   

FF에서 createElement로 생성한 input element에 focus()를 하려고 할 경우 아래와 같은 에러가 발생하는 문제가 있습니다.
(무조건 발생하는 것이 아니라 특정한 상황에서만 발생합니다.
저같은 경우에는 키보드를 이용하여 트리 구조를 이동하며 동적으로 text input을 생성/삭제하는 기능을 제작할때, 생성한 text input에 focus()를 주면 발생했습니다.)

이 경우 createElement로 생성한 이후에 아래 부분을 추가해주면 해결이 됩니다.

autocomplete 속성이 표준이 아니라는 것이 문제기는 하지만 JS를 이용하여 동적으로 생성해주는 부분이니 이 정도는 애교로 봐줘야(...)

bugzilla에 있는 비슷한 버그 : https://bugzilla.mozilla.org/show_bug.cgi?id=236791

결론. [nsIAutoCompletePopup::selectedIndex] 이런 에러가 날 경우 위와 같이 해주면 해결이 됩니다.

AJAX. 대부분 아시다시피 Asynchronous Javascript And XML의 약어입니다.
비동기의 자바스크립트와 XML이죠.

근데 AJAX로 작업을 해보신 분이라면 아시겠지만 어떤 기능을 AJAX로 구현하게되면 그 기능만을 위한 별도의 XML 페이지를 작업 해야된다는 것을 잘 아실겁니다.
하지만 이렇게 별도의 XML페이지를 제작하게 된다면 당연히 제작/유지/보수에 2배에 가까운 노력이 들게 됩니다.
물론 웹 접근성을 고려해서(이 경우에는 보통 javascript가 disable된 상황) 일반 HTML페이지도 제작한다는 전제하이기는 합니다.
(사실 아쉽지만 대부분의 AJAX로 제작된 사이트들이 이 것을 무시하고 있습니다. 뭐 이런 문제가 있다는 것조차 모르시는 분들이 더 많다는게 문제이기는 합니다만..)

위에서도 말했듯이 2배에 가까운 노력이 드는데도 불구하고(?) 사실 그런 환경으로 웹서핑을 하는 경우가 거의 없기 때문에 얻을 수 있는 효과는 미미합니다. 그렇기 때문에 무시되는 경우가 많죠.

하지만 XML대신 XHTML을 사용한다면 이야기는 조금 달라집니다.
역시나 아시겠지만 XHTML은 XML parser에 의해 parsing이 됩니다.
따라서 애초에 처리되는 페이지를 XHTML로 가능한한 semantic하게 제작을 해두면 큰 노력없이도 AJAX와 웹접근성이라는 두마리 토끼를 다 잡을 수 있습니다.

위의 예제는 W3C의 XHTML1.0 문서에 있는 내용입니다.

위의 예제를 실제 작업할 내용으로 변경해보겠습니다.
예제 페이지는 http://rsef.net/Work/xhtml.php(소스는 http://rsef.net/Work/xhtml.phps)입니다.

맨 위에 header의 Content-Type이 있을 경우 그 Content-Type으로 선언한 것이 보일겁니다. 이 것은 아래의 request.php에서 설명하도록 하고 넘어갑니다.
그 아래 no-cache설정은 실제 작업을 할때는 특별히 고려할 필요는 없겠지만(IE의 경우 xhtml.php와 request.php를 no-cache설정 없이 한개의 window로 볼 경우 문제가 되지만 실제 사용시 그런 경우는 없겠죠.) 이 경우는 예제이다보니 넣겠습니다.
그리고 제가 사용하고 있는 서버는 php의 short_open_tag 설정이 on으로 되어있기 때문에 XML선언부를  echo '<?xml version="1.0" encoding="UTF-8"?>';로 썼습니다.

그럼 이 페이지를 javascript로 요청하는 페이지를 만들어 보겠습니다.
예제 페이지는 http://rsef.net/Work/request.php(소스는 http://rsef.net/Work/request.phps)입니다.

newXMLHttpRequest() 함수야 많이 보셨을테니 생략하고..
request() 함수도 많이 보신 형태입니다.
다만 REQ.setRequestHeader에서 Content-Type을 text/xml로 지정하는 부분이라던가,
성공했을때 false, 실패했을때 true를 return해주는 정도가 흔히 보는 형태와 다를겁니다.

일단 Content-Type을 text/xml로 지정해주면 위의 xhtml.php 설명에서 생략한 $_SERVER['CONTENT_TYPE']에 text/xml이라는 값이 할당되게되며 따라서 xhtml.php의 Content-Type이 text/xml로 되게 됩니다.(일반적인 browser로 접속을 하게되면 값이 없으므로 skip됩니다.)
이렇게 text/xml로 되야 xml parser가 parsing을 할 수 있으니 반드시 필요한 작업이 되겠습니다.

그리고 성공했을때 false, 실패했을때 true를 return해주는 이유는 onclick event에서 실패했을 경우에 xhtml.php로 페이지 이동을 시킴으로써 원래 anchor(a) element의 동작을 보증해주기 위해서입니다.(장담은 못하겠지만;; 이 경우 검색엔진도 실제 contents인 xhtml.php의 접근이 가능할 것입니다.)


위의 예제를 보시면 아시겠지만 크게 신경쓸 것 없이도 상당한 웹 접근성을 확보하는 일이 가능합니다.
물론 실제 작업 중, 특히 동적인(server side) 페이지같은 경우에는 이런저런 문제(대부분은
validate를 통과하지 못하는 문제)가 생길 수도 있습니다.
하지만 XHTML만 validate를 보장해준다면 얻을 수 있는 많은 이점이 있기 때문에 결코 손해보는 일은 아닐 것입니다. :)

ps. 위의 예제는 서버 설정에 따라 약간 수정을 해주어야 할 수도 있습니다.

무려 5개월만에 10,000 hit를 돌파하였습니다.
물론 그 동안 작성한 글이 워낙 없어서이기는 하지만..;;
(옆에 Archives를 보면 바로 납득;)

6월은 작성한 글이 2개 밖에 없는데 3,200 hit라는 대기록(?)을 세웠군요.
무슨 글을 작성했나보니..

• WorldCup 2006 v0.1
• 새 도메인

이렇게 두개의 글이 작성되어있군요. 아무래도 월드컵 기간동안 월드컵과 관련된 플러그인을 올렸더니 방문객이 증가한 것인가 보군요.

7월 한달 동안은 작성한 글이 하나도 없음에도 불구하고;; 거의 2,000 hit를 기록했다는 것이 참 신기하네요.;;

이번달 22일에는 정말 오랜만에 글 하나 작성했더니 30여명이던 방문객이 갑자기 100여명으로 증가하기도 하는군요. 올블로그의 힘인가요? :)

뭐 어쨌든 방문해주신 모든 분들에게 감사드립니다.
10,000hit를 달성하는데 혁혁한 공을 세운 봇님들께도 감사(...)

1. 태터툴즈 : 플러그인 제작 관련한 내용 덕분인지 압도적인 숫자;
   
2. 구글 검색 : 역시 우리의 구글신님(...)
3. 올블로그 : 국내 Blogosphere에서의 올블로그의 파워(?)
   
4. msn 검색
   
5. TnF 포럼 : 나름 열심히 활동 중;;
   
6. 다음 검색
7. 벅스 검색 : 벅스에 검색이 있다는 것을 처음 알았음(...)
8. whois.sc : 도메인 검색을 해주는 곳인 듯 한데.. 제 도메인에 눈독들이지 마세요. T_T
9. rsef.net : ... 버그인가;;
10. 네이트 검색
11. 네이버 카페 : 태터툴즈 플러그인 관련한 링크

목록을 살펴보니.. 역시나 네이버 검색은 우리를 실망시키지않고 목록에 존재하지 않는군요.
"검색 No.1 네이버"라는 단어는 "포탈 No.1 네이버"로 바꾸는게 어떨런지..

그 외에 http://.../id/owner/setting/plugins 로 들어오는 referer도 꽤 됩니다.
환경설정에서 플러그인 설정 부분에 제가 제작한 플러그인에 박힌 링크타고 들어오시는 듯. :)


태터툴즈 1.1이 배포될 때 같이 배포될거라 예상되는 Chiri님의 검색어 통계 플러그인도 해보면 꽤 재밌을 것 같지만 이건 나중의 즐거움으로.. :)

이상 엄청나게 성급한 일반화의 오류를 범하고 있는 포스트의 작성을 마칩니다.