로그인 바로가기

중앙 내용으로 바로가기

한국직업전문학교

본문내용

본문

읽을거리
+ Home > 커뮤니티 > 읽을거리
반응형 웹 디자인의 현재
  • 작성자
    관리자
  • 등록일
    2016-06-16 19:39:39
    조회수
    1269

 

 

[정보]반응형 웹 디자인의 현재

[출처]webactually http://www.webactually.com

http://www.webactually.co.kr/archives/12875

예전에 올라온 자료이기는 하나 유용한 정보라서 올려봅니다.

18 August 2014 by  http://bit.ly/1mY6Qix

“반응형”은 단순한 한 단어이지만 이를 구현해 내는 기술은 상상을 초월할 정도로 복잡합니다. “가야할 길은 멀고 아직 목표점에 도착하지 않았다”라는 저자 스테파니 월터의 말처럼 반응형 웹 디자인 기술은 개선되야 할 문제가 많고 더 많은 토론과 합의점을 모아야 하는 흥미진진한 분야이기도 하지요.

이 글에서 이미지, 폼, iframe, 타이포그래피, 콘텐츠 등 반응형 웹 디자인 기술에 관한 많은 자료를 공유하고 있습니다. 책에 설명되지 않은, 현재 W3C, WHATWG, 필라멘트 그룹 같은 단체에서 진행중인 따끈따끈한 기술들을 접할 수 있는 글입니다. 그 따끈함이 여러분의 머리와 마음에 전해지길 바랍니다.

[편집자주]

반응형 웹 디자인이 나온지 수년이 지났고 이는 2012년 웹계의 최대 관심사였다. 브래드 프로스트Brad Frost나 루크 로블르스키Luke Wroblewski 같이 널리 알려진 사람들은 반응형 디자인으로 경험을 많이 쌓았고 우리가 이 분야에서 비약적으로 발전할 수 있도록 도움을 주고 있다. 하지만 여전히 할 일은 많이 남아있다.

이 글에서 반응형 웹 디자인으로 현재 가능한 것과 (CSS Level 4나 HTML5 APIs와 같이) 아직 표준화되지 않은 속성을 사용해 미래에 가능한 것, 계속해서 개선할 것에 대해 살펴볼 것이다. 이 글은 완벽하지 않고 각 기술에 대해 심도깊게 들어가지 않는다. 대신 여러분은 스스로 더 검토할 수 있을 만큼 충분한 링크와 지식을 얻을 것이다.

반응형 웹 디자인 이미지의 현재

반응형 웹 디자인에서 이미지만큼 이야기를 시작하기 좋은 측면이 있을까? 꽤 오랫동안 중요하게 다루어진 주제이다. 고밀도high-density 화면의 도래로 이미지는 더욱 더 중요해졌다. 고밀도를 말하자면 픽셀 비율이 2보다 높은 화면이며 애플에서 이를 레티나 기기Retina devices라 하고 구글에서 XHDPI라고 한다. 반응형 웹 디자인에서 이미지는 크기와 성능과 연관된 큰 문제에 직면한다.

대부분의 디자이너가 픽셀을 완벽하게 맞추는 것을 좋아하지만 고밀도 기기에서 ‘일반’ 크기의 이미지는 픽셀이 화면에 맞게 보정되어 흐릿하게 보인다. 단순히 두 배 크기되는 이미지를 고밀도 기기에 사용하고 싶은 유혹이 들지않나? 그렇게 하면 성능에 문제가 발생한다. 두 배나 큰 이미지를 로딩하는데 시간이 더 걸리기 때문이다. 고밀도 기기를 소유한 사용자는 그 이미지를 다운로드하는데 필요한 인터넷 대역폭이 제공되는 환경에 있지 않을 수 있다. 사용자가 거주하는 국가에 따라 인터넷 대역폭 사용료가 비쌀 수도 있다.

두번째 문제는 더 작은 기기에 영향을 미친다. 모바일 기기에서 300픽셀 이미지만 필요한데 750픽셀 이미지를 왜 다운로드해야 할까? 작은 기기를 사용하는 사용자가 의미 있는 부분만 볼 수 있도록 이미지를 자르는crop 방법이 있을까?

