호이♡ http://www.hoiheart.com/wp 호이♡`s Blog Thu, 15 Oct 2009 06:57:42 +0000 http://wordpress.org/?v=2.7.1 en hourly 1 웹 개발자를 위한 스크린 리더 세미나 후기 http://www.hoiheart.com/wp/archives/129 http://www.hoiheart.com/wp/archives/129#comments Mon, 05 Oct 2009 05:27:52 +0000 호이♡ http://www.hoiheart.com/wp/?p=129

지난 9월 26일 잡코리아에서 웹 개발자를 위한 스크린 리더의 이해 세미나가 열렸습니다. 한국시각장애인복지관에서 일하고 계신 백남중 선생님의 강의로 약 3시간 동안 진행된 이 세미나는 현재 웹 개발에 종사하고 계신 분들에게 정보접근보조기기에 대한 근본적인 이해와 활용에 도움을 드리고자 하는 취지로 준비되었습니다. 저는 운이 좋게도 자원봉사자로 참여하는 영광을 누렸는데요. 세미나 참석자로만 지내왔던 저에게 새로운 경험이 되었기에 세미나 관계자 여러분들께 감사하게 생각하고 있습니다 ^^

사실 저도 마크업 개발에 종사한 3년동안 스크린 리더를 직접 접해볼 기회가 없었는데 전반적인 스크린리더의 발전과정, 센스리더를 통한 시연 등을 보게 되면서 정말 많은 것들을 얻을 수 있었던 자리였습니다. 특히, 백남중 선생님께서는 현재 장애인들에게 직접 보조기기 교육을 하고 계시기 때문에 장애인들이 실제로 어떤 부분들에서 어려움을 느끼고 있는지, 보조기기가 가지고 있는 한계점이 무엇인지 등 우리가 생각해봐야 할 부분들을 일깨워 주신 것이 저에게는 참 좋았던 것 같습니다.

현재 센스리더 등의 보조기기들이 html의 문법적인 부분을 모두 제대로 지원해주고, 웹의 다양한 신기술들을 지원해주고 있는 상황이 아닙니다. 언젠가부터 웹표준과 웹접근성이 문법적 유효성과 우수한 측정률 및 인증마크 획득으로 목적이 변질되고 있는 부분이 있는데, 의미에 맞는 코드를 통한 정보전달과 유니버셜한 웹이라는 본래의 목적을 간과해서는 안됩니다. 제가 세미나의 준비단계에서나 강의를 들으면서 가장 놀랐던 게, 센스리더가 웹만 지원하는 것도 아니고 OS나 어플리케이션 까지 죄다 지원하고 있는데 센스리더 개발자는 6-7명 밖에 안된다는 것이었는데, 지원 제대로 안된다고 업체탓만 하는 것보다 웹개발자로서 어떻게 하면 이 상황에서 동등한 정보전달을 해줄 수 있을지에 대한 고민도 해봐야 할 것 같습니다.

세미나가 끝나고 설문을 받아본 결과 샘플코드를 통한 구현예제 등의 기술적인 부분을 원하시는 분들이 다수 계셨는데, 저희가 하는 일이 정답의 코드가 존재하는 것이 아니고, 좋은 예제들은 책이나 블로그에서도 찾아볼 수가 있고, 그런 것들을 다루기엔 세미나의 시간 제약도 있고요. 제가 볼땐 이런 개념의 이해와 간단한 예제, 그리고 마인드를 다잡을 수 있는 계기가 되는 얘기들이 많은 세미나가 더 좋더라구요 ^^ 마크업 개발자들은 특히나 다른 직군보다 더 이런 조건들을 갖춰야만 좋은 코드가 나오게 되는 것 같습니다.

그리고 개인적으로 아쉬웠던 것은, 최근 이런 세미나에서 공식적인 뒷풀이가 있었던 적이 별로 없었는데 이번엔 공식적인 뒷풀이가 있었거든요. 그런데 다들 가시더라구요 ㅜㅜ 물론, 토요일 저녁시간이었기 때문이었겠지만 그래도 시간되시는 분들은 앞으로 많이 참여하셨으면 좋겠습니다. 저 또한 그랬고, 뒷풀이에서 세미나때만큼이나 좋은 분들 많이 만나서 좋은 얘기 많이 듣게 되거든요.

