블로그 첫페이지블로그 첫페이지 태그로그태그로그 카테고리 로그카테고리 로그 미디어 로그미디어 로그 방명록방명록 관리자관리자 글쓰기글쓰기 RSSrss

'Cross Browsing'에 해당되는 글 4건

  1. 2007/08/27 Web standards treats all alike except... 2
  2. 2007/08/24 Open site fit on Web standard 3
  3. 2007/08/24 Open site fit on Web standard 2
  4. 2007/08/24 Open site fit on Web standard 1

Web standards treats all alike except... 2

Web standards treats all alike except... 2 웹표준 잡학 2007/08/27 16:05

웹표준이라는 단어가 처음 나왔을 때, 웹표준이 무엇인지 대해서 많은분들이 의견을 나누셨습니다. 모든 브라우저에서 똑같이 보일 수 있는 표준이다, 파이어폭스와 오페라에서 제대로 보여야 웹표준이다, XHTML로 코딩을 해야 웹표준이다... 참 많은 의견이 오고갔던 것으로 기억합니다.

이제 어느 정도 정리된 의견이라면, 웹표준은 간단하게 말하면 Semantic적으로 만들어진 홈페이지를 뜻하는 말이 되었습니다. (바로 이 점이 제가 네이버 메인페이지를 웹표준적이지 않다고 말하는 근거입니다.)

한가지 문제가 있다면, 아직 웹표준이라는 것이 권고 상태라는 것이죠. 강제 상태가 아니라는 말입니다. 구글식으로 표현하면 베타판이라는 말입니다. 아직 많은 사람들이 웹표준에 대한 토론을 계속하고 있습니다.

웹표준은 아직 정해지지도 않았다는 말이지요!

이런 의미에서 접근하면, 파이어폭스나 오페라 또한 웹표준을 지키는 브라우저가 아닙니다. 현재까지 발표된 웹표준 권고안에 가장 접근한 출력결과를 보장하는 브라우저라는 표현이 맞습니다.

역으로, 인터넷 익스플로러는 웹표준을 지키지 않는 브라우저가 아닙니다. 이 말은 웹표준의 의미를 생각하시면 쉽게 이해가 되실 줄 믿습니다.

인터넷 익스플로러도 웹표준에 맞게 Semantic으로 코딩해주면 논리적으로 브라우저에 나타내줍니다. 인터넷 익스플로러가 웹표준을 지키지 않은 브라우저라면, CSS를 끄고 문서의 구조를 살펴보았을 때, 태그의 성격이 무시되어 출력되거나 (예 : H1요소와 H3요소의 글자 크기가 같다던지) 인라인 요소와 블록 요소가 혼재되어 나타나는 (예 : p요소로 묶인 문단이 각각 한줄의 공백으로 구분되지 않는다던지) 현상이 발생해야겠지요. 현실은 그렇지 않습니다. 파이어폭스, 오페라 등등, 웹표준의 필수 브라우저로 추앙받는 것들과 똑같은 결과를 나타냅니다.

많은 웹디자이너, 웹퍼블리셔들이 인터넷 익스플로러가 웹표준을 지키지 않는 근거로서 레이아웃이 깨지는 문제를 드는데, 웹표준 코딩 - HTML과 XHTML을 사용한 코딩 - 에서 레이아웃을 결정하는 유일한 방법은 CSS입니다. 이 CSS의 표현방법이 잘못된 것과, 그렇기 때문에 인터넷 익스플로러가 웹표준을 지키지 않았다는 것은 동문서답입니다. 차라리 인터넷 익스플로러때문에 크로스브라우징이 어렵게 되었다는 주장은 납득이 가는군요.

웹디자이너는, 웹퍼블리셔는, 웹표준을 따른다고 마음먹으셨다면, 그 순간부터 인터넷 익스플로러를 욕하면 안됩니다. 인터넷 익스플로러 때문에 웹디자인을 못하시겠다는 말은 더더욱 하시면 안됩니다. 어떤 브라우저에서도 잘 나타낼 수 있게, 하물며 그것이 저주받은 익스플로러라하더라도 외면해서는 안됩니다. 그것이 유일한 방법이라면, 핵을 사용해도 좋습니다.

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by stophobia

Open site fit on Web standard 3

Open site fit on Web standard 3 웹표준 실전 2007/08/24 18:45
이어, SEO와 시각장애인을 위한 접근성 대책에 대한 부분을 소개하겠습니다.

