CSS 그리드 레이아웃 모범 사례

CSS 그리드 레이아웃을 실제로 사용할 때 자주 하는 질문이 있다면 “어떻게 하는 게 제일 나은 방법이지?”일 것이다. 이 질문에 대한 간단한 답은 “명세에 정의된 레이아웃 제작 방식을 사용하라”는 것이다. 명세의 어떤 부분을 사용할 것인지, 플렉스박스 같은 다른 레이아웃 제작 방식을 그리드와 어떻게 결합할 것인지는 여러분과 여러분 팀이 작업하는 방식에 따라, 그리고 만들려는 대상에 따라 달라진다.

이 질문에 조금 더 깊이 들어가보자. 레이아웃을 작성하면서 ‘모범 사례’에 대한 요청이 예전과는 너무나도 달라진 레이아웃 제작 방식에 대한 자신감 결여를 반영하는 건 아닐까 생각한다. 그리드를 설계 의도와 달리 사용하고 있는 건 아닌지, 그리드를 사용해야 하는 상황에서 사용하지 못하고 있는 건 아닌지 하는 걱정에서 온 걸 수도 있다. 아니면 구식 브라우저 지원이나 현재의 개발 방식에 그리드가 적합한가에 대한 우려에서 왔을 수도 있다.

이 글에서는 모범 사례로 삼을 만한 몇 가지 내용을 소개한다. 굳이 걱정하지 않아도 될 다른 사항에 대해서도 살펴본다.

 

설문조사

이 글을 작성하기 위해 그리드 레이아웃을 업무에서 사용하는 사람들이 그리드 레이아웃을 사용하는 방법, 사용하면서 겪는 문제, 그리드 레이아웃을 좋아하는 이유, 그리드 레이아웃과 관련한 공통된 질문, 그리드 레이아웃 제작 방식을 알고 싶었다. 그래서 간단한 설문조사를 하여 그리드 레이아웃을 사용하는 방법과 특히 좋아하는 점과 어려웠던 점 등을 물어보았다.

이 글은 설문조사를 통해 얻은 응답 중 일부를 참조하거나 인용하고 있다. 그뿐만 아니라 본문에서 설명한 기술에 관해 더 많이 찾아볼 수 있도록 관련 링크도 포함했다. 나중에 안 사실이지만 설문조사 응답에는 살펴볼 만한 가치 있는 내용이 너무 많아서 글 하나에서 다루기엔 벅찰 정도였다. 이에 관해서는 나중에 다른 글을 통해 다룰 예정이다.

 

접근성

만약 그리드 명세를 사용할 때 주의해야 할 부분이 있다면 콘텐츠의 재정렬을 유발하는 모든 것이 이에 해당할 것이다.

제작자들은 시각적인 콘텐츠 재정렬 용도로만 순서와 그리드 배치 속성을 사용해야 할 것이다. 논리적인 콘텐츠 재정렬을 위해 사용해서는 안 된다. 이러한 기능을 사용해 논리적인 재정렬을 수행하려는 스타일시트는 부적절하다.

– 그리드 명세: 재정렬과 접근성

사실 그리드에만 국한되는 문제는 아니지만 그리드에서는 콘텐츠 재정렬이 워낙 쉽다 보니 문제가 더 커졌다. 그렇지만 그리드든 플렉스박스든 혹은 절대 좌표 설정이든 콘텐츠를 재정렬하는 방법을 사용한다면 시각적인 표현과 문서 내의 콘텐츠 구조에 괴리가 발생하지 않도록 주의를 기울여야 한다. 키보드로만 문서를 탐색하는 사람들과 화면낭독기는 화면에 표현된 순서가 아닌 소스 코드에 있는 순서에 따라 콘텐츠를 탐색한다.

특히 주의해야 할 때는 flex-direction을 사용해 플렉스박스를 역순으로 표현할 때다. 플렉스박스와 그리드의 order 속성을 사용할 때도 주의가 필요하다. 어떤 방식을 사용했든 그리드 아이템을 배치할 때 그리드 아이템이 문서의 논리적인 순서를 벗어난다면 조심해야 한다. grid-auto-flow를 사용해 그리드를 밀집하여 배치할 때도 마찬가지로 주의해야 한다.

이 문제에 관해 더 알고 싶다면 다음 문서를 추천한다.

그리드 레이아웃과 접근성^{Grid Layout and Accessibility} – MDN

플렉스박스와 키보드 탐색의 괴리^{Flexbox and the keyboard navigation disconnect}

 

