HTML, CSS좀 해서 약간!!!의 시멘틱한 페이지 좀 만들 수 있고, 브라우저 몇개 맞추면서 웹 접근성 품질마크 한 두번 따보면 HTML, CSS는 대충 다했다고 할 수 있는거 였어?

예전에 내가 좋아했던 카트라이더라는 게임이 있었는데(지금도 좋아해) 그때 통했던 캐쥬얼게임의 정석같은 개념은 “처음에 시작은 쉽게, 하면 할수록 어렵게, 마스터는 정말 어렵게” 였는데 난 HTML, CSS 가 그렇다고 생각해…

한국에 웹 표준 좀 한다고 알려져 있는 사람들 중에 자기는 HTML, CSS 어느정도 했다고 하는 사람 있는지 찾아봐. 그들은 겸손한게 아니라 정말 그 어려움을 알기 때문이라고 생각해(뭐 아닌 사람도 있겠지만)

남들보다 좀더 안다고 생각해서 각종 커뮤니티 활동이나 각종 발표 하는사람들도 너무 겁만주는것도 문제지만 무조건 태그 몇개, CSS 속성만 알면 바로가능 이딴 스레기 같은 얘기 좀 하지 말고(진짜 이런사람은 없지?), 장기적인 관점으로 로드맵을 그려주는것을 목표로 해봐

그리고 HTML,CSS 다하고 javascript하는게 아니라 그냥 다같이 하는거다. 졸라 씨발 단계 생각하지 말고  HTML, CSS 공부하고 있으면 닥치고 좀 봐라. 좀 프로그래밍의 로직도 좀 생각해보고.

p.s1 눈팅하던 하코사는 진짜 탈퇴해야겠다(모르는 사람들이 짜증나는게 아니라, 잘난사람들이 짜증나) CDK도 사람늘어나면 저리 되려나

p.s2 이빨까는 웹표준을 성민님 현석님과 podcast 방식으로 기획했었는데.. 요즘 나꼼수는 재미있더라 근데 우린 찬양할사람이 별로없어서 말이지;;;; 그리고 닥치고 웹표준을 좀 외쳤더니 존경하는 김어준 총수는 닥치고 정치 라는 책을 내었구나. 역시 싱행력이 있어야한다.(까는거 아님 멋진 실행력이 절대 부러운거임 =_=)

p.s3 요즘 맘의 짐을 한 두개 정도 버려 버리고 대충 살기로해서 블로그에서 정제된 언어보다는 내가하고 싶은 말이나 표현을 그냥 여과없이 해보려고

그렇게 열심히 스터디에서 공부를 하는데 저는 책 중심의 스터디가 맞지 않는것이었습니다.

보통 스터디는 책을 선정해서 정해진 부분을 정해진 사람이 발표를 준비해서 사람들에게 발표하는 방식이었습니다. 제가 느끼기에는 한사람이 준비를 해와서 그것에 대해서 설명하는것보다는 모두가 공부를 해오고 내용에 대한 설명은 대충 생략하고 토론을 원했거든요. 사실 책을 보는것은 혼자서도 할 수 있으니까요. 책을 보고 의견을 나누는 것이 제가 원했던 것이었는데 그렇질 못했습니다.

또한 자율적으로 스터디를 하다보니 준비도 미흡하고 결석자도 많고 그렇더라구요. 당연히 흐름은 끊기게 되고, 약간은 산만한 느낌이 들었습니다.

주말에 내가 큰시간을 할애해서 공부를 모여서 하는것인데 산만해 지는것은 싫었습니다. 그래서 강력한 규칙을 정하는 스터디를 만들어서 다같이 공부해보자는 마음을 먹게 되었습니다.