2가지 마크업 해결책: <PICTURE> 엘리먼트와 SRCSET 속성

반응형 이미지 문제를 풀려는 첫 단계는 HTML 페이지에 있는 이미지 마크업을 바꾸는 것이다.

반응형 이미지 커뮤니티 그룹은 새롭고 다루기 쉬운 엘리먼트인 <picture> 엘리먼트에 관한 제안을 지지한다. 현재 잘 알려진 미디어 쿼리를 이용해 각각 다른 기기에 다른 이미지를 제공한다는 개념이다. 따라서 작은 기기에 작은 이미지가 다운로드된다. 비디오 마크업과 유사하게 작동하지만 source 엘리먼트에서 다른 이미지를 참조하는 점이 다르다.

제안된 명세서에proposed specification 있는 코드는 다음과 같다.

다른 이미지 자료를 제공할 수 있다면 작은 기기에서 의미 있는 부분을 보도록 이미지 일부를 잘라서 제공하는 것도 상상할 수 있다. W3C ‘아트 디렉션[1]’의 이용 사례는 무엇을 할 수 있는지에 관한 좋은 예를 보여준다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

(이미지: 예고리 파스코Egor Pasko)

해결방안은 현재 W3C 반응형 이미지 커뮤니티 그룹에서 논의중이고 아는 바로는 이 순간 어떤 브라우저에서도 사용할 수 없다. 픽쳐필Picturefill로 부르는 폴리필polyfill을 사용할 수 있으며 이것은 거의 동일한 기능을 구현한다. 폴리필은 보안을 위해 div와 data- 속성 구문을 사용한다.

반응형 이미지 마크업에 관한 두 번째 제안을 애플이 W3C에 했고 그것을 ‘srcset 속성’이라 부른다. CSS 레벨 4에 있는 image-set()에 해당한다. 이 속성의 목적은 사용자 에이전트user agents가 전체 세트를 가져오지 않고 세트에서 조건에 맞는 리소스를 선택하도록 하는 것이다. 이 제안을 위한 HTML 구문은 <img> 태그 자체를 기본으로 하며 명세서에 있는 예는 다음과 같다.

보다시피 구문이 전혀 직관적이지 않다. 태그 값은 쉼표(,)로 구분되는 문자열로 되어 있다. 속성 값은 각종 이미지 이름이나 URL, 기기의 픽셀 밀도, 각각 의도하는 뷰포트 크기의 최대값이다.

위의 정보를 다음과 같이 쉽게 설명할 수 있다.

  • 기본 이미지는 banner.jpeg이다.
  • 픽셀 비율이 2보다 높은 기기에서 banner-HD.jpeg을 사용한다.
  • 최대 뷰포트 크기가 100 w인 기기에서 banner-phone.jpeg을 사용한다.
  • 최대 뷰포트 크기가 100w이고 픽셀 비율이 2보다 높은 기기에서 banner-phone-HD.jpeg을 사용한다.

srcset 속성이 지원되지 않으면 첫 번째 소스는 기본 이미지가 된다. banner-HD.jpeg 뒤에 있는 2x 접미사는 이 특정 이미지가 픽셀 비율이 2보다 높은 기기에 사용된다는 것을 의미한다. banner-phone.jpeg 뒤에 있는 100w는 그 이미지를 사용해야 하는 최소 뷰포트 크기를 말한다. 기술적 복잡성으로 이 구문은 어떤 브라우저에도 구현되지 않았다.

image-set() CSS속성 구문은 거의 똑같은 방법으로 작동하고 화면 해상도에 맞추어 특정 이미지를 로딩시킨다.

아직까지 이 제안은 W3C 편집자 초안 상태이다. 일단 사파리 버전 6+와 크롬 버전 21+에서 작동한다.

이미지 형식, 압축, SVG: 웹에서 이미지로 작업하는 방법 바꾸기

보다시피 새로운 이미지 마크업 형식을 찾는 시도는 굉장히 실험적이다. 이 문제는 이미지 형식 자체에 대한 이슈를 제기한다. 이미지 자체 처리방법을 바꿔서 반응형 해결안을 생각할 수 있을까?