어떤 그리드 레이아웃을 사용해야 할까?

그리드에는 너무 많은 선택지가 있어서 코드를 작성할 때 일관성을 유지하는 게 어려웠다(이를테면, 그리드 기준선에 이름을 붙일 것인가 말 것인가, grid-template-areas를 정의하는 법, 폴백, 미디어 쿼리 등). 그래서 팀 전체가 이를 관리했다.

– 미쉘 바커, wbsl.com 제작 

처음 그리드를 살펴볼 때는 레이아웃 제작 방식이 너무 많아서 힘들게 느낄 수 있다. 하지만 결국은 일련의 그리드에 다른 그리드를 배치하는 작업일 뿐이다. 만들려는 레이아웃, 여러분과 여러분의 팀에게 적합한 방식에 따라 선택하면 된다.

옳은 방법도, 틀린 방법도 없다. 다음에서는 자주 헷갈릴 만한 주제를 몇 가지 골랐다. 이전 글 ‘그리드 이해와 문제점 ^{Grid Gotchas and Stumbling Blocks}’에서 헷갈릴 만한 몇 가지 영역을 다루기도 했다.

 

묵시적/명시적 그리드 중 무엇을 사용해야 하나?

grid-template-columns와 grid-template-rows를 사용해 정의된 그리드는 명시적 그리드^{Explicit Grid}라고 한다. 명시적 그리드는 그리드의 기준선에 이름을 붙일 수 있으며 -1을 사용해 끝 선을 선택할 수도 있다. 명시적 그리드는 앞서 설명한 동작을 수행하고 싶을 때 사용할 수 있고, 설계된 레이아웃에서 정확한 위치에 그리드 기준선을 배치하고 트랙의 크기를 정확하게 설정하고 싶을 때도 사용할 수 있다.

나는 행 트랙^{row tracks}에 묵시적 그리드^{Implicit Grid}를 더 자주 사용한다. 열을 정의하고 나면 행의 크기는 자동으로 조정되거나 콘텐츠의 크기에 따라 늘어나기도 한다. 묵시적 그리드에서도 grid-auto-columns와 grid-auto-rows를 사용해 크기를 조정할 수 있지만, 명시적 그리드처럼 모든 것을 정의할 때보다는 조정할 수 있는 여지가 적다.

표시할 콘텐츠의 양을 정확하게 알고 있어서 필요한 열과 행의 개수를 정확히 알 수 있다면 명시적 그리드를 만들 수 있다. 콘텐츠의 정확한 양은 알 수 없지만 양에 상관없이 콘텐츠를 열과 행으로 표현하고 싶다면 묵시적 그리드를 사용하는 게 좋다.

그렇지만 두 방식은 조합해서 사용할 수도 있다. 아래의 CSS는 명시적 그리드 명시적 그리드로 3개의 열과 3개의 행을 표현했다. 이 3개의 열은 순서대로 다음과 같은 특징이 있다.

•  트랙의 높이는 최소 200px이고 콘텐츠가 늘어나면 높이도 더 길어진다.
•  트랙의 높이가 400px로 고정되어 있다.
•  트랙의 높이는 최소 300px이고 콘텐츠에 따라 늘어난다.

 

나머지 콘텐츠는 묵시적 그리드로 구현한 행 안에 담았다. 묵시적 그리드에는 grid-auto-row 속성을 사용해 각 트랙의 높이를 최소 300px로 설정하고 최댓값을 auto로 정하여 콘텐츠에 따라 늘어날 수 있도록 했다.

열의 개수가 유동적인 유연한 그리드

Repeat 표기법과 autofill, minmax를 사용하면 컨테이너의 크기에 딱 맞을 때까지 열의 개수가 자동으로 증가하는 패턴을 만들 수 있다. 덕분에 일정 수준까지는 미디어 쿼리^{Media Queries}를 사용하지 않아도 될 정도다. 이 기법을 설명한 동영상은 여기서 찾을 수 있고, 나의 최근 글 ‘2018년 반응형 디자인을 위한 미디어 쿼리 사용^{Using Media Queries For Responsive Design In 2018}’에서도 비슷한 개념을 볼 수 있다.

이 기법은 공간이 충분하지 않은 경우 콘텐츠가 먼저 나온 다른 콘텐츠 밑으로 나타나더라도 상관없을 때, 그리고 크기에 있어서 유연성을 많이 부여하고 싶을 때 사용한다. 열을 최소 크기로만 표현하고 싶은지 아니면 남는 공간을 자동으로 채우고 싶은지(auto fill)를 먼저 생각해야 한다.

