태그 보관물: Web Standards

웹 퍼블리셔의 업무 범위

좀 오래전 얘기이나 한번쯤은 제 생각을 써놓는게 좋을듯 싶어 풀어 보려합니다.

항상 많이 나오는 질문중에 하나는 웹 퍼블리셔가 자바스크립트를 해야하나요 라는 질문입니다. 우리나라에 웹 퍼블리셔 라는 용어를 만든 현석님은

지금은 웹에 어플리케이션의 개념이 많이 들어오고 있지만 웹은 기본적으로 문서다. 그래서 문서나 책을 출판하는 퍼블리시(publish)라는 단어를 생각하게 되었고, 실제로 이 단어는 이미 여러곳에서 사용되고 있었다. 플래시에서 HTML 코드를 만드는 기능도 퍼블리시고 MS 프론트페이지(FrontPage)에서도 퍼블리싱이라는 용어를 썼다. 그리고 어도비(Adobe)에서도 웹페이지를 만드는 작업을 웹 퍼블리싱(Web publishing)이라고 지칭하고 있었다. 이 외에도 많은 툴에서 웹페이지를 실제로 제작하거나 배포하는 단계를 지칭해서 퍼블리시라는 단어를 많이 쓰고 있었다. 웹을 출판하는 사람이라는 의미가 기존의 시각에만 집중한 웹 저작과는 반대되는 의미를 가지고 있다는 느낌도 이 용어를 선택하게 된 이유중의 하나였다. – 웹 퍼블리셔라는 말을 만든 이유 – (hyeonseok.com)

무슨 말인지 쉽게 이해하기는 힘들지만 내가 이해 하기로는 실제로 사용자가 보고 사용하는 웹 페이지를 만드는 사람을 뜻한다고 생각했습니다. 암튼 제가 생각하는 웹 퍼블리셔(요즘은 이 용어에 대한 의문도 많이 생기긴 하지만)는 실제로 사용자가 실제로 사용하는 기술이라면(예를들어 자바스크립트, 플래시, 실버라이트 같은) 다 할 수 있어야 한다고 생각 했습니다.

그러나 무슨 웹 퍼블리셔가 만능 슈퍼맨도 아니고, 그 많은 기술들을 어찌다 마스터해요… 그리고 HTML, CSS만 잘하기도 얼마나 힘든데 말이죠. ㅠ_ㅠ 그래서 저는 웹 퍼블리셔라고 해서 꼭 자바스크립트나 플래시 등을 모두 잘할 필요는 없다고 생각합니다. 자바스크립트를 업무로 한다고 더 실력이 좋은 웹 퍼블리셔라고 생각지도 않고요.

그러나 이전의 포스팅에서도 언급했듯이 웹 페이지를 만드는데 이용되는 기술을 이해하는것은 정말 중요합니다. 사실 내가하지않더라도 다른사람의 작업에 대한 이해도가 있어야 커뮤니케이션에도 문제가 없고 작업의 효율도 올라갈것이기 떄문입니다.

더구나 사용자가 직접적으로 사용하는 기술인 Front-end단의 기술등은 좀더 높은 이해도를 가져야 한다고 생각합니다. 내가 직접적으로 해야하는 작업들만 신경쓰고 타인의 작업을 신경쓰지 않는다면 만들어진 결과물은 결코 좋다고 볼수 없을것같습니다.

다 잘할 수 있으면 더욱 좋구요.

어디까지만 공부해야하는지 고민하지 말고 할 수 있는 만큼은 다 노력해서 최대한 많이 내 자신의 지식으로 만들었으면 좋겠습니다.

meta tag 정리

html페이지에 meta 태그를 많이 쓰는데 한번 쯤 정리해 보고 싶어서 찾아봤습니다.
일단 meta에 대한 단어의 뜻이 필요하겠죠??

http://engdic.daum.net/dicen/search.do?m=all&n=search&endic_kind=&q=meta

찾아보니 뭔 헛소리인지 모르겠더라구요 그래서 좀더 찾아보니

http://www.terms.co.kr/meta.htm

이런글이 나오네요..
뭐 길게 써놨는데 일단 필요한건 첫줄!!

“대부분의 정보기술 용례에서 “메타”란, “근원적인 정의 또는 설명”을 의미하는 접두사이다.
그러므로, 메타데이터란 데이터에 대한 정의나 설명이 되고, 메터언어란 언어에 대한 정의나 설명이 되는 것이다.”

라고 합니다.
이 정도로 영어공부는 그만 하고;;;

