NARADESIGN:BLOG

BMW F800R 구매.

정찬명 — Wed, 05 Jun 2013 16:33:03 +0000

어린 시절부터 두 바퀴 탈것으로 모험하는 것을 즐겼는데 결국 여기까지 왔네요. 사실은 작년 2월부터 준비해 왔어요.

BMW F800R 이라는 네이키드 모델입니다. 네이키드란 경주용 바이크를 모방한 레플리카 모델(흔히 R차 또는 숑카)에서 성능은 유지하고 카울을 벗겨내고 자세를 좀 더 편하게 바꾼(레플리카보다 상체가 서는) 실용적인(?) 모델이예요. 카울이 있으면 바람 저항도 줄일 수 있고 외관도 더 미려해 지지만… 뭐랄까 멀쩡한 청바지 찢어 입는거랑 똑같은 거라고 생각하시면 돼요. 카울 없는 네이키드 모델의 유래는 바이크가 워낙 넘어지는 일이 많아서 카울을 아예 떼어버린 거라고 하네요. 유래를 알고 나서부터 더 끌렸죠.

바이크는 위험하다는 말을 많이 하는데요. 사고 발생시 치사율은 차량에 비해 2배 높은 것이 사실이지만 바이크 사고 발생률은 차량 사고 발생률의 절반 정도 밖에 되지 않아요. 바이크가 더 위험하다는 것은 통계적으로 보면 틀린 말일 수 있다는 의미입니다. 사고시 치사율 때문에 위험하다고 한다면 사실 비행기가 제일 위험한 것인데(사고=죽음) 통계적으로 교통사고 사망자 중에서 비행기 사망률이 가장 낮죠.

바이크 경력은 배기량 125cc 미만을 7년 정도 탔었고 적당히 겁을 낼 줄도 알아서 지금까지 아무 사고 없이 잘 탔습니다. 이런 말도 있어요. 바이크로 부상 당하는데까지 걸리는 시간은 평균 128년이고, 사고로 사망하기까지 걸리는 시간은 평균 3,289년 이랍니다. http://goo.gl/1D2PG 지나치게 걱정하실 필요 없어요.(위험해요. 조심해요. 이런 말을 귀에 딱지가 앉게 듣다보니)

레이어 열기/닫기 키보드 접근성.

정찬명 — Wed, 24 Apr 2013 00:27:57 +0000

일반적으로 레이어 열기/닫기 인터페이스는 다음과 같은 방식으로 처리하고는 하죠. 하지만 보통은 키보드 접근성 문제가 발생합니다.

통상적인 레이어 열기/닫기 예: http://codepen.io/naradesign/pen/eynbo

레이어 열기/닫기 UI의 키보드 접근성 문제

레이어가 열리는 순간 초점 순서 오류: 앵커를 클릭 또는 엔터를 입력한 이후에 키보드 초점은 여전히 앵커에 머물러 있습니다. 열린 레이어로 키보드 초점이 이동해야 하는데 인위적으로 초점을 옮겨주지 않으면 여전히 앵커에 초점이 머뭅니다. 열리는 레이어가 앵커 바로 다음에 등장하는 경우라면 순서에 문제가 없지만 앵커와 레이어가 서로 다른 위치에 존재하는 경우 인위적으로 초점을 옮겨주지 않으면 키보드 초점은 엉뚱한 곳을 탐색하게 되므로 오류에 빠지게 됩니다. 모든 브라우저가 이렇게 동작합니다.
레이어가 닫히는 순간 키보드 트랩: 열린 레이어를 닫으려고 레이어 닫기 버튼을 클릭하거나 엔터를 입력하면 레이어가 사라져 버리기 때문에 키보드 초점은 페이지 처음으로 돌아가 버리는 브라우저가 있습니다. IE 6~10 브라우저가 이렇게 동작합니다. 대부분의 표준 브라우저들은 닫힌 레이어 이후부터 키보드 초점을 받을 수 있도록 정상적으로 처리합니다.

레이어가 열리는 순간 초점 순서를 바로잡는 방법

키보드 초점을 논리적인 순서대로 진행하도록 만들기 위해 앵커 클릭 후 레이어가 열리는 순간 초점을 레이어로 옮기는 예시를 만들어 봤습니다.

앵커 클릭하면 레이어로 초점 옮기기: http://codepen.io/naradesign/pen/brwuj

앵커를 클릭하면 타겟 레이어에 tabindex=”0″ 속성이 들어가면서 초점을 받을 수 있는 상태가 된다.
레이어의 상태를 display:block 으로 만든다.
레이어에 focus를 넣는다.

이렇게 처리하면 앵커와 레이어 중간에 존재하는 엉뚱한 맥락의 다른 콘텐츠를 탐색하게 되는 키보드 초점 오류를 방지할 수 있습니다. 하지만 문제는 여전히 존재합니다. 레이어를 닫을 때 초점이 머물던 요소가 사라지면서 IE 6~10 브라우저는 키보드 초점을 페이지 맨 처음으로 돌려놓습니다. 이것 때문에 키보드 트랩에 빠지게 되는 것입니다. 레이어 이후의 항목을 탐색할 수 없게 되는 문제가 발생합니다.

레이어가 닫히는 순간 키보드 트랩에서 빠져나오기

이 문제를 해결하려면 레이어가 닫힐 때 논리적으로 납득할만한 위치로 초점을 옮겨야만 했습니다. 대부분의 최신 브라우저들(크롬, 파이어폭스, 사파리, 오페라)은 키보드 초점이 머물던 요소가 사라지는 경우 레이어 이후의 맥락을 탐색할 수 있도록 키보드 초점이 자연스럽게 처리가 됩니다. 하지만 IE 6~10 브라우저는 그렇지 못했기 때문에 문제가 됩니다. 또한 레이어의 위치가 문맥에 맞지 않게 엉뚱한 곳에서 펼쳐지는 경우에는 표준 브라우저도 여전히 엉뚱한 위치로부터 탐색을 시작하기 때문에 문제가 됩니다.