설문조사에 있던 의견을 읽다 보면 정말로 열의 개수가 고정된 그리드가 필요해서 이 기법을 사용했는지 명확하지 않을 때가 있었다. 열의 개수가 특정 너비에서만 유동적이라면 열의 개수를 고정한 상태에서 작업 후 미디어 쿼리를 통해 필요한 경우 그리드를 재정의하도록 하는 편이 auto-fill이나 auto-fit을 사용하는 것보다 낫다.

 

트랙의 크기는 무엇으로 정해야 하는가?

트랙의 크기에 관해서는 ‘그 상자는 얼마나 클까? 그리드 레이아웃에서의 크기 이해 ^{How Big Is That Box? Understanding Sizing In Grid Layout}’라는 글에 자세히 설명했다. 트랙의 크기를 정할 때 사용할 방법에 관한 질문을 종종 받는다. 특히 퍼센트 단위와 fr 단위의 차이에 관한 질문이 많았다.

명세에 기술된 대로 fr 단위를 사용했다면 퍼센트를 사용한 것과는 다를 수밖에 없다. fr 단위는 사용 가능한 공간을 분할하기 때문이다. 크기가 더 큰 트랙을 나중에 추가하더라도 fr 단위는 잘 동작한다. 추가된 트랙이 조금 더 큰 공간을 가져가고 남아 있는 공간을 나머지 트랙들이 나눌 것이다.

그리드 컨테이너에 있는 모든 공간을 fr 단위가 분할하게 하려면 minmax()를 사용해서 최소 크기를 0으로 하면 된다.

따라서 fr 단위는 다음과 같은 두 가지 경우에 사용할 수 있다. 첫째, 자동으로 공간을 일정 비율로 분할(기본 동작)하고 싶을 때. 둘째, 트랙을 균등한 크기로 표현하고 싶을 때. 나는 보통 fr 단위를 사용해서 크기를 먼저 설정한 후 고정 너비 트랙이나 간격을 사용한다. 퍼센트 단위를 사용할 때는 그리드 컴포넌트를 다른 레이아웃 제작 방식으로 만들어진 기존 레이아웃에 추가할 때뿐이다. 만약 그리드 컴포넌트를 퍼센트 단위를 사용한 플롯(float) 기반 또는 플렉스(flex) 기반 레이아웃과 함께 사용하고 싶을 때는 퍼센트 단위를 그리드 레이아웃에서도 사용해서 모든 레이아웃이 같은 방법으로 크기를 설정할 수 있게 한다.

 

자동 배치를 사용할까, 직접 위치를 설정할까?

간혹 아이템 한두 개만 레이아웃에 직접 배치하고 나머지는 콘텐츠 순서에 따라 자동으로 배치하고 싶을 때가 있다. 이 사례는 소스 코드에 나온 순서와 시각적인 표현에 괴리가 있는지 확인해보기에 좋다. 콘텐츠의 위치가 자동 배치(auto-placement) 방식에 따라 설정된다면 아마 잘 정돈되었다 볼 수 있을 것이다.

하지만 나는 아이템을 배치해야 할 때는 아예 모든 아이템에 일일이 위치를 설정하곤 한다. 이렇게 하면 누군가 해당 문서에 다른 내용을 추가하고 그리드 자동 배치를 통해 추가된 내용을 잘못된 곳에 두어 그게 레이아웃을 망칠 상황이 되어도 이상한 문제가 생기지 않는다. 직접 전부 배치를 한 뒤에 아이템을 추가하면 그리드는 추가된 아이템을 배치된 아이템 이후에 비어 있는 그리드 셀에 둔다. 결과가 원했던 것과 다를 수는 있다. 하지만 새로 추가한 아이템이 작성한 레이아웃 끝에 자리 잡는 편이 중간 어디에서 툭 튀어나와서 주변의 다른 아이템을 밀어내는 것보다는 더 나을 것이다.

 

어떤 방법으로 위치를 설정할까?

그리드 레이아웃을 사용하면 결국 모든 콘텐츠는 기준선을 따라 자리를 잡게 된다. 그 외의 다른 것들은 이런 배치를 도울 뿐이다.

기준선에 이름을 붙이고 싶거나 다른 레이아웃 형식과 함께 그리드를 사용하고 싶다면 그리드 템플릿 영역^{Grid Template Areas}을 사용하자. 나는 작은 컴포넌트를 표현할 때 그리드 템플릿 영역을 즐겨 사용한다. 하지만 옳은 길도 없고 틀린 길도 없다. 여러분에게 적합한 방법을 골라 사용하면 된다.

 