그래서 CDK에서 스터디를 모집 하게 되었습니다. 책만 보는것이 아닌, 웹 표준의 깊숙한 부분, 사상(이라고 하기엔 거창하지만), 무엇보다 공부를 하는 자세를 연구하는 스터디를 모집하고 싶었습니다. 그렇게 저를 제외한 8명의 사람들이 모였습니다. 그래도 책을 한권 정해서 같이 공부하는것이 수월했기 때문에 책을 한권 정해서 공부하기로 했습니다. 그 책이 바로 제프리 젤드만의 웹 표준 가이드였습니다. 이 책은 웹 표준이 생길 당시의 이슈들을 주로 얘기하는책이었던 만큼 웹 표준을 심도있게 공부하기에는 딱이었습니다.

물론 발표도 했었습니다.  그러나 누가 준비해 오는것이 아닌 다같이 발표 준비를 해오고 그중에 즉석에서 발표를 정하는 방식이었습니다. 당연히 준비를 안해오는사람은 거의 없었고(없진않았습니다.-_-+) 책은 그렇게 진행을 했습니다.

그리고 또한 자유 주제를 선정하거나 제가 할당해주어 그것에 대해 심도있게 공부하고 내용을 공유하는 방식으로 진행되었습니다. 그 결과물들은 CDK위키에 조금씩 정리 되었습니다:)

제가 목표로 했었던건 스터디를 통해서 그냥 단순히 페이지를 쳐내는 사람이 아니라 어떤 이슈가 생겼을때 ‘왜’ 라는 의문을 가지고, 근본적인 원인과 문제를 파악하여 처리하는것을 목표로 하는 사람을 만드는것이었습니다. 그렇게 1년을 진행했습니다.

스터디를 하는 사람들이 얼마나 발전했는지는 모르겠지만, 오히려 저는 나름 많은걸 배우고 느낄수 있었습니다. 이제 남은분들이 열심히 하셔서 좀 더 좋은 방향으로 스터디를 이끌었으면 좋겠습니다.  또 다른 스터디를 할것이냐는 아직 모르겠네요.

처음에는 다음과 같이 했습니다.

element.style.backgroundImage

이랬더니 값이 없다고 나오더군요. 그래서 좀 찾아보니… css같이 외부로 스타일을 지정해 준 경우에는 값을 읽어올 수 없다고 합니다.
그래서 이것도 몰랐냐 바보야 이러면서 computedstyle 이라는게 문득 생각나면서  좀 찾아봤더니 역시 우리의 IE는

element.currentStyle.backgroundImage

이렇게 써야한다고 하더라구요…

그래서 어쩔 수 없이 분기해서 함수처럼 만들어 쓰기로 했습니다. jQuery같은 훌륭한 라이브러리쓰는 사람들은 알 필요 없겠지만; 혹시나 해서 ^_^ 남겨봅니다.

그리고 언제나 그렇듯 제 코드는 무식 그자체 입니다. 보고 욕하지마세요. 조언은 환영합니다 ㅠ_ㅠ

function getStyle(obj ,sStyle) {
	var val;
	if (obj.currentStyle) {
		val = eval("obj.currentStyle."+sStyle);
	} else {
		val = eval("window.getComputedStyle(obj,null)."+sStyle);
	}
	return val;
}

miname 님의 조언으로 코드가 좋아졌습니다!!! 감사합니다!!! ㅎㅎ
무식하면 삼대가 고생해요 ㅠ_ㅠ 아래 코멘트는 miname님의 언급이십니다*_*

아시겠지만, 보안상으로보나 성능면에서 eval is evil이잖아요.^^
property 값을 얻을 때 bracket notation([])을 쓰면 eval 사용을 피할 수 있습니다.
아래처럼요.

function getStyle(el, sStyle) {
  var computedStyle;
  if (el.currentStyle) {
  computedStyle = el.currentStyle;
  } else {
  computedStyle = window.getComputedStyle(el, null);
  }
  return computedStyle[sStyle];
 }

만약에 위 function이 여러번 반복적으로 실행되는 상황이라면 아래처럼 바꿔서 두 번째부턴 더 빠르게 실행될 수 있도록 할 수 있을 겁니다.

function getStyle(el, sStyle) {
  if (el.currentStyle) {
   getStyle = function(el, sStyle) {
     var computedStyle;
     computedStyle = el.currentStyle;
     return computedStyle[sStyle];
   };
  } else {
   getStyle = function(el, sStyle) {
     var computedStyle;
     computedStyle = window.getComputedStyle(el, null);
     return computedStyle[sStyle];
   };
  }
  getStyle(el, sStyle);
 }