meta 태그는 HTML문서의 메타데이터(데이터 즉 자료에 대한 정보를 말함) 공급하는 태그입니다.
떄문에 정보만 가지고 있기 때문에 화면이나 코드에는 표현이 되지않지만 컴퓨터는 이해하는 정보가 되는것이죠.
그래서 일반적으로 meta 태그는 페이지의 키워드나, 페이지를 만든사람, 마지막으로 업데이트된 날짜, 등등의 정보를 넣어주면 컴퓨터(현재는 브라우저)에서 인식을한다는것같아요~
페이지의 인코딩이나 타겟브라우징(현재 IE)을 설정할 수 있기도 하고. 그리고 페이지를 리다이렉트 시키기도 하고 뭐 그런 용도로 쓰이는 태그입니다.

그래서 브라우저는 meta 의 정보를 보고 이페이지의 인코딩, 저작자, 내용, 업데이트 된 날짜 등등을 알아내고 그에 맞게 반응을  합니다.

에서 참고했습니다.

참 meta정보는 head 태그에 넣어야하구요. 인코딩 정의 메타태그는 맨 앞에 넣어주는게 좋습니다
이제 대충 뭔 태그인가 알아봤으니 써봐야겠죠.


<!-- 제일중요한거! -->
<meta http-equiv="content-Type" content="text/html; charset=UTF-8" /> : 웹 문서의 인코딩 설정.

<meta http-equiv="Last-Modified" content="Sat,22 01 2011 10:07:30" /> : 최종수정일을 정의.

<!-- 이건 페이지를 자동으로 이동하는건데 사용자가 의도하지않은 액션이 생기므로 접근성에 별로 좋지 않아요:) -->
<meta http-equiv="Refresh" content="15;URL=http://mydeute.com/txp/" /> : 페이지이동
<meta http-equiv="Page-Enter" content="RevealTrans(Duration=5/시간 초단위, Transition=21) " /> : 페이지 로딩시 트랜지션 효과(장면 전환 효과)
<!-- 이걸쓰면 검색엔진이나 브라우저에서 정보를 잘긁어간다는!! -->
<meta name="Subject" content="홈페이지 주제 입력" />
<meta name="Title" content="홈페이지 이름 입력" />
<meta name="Description" content="설명문 입력" />
<meta name="Keywords" content="키워드 입력" />
<meta name="Author" content="만든사람 이름" />
<meta name="Publisher" content="만든단체/회사 이름" />
<meta name="Other Agent" content="웹책임자 이름" />
<meta name="Classification" content="카테고리위치(분류)" />
<meta name="Generator" content="생성프로그램(에디터)" />
<meta name="Reply-To(Email)" content="메일주소 입력" />
<meta name="Filename" content="파일이름 입력" />
<meta name="Author-Date(Date)" content="제작일" />
<meta name="Location" content="위치" />
<meta name="Distribution" content="배포자" />
<meta name="Copyright" content="저작권" />

<!-- 검색엔진에서 뭘가져갈지 허용범위를 설정해주는~ -->
<meta name="robots" content="ALL" />
<meta name="robots" content="index,follow" /> : 이 문서도 긁어가고 링크된 문서도 긁어감.
<meta name="robots" content="noindex,follow" /> : 이 문서는 긁어가지 말고 링크된 문서만 긁어감.
<meta name="robots" content="index,nofollow" /> : 이 문서는 긁어가지만, 링크된 문서는 무시함.
<meta name="robots" content="noindex,nofollow" /> : 이 문서도 무시!, 링크도 무시함.

<!-- 캐시 컨트롤 -->
<meta http-equiv='Cache-Control' content='no-cache' />
<meta http-equiv="Expire" content="-1" /> : 캐쉬 완료(파기)시간 정의.
<meta http-equiv='Pragma' content='no-cache' /> : 캐쉬가 되지 않게 하는 태그

물론 다쓸 필요 절대 없고
주로 쓰는거를 보면


<meta http-equiv="content-Type" content="text/html; charset=UTF-8" />
<meta name="Keywords" content="키워드 입력" />
<meta name="Author" content="만든사람 이름" />
<meta name="Description" content="설명문 입력" />

아무래도 대충 찾아본거라 부족한점이 많습니다.
잘못된거나 지적질 환영합니다.
그럼 안녕~

p.s 참 이 메타태그리스트는 어떤 사이트에서 참고를 한건데 사이트가 기억이 안나네요. 찾으면 출처 및 참고 업데이트 하겠습니다.

