CSS 그리드로 미지원 브라우저 지원하기 - WebactuallyWebactually | 웹사이트를 만드는 사람들을 위한 온라인 정보

‘지원’의 의미

그리드 미지원 브라우저를 어떻게 지원할지 고민하기 전에, 먼저 ‘지원^support‘의 의미를 정할 필요가 있다. 지원이란 대상 목록에 있는 모든 브라우저에서 우리 사이트가 완전히 동일한 모습이라는 의미일 수 있다. 또한, 어떤 브라우저에서도 따로 마무리 작업을 할 필요가 없는 만족스러운 상태이거나, 또는 훨씬 단순화된 경험을 잘 수용하는 브라우저로 테스트를 하고 있다는 의미일 수도 있다.

연결되는 질문은, 그럼 ‘그 브라우저 지원 목록을 어떻게 만들 것인가’이다. 이는 아무리 새로운 웹사이트라 할지라도 추측이 개입되면 안 되는 문제다. 오늘날 많은 비즈니스 영역에서 웹사이트를 처음 구축해 보는 경우는 거의 없다. 따라서 고객이 실제 사용하는 브라우저들을 알 수 있는 분석 자료들을 갖고 있을 것이다. 비록 완전히 모바일 비친화적인 사이트(보통은 작은 화면에서 사용할 수 없는 사이트를 모바일에서 방문하지는 않는다)라서 분석 결과가 왜곡되지 않도록 신경 써야 할 필요가 있더라도 말이다.

만약 적절한 분석 자료를 갖고 있지 않다면 Can I Use 사이트에서 자신의 지역 정보를 임포트하고 관련 데이터를 이용하는 방법도 있다.

Can I Use 웹사이트에서는 자신의 지역에 해당하는 사용 데이터를 임포트할 수 있다. [크게 보기]

또한 여기서도 사이트의 목적을 잊지 않는 게 중요하다. 예를 들어 인도와 같은 신흥 시장에 거주하는 방문자의 관심을 끌고자 하는 사이트라면 그런 국가에서 많이 사용되는 브라우저에서 잘 작동돼야 할 것이다.

구식 브라우저만 신경 쓰면 되는가?

이 글을 쓰는 시점에서의 엣지^Edge, 크롬^Chrome, 파이어폭스^Firefox, 오페라^Opera, 사파리^Safari, iOS용 사파리는 모두 그리드 레이아웃^{Grid Layout}을 지원하고 있다.

IE10과 IE11은 -ms- 접두어를 통해 CSS 스펙을 지원한다.(역주: 원문에는 -ms로 돼 있으나 -ms-로 표기하는게 맞음) 따라서 구식 브라우저는 다음과 같은 버전의 브라우저들로 간주할 수 있다.

인터넷 익스플로러 9 이하(또는 새 CSS 스펙만을 고려한다면 IE11 이하)
엣지 15 이하
파이어폭스 52 미만
크롬 57 미만
삼성 인터넷^{Samsung Internet} 6.2 미만

그러나 앞서 말했듯 신흥 시장의 국가에서는 이와 같은 유명한 데스크톱과 모바일 브라우저 이외에도 흔히 사용되는 다른 브라우저들이 있다. 그런 브라우저들은 아직 그리드를 지원하지 않는다. 예를 들어 관점을 전 세계로 넓혀보면, 전체 트래픽의 8.1%를 차지하는 UC 브라우저^{UC Browser}가 등장한다. 이는 세계 3위의 사용률이다. 미국이나 유럽 사람이라면 들어보지도 못했을 브라우저가 말이다.

UC 브라우저는 그리드 레이아웃을 지원하지 않는다. 저전력 디바이스에 최적화돼 있으며 값비싸고 계량된 데이터 환경의 사용자들을 위한 브라우저이기 때문이다. 이는 우리가 브라우저 지원 전략을 수립할 때 고려해야 할 중요한 점이다.

CSS 그리드의 폴리필이 있는가?