p.s 파젯을 KWCAG2.0 버전으로 조금 바꾸고 있습니다 ㅎㅎ 그중에 하나만들다가 이게 나온것이에요.
아시는분들만 안다는 파젯 사용방법을 아시는 분은 새로운 파젯 개발버전인 http://mydeute.com/was/pajet.js 으로 변경해서 확인 가능합니다 ㅋㅋㅋㅋ

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

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

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

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

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

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

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

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

이유를 물어보면 보통 나오는 얘기가.

“쓸 얘기가 별로 없어서” 라던가, “제가무슨…”, “좀더 준비해서요” 등의 얘기가 나오드라구요…

제 생각에는 블로그에 꼭 기술 이슈에 대한 얘기 남에게 도움이 될거 같은글만 올려야 한다고 생각하지는 않습니다. 예를 들어 저 같은 경우는 개인적인 관심사나 사는 이야기 등의 이야기도 올리고, 어쩌다 알게된 기술 상식도 올리고 그러고 있습니다. 블로그는 기본적으로 개인적인 일기나 느낌들을 올리거나.. 기술이라도 개인이 자유롭게 작성하면 되는건데  많은 분들이 뭔가 블로그는 아무나 하는게 아닌것처럼 인식되어서 참으로 안타깝더라구요…

저만해도 블로그 업데이트가 정말 뜸하기 떄문에 할말은 없지만, 그래도 블로그를 운영하면 얻는것이 정말 많다고 생각합니다.

블로그를 운영하면서 얻을 수 있는 잇점은 여러가지가 있지만 제가 생각하는 몇가지 잇점을 나열해보면…

1. 자신이 공부한것을 정리할 수 있다 입니다.우리는 많은것을 배웁니다. 커뮤니티에 질문을 하던, 검색을 하던, 아님 직접 손으로 짜면서 테스트를 하던, 각각의 공부 방법을 통해 우리는 얻는게 있습니다. 그것을 블로그에 정리해두면 나중에 찾아보기도 쉽고, 다른 사람도 쉽게 접근하여 더욱 발전할 수 있는 계기를 만들 수 있습니다. 물론 자신만의 노하우를 가지고 싶은 사람은 싫은 일이겠지만 다먹고 살자고 하는건데 공유하면서 살면 좋자나요
2. 내꺼니까 이것저것 해볼 수 있다.
   사실 업무로 웹 페이지를 만들때는  지산이 하고 싶은것을 충분히 할 수 없는 경우가 많습니다. 하지만 내 블로그는 내 소유이기 때문에 내 맘대로 지지고 볶고 난리를 쳐도 모라 그럴사람 없습니다. 그야말로 자신의 블로그는 내 코드를 맘껏가지고 놀 수 있는 놀이터인 셈입니다.
3. 설치형 블로그에 대한 경우 많은 다른기술을 익힐 기회가 있다.
   위의 이것저것과 일맥 상통하는 부분인데 맘만 먹으면 프로그래밍도 해볼 수 있고, 디자인도 해볼 수 있고 역시 내꺼니까 내맘대로 할 수 있고 또 애정을 가지고 해볼수있다는 생각이 듭니다. 사실 일할때는 다른 업무롤 접하기는 힘드니까요.. 이것도 큰 도움이 되지 않을까요?
4. 말그대로 내 자신에 대한 로그이다.
   저 같은 경우에 해당이 되는데 제 신변잡기를 써놨기 때문에 제가 언제 무엇에 관심이 있었고 뭘 하려했는지 알수가 있습니다. 저는 제 자신의 기록을 따로 많이 해두는 편이 아니라서 그런가…. 블로그가 이럴깨 도움이 많이 되더라구요 (특히 이력서 쓸때;;; )