어쨌든 이번에도 전 많은 것을 새로 알게되고, 경험해 볼 수 있었던 있었던 좋은 기회가 되었습니다. 백남중 부장님, 성민장군님 그리고 저빼고 자원봉사자 여러분들께 감사드립니다.

p.s 백남중 부장님, 그 날 세미나 자료 프린트물을 못받아서요… 저말고도 못받은 분들이나 보고싶은 분들이 계실텐데 파일로도 블로그에 올려주셨으면 합니다;

]]> http://www.hoiheart.com/wp/archives/129/feed IR(image replacement)의 문제점들을 해결할 수 있는 기법? http://www.hoiheart.com/wp/archives/125 http://www.hoiheart.com/wp/archives/125#comments Tue, 14 Jul 2009 02:37:51 +0000 호이♡ http://www.hoiheart.com/wp/?p=125

IR(image replacement)을 쉽게 설명하자면 이미지는 통으로 잘라서 쓰고 이미지에 들어있는 컨텐츠 내용은 텍스트로 코드에 심어놓은 뒤 텍스트를 숨기는 기법입니다. 얼핏 보면 왜 저런 짓을 하느냐고 생각할 수도 있는데 제가 볼때 제일 장점은 구축 및 운영의 시간절약, HTTP Request의 감소 부분인 것 같습니다.

웹 에이젼시에서 있을때는 저런 부분이 별로 와닿지 않아서 관심이 별로 없었는데, 아무래도 지금은 업무특성상 컨텐츠 자체가 이미지로 나오는 게 대부분이고 HTTP Request를 최소한으로 해야하는 입장인지라 IR을 꽤 사용하고 있습니다. 이것은 뭐 회사의 방향성의 부분이기 때문에…

그런데 이 IR 기법은 문제가 아주 많다는 것인데, 다들 아시는 것처럼 윈도우 CSS를 이용하여 백그라운드 처리를 하다 보니 고대비 모드, CSS on - image off의 경우, 프린트시, 불필요한 태그의 사용 등이 있죠. 그래서 항상 사용하면서도 꺼림칙했었는데, 어제 퇴근을 하면서 문득 재밌는 방법을 생각해 냈습니다.

Image Replace Code

	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ko" lang="ko">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

	<title>Image Replacement Sample </title>

	<style type="text/css" media="screen">
	.IRContents	 {position:relative;}
	.IRContents	 img	{position:absolute;top:0;left:0;width:400px;height:400px;z-index:10;}
	.replacement	{width:400px;height:400px;overflow:scroll;}
	</style>
	</head>

	<body>

	<div class="IRContents">
		<img src="profile_nowis_img.gif" width="0" height="0" alt="" class="image" />

		<div class="replacement">
			<h1>프로필</h1>
			<ul>
				<li>본명 ...</li>
				<li>출생 ...</li>
				<li>학력 ...</li>
				<li>싫어하는거 ...</li>
				<li>좋아하는거 ...</li>
			</ul>

			<h1>현재</h1>
			<p>경기도 파주에서 ...</p>

			<h1>기타</h1>
			<p>어쩌구 저쩌구 ...</p>

			<h1>기타</h1>
			<p>어쩌구 저쩌구 ...</p>
		</div>
	</div>

	</body>
	</html>

이것이 제가 생각한 코드인데요. 이 방식이 다른 IR 기법과 다른것은 CSS로 Background 처리를 하지 않은 것입니다… 사실 이 코드는 엄밀히 말해서 대체(replacement)한다는 의미는 아닙니다… 그래서 어이없는 방법이기도 합니다 -_-;; 하지만 이 방식은 기존의 IR의 단점을 대부분 커버할 수 있습니다.

단점1. 고대비 모드

윈도우의 고대비 모드 기능을 하용하면 background가 off 되기 때문에 이미지도 안보이고 숨겨놓은 대체 컨텐츠도 안보이게 되는데, 이 코드는 img 태그가 살아있기 때문에 문제가 해결됩니다