웹 페이지의 내실을 다져야 할때

예전에 웹 사이트를 만들때 사람들이 흔히 하던 얘기가 “한국은 네트워크 속도가 빠르니, 페이지 용량은 그렇게 신경쓰지않아도 괜찮아!” 라는 것이었습니다. 그래서 사람들은 퀄리티 좋고 화려한 사이트를 만들기 시작했죠. 플래시도 사용하고, 큰 이미지도 쓰고 해서 화려한 사이트를 만들기 시작 했는데;….

갑자기 스마트폰이니 아이폰이니 하는 상대적으로 느린 네트워크를 이용하고 작은 화면을 사용하는 환경이 추가가 되었습니다. 그래서 사람들은 작은 화면과 느린 네트워크에 최적화를 시킨 모바일 전용 사이트를 만들기 시작 했습니다. 작은 화면에 맞추려다보니 콘텐츠가 빈약해지기도 했습니다. 그래도 많은 모바일 전용 사이트가 생겨서 그냥 그런데로 사용을 했죠. 그런데 이제는 아이패드나 갤럭시탭 같은 화면은 크지만 이동하면서 사용하는 환경이 추가 되었습니다. 이제 웹 사이트를 만드는 사람은 어떻게 대응할까요? 또 아이패드 전용, 갤러시탭 전용 페이지를 만드시겠습니까?

물론 환경이 되고 돈이 가능하고 그렇다면 각 환경에 맞는 웹 페이지를 따로 만드는것이 가장 좋은 방법일지 모릅니다. 각 환경별 사이트를 만드는데 곱절의 시간이 들고 그 사이트들을 관리하는데 또 곱절의 시간과 인력이 투입 되어야 합니다. 그냥 원래 페이지를 내용에 충실한, 그리고 어떤기기에서도 무리없이 이용할 수 있게 만들수 있지 않을까요?

제가 보기에 모바일 사이트들을 보면 구멍난 곳을 계속 그때 그때 땜빵하는 처리 방식으로 밖에 안보입니다. 앞으로 얼마나 다양한 환경에서 웹페이지를 보게 될지는 아무도 모릅니다. TV에서도 보고 냉장고에서도 볼지 모릅니다. 손목시계만한 곳에서 웹 페이지를 볼지도 모릅니다. 그럴때마다 전용 페이지를 만들 수는 없죠. 현재는 타겟 기기가 얼마 안되지만 이제는 몇몇 기기만 대응해서 웹 페이지를 만들어서는 안될것입니다. 그래서 One Web 이 중요합니다.

이미 CSS3의 미디어 쿼리등의 기술이 많이 소개 되었고 많은 곳에서도 적용이 되고 있습니다. 하나의 페이지를 만들어서 다양한 환경에서 웹을 볼수 있게 해주는 방법은 얼마든지 있습니다. 또한 특정기기에 종속적인 기술은 웹 페이지에서는 더 이상 사용해서는 안될지도 모릅니다. 아님 사용하더라도 그러한기술들이 표현되지 않을때의 대안을 준비해야 할것입니다. 이렇게 만든 페이지는 어떤 환경에서도 웹 페이지로서의 역할을 충실히 해낼것 입니다. 저는 그런 웹 페이지가 많이 생기길 바라고 있습니다.

img에 onerror이벤트를 tag의 속성이 아닌 자바스크립트로 등록하기

img가 로드가 안될때 기본이미지를 보여주고 싶을때 onerror를 사용합니다.


<img src="기본이미지.png"  alt="대체텍스트" onerror="this.src='대체이미지.png';" />

이런식으로 사용을 하는데;  문제는 validator 에서 onerror은 에러로 뱉어내버리죠…
그냥 안쓰거나 밸리데이터 따위 무시해주면 되겠지만 onerror도 사용하고 밸리데이터도 통과해야하는 경우가 얼마든지 있을수있죠.
그래서 그냥 이벤트를 자바스크립트로 등록하는것을 만들어봤습니다.

핵심은 IE와 IE외의 브라우저가 이벤트 등록하는것이 다르다는것입니다.
IE의경우에는 attachEvent 를 이용해서 onerror를 등록하고  일어난이벤트의 srcElement의 src값을 변경해주면 됩니다.


"이미지DOM".attachEvent("onerror",function(e) { e.srcElement.src ="images/pic_noimg.gif"})

그외 Opera, FF, safari, chrome 에서는


"이미지DOM".onerror = function(e) { e.target.src = "images/pic_noimg.gif";};

