hoi~♡

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는 속성마다 허용되는 부분이 틀리기 때문에 배제하고 테스트를 하였습니다. 테스트 결과는 다음과 같습니다.

이 테스트로 메일 작업에 ‘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을 사용하는 것입니다. 얼마전 타 회사와의 공동 프로젝트에서 이러한 부분들이 간과된채 제작된 메일링 디자인을 본 적이 있었습니다. 자기분야에 대한 스킬도 중요하지만 웹 종사자로서 웹 전반적인 부분들에 대한 이해 또한 중요하다고 생각합니다. 위 내용은 퍼블리셔 뿐만 아니라 기획자, 디자이너 등 모두가 알고 있어야 할 부분이 되겠습니다.

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

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

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

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

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를 계속 사용해줘야 하나요?
머릿속이 복잡하군요 :(