단점2. CSS on - image off

이 코드의 대체컨텐츠는 단순히 이미지 뒤에 같은 크기의 박스로 숨어 있을 뿐입니다. 여기에 overflow 속성으로 스크롤만 주면 이미지가 없을때도 컨텐츠를 읽는데 무리가 없어집니다

부가사항. CSS off

하지만 img 태그를 사용하는 방식이기 때문에 css만을 off 했을때, 이미지와 대체 컨텐츠가 중복으로 나오는 문제가 있습니다. 이를 대비하여 img 태그에는 width, height를 0으로 주어 css가 off 됐을땐 이미지가 보이지 않게 합니다.

단점3. 프린트시

뭐 프린트에 대한 경우는 기존의 IR 방식에서도 media type를 이용하여 충분히 커버가 가능한 부분이니 생략하도록 하겠습니다.

단점4. 불필요한 태그의 사용

이 부분은 해결 못한 부분입니다. 결국 시각적으로 ‘중복적인 컨텐츠를 담은’으로 볼 수도 있고, 코드적으로 ‘불필요한 태그’가 들어갔습니다.

뭐 좀 어이없기도 하고, 제가 놓친 문제점도 있긴 하겠지만 IR에 대해 좀 깊이 생각해본 계기였습니다. 그리고 오늘 IR에 대한 글들을 보다가 윤좌진님께서 차라리 longdesc를 사용하는 게 어떻냐는 의견을 봤는데, 센스리더가 longdesc를 지원한다고 하니 그 방법이 오히려 괜찮은 것 같습니다. 대신 longdesc라고 해서 한개당 한페이지를 추가하는게 아니라 책의 ‘역주’를 맨 뒤에 몰아 넣는 것 처럼 longdesc.html 페이지를 하나 만들고 longdesc=”longdesc.html#contents3″ 이런식으로 id값으로 링크를 잡으면 괜찮을 것 같네요. 그럼 이미지와 컨텐츠의 업데이트에 대한 유지보수도 편해질 것 같습니다 :)

]]> http://www.hoiheart.com/wp/archives/125/feed display:none을 다른 방식으로 대체할 수 있을까 http://www.hoiheart.com/wp/archives/117 http://www.hoiheart.com/wp/archives/117#comments Thu, 09 Jul 2009 05:12:04 +0000 호이♡ http://www.hoiheart.com/wp/?p=117

백남중님의 웹 접근과 개발자 그리고 보조공학기기 업체란 글에서 보듯 스크린 리더에서 display:none 인 컨텐츠는 상당히 민감한 문제입니다. 원래 내가 이 분야에서 처음 일할때만 해도 display:none 이라고 해도 센스리더에서는 낭독을 해준다고 했기 때문에 특별히 display:none 에 대한 고려는 하지 않았는데 점진적으로 업그레이드 되면서 현재는 선택사항을 통해 display:none 된 컨텐츠는 읽지 않도록 설정이 가능해졌습니다.

사실 처음부터 css를 이용해서 display:none 시킨다는 것은 “이건 있어도 그만 없어도 그만인 컨텐츠야” 라는 생각에서 아니면 접근성에 대한 이해가 부족해서 이뤄지는 것이라고 생각합니다. 뭐 또 아무래도 현실적인 제약사항도 있으리라고 봅니다. 어쨌든, display:none 과 스크린 리더의 이런 관계로 인하여 최근에는 여러가지 대체기법 중 display를 이용하는 방식을 visibility를 이용하는 방식으로 많이 대체하는 추세입니다.

visibility를 이용한 방식은 visibility:hidden을 이용하여 컨텐츠를 숨기는데, visibility는 컨텐츠의 영역은 그대로 잡고 있기 때문에 overflow, position 등을 같이 이용해서 공간을 잡지 않고 숨겨주는 방식입니다. 이렇게 하면 화면상에서는 숨겨주지만 스크린 리더에서는 인식을 하게 됩니다.