처음 CSS 그리드를 접할 때 당연히 떠오르는 질문 하나가 있다. “사용할 수 있는 폴리필^ployfill이 있나?” 불행히도 모든 레이아웃을 가능하게 할 마법의 폴리필이나, 그런 폴리필을 만들 수 있는 기발한 아이디어조차 나오기 힘들 듯하다.

그리드는 예전의 레이아웃 메서드로는 할 수 없는 거의 불가능한 역할을 수행한다. 따라서 그리드 미지원 브라우저에서 그리드를 재현하려면 엄청난 양의 자바스크립트 작업이 필요할 것이다. 고속 렌더링 엔진을 갖춘 고사양의 컴퓨터에서조차 높이를 계산하고 아이템의 위치를 산정하는 작업 따위의 질 나쁜 사용자 경험을 선사할 가능성이 높다. 알다시피 그리드 미지원 브라우저는 오래됐거나, 느리거나, 또는 신흥 시장에서 볼 수 있는 저전력 디바이스를 위한 브라우저이기 때문이다. 어찌 그런 디바이스에 폴리필을 포함한 엄청난 양의 자바스크립트를 강제로 실행시키게 하겠는가?

폴리필을 찾아 헤매기보다는 그리드 미지원 브라우저일지라도 그리드 레이아웃으로 더 나은 사용자 경험을 제공할 수 있는 실질적인 방법을 고민해야 한다. 그리드 레이아웃은 그리드 지원 브라우저에서는 최소한의 CSS로 복잡한 고급 레이아웃을 만들 수 있게 하며, 미지원 브라우저에서도 여전히 괜찮은 사용자 경험을 제공한다. 물론 단순히 폴리필로 문제를 해결할 때보다 약간의 작업이 더 필요할 수 있다. 그러나 그렇게 함으로써 모든 브라우저에서 똑같이 보이게 하기보다는 모두에게 좋은 사용자 경험을 제공하는 ‘지원’이라는 가장 중요한 목적을 이룰 수 있다.

미지원 브라우저 지원하기

그렇다면 어떻게 디바이스 및 브라우저 맞춤형 지원을 할 수 있을까? CSS가 그 해답을 제시한다.

이해하지 못하는 CSS는 무시된다

이 그림의 첫 번째 조각은 브라우저는 자신이 이해하지 못하는 CSS를 무시한다는 사실에 있다. CSS 그리드 미지원 브라우저는 grid-template-columns 등과 같은 속성을 만나면 무얼 해야 할지 모르기 때문에 그냥 그 라인을 무시하고 다음으로 진행한다.

이는 예컨대 float이나 display: table-cell과 같이 그리드와 비슷한 레이아웃을 제공하는 예전의 CSS를 사용할 수 있다는 의미다. 우리가 예전에 했듯이 말이다. 그리드 레이아웃 미지원 브라우저는 그리드 관련 코드는 모두 무시하고, 예전 CSS 코드를 이용하여 레이아웃을 만들 것이다. 그리드 레이아웃 지원 브라우저는 그리드 관련 코드를 적용하면서 계속 진행할 것이다. 바로 우리가 다른 레이아웃 메서드를 사용하는 아이템이 그리드 아이템으로 될 때 어떤 일이 벌어질지 고민해야 하는 지점이다.

새 레이아웃은 예전 레이아웃에 대해 알고 있다

다른 레이아웃 메서드로 엘리먼트를 페이지에 배치하는 경우 그리드가 어떻게 동작하는지는 정확히 스펙에 정의돼 있다.

float이나 clear 프로퍼티를 사용하는 아이템이 그리드 아이템으로 되면 더 이상 float이나 clear의 동작을 하지 않게 된다. 원래부터 없었던 것처럼 말이다. 아래의 코드펜^CodePen에서 .grid 클래스에 적용된 모든 프로퍼티를 제거해보면 모든 아이템에 float이 적용되고 세 번째 아이템에 clear가 적용된 모습을 볼 수 있다. 그러나 이는 그리드 레이아웃이 되면 모두 무시된다.

☞ 레이철 앤드루(@rachelandrew)의 float과 clear를 재정의하는 display: grid