다른 레이아웃 제작 방식과 그리드를 함께 사용하기

그리드 레이아웃은 만병통치약이 아니다. 그리드 레이아웃은 특정한 형태, 다시 말해 2차원 레이아웃을 위해 설계되었다. 다른 레이아웃 제작 방식도 여전히 사용할 수 있으며 상황에 가장 적절한 방식을 찾아야 한다.

원래의 설계 의도와 다른 방식으로 기존 레이아웃 제작 방식을 사용해온 사람들에게는 이 부분이 정말 어려울 것으로 생각한다. 이제는 한 걸음 뒤로 물러나서 여러 레이아웃 제작 방식들이 어떤 문제를 해결하기 위해 설계되었는지 생각해보고 원래 의도된 대로 그 제작 방식을 사용하려고 노력할 때다.

그리드와 플렉스박스의 차이에 관한 글을 자주 썼다. 하지만 그와 상관없이 앞으로도 사람들은 나에게 무엇을 사용해야 하는지 계속 질문할 것이다. 두 레이아웃 방법 모두 좋은 선택일 때가 많다. 따라서 무엇을 선택할지는 여러분에게 달려 있다. 아무도 여러분에게 그리드 대신 플렉스박스를 선택하라거나 플렉스박스 대신 그리드를 사용하라고 윽박지르지 않는다.

실무에서 나는 아이템의 크기는 자연스럽게 설정하되 주변 다른 아이템을 밀어내는 식으로 레이아웃을 강하게 제어하고 싶은 컴포넌트를 제작할 때 플렉스박스를 자주 사용한다. 그 외에도 플렉스박스와 그리드에서 사용할 수 있는 상자 정렬(Box Alignment) 속성을 사용해 정렬할 때 플렉스박스를 사용하곤 한다. 플렉스 컨테이너에 자식 아이템을 하나만 두고 자식 아이템을 정렬하는 경우도 있다.

플렉스 아이템에 퍼센트 너비를 추가하고 flex-grow를 0으로 설정하기 시작했다면 플렉스박스가 아닌 다른 레이아웃 제작 방식이 더 적합한 상황일 수 있다. 플렉스 아이템에 퍼센트 너비를 추가할 때는 보통 2차원 배열이 필요할 때가 많았는데, 아이템의 2차원 배열은 그리드를 사용하기에 적합한 상황이기 때문이다. 하지만 두 방법 모두 사용해보고 주어진 콘텐츠나 디자인 패턴에 가장 적합한 것이 무엇인지 확인해보자. 두 방법 모두 시도해본다고 해서 문제가 될 공산은 적다.

 

중첩된 그리드 아이템과 플렉스 아이템

역시 설문조사에서 자주 나왔던 질문이지만, 그리드 아이템을 그리드 컨테이너로 만들어서 그리드 안에 다른 그리드를 중첩하는 건 전혀 문제가 없다. 플렉스박스도 마찬가지다. 플렉스 아이템을 플렉스 컨테이너로 만들어도 아무런 문제가 없다. 또한 그리드 아이템을 플렉스 컨테이너로 만들 수도 있고 플렉스 아이템을 그리드 컨테이너로 만들 수도 있다. 역시 아무런 문제가 없는 사용법이다.

현재 허용되지 않은 동작은 그리드 안에 다른 그리드를 중첩해두고, 내부에 있는 그리드가 바깥에 있는 그리드에 정의된 트랙을 사용하는 것이다. 이게 가능해지면 굉장히 유용할 것이므로 그리드 명세 레벨 2에 제안된 서브 그리드가 이 문제를 해결해줄 것으로 기대한다. 현재 중첩된 그리드는 새로운 그리드가 돼버리므로 크기를 설정할 때는 부모 그리드의 트랙을 벗어나지 않도록 주의를 기울여야 한다.

 

한 페이지에 여러 그리드 표시

설문조사에서 몇 번 등장해서 조금 의외라고 느꼈던 것이 있다. 어떤 사람들은 그리드는 메인 레이아웃을 표현할 때만 사용해야 하며 한 페이지에 여러 그리드를 사용하는 것은 좋지 않다는 생각을 하고 있었다. 사실은 그렇지 않다. 그리드는 얼마든지 원하는 만큼 사용해도 된다. 그리드는 큰 틀을 만들 때도 작은 콘텐츠를 표현할 때도 사용할 수 있다. CSS 그리드를 사용해서 그리드 형태로 만드는 게 합리적인 콘텐츠라면 말이다.

 