써 놓고 보니 몇가지 안되기는하는데;;;;;;;; 그래도 위의 두 세가지 정도만 으로도 충분히 가치가 있다고 생각하지 않으시나요? 또한 써 놓고 보니 블로그 라기보다는 개인 홈페이지가 더 필요 할 것 같긴한데… 뭐 암튼 그놈이 그놈이고 ㅋㅋㅋ

블로그를 만들어서 조금의 시간 투자만으로도 좋은 블로그를 만들 수 있을것이고 그런 블로그들이 많이 모여야 한국의 웹 퍼블리싱 시장도 발전 할 수 있을거라는 생각이 듭니다. 요즘 좋은서비스도 많이 나왔고 툴도 많으니 잘골라서 바로 시작해 보세요.

웹 상의 좋은 문서는 모두 영어야 라고 불평만 하지 마시고, 일단 글을 써보세요 쉬운것부터 말이죠…  글이 많아져야 정보도 많이 생기고 경쟁력도 많이 생긴다고 봅니다 저는 ㅎㅎㅎ

하지만 무엇보다 저부터 좀 글좀 많이 써야할텐데 말이죠 ㅠ_ㅠ

“그런거 없습니다. 그냥 열심히 하세요.” 라고 하면 돌 맞을것 같고… 일단은 제가 웹 표준 기반 기술에 대한 것들을 아직 잘 하지 못하는 데다가 제가 공부했던 방식은 닥치고 하다보면 뭔가 생기겠지 라는 방식이었기 때문에 할 얘기도 별로 없습니다. 그러나 주변의 사람들이나 술자리에서 들었던 얘기들을 토대로 이야기를 풀어가 보려고 합니다.

웹 표준을 잘한다는 말은 어떤 의미에서 보면(적어도 한국에서는) HTML, CSS등의 front-end기반의 기술이 높은것을 말하기도 합니다. 또한 웹 접근성에 대한 지식도 높은것을 의미하기도 합니다. 그외 여러가지 알아야 할 것들이 많기 합니다만 천리길도 한걸음부터라고 하나하나 알아가다 보면, 잘하게 되겠죠…

웹 표준 관련 도서

시중에 웹 표준 관련 도서들이 많이 나와 있습니다. 2005년 실용예제로 배우는 웹 표준 (에이콘, 2005)이라는 책이 처음 번역이 되면서 웹 표준 책은 그동안 수도 없이 나왔습니다. 사실 저는 어떤 책을 특히 추천 한다기 보다는, 어떤 책이던지 한 권을 전부 읽는것을 먼저 목표로 잡아야한다고 생각합니다. 사실 책 한 권 보기가 그렇게 쉬운일이 아니죠… 어떤 책이 좋은지 추천을 권하신다면 현석님 블로그의 글을 읽어 보기를 권합니다.

제가 몇가지 권하는 책은

• 제프리 젤드만의 웹 표준 가이드 (웹 표준의 역사를 알 수 있는 책입니다. 출간된지 오래되어 이해하기 힘든면들이 있을 수 있지만 제게는 제일 좋았던 책입니다.)
• 웹 표준 교과서 (말그대로 교과서 같은책입니다. 가장 많이 알려지기도 했습니다.)
• Head first HTML & XHTML with CSS (HTML, CSS 처음배우는 사람에게 권장하는 책입니다. 이시리스 책의 특징은 재미있는구성으로 이해하기가 쉽다는것입니다.)

입니다. 사람마다 기호가 다르고 취향이 다르기 때문에 좋아하는 책도 다릅니다. 뭐 그냥 제 개인적인 생각이니 그냥 지면 낭비용이라고 보시면 될것같아요

RSS Feeding

사실 웹 표준 관련도서가 한국에 전무했을때는 웹 표준을 공부하는데 가장 큰 도움을 주었던 방식이라고 생각합니다. 웹 표준은 단순히 기술만 이해한다고 해서 되는것이 아니라고 생각하기 때문에 사람들의 다양한 생각을 보고 느끼고 자신의 생각을 정리하는데 RSS Feeding 만한 것도 없다고 봅니다. 저는 구글 리더에 각종 RSS주소들을 등록하고 읽고 있습니다. 50여개정도의 RSS를 등록해서 보고 있는데.. 정말 많은 도움이 되고 있습니다. 조만간 CDK 에서 유용한 RSS들을 모아서 공유할까 하는 생각도 있습니다.