이론상으로는 충분히 display:none을 대체가 가능합니다만, 아쉽게도 그동안 작업해오면서 몇가지 태그에 대해서는 브라우저마다 약간의 해석차이로 인하여 원하는 대로 구현이 안되는 부분이 있었습니다. 이 부분에 대해 정리해 보도록 하겠습니다.

테스트 CSS 적용

일단 display:none의 대체기법으로 사용할 CSS는 가장 보편적인 것 같은(제맘대로?) {visibility:hidden;overflow:hidden;width:0;height:0;margin:0;padding:0;} 속성을 기준으로 사용하겠습니다. 그 외에 font-size:0 이나 line-height:0을 추가하시기도 하는데, 저 속성이 특별히 영향을 끼치지 않았으므로 빼도록 하겠습니다.

테스트1. <hr>

hr은 수평선을 그어주는 태그인데 흔히 레이아웃 상에서 큰 구분들을 나눠주는 역할로 사용되고 있습니다. 센스리더를 써본 적이 없어서 hr 태그를 낭독해주는지 잘 모르겠으나, hr 태그는 CSS를 제거했을때도 그렇고 나름 있으면 도움이 되는 태그인 것 같습니다.

일단 4대 메이저 브라우저 최신버젼에서 {visibility:hidden;overflow:hidden;width:0;height:0;margin:0;padding:0;} 만으로도 문제없이 display:none을 대체 했습니다만, IE6, IE7 계열에서는 일정 공간을 차지하였습니다. hr이 선 + margin 일거라 생각했는데 브라우저마다 렌더링 되는 방식이 역시 다른것 같았습니다. 이에 {position:absolute;top:-10000px;} 을 추가하니 hr이 absolute 포지셔닝 되면서 영역을 차지하지 않는 것을 확인하였습니다.

테스트 CSS 적용 속성의 변경

hr의 테스트를 통해 일단 제가 생각하기에 가장 문제가 없을 것 같아진 {position:absolute;top:-10000px;visibility:hidden;overflow:hidden;width:0;height:0;margin:0;padding:0;} 으로 기준을 변경 하였습니다.

테스트2. <caption>

caption은 표의 제목을 표기하는 태그입니다. HTML 4에서는 caption 내에 inline 요소만 올 수 있었는데 HTML5 부터는 block 요소도 허용하도록 바뀐 것 같군요. caption은 표 데이터의 접근성 향상 부분에서 상당한 역할을 할 수 있는 태그라고 생각합니다.

하지만 불행히도 caption 같은 경우 테스트 CSS 적용으로는 display:none을 완벽히 대체 할 수는 없었습니다. 저 겉보기에 완벽할 것으로만 보였던 CSS도 IE6, IE7 에서는 공간이 붕 뜨는 현상이 발생하였습니다.

테스트3. <legend>

legend는 fieldset 요소의 제목을 표기하는 태그입니다. caption과 비슷한 역할을 해주는 태그로 역시 fieldset 데이터의 접근성 향상 부분에서 상당한 역할을 하게 됩니다.

legend 같은 경우에는 IE6, IE7에서도 문제가 없었습니다만 오히려 FF3.5에서는 공간이 붕 뜨는 현상이 발생하였습니다.

파덕님께서 FF에선 font-size와 line-height를 조절해줌으로써 대체가 가능하다는 제보를 주셨습니다. 감사합니다 (__)

테스트 소스 및 캡쳐화면

상기 테스트에 대한 html 소스 및 테스트 브라우저(IE6, IE7, IE8, FF3.5, Opera9.6, safari3.1)의 캡쳐화면 입니다

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ko" lang="ko">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>Display:none 속성 대체 Test</title>

<style type="text/css">
*	{margin:0;padding:0;}
</style>

</head>

<body style="width:300px;">

<h1 style="border:1px solid #000;">제목</h1>
<table width="100%" border="1">
<caption style="display:block;visibility:hidden;width:0;height:0;overflow:hidden;position:absolute;top:-10000px;">표</caption>
<thead>
	<tr>
		<th scope="col">제목1</th>
		<th scope="col">제목2</th>
		<th scope="col">제목3</th>
	</tr>
