수라의 티스토리

[HTML]
<img src="images/gnb_menu01.gif" onmouseover="show_layer('showmenu1')" onmouseout="sub_out()" class="gnb_img" alt="품질지수관리" />
                <div id="showmenu1" style="visibility:hidden;" onmouseout="sub_out()" onmouseover="sub_over()">
                    <iframe id="back_smenu01" frameborder="0"></iframe>
                    <div class="smenu01">
                        <ul class="gnb_depth01">
                            <li><a href="#" onmouseover="txt_over()" onmouseout="txt_out()">품질지수조회</a></li>
                            <li><a href="#" onmouseover="txt_over()" onmouseout="txt_out()">목표수준거래승인완료율</a></li>
                        </ul>
                    </div>
                </div>

[스크립트]
//메뉴 갯수
 var lay_length = 3;
 var inter_id = "";
 
 function hide_set(){
  //서브레이어 다 안보이게
  for(var i=1; i<=lay_length; i++){
   var txt = "showmenu"+i;
   document.getElementById(txt).style.visibility="hidden";
  }
 }
 
 function show_layer(id){
  //서브레이어 다 감추고 다시 내꺼만 보이게
clearInterval(inter_id);
  hide_set();
  document.getElementById(id).style.visibility="visible";
 }
 
 //서브배경과 메뉴를 벗어날경우 시간차로 서브감추기
 function sub_out(){
clearInterval(inter_id);
  inter_id = setInterval("check();",1000);
 }
 function sub_over(){
  clearInterval(inter_id);
 }
 function txt_out(){
clearInterval(inter_id);
  inter_id = setInterval("check();",1000);
 }
 function txt_over(){
  clearInterval(inter_id);
 }
 function check(){
  hide_set();
  clearInterval(inter_id);
 }
//메뉴 갯수
 var lay_length = 3;
 var inter_id = "";
 
 function hide_set(){
  //서브레이어 다 안보이게
  for(var i=1; i<=lay_length; i++){
   var txt = "showmenu"+i;
   document.getElementById(txt).style.visibility="hidden";
  }
 }
 
 function show_layer(id){
  //서브레이어 다 감추고 다시 내꺼만 보이게
clearInterval(inter_id);
  hide_set();
  document.getElementById(id).style.visibility="visible";
 }
 
 //서브배경과 메뉴를 벗어날경우 시간차로 서브감추기
 function sub_out(){
clearInterval(inter_id);
  inter_id = setInterval("check();",1000);
 }
 function sub_over(){
  clearInterval(inter_id);
 }
 function txt_out(){
clearInterval(inter_id);
  inter_id = setInterval("check();",1000);
 }
 function txt_over(){
  clearInterval(inter_id);
 }
 function check(){
  hide_set();
  clearInterval(inter_id);
 }

플래시 태그 삽입시 wmode를 안넣으면 위로 올라가는 레이어가 다 숨는 현상이 발생.

object 태그에는
<param name="wmode" value="transparent">

 

embed 태그에는
<embed wmode="transparent" ...

참고글 : http://blog.naver.com/hwi95?Redirect=Log&logNo=110052212041

**내용 입력시**

<textarea cols=40 rows=5 onfocus="this.value=''">내용을 입력하세요</textarea>
<input type="text" name="textfield" onfocus="this.value=''" value="주소를 입력하세요.">

<textarea cols=40 rows=5 onc　lick="if(this.value=='내용을 적어주세요.^^'){this.value=''}">내용을 적어주세요.^^</textarea> 

 

**이미지 넣을시**

<input type="text" style="background:url(이미지경로) no-repeat 0 50%;" onfocus="this.style.background='none';" />

 

 

**색상 넣을시**

<input type="text" style="background:#ff6600 " onfocus="this.style.background='none';" />

이 포스트를 보낸곳 ()

웹 표준에 관심이 있다면 웹 접근성이나 크로스 브라우징에도 관심이 있을 것입니다. 웹 접근성은 웹 표준의 상위목적이며 크로스 브라우징은 웹 접근성 가운데 Vendor 호환성을 충족하는 기술입니다. 간혹 ‘웹 표준 지키면 크로스 브라우징은 저절로 얻을 수 있는것 아니었어?’ 라고 생각하는 분들도 계신데 이자리에서 오해를 푸셨으면 합니다. 웹 표준은 W3C 권장지침만 지키면 되는 것이지만 크로스 브라우징은 브라우저 제품별 특성(버그)을 모두 극복해서 동일하게 보이거나 또는 기능하도록 해야 하기 때문에 훨씬 어렵고 예측불가능한 문제와 자주 만나게 됩니다. 웹 표준 방식의 코딩은 시간이 너무 많이 걸린다는 오해도 여기에서 비롯됩니다. 정확히 말하면 웹 표준 때문에 시간이 많이 걸리는 것이 아니라 브라우저 제품의 버그를 극복하는 과정(크로스 브라우징)이 개발자들의 시간을 좀먹고 있는 상황입니다. 만약 모든 브라우저의 렌더링 방식에 버그가 없다고 가정하면 ‘웹 표준 vs 비 표준’ 개발자가 동일 사이트를 개발한다고 했을 때 ‘백이면 백’ 웹 표준 개발자의 코딩이 훨씬 빠를 것입니다. 도박은 별로 좋아하지 않지만 제게 내기를 걸어오셔도 좋습니다. 버그 투성인 IE 브라우저(암적인 존재)만 세상에서 사라져 준다면 이런 문제는 말끔하게 해결될 것 같은데 말이죠. IE, 생각할 수록 열받네요. 아래 설명중 제가 IE 라고만 표기하는 것은 IE6~7 을 모두 포함합니다. (IE:Internet Explorer, FF:Firefox, OP:Opera, SF:Safari)