6. SEO에 최적화
메타태그의 입력방법, 헤드부분 처리는 물론, 본문의 각 요소에도 SEO처리를 해 놓았습니다. 이것도 Semantic으로 반은 먹고 들어갔습니다. 아픈 기억으로 입력방법이나 헤드처리요령 등은 설명하지 않겠습니다.

사실 검색엔진이라고 부르기엔 뭐한 네이버가 국내 검색시장을 대표하는 마당에선 제일 충실한 SEO대책은 네이버에 광고를 올리는 것이겠지만요.

7. 시각 장애인을 위한 접근성 대책
제가 사실 스크린 리더기를 사용할 기회가 없어서 이 부분은 확언을 못드리겠습니다. 하지만 웹에서 얻은 지식으로 accesskey 라던지 title의 사용을 최적화해 보았습니다. 시각장애자분들이라도 적어도 링크는 제대로 누르시지 않을까 생각합니다.

또 access단축키를 생각하면서도, 입으로 스틱을 물고 사용하시는 분들의 입장에서 어떤 키 배열이 좋을까 생각해보니, 단축키가 ALT키와 함께 쓰인다는 점에 착안해 스킨을 바꾸는 accesskey는 ALT와 가까운 곳에 있는 Z, X, C, V로 해보았습니다. 로고와 연결된 accesskey는 아마 대부분의 웹페이지가 단축키를 숫자 0이나 1로 설정해 놓지 않았을까 생각하여 익숙하신대로 쓰는게 제일 편하지 않을까 하는 마음에 1로 설정해 보았습니다. 저에게 메일을 보낼 수 있는 키는 7입니다. 행운의 7! (경험상 이래도 메일은 안오더라구요)

기획을 할 때 장애인용 키보드에 대한 자료를 찾아보았지만, 한국어로 된 자료가 많이 없었기에, 어쩔수 없이 일반 키보드를 기준으로 했습니다.

8. Semantic 구현
100% 완벽하다고는 할 수 없지만, 이전까지 제가 참고했던 어떤 웹페이지보다 더욱 Semantic에 가깝게 작업했습니다. id와 class가 의미를 가지도록 하는데 집중하였고, 이미지 파일의 이름도 용량의 범위 내에서 의미를 가지도록 신경을 써 보았습니다.

http://wis1674.dothome.co.kr/

이 사이트를 제작하면서 느낀 것이지만, 작업의 순서가 바뀌었습니다.

일단 XHTML코딩을 하고, 그 다음 디자인을 하였습니다.
이 순서의 변화가 무엇을 의미하는지 아시리라 믿습니다.

예전의 웹공정, 특히 테이블 레이아웃에서는 디자인이 나오고 나서야 코딩이 진행되었습니다. 물론 프로그래밍은 코딩이 끝난 뒤가 되니 웹제작에 시간이 걸리게 마련이었지요.

하지만, 코딩이 우선이 되면, 코딩과 디자인을 동시에 들어갈 수 있게 됩니다. 기획단계에서 레이아웃과 요소들을 결정하면, 그 다음은 퍼블리셔와 디자이너가 동시에 작업을 진행할 수 있다는 이야기가 되겠지요. 작업에 대한 패러다임까지 발전적으로 변화합니다.

다음 글부터는 XHTML제작과 CSS제작에 대해 간단히 적어보겠습니다.

읽으시느라 수고하셨습니다!!!
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by stophobia

Open site fit on Web standard 2

Open site fit on Web standard 2 웹표준 실전 2007/08/24 18:27

100% 만족하지는 않지만, 입으로만 떠드는 것을 탐탁치 않게 여기는 저이기에, 글은 이정도면 쓸만큼 써둔 것 같고, 실제로 웹표준에 입각한 사이트를 만들어보자고 해서 만든 것이 이 사이트입니다. 사이트에 명시는 해 두었지만, 절대 W3C의 밸리데이션 통과를 목적으로 만들지 않았습니다.

http://wis1674.dothome.co.kr/

일단 이 사이트 설계시의 기준 (기획이라고 하는 말이 어울리겠군요.)을 말씀드리겠습니다.

1. XHTML1.1 과 CSS 3.0기준에 맞추어 제작
실무에서는 에러방지를 위해 제일 유연성이 풍부한 HTML4.01 transitional을 쓰지만, 이 사이트는 목적 자체가 포트폴리오니만큼 제가 아는 한 "최신의 기술"을 사용하고 싶었습니다. 언제까지 최신의 기술일지는 모르겠지만... XHTML의 밸리데이션이야 분석기가 DTD를 자동으로 판별해 주니 알기 쉽지만, CSS 3.0? 지금 2.1도 안나와있는데 무슨? 하시는 분들을 위해 알려드리면, CSS 검증페이지에 가면 옵션으로 검증모드를 선택할 수 있게 되어있습니다. 여기서 원하는 검증 모드를 선택하시면 선택된 모드로 검증이 됩니다.