inline-block의 경우도 마찬가지다. inline-block은 모든 자식 아이템에 적용되지만, 부모가 display: grid를 갖는 순간 inline-block의 기능은 상실된다.

나는 그리드 미지원 브라우저에서 컬럼 레이아웃을 만들고 아이템을 정렬하고 싶을 때에는 종종 display: table-cell을 사용한다. 그렇게 하면 vertical-align 프로퍼티가 작동하기 때문이다.

만약 처음 듣는 얘기라면 CSS의 안티히어로 – “display:table”을 읽어보기 바란다. 이를 당장 주된 레이아웃 메서드로 사용하라고 제안하기는 힘들지만, 매우 도움이 되는 대체수단(폴백^fallback)이 될 수는 있다.

컬럼을 만들기 위해 display: table-cell을 사용하면 CSS는 소위 익명 박스^{anonymous box}라는 것을 만든다. 이는 테이블에서 누락된 부분으로서, table 엘리먼트 안의 tr 엘리먼트에 들어갈 실제 HTML 테이블의 셀이다. 익명 박스는 이 같은 누락된 부분을 보완하는 역할을 한다. 그러나 table-cell 아이템이 그리드 아이템으로 되는 일은 익명 박스가 생성되기 전이므로, 마찬가지로 CSS 테이블이 적용된 적이 없었던 것처럼 작동한다.

vertical-align 프로퍼티 역시 그리드 레이아웃에서는 적용되지 않는다. 따라서 이 프로퍼티를 CSS 테이블 레이아웃에 사용했거나 inline-block과 함께 사용했다면 깔끔히 무시될 것이므로, 대신 박스 정렬^{Box Alignment}을 사용해야 한다. 그리드 레이아웃에 의해 무력화되는 display: table-cell과 vertical-align을 다음 코드펜에서 확인할 수 있다.

☞ 레이철 앤드루(@rachelandrew)의 display: table-cell과 vertical-align을 재정의하는 display: grid

플렉스박스를 그리드의 폴백으로 사용할 수도 있다. 그러나 flex 프로퍼티나 flex-grow, flex-shrink, flex-basis 등의 개별 프로퍼티가 적용된 아이템이 일단 그리드 아이템으로 바뀌면 그 프로퍼티들은 모두 무시된다.

마지막으로, 어떤 상황에서는 다중컬럼^Multi-column 레이아웃도 폴백으로 사용할 수 있음을 잊지 말자. 예를 들면 카드^card 컴포넌트나 이미지의 목록을 배치하는 경우다. 다중컬럼 레이아웃은 로우가 아닌 컬럼을 중심으로 아이템을 보여주는데, 상황에 따라서는 유용한 방법이다. 여기서도 마찬가지로 column-count나 column-width가 적용된 다중컬럼 컨테이너에 display: grid를 적용하면 모든 column-* 관련 동작은 무시된다.

기능 쿼리

나머지 대다수의 레이아웃 메서드의 경우엔 컨테이너보다는 개별 아이템에 초점을 맞추게 된다. float 레이아웃을 예로 들어보자. 이 레이아웃에는 퍼센트 너비와 float: left가 지정된 아이템 집합이 있다. 이렇게 함으로써 각 아이템은 일렬로 배열된다. 너비의 합이 100%를 넘지만 않는다면 이는 그리드와 비슷한 모습을 갖는다.

그리드 레이아웃에서는 각 트랙의 퍼센트 크기가 아이템의 너비가 된다. (크게 보기)

그다음엔 이 레이아웃을 CSS 그리드 레이아웃으로 전환하기 위해 부모 그리드를 만든다. 아이템에 적용할 사항은 기껏해야 컬럼 개수 등이다.

이전 레이아웃에서 float과 크기가 적용된 아이템이 새 레이아웃에서는 그리드 아이템으로 바뀌며, 보통은 아이템의 크기를 따로 지정하지 않으므로 이 경우 각 그리드 트랙의 정보를 기초로 크기가 부여된다.