폴백과 구식 브라우저 지원하기

@supports와 그리드를 함께 사용하면 다양한 레이아웃을 더 잘 다룰 수 있다. 또한 이 방법은 점진적 개선 방식과도 잘 어우러진다. 즉, 최신 기술을 지원하지 않는 브라우저가 콘텐츠에 접근하는 것을 제한하지 않으면서도 최신 브라우저에서는 더 나은 결과를 보여줄 수 있다는 뜻이다.

– 조 램버트, rareloop.com 제작 

 

실시했던 설문조사에서 많은 사람이 구식 브라우저에 관해 언급했다. 그러나 구식 브라우저를 지원하는 것이 어렵다고 느끼는 사람과 피처 쿼리 및 그리드를 대신할 수 있는 여러 레이아웃 제작 방식 덕분에 구식 브라우저 지원이 어렵지 않다고 생각하는 사람의 수는 거의 비슷했다. 나는 예전에 이러한 폴백^fallback(최신 기술을 사용할 수 없는 경우 이를 대체하기 위해 구식 기술을 사용해 마련해두는 대비책 — 역자)을 만드는 기법에 관해 ‘CSS 그리드로 미지원 브라우저 지원하기^{Using CSS Grid: Supporting Browsers Without Grid}’에서 기술한 적이 있다.

최신 브라우저들은 일반적으로 예전 버전에서보다 지원하는 기술 수준이 상당히 비슷해졌다. 실제로 확인할 수 있는 ‘브라우저 버그’는 굉장히 적으므로 HTML과 CSS를 올바르게 작성했다면 한 브라우저에서 봤던 화면이 보통은 다른 브라우저에서도 똑같이 표현된다.

물론 어떤 브라우저는 특정한 명세나 명세의 일부를 지원하지 않는 경우도 많다. 다행히 그리드 레이아웃은 이런 브라우저에서도 완벽히 지원되는 편이라 짧은 시간 내에 다른 브라우저와도 호환될 것으로 생각한다. 따라서 테스트할 때는 그리드를 지원하는 브라우저와 그렇지 않은 브라우저로 나누어 진행하는 것이 좋다. IE10과 IE11을 위해 -ms 접두어가 붙은 속성을 남겨두기로 했다면 확인할 브라우저의 종류를 하나 더 늘려야 할 것이다.

최신 그리드 레이아웃을 지원하는 브라우저(IE 제외)는 피처 쿼리도 지원한다. 즉, 피처 쿼리를 사용해 그리드 지원 여부를 확인할 수 있다.

 

그리드를 지원하지 않는 브라우저에서 확인하기

그리드 레이아웃을 지원하지 않는 브라우저를 위해 폴백(fallback)을 사용할 때는(또는 IE10/11을 위해 -ms 접두어가 붙은 속성을 사용할 때), 이 브라우저는 그리드 레이아웃을 어떻게 보여주는지 확인해야 할 것이다. 이를 위해 원하는 브라우저에서 여러분의 사이트를 확인할 방법이 있어야 한다.

나는 무의미한 값이나 오타가 포함된 grid 값을 지원하는지 확인하여 피처 쿼리(Feature Query)를 일부러 망쳐 보는 방식은 사용하지 않는다. 이 방식은 스타일시트가 매우 단순하고, 그리드 레이아웃과 관련된 모든 코드를 피처 쿼리 안에 넣을 때만 가능하다. 취약하기도 하고 시간도 많이 소비되는 방법이다. 특히 그리드를 광범위하게 사용하고 있는 경우라면 더 그렇다. 게다가 구식 브라우저는 그리드 레이아웃은 물론이고 그 외에도 지원하지 않는 CSS 속성이 많다. “모범 사례”를 원한다면 여러분의 작업이 뛰어나다는 것을 확인할 수 있는 좋은 환경을 만들도록 하자.

몇 가지 방법을 통해 폴백을 확인할 수 있는 적절한 환경을 설정할 수 있다. 가장 쉬운 방법은 브라우저 스택^BrowserStack과 같은 서비스를 사용하는 것이다. 인터넷 속도가 빨라야 하고 서비스 이용료도 내야하지만 말이다. 이 서비스를 사용하면 실제 웹 브라우저에서 웹사이트를 볼 수 있다. 심지어 여러분의 컴퓨터에서 개발하고 있는 사이트도 볼 수 있다. 브라우저 스택은 오픈소스를 위한 무료 계정도 지원하고 있다.