</thead>
<tbody>
	<tr>
		<td>내용1</td>
		<td>내용2</td>
		<td>내용3</td>
	</tr>
</tbody>
</table>

<hr style="visibility:hidden;width:0;height:0;overflow:hidden;position:absolute;top:-10000px;" />

<h1 style="border:1px solid #000;">제목</h1>
<form action="" style="">
	<fieldset style="border:none;margin:0;padding:0">
		<legend style="display:block;visibility:hidden;width:0;height:0;overflow:hidden;position:absolute;top:-10000px;font-size:0;line-height:0;">폼제목</legend>
		<p style="margin:0;padding:0">폼내용</p>
	</fieldset>
</form>

</body>
</html>

각 브라우저 캡쳐화면

이처럼 일부 브라우저에서 빈공간이 생겨버리는 caption, legend에 대하여 display:none을 완벽히 대체할 수 있는 방법은 찾지 못했습니다.(찾으신 분 알려주세요 ㅜㅜ) 그리고 대부분의 태그는 대체가 가능했지만 모든 태그를 테스트 한 것이 아니기 때문에, 몇가지 문제가 더 있는 태그들이 존재할 수도 있습니다(사실 이건 브라우저간의 렌더링 방식의 차이지 태그의 문제는 아니죠). 하지만 제 경험으로는 기획서나 디자인상으로 caption, legend을 사용할 만한 부분은 많지 않았고 접근성 향상을 위해 임의로 추가해주는 경우가 많지만 display:none의 속성을 대체할 방법을 찾지 못해 display:none을 사용했었는데 스크린 리더가 이를 읽어주지 않는다면, 접근성을 위해 사용한 부분이 아무런 효과를 발휘하지 못하게 되어지는 것 같습니다. 이렇게 봤을때 백남중님의 말씀대로 보조기기에 대한 기술 또한 브라우저, 보조기기, 마크업 등 상호간에 깊은 이해와 도움이 필요하다는 것을 다시한번 느끼게 됩니다.

p.s 뭐 마크업을 하고있는 개인적인 제 입장으로 봤을때는, 처음부터 display를 none 할꺼면(안보여줄꺼면) 그게 왜 들어가냐는 입장인지라(초기 display를 javascript로 제어하고 숨겨진 것을 다시 보이게 할 수 있는 기능을 갖춘 것은 별개지요) 다 필요한 컨텐츠이므로 스크린 리더 설정도 낭독해도 무방하게 설계된 웹 페이지를 처음부터 만들어야 한다입니다;;

]]> http://www.hoiheart.com/wp/archives/117/feed FCKEditor 적용 팁 http://www.hoiheart.com/wp/archives/93 http://www.hoiheart.com/wp/archives/93#comments Fri, 12 Jun 2009 04:27:37 +0000 호이♡ http://www.hoiheart.com/wp/?p=93

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

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

템플릿 기능

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

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

FCKEditor 캡쳐화면 - 템플릿 버튼FCKEditor 캡쳐화면 - 템플릿 선택화면

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

Tip

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

<Templates imagesBasePath="fck_template/images/">
	<Template title="오른쪽 이미지와 제목" image="template1.gif">
		<Description>하나의 이미지에 제목과 내용이 들어가 있는 형태의 입력 방식</Description>
		<Html>
			<![CDATA[
				<div class="editorTemplate1">
					<p class="img">이미지</p>
					<div class="con">
						텍스트
					</div>
				</div>
			]]>
		</Html>
	</Template>
</Templates>

속성값 부분정도만 유의깊게 보시면 금방 파악이 되실텐데 Templates의 imagesBasePath 속성은 템플릿 샘플 이미지의 기본경로이고, Template의 타이틀은 해당 템플릿의 이름, img는 템플릿 샘플 이미지의 주소입니다. 그리고 <![CDATA[ 에서부터 ]]> 부분 사이가 실제 입력되는 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 샘플을 예제로 설명드리겠습니다.

<Styles>
	<Style name="제목1" element="h1">
		<Attribute name="class" value="editorH1" />
	</Style>
</Styles>