첫 단계는 더 나은 압축률을 적용한 대체 이미지 형식을 검토하는 것이다. 예를 들어 구글은 WebP라는 새로운 이미지 형식을 개발했다. 이것은 PNG보다 26% 작고 JPEG보다 25%~34% 작다. 이 형식은 구글 크롬, 오페라, 얀덱스Yandex[2], 안드로이드, 사파리에서 지원되며, 구글 크롬 프레임 플러그인을 사용하면 인터넷 익스플로어에서도 작동시킬 수 있다. 이 형식의 주된 문제는 파이어 폭스가 이를 구현할 계획이 없다는 것이다. 이를 알기에 현재로서는 폭넓게 사용될 것 같지 않다.

좋은 평판을 얻고 있는 다른 아이디어는 progressive JPEG 이미지이다. Progressive JPEG 이미지는 그 이름이 시사하듯 점진적으로 보여진다. 렌더링 초기에 흐릿하게 보이지만 계속 진행될수록 이미지는 점점 선명해진다. Non-progressive JPEG는 위에서 아래로 나타난다. “Progressive JPEGs: 새로운 최고의 방식”이란 글에서 앤 롭슨Ann Robson은 progressive JPEG이 기선baseline JPEG보다 더 빨리 보여지는 느낌을 준다고 주장한다. Progressive JPEG은 파일이 완전히 로딩되기 전에 사용자에게 이미지의 전체적인 느낌을 빨리 전달한다. 이것이 성능과 이미지 크기의 기술적인 문제를 풀지 못하지만 사용자 경험을 개선해준다.

성능과 이미지 크기 문제에 대한 다른 해결안은 이미지 압축률을 바꾸는 것이다. 오랫동안 우리는 이미지 압축률을 높이면 전반적으로 이미지 품질에 손실을 가져온다고 생각했다. 다안 조브시스Daan Jobsis는 이것을 주제로 폭넓은 연구를 했고 “레티나 혁명”이라는 글을 썼다. 실험에서 그는 다른 이미지 크기와 압축률을 시도했고 매우 흥미로운 해결안에 도달했다. 보여지는 이미지 크기를 두배로 유지하고 더 높은 압축률을 적용하면 그 이미지는 원본보다 파일 용량이 작아지고 일반 화면과 고밀도 화면에서 선명하게 보인다. 이 기술로 조브시스는 이미지 용량을 75% 줄였다.

 

 

 

 

 

 

 

 

골칫거리인 반응형 이미지를 고려해 볼 때 가능한 모든 곳에서 픽셀 독립성을 확보하려는 발상은 많은 디자이너와 개발자를 유혹한다. 예를 들어 SVG 형식은 웹사이트의 모든 UI 요소를 만드는 데 사용될 수 있고 해상도에 독립적이다. 작은 기기에서 그에 맞게 축소되고 고밀도 기기에서 흐리게 보이지 않는다. 폰트 아이콘 역시 증가하는 추세이다. 아이콘 글리프를 (Unicode Private Area처럼) 폰트의 특정 문자에 지정하는 것이 필요하고 폰트를 다루기 쉽게 해준다. 불행히도 이 해결안은 사진에 적용되지 않는다. 이에 성공할 수 있는 마크업이나 이미지 형식을 간절히 기대하고 있다.

반응형 레이아웃의 문제: HTML 작업없이 콘텐츠를 재배열하고 관리할 수 있는가?

솔직히 말해 오늘날 우리가 사용하는 float와 inline 블록으로 만들어진 유동형 그리드fluid grid는 더 나은 해결책을 기다리는 부족한 패치patch이다. 현재 자바스크립트에 의지하지 않고 레이아웃 작업과 모바일 기기 페이지에서 블록을 재배열하는 일은 악몽이다. 융통성도 없다. CMS로 만들어진 웹사이트에서 특히 중요하다. 디자이너는 웹사이트의 모든 버전과 페이지의 HTML을 변경할 수 없다. 그렇다면 어떻게 이것을 개선할 수 있을까?

융통성 없는 레이아웃 문제를 다루는 4가지 CSS3 레이아웃 해결안