바른 DTD(Document Type Definition)를 사용할것.

앞서 버그 투성이라고 소개했던 IE 조차도 DTD 만 제대로 적어주면 제법 표준에 따르는 렌더링방식을 취하게 됩니다. DTD 를 적지 않으면 브라우저들은 Quirk Mode 상태(어물쩡한 상태)로 렌더링 하기 때문에 바른 DTD를 적어주는 것은 크로스 브라우징의 첫 번째 원칙 입니다. DTD 조차 정의하지 않은 상태로 크로스 브라우징 한다는 것은 애시당초 불가능 합니다. 현재 활성 버전의 HTML 은 XHTML 1.0 이므로 XHTML 1.0 DTD 를 소개 합니다. 프레임셋 DTD와 호환모드 및 표준모드가 있는데 저는 호환모드를 권장 합니다. 프레임셋 DTD는 프레임이 있는 문서의 프레임셋에 정의하는데 프레임은 강력하게 비추천 하므로 권장하지 않으며 표준모드는 강력하게 추천하지만 너무 엄격해서 이를 적용하기 어렵기 때문에 소개하지 않겠습니다. 아래는 하위버전 호환성을 고려하면서 약간은 느슨한 상태의 호환모드 DTD 입니다. 제 블로그의 DTD도 이것이고 제가 최근에 개발하는 웹사이트의 DTD도 모두 이것입니다.

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

공통선택자 ‘*’ 를 활용할것.

브라우저 제품에 따라서 특정 element 에 대한 margin, padding, line-hight, letter-spacing, font-size 등등… 많은 것들에 대한 차이가 존재 합니다. 특히 가장 빈번하게 발생하는 문제는 의도하지 않았던 여백에 대한 문제 입니다. 다행히도 공통선택자 ‘*’ 는 이런 문제를 간단하게 해결해 줄 수 있습니다. ‘실전 웹 표준 가이드‘ 또는 ‘CSS 마스터 전략‘ 이라는 책을 읽어보신 분들이라면 제 설명이 굳이 필요 없을것 같습니다.

* {margin:0; padding:0;}
or
* { margin:0; padding:0; font-size:small; font-family:돋움, Dotum, AppleGothic, sans-serif;}

위 예제 가운데 첫 번째는 앞서 소개해드린 서적에서 보통 설명하고 있는 방식의 예제이고 두 번째는 그것을 응용하여 실무에서 활용하고 있는 방식입니다. 제가 사용하는 공통선택자에 font 속성을 적용한 것과 font 속성에 대표속성(단축속성)을 사용하지 않는 이유가 궁금하실껍니다. 공통선택자에 font 를 정의하는 이유는 body 태그에 적용한 font 속성은 form 내부의 element 와 th, td 태그에까지 이를 상속하지 않는데 반하여 공통선택자에 이것을 적용하면 모든 element 에 대한 font 를 완벽하게 통일할 수 있기 때문입니다. 또한 font 에 대표속성(예: {font:small 돋움, Dotum, AppleGothic, sans-serif})을 사용하지 않는 이유는 이를 사용하는 경우 h1~h6, th, strong 태그가 기본적으로 지니고 있는 font-weight 까지 모두 초기화(normal) 되기 때문입니다. font의 대표속성을 사용할 때 font-weight 따위를 정의하지 않으면 font-wight:normal 상태로 렌더링 됩니다. 딱, 저 정도만 정의해 놓으면 일단 모든 브라우저에서 나타나는 margin, padding 관련 렌더링의 차이는 간단하게 해결 되고 사이트의 기본서체 문제까지 해결됩니다. 이것은 브라우저 제품마다 다른 element 의 렌더링 차이를 CSS로 극복하는 크로스 브라우징의 기초 입니다.

의도하지 않았던 여백이 발생하는 경우 inline 을 의심하거나 또는 그 면적을 float 으로 없애줄것.