여기가 바로 레이아웃 메서드를 다른 메서드로 재정의할 때 나타나는 이슈를 만나게 될 지점이다. float 레이아웃 예제에서는 각 아이템에 퍼센트 크기를 부여했었다. 그러나 그리드 아이템으로 되면 그 크기는 전체 컨테이너의 너비가 아닌 그리드 영역의 크기가 된다. 이는 파이어폭스의 그리드 인스펙터^{Grid Inspector}로 그리드 라인에 강조를 주어 확인해보면 알 수 있다. 다음 그림과 같이 각 아이템이 각 그리드 셀의 한쪽 편에 정사각형으로 존재한다.

브라우저스택를 통해 다양한 운영체제와 브라우저에 접근할 수 있다. (크게 보기)

이제 기능 쿼리^{Feature Query}의 도움이 필요한 시점이다. 디바이스의 너비와 회전 방향을 감지하는 미디어 쿼리^{Media Query}처럼, 기능 쿼리는 브라우저가 특정 CSS 기능을 지원하는지 확인해준다. 이 float 레이아웃 예제에서는 기능 쿼리 안에 하나만 재정의하면 된다. 바로 너비를 자동으로 설정할 수 있는지 여부다.

☞ 레이철 앤드루(@rachelandrew)의 display: feature 쿼리 예제

얼마나 많이 미지원 브라우저에서의 확인 메서드가 필요한지는 얼마나 많이 그 브라우저에서 서로 다른 레이아웃을 만들기로 했느냐에 달렸다.

IE10과 11에서의 그리드 레이아웃

엣지는 최신의 그리드 레이아웃을 지원하지만, IE10과 11은 -ms- 접두어를 통한 초기 버전만을 지원한다.(역주: 원문에는 -ms로 돼 있으나 -ms-로 표기하는 게 맞음) 그런데 우리가 알고 있는 그리드의 스펙은 원래 마이크로소프트에서 비롯됐다. 그 예전 그리드가 만족스럽지 못하다는 점과는 별개로, 우리에게 처음으로 그리드를 선사하고 발전시킨 마이크로소프트에 감사해야 할 것이다. 더 많은 얘기는 창시자가 말하는 CSS 그리드 이야기에서 읽을 수 있다.

아마도 IE10과 11을 위해 앞서 말한 float이나 다른 레이아웃에 기반을 두는 그리드의 폴백을 직접 제공하기로 했을 수 있다. 다만 IE10과 11은 기능 쿼리를 지원하지 않는다. 따라서 브라우저의 지원 여부를 직접 확인하고 동일한 기능의 새 버전을 만드는 식으로 예전 메서드를 재정의하여 사용하는 한, IE10과 11은 그 메서드를 계속 사용할 것이다.

물론 -ms-grid 버전의 폴백을 만들 수도 있다. 비록 현대의 그리드 레이아웃과 똑같지는 않지만 -ms-grid는 최초이자 실험적인 버전이었다. 그러나 대략 5년이 넘는 시간이 흘렀고, 상황은 변했다. 이는 단순히 자동으로 접두어를 붙여주는 도구를 사용하지 못한다는 수준이 아닌, 차라리 아무 조치도 하지 않았을 때보다 오히려 더 나쁜 경험을 안은 채 IE10과 11 사용자들이 떠나갈 것이라는 의미다. 따라서 그와 같은 방식 대신 좀 더 제약은 있지만 다른 레이아웃을 사용할 필요가 있다.

IE10과 11을 지원할 때 주의해야 할 사항은 다음과 같다.

01 자동 배치는 없다. 그리드의 각 아이템을 라인 기준으로 일일이 배치해야 한다.

02 grid-template-areas를 사용하는 경우, 아스키 아트^ascii-art 작업에 필적하는 코딩을 손수 해야 한다.

03 grid-gap 프로퍼티는 지원되지 않는다.

04 아이템들이 차지할 시작과 끝 컬럼(로우)을 지정하는 대신, 시작 컬럼(로우)과 그 개수를 지정해야 한다.

이들 속성과 관련한 자세한 사항은 본인의 블로그 포스트인 IE용 그리드 레이아웃을 정말 사용해야 하는가?를 참고하기 바란다.