Forum, community

우리나라에도 웹 표준 관련 커뮤니티나 포럼들이 많이 존재합니다. 그들과 의견을 공유하고 개개인의 사정을 공감하면 때로는 오프라인에서 만나서 대화도 나누면서 자기자신의 실력을 높이는 방법중 하나입니다. 우리나라에는 대표적인 사이트로 CDK, clearboth, 하드코딩을사랑하는사람들 등이 있습니다:) 그냥 맘에 드는 사이트에서 질문도 하고 의견도 나누고 답변도 하고 그러다보면 배우는것이 정말 많을거라 생각합니다.

Spec 문서 공부 및 영어 =_=;

제가 보기엔 스팩을 보는것이 가장 확실한 방법입니다. 보는데 어려움이 있고 영어로 구성되어있어 이해하기 쉽지는않지만 차근차근 보다 보면 생각보다 문서가 어렵지 않게 구성되어 있습니다. “모든것의 핵심에는 스팩이 있었다” 라고 말할정도로 스팩은 중요합니다. 포럼이나 게시판에서 나오는 질문들의 대부분은 (호환성 이슈를 제외하고) 스팩에 답이 있습니다. 다만 항상 문제가 되는것은 영어라지요. 저도 영어가 이세상에서 이명박 다음으로 싫은데… 사전 좀 찾고 구글 번역기 돌리면 대충 이해할 수 있더라구요. 그리고 영어문서는 보면 볼수록 이해의 폭이 넓어지더라구요. 저같은 까막눈도 이제는 어려워도 조금은 볼 수 있으니 가능할것같아요.

Search

검색만 잘하면 언제나 반은 먹고 들어갑니다. 이것도 하면 할수록 늘어요… 잘키운 검색 습관 열 책 안부럽습니다. ㅎㅎ

다들 열심히 공부해서 웹 표준의 고수가 되어봅시다 (저부터도 좀;;;;)

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 의 정보를 보고 이페이지의 인코딩, 저작자, 내용, 업데이트 된 날짜 등등을 알아내고 그에 맞게 반응을  합니다.

• http://www.w3schools.com/tags/tag_meta.asp
• http://www.w3.org/TR/html401/struct/global.html#h-7.4.4

에서 참고했습니다.

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

기분전환할려고 블로그 스킨을 바꾸기 시작했는데; 디자인을 못하니; 스트레스가 되려 쌓이는 느낌이 었어요 어쨌든 변경완료…

블로그랑 위키 적용했으니 이제 남은 서비스도 해야지요.

이제 미디어 쿼리를 적용해 봐야 겠어요 >_<

간만의 또 뻘글

개요

HTML4.01 과 CSS2 에서 이미 media type에 대응하는 스타일 시트를 따로 구성할 수 있는 방식을 지원하고 있었지만, 미디어에 대한 특징이나 범위를 명확하게 지정할 수 없었기 때문에, screen, print, handheld 정도만 사용 되었던것이 사실이었습니다. 그래서 CSS3에서는 좀 더 미디어의 특징을 잘 표현할 수 있는 방법을 확장하고 세분화한 스팩을 제공하게 되었습니다. 그것이 CSS3 Media Queries Module 이 되겠습니다. 앞서 언급했지만 HTML4, CSS2에서도 media type에 따른 css를 분기하는 방법은 지원하고 있었습니다. 그예를 보면 HTML4.01 에서는 스타일 시트 정의 시에 media를 선택 할 수 있습니다.

<STYLE type="text/css" media="projection">
    H1 { color: blue}
</STYLE>
<link rel="stylesheet" type="text/css" media="screen" href="sans-serif.css">
<link rel="stylesheet" type="text/css" media="print" href="serif.css">

참고 URL 은 다음과 같습니다.

• http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2.4
• http://www.w3.org/TR/REC-html40/types.html#type-media-descriptors