XHTML의 경우는 ol, ul, blockquote, fieldset, table 등등 고루 사용했습니다. Semantic에 신경쓰다보니 당연히 그렇게 되더라구요.

또한 CSS도 그냥 대충 요소를 집어넣지 않고, 모질라에서 권장하는 순서대로 적어 넣었습니다. Naver UI 팀 지침 참고 퍼포먼스에 차이가 있는지 어떤지는 모르겠지만, 있다고 해도 과연 느껴질 수준인지는 모르겠지만, 설마 순서가 괜히 있는것은 아니겠지 싶어서 말이지요.

2. UTF-8 사용
제가 외국에 살고 있어서인지는 몰라도, 여러 외국어를 한꺼번에 쓸 경우가 종종 있습니다. 영어도 되지않을뿐더러, 행여 외국의 웹에 들어가보아도, 한글을 쓸 수가 없어서 영어로 적을수 밖에 없었던 아픈 기억을 되살리면서 작업했습니다. 결정적인 이유 중의 하나는, 제가 쓰는 드림위버8이 일본어판이기 때문에 한글이 깨져서 보입니다. 그래서 utf-8모드가 아니면 한글이 제대로 나오지 않았던 이유도 있습니다.

3. 자바스크립트를 이용하여 페이지를 갱신하지 않고 외부CSS 교환
CSS를 교환하는 사이트가 꽤 되는걸로 알고 있습니다. 대표적으로 zengarden이 있지요. 하지만 CSS를 교환하기 위해서는 페이지를 갱신해야 했습니다. 이 부분을 자바스크립트를 사용하여 갱신없이 파일을 교환하도록 했습니다. "아! AJAX틱하다"하고 멋대로 생각해 버렸습니다만...
참고로 이 자바스크립트는 순수한 저의 작품은 아닙니다.

4. 1999년 9월 26일 이후 발표된 모든 브라우저에서 동일한 외관을 보장
저 날짜의 근거는 인터넷 익스플로러 5.0 버전이 네이버 자료실에 올라간 날짜를 기준으로 한 것입니다. 참고로 제가 크로스브라우징에 사용한 브라우저는

Internet Explorer 5
Internet Explorer 5.5
Internet Explorer 6
Internet Explorer 7
Firefox 2
Opera 9
Safari Beta 3 for Windows
Netscape 8
Netscape 9
Avant
Flock

이렇게 되겠습니다.
AVANT와 FLOCK이 생소하신 분들도 있으시겠지만, AVANT는 IE의 렌더링 엔진을, FLOCK은 Firefox의 렌더링 엔진을 각각 사용하고 있습니다.

이렇게 다양한 브라우저에서 테스트를 하다보니 CSS Hack이 조금 들어갔습니다. 하지만 그에 대한 주석은 생략했습니다. 일하면서 안좋은 기억이 있어서...

5. Clear Font 사용
구글 스킨(기본 스킨)을 제외한 모든 스킨은 Cleartype Font 를 사용했습니다.

한글 : 맑은 고딕체
일본어 : 명료체
영어 : Segoe UI

이유는 단지 개인적으로 예쁘게 보이기 때문에. 그리고 앞으로 비스타가 널리 보급되면 그만큼 클리어타입이 친숙하게 될텐데, 그 때를 대비해서 분위기를 미리 파악해보는 것도 좋지 않나 하는 생각에서 입니다.

다음 글에서 계속...

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by stophobia

Open site fit on Web standard 1

Open site fit on Web standard 1 웹표준 실전 2007/08/24 16:30

세월도 조금 지난 듯, 웹표준을 지켜야 된다는 글들도 이젠 어렵지 않게 보이고, 어떻게 하면 웹표준을 지킬수 있는지에 대한 글도 꽤 많이 보입니다. 웹표준이라는 단어가 이제는 개념적인 차원에 머물지 않고 실용적으로 다가오고 있음을 실감할 수 있습니다.