의도하지 않았던 여백이 발생하는 경우는 보통 inline 형태의 element 문제 또는 IE 의 버그 때문 입니다. inline 형태의 element 는 항상 line-height 를 지니고 있습니다. 따라서 의도하지 않았던 여백이 발생하는 경우 일단 inline element 의 line-height 문제가 아닌지 먼저 확인해 보아야 합니다. line-height 도 화면에서 분명히 면적을 차지하고 있습니다. 안타깝게도 line-height 속성을 CSS 에서 따로 정의하지 않았다면 웹 브라우저 제품마다 line-heght 를 다르게 렌더링 할 것입니다. 이 때문에 어떤 브라우저에서는 의도한 대로 나타나지만 어떤 브라우저에서는 박스와 박스 사이에 여백이 생길 수도 있는 것입니다. 또 다른 문제는 잘 알려진 IE 버그로서 block 된 li 에 발생하는 알 수 없는 여백의 문제 입니다. 이럴 때에는 해당 li 가 화면에서 차지하는 면적을 제거하기 위하여 li {float:left; clear:both} 를 적용하고 float 된 li 의 면적이 부모 element 에게는 유효하게 전달되도록 ul {overflow-hidden} 을 적용해 보시기 바랍니다. 단, 이 팁이 모든 경우에 적당한 것은 아닐껍니다. 특히 세로 네비게이션 코딩시 문제가 발생하면 적용해 보시고 다른 경우에도 적절하게 응용해 보시기 바랍니다. 설명을 듣고도 잘 해결이 되지 않으면 제게 문의해 주세요. 친절 A/S 해드리겠습니다.

면적을 차지하는 것과 그렇지 않은 element 이해하기.

화면 레이아웃을 결정할 때 position 속성을 사용하거나 또는 float 을 사용하라고 배웠을 것입니다. {position:absolute} 상태일 때에는 화면에서 면적을 차지하지 않는다는 것을 잘 알고 계실껍니다. 그리고 {position:absolute} 상태일 때에는 그다지 렌더링 관련 버그를 만나는 경우가 없을 것입니다. 하지만 float 의 경우 IE 에서는 버그가 있으므로 FF, OP 브라우저와의 차이가 발견되면 일단 IE 를 믿지 마시기 바랍니다. 이것에 대한 문제해결은 float 이 화면에서 면적을 차지하지 않는다는 사실과 IE 에서는 이와 관련된 버그가 있다는 사실을 인지하는 것으로부터 시작됩니다. 자주 발견되는 IE 의 렌더링 오류는 float 된 요소와 float 되지 않은 요소가 만나는 방법입니다. float 은 원래 주변의 inline 요소만 흐르도록 하는것이 맞지만 IE 는 block 된 이웃 요소도 float 의 영향을 받습니다. 아래 예제를 FF, OP, SF, IE 에서 각각 렌더링 해보시면 제 설명의 이해를 돕습니다.

<!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”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
<title>IE의 float 관련 버그 확인</title>
<style type=”text/css”>
#a { float:left; width:100px; height:100px; background:#00F}
#b { width:100px; height:100px; background:#F00}
</style>
</head>
<body>
<div id=”a”></div>
<div id=”b”></div>
</html>

코드를 실행해 보셨으리라 믿고 설명을 계속 이어가겠습니다. FF, OP, SF 에서 b 상자는 보이지 않습니다. 왜냐하면 a 상자가 화면에서 면적을 차지하지 않고 붕 떠있으면서 b 상자를 가리고 있기 때문입니다. 하지만 IE 의 경우 b 상자는 float 의 영향을 받아서 a 상자의 오른쪽에 흐르고 있습니다. FF, OP, SF 의 렌더링이 맞고 IE 가 잘못된 렌더링을 출력하고 있으므로 당황하지 마시기 바랍니다. 한편 IE 처럼 렌더링 시키려면 b 상자에도 float 속성을 넣어주면 됩니다. float 된 element 는 float 되지 않은이웃 element 와 서로 간섭하지 않지만 float 된 이웃 element 끼리는 서로의 면적을 인식하게 되기 때문입니다. 추가적으로 IE 6.x는 float된 요소에 적용된 margin을 두 배로 출력하는 버그가 있습니다. 따라서 float을 사용할때 margin을 함께 사용하지 않는것도 중요한 팁 입니다.

Firefox 를 사용하고 IE Tab, Opera view 부가기능을 활용할 것.