마찬가지로 금방 파악이 되실텐데 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 에디터 사용률로 생각해본다면, 이런 부분에 대한 노하우나 팁 공유도 중요한 부분이 될 것 같습니다.
]]> http://www.hoiheart.com/wp/archives/93/feed IE7 이하 zoom 스타일 제어시 Flash object가 사라지는 버그 http://www.hoiheart.com/wp/archives/87 http://www.hoiheart.com/wp/archives/87#comments Wed, 10 Jun 2009 05:40:08 +0000 호이♡ http://www.hoiheart.com/wp/?p=87 뭐, 상당히 예전에 겪었던 문제였는데 참고 차원에서 정리하는 포스팅입니다. 요즘은 크로스브라우징 얘기도 많고 최신형 브라우저들 자체가 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 해제용 정도로만 쓰잖아요. 이런 문제가 생길일은 극히 드물겠지만 한번 정리해봤습니다 (__)

]]> http://www.hoiheart.com/wp/archives/87/feed 변화 http://www.hoiheart.com/wp/archives/85 http://www.hoiheart.com/wp/archives/85#comments Fri, 29 May 2009 04:19:49 +0000 호이♡ http://www.hoiheart.com/wp/?p=85 부끄럽게도 1년만의 포스팅입니다 ㅡㅡ

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

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

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

]]> http://www.hoiheart.com/wp/archives/85/feed E-Mail 관련 작업시 고려사항 http://www.hoiheart.com/wp/archives/47 http://www.hoiheart.com/wp/archives/47#comments Wed, 02 Apr 2008 08:11:48 +0000 호이♡ http://www.hoiheart.com/wp/archives/47 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을 사용하는 것입니다. 얼마전 타 회사와의 공동 프로젝트에서 이러한 부분들이 간과된채 제작된 메일링 디자인을 본 적이 있었습니다. 자기분야에 대한 스킬도 중요하지만 웹 종사자로서 웹 전반적인 부분들에 대한 이해 또한 중요하다고 생각합니다. 위 내용은 퍼블리셔 뿐만 아니라 기획자, 디자이너 등 모두가 알고 있어야 할 부분이 되겠습니다.

]]> http://www.hoiheart.com/wp/archives/47/feed 공공기관 프로젝트를 마무리 지어가며… http://www.hoiheart.com/wp/archives/46 http://www.hoiheart.com/wp/archives/46#comments Wed, 26 Mar 2008 07:31:28 +0000 호이♡ http://www.hoiheart.com/wp/archives/46 넷스케이프 6.0은 지원하지 않습니다 라는 자바스크립트 alert창 캡쳐화면

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

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

XHTML 유효성 검사 캡쳐화면

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

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

]]> http://www.hoiheart.com/wp/archives/46/feed IE 에서 object data 값에 대한 request 문제 http://www.hoiheart.com/wp/archives/42 http://www.hoiheart.com/wp/archives/42#comments Sun, 23 Mar 2008 13:42:20 +0000 호이♡ http://www.hoiheart.com/wp/archives/42 IE에서 플래시 대체 컨텐츠 확인하기 라는 글에서 플래시 object에 대한 크로스 브라우징 코드를 설명한 적이 있습니다. object 코드 사용에 대한 자세한 내용은 신현석님의 포스트를 참고하시면 좋을 듯 합니다.

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

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

object 크로스브라우징 코드를 IE Watch로 돌렸을때 캡쳐화면

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

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

]]> http://www.hoiheart.com/wp/archives/42/feed ID와 name 속성값의 document.getElementById 접근 http://www.hoiheart.com/wp/archives/41 http://www.hoiheart.com/wp/archives/41#comments Wed, 16 Jan 2008 13:30:53 +0000 호이♡ http://www.hoiheart.com/wp/archives/41 최근 프로젝트부터 접근성 메뉴를 추가시켜 작업하고 있는데 현재의 스크린리더와의 호환을 맞추기 위해 빈 앵커태그를 같이 사용하고 있습니다. (해당 사항에 대해서는 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 속성값이 설정된 엘레멘트가 먼저 나와야 임자를 제대로 찍을 수 있다는 거~~~~

]]> http://www.hoiheart.com/wp/archives/41/feed