만약 IE10과 11 사용자가 대다수인 경우라면 이와 같은 오래된 스펙을 이용하는 일이 유용할 것이다. 이뿐만 아니라 실질적으로 진행을 가로막는 작은 이슈 몇 가지만 해결하면 되는 상황이더라도 반드시 알아둘 가치는 있다.

브라우저 지원을 위해 그리드 사용에 신경 써야 하는 이유

만약 여러분이 지원 브라우저에서와 완전히 동일한 사용자 경험을 미지원 브라우저에도 제공해야 한다면, 그리드 레이아웃이나 새로운 CSS를 꼭 사용해야 하는지 솔직하게 묻고 싶다. 원래 잘 작동하는 메서드를 선택하는 것이 여전히 유효한 접근 방법이기 때문이다.

그런데도 만약 단기적으로 ‘반드시 똑같아야 함’ 목록에서 한 무더기의 브라우저를 들어낼 각오까지 하고 있다면 높은 비중의 폴백과 함께 그리드 레이아웃의 사용을 고려할 수 있다. 특히 현재 진행하고 있는 개발이 긴 유통기한을 가질 예정이라면 더욱 그렇다. 나중에 폴백은 버려지고 오직 그리드 버전만 남게 될 테니 말이다.

미지원 브라우저에 간소화된 사용자 경험을 제공하는 일이 ‘지원’을 의미하지만, 그럼에도 불구하고 그리드 레이아웃이 있어야만 가능한 어떤 것을 하고 싶을 수 있다. 바로 그때가 그리드 레이아웃도 사용하면서, 동시에 그리드를 사용하지 않는 좋은 설계를 할 기회다.

폴백 테스트

마지막은 폴백 테스트에 관한 얘기다. 현실적인 유일한 폴백 테스트 방법은 CSS 그리드 미지원 브라우저를 사용하는 것이다. 그렇게 하기 위해 유형별로 각각의 컴퓨터를 모두 구비하는 대신, 마이크로소프트 가상머신을 다운로드하는 방법이 있다. 가상머신을 사용하면 미지원 IE의 각 버전을 테스트할 수 있다.

모바일에서 UC 브라우저를 다운로드하거나, 또는 윈도우나 가상머신에서 사용할 데스크톱 버전의 UC 브라우저를 사용할 수도 있다.

혹은 모든 종류의 브라우저를 실행할 수 있는 원격 가상머신인 브라우저스택^BrowserStack과 같은 툴도 있다. 비록 유료이긴 하지만 가상머신에서의 테스트 준비에 필요한 많은 시간을 아낄 수 있다.

기능 쿼리를 사용하여 그 브라우저에 존재하지도 않을 기능을 테스트하라고 권하는 사람들이 있다. 예를 들어 display: gridx의 지원 여부를 테스트하는 등의 일 말이다. 문제 될 건 없다. 그러나 브라우저가 그 기능을 지원하지 않는다는 명백한 사실은 외면한 채, 모든 그리드 코드를 기능 쿼리 안에 집어넣는 일을 하게 된다. 이 경우 일부 그리드 코드가 기능 쿼리의 외부에서 종료된 사실을 인지하지 못함으로써 쉽게 거짓 양성^{false positive}(또는 1종 오류^{type I error})의 결과를 얻게 될 것이다. 심지어 단지 빠른 확인을 위한 경우라도 실제 브라우저에서 테스트하기를 권한다.

참고 자료

여기에 이 글에서 참고한 문서의 URL을 포함해, 새 레이아웃을 활용하면서도 여러 브라우저를 지원하는 데 도움이 될 추가 자료를 모아 놓았다. 또 다른 좋은 자료가 있거나 혹은 까다로운 특정 이슈를 만나게 될 경우 질의 목록에 추가하기 바란다. 운영 사이트 관점에서 보면 그리드 레이아웃은 우리 모두에게 여전히 새로운 기술이다. 따라서 우리에게는 풀리지 않은 문제를 계속 관찰해야 할 의무가 있다.