HTML/CSS2010. 8. 19. 09:32

block요소 엘리먼트의 중앙정렬

DIV태그에 text-align:center속성을 주고 TABLE태그를 둘 경우 IE에선 가운데 정렬이 되는데 FF(또는 dtd에 따른 IE8)에선 왜 안되냐 라고 물어 보는 분들이 있어 블러그에 올려 둡니다.

TABLE태그는 기본적으로  Block-level 엘리먼트로 정의 되어 있습니다.(http://htmlhelp.com/reference/html40/block.html)
따라서 이런 Block-Level 엘리먼트는 text-align:center로 중앙 정렬을 할 수 없습니다. 원칙적으로는 말이죠.


일단 이미지를 통해 내용을 확인하겠습니다.

<div style="border:1px solid red; text-align:center">
    <table width="200" border="1" cellspacing="0" cellpadding="0">
        <tr>
            <td>&nbsp;</td>
        </tr>
    </table>
    <br>
    <table width="200" border="1" cellspacing="0" cellpadding="0">
        <tr>
            <td>&nbsp;</td>
        </tr>
    </table>
    <br>
    <table width="200" border="1" cellspacing="0" cellpadding="0">
        <tr>
            <td>&nbsp;</td>
        </tr>
    </table>
</div>

이렇게 간단히 코딩을 하고 위와 같은 이미지를 기대 하셨을 겁니다. 그런데 이게 브라우저 또는 dtd에 따라서 다른 모양을 나타 낼겁니다.
혹시 에디트플러스를 켜놓고 html에 위의 내용을 작성 하셨다면 dtd문제로 브라우저 마다 다른 화면을 보게 될겁니다.

그 이유는 에디트플러스에서 제공하는 기본적인 dtd <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">는 dtd가 아닙니다. 순수하게 문법오류만을 잡아낼뿐 dtd에 대한 내용이 없습니다. 뿐만아니라 HTML 4.0입니다. 이미 HTML이 4.1로 바뀐마당에 서언문 자체도 문제가 있죠. 아무튼 이건 기본적인 dtd일뿐입니다.


따라서 만약 DIV안의 TABLE을 중앙 정렬을 시켜야 한다면 아래와 같이 하셔야 합니다.

<!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></head>
<body>
<div style="border:1px solid red;">
    <table width="200" border="1" cellspacing="0" cellpadding="0" style="margin-left:0px; margin-right:auto">
        <tr>
            <td>왼쪽</td>
        </tr>
    </table>
    <br />
    <table width="200" border="1" cellspacing="0" cellpadding="0" style="margin-left:auto; margin-right:auto">
        <tr>
            <td>중앙</td>
        </tr>
    </table>
    <br />
     <table width="200" border="1" cellspacing="0" cellpadding="0" style="margin-left:auto; margin-right:0px">
        <tr>
            <td>오른쪽</td>
        </tr>
    </table>
<div>
</body>
<html>

위와 같이 하는게 정상적인 방법인데, 만약 quirks모드로 화면을 구동 시킨다면 IE8이건 IE6이건 단순히 DIV에 text-align:center만 놓아도 됩니다.

사실 IE6이 문제라기 보단 IE가 가진 기본적인 quirks모드에 따라 화면이 달라 보이는 겁니다.
즉 위의 소스에서 보이는 DTD를 STRIC모드로 하였을 경우 TABLE에 style="margin-left:auto; margin-right:auto"(또는 margin:0px auto)속성을 줘야 합니다.


위의 속성으로 화면을 보게 되면 아래와 같이 나옵니다.


사실 이런 불편한 관계를 피하기 위해서는 기본적으로 DTD선언에 맞춰 화면을 개발 해야 하며, 기본적으로 엘리먼트의 속성을 파악 해줘야 합니다.
Posted by Jake Kim
HTML/CSS2010. 6. 22. 19:09

DOCTYPE에 따른 브라우저 렌더링

이번에 다룰 내용은 브라우저와 DOCTYPE에 따른 width와 height 그리고 padding, border등의 관계에 대해서 다루겠습니다. 단순하게 말하자면 브라우저와 DOCTYPE에 따른 박스모델 구현 정도로 알아 두시면 되겠습니다.

일단 이미지를 보여드리겠습니다.

Strict(W3C박스 모델)

Quirks

내용 적고, 소스 만드는 시간보다 저 이미지 만드는 시간이 훨씬 오래 걸렸답니다.

잡설은 집어치우고 계속 내용을 이어 가겠습니다. 한쪽은 승인된 DOCTYPE이 포함된 페이지이며, 한쪽은 DOCTYPE없는 페이지 입니다. IE에서 이처럼 차이를 나타내난 이유는 브라우저의 렌더링 차이 때문입니다.

IE는 기본적으로 렌더링 모드가 strict인지 quirks인지에 따라 렌더링 방식을 결정합니다. 즉 페이지에 선언한 DOCTYPE이나 혹은 DOCTYPE의 생략 여부에 따라 사용되는 렌더링 모드가 결정 된다는 말입니다.

IE는 quirks모드일 경우 width와 height안에서 엘리먼트를 구성합니다. padding과 border또한 처음 설정한 widht와 height안에서 결정 된다는 말이죠. 반면에 strict인 경우는 width와 height크기에 영향을 주지 않은 채로 padding과 border가 추가가 된다는 말이죠. (표현되는 엘리먼트의 크기는 이미지를 참고 하시기 바랍니다. 고생한 결과물은 봐줘야 합니다. ㅡㅡ;)

즉 박스모델은 padding및 border와 결합하여 엘리먼트의 컨텐츠 크기를 결정하게 됩니다. 참고로 margin또한 박스 모델의 일부분이지만 컨텐츠 크기를 결정하는 부분은 아닙니다. 사실 대부분의 브라우저가 W3C박스 모델을 지원하지만, 인터넷 익스플로러만 페이지의 렌더링 모드가 strict인지 quirks인지에 따라서 박스 모델을 결정하다 보니 엘리먼트의 크기가 달라진다고 할 수 있습니다.

사실 두 방법 중 어떤 방법이 더 좋다, 나쁘다 말할 수 없습니다. 서로 자신이 지지하는 방식에 따른 quirks방식이 좋다 strict방식이 좋다고 말할 뿐이죠.

마지막으로 글을 쓰다 보니 단순히 IE의 strict과 quirks에 대해서만 다루게 되었네요.
다음에 기회가 된다면 DOCTYPE에 대해서 다루겠지만, 본 내용을 잘 이해하시려면 DOCTYPE에 대해서 꼭 아셔야 합니다. 내용에 DOCTYPE부분이 많이 빠진 관계로 해당 내용은 링크로 대신합니다.

http://www.w3schools.com/tags/tag_doctype.asp
http://ko.wikipedia.org/wiki/XHTML

그리고 혹시 DOCTYPE 이슈에 관한 내용을 좀더 알고 싶다면(http://www.quirksmode.org/css/quirksmode.html) URL을 참고 하시기 바랍니다.

Posted by Jake Kim
HTML/CSS2010. 5. 28. 11:41

브라우저 리셋 CSS

출처: http://meyerweb.com/eric/tools/css/reset/

기본적으로 설정 되어 있는 엘리먼트의 padding, margin, outline등의 속성을 없앨때 사용하시면 됩니다.
저 같은 경우는 이렇게 많은 값을 한번에 초기화 하지 않고 필요한 값만 그때 그때 초기화 했었는데... 일단 알아 두면 차후 도움은 될듯합니다.

/* v1.0 | 20080212 */
html, body, div, span, applet, object, iframe, 
h1, h2, h3, h4, h5, h6, p, blockquote, pre, 
a, abbr, acronym, address, big, cite, code, 
del, dfn, em, font, img, ins, kbd, q, s, samp, 
small, strike, strong, sub, sup, tt, var, 
b, u, i, center, 
dl, dt, dd, ol, ul, li, 
fieldset, form, label, legend, 
table, caption, tbody, tfoot, thead, tr, th, td {
    margin: 0; 
    padding: 0; 
    border: 0; 
    outline: 0; 
    font-size: 100%; 
    vertical-align: baseline; 
    background: transparent; 
} /* *{margin:0; padding:0;}은 모든 요소에 상속이 되어 컨텐츠가 많은 경우 속도가 느려진다고 합니다 */ 
body { 
    line-height: 1; 
} /* 필요한 경우 적절하게 line-height를 조정하면 될 것 같습니다 */ 
ol, ul { 
    list-style: none; 
} /* 대부분의 리스트를 리스트 스타일을 제거하고 bullet은 백그라운드 이미지로 처리하는 경우 필요합니다 */ 
blockquote, q { 
    quotes: none; 
} 
blockquote:before, blockquote:after, 
q:before, q:after { 
    content: ''; 
    content: none; 
} /* 인용구 태그의 앞뒤를 정리하는데 쓰입니다. */ 

/* remember to define focus styles! */ 
:focus { 
    outline: 0; 
} /* 이 속성을 쓰면 개체에 포커스가 간 경우 outline이 안 보이기 때문에 저는 지우고 사용합니다. */ 

/* remember to highlight inserts somehow! */ 
ins { 
    text-decoration: none; 
} /* ins 태그는 중간에 삽입된 개체에 대해 씁니다. 기본값은 underline이기 때문에 필요한 정도로 수정하여 쓰면 됩니다 */ 
del { 
    text-decoration: line-through; 
} /* del 태그는 중간에 삭제된 개체에 대해 씁니다. */ 

/* tables still need 'cellspacing="0"' in the markup */ 
table { 
    border-collapse: collapse; 
    border-spacing: 0; 
}
Posted by Jake Kim
HTML/CSS2010. 5. 4. 09:11

Javascript의 올바른 표준 MIME TYPE은??

적당히 아는게 참 무서운거다... 적당히 그런게 있어라고만 알고 있었는데.. 이 참에 좀 적어놔야 겠다.

지금까지 일반적으로 Javascript를 웹 문서에 올려 놓을때 MIME TYPE으로 대충 다음의 것들을 사용했다.

* text/javascript
* text/ecmascript
* application/x-javascript (javascript 앞에 x가 붙은 것은 표준이 아닌, 실험적인 것임을 뜻함)
* text/javascript1.5 (요새 브라우저들은 버전 숫자를 그냥 무시해 버림)
* language="JavaScript" (HTML 4부터는 지원하지 않음)

그래서 이런 혼란스런 상황을 막으려고 2006년 4월에 Javascript(ECMAScirpt)를 위한 MIME type의 표준(RFC4329)이 마련되었지만, 여러 브라우저들의 표준 JavaScript MIME type 지원은 아직 요원한 상황이다.
(확인해 본 바로는, 지금까지 오직 Firefox 1.5+, Opera 9+, Camino 만이 지원하고 있다.)

Javascript 프로그램은 그 성격상 text 문서로 지정하는 것은 적절치 않으며, 대신 application/javascript 혹은 application/ecmascript(이것을 사용하면 좀 더 엄격한 적용 규칙이 주어진다)를 대신 사용할 것을 권장하고 있지만, 이는 대부분의 웹 브라우저들이 지원하지 않는 한 그 실제 적용은 아직 이를 것이다.

Posted by Jake Kim
HTML/CSS2010. 4. 2. 23:29

Javascript & CSS 객체 제어 프로퍼티 모델

출처: http://blog.naver.com/woodambara_?Redirect=Log&logNo=20062319065




object 제어 요소
  offsetLeft, offsetTop, offsetWidth, offsetHeight,
  clientLeft, clientTop, clientWidth, clientHeight,
  scrollLeft, scrollTop, scrollWidth, scrollHeight
 
style 제어 요소
 margin, padding, border

Posted by Jake Kim
HTML/CSS2010. 2. 24. 14:59

tabindex 속성이 오히려 접근성을 해친다.

출처: http://naradesign.net/wp/2009/04/07/744/

tabindex라는 속성이 있습니다. 말 그대로 tab의 접근 순서를 인위적으로 변경할 수 있는 속성 입니다.
tabindex는 다음 요소에 적용할 수 있습니다.

a, area, button, input, object, select, textarea

이 요소들 이외의 요소에 tabindex 속성이 지정되면 문법적으로 유효하지 않습니다. 그러나 문법적으로 옳고 그름을 떠나 한 가지 질문을 던져 보겠습니다.

tabindex 속성을 왜 사용하시나요?

여러분은 아마도 아래 두 가지 경우중 하나의 대답을 선택할 것입니다.

1. 사용성을 높이기 위하여.
2. 접근 순서를 보완하기 위하여.

tabindex, 사용성을 높인 사례.

포털 초기화면에서 가장 많은 포커스를 가져가는 곳을 순서대로 정렬시켜 보면 어떨까요?

1. 검색 인풋
2. 아이디 인풋
3. 비밀번호 인풋
4. 로그인 버튼

맞나요? 객관적으로 제시할 근거 자료는 없지만 저는 거의 확신하고 있습니다. 국내 양대 포털인 DAUM과 NAVER에 가서 키보드만으로 웹 페이지를 탐색해 보세요. tab 키는 ‘검색 인풋-아이디 인풋-비밀번호 인풋-로그인 버튼’ 순으로 이동할 것입니다.
양대 포털은 누가 먼저랄 것도 없이 이 네 가지 요소에 tabindex를 적용 했습니다. 굳이 누가 먼저 했는지를 따지는 것은 의미는 없는 일입니다. 어느 한쪽이 뒤늦게 이것을 했다고 해서 따라했다는 소리를 들을 필요는 없다고 생각하니까요. 키보드만으로 웹 페이지를 탐색하는 사람들은 보통 장애인이거나 또는 숙련된 사람들 입니다. 이 사람들에게 포털에서 제공한 tabindex키는 분명 도움이 되었을 것입니다. 굳이 제공하지 않더라도 접근에 제한이 되는것은 아니지만 제공함으로써 효율적인 탐색이 가능하게 되었으니 사용성을 높였다고 평가할 수 있습니다. ‘검색 인풋-아이디 인풋-비밀번호 인풋-로그인 버튼’ 탐색이 끝나면 포커스는 페이지에서 가장 처음 등장하는 a, area, button, input, object, select, textarea 요소를 찾고 그 이후로는 순차적으로 웹 페이지를 탐색할 것입니다.

tabindex, 키보드 접근 순서를 보완한 사례.

tabindex가 접근성을 높여준다는 오해가 있는데 완전히 잘못된 상식입니다. 만약 여러분이 사용성을 높이기 위한 목적이 아니라 HTML의 접근 순서를 보완하기 위하여 tabindex를 사용했다면 그것은 여러분의 HTML이 논리적인 순서로 마크업 되지 않았다는 것을 반증하는 것입니다. HTML의 마크업 순서가 논리적으로 작성되었다면 tabindex 속성은 애시당초 필요하지 않습니다. 심지어 tabindex 속성은 HTML 스펙에서 사라지더라도 전혀 문제가 없는 속성이라고 생각합니다. 빈번하게 발견되는 예를 한번 들어 보겠습니다.

다음과 같이 table을 이용하여 로그인 서식을 배치하는 경우 키보드 접근 순서는 ‘아이디 인풋-로그인 버튼-비밀번호 인풋’이 됩니다. 이 순서는 HTML 마크업 순서에 따라 발생하는 순서로써 논리적이라고 보기 어려운 순서 입니다. 

HTML 코드를 보면 왜 이런 순서로 탐색이 되는지 알 수 있습니다.

<TABLE border=1>
     <TBODY>
          <TR>
               <TH scope=row><LABEL for=uid>아이디 :</LABEL></TH>
               <TD><INPUT id=uid></TD>
               <TD rowSpan=2><INPUT value=로그인 type=submit></TD>
          </TR>
          <TR>
               <TH scope=row><LABEL for=upw>비밀번호 :</LABEL></TH>
               <TD><INPUT id=upw value="" type=password></TD>
          </TR>
     </TBODY>
</TABLE>


로그인 버튼은 병합된 첫 번째 행의 세 번째 컬럼에 포함되기 때문에 아이디 인풋 다음으로 포커스를 받게 됩니다. 비밀번호를 작성하지 않은 상태로 로그인 하도록 유도하는 상황 입니다. 문제는 웹 페이지 저작자들이 이 문제를 해결하기 위하여 table을 걷어내지 않고 ‘아이디, 비밀번호, 로그인’ 콘트롤에 tabindex 속성을 사용한다는 데 있습니다. 여기서 tabindex를 사용하게 되면 tab키는 다른 어떤 항목보다 로그인 서식을 먼저 탐색하게 됩니다. 이것이 의도한 경우라면 문제가 되지 않지만 만약 ‘로그인’ 서식이 아니고 웹 페이지에서 가장 먼저 탐색이 되어야 하는 콘텐츠가 아니라면 어떨까요? 어설프게 tabindex를 사용한 다음 그 순서가 잘못 지정된 것을 바로잡지 않은 사례가 무척 많이 발견 됩니다. 또 그것을 그대로 복사해서 다른 곳에 아무 생각 없이 가져다 쓰는 사례도 많습니다. 이런 경우 tabindex가 접근성을 오히려 훼손하게 됩니다. 지금 당장 여러분이 제작한 웹 사이트를 찾아서 tabindex가 사용되었는지를 확인하고 접근 순서를 오히려 훼손하고 있지 않은지 테스트 해보세요.

tabindex 대신 HTML의 논리적인 구조를 바로잡아야.

테이블이 사용되지 않아야 할 곳에 테이블이 사용되었다면 테이블을 걷어내야 합니다. 위에서 예로 든 로그인 서식의 경우 적어도 th 요소가 있기 때문에 table이 의미에 맞지 않는다고 보기는 어렵습니다. 단지 논리적인 구조를 갖지 못할 뿐이죠. 그러나 table을 걷어낸다면 적어도 tabindex를 사용하지 않아도 될 것입니다. 매우 치밀하게 사용하고 관리하지 않는다면 tabindex를 사용하는 것은 여러분의 웹 사이트에 땜빵질을 하는 것과 같습니다. 땜빵하는 방법 대신 얼개를 바꾸기를 강력하게 권장 합니다

Posted by Jake Kim
HTML/CSS2010. 2. 19. 09:50

CSS Box Model

출처: http://www.w3.org/TR/CSS2/box.html

CSS를 통해서 어떻게 레이아웃을 잡고 사용하는지를 간단하게 보여준 예제...

UL {
	background: yellow;
	margin: 10px;
	padding: 5px;
	/* No borders set */
}
LI {
	color: white;		/* text color is white */
	background: blue;	/* Content, padding will be blue */
	margin: 10px;
	padding: 10px 0px 10px 10px;/* Note 0px padding right */
	list-style: none			/* no glyphs before a list item */
	/* No borders set */
}
LI.withborder {
	border-style: dashed;
	border-width: medium;		/* sets border width on all sides */
	border-color: lime;
}


    
	
  • First element of list
	
  • Second element of list is a bit longer to illustrate wrapping.



Posted by Jake Kim
HTML/CSS2009. 10. 13. 10:08

CSS Tab 메뉴입니다.

탭 메뉴 기본 이미지 입니다.
탭 이미지를 변경 했다면 관련 색깔을 CSS에서도 동일하게 변경 해야 롤오버시 문제가 없습니다.

관련글: CSS Tab Designer입니다.
Posted by Jake Kim
HTML/CSS2009. 7. 7. 15:43

pt, px, em 환산표

출처 : http://blog.naver.com/preserde?Redirect=Log&logNo=130022567536

Points Pixels Ems Percent
6pt 8px 0.5em 50%
7pt 9px 0.55em 55%
7.5pt 10px 0.625em 62.5%
8pt 11px 0.7em 70%
9pt 12px 0.75em 75%
10pt 13px 0.8em 80%
10.5pt 14px 0.875em 87.5%
11pt 15px 0.95em 95%
12pt 16px 1em 100%
13pt 17px 1.05em 105%
13.5pt 18px 1.125em 112.5%
14pt 19px 1.2em 120%
14.5pt 20px 1.25em 125%
15pt 21px 1.3em 130%
16pt 22px 1.4em 140%
17pt 23px 1.45em 145%
18pt 24px 1.5em 150%
20pt 26px 1.6em 160%
22pt 29px 1.8em 180%
24pt 32px 2em 200%
26pt 35px 2.2em 220%
27pt 36px 2.25em 225%
28pt 37px 2.3em 230%
29pt 38px 2.35em 235%
30pt 40px 2.45em 245%
32pt 42px 2.55em 255%
34pt 45px 2.75em 275%
36pt 48px 3em 300%

[출처] CSS의 em 단위|작성자 아마티


Posted by Jake Kim

티스토리툴바