[2010 TAEYO.NET 오프 스터디]에서 발표한 "Developer`s Web Standard" 세션의 발표 자료입니다. ※ 이 자료는 오래전 진행한 내용을 다루고 있습니다. 작성 시점 혹은 이후라면 유용하지 않을 수 있으니 참고 부탁드립니다.

1. Microsoft Community Conference
Developer`s
Web Standard
한상훈
Taeyo.NET ASP.NET 시삽
Microsoft MVP(ASP/ASP.NET)

2. Microsoft Community Conference
Agenda
• 웹 표준(Web Standard)
• XHTML
• CSS(Cascading Style Sheet)
• CSS 레이아웃
• DOM/Script
• 웹 접근성
• 크로스 브라우징
• 검증과 확인
• HTML5, CSS3

3. Microsoft Community Conference
웹 표준 (Web Standard)

4. Microsoft Community Conference
웹 표준이란 무엇인가?
• 웹 표준
– 월드 와이드 웹의 구현 방법을 서술하고 정의하는 공
식 표준이나 기술 규격
– W3C(World Wide Web Consortium)에서 정의
– W3C의 토론을 통해 나온 권고안(Recomendation)
• W3C(World Wide Web Consortium)
– http://www.w3c.org, http://www.w3c.or.kr/
– 연구기관 : MIT LCS, ERCIM, 게이오 대학
– 참여기업 : 약 500여개의 다국적 IT 기업체
– Leading the Web to its Full Potential…

5. Microsoft Community Conference
웹 표준에 목적
• 웹에 모든 잠재력을 이끌어 내기 위하여…
– W3C에 창설 의도이면서 동시에 웹 표준을 지향하는
근본적인 목적
• 호환성
– 상호 호환성 (Cross Browsing)
– 상위 호환성 (Forward Browsing)
– 하위 호환성 (Backward Browsing)
• 장기적인 관점에서의 웹 표준
– 어느 한쪽에 치우치지 않는 웹
– 미래에 어떠한 브라우저나 장치에 출현에도 영향 받
지 않는 웹

6. Microsoft Community Conference
웹 표준이 정의되는 과정
• 제안에서 확정까지의 과정
– 단일 혹은 세트에 어떤 기능을 Draft로서 제안
– 실제로 적용이 가능하도록 기술적인 작업 수행(Working
Draft)
– 논리 오류 유/무, 하드웨어에서 지원 가능 유/무를 확인 후
기업체에 공개하여 토론(Candidate Recommendation)
– 최종적으로 권고안을 확정(Recommendation)
Draft Working Draft
Candidate
Recommendation
Recommendation

7. Microsoft Community Conference
웹 접근성! 크로스 브라우징!
• 웹 접근성
– “누구나” 웹에 접근할 수 있어야 한다.
– 컨텐츠를 2차원 이상의 다차운 수준으로 제공하여 다
양한 조건 및 상황에 대처
• ex : 자동차 네비게이션, 각종 영상의 자막
– 장애인 차별 금지법 시행
• 공공기관 및 300인 이상 사업장 우선 적용
• 크로스 브라우징(크로스 플랫폼)
– 벤더에 구분 및 차별 없이 모든 브라우저에서 동일한
컨텐츠를 제공할 수 있어야 한다.
– 컴퓨터만이 아닌 어떠한 단말 장치도 수용 가능
• 크로스 플랫폼

8. Microsoft Community Conference
웹 표준에 장점
• 웹 접근성 향상
– Markup Tag 본래 의미 그대로 사용
– 이미지 혹은 영상 등의 미디어 컨텐츠에 대한 대체 컨
텐츠 제공
• 상호 호환성 (크로스 브라우징)
– 다양해지고 넓어진 브라우저 종류 및 플랫폼 수용
– 물론 아직까지는 완벽하지 않음
• 구시대 브라우저에 존재 및 높은 점유율
• 브라우저들 각각에 다양한 버그 존재
– W3C 자체 토론에서 가장 치열한 주제
• HTML5, CSS3로 상당 부분 해결을 노림

9. Microsoft Community Conference
웹 표준에 장점(계속)
• 웹 생산 과정 전체적인 부분에 이점 제공
– 개발 생산성 향상
• 구조(Markup), 표현(CSS), 행동 양식(DOM, ECMA
Script)에 완벽한 구분
• 말도 많고 탈도 많은 Waterfall 개발 방법론 탈피
• Markup 코드 양 상당 부분 감소 (약 2배)
– 유지보수 비용(인력, 시간 등) 감소
• 구조를 변경하지 않는 상태로 디자인 변경 가능
• 디자인을 변경하지 않는 상태로 구조 변경 가능
• 다양한 버전에 컨텐츠 개발 가능
– SEO(Search Engine Optimization) 향상
• 확실하게 구분되는 구조, 그리고 의미에 맞는 Markup
을 사용함으로써 검색 엔진 최적화 향상

10. Microsoft Community Conference
웹 표준에 장점(계속)
• 구조와 표현, 그리고 행동 양식에 분리

11. Microsoft Community Conference
웹 표준에 대한 오해
• 화려하고 세련된 웹 사이트를 만들 수 없다?
– 텍스트 위주로 구성되고 멋없는 사이트?
• 웹 표준 및 웹 접근성 지침에는 이미지나 멀티미디어
컨텐츠 사용을 자제하라는 언급이 전혀 없음
– 이미지의 경우 CSS를 활용하여 배경(background)으로
처리해 주는 것만으로도 웹 접근성 확보
– Flash의 경우 <object> 태그 사이에 대체 텍스트 삽입만
으로도 웹 접근성 확보
• CSS Layout에 극을 볼 수 있는 필수 코스
– Zen Garden : http://www.csszengarden.com

12. Microsoft Community Conference
웹 표준에 대한 오해(계속)
• 개발 비용이 증가한다?
– 개발 과정에서 추가 비용이 발생할 이유가 없음
• 부가적인 하드웨어 및 소프트웨어가 필요하지 않음
• 전문 인력 및 리뉴얼에 대한 비용 예외
– 유지보수 측면에서는 오히려 비용 감소
• 구조와 표현 그리고 행동 양식에 완벽한 분리
– 컨텐츠 담당자는 구조와 내용에만 관심
– 디자인 담당자는 표현과 외양적 디자인에만 관심
– 프로그램 담당자는 프로그램 코드에만 관심
• 내용이 바뀌면 구조 및 디자인까지 다 고쳐야 한다거나,
디자인이 바뀌기 위해서 내용과 구조가 타협을 해야 하
는 상황 필요 없음
• 신규 담당자 입장에서도 훨씬 수월한 분석 가능

13. Microsoft Community Conference
웹 표준에 대한 오해(계속)
• 특수 계층을 위한 별도의 사이트가 필요하다?
– 소수일지도 모르는 특수 계층 사용자를 위해서?
• 웹에서 표준안에 사용과 접근성 가이드에 대한 준수 만
으로도 특수 계층을 위한 별도의 사이트는 필요 없음
• 별도의 사이트를 개발하는 것 자체가 비효율
• 표준안을 사용하고 접근성이 높은 사이트는 일반 사용
자에게도 오히려 도움을 줌
– 문서가 분명하며 이해하기 쉽기 때문에 아이들이나 노인
들에게 도움을 줄 수 있음
– 사이트 곳곳에 설명 도구(tooltip)들이 생겨서 친근감을
향상시킴

14. Microsoft Community Conference
웹 표준 스펙
• W3C에서 제공하는 웹 표준 스펙 권고안
– (X)HTML (eXtensible Hypertext markup Language)
• 웹 페이지를 표시하는 기본 언어
• 웹 페이지에 내용은 표준 HTML 포멧으로 작성되어야
하며, 독점적인 고유 포멧으로 작성되는 경우, 대체
HTML 포멧도 제공되어야 함
• 특정한 브라우저에 맞추어 제작되어서는 안되며, 클라
이언트 그룹에 의해 빈번하게 사용되는 모든 브라우저
에서 올바르게 작동해야 함
– CSS (Cascading Style Sheets)
• 사용자 정의의 디자인 속성, 즉 글꼴, 크기, 색상, 이벤트
등을 지정할 수 있으며, CSS를 사용한 모든 페이지는
기존 버전과 호환이 되도록 모든 브라우저에서 올바르
게 작동해야 함

15. Microsoft Community Conference
웹 표준 스펙(계속)
– XML (eXtensible Markup Language)
• 웹 페이지를 표시하는 기본 언어HTML이나 CSS로 표현
하지 못하는 영역을 DTD를 이용하여 사용자 정의 태그
를 생성할 수 있는 메타 마크업 언어
• 무분별한 사용을 금하고 적절한 용도에 맞게 사용
– DOM (Document Object Model)
• 웹 페이지에서 표현되는 모든 속성에 대해 객체화 하여
이를 자유 자재로 사용할 수 있도록 함
• 크게 MS DOM과 W3C DOM이 존재
– ECMA Script
• W3C 표준은 아님 (ECMA 표준)
• 모든 브라우저에서 사용이 가능하지 않다는 점 고려
• 문서에 HEAD 태그 내에 존재하여야 함

16. Microsoft Community Conference
웹 표준 DTD
• DTD (Document Type Definition) : 문서형태 정의
– 문서의 정보 모델을 구체적으로 서술
– 문서를 구성하는 정보 요소, 해당 요소의 구조와 특성
등의 문서 형태를 구조화
– 웹 브라우저에서 HTML 문서가 렌더링 되는 기준
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
DTD 문서 선언부
Markup 선언부

17. Microsoft Community Conference
웹 표준 DTD(계속)
• DTD 종류
– HTML 4.01, XHTML 1.0 기준으로 각각 3가지로 구분
• Strict, Transitional, Frameset
• Strict : 엄격한 규격
– W3C가 의도했던 문서 타입
– 표현에 관련된 태그와 속성을 배제한 문서 타입
– 근본적으로 사용해야 하는 DTD
• Transitional : 과도적인 규격
– 기존에 만들어진 문서들과의 호환성으로 위해서 제작
– 기존에 존재하는 페이지들을 한번에 Strict로 바꾸는
것이 어렵기 때문에 그 중간 단계를 구성하는 DTD

18. Microsoft Community Conference
웹 표준 DTD(계속)
• Frameset : Frame 지원
– Transitional을 기반으로 Frame 사용을 허가하는 DTD
– Frame을 제외하고는 Transitional과 동일
• XHTML 1.1
– Strict를 기반으로 재구성
– 기본적으로 사용하는 엘리먼트는 XHTML1.0과 크게
다르지 않음
– 루비요소와 가상모듈 그리고 모듈화가 되어있는
MOD파일이 리스트화 되어 있음
– Module-based-XHTML

19. Microsoft Community Conference
웹 표준 DTD(계속)
• Quirks Mode
– 비 표준 웹 페이지를 정상적으로 보여주기 위한 모드
– Quirks Mode로 동작하는 경우
• DTD를 선언하지 않았거나 잘못 선언한 경우
• DTD 선언에서 시스템 식별자를 미 지정한 경우
– Quirks Mode의 문제점
• 비 표준 모드로서 브라우저에 따라 호환 방법이 다름
– ex : IE와 다른 브라우저 간의 Box Model 해석 차이

20. Microsoft Community Conference
감사합니다!