CSS2에서 정의된 media type 정의방법은 다음과 같습니다.

@media screen {
    * { font-family: sans-serif }
}

참고 URL은 다음과 같습니다.

• http://www.w3.org/TR/CSS21/media.html

위의 방법은 출력될 media의 type만 결정 할 수 있기 때문에 같은 미디어의 다양한 환경을 모두 수용하기에는 어려움이 많습니다. 하지만 CSS Media queries Module을 이용하면 디바이스의 종류뿐만 아니라 다양한 조건을 이용하여 Style을 분기할 수 있게 됩니다.

문법 및 사용법

미디어 쿼리의 문법 및 사용법은 다음과 같습니다.

media_query_list: <media_query> [, <media_query> ]*
media_query: [[only | not]? <media_type> [ and <expression> ]*]
| <expression> [ and <expression> ]*
expression: ( <media_feature> [: <value>]? )
media_type: all | aural | braille | handheld | print |
projection | screen | tty | tv | embossed
media_feature: width(가로 너비) | min-width(최소 가로 너비) | max-width(최대 가로 너비)
| height(높이) | min-height(최소 세로 높이) | max-height(최대 세로 높이)
| device-width(디바이스의 기본 가로 너비)
| min-device-width(디바이스의 기본 최소 가로 너비) | max-device-width(디바이스의 기본 최대 가로 너비)
| device-height(디바이스의 세로 높이) | min-device-height | max-device-height
| aspect-ratio(화면 비율) | min-aspect-ratio(최소 화면 비율) | max-aspect-ratio(최대 화면 비율)
| device-aspect-ratio(디바이스의 화면 비율)
| min-device-aspect-ratio(디바이스의 최소 화면 비율) | max-device-aspect-ratio(디바이스의 최대 화면 비율)
| color(색상당 비트수) | min-color(최소 색상당 비트수) | max-color(최대 색상당 비트수)
| color-index(user agent가 지원하는 팔레트의 색상 갯수)
| min-color-index(user agent가 지원하는 팔레트의 색상의 최소 갯수) | max-color-index(user agent가 지원하는 팔레트의 색상의 최대 갯수)
| monochrome(흑백 장치에서 픽셀 당 비트의 개수)
| min-monochrome(흑백 장치에서 픽셀 당 비트의 최소 개수) | max-monochrome(흑백 장치에서 픽셀 당 비트의 최대 개수)
| resolution(해상도) | min-resolution(최소 해상도) | max-resolution(최대 해상도)
| scan | grid

무슨소리인지 저도 잘모르겠습니다. ㅎㅎ 미디어 쿼리는 대소문자를 구별하지 않으며 알수없는 미디어의 경우에는 false 를 리턴한다고 합니다.

Media Type

CSS3 Media Queries Module 에서 정의하는 Media의 종류는 다음과 같습니다.

• all : 모든 미디어 타입
• aural : 음성 합성 장치
• braille : 점자 표시 장치
• handheld : 손으로 들고 다니면서 볼 수 있는 작은 스크린에 대응하는 용도
• print : 인쇄 용도
• projection : 프로젝터 표현 용도
• screen : 컴퓨터 스크린을 위한용도
• tty : 디스플레이 능력이 한정된, 텔렉스(teletype), 터미날, 또는 수동 이동 장치 등, 고정 피치(fixed-pitch:폭이 일정) 글자를 사용하는 메디아를 위한 의도 “tty” 메디아 타입에서 제작자는 픽셀(pixel) 단위를 사용하여서는 안됨
• tv : 음성과 영상이 동시 출력되는 TV와 같은 장치
• embossed : 페이지에 인쇄된 점자 표지 장치

뭔가 겁네 많은것 같아요. 일단 대충 이정도로 알아보고 실제 사용해보면서 알아보는거로 하는게 좋겠어요.

사용예

외부 파일을 사용하는법

<link rel="stylesheet" media="screen and (min-device-width: 200px)" href="example2.css" />
<link rel="stylesheet" media="screen and (min-device-width: 800px)" href="example1.css" />  