그렇습니다. web2.0처럼 개념적으로도, 수익모델적인 측면에서도 추상적인 의미에 머무르는 단어가 있는 반면, 웹표준은 실제 사업모델에서 고급이면서도 경제적인 웹 퍼포먼스를 보여주기 위한 도구로서 적극적으로 사용되고 있다는 뜻이겠지요.

하지만, 실제 웹표준을 표방하고 있는 사이트를 살펴보면, 사실은 HTML 또는 XHTML과 CSS만을 사용한 사이트가 대부분이라는 사실에 조금 실망하게 됩니다. (게다가 이런 사이트들은 W3C의 밸리데이션 통과마크를 꼭 걸어놓습니다. 아마 그것이 의무사항이라고 생각하고 있는지도 모르겠지만, 이부분은 W3C의 홍보부족이 아닌가 싶네요. 역으로 과다홍보일수도 있죠. 어쨌든.)

물론 XHTML과 CSS를 사용했다는 사실만으로도 매우 장족의 발전이고, 이러한 코딩이 익숙해질수록 웹표준에 상당히 가깝게 다가간다는 사실은 부정할 수 없습니다. 하지만, 매일매일 쏟아지고 있는 웹표준과 관계된 웹문서나 서점에 진열된 책의 수준과 비교해보면, 역시 아직은 웹표준이 개념적인 측면에 머물고 있지는 않은가 생각하게 됩니다.

일단 웹표준은 Semantic에 입각해야합니다. 밸리데이션 따위, 부차적인 목적이 되어도 좋습니다. 접근성도 일단 접어둡시다. Semantic만 해결하신다면, 모두 거저 얻으실 수 있습니다.
 
Hn요소가 순서대로 들어가 있는지, 사이트맵을 나타내는 웹페이지의 이름은 sitemap.html인지, 그 사이트에 링크가 걸린 이미지 버튼의 이름은 sitemap.gif인지, 각 div의 id명은 의미를 가지고 있는지, 다 생각하면서 해야합니다.

로고에 H1요소를 쓰는 것은 알고 있지만 글자를 넣어버리면 처리가 불가능해지기 때문에 글자대신 이미지를 넣어버린다던지 아예 H1요소를 빼버린 (정말... 눈물이 날 지경입니다.) 사이트, 사이트맵의 이름은 꼭 gnb05.gif 또는 top-btn05.gif인 사이트, div의 id나 class명은 어김없이 숫자나 알파벳을 순서대로 나열한 사이트...

단지 XHTML밸리데이션 통과가 목적이라면, 공부는 충분합니다. 밸리데이션 통과 마크를 얻으셨지 않습니까?

웹표준이란, 기초적인 XHTML 문법과 CSS 문법만 적어놓은 책에서는 절대로! 얻으실 수 없습니다.

또한, 웹표준과 함께 부가적으로 얻을 수 있는 여러 장점, 특히 웹접근성과 관련된 장점을 살리지 못한다는 것이 매우 유감이지요.

예를 들면 스크린 리더에서 무리없이 읽어줄 수 있는 구조인가, 입에 전용 스틱을 물고 키보드를 치시는 장애인들도 단축키를 이용하여 마우스없이 메뉴를 선택할 수 있는 구조인가, 탭을 사용하여 순차적으로 데이터를 입력할 수 있는 구조인가... 웹표준이라는 주제에 대해 생각하기 이전에는 당연히 전문가의 손길이 닿지 않으면 안되었던 이런 부분들 조차, 웹표준에 입각한 코딩이라면 어느 정도는 대책이 가능하다는 것입니다.

물론 매우 기초적인 장벽도 있습니다. 크로스브라우징이 바로 그것인데요, 인터넷익스플로러 의존도가 높은 편인 우리나라에서는 아주 최근에 문제의 심각성을 인식하고 (비스타님 감사합니다) 대책을 세워나가는 분야입니다.

인터넷익스플로러만 믿고 여기까지 왔는데(정확히 말하면 인터넷 익스플로러 6 이 되겠지만) 파이어폭스나 오페라는 그렇다치고 인터넷익스플로러 7마저 형을 배반하는 바람에 익스플로러 6과 7이 무엇이 다른지도 모르는 불쌍한 소비자들만 인터넷 뱅킹을 못하게 되는 상황이 되어버린 것 아닙니까?

서론이 길었습니다만, 저조차도 이론만 늘어놓는 것은 아니다 싶어서 (사실은 다른 목적을 가지고) 사이트를 한번 만들어 보았습니다.

http://wis1674.dothome.co.kr

다음 글에서 설명을 올리겠습니다.

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by stophobia
1 
하단 사이드바 열기