일단 크로스 브라우징을 목표로 하고 있다면 IE 브라우저를 기본 브라우저로 사용하지 마십시오. IE 는 CSS 를 렌더링 함에 있어서 수많은 버그를 포함하고 있기 때문에 기준으로 삼을만한 브라우저가 못됩니다. FF 를 기본 브라우저로 채용하고 FF 의 확장기능(IE Tab, Opera View)을 이용하여 IE, OP 브라우저의 렌더링 결과를 확인하십시오. 사실 CSS 를 가장 정확하게 렌더링 해주는 브라우저는 Opera 와 Safari 입니다. Safari 는 Mac OS X 전용 브라우저이므로 Windows 에는 설치할 수 없습니다. 하지만 두 개의 브라우저 모두 Acid2 Test 를 통과한 브라우저 이므로 렌더링 결과는 Opera 와 Safari 가 크게 다르지 않습니다. 단, Safari 를 제대로 지원하려면 Mac 전용 서체 (ex: AppleGothic, AppleMyeongjo)를 보조서체로 사용하여야 합니다. Safari 브라우저의 Simulator Test 는 가능합니다. 현재 FF 2.x 버전도 Acid2 Test 를 통과하지는 못했으며 CSS와 관련된 약간의 버그를 포함하고 있습니다. 그러나 표준 준수율이 매우 높기 때문에 기본 브라우저로 채용하더라도 크게 문제는 되지 않을 것입니다. 또한 FF 의 확장기능으로 하여금 타 브라우저의 렌더링 결과를 쉽게 관측할 수 있기 때문에 이것을 사용하라고 권장하는 것입니다. FF 를 기본 브라우저로 사용하고 IE Tab 을 이용하면 IE 를 실행하지 않고도 FF 에서 IE 의 렌더링 엔진을 사용할 수 있습니다.(상태표시줄의 FF 로고를 클릭하면 렌더링 엔진을 IE 으로 전환해줌) 단, Opera view 는 Context Menu(마우스 우측 버튼>이 페이지를 Opera 로 보기)를 이용하여 OP 브라우저를 직접 실행하게 되어 있습니다.

이 포스트를 보낸곳 ()

UI(User Interface)개발자 = 사용자환경을 최적화 하는 개발자

웹 애플리케이션 개발은 크게 UI 개발자 이전과 이후로 나눌 수 있다. 그는 디자이너가 구성한 화면을 HTML, Javascript, CSS 레이아웃을 사용해 가공한 다음 개발자가 코드와 매핑시킬 수 있도록 도와준다. 팀 내 디자이너와 개발자 사이에서 오작교 같은 역할인 셈이다. UI 개발자로 인해 디자이너는 기획한 데로 디자인에 집중할 수 있고, 개발자 역시 디자인에 입각한 시스템 퍼포먼스를 향상시킬 수 있게 됐다.

과거와 달리 웹사이트를 평가하는 기준이 바뀌고 있다. 웹에서 보여주는 콘텐츠도 텍스트, 이미지 위주에서 동영상, 게임, 지도 등으로 확대됐다. 홈쇼핑, 영화 예매, 지도(경로) 검색 등 기존에 없었던 새로운 인터페이스가 부각되면서 UI의 수준도 클라이언트 애플리케이션과 대등한 수준으로 발전하고 있다. 그저 페이지 로딩이 빠른 텍스트 기반이면 만족하던 시절은 먼 옛날이야기다.

UI 개발자의 길을 걷게 된 건 우연한 기회였다. 대학시절 웹 에이전시에서 일하던 친척 누나의 권유로 시작한 아르바이트가 계기였다. 처음 한 일은 틈틈이 익혔던 그래픽 툴을 사용한 디자인 작업이다. 컴퓨터공학을 전공한 탓에 HTML이나 여타 스크립트 언어에도 익숙했던 그는 디자이너와 개발자가 보지 못하는 빈 구석을 빨리 잡아낼 수 있었다.

“디자이너는 오로지 디자인! 이에 질세라 개발자들은 무조건 안 된다는 말만 했죠” 개발 초년생이 바라본 현장의 모습이었다. 그는 디자이너와 개발자 집단 사이를 넘나들고 있다. 우선 UI 기획 단계부터 참여한다. 디자이너들의 모티브를 십분 이해한 뒤 구현작업에 참여해 개발자 함께 디자인과 코드를 조율한다. 이렇다 보니 배울 것도 두배다. 개발 툴 없이 HTML, CSS, JavaScript의 소스만 보고 구조를 파악할 수 있음은 물론이고, 포토샵, 일러스트레이터 같은 그래픽 도구 몇 개쯤은 쉬이 다룰 수 있어야 한다. 게다가 웹 표준에 대한 이해는 기본이라고.

웹 표준 지킴이
대부분 웹 애플리케이션이 보안 등의 문제로 통상 익스플로러 기반으로 작업한다. 모든 사람이 익스플로러만 사용한다면 애써 문제 삼을 필요가 없다. 웹 표준이 필요한 이유를 들어봤다. “어떤 브라우저에서도 페이지를 볼 수 있어야 합니다. 심지어 기기 환경에 상관없이 같은 페이지를 볼 수 있어야 하죠” 점점 늘어가는 파이어 폭스 사용자 수만 보더라도 웹 표준을 지키는 것이 얼마나 시급한 일인지 알 수 있다. 기존 웹의 경우 테이블 구조로 만들다 보니 페이지 로딩과 용량이 문제가 됐다. 웹 표준에 맞춰 태그를 활용하면 이러한 문제들을 해결 할 수 있다.

