hoi♡

FCKEditor 적용 팁

호이♡ — Fri, 12 Jun 2009 04:27:37 +0000

웹표준이 대두되면서 기존 혹은 신규 사이트에서 페이지나 게시물을 관리할 수 있는 HTML 에디터에 대한 관심도 자연스레 늘어나게 되었습니다. HTML 에디터에 대한 종류나 추천의 내용은 CDK의 관련글에서 참고하세요.

제가 다녔던 회사에서도 기존 자체 에디터를 가지고 있었지만 웹 표준에 맞는 코드생성부분이나 부가기능이 부족하여 나중에는 FCKEditor를 공식적으로 사용했습니다. 공개 에디터 툴을 훑어본 적은 있어도 샅샅히 들여다본 건 처음이었는데 퍼블리셔의 입장에서 FCKEditor란 녀석이 생각보다 막강한 기능들을 제공하고 있었습니다. 하지만 HTML 에디터로 생성하는 컨텐츠는 사이트 레이아웃 영역내 하나의 부분에 자리잡게 되는 경우가 대부분이기 때문에 이에 따라서 고려해야 할 부분도 생기게 되는데요. 별로 경험은 없지만 어쨌든 제가 FCKEditor를 사이트에 적용시키면서 문제됐던 부분이나 알게된 팁들을 정리해 봅니다.

템플릿 기능

FCKEditor를 살펴보면서 퍼블리셔의 피가 끓어오르는 가장 멋진 기능이었습니다. 구현방식도 간단하죠.

템플릿은 아래 이미지처럼 사용하고 싶은 템플릿 이미지를 선택하면 자동으로 해당 템플릿 구조의 HTML 소스를 에디터에 삽입시키는 기능입니다.

기본적으로 이 기능을 사용하기 위해서는 HTML, CSS, 약간의 XML을 다룰 수 있어야 합니다. 개인적으로 CSS를 이용한 템플릿화는 수십 수백장의 페이지를 가지고 있는 사이트를 구축하는 웹 에이젼시에서 페이지 제작방식의 꽃이라고 생각하는데, FCKEditor의 이 기능을 통해 CSS로 공통 관리가 가능한 컨텐츠 레이아웃을 입력할 수 있습니다.

Tip

템플릿 기능을 수정할 때 가장 중요한 파일은 FCKEditor 루트에 있는 fcktemplates.xml 입니다. 이 XML 파일에 템플릿에 대한 정보와 HTML 코드를 설정할 수 있습니다. xml 샘플을 예제로 설명드리겠습니다.

속성값 부분정도만 유의깊게 보시면 금방 파악이 되실텐데 Templates의 imagesBasePath 속성은 템플릿 샘플 이미지의 기본경로이고, Template의 타이틀은 해당 템플릿의 이름, img는 템플릿 샘플 이미지의 주소입니다. 그리고 부분 사이가 실제 입력되는 HTML 코드입니다.

다음으로 마크업에 대한 CSS 코드를 추가해야하는데요. 기본적으로 FCKEditor 입력영역은 root/editor/css/fck_editorarea.css 를 바라보고 있는데 어짜피 위지위그 모드에서도 템플릿이 CSS가 입혀져서 보여야 하고 실제 view 페이지에서도 보여야 하니까 저같은 경우는 editor 영역에 대한 CSS파일을 별개로 만들어서 import 시켜 사용했습니다. 뭐 방식은 각자의 성향에 따라~

Style 기능

템플릿 기능이 컨텐츠의 레이아웃을 잡아주는 기능이라 한다면 Style 기능은 개별 요소(Tag)에 대한 스타일의 템플릿화라고 볼 수 있습니다. 원리 자체는 템플릿 기능과 비슷하고 저 같은 경우에는 HX 태그의 스타일 지정, division의 스타일 지정 등에서 사용했습니다.

Tip

Style 기능을 수정하는 XML 파일은 FCKEditor 루트에 있는 fcktemplates.xml 입니다. 이 XML 파일에 템플릿에 대한 정보와 HTML 코드를 설정할 수 있습니다. 역시 xml 샘플을 예제로 설명드리겠습니다.