자바스크립트 내공이 없어서 이 문제를 끙끙 앓다가 트위터와 페이스북에 도움을 요청했는데요. 몇몇 지인 분들께서 제가 작성한 코드를 보완해 주셨습니다. 레이어를 닫을 때 레이어를 열었던 앵커로 초점을 옮겨주는 방식입니다.

정답이 없는 문제이기 때문에 어떤 코드가 좋고 나쁘다고 단적으로 말하기는 어렵습니다. 다만 제가 고민하던 문제를 어떤 방법으로든 해결했다는 것이 더 중요한 것 같네요. 문제를 함께 해결해 주신 여러분께 진심으로 감사드립니다.

만약 여러분이라면 이 문제를 어떻게 해결하시겠어요? 직접 코드로 보여주시면 더 좋구요.

참고 ^{2013-05-29 업데이트}

키보드 접근성을 보장한 모달 다이얼로그 데모도 참고로 보세요. http://webhipster.com/testing/accessibility/modal-dialog-latest/

CSS Quiz – 화면을 가득 채우는 격자 그리기.

정찬명 — Wed, 24 Oct 2012 14:17:27 +0000

몇 일 전에 냈던 “가장 많은 수평선 그리기” 퀴즈는 아직도 진행 중입니다. 물론 전의를 상실할만큼 빠르게 정답(?)에 근접한 댓글들이 제출돼서 김이 조금 새기는 했지만요. 컨닝 얼마든지 하셔도 괜찮아요. 코드를 더 짧게 줄일 수 있다면 말이죠. 저도 퀴즈 내고 여러분의 댓글 보면서 많이 배우고 있습니다. 그래서 하나 더 준비 했습니다.

이번에는 격자 그리기 입니다. 지난 퀴즈의 답을 보면서 이것도 쉽게 가능하겠다는 생각을 했습니다.

도전 과제

CSS만을 사용하여 화면을 가득 채우는 격자를 그려주세요. body 요소 내부에는 다른 html 코드가 존재하지 않아야 합니다.
격자의 규격은 한 셀의 크기가 가로 10px, 세로 10px 이어야 합니다. 셀의 내부 색상은 흰색입니다.
격자 선의 두께는 1px이며 색상에 대한 규칙은 없습니다.
이미지(base64 인코딩 이미지 포함)는 사용할 수 없습니다.
정답은 CSS 코드를 포함하여 댓글로 제출해 주세요.
정답은 크롬 브라우저 최신버전에서 확인할께요.
똑같은 답을 제출하지 않는다면 컨닝해도 됩니다.
정답을 여러번 제출해도 됩니다.
정답자가 여러명인 경우 압축(공백 제거, 줄바꿈)된 코드의 양이 적은 분을 최고의 정답으로 간주할께요. 파일 압축하기.
제출 기간: 2012년 12월 31일

최고의 답변을 제출해 주신 분께는 ‘커피, 밥, 술‘ 가운데 원하는 것을 쏠께요.

어디서부터 시작해야 할지 모르겠다면 지난 퀴즈 “가장 많은 수평선 그리기“를 참고해 보세요.

이번에도 기대할께요. ^___^

[저는 현재 209byte로 완성했습니다. 이번에도 이게 최선이 아니겠죠? ㅡㅡ;]

CSS Quiz – 가장 많은 수평선 그리기.

정찬명 — Mon, 22 Oct 2012 10:32:31 +0000

제가 요즈음 풀고 있는 정답 없는 문제가 하나 있는데요. 여러분도 한번 도전해 보시겠어요?

도전 과제

아래 제시된 HTML 코드를 기반으로 CSS만을 사용해서 가장 많은 수평선을 그려보세요.
하나의 행에는 100% 너비를 지닌 하나의 라인만 유효합니다. 선의 두께에 관한 기준은 없습니다.
선과 선 사이에는 흰색 선이 반드시 포함되어 있어야 합니다. 이 구분 선은 개수로 세지 않겠습니다.
이미지(base64 인코딩 이미지 포함)는 사용할 수 없습니다.
순수 CSS 코드 용량은 압축(공백과 줄 바꿈 제거)된 것을 기준으로 1KB(1024byte)를 초과하면 안됩니다.
작성한 CSS 코드는 이 포스트의 댓글로 제출해 주세요.
제출된 답은 크롬 브라우저 최신 버전에서 화면 확대 기능을 사용하지 않은 상태로 확인하겠습니다.
정답 제출 횟수는 제한이 없습니다. 여러번 제출해도 됩니다.
가장 많은 선을 그린 정답 제출자에게는 제가 ‘커피, 밥, 술‘ 가운데 원하는 것을 쏠께요.
정답자 가운데 1등이 두 명인 경우 CSS 코드를 압축(공백과 줄 바꿈 제거)한 결과 용량이 더 적은 분을 최고의 정답자로 인정할께요.
정답 제출 기한 2012년 12월 31일 까지.

HTML 코드

CSS Quiz – 가장 많은 수평선 그리기

CSS 정답 제출 예시