예제) 아이폰과 웹브라우저에서 비교 http://mydeute.com/media_queries/1.html
디바이스의 가로값이 최소 200px이상이면 example2.css를 로드, 디바이스의 가로값이 최소 800px이상이면 example1.css도 같이 로드함

<style> 태그를 이용하는법.

<style type="text/css" media="screen and (min-device-width: 200px)">
body { background-color: #0F0; }
</style>
 <style type="text/css" media="screen and (min-device-width: 800px)">
body { background-color: #F00; }
</style>

예제) 아이폰과 웹브라우저에서 비교 http://mydeute.com/media_queries/2.html

CSS 파일내에서 사용하는 방법

<style type="text/css">
@media screen and (min-device-width: 200px) {
body { background-color: #0F0; }
}
@media screen and (min-device-width: 800px) {
body { background-color: #F00; }
}
</style>

예제) 아이폰과 웹 브라우저에서 비교 http://mydeute.com/media_queries/3.html

only, not

media type 을 선별하는 과정중에 선택할 수 있는 접두어

only

@media only handheld {
body { background-color: #F00; }
}

not

@media not screen {
body { background-color: #F00; }
}

features

width

user-agent의 현재 width 값에 대응해서 반응

@media screen and (width: 980px) {
body { background-color: #F00; }
}

예제) 아이폰과 브라우저에서 비교 http://mydeute.com/media_queries/4.html user-agent의 가로너비가 980px일때 배경이 빨간색으로 표현

min-width

최소 가로 너비를 지정하고 지정된 값보다 너비가 길면 그값에 대해 반응

@media screen and (min-width: 981px) {
body { background-color: #F00; }
}

예제) 아이폰과 브라우저에서 비교 http://mydeute.com/media_queries/5.html user-agent의 가로너비가 981px 이상 일때 배경이 빨간색으로 표현

max-width

최대 가로 너비를 지정하고 지정된 값보다 너비가 좁은 경우에만 그 값에 대해 반응

@media screen and (max-width: 980px) {
body { background-color: #F00; }
}

예제) 아이폰과 브라우저에서 비교 http://mydeute.com/media_queries/6.html user-agent의 가로너비가 980px 이하 일때 배경이 빨간색으로 표현

응용 1

조합이 가능해짐 0~ 320px 까지는 배경이 파란색 321px~ 800px 까지는 배경색이 빨간색 801px이상의 너비에서는 녹색 배경을 만들고 싶다면

@media screen and (max-width: 320px) {
body { background-color: #00F; }
}
@media screen and (min-width: 321px) and (max-width: 800px) {
body { background-color: #F00; }
}
@media screen and (min-width: 801px) {
body { background-color: #0F0; }
}

예제 브라우저의 가로 너비를 조절해보면서 보면 됨 http://mydeute.com/media_queries/7.html

응용 2

브라우저 화면의 가로 너비에 따라 레이아웃을 변경할수도 있음

@media screen and (max-width: 320px) {
#wrap { width:320px }
#left {  border:2px solid #F00; width: 316px }
#contents{ border:2px solid #0F0; width: 316px }
#right { border:2px solid #00F; width: 316px }
}
@media screen and (min-width: 321px) and (max-width: 800px) {
#wrap { width:800px }
#left {  float: left; border:2px solid #F00; width: 196px }
#contents{ float: left;border:2px solid #0F0; width: 596px }
#right { clear:both;border:2px solid #00F; width: 796px }
}
@media screen and (min-width: 801px) {
#wrap { width:100% }
#left {  float: left; border:2px solid #F00; width: 23% }
#contents{ float: left;border:2px solid #0F0; width: 50% }
#right { float: left;border:2px solid #00F; width: 23% }
}

예제) http://mydeute.com/media_queries/8.html

아주 기본적인 미디어 쿼리의 사용법에 대해 알아보았습니다.
이 다음에는  제가 현재 제블로그 스킨을 좀 바꿔보려고 하고 있으므로 실제 적용기를 다뤄볼까 합니다.

그럼 그동안 즐거웠어요

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

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

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

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