가장 확실하고 실행가능한 해결안은 CSS3 플렉시블 박스 레이아웃 모델 (혹은 ‘플렉스박스flexbox’)이다. 현재 후보 권고안candidate recommendation 상태이며 대부분의 주요 모바일 브라우저와 데스크톱 브라우저에서 지원된다(IE는 버전 10이상). 이 모델은 HTML에 독립적이어서 화면 요소들을 쉽게 재배치할 수 있게 해준다. 문맥에 맞게 박스 방향과 박스 흐름을 변경할 수 있고 공간을 분배하고 정렬시킬 수 있다. 모바일에서 재배열되는 레이아웃에 대한 예제이다. 구문은 다음과 같다.

 

 

 

 

 

 

 

 

CSS3 플렉시블 박스 레이아웃 설명” 글에서 플렉스박스가 작동하는 방식에 대해 깊이 이해할 수 있다.

다른 해결안은 리로케이트Relocate로 이것은 페이지에서 블록을 재배치하는 플렉스 박스 개념에 매우 가깝지만 자바스크립트를 사용한다.

오늘날 반응형 디자인에 꽤 쓸만한 두 번째 유형의 레이아웃은 CSS3 다중 열 레이아웃multiple-column layout이다. 이 모듈은 후보 권고안 상태이며 IE 9 이하 버전을 제외한 대부분 브라우저에서 잘 작동한다. 이 모델의 주요 혜택은 유연성에 크게 힘입어 컨텐츠가 한 열에서 다른 열로 흘러간다는 것이다. 반응성 면에서 볼 때 뷰포트 크기에 따라 열의 개수가 조정된다.

사용가능한 공간에 따라 열 크기를 정하고 브라우저에서 열 개수를 계산하도록 할 수 있다. 또한 사이 빈 공간과 규칙이 적용된 열 개수를 정할 수 있고 브라우저에서 각 열의 폭을 계산하게 하는 것도 가능하다.

 

 

 

 

 

 

 

 

구문은 다음과 같다.

더 자세히 알고 싶으면 데이비드 월시David Walsh의 글 “CSS 열Columns”을 읽어보라.

향후 더 많은 주목을 받으리라고 생각하는 세 번째 CSS3 속성은 CSS3 그리드 레이아웃grid layout이다. 이 레이아웃은 디자이너와 개발자에게 유연한 그리드를 제공해 각기 다른 레이아웃을 만드는데 이를 사용할 수 있다. 정의된 구조없이도 컨텐츠 엘리먼트를 행렬에 보여지도록 해준다. 우선 컨테이너container에 그리드를 선언하고 자식 엘리먼트를 이 가상 그리드virtual grid에 배치한다. 그다음 작은 기기에 대한 다른 그리드를 정의하거나 그리드에서 엘리먼트 위치를 변경하면 된다. 미디어 쿼리와 함께 이것을 사용하면 유연함과 방향 변경 등의 효과를 염두해 볼 수 있다.

구문은 다음과 같다. (2013년 4월 2일자 초안에서 발췌)

명세서에 자세히 알려진대로 행렬 크기를 정하는데 여러가지 단위를 사용할 수 있다. 다양한 엘리먼트를 배치하는 것에 대해 명세서에 다음과 같이 쓰여있다. “게임(예)의 각 부분은 그리드 선들 사이에 놓인다. 이는 시작하는 그리드 선을 표시하고 그다음 (한 개보다 많다면) 끝나는 그리드 선을 확정짓는, 전체를 포괄하는 행과 열 개수를 명시한다. 이로서 그 부분의 경계선이 만들어진다.

이 속성의 가장 큰 문제는 현재 IE 10에서만 지원이 된다는 점이다. 이 레이아웃을 더 알고 싶으면 레이첼 앤드류Rachel Andrew의 “CSS3 그리드 레이아웃으로 콘텐츠 우선순위 정하기”를 읽어보라. 2013년 4월 2일을 기준으로 그리드 레이아웃에 관한 명세서와 구문이 변경되었으니 주의하라. 레이첼은 구문에 대한 업데이트 내용을 “CSS 그리드 레이아웃: 무엇이 바뀌었는가?”라는 글에 담았다.