마찬가지로 금방 파악이 되실텐데 Style 엘레멘트의 name 부분이 에디터에 표시될 해당 Style의 제목이고 element 부분이 삽입될 태그입니다. Attribute 엘레멘트를 사용하여 태그의 속성값을 줄 수 있는데 style attibute로 inline CSS 방식을 사용할 수도 있지만 CSS 사용의 목적상 class로 사용하는 것이 더 유용하겠죠? ^^

CSS import에 대한 설명은 템플릿 기능에서 설명했으므로 패스~

fckconfig.js 변경

FCKEditor에 대한 설정값들이 지정된 파일입니다. 위치는 루트에 있고요.

Tip

뭐 대부분 일반적인 설정부분이고, 중요한 부분이 있는데 FCKConfig.DocType 에 대한 정의 부분입니다. FCKEditor에서 컨텐츠를 입력할때 미리보기 기능이 있는데 이 기능이 팝업창으로 뜹니다. 이 팝업창의 Doctype를 설정해주는 부분으로 작업하고 계신 사이트와 동일한 DTD를 주시면 됩니다.

CSS 초기화에 대한 고민

제가 느낀바로는, HTML 에디터에 대한 사용여부와 종류가 HTML 작업초기에 이미 정해져있어야 합니다. CSS 초기화를 무작정 했을경우 위지윅모드에서 보여주던 화면과 출력 결과물이 다르게 보여질 수 있으므로 신중하게 사용하여야 합니다. CSS 초기화를 하시는 분도 있고 안하시는 분도 있을텐데 제 생각엔 사이트의 규모가 크다면 해주는 것이 좋은 것 같습니다. 물론 위에서 언급한 ‘무작정’이 되면 안되겠고, 초기화 해보신 분들은 다 각자의 노하우를 가지고 계실 것입니다.

Tip

아무튼 FCKEditor를 사용할 때 사이트 CSS 초기화 부분에서 고려해야 할 태그 및 속성은 다음과 같습니다

form
input type=”checkbox”
input type=”text”
input type=”button”
input type=”submit”
input type=”reset”
input type=”image”
input type=”hidden”
textarea
select
strong
em
u
strike
sub
sup
ol
ul
blockquote
div
p
a
img
embed
pre
hX
address
table
caption

이것들이 FCKEditor에서 생성할 수 있는 태그들인데요. 이부분들 중에는 초기화를 시키고 다시 브라우저가 기본적으로 렌더링하는 형태와 비슷하게 복구할 수 있는 부분도 있고 그렇지 못한 경우도 있습니다. 초기화 된 엘레멘트의 스타일 복구는 HTML 4를 위한 스타일쉬트 견본을 참고하시면 됩니다. 위 사항들을 참고해서 좀더 최적화된 CSS 초기화가 가능할 것으로 보입니다.

Flash wmode

플래시 오브젝트에 대한 wmode는 세가지가 있습니다. ‘window’, ‘transparent’, ‘opaque’ 로 wmode를 지정하지 않았을 때의 기본값은 ‘window’ 입니다. 그런데 아무래도 에디터 영역이 사이트의 레이아웃의 한 영역에 자리잡고 있다면 다른 position이 absolute 된 영역과 겹칠 가능성이 있는데요. 이렇게 되면 wmode 값이 ‘window’ 이므로 absolute된 position의 z-index가 제대로 작동하지 않고 플래시가 무조건 상위에 위치하게 됩니다.

Tip

이를 해결하기 위해서 FCKEditor 본문영역의 flash에 대한 wmode 기본값을 변경해주어야 할텐데요. ‘transparent’ 와 ‘opaque’ 어느 값을 줘도 상관없지만 ‘transparent’가 점유율을 더 높인다고 하더군요. 투명플래시를 입력해야 하는 경우가 있는지 여부에 따라서 선택사항이 될것 같습니다.

FCKEditor에서 플래시에 대하여 제어하는 파일은 fckeditor root/editor/dialog/fck_flash/fck_flash.js 입니다.

해당 소스를 보시면 UpdateEmbed( e ) 라는 function이 있는데 그 부분에 object의 속성값을 정의하는 구문들이 있습니다.

SetAttribute( e, 'wmode', 'opaque' ) ;

적당한 곳에 위와같이 wmode를 정의해 주시면 됩니다 :)