여러분의 컴퓨터에서 테스트하는 경우에는 버추얼 머신^{Virtual Machine}을 사용해 대상 브라우저를 설치하는 방법을 권장한다. 마이크로소프트는 IE8부터 다양한 버전의 IE와 Edge를 버추얼 머신에 담아 무료로 제공하고 있다. 물론 그리드를 전혀 지원하지 않는 구식 브라우저가 설치된 버추얼 머신도 다운로드할 수 있다. 그리드를 지원하지 않는, 예컨대 파이어폭스 51 이하 버전의 브라우저도 설치할 수 있다. 구식 파이어폭스를 설치한 후에는 여기서 설명한 방법에 따라 자동 업데이트 기능을 끄는 것도 잊지 말자. 그렇지 않으면 구식 파이어폭스가 최신 버전으로 자동 업데이트되어버린다.

이제 버추얼 머신을 사용해 IE11과 그리드 미지원 파이어폭스에서 사이트를 철자가 틀린 값을 사용할 때보다 훨씬 안정적으로 테스트할 수 있다. 설정에 한 시간쯤 걸리겠지만 이후에는 폴백을 확인할 수 있는 정말 좋은 환경이 될 것이다.

 

오래된 습관 버리기

그리드 레이아웃을 처음 사용할 때는 배워야 할 개념과 속성이 너무 많았다. 플로팅 요소를 재설정하거나 컨테이너 div 안에 많은 걸 욱여넣는 등 내가 수년간 해왔던 그 모든 것을 잊는 게 제일 어려운 일이었다.

– 히데, hiddedevries.nl/en 제작

설문조사에 응답한 많은 사람이 오랜 습관을 버려야 할 필요성에 대해 언급하면서 CSS를 전혀 모르는 사람이 레이아웃 배우는 게 더 쉬울 것이라 응답했다. 일리가 있는 말이다. 직접 가르칠 때 보면 완전 초심자들은 그리드를 사용하는 데 문제가 별로 없지만, 숙련된 개발자들은 그리드에서 일차원적인 레이아웃 제작 방식으로 돌아가려는 경향이 강했다. float이나 플렉스 기반 그리드에나 필요한 행 래퍼(row wrapper)를 추가한 ‘그리드 시스템’을 사용하려는 경우도 여러 번 봤다.

새로운 기술을 사용하는 데 두려워하지 마라. 여러 브라우저에서 확인해볼 수 있는 능력이 있고, 잠재적인 접근성 문제를 염두에 두고 있다면 크게 실수하기도 어렵다. 혹시 특정한 패턴을 만들 수 있는 좋은 방법을 발견하게 된다면 여러 사람에게 전파하라. 실무에서 그리드를 사용해본 경험이 부족한 건 모두 마찬가지다. 아직 찾아내고 공유할 내용이 굉장히 많이 있을 것이다.

그리드 레이아웃은 미디어 쿼리 이후 가장 흥미로운 CSS 개발 방법이다. 실제 개발자들의 요구사항을 충분히 고려하여 디자이너나 개발자 혹은 비슷한 일을 하는 사람이 실무에서 사용하기에도 매우 만족스러운 기술이다.

– 트리스 머드포드, trysmudford.com 제작

마지막으로 현재의 모범 사례를 짧은 목록으로 정리했다. 일하다가 해야 할, 혹은 하지 말아야 할 사례를 알게 된다면 댓글로 남겨주기 바란다.

1. 콘텐츠 재정렬 가능성에 최대한 주의하라. 시각적인 표현과 문서상의 순서에 괴리가 없는지 확인하라.
2. 로컬 또는 리모트 가상 머신에서 실제 브라우저를 사용해 확인하라.
3. 여전히 유효하고 쓸 만한 오래된 레이아웃 제작 방식은 잊지 말자. 똑같은 패턴을 다른 방식으로도 시도하라. 반드시 그리드를 사용해야 한다고 생각지는 말라.
4. 능숙한 프론트엔드 개발자로서 여러분은 레이아웃 작동 방식에 대해 선입견이 있을 수 있음을 인정하라. 새로운 제작 방식을 기존 패턴에 껴맞추듯 살펴보지 말고 완전히 새로운 관점에서 바라보도록 노력하라.
5. 계속 시도하라. 우리 모두는 이 분야에 처음이나 다름없다. 결과물을 확인하고 알게된 사실을 다른 이들과 공유하라.