향후 브라우저에서 실행되면 유용한 마지막 레이아웃은 CSS3 템플릿 레이아웃이다. 이 CSS3 모듈은 하나의 엘리먼트와 레이아웃 “이름”을 연결한 다음, 보이지 않는 그리드 위에 그 엘리먼트를 나열해서 적용된다. 그리드는 고정되거나 유동적으로 움직일 수 있고 뷰포트 크기에 따라 변할 수 있다.

구문은 다음과 같다.

보이는 결과는 다음과 같다.

 

 

 

 

 

 

 

 

안타깝게도 이 CSS3 모듈을 지원하는 브라우저는 없다. 아마 언젠가 디자이너와 개발자들이 이 명세서에 흥미를 충분히 보이면 브라우저 회사들이 이를 적용할 듯싶다. 지금은폴리필로 테스트할 수 있다.

뷰포트 상대 단위와 픽셀기반 레이아웃의 마지막

뷰포트 기반의 퍼센트 길이(vw, vh, vm, vmin, vmax)는 뷰포트 자체 면적에 상대적으로 측정되는 단위이다.

1 vw 단위는 초기 컨테이터 블록 너비의 1%이다. 뷰포트 너비가 320이라면 1 vw는 1 x 320/100 = 3.2픽셀이다.

vh 단위도 같은 방식이지만 뷰포트의 높이에 상대적이다. 고로 50 vh는 문서document 높이의 50%와 같다. 이쯤되면 퍼센트 단위와 무슨 차이가 있는지 궁금할 것이다. 퍼센트 단위는 부모 엘리먼트 크기에 상대적이나 vh와 vw 단위는 부모 엘리먼트 크기와 상관없이 언제나 뷰포트 크기에 상대적이다.

점점 흥미로와지 시점은, 한 예로 콘텐츠 박스content box를 만들어 뷰포트 아래로 박스가 내려가지 않는 것을 확인하고 그 결과로 사용자가 스크롤하지 않고도 정보를 찾을 수 있을 때이다. 또한 전체 부모 엘리먼트에 핵hack을 적용하지 않고도 정확도 100% 높이의 박스를 생성할 수 있다.

vmin 단위는 vm이나 vh 중 더 작은 값과 같고 vmax는 vm이나 vh 중 더 큰 값과 같다. 따라서 이 단위는 기기 방향의 변화에도 완벽히 대응한다. 아쉽게도 현재 이 단위들은 안드로이드 브라우저에서 지원하지 않는다. 레이아웃에 적용하기 전에 조금 더 기다려야 한다.

적응성Adaptive 타이포그래피에 관한 한마디

웹사이트 레이아웃은 콘텐츠에 달려있다. 타이포그래피를 논하지 않고 반응형 레이아웃 가능성에 대한 부분을 마무리할 수 없다. CSS3는 폰트 단위를 도입했다. rem단위로 반응형 타이포그래피에 상당히 유용하다.

Em 단위로 측정된 폰트는 부모 엘리먼트에 상대적인 길이인 반면 rem 단위로 측정된 폰트는 루트root 엘리먼트 폰트 크기에 상대적인 길이이다. 반응형 웹사이트에서 여러분은 다음과 같은 CSS를 작성하고 html 엘리먼트에 명시된 폰트 크기를 변경해서 전체 폰트 크기를 쉽게 바꿀 수 있다.

IE8과 오페라 미니를 제외하고 rem에 관한 지원은 상당히 좋다. rem 단위에 대해 자세히 알고 싶으면 매튜 레티니Matthew Lettini의 글 “rem 단위를 보호하기 위하여”을 읽어보라.

다른 복잡한 콘텐츠를 반응형으로 작동하게 하는 더 나은 방법

느린 속도이긴 해도 반응형 레이아웃에서 이미지와 텍스트를 다루는데 능숙해지고 있다. 그래도 여전히 더 복잡한 콘텐츠 유형에 관한 해결책을 찾아야 한다.

반응형 웹사이트에서 폼Form 다루기