하지만 빠듯한 개발 일정을 생각하며 웹 표준을 지키기란 여간 쉬운 일이 아니다. “당장은 기업의 업무용 프로그램 중심으로 웹 클라이언트 인터페이스가 부각되고 있지만, B2C 환경에서도 인터페이스 강화가 화두가 될 것”이라며 무엇보다 웹 표준이 왜 필요한지 설득하는 것이 관건이란다. “국내는 이제 커뮤니티가 생겨나고 몇 군데서 세미나가 열리는 상황”이여서 관심 있는 그룹끼리 레퍼런스를 만드는 노력이 필요하다고 한다.

몇 몇 유명 블로그를 언급하며, 웹 애플리케이션을 만드는 이들에게 조언을 아끼지 않았다. 특히 앤디버드가 쓴 ‘CSS Mastery’는 그가 늘 끼고 다니는 책이다. UI 개발자의 길을 희망하는 사람이라면 무조건 읽어보란다. 이와 함께 박수만 씨가 번역한 웹 표준과 방탄 웹을 꼽았다. 그를 포함한 UI 개발자들에게 바이블 같은 책이다.

UI 개발자의 미래
여 전히 새로운 직군으로 인식될 만큼 UI 개발자의 수는 그리 많지 않다. 적은 인원으로 개발을 진행하는 중소기업에서는 생각조차 할 수 없는 자리다. 여전히 개발자냐? 디자이너냐는 질문을 늘 접하니 풀어야할 문제가 한 두 가지가 아니다. 그 나름대로 UI 개발자를 구분해 봤단다. 시스템 지향 UI 개발자와 디자인 지향 UI 개발자다. 자신은 ‘시스템 지향’에 속한다며, Ajax나 플렉스 같은 기술을 사용해 웹 클라이언트 인터페이스 개발을 하게 된다.

디자인 지향적인 UI 개발자는 UX(User eXperience: 사용자 경험) 측면에서 콘텐츠의 접근성을 높이는 노력을 해볼만 하다고 한다. 있는 그대로를 보여주는 웹은 끝났다. 실시간으로 데이터를 요구한다. 사용자의 취향을 반영해 레이아웃을 변경하고 손쉽게 제어할 수 있는 UI들을 포함하기 시작했다. 이런 추세라면 UI 개발자의 영역이 기존 클라이언트 개발자 영역까지 대체 할 가능성도 보인다. 시장은 편의성을 높이는 기술에 손을 들어주기 마련이다.

보안 등의 이슈로 널리 사용되던 ActiveX가 점차 밀려나면서 Ajax나 플렉스 기술이 더욱 관심을 받고 있다. 끊임없이 진화중인 웹 애플리케이션 분야에서 그가 만들어갈 세상을 위해 가슴 한 컨을 비워두려 한다.

- publy 블로그에서 발췌

웹퍼블리셔(Web Publisher)

웹 퍼블리셔(web Publisher)?! 그게 뭐지?
퍼 블리셔는 웹 관련 종사자들은 누구나 알고 있는 코더(Coder)를 높이는 말이라고 보셔도 됩니다. 하지만, 그것만이라고 생각하시면 안 됩니다. 이유는 퍼블리셔의 역할을 제대로 알고 수행하는 인력은 코더와 비교되어 분류, 평가되어야 하기 때문입니다. 퍼블리셔의 역할이 중요하게 인식되는 이유는 웹 표준으로 인하여 발생되는 브라우저간의 문제점 구조화의 분석을 통한 소스의 최적화 등 디자인에서 개발로 넘어가기 전 디자이너의 의도에 맞게!, 개발 쪽의 의도에 맞게! 이슈를 최소화하여 작업에 보다 쉽고 관리가 용이하게 해주는 없어서는 안 될 역할이기 때문입니다. 그리고 또 다른 이유가 바로 W3C에서 주창하는 “웹을 사용하는 모든 이들에게 동일한 사용 환경을 제공해야 한다.” 웹 접근성 향상에 기여하는 부분이 많기 때문입니다. 이처럼 단순히 기존의 Table 코딩에서 DIV 코딩으로 변화한 것이 아닌, 보다 전문적인 직종으로 발돋움하기 위해 퍼블리셔가 갖추어야 할 요건이 많이 생겼기 때문입니다.

웹 퍼블리셔(web Publisher)역할은 알았는데? 영역은?
코 더의 역할을 벗어나 기획, 디자인, 개발까지 의견을 반영하고 접근성 및 표준을 순수할 수 있게 해주는 중요한 포지션(Position)에 위치한 것이 퍼블리셔라고 앞에서도 말씀드렸습니다. 퍼블리셔의 영역은 [표준과 접근성]이 주된 일이기 때문에 디자인 영역과는 90% 이상 관계가 없습니다. 물론, 100% 디자인과 연관이 없는 것은 아니기 때문에 퍼포먼스가 큰 유동적인 페이지는 디자이너의 합의하에 조율을 할 수 있는 것입니다. 그리고 Flash 등을 활용한 비 접근성적인 디자인이 나온다 하더라도 충분히 퍼블리셔는 커버의 역할이 가능합니다. Flash 쪽에서 로딩(Loading) 완료시, 일정 값(value)을 스크립트(Script)로 주고, 그것이 확인되면 Flash를 호출하고, 그렇지 않을 경우 이미지(image)로 처리하게 도와주면 되는 것이죠. 결론은 표준 작업시 특정 이슈에 고나한 것은 디자인 쪽과 조율을 하되 그 이상은 관여하지 않는 것이 디자인 영역에 대한 퍼블리셔의 영역입니다.