이렇게 해주니 되더라구요. 사실 addEventListener를 사용해볼까 했었는데 귀찮아서 패스=_=
그럼 이만(제목에 비해 겁네 포스팅이 허접하군요=_=/ )

CSS nite in seoul vol.2 후기

이번 가을은 무슨 바람들이 불었는지 세미나 컨퍼런스가 참 많았는데… 이번에는 두번째 CSS nite in seoul을 참석하게 되었습니다. 🙂

CSSnite는 일본 전역에서 열리는 웹 기술 컨퍼런스라고 합니다. 그중의 서울컨퍼런스를 올해로 두번째로 하게 되었는데요. 일본의 컨퍼런스이니만큼 많은 일본의 발표자들이 오셔서 훌륭한 발표를 해주셨습니다.

우리나라 에서 열리는 대부분의 웹 표준, 웹 접근성 컨퍼런스가 실제 현업에서 관련일을 맡아서 하는분들이 직접 준비하고 스피커로 나서주시고 그래서 몇 년전만 해도 미숙한 부분도 많이 보이고 그랬는데 요즘에 열리는 컨퍼런스들은 뭐 전문적으로 컨퍼런스를 하는분에 버금가는 준비와 퀄리티가 느껴질 정도 였습니다. 저도 저렇게 잘할 수 있을까 하는 숙제도 하나 받은 느낌입니다. 이번에 모임을 준비했던 많은 분들이 정말 수고를 많이 하셨을것 같습니다. 정말 감사하고 또 고맙습니다. 다음에도 부탁드릴께요. ㅋ

제가 애초에 기대를 했던 세션은 오후지 미키씨의 CSS3 세션이었는데 어려운 여건에서도 참 좋은 발표를 해주셨다는 생각이 들었습니다. 프로젝터가 빨간색을 잘 표현해 주었다면 정말 수준높고 재미있는 세션이 되었을텐데 그점이 옥에 티라면 티일까요? 또한 발표중간에 30분이라는 긴 공백이 있었음에도 불구하고 다시 세션이 시작될때 바로 집중 할 수 있게 되는 그런 훌륭한 발표였다고 생각합니다.

그리고 하타노 후토미씨의 HTML5세션은 사실 그렇게 기대하지 않았는데 정말 도움도 많이 되고 많은것을 얻어갈 수 있었습니다. 처음에는 API 부분만 너무 강조하는게 아닐까 라는 생각만하고 별기대를 안했는데; HTML5에 대한 전방위적으로 한번 얘기하고 api를 접근하는것이 맘에 들었습니다. 그리고 약간은 시원 시원한 표현도 맘에 들었습니다.

일본의 발표자들이 공통적으로 했던 이야기가 있습니다. 그것은 바로 Progressive enhancement(점진적 향상)입니다. 사실 요즘 우리나라에서는 HTML5와 웹 접근성이 주요 키워드로 자리 잡고 있는데 이번 컨퍼런스에 웹 접근성에 관한 세션이 따로 없어서 0.5초 정도 고개를 갸우뚱했었습니다만, 발표를 들으면서 느낀것은 ‘일본에서는 웹 접근성이 기본적이고 당연한 것은 아닐까’ 하는 생각이었습니다. CSS3, HTML5 에서도 모두 Progressive enhancement 언급을 하면서 설명을 했으니까요… 사실 발표자들의 의도는 웹 접근성을 고려한 것이 아닐지도 모르지만 기본적인 이야기인 HTML 마크업으로 진행한뒤 CSS3와 각종 HTML5 api를 이용해서 사용자의 사용성을 극대화한다는 이야기는 웹 접근성에서의 Progressive enhancement 의 개념과 정확히 일치한다고 생각합니다.

“웹 접근성에 대해 한마디 하지 않아도 웹 사이트는 당연히 웹 접근성을 고려해서 만들어야 한다.” 라고 요즘 많이 생각하게 되는데 이번 컨퍼런스를 통해 그 점을 더욱 명확하게 정리한 느낌 입니다. 여러분들은 자신이 하는 웹 접근성 관련 작업이 누구를 위해서 하는것 입니까? 품질마크를 받아야하는 담당자일까요? 아님 그 사이트를 사용하는 일반 사용자 일까요? 한번쯤은 고민해볼 문제라고 생각합니다.

다시한번 이런 훌륭한 컨퍼런스를 만들어주신 분들께 감사드립니다. 이제는 11월 3일 글로벌 웹기술 세미나 입니다.