일반적으로 반응형 웹 디자인에서 폼을 다루는 것, 특히 길이가 긴 폼들은 상당히 어렵다! 폼이 길면 길 수록 작은 기기에 맞추기가 더 난해해진다. 물리적인 적용은 그다지 어렵지 않다. 대부분 디자이너들은 폼 엘리먼트를 한 열에 넣고 input 길이를 화면의 최대 너비로 늘인다. 폼을 눈으로 보기에 매력적으로 만드는 것으로는 부족하다. 모바일 기기에서도 사용하기 쉽게 만들어야 한다.

루크 로블르스키는 초심자에게 텍스트 입력박스input 대신 체크박스와 라디오 버튼에 의지하고 가능한 곳에서 드롭다운 메뉴를 선택하라고 조언한다. 이런 방식으로 사용자는 정보를 되도록 적게 입력하게 된다. 다른 조언은 제출할 입력내용에 대해 피드백을 받기 전에 사용자가 “전송” 버튼을 누르지 않도록 하는 것이다. 다음 입력으로 넘어가기 전에 진행되는 오류 확인은 모바일에서 특히 중요한데 이는 모바일에서 대부분 폼이 화면 높이보다 길기 때문이다. 사용자가 어떤 입력 필드에서 오타를 냈는데 폼을 전송해야 그것을 알수있다면 (폼을 작성하면서) 오타를 어디서 냈는지 알지 못할 가능성이 많다.

미래에는 자바스크립트 도움없이 새 HTML5 폼 입력박스inputs와 속성으로 더나은 폼을 만들것이다. 한 예로 required 속성을 적용해 특정 입력필드에 대해 그자리에서 피드백을 받을 수 있다. 아쉽지만 이 시점에 모바일 기기에서 이에 대한 지원은 열악하다. autocomplete 속성 역시 폼을 더 반응형으로 만드는데 도움이 된다.

모바일은 개인용 소지품으로 이름이나 우편주소와 같은 데이터가 일정하게 유지된다고 가정할 수 있다. HTML5 autocomplete 속성을 사용해서 그런 입력필드에 정보를 미리 채워서 사용자가 모든 정보를 반복해서 입력하지 않도록 해준다. 가까운 미래에 폼을 더욱 더 반응형으로 만들 수 있는 새 HTML5 input 전체목록도 있다.

폼 엘리먼트 중에 날짜Dates는 HTML5로 개선할 수 있는 좋은 예제가 된다. 자바스크립트에 의존해 날짜 선택기date-pickers를 만들곤 했다. 그 선택기들은 큰 데스크톱 화면에서 쓸만하지만 터치 기기touch devices에서는 사용하기 어렵다. 터치 영역이 너무 작으면 한 손가락으로 날짜를 정확하게 선택하기가 어렵다.

 

 

 

 

 

 

 

 

기대되는 해결안은 새 HTML5 input type=”date”에 있고 이것은 날짜형식에서 문자열을 정한다. HTML5 input type=”datetime”은 날짜와 시간형식에서 문자열을 정한다. 이 방법의 커다란 이점이라면 브라우저에게 어떤 UI를 사용할지 결정하게 한다는 것이다. 이런 식으로 UI는 모바일에 자동으로 최적화된다.

input type=”date”는 데스크톱, (크롬을 사용하는) 안드로이드 폰과 태블릿, 아이폰, 아이패드에서 다음과 같이 보인다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

화면 이미지들은 내 안드로이드 폰과 브라우저에서 찍은 것으로 언어가 자동적으로 시스템 언어(불어)로 반영된 것에 주목하라. 내장native 요소를 사용하기에 여러분은 더 이상 웹사이트의 버전별 언어를 적용할 필요가 없다.

현재 데스크톱 브라우저의 input type=”date” 지원은 오페라와 크롬을 제외하면 전무하다. 안드로이드 내장 브라우저에서 전혀 지원하지 않는다. 하지만 안드로이드용 크롬은 지원하고 iOS용 사파리도 지원한다. 반응형 웹사이트에 이 해결책을 사용하려면 넘어야 할 산이 많다. 그 동안에 기본적으로 해결책을 지원하지 않는 모바일 브라우저에 모비스크롤mobiscroll 같은 폴리필을 사용하면 된다.