html,
body,
body:before,
body:after { content:”"; display:block; border:30px double #000; border-left:0; border-right:0; padding:10px 0 0 0; margin:0 0 10px 0 }

예시 코드는 이 문제를 생각하면서 처음 작성해 본 코드로 16개의 수평선을 그려냅니다. 저를 가볍게 뛰어 넘어주실 분을 찾습니다.

DEVIEW 2012 반응형 웹 구축기

정찬명 — Thu, 20 Sep 2012 01:54:07 +0000

DEVIEW는 올해로 다섯번째 열리는 NHN의 기술 공유 컨퍼런스입니다. NHN 뿐만 아니라 한국의 포털과 글로벌 IT 기업들이 연사로 나서며 함께 준비했구요. 한국 IT와 함께 성장하기를 바라는 취지로 매년 무료로 진행하고 있습니다. 유사한 행사로는 DAUM DevOn, KTH H3가 있습니다. 다음이 주최하는 DevOn은 2012.10.12(금)에 열릴 예정이구요. KTH의 H3 행사도 준비가 되고 있다니 올해가 지나기 전에 열릴것(작년에는 11월 말에 열림)으로 보입니다. 만약 DEVIEW에 참석하지 못하셨다면 DevOn, H3 행사에 한 번쯤 꼭 참석하길 권합니다. IT 기업들의 최근 화제가 무엇인지도 알 수 있고 스피커들의 원맨쇼(?) 그리고 공대생 개그에 함께 웃을 수 있으니 좋은 자극이 될꺼라고 생각합니다.(저는 공대생이 아니지만 ㅎㅎ)

지난 DEVIEW 2009년도에는 ‘XE 스킨 제작 가이드’라는 주제를 가지고 발표자로 참여했었는데요. 올해는 ‘DEVIEW 2012 반응형 웹 구축기‘ 라는 주제를 가지고 두 번째로 참여하게 됐습니다. 발표자로 지원할 당시에는 ‘지금 하는 일도 바쁜데 괜히 나서는것 아닐까?’ 고민을 했는데요. 막상 발표자로 등록하고 DEVIEW 참가 신청자들의 시간표 등록 현황을 보니 800분께서 제 세션을 듣겠다고 선택해 주셨더라구요. 결국 250명 규모에서 500명 규모의 C 트랙으로 옮겨져서 가장 마지막 세션으로 진행이 됐습니다.

반응형 웹은 작년부터 ‘XE 관리자 페이지, 헬로월드 블로그, DEVIEW’ 개발을 진행하면서 실무에 적용을 해왔고 이번 발표에서는 반응형 웹을 구축하면서 격은 시행착오들을 총정리 해야겠다는 생각으로 준비했습니다. 발표 주제에 맞게 프리젠테이션도 반응형 웹으로 제작을 했고 제 발표를 듣지 않은 분들께도 실무를 진행할 때 충분한 레퍼런스가 될 수 있도록 작성하려고 노력했습니다.

DEVIEW 2012 반응형 웹 구축기
발표자료 - http://naradesign.net/rwd/pr/
발표영상 – http://goo.gl/fuLBJ

끝으로 제 발표를 들어주신 분들께서 블로그에 후기를 남기며 적어주신 글들을 몇 글자 인용할께요.

PC, 모바일 안에서도 보여질 수 있는 모습이 모두 다른 지금, 앞으로는 그 형태가 더욱 다양해 질 것이다. 요즘 화두가 되고 있는 반응형 웹! 미디어 쿼리와 함께 반응형 웹을 구축하기 위한 디테일한 내용을 소개한다. 이에 실패를 극복해 나가는 경험담이 많은 도움이 되었고, 미디어쿼리에 대한 필요성을 느끼게 했다. 현실적으로 가장 유익했던 세션!

[출처] Deview 2012 : 데뷰 2012 컨퍼런스 후기 | 작성자: 미쎄 - http://catchthedesign.com/10147987610

반응형 웹에 대해 회사에서 사내세미나로 한번, 외부세미나로 한번, 이번이 세번째. 이건 해보지 않으면 절대 내것이 안될거다. 그래도 하도 필요한거라 들었다. 현재의 웹은 더이상 데스크탑이 아닌 다양한 단말이다. 그것은 미래에는 더 심화될 것이고. 그것에 대응하는 방법. 그리고 그렇게 대응하더라도 브라우저의 종류와 버전은 끊임없이 정말 끊임없이 예외를 만드는데, 이 강연의 느낌이 어땠냐면 “근데 이러면 이게 안먹어서, 그래서 이렇게 했어요… 근데 이러면 또 이게 안먹어요.. 그럼 이건 이렇게 하구요” x 100 이었다. 지겨웠다는게 아니라, 나같으면 x 3 에서 이미 미추어버렸을 텐데, 그걸 다부지게 계속 하는 사람이 있다는게 놀라웠다. 그건 끈기만으로 되는 것은 아니고, 어디를 어떻게 테스트해야 할지 판단을 가능케 해줄 탄탄한 기본 개념(+머리;;)가 중요하지 않을까, 라는 생각을 했다.

[출처] DEVIEW 2012 후기 | 작성자: 슈가루이 - http://blog.naver.com/sugarui/110147762860

반응형 웹을 구축하면서 생겼던 모든 이슈를 총망라한 발표였다. 반응형 웹이라 해서 단순히 미디어쿼리 정도 설명하겠구나 생각했는데, 정말 디테일하게 성능 그리고 이미지 스프라이트, 웹폰트, 뷰포트 등등 많은 내용을 이야기하였다. 그 중 중요했다고 생각하는 내용은 반응형 웹은 하나의 웹(One HTML)이라는 내용과 PC 5초 모바일 6초를 넘어간다면 차라리 반응형을 하지 마라 이다.

[출처] DEVIEW2012 후기 | Yeongil’s Blog - http://yeongil.info/archives/46

- Mobile First
- web font 되도록이면 사용하지 않되, 사용할거라면 제대로 분기사용하자. (용량이 2메가다)
- 생각해야할 게 매우 많다.
- 그냥 평소에 front-end로 responsive web design에 대해 한번쯤 생각해봤고, 실제로 구현해봤으면 다 알만한 내용.
- media query를 어떻게 써줘야 하며, 뷰포트 어떻게 해줘야되고, 모바일 레이아웃 어떻게 짜고, 뭐 그런것들.
- ppt를 참고하자. 링크는 나라디자인 가면 있지 않을까.

[출처] redpotato - http://www.cyworld.com/radpotato/6216207

이렇게 인용되는 것을 원치 않으시는 분께서는 제게 메일(dece24앳gmail.com)을 보내주시면 삭제해 드리겠습니다. 후기를 남겨주셔서 고맙습니다.

웹 폰트 문제 해결. @font-face troubleshooting.

정찬명 — Mon, 18 Jun 2012 15:25:16 +0000

@font-face 규칙은 CSS3에 새로 추가된 웹 글꼴 명세입니다. 표시하려고 하는 글꼴이 시스템에 없는 경우 웹 서버에서 글꼴을 내려받아 화면에 표시해 주는 방법인데요. 마이크로소프트가 독자적으로 IE 6~8 브라우저에 지원하던 명세였는데 W3C에 제안하여 현재 CSS3 표준 초안이 되었습니다. 그러나 현실에서 사용하려면 다음과 같은 몇 가지 문제를 확실히 알고 있어야 합니다.

IE 6~8 브라우저는 *.eot 형식의 글꼴만 지원한다. 하지만 W3C가 권장하는 형식은 *.woff 이다. IE 9 브라우저는 *.eot 형식과 *.woff 글꼴을 모두 지원한다.
Chrome, Safari, Firefox, Opera 최신 버전 브라우저는 *.woff 형식을 지원하지만 *.eot 형식은 지원하지 않는다. 결국 모든 브라우저를 지원하기 위해 *.woff 형식과 *.eot 형식을 함께 준비해야 한다.
표준과 비표준 글꼴을 모두 지원하기 위해 @font-face 규칙을 두 번 사용하는 경우 IE 6~9 브라우저는 *.woff 형식과 *.eot 형식을 모두 내려받아 성능에 좋지 않은 영향을 준다.
@media 구문 안쪽에서 @font-face 규칙을 사용하는 경우 IE 9 브라우저는 글꼴을 요청하지 않는다.

하나의 글꼴에 @font-face 규칙은 한 번만 선언

eot 형식과 woff 형식을 모두 사용해야 한다는 사실을 알고 나면 하나의 글꼴을 모든 브라우저에서 표시하기 위해 @font-face 규칙을 두 번 선언할 수 있습니다. 그러나 이런 방식은 시스템 글꼴이 없는 경우 IE 6~9 브라우저에서 eot 형식 외에 woff 형식도 요청하기 때문에 사용자는 불필요한 1MB 미만의 파일을 추가로 내려받는 샘이 됩니다.

/* Not recommended */
@font-face{font-family:ngwoff; src:url(NanumGothic.woff)}
@font-face{font-family:ngeot; src:url(NanumGothic.eot)}
body{font-family:나눔고딕, NanumGothic, ngwoff, ngeot}

위 코드는 더 나은 성능을 위하여 다음과 같이 개선할 수 있습니다. Paul Irish가 제안한 방탄 코드 입니다.

/* Recommended */
@font-face{
font-family:ng;
src:url(NanumGothic.eot);
src:local(※), url(NanumGothic.woff) format(‘woff’)
}
body{font-family:나눔고딕, NanumGothic, ng}

이 코드는 추가 설명이 필요합니다.

ng 라는 글꼴 이름을 한 번만 선언한 다음 eot 형식과 woff 형식을 순차적으로 참조 했습니다.
IE 6~8 브라우저는 eot 글꼴만 요청해서 화면에 표시합니다. eot 형식을 woff 형식보다 먼저 참조해야 합니다.
IE 9 브라우저와 Chrome, Safari, Firefox, Opera 브라우저는 woff 글꼴만 요청해서 화면에 표시합니다. @font-face 명세에 따르면 eot 글꼴에 대한 format(‘embeded-opentyep’) 선언이 없기 때문에 브라우저가 eot 글꼴을 내려받아야 하지만 영리하게도 내려받지 않습니다.
local(※) 값은 외부 자원을 참조하기 이전에 시스템 글꼴을 우선 참조할 수 있도록 만들어 줍니다. 그러나 이 코드에서는 IE 6~8 브라우저가 local() 값을 처리하지 못하는 특징을 이용하여 woff 글꼴을 추가로 요청하지 않도록 해 줍니다.
local(※) 값의 괄호 안쪽에 포함된 ※ 기호는 사용자 시스템에 존재하지 않을만한 글꼴을 임의로 지정한 것입니다. 굳이 2 byte 짜리 특수문자를 사용한 이유는 Mac OS 에서 2 byte 짜리 문자열로 된 시스템 글꼴 이름은 아예 처리하지 않기 때문입니다.
format(‘woff’) 값을 명시적으로 작성하면 이 형식을 지원하는 브라우저만 글꼴을 내려받게 되어 있습니다. 값은 반드시 홀따옴표 또는 쌍따옴표 안에 있어야 합니다. 작성하지 않는 경우 지원 여부에 무관하게 모든 형식의 글꼴을 내려받는것이 명세입니다. 글꼴을 지원하지 않으면서도 내려받는 상황을 예방하기 위해 이 형식을 지원하는 경우에만 외부 글꼴을 내려받도록 명시적으로 코드를 작성한 것입니다. IE 7~8 브라우저는 이 코드를 해석하지 못하기 때문에 woff 글꼴을 추가로 요청하지 않도록 만들지만 여기서 그것이 목적은 아닙니다.
나눔고딕 시스템 글꼴의 이름을 한글과 영문으로 연거푸 두 번 적은 이유는 영문으로만 작성했을 때 제대로 표시하지 못하는 브라우저가 있기 때문입니다. 한글 이름이 있는 글꼴은 한글과 영문 모두 작성하는 것이 좋습니다.

IE 9은 @media 규칙 내부에 @font-face 허용 안함

다음과 같이 @media 구문 안쪽에 @font-face 규칙을 선언하는 경우 IE 9 브라우저는 외부 글꼴을 요청하지 않기 때문에 표시하지 못합니다. 아래 예제는 Paul Irish가 제안한 방탄 코드를 수정하지 않고 그냥 미디어쿼리 구문 안쪽에 넣었습니다.

/* IE 9 does not support @font-face within @media */
@media all and (min-width:768px) {
@font-face{
font-family:ng;
src:url(NanumGothic.eot);
src:local(※), url(NanumGothic.woff) format(‘woff’)
}
body{font-family:나눔고딕, NanumGothic, ng}
}

처음에는 이 현상이 유일하게 IE 9에만 발생하여 IE 9 버그인줄 알았는데 자세히 알고 보니 IE 9 브라우저만 CSS 2.1 명세에 잘 따른 것이었습니다. CSS 2.1 명세에 따르면 @media 규칙 내부의 또 다른 규칙인 @font-face는 유효하지 않다는 것입니다. 하지만 IE 9을 제외한 모든 브라우저는 이 명세에 따르지 않습니다. 이런 형식의 코드를 이용하면 WiFi/3G 망을 사용하는 좁은 해상도의 모바일 장치에서는 웹 글꼴을 내려받지 않아도 되기 때문에 모바일 성능 향상에 도움이 됩니다. 반응형 웹을 구현하기 위해 누구나 한 번쯤 생각할 수 있는 코드입니다.

CSS 2.1의 @media 명세를 잘 지킨 IE 9 브라우저가 오히려 웹 글꼴을 표시하지 못하는 것은 문제입니다. 이 문제는 @font-face 규칙을 미디어쿼리 밖에 선언함으로써 간단하게 해결할 수 있습니다.

/* IE 9 does not support @font-face within @media */
@font-face{
font-family:ng;
src:url(NanumGothic.eot);
src:local(※), url(NanumGothic.woff) format(‘woff’)
}
@media all and (min-width:768px) {
body{font-family:나눔고딕, NanumGothic, ng}
}

참고

이 포스트와 관련된 문제를 확인하기 위해 작성했던 테스트 케이스 입니다. http://naradesign.net/css3/font-face/ IE 9 브라우저가 CSS 2.1 @media 규칙 명세를 잘 따르기는 했지만 이번에는 오히려 따르지 않는편이 더 좋을뻔 했군요.

IE 6~8 브라우저의 미디어쿼리 규칙을 지원하기 위해 respond.min.js 파일을 사용하는 동시에 미디어쿼리 구문 안쪽에 @font-face 규칙을 추가하는 경우가 있습니다. 이런 경우 IE 9 브라우저에서 개발자 도구(F12)를 이용하여 브라우저 모드와 문서 모드를 IE 8 으로 설정하면 웹 글꼴을 무한 반복 요청하다가 브라우저가 종료되는 문제가 있었습니다. 그러나 실제 IE 8 브라우저에서는 이런 증상이 재현되지 않는것을 확인 했습니다.

CSS3 미디어쿼리 이해

정찬명 — Wed, 30 May 2012 02:15:52 +0000

출력 장치의 여러 특징 가운데 일부를 참조하여 CSS 코드를 분기 처리함으로써 하나의 HTML 소스가 여러가지 뷰를 갖도록 구현할 수 있는 명세이다. 일반적으로 뷰포트 해상도에 따라 CSS 코드를 분기한다.

CSS 코드 내부에서 분기하는 방법

CSS 코드 내부에서 사용하는 미디어 쿼리의 기본적인 문법 예는 다음과 같다. 일반적으로 권장하고 널리 쓰이는 방식이다.

@media only all and (조건문) {실행문}

@media: 미디어 쿼리가 시작됨을 선언한다. @media, only, all, and, (조건문) 사이에 포함되어 있는 공백은 필수적이다.
only: only 키워드는 미디어 쿼리를 지원하는 사용자 에이전트만 미디어 쿼리 구문을 해석하라는 명령이며 생략 가능하다. 생략했을 때 기본 값은 only로 처리 된다. 생략해도 무방하므로 이 키워드는 일반적으로 작성하지 않는다. 이 자리에는 not 키워드를 사용할 수 있는데 뒤에 오는 모든 조건을 부정하는 연산을 한다.
all: all 키워드는 미디어 쿼리를 해석해야 할 대상 미디어를 선언한 것이다. all 이면 모든 미디어가 이 구문을 해석해야 한다. all 키워드 대신 screen 또는 print와 같은 특정 미디어를 구체적으로 언급할 수도 있다. all 키워드는 생략 가능하고 생략했을 때 기본 값은 all 으로 처리된다. 이 밖에도 다양한 미디어 타입(all, aural, braille, embossed, handheld, print, projection, screen, speech, tty, tv)이 있다. all, screen, print를 가장 널리 쓴다.
and: and 키워드는 논리적으로 ‘AND’ 연산을 수행하여 앞과 뒤의 조건을 모두 만족해야 한다는 것을 의미한다. 조건이 유일하거나 또는 only, all과 같은 선행 키워드가 생략되면 and 키워드는 사용하지 말아야 한다. and 대신 콤마 ‘,’ 기호를 사용하면 ‘OR’ 연산을 수행한다. ‘OR’ 연산은 나열된 조건 중에서 하나만 참이어도 {실행문}을 해석한다. OR 조건을 위한 콤마 ‘,’ 기호 사용시 유의점.
(조건문): 브라우저는 조건문이 참일때{실행문}을 처리하고 거짓일 때 무시한다. 조건문은 두 가지 이상 등장할 수 있다. 둘 이상의 조건문은 ‘and’ 키워드 또는 콤마 ‘,’ 기호로 연결해야 한다.
{실행문}: 일반적인 CSS 코드를 이 괄호 안에 작성한다. 브라우저는 (조건문)이 참일때 실행문 안쪽에 있는 CSS 코드를 해석한다.

CSS 코드 외부에서 분기하는 방법

조건문에 따라 별도의 외부 CSS 파일을 참조하여 분기하는 방법은 다음과 같다. 이 방식은 성능 최적화 측면에서 권장하지 않는다.

데스크탑 브라우저 사용자가 언제든 조건을 변경(예를 들면 창 크기를 조절해서 해상도를 바꿈)할 수 있기 때문에 웹 브라우저는 조건에 관계 없이 A.css 파일과 B.css 파일을 항상 요청한다. HTTP 요청을 불필요하게 두 번 발생시켜 이 페이지를 처음 로딩하는 사용자에게는 성능 저하의 원인이 된다. CSS 파일은 하나로 병합하고 CSS 코드 내부에서 조건 분기하는 방식을 권장한다.

미디어 쿼리 코드 템플릿

아래 코드는 모든 해상도를 커버하기 위한 미디어 쿼리 코드 템플릿이다. All, Mobile, Tablet, Desktop 으로 기기별 대응 코드를 분류 했지만 Liquid 레이아웃 기법을 사용하면 사실상 모든 해상도를 커버할 수 있다.

@charset “utf-8″;

/* All Device */
모든 해상도를 위한 공통 코드를 작성한다. 모든 해상도에서 이 코드가 실행됨.

/* Mobile Device */
768px 미만 해상도의 모바일 기기를 위한 코드를 작성한다. 모든 해상도에서 이 코드가 실행됨. 미디어 쿼리를 지원하지 않는 모바일 기기를 위해 미디어 쿼리 구문을 사용하지 않는다.

/* Tablet & Desktop Device */
@media all and (min-width:768px) {
사용자 해상도가 768px 이상일 때 이 코드가 실행됨. 테블릿과 데스크톱의 공통 코드를 작성한다.
}

/* Tablet Device */
@media all and (min-width:768px) and (max-width:1024px) {
사용자 해상도가 768px 이상이고 1024px 이하일 때 이 코드가 실행됨. 아이패드 또는 비교적 작은 해상도의 랩탑이나 데스크톱에 대응하는 코드를 작성한다.
}

/* Desktop Device */
@media all and (min-width:1025px) {
사용자 해상도가 1025px 이상일 때 이 코드가 실행됨. 1025px 이상의 랩탑 또는 데스크톱에 대응하는 코드를 작성한다.
}

조건문이 될 수 있는 특징들

width / height

뷰포트의 너비와 높이. 뷰포트의 크기는 HTML body 콘텐츠를 표시하는 영역으로 실제 스크린의 크기와는 다르다. 반응형 웹 구현시 가장 일반적으로 사용하는 조건이 된다.

Value:
Applies to: visual and tactile media types
Accepts min/max prefixes: yes

Example:

@media all and (min-width:768px) and (max-width:1024px) { … } // 뷰포트 너비가 768px 이상 ‘그리고’ 1024px 이하이면 실행

@media all and (width:768px), (width:1024px) { … } // 뷰포트 너비가 768px 이거나 ‘또는’ 1024px 이면 실행

@media not all and (min-width:768px) and (max-width:1024px) { … } // 뷰포트 너비가 768px 이상 ‘그리고’ 1024px 이하가 ‘아니면’ 실행

device-width / device-height

스크린의 너비와 높이. 스크린은 출력 장치가 픽셀을 표시할 수 있는 모든 영역으로 일반적으로 HTML body 콘텐츠를 표시하는 뷰포트 보다 크다.

Value:
Applies to: visual and tactile media types
Accepts min/max prefixes: yes

Example:

@media all and (device-width:320px) and (device-height:480px) { … } // 스크린 너비가 320px ‘그리고’ 높이가 480px 이면 실행

@media all and (min-device-width:320px) and (min-device-height:480px) { … } // 스크린 너비가 최소 320px 이상 ‘그리고’ 높이가 최소 480px 이상이면 실행

orientation

뷰포트의 너비와 높이 비율을 이용하여 세로 모드인지 가로 모드인지를 판단한다.

Value: portrait | landscape
Applies to: bitmap media types
Accepts min/max prefixes: no

Example:

@media all and (orientation:portrait) { … } // 세로 모드. 뷰포트의 높이가 너비에 비해 상대적으로 크면 실행

@media all and (orientation:landscape) { … } // 가로 모드. 뷰포트의 너비가 높이에 비해 상대적으로 크면 실행

aspect-ratio

뷰포트의 너비와 높이에 대한 비율. ‘너비/높이’ 순으로 조건을 작성한다. min/max 접두사를 사용하면 너비 값의 최소/최대 비율을 정할 수 있다.

Value:
Applies to: bitmat media types
Accepts min/max prefixes: yes

Example:

@media all and (aspect-ratio:5/4) { … } // 뷰포트 너비가 5, 높이가 4 비율이면 실행

@media all and (min-aspect-ratio:5/4) { … } // 뷰포트 너비가 5/4 비율 이상이면 실행

@media all and (max-aspect-ratio:5/4) { … } // 뷰포트 너비가 5/4 비율 이하면 실행

device-aspect-ratio

스크린의 너비와 높이에 대한 비율. ‘너비/높이’ 순으로 조건을 작성한다. min/max 접두사를 사용하면 너비 값의 최소/대최 비율을 정할 수 있다.

Value:
Applies to: bitmap media types
Accepts min/max prefixes: yes

Example:

@media all and (device-aspect-ratio:5/4) { … } // 스크린 너비가 5, 높이가 4 비율이면 실행

@media all and (min-device-aspect-ratio:5/4) { … } // 스크린 너비가 5/4 비율 이상이면 실행

@media all and (max-device-aspect-ratio:5/4) { … } // 스크린 너비가 5/4 비율 이하면 실행

color

출력 장치의 색상에 대한 비트 수. 출력 장치가 컬러가 아닌 경우 ’0′의 값에 대응한다.

Value:
Applies to: visual media types
Accepts min/max prefixes: yes

Example:

@media all and (color) { … } // 출력 장치가 컬러를 지원하면 실행

@media all and (color:0) { … } // 출력 장치가 컬러가 아니면 실행

@media all and (color:8) { … } // 출력 장치가 8비트 색상이면 실행

@media all and (min-color:8) { … } // 출력 장치가 8비트 이상 색상이면 실행

@media all and (max-color:8) { … } // 출력 장치가 8비트 이하 색상이면 실행

color-index

출력 장치가 색상 색인 테이블을 사용하는 경우 표현할 수 있는 색의 수. 출력 장치가 색상 색인 테이블을 사용하지 않으면 ’0′의 값에 대응한다. 현재 제대로 지원하는 브라우저가 없다.

Value:
Applies to: visual media types
Accepts min/max prefixes: yes

Example:

@media all and (color-index) { … } // 출력 장치가 색상 색인 테이블을 사용하면 실행

@media all and (color-index:0) { … } // 출력 장치가 색상 색인 테이블을 사용하지 않으면 실행

@media all and (color-index:256) { … } // 출력 장치가 256 색을 지원하면 실행

@media all and (min-color-index:256) { … } // 출력 장치가 256 이상 색을 지원하면 실행

@media all and (max-color-index:256) { … } // 출력 장치가 256 이하 색을 지원하면 실행

monochrome

출력 장치가 흑백인 경우 픽셀당 비트 수. 출력 장치가 흑백이 아니라면 ’0′의 값에 대응한다.

Value:
Applies to: visual media types
Accepts min/max prefixes: yes

Example:

@media all and (monochrome) { … } // 출력 장치가 흑백이면 실행

@media all and (monochrome:0) { … } // 출력 장치가 흑백이 아니면 실행

@media all and (min-monochrome:2) { … } // 출력 장치가 흑백이고 2비트 이상이면 실행

@media all and (max-monochrome:2) { … } // 출력 장치가 흑백이고 2비트 이하이면 실행

resolution

출력 장치의 해상력에 대응한다. min/max 접두사는 사각형 아닌 픽셀(인쇄 장치)에도 대응하지만 접두사 없는 resolution 조건은 사각형 픽셀에만 대응한다. 조건의 값으로 dpi와 dpcm 단위를 사용할 수 있다.

Value:
Applies to: bitmap media types
Accepts min/max prefixes: yes

Example:

@media all and (resolution:96dpi) { … } // 1인치당 96개의 사각형 화소를 제공하면 실행

@media all and (min-resolution:96dpi) { … } // 1인치당 96개 이상의 화소를 제공하면 실행

@media all and (max-resolution:96dpi) { … } // 1인치당 96개 이하의 화소를 제공하면 실행

scan

TV의 스캔 방식에 따라 대응한다. progressive 값은 초당 60회 수준의 고화질 스캔에 대응하고 interlace 값은 초당 30회 수준의 일반 스캔에 대응한다. 대부분의 HDTV는 progressive와 interlace 방식을 모두 지원하고 있다.

Value: progressive | interlace
Applies to: “tv” media types
Accepts min/max prefixes: no

Example:

@media tv and (scan:progressive) { … } // 초당 60회 수준의 고화질 스캔 방식 TV에 대응한다

@media tv and (scan:interlace) { … } // 초당 30회 수준의 일반 스캔 방식 TV에 대응한다

grid

출력 장치가 그리드 방식이면 대응한다. 그리드 방식은 타자기와 같이 고정된 글꼴만 사용하는 장치이다. 통상 출력 장치는 비트맵이 아니면 그리드 방식이다. 값은 정수 ’0′과 ’1′ 뿐이고 ’0′의 값은 비트맵 방식에 대응한다.

Value: 0 | 1
Applies to: visual and tactile media types
Accepts min/max prefixes: no

Example:

@media all and (grid) { … } // 출력 장치가 그리드 방식이면 실행

@media all and (grid:0) { … } // 출력 장치가 그리드 방식이 아니면 실행

@media all and (grid:1) { … } // 출력 장치가 그리드 방식이면 실행

CSS를 사용한 썸네일 크게 보기.

정찬명 — Fri, 25 May 2012 04:43:13 +0000

어제 지인 한 분이 CSS만을 사용해서 썸네일을 크게 볼 수 있는 기능 구현 가능한지를 묻더라구요. 그래서 아래와 같이 구현해 봤습니다.

예제를 새 창에서 보기. 소스 코드는 다음과 같습니다.

CSS를 사용한 썸네일 크게 보기.

IE6 브라우저에서는 동작 안합니다. 자바스크립트를 사용하지 않고 IE6 브라우저에서 동일한 동작을 구현하면 천재.

tabindex=”1″? tabindex=”0″? tabindex=”-1″?

정찬명 — Thu, 10 May 2012 14:59:53 +0000

요 며칠 사이 tabindex 속성이 저를 좀 당황스럽게 했습니다. 일반적으로 tabindex 속성은 키보드 접근성을 훼손할 우려가 있기 때문에 평소에 거들떠 보지도 않던 속성인데요. 해외 오픈소스 위지윅 에디터를 벤치마킹 하다가 tabindex=”-1″ 이라는 코드를 발견한 겁니다. 제가 알기로 소시적에 이런 코드는 표준이 아니었거든요.

HTML4 명세는 tabindex를 다음과 같이 설명합니다. 이 설명은 XHTML 문서에도 동일하게 적용됩니다.

이 속성은 문서의 탭 순서 안에서 현재 요소의 순번을 결정한다. 값은 0부터 32767 사이의 숫자여야 한다. 브라우저는 값 앞에 0이 붙어있으면 무시해야 한다.
탭 순서는 사용자가 키보드를 통해 탐색할 때 어떤 요소가 초점을 받는 순서가 되는지를 결정한다.
초점을 받을 요소는 브라우저에서 다음과 같은 규칙에 따라 탐색되어야 한다.

요소가 tabindex 속성을 지원하고 양의 값이 할당되어 있으면 먼저 탐색되어야 한다. 탐색은 tabindex 값의 가장 작은 수에서 시작하여 가장 큰 값으로 향한다. 값은 연속되는 일련의 숫자가 아니어도 상관이 없고 어떤 수로 시작해도 무방하다. 요소에 동일한 tabindex 값이 지정되어 있다면 코드 안에서 먼저 등장하는 순서대로 탐색되어야 한다.
tabindex 속성 지원 여부에 관계 없이 “0″의 값이 할당된 요소는 그 다음으로 탐색된다. 이 요소들은 코드 안에서 등장하는 순서대로 탐색된다.
disabled 속성이 사용된 요소는 탭 순서에 관여하지 않는다.

a, area, button, input, object, select, textarea 요소가 tabindex 속성을 지원하는 요소이다.

어쨌거나 표준에 따르면 tabindex 속성에는 음수 값을 사용할 수 없습니다. 그러나 현존하는 브라우저들은 tabindex=”-1″ 속성이 부여된 요소에 대해 키보드가 접근하지 않는 방식으로 구현을 해놨더라구요. 결국 이 방식이 사실상 표준이거나 또는 공식 표준이 아닐까 하는 생각이 들어 HTML5 명세를 찾아 봤습니다.

HTML5 명세는 tabindex 속성의 음수 값을 다음과 같이 설명합니다.

tabindex 값이 음의 정수라면 요소에 초점이 도달하지 않도록 해야 한다.

결국 tabindex 속성에서 음수 값을 사용하여 초점을 받을 수 없도록 하는 스펙을 추가한 것입니다. 그리고 현존하는 웹 브라우저들은 문서의 DTD에 관계 없이 이런 새로운 스펙을 낡은 문서에서도 사용할 수 있도록 구현해 둔 것입니다.

지구인들이 가장 많이 사용하고 있는 위지윅 에디터 TinyMCE와 CKEditor는 이런 코드를 도구모음 버튼에 적용하여 키보드 사용자들이 도구모음 블럭을 아예 건너 뛰도록 해 놨더라구요. 이런 구현방식에 대해 어떤 분들은 키보드 사용자를 고려하지 않았다고 주장할 수 있는데요. 제가 보기에는 이 친구들 센스있게 잘 처리한 것으로 봅니다. 키보드만으로 위지윅 에디터를 사용해 본 분들은 이런 처리를 이해할 수 있습니다.

네이버 스마트에디터와 다음 에디터는 도구모음 블럭에 키보드가 접근할 수 있도록 처리해 놨지만 실제로는 키보드만으로는 절대로 사용할 수가 없습니다. 일단 본문 영역에 초점이 들어가면 빠져나올 방법이 없기 때문에 문제가 시작됩니다. 편집 영역에 초점이 들어가면 Tab 키를 눌러서 빠져 나와야 하는데 Tab 키에 들여쓰기 기능을 맵핑해 놓았기 때문에 편집 영역에서 빠져나올 수 없습니다. 결국 키보드만 사용하는 시각 장애인 또는 상지 장애인(팔이 없거나 불편한)은 글쓰기 과업을 수행할 수 없었습니다.

tabindex=”1″

문서 안에서 가장 먼저 초점을 받을 수 있습니다. 그러나 자연스러운 마크업 순서를 거스르기 때문에 주의해서 사용해야 합니다. 검색엔진 사이트에서 검색창에 사용하면 적합하지만(이 대신 autofocus=”autofocus” 속성이 더 적절할 듯 해요) 그 외 적합한 경우는 잘 떠오르지 않는군요.

tabindex=”0″

키보드 초점을 받을 수 없는 div, span과 같은 요소도 초점을 받을 수 있도록 만들어 줍니다. 초점을 받되 초점을 받는 순서는 자연스러운 마크업 순서를 따릅니다.

tabindex=”-1″

키보드 초점을 받을 수 있는 요소도 초점을 받을 수 없도록 만들어 줍니다. 초점을 받을 수 없기 때문에 “-1″ 이외의 다른 음의 정수 값은 사실상 의미가 없습니다.

input type=”search” in Webkit Browser.

정찬명 — Thu, 10 May 2012 13:27:27 +0000

SNS를 사용하다 보니 왠만한 글은 짧게 압축해서 간단하게 쓰는 버릇이 생겼습니다. 대신 블로깅은 뒷전이 됐구요. 오늘은 놀고 있는 블로그에 미안한 생각이 들어서 앞으로 가급적 짧은 내용이라도 블로그에 적어야겠다는 생각을 했습니다.

웹킷 엔진을 사용하는 크롬과 사파리 브라우저는 요소를 다른 브라우저와 다르게 표시하는 특징(또는 버그)이 있습니다. search 타입은 HTML5 문서에서 새로 등장한 속성입니다.

보통의 경우 input 요소에 적용되어 있는 브라우저의 기본 CSS는 웹 제작자의 CSS 코드를 이용하여 덮어 쓸 수 있는데요. 크롬과 사파리 브라우저는 유독 요소에 border 속성을 덮어쓰지 않도록 처리를 해 놨습니다. 원인을 찾다가 보니 크롬 브라우저에서 다음과 같은 코드가 UA(User Agent) 스타일시트 안에 포함되어 있더라구요.

input[type="search"] {
-webkit-appearance:searchfield;
box-sizing:border-box;
}

다른 타입의 input은 이렇지 않은데요. 유난히 search 타입만 이렇습니다.

-webkit-appearance:searchfield; 라는 코드는 웹 제작자가 검색 input에 대한 border 속성을 덮어 쓸 수 없도록 만듭니다.
box-sizing:border-box; 속성은 다른 일반적인 박스와 다르게 패딩과 보더를 너비값에 포함시켜 버리는 방식으로 면적(너비와 높이)을 계산합니다.

결국 웹 제작자는 검색 인풋을 의도한 대로 디자인 하기 어렵고 다른 브라우저와 다른 면적 계산 방식 때문에 당황하게 됩니다. 다른 input 요소와 동일한 방법으로 검색 input에 border 속성을 제공하고 일반적인 면적 계산 방식을 가질 수 있도록 하려면 웹 제작자는 다음과 같은 코드를 사용해서 UA 스타일을 덮어쓰기 할 수 있습니다.

input[type="search"] {
-webkit-appearance:textfield;
box-sizing:content-box;
}

끝입니다. 웹킷 개발자는 어떤 의도로 이렇게 처리를 해놓은 것일까요?

NARADESIGN:BLOG

BMW F800R 구매.

레이어 열기/닫기 키보드 접근성.

레이어 열기/닫기 UI의 키보드 접근성 문제

레이어가 열리는 순간 초점 순서를 바로잡는 방법

레이어가 닫히는 순간 키보드 트랩에서 빠져나오기

참고 2013-05-29 업데이트

CSS Quiz – 화면을 가득 채우는 격자 그리기.

도전 과제

CSS Quiz – 가장 많은 수평선 그리기.

도전 과제

HTML 코드

CSS 정답 제출 예시

DEVIEW 2012 반응형 웹 구축기

웹 폰트 문제 해결. @font-face troubleshooting.

하나의 글꼴에 @font-face 규칙은 한 번만 선언

IE 9은 @media 규칙 내부에 @font-face 허용 안함

참고

CSS3 미디어쿼리 이해

CSS 코드 내부에서 분기하는 방법

CSS 코드 외부에서 분기하는 방법

미디어 쿼리 코드 템플릿

조건문이 될 수 있는 특징들

width / height

device-width / device-height

orientation

aspect-ratio

device-aspect-ratio

color

color-index

monochrome

resolution

scan

grid

CSS를 사용한 썸네일 크게 보기.

tabindex=”1″? tabindex=”0″? tabindex=”-1″?

tabindex=”1″

tabindex=”0″

tabindex=”-1″

input type=”search” in Webkit Browser.

참고 ^{2013-05-29 업데이트}