지금까지 FCKEditor 사용간 퍼블리셔분들이 알아야 할 팁들을 몇가지 정리해 보았는데요. 사실 전 FCKEditor를 적용한 프로젝트가 딱 한번 있었습니다 ㅋㅋㅋ 이것 외에도 고려할 부분이 상당히 많겠죠. 백 앤드 영역까지 포함해서 보았을때의 HTML 에디터 사용률로 생각해본다면, 이런 부분에 대한 노하우나 팁 공유도 중요한 부분이 될 것 같습니다.

IE7 이하 zoom 스타일 제어시 Flash object가 사라지는 버그

호이♡ — Wed, 10 Jun 2009 05:40:08 +0000

뭐, 상당히 예전에 겪었던 문제였는데 참고 차원에서 정리하는 포스팅입니다. 요즘은 크로스브라우징 얘기도 많고 최신형 브라우저들 자체가 zoom 기능을 자체지원을 하고 있다지만 IE6이 브라우저 점유율을 독식하고 있을 때쯤은 퀵바에 +, - 버튼을 달아놓고 자바스크립트로 IE 전용 CSS 속성인 zoom 을 제어해서 확대와 축소를 하는 기능이 유행이던 시절이 있었습니다.

그런데 zoom으로 제어하는 부분에 플래시 오브젝트가 있을 경우 zoom 스타일 제어와 동시에 플래시 오브젝트가 갑자기 사라져버리거나 깨져버리는 경우가 있습니다. 해당 내용에 대하여 검색해보니 외국사이트에서 이런 현상이 일어나는 조건이 정리된 간단한 테스트 페이지를 찾을 수 있었습니다.(http://www.consol.co.il/test.asp)

해당 현상이 일어나는 조건을 간단히 정리하자면 다음과 같습니다

플래시 오브젝트의 정렬값이 center 혹은 right이다(제 기억으로는 css text-align 속성으로 정렬하는 경우도 마찬가지였을겁니다)
zoom의 범위는 어떤 수치던지 상관없다
플래시 오브젝트의 wmode가 opaque 혹은 transparent 로 설정되어 있다
IE 버전이 7 이하이다(IE8에서 호환성보기 모드로 해봤는데 버그가 일어나질 않는군요)

딱히 이 버그를 한방에 해결할 수 있는 방법은 없는 것 같고요… 저 조건들을 피해야겠죠. 사실 요즘은 zoom 속성을 float 해제용 정도로만 쓰잖아요. 이런 문제가 생길일은 극히 드물겠지만 한번 정리해봤습니다 (__)

변화

호이♡ — Fri, 29 May 2009 04:19:49 +0000

부끄럽게도 1년만의 포스팅입니다 ㅡㅡ

1년이란 시간은 개인적으로도 많은 일들이 일어날만한 긴 시간이라고 생각됩니다
저는 좀 더 멋진 인생을 살 수 있는 여건을 만들만한 정신적인 성장을 주로 이룬 것 같습니다
그리고 행보적으로는 2년 8개월동안 일했던 첫 회사를 떠나, 새로운 곳에서 일 할 기회를 얻었습니다

그래서 새로이 마음을 다잡고자 WP 버젼도 업그레이드 하고, 스킨도 새로 만들어서 입혔습니다
‘서당개 3년이면 풍월을 읊는다’ 더니 웹에이젼시에 3년정도 있으면서 저의 디자인 감각도 쫌 생긴것 같습니다 ㅋㅋㅋㅋㅋㅋㅋㅋ

당분간은 웹에이전시에 있으면서 얻은 노하우들을 정리하는 차원에서 포스팅 할 계획입니다
배운 지식을 되새기는 저에게도, 새로운 지식을 얻기위한 분들에게도 도움이 됐으면 합니다 ^^

E-Mail 관련 작업시 고려사항

호이♡ — Wed, 02 Apr 2008 08:11:48 +0000

E-Mail은 수신자마다 이용하는 툴 및 서비스 업체가 다릅니다. 이런 툴 혹은 서비스 업체마다의 E-Mail에 대한 코드 지원범위가 상이하기 때문에 관련 작업시 이 부분들에 대한 기본적인 이해가 필요합니다.

공통적인 E-Mail의 제약 사항

대부분의 E-Mail 서비스가 제약하고 있는 부분은 다음과 같습니다.

자바스크립트
외부(external) 스타일시트(CSS)
css position 속성
object 태그

메일 송신자가 악의적으로 E-Mail 서비스 업체 혹은 수신자에게 피해를 줄 수 있는 상기 사항들에 대해서는 사용할 수 없다고 보시면 됩니다. 간단하게 부연설명을 하겠습니다.

자바스크립트: 가장 악의적으로 사용하기 쉬운 부분입니다. 무한 팝업 신공 등의 피해가 발생할 수 있습니다.
외부(external) 스타일시트(CSS): 외부 CSS를 지원한다는 것은 CSS 전체를 허용하게 되기 때문에 일부 CSS를 제약해야하는 정책을 위한 하나의 방법으로 보여집니다.
css position 속성: 흔히 레이어라고 불리우는 absolute 포지셔닝으로 서비스 업체의 사이트의 메뉴를 가려버리는 등의 장난질이 가능합니다.
object 태그: object 태그는 상당히 활용범위가 높은 만큼 위험한 태그가 될 수도 있습니다. activeX, object 영역내 타 문서의 로드, 플래시 등이 악용될 우려가 있습니다.

각 서비스 업체마다의 허용범위의 차이

그렇다면 위 사항들만 조심하면 되느냐? 불행하게도 앞에서 설명했듯이 각 메일 서비스 업체마다의 정책이 다르기 때문에 더 많은 부분들까지도 신경을 써줘야 합니다. 현재 외국에서는 이로 인한 혼란을 줄이고자 email standards project라는 이메일 표준정책을 위한 프로젝트도 운영되고 있을 정도로 이슈화가 되고 있기도 합니다.

그럼 이제 주요 포털들의 메일보기에서의 지원범위를 살펴볼까요?
테스트는 우리나라에서 가장 많이 쓰는 네이버, 다음, 네이트, 구글, 야후, 파란 여섯개로 해보겠습니다. 테스트 항목은 다음과 같습니다.

head 태그 안의 internal, external CSS
head 태그 안의 internal, external JS
body 태그 안의 internal CSS(이것은 올바른 형식은 아닙니다만…)
body 태그 안의 JS
플래시 오브젝트

inline css는 속성마다 허용되는 부분이 틀리기 때문에 배제하고 테스트를 하였습니다. 테스트 결과는 다음과 같습니다.

서비스 업체	head CSS	head JS	body CSS	body JS	플래시
네이버	X	X	X	X	O
다음	O	X	O	X	X
네이트	X	X	O	X	O
구글	X	X	X	X	X
야후	internal만 지원	X	O	X	X
파란	O	X	O	X	O

이 테스트로 메일 작업에 ‘JS와 flash는 사용할 수 없다’ 와 ‘CSS는 inline 방식으로만 사용해야 한다’ 라는 결과를 얻을 수 있군요.

그렇다면 css 속성의 지원범위는 어떨까요? gmail,hotmail,yahoo 에 대한 CSS 지원현황을 깔끔하게 정리한 포스트를 참조해 주시기 바랍니다. 아래로 보시면 메일툴들에 대한 지원현황도 있네요.

지원여부가 천차만별이기 때문에 메일에서 이용할 수 있는 CSS도 한정적일 수 밖에 없습니다. 게다가 DTD 역시 서비스사 별로 틀리기 때문에 DTD에 따른 IE의 Box-Model 렌더링 차이 또한 고려해야 합니다. 덧붙여, outlook 2007은 td의 background 속성도 지원을 하지 않는다고 하네요.

몇개월 전, 이러한 문제들을 고려하며 작업한 메일링의 html 코드는 이런식이었습니다.

outlook 2007의 td의 background 속성 부분은 어쩔수 없는 문제일 것 같고, DTD에 따라서 table 혹은 td에 font CSS를 사용했을 때 자식 엘레멘트까지의 적용유무가 틀려지기 때문에 font 관련 속성은 전부 각 엘레멘트들마다 inline으로 지정해주어야 합니다. css는 최소한의 기본적인 속성들만 사용하고 디자인이 복잡해졌을 때는 통짜로 잘라서 이미지맵을 쓸 지언정 position과 float의 사용은 하지 않아야 합니다.

맺음말

이러한 현재 상황에서 메일링 작업시 최선의 대안은 기능이나 디자인이 복잡하지 않고 html 역시 table layout과 적절한 inline style을 사용하는 것입니다. 얼마전 타 회사와의 공동 프로젝트에서 이러한 부분들이 간과된채 제작된 메일링 디자인을 본 적이 있었습니다. 자기분야에 대한 스킬도 중요하지만 웹 종사자로서 웹 전반적인 부분들에 대한 이해 또한 중요하다고 생각합니다. 위 내용은 퍼블리셔 뿐만 아니라 기획자, 디자이너 등 모두가 알고 있어야 할 부분이 되겠습니다.

공공기관 프로젝트를 마무리 지어가며…

호이♡ — Wed, 26 Mar 2008 07:31:28 +0000

최근 작업하고 있는 프로젝트 사이트를 로컬에서 Firefox로 접속했을때의 모습입니다.(프로젝트는 거의 막바지 단계입니다)
인증관련 솔루션(activeX)에서 뿌려주는 아름다운 alert 창이군요 -_-
제가 두번째로 퍼블리싱을 맡은 공공기관 프로젝트인데 사실 첫번째 프로젝트 역시 이런 alert 창만 안떴지 로그인조차 IE가 아니면 할 수 없었습니다.(공인인증서 로그인이 아닌 일반 로그인도 SSL 솔루션이 activeX 기반이었습니다)

전자정부가 openweb 소송으로 인하여 공인인증을 FF와 Safari까지 지원한다는 포스트를 본지가 꽤 지났건만 다른곳은 아직도 제자리 걸음이군요.

개발이 끝났을 때 마크업의 오류정도 입니다. 개발범위가 가장 많은 페이지는 공인인증서로 로그인을 해야 하기 때문에 FF로는 접근이 불가하여 게시판 페이지에서 측정을 했습니다.
HTML은 vaildation이 통과된 문서로 넘겨졌습니다. 참고로 저는 실력이 모자란지라 마크업을 시맨틱하게 한건 아니고 단지 문법만 지켰을 뿐입니다;;
웹 개발자들이 시간도 부족하고, 웹표준이나 접근성에 대한 인식도 낮기 때문에 CVS로 뒤에서 쫓아다니면서 오류를 잡는 형편입니다. 그러나 그러기에는 파일이 너무 많고-_- 좋은 프로세스도 아니죠…

KWAG 11차 워크샵이었던 장차법 세미나를 들으면서 많은 공공기관들이 이제 웹표준과 접근성에 관심을 갖고 있고, 가장 빨리 고쳐야 할 사이트들이라고 들었지만 제 생각에는 가장 고치기가 어려운 곳이 공공기관 사이트가 아닐까 합니다.
짧은 일정으로 인해 스킨바꾸기(?)에 급급하고, 이로 인해 안쓰는 소스나 파일조차 함부로 지울수가 없어 디렉토리와 코드는 점점 지저분해지고, IE에서 잘 돌아가는 솔루션들 바꿀 생각도 없습니다. ActiveX와 자바스크립트 없이는 전자민원을 처리할 수가 없습니다. 플래시 플레이어 없이는 메뉴를 볼 수가 없습니다.
이게 대다수 우리나라 공공기관 사이트의 현실인 것 같습니다. 물론, 이것을 바꾸기 위해 지금도 열심히 웹표준과 웹접근성을 위해 노력하시는 분들은 늘어나고 있습니다만 결코 몇몇 사람들만의 노력으로 전체를 바꾸기는 너무도 힘든 것이 사실이네요~~~

IE 에서 object data 값에 대한 request 문제

호이♡ — Sun, 23 Mar 2008 13:42:20 +0000

IE에서 플래시 대체 컨텐츠 확인하기 라는 글에서 플래시 object에 대한 크로스 브라우징 코드를 설명한 적이 있습니다. object 코드 사용에 대한 자세한 내용은 신현석님의 포스트를 참고하시면 좋을 듯 합니다.

어쨌든, 기존 document.write를 이용하여 js로 다시 찍는 방법보다 conditional comment와 js 함수를 이용하여 직접 HTML에 삽입하는 방식이 훨씬 접근성이 좋기 때문에 그동안 여러 프로젝트에 적용시켜왔는데 엄청나게 혼란을 주는 사건이 발생하였습니다.

대충 이러한 소스가 있다고 가정하면 당연히 IE에서는 IE부분만 해석하고 넘어가리라고 알고 있었습니다. 그러나 이게 왠일… request를 확인할 수 있는 IEWatch로 돌려본 결과 타 브라우저를 위한 object data 부분까지도 request를 받아오고 있었습니다.

현재 진행중인 프로젝트는 이러한 이유로 인해 모든 플래시를 js로 빼고 embed를 이용한 방법으로 바꾼상태입니다(embed에 대해선 request 하지 않더군요) 혹시나 해서 YSLOW를 이용하여 FF에서도 같은 사이트에서 시험해보았는데 FF는 한번씩만 요청하더군요.

그동안 나름 표준과 접근성을 지켜가며 플래시 오브젝트를 사용하고 있다고 생각해왔는데, IE 사용자들에게 2배의 request를 받는다는 것은 문제가 될 부분입니다. 이올라스 소송 문제가 해결되어 이젠 외부JS를 처리하지 않는 날이 온다고 해도 ie를 위해 embed를 계속 사용해줘야 하나요?
머릿속이 복잡하군요 :(

ID와 name 속성값의 document.getElementById 접근

호이♡ — Wed, 16 Jan 2008 13:30:53 +0000

최근 프로젝트부터 접근성 메뉴를 추가시켜 작업하고 있는데 현재의 스크린리더와의 호환을 맞추기 위해 빈 앵커태그를 같이 사용하고 있습니다. (해당 사항에 대해서는 CDK에 관련 댓글이 있으니 참조해주세요)

대략 소스는 위와 같은데 이 때 DOM을 이용하여 ‘top’을 getElementById로 접근하였을때 브라우저마다 접근방식이 틀리다는 것을 알게 되었습니다
몇가지 테스트를 해보니 IE와 Opera는 name속성도 getElementById 로 접근이 되더군요 -_-;
(당연히 id 속성외에는 접근이 안된다고 생각해서 ‘IE’ 모야~ 했다가 Opera도 마찬가지인 것을 보고 혼란스럽습니다;)
파이어폭스와 사파리는 제가 원래 예상한 결과였던 id 속성에 대해서만 접근을 하였습니다.

즉, 위 코드에 대해서 getElementById(”top”)으로 접근하면 IE와 Opera는 앵커 태그에 접근이 되고 파이어폭스와 사파리는 div에 접근이 되었습니다.

간단한 테스트 페이지를 만들어 보았습니다.

1번은 같은 이름의 name과 id가 있을때 name이 문서상 먼저 위치할 경우 getElementById의 innerHTML,
2번은 같은 이름의 name과 id가 있을때 id가 문서상 먼저 위치할 경우 getElementById의 innerHTML,
3번은 name 속성만 있는 input을 getElementById로 접근할 경우,
4번은 name 속성만 있는 앵커를 getElementById로 접근할 경우

1,2번의 결과는 IE,Opera팀은 먼저 입력된 엘레멘트로 접근. FF,Safari 팀은 id로 지정된 엘레멘트로 접근.
3,4번의 결과는 IE,Opera팀은 object 혹은 공백값 반환(존재). FF,Safari 팀은 null값 반환(비존재)

어쨌든 브라우저마다 틀린 해석을 하므로 name 속성과 id 속성의 네이밍이 같으면 위험하다는 결론이 나오는군요~~
혹여 같더라도 다른 엘레멘트로 존재하면 괜찮겠지만 다른 엘레멘트로 존재한다면 그때는 id 속성값이 설정된 엘레멘트가 먼저 나와야 임자를 제대로 찍을 수 있다는 거~~~~

HTML과 스크립트의 구조분리에 대해서..

호이♡ — Fri, 14 Dec 2007 13:01:24 +0000

웹표준에 따르는 문서 구조적 설계에 HTML, JS, CSS는 분리되어야 하는것이 마땅하겠지만, 에이젼시에서 일하면서 이에 반하는 작업을 하게되는 일이 다반사입니다.

그 중에 하나가 바로 HTML과 스크립트의 분리입니다.
흔히 사용하는 탭 메뉴나 펴졌다 접혔다 하는 메뉴 등 주로 display를 제어해서 표현해주는 스크립트에서 생각해볼 문제인데 이것을 제어하는 함수를 onload 혹은 addEventListener를 사용하여 문서가 로드된 후에 실행되게 한다면 문서가 완전히 로딩되기 전까니는 모든 컨텐츠가 보이는 상태에서 레이아웃이 틀어져 있는 상태가 됩니다. 순간적으로 자리를 잡는 장면도 다 티가 나구요… 일반적으로 이 눈에 활짝 띄는 장면에 그냥 넘어가는 클라이언트는 없더군요. 사실 CSS가 읽어지기 전 구조대로 쭉 나열되어 있다가 CSS에 의해 자리를 찾아가는 모습에 대해서도 전에는 안그랬는데 (테이블 레이아웃) 눈에 거슬린다고 하는 클라이언트도 많고요…

어쨌든, 이런 문제로 인해서 저도 문서 중간에(스크립트를 사용할 컨텐츠 마크업 바로 아래부분) 함수를 사용하는 일이 많습니다. 아직은 이런문제에 대해서 고객을 설득할만한 위치도 아니며, 로딩타임 동안의 부자연스러운 화면의 모습이 저 역시도 보기에 좋지는 않습니다 ^^;

JQuery 프레임워크에 $().ready 라는 것이 있더군요. 이것을 사용하면 이 문제를 해결할 수 있을지 모르겠습니다. 아니면 진짜 빠른 서버를 구축해서 순간적으로 로딩이 끝나게??ㅋㅋ

결론은 에이젼시에선 이렇게 나름 고민해야 될 상황이 많은 것 같습니다 . 웹표준을 준수한다는 것이 힘에 부치는게 현실이죠.

IE7의 팝업창 최소값

호이♡ — Sun, 07 Oct 2007 09:58:56 +0000

각 브라우저에서는 window.open을 사용한 팝업창의 최소값이 존재합니다.

IE7 뿐만 아니라 타 브라우져에서도 기본적으로 팝업의 최소값이 존재하고 있었는데 100px 대에서 최소값을 가지고 있었기 때문에 특별히 문제를 느끼지 못했지만 IE7은 가로 250px 세로 150px로서 꽤 큰 최소값을 가지고 있기 때문에 팝업 디자인에 있어서도 인지가 필요할 것으로 보입니다.

http://javascript.about.com/library/blpopup10.htm: window.open에 대한 Reference에서 ie 7에서의 최소값에 대한 언급이 있습니다.

웹접근성 진단평가 VeryFineWeb

호이♡ — Sun, 02 Sep 2007 14:12:55 +0000

얼마전부터 웹접근성 순위라는 제목으로 접근성 준수율로 순위를 정한 게시물이 돌아다니는 것을 보았습니다.
알고보니 cakesoft 라는 곳에서 웹접근성 진단 솔루션으로 VeryFineWeb 이라는 사이트로 서비스를 하고 있었습니다.
회원가입을 하면 최대 50페이지의 원하는 사이트의 접근성을 진단할 수 있습니다.

위의 측정사이트는 제가 작업한 곳은 아니란점… -_-
그냥 어떻게 생겨먹은건지만 보세요

KADO도 그렇지만 접근성을 기계로 평가하는 것을 보니 부족하고 아쉬운점이 많네요
그리고 일괄적으로 검사하다보니까 어떤부분은 표준에 오히려 안맞는 것을 요구하는 부분도 있습니다
(noscript를 head에서도 사용하고 object에 alt를 넣어야 준수율이 올라가지요;;)
이것은 KWCAG1.0 을 기준으로 하기 때문에 어쩔수 없는 것일까요…

빨리 한국 웹접근성 지침이 수정, 보완되어야 겠네요
각종 기관들에서 이제 여기를 보면서 %를 높여주길 원할텐데… -_-
그래도 요즘은 많은 분들이 접근성에 관심을 갖고 열심히 활동하시기 때문에 좋은 결과가 나올것이라 기대합니다 ^^

어쨋든, 이 곳 덕분에 이제 접근성 부분에도 더 많은 관심을 갖게 될테니 잘된 일이군요 ^^