HMTL5 input 해결책과는 별도로 모바일에서의 비밀번호 마스크masks를 이용한 복잡한 input 형식화와 같은 다른 디자인 패턴을 개선하려는 시도를 해왔다. 알게 되겠지만 이들은 실험적이다. 완벽한 반응형 폼은 이 순간 존재하지 않으며 이 분야에서 이루어져야 할 게 많다.

반응형 웹사이트에서 테이블 다루기

모바일과 반응형 웹사이트에서 상당히 골치아픈 콘텐츠 유형이 테이블이다. 대부분 테이블은 방향이 수평으로 맞춰지고 수많은 데이터를 한번에 보여준다. 따라서 작은 화면에서 제대로 보이는 테이블을 구현하는 일이 얼마나 어려운지 알게 될 것이다. HTML 테이블은 꽤 유연하다(퍼센트를 사용해 열 너비를 바꿀 수 있다). 그렇게 하면 금새 콘텐츠 가독성이 떨어진다.

누구도 아직까지 테이블을 표시하는 완벽한 방법을 발견하지 못했다. 그래도 나온 의견들이 어느정도 된다.

하나의 접근방법은 “덜 중요하다고 여겨지는 열 숨기고” 체크박스를 두어 사용자가 보고자 하는 열을 고르게 하는 것이다. 데스크톱에서 모든 열이 보여지지만 모바일에서 보여지는 열 개수는 화면 크기에 달려있다. 필라멘트 그룹Filament Group에서 이 접근방식을 설명하고 글에서 실례를 보여준다. 이 해결책은 jQuery 모바일의 테이블 열 토글toggle에서도 사용되고 있다.

 

 

 

 

 

 

 

 

 

 

 

 

두 번째 접근방식은 스크롤 가능한 테이블을 활용한다. 크기가 고정된 열 하나를 왼쪽에 고정시키고 오른쪽으로 테이블의 더 작은 부분에 스크롤바를 둔다. 데이비드 부쉘David Bushell은 글에서 이 아이디어를 적용하고 있다. 테이블 왼쪽의 <thead>에 콘텐츠 전체가 보이도록 CSS를 사용하고 오른쪽에서 사용자가 콘텐츠를 스크롤하도록 했다. Zurb는 동일한 발상을 다른 방식으로 플러그인에 구현한다. 이 경우 헤더는 테이블 맨 위에 그대로 있고 테이블은 자바스크립트로 복제되어 왼쪽에 첫 번째 열만 보이고 나머지 열들은 오른쪽에 스크롤바와 같이 보인다.

 

 

 

 

 

 

 

 

 

 

 

 

 

스크롤바와 overflow: auto 같은 CSS 속성에 대한 커다란 문제점은 많은 모바일 기기나 태블릿이 스크롤바를 표시하지 않는다는 것이다. 테이블의 오른쪽 영역은 스크롤이 가능하지만 그 사실에 대한 시각적 단서가 없어 사용자는 알지 못한다. 오른쪽에 더 많은 콘텐츠가 있다는 것을 알려줄 방법을 찾아야 한다.

세 번째 접근방식은 큰 테이블을 리플로우reflow 하고 열을 헤딩과 함께 보여야할 항목으로 나누는 것이다. 이 기술은 jQuery 모바일에 관한 ‘reflow mode’에서 사용되고 크리스 코이어Chris Coyier의 글 ‘반응형 데이터 테이블’에서 설명하고 있다.

 

 

 

 

 

 

 

 

 

 

 

 

다른 기술도 많이 있다. 어떤 것을 사용할지는 여러분의 프로젝트에 달려있다. 2개의 프로젝트라도 서로 같지 않다. 그러기에 다른 사람들이 이 문제를 어떻게 풀었는지만 여러분에게 보여줄 수 있다. 여러분만의 해답을 찾았다면 아래 댓글을 남기거나 트위터에 포스팅해서 세상과 공유하기를 부탁한다. 우리는 한 배를 탔고 모바일에서 테이블은 형편없으니 함께 개선하도록 합시다!

서드파티 콘텐츠 넣기embedding: 반응형 iframe 문제

많은 웹사이트에 내장된

목록보기
수정하기
삭제하기