그럼 개발영역에 대한 퍼블리셔의 영역은 무엇일까요? 개발자와 일하는 퍼블리셔가 고려해야될 상황은 웹 표준 및 DocType을 인지하지 못한 개발자와 작업하는 경우입니다. 퍼블리셔는 개발 도중 이거 안 되고, 저거 안 되고 하는 것보다 미리 간단한 WSG를 만들어 개발자에게 배포/교육 후 프로젝트에 들어가면 문제가 발생되는 것을 미리에 방지하는 것이죠.

예를들어 스크립트 부분에서 IE, FF, Safari 등 특정 스크립트만 인식하는 부분과 그렇지 않은 부분, 태그(Tag) 사용법 등을 미리 선정하여 문제를 방지하는 것입니다.

여 지껏 이야기를 정리하자면, “퍼블리셔는 서포터의 역할을 수반하는 직종이다.”라고 볼 수 있겠죠. 즉 이거 아냐, 저거 아냐가 아니고 최대한 디자인을 살린! 최대한 개발 영역을 넓혀주는 역할을 하는 것이 바로 퍼블리셔의 영역인 것입니다.

퍼블리셔가 디자이너에게_

“가능한 서포트 해드릴 테니 마음껏 디자인 하세요. 정 안되면 말씀드릴게요. ^-^ ”

퍼블리셔가 개발자에게_

“일단 저희가 준 WSG를 최대한 참고하시고, 개발 완료시점 때 미팅을 하면서 변경하죠.”

그렇습니다. 최고의 퍼블리셔는 틀이 아닌, 두 개의 직종을 무한대로 확장시켜주는 서포터인 것입니다.

- 정리 by yamoo9

  <참고> DOM스크립트(에이콘출판사), 서정민님의 웹 퍼블리셔에 대한 글.

웹표준 교과서에서 소개하는 CSS 핵 & 필터 안내 페이지

그 외에 평소에 자주 사용하는 팁으로서의 CSS 핵 정리는 아래에 정리.

Netscape 4 배제하기
<link rel="stylesheet" type="text/css" href="/css/style.css" media="all" />
Netscape 는 media 속성이 screen 이 아닌 경우 외부 스타일시트를 읽지 못하는 버그가 존재함.

Win IE 3~4, Mac IE 4~4.5, Netscape 4 배제하기
@import url("/css/style.css")
Win IE 4, Mac IE 4 는 인용부호가 "가 아니면 읽지 못하는 버그 존재. IE 3과 Netscape 4는 @import 지원하지 않음.

Mac IE 5 배제하기
H1 { /* \*/ color:red; /* */ }
Holly 핵이라 하며, 주석 안의 내용이 적용되지 않음.

Win IE 4~5 배제하기
H1/**/ { color:red; }
셀렉터 뒤에 /**/ 삽입.

Win IE 4~5, Mac IE 4.5~5 배제하기
H1 { color/* */:red; }
속성과 속성값을 구분하는 콜론(:) 앞에 /* */ 삽입.

Win IE 4~6, Mac IE 4, Netscape 4 배제하기
html>body H1 { color:red; }
셀렉터 앞에 html>body 삽입.

Win IE 6 제외시키기
H1 { color /**/:red; }
속성과 속성값을 구분하는 콜론(:) 앞에 스페이스와 /**/ 삽입.

언더스코어 핵 (_)
H1 { _color:red; }
Win IE 4~6 에 적용.

닷핵 (.)
H1 { .color:red; }
속성 앞에 . 삽입. Win IE 6~7 에만 적용. 타 브라우저는 정확히 확인하지 못했습니다.
이 핵에 대해선 계속 확인중인데 블로그스피어나 여타 서적에는 전혀 언급이 없는 이상한 핵(?)입니다.

해시 핵(#)
H1 { #color:red; }
속성 앞에 # 삽입. Win IE 4~6, Mac IE 5, Opera 7, Mozilla계열, Firefox 에 적용.

스타 핵
*HTML H1 { color:red; }
셀렉터 앞에 *html 삽입. Win IE 4~6, Mac IE 4~5 에 적용.

스타7 핵
HTML*H1 { color:red; }
셀렉터 앞에 html* 삽입(공백없이). Win IE 5.5~6, Mac IE 5, Safari 에 적용.

xmlns 속성 핵
HTML[xmlns] H1 { color:red; }
셀렉터 앞에 속성 선택자를 삽입. Mozilla, Firefox, Opera, Safari 등 속성 선택자를 지원하는 브라우저에 적용.

:root 가상클래스 핵
:root H1 { color:red; }
셀렉터 앞에 :root 가상클래스 삽입. Mozilla, Firefox, Mac IE 5, Safari 등 가상클래스를 지원하는 브라우저에 적용.

Tantek 박스모델 핵
H1 {
    width:500px;
    voice-family: ""}"";
    voice-family:inherit;
    width:400px;
}
Tantek Celik 이 고안한 유명한 박스모델 핵. Win IE 4~5, Mac IE 4, Netscape 4 에서는 voice-family 속성 이전의 스타일 적용. 그외의 브라우저는 뒤의 속성 적용.

단순 박스모델 핵
H1 {
    width:500px;
    w\idth:400px; //Win IE 6, Mac IE 5, Mozilla, Opera, Safari
    \width:450px; // only Win IE 5
}
속성의 첫번째, 두번째 글자 사이에 \를 삽입하면 Win IE 6, Mac IE 5, Mozilla, Opera, Safari 에 적용.
추가로 속성의 앞에 \를 삽입하면 Win IE 5 에만 적용.

IE 7, Opera 적용하기
*+html body H1 { color:red; }
셀렉터 앞에 *+html body 삽입. IE 7, Opera 8 이후 버전 적용. Opera를 배제한 IE7 전용으로 하고 싶을 때는 *+html>/**/body 로 Opera 전용 속성 기술.

IE 7 적용하기
*:first-child+html H1 { color:red; }
셀렉터 앞에 *:first-child+html 삽입. IE 7에만 적용되고, 이외의 브라우저는 앞에서 기술한 셀렉터의 속성 적용.

Win IE 5 패스필터
@media tty {
i{content:"";/*" "*/}}; @import '/css/style.css'; {;}/*";}
}/* */

Win IE 5.5 패스필터
@media tty {
i{content:"";/*" "*/}}@m; @import '/css/style.css';/*";}
}/* */

Win IE 6 패스필터(?)
<!--[if IE 6]><link rel="stylesheet" type="text/css" href="/css/style.css" media="all" /><![endif]-->

Win IE 7 패스필터(?)
<!--[if gte IE 7]><link rel="stylesheet" type="text/css" href="/css/style.css" media="all" /><![endif]-->

모던브라우저 패스필터 (Win IE 5.5 이하, Mac IE 5, Opera 8 이하, Netscape 4 이하 제외)
@import "null?"{";
@import "/css/style.css";
@import "null?"}";


저의 주 작업 브라우저는 IE6, IE7, FF2, OP9 입니다. 개인적으로 CSS 핵은 거의 사용하지 않지만, 폼 (특히 체크박스, 라디오 버튼) 의 형태가 각 브라우저마다 틀려서 IE 6~7 에서 폼의 마진을 조절하기 위해 언더스코어 핵, 닷핵 만을 사용하고 있습니다.
덧붙여... 우리나라에서 최고의 사용률을 보여주는 IE가 CSS Spec을 제대로 지원하지 않으면서도 이를 업데이트하지 않는 이유는, 아이러니컬하게도 브라우저간 버그를 보정하기 위한 CSS핵도 큰 이유를 차지하고 있는 듯.
IE 6에서 갑자기 IE 7 또는 표준스펙 풀 지원으로 CSS 지원 스펙을 수정하면 현재 IE 6 기준으로 만들어진 사이트나 IE 6용 패스필터, 핵을 사용한 엄청난 수의 사이트(특히 우리나라)는 어떻게 될지...

중요 포인트!!
1. 구조를 설계할 때 절대 CSS핵 위주로 설계하지 말 것.
2. 단발성 CSS 핵보다는 패스필터 사용 권장.
3. CSS핵은 어쩔 수 없는 경우에만 사용할 것.


출처:http://kaludin.egloos.com/967831

01 / 무분별한 table의 사용금지

 

02 / 잘못된 위치, 태그, 스크립트 사용

• form태그 tr태그 사이에 넣지 않기
• ⇒ 오류의 원인 (form태그의 공배해결을 위해)
• ⇒ 해결책 form {margin:0;}
  
  
• form submit 자바스크립트로 하지 않기
• ⇒ 잘못된 표현예 <a href="javascript:search()"><img src="test.gif" /></a>
• ⇒ 해결책  <input type="submit" /> 혹은 <input type="image" />
  
  

  <form action="/search/" method="get" onsubmit="validation(this)"> <div class="search"> <select> <option>제목</option> <option>내용</option> <option>작성자</option> </select> <input type="text" size="10" class="type-text" /> <inpyt type="image" src="button_search.gif" alt="검색" /> </div> </form>

 

 

 

03 / 올바른 그룹요소의 사용 (div, span)

• div등 일부 태그를 table 대용으로 사용하지 않도록 한다. (의미에 맞는 태그사용)
• block / inline 예
• block 요소 ⇒ <div>, <form>, <ul>, <ol>, <li>, <dl>, <dt>, <dd>
• inline 요소 ⇒ <span>, <a>, <img>, <slect>, <input>

 

04 / 표제의 사용(Heading)

• <h1>~<h6> 문서내 가장 중요한 제목을 <h1>에서 부터 차례대로 하위 heading 지정
• <h1> 하위 heading은 <h3>로 건너띄어서는 안된다.

05 / 올바른 문단작성을 위한<p>태그

• <p>올바른 문단작성을 위해 P태그 사용해라</p>
• <p>태그는 inline요소만을 포함할 수 있다.⇒

 

 

 

06 / 구문을 분리해서 사용하라 (em,strong,dfn,code,samp,kbd,var,cite,abbr,acronym)

• 의미에 있어 강조(em, strong)
• <em> ⇒ 이탤릭체로 표현
• <strong> ⇒ 볼드체로 표현
• <i> 또는 <b> 단순히 표현을 이탤릭이나 볼드로 표현 
• <i> 이탤릭
• <b> 볼드
  
  
• 용어정의를 나타는 <dfn>
• <dfn> DDR(dial-on-demand routing) </dfn> 이란 어쩌구 저쩌구....
  
  
• 코드표현 <code>
• <code> ⇒ 컴퓨터 코드를 나타냄
• <samp> ⇒ 코드의 결과 출력물을 나타냄
  
  
• 값을 표현하는 <kbd>
• <kbd> ⇒ 유저키보드 입력
• <kbd>Enter</kbd>키를 누르세요.
• <var> ⇒ 프로그램에서의 변수선언
  
  
• 인용이나 출처를 나타내는 <cite>
  
  
• 축약을 표현하는 <abbr>, <acronym>
• <abbr> ⇒ 축약어(한글자씩 읽음) ⇒ who(w.h.o로 한글자씩 발음)
• <acronym> ⇒ 두문자어(약어를 그대로 발음) ⇒ Dom(돔으로 발음)
  
  
• 인용문구표현하는 <blockquote>, <q>
• <blockquote> ⇒ block요소
• <q> ⇒ inline요소
  
  
• 첨자 <sup>, <sub>
• x² + 4x + 4 = (x+2)²

07 / 추가 및 삭제 <ins>, <del>

• 문서에 <ins>새로 추가</ins>되거나 <del>삭제된 내용</del>을 표시 할 수 있습니다.
• <ins> 밑줄로 표시
• <del> 취소선으로 표시

08 / 리스트항목 <ul>, <ol>, <dl>

• <ul></ul>
• 하위로 <li></li>를 가진다.
• 앞에 불릿이 붙는다.
  
  
• <ol> </ol>
• 하위로 <li> </li>가 붙는다.
• 앞에 자동적으로 숫자가 붙는다.
  
  
• <dl></dl>
• 하위에 <dt><dd>를 가진다.
• <dt> ⇒ term을 담는다.
• <dd> ⇒ definition을 담는다.

  [출처] 웹표준가이드(3) / 올바른 마크업을 위한 준수사항|작성자 마그리뜨

01 / html과 css의 관계

• html : 컨텐츠의 내용과 구조 표시
• 컨텐츠가 문단인지<p>, 인용문인지<blockquote>, 리스트형태<ul>인지에 따라 적합한 엘리먼트로 표기
• 컨텐츠가 문서내에서 가지는 의미에 따라 <div>와 적절한 id, class 속성표기(나타내고자 하는 컨텐츠를 의미에 맞게 기술하여 웹페이지로의 접근성을 높이는 방법으로 markup을 만드는 것이 웹표준의 목적)
• 웹표준의 목적 : 컨텐츠의 의미에 맞게 기술하여 웹페이지로의 접근성을 높이는 방법으로 markup하는 것.
  
  
• css : 문서의 내용과 표현을 분리하는것
• 문서의 내용은 html로 작성하고 표현은 css로!!

 

 

02 . css의 일반선택자

일반선택자(selector) 종류

• (*) : 공용선택자 ㅣ 모든 태그에 적용
• (a) : 타입선택자 ㅣ 태그 <a> 지정
• (.A) : class 선택자 ㅣ 클래스가 A인 태그에 적용
• (#A) : id 선택자 ㅣ 아이디가 A인 태그에 적용
  
  
  

(*)공용선택자

* {     margin: 0;     padding: 0;  }

페이지 내의 모든 <h1>,<h2>,<p>,<form>,<blockquote> 등의 브라우져 기본 마진과 패딩을 가지고 있는 엘리먼트들의 여백을 없앤다.

div.search * {                     vertical-aling: middle;  }

div.search안의 모든 엘리먼트가 세로로 가운데 정렬이 되게 된다.

(a)타입선택자 : 해당엘러먼트를 선택하여 속성 부여

클래스선택자 : 한페이지에서 여러번 사용가능

아이디선택자 : 한페이지에 한번만 사용할 수 있다.

[출처] 웹표준가이드(4) / css선택자와 선언종류|작성자 마그리뜨