이글루스 스킨을 만드는 것은 고문과도 같기 때문에 일종의 가학성(?) 행위에 가깝다고 봐도 될듯.
새로만든 스킨. Full bleed layout과 fixed top menu, dropdown menu를 제공한다. 레이아웃 제한 때문에 fixed top menu는 거의 이글루스로 치면 차세대급 기술.
발단은 이렇다. 요즘 웹디자인 트랜드는 Full bleed layout이다. 즉, 텍스트는 읽기 쉬운 너비인 600~700px을 유지하되, 사진은 최대한 크게 뿌려주는 형태의 디자인이다. 미디움도 이러한 형태를 사용하고 있으며, 많은 미니 블로그 시스템들이 이와 유사한 형태의 스타일을 제공한다.
Hassle-free Full Bleed with *:not()
Breaking out of container DIVs with this one weird trick
이 포스팅을 보면 이러한 Full bleed layout을 css로 손쉽게 적용하는 방법을 알려준다. 즉, :not 셀렉터를 통해서 full bleed로 화면에 뿌려줄 것만 걸러낼수 있다. 의외로 간단한 코드로 구현이 가능하여 호기심이 생겼다. (그리고 이것이 고생길의 시작이었다.)
1차시도 - :not
그래서 이글루스 스킨 하나 파서 :not을 넣었다. 그리고 모든게 다 잘 될줄 알았다.
잘 될리가 있나... 태생적 구조가 병신인 이글루스 인데.
52c26899959e58484b9cd35a4ff5771aeacc6ea1939a35d50fe88ba5a86aa31b
- 아..아.. 세상은 DIV로 가득해.
- 제발 paragraph는 P로 뿌려주세요!
- 할 수 있는 것은 DIV 만드는 것 밖에 없는데...
- 제발 paragraph는 P로 뿌려주세요!
:not 써먹는 것은 일단 실패. 모든 요소가 div로 감싸져있어서 아무런 의미가 없었다.
2차시도 - position: absolute;
결국 이미지만 일일히 찾아내는 방법 밖에 없었다. 그래서 파이프라인(?)을 마구파서 어떻게든 img와 iframe을 찾으려고 했다. 하지만 그럼 뭐하나, parent container의 너비가 이미 고정되어 있는데. 그래서 position:absoulte랑 margin-bottom hack을 사용해서 이미지 위치를 조정하려고 했다. Position:Absolute 사용시 날아가버리는 높이 수치를 퍼센티지 margin으로 메꿔넣는 방식이다. 하지만 이 경우 percent 치수를 쓰게 되기 때문에 사진의 중앙 정렬이 안되는 문제가 생겼다. 마이너스 margin으로 특정한 크기의 요소 위치를 중앙으로 맞춰놓으면 나머지 요소들의 위치가 전부 틀어저 화면에서 따로 노는 웃지 못할 일이 벌어졌다.
3차시도 - display:inline-block
결국 position:absolute는 포기. 어떻게든 사진을 중앙정렬 시키겠다는 집념(?)이 있었기 때문에 가장 흔하게 쓰이는, 하지만 원래 사용용도와는 먼 방법을 사용했다. 최근들어 뼈대만 놓고 CSS만 만지는 삽질을 해보았는데, 이런거 해보면서 요소의 사용용도고 뭐고 간에 그냥 그럴듯하게 보이고 문제 없이 돌아가기만 하면 그만이라는 사고방식이 생겼다. (애초에 뭐 CSS 스타일링이 그런 주먹구구 식이기도 하고). 그래서 parent container에 text-align:center 속성을 넣고 하위요소에 display:inline-block 속성을 써봤다. 중앙 정렬은 해결되었지만 너비가 작은 사진의 경우 본문과 붙어 버리는 이해 안 가는 상황이 발생했다. 결국 또 실패
4차 시도 - display: flex
요새 핫한 (하지만 css grid가 크롬57 부터 지원되면서 한물간) flexbox를 써보았다. 결과는 아주 좋았다. flex-direction을 column으로 설정하고, 모든 요소에 margin:auto를 적용하니 그낭 알아서 다 중앙정렬이 되어버렸다. 어짜피 반응형이 아니기 때문에 컨테이너의 최대 너비는 1600px로 설정했다. 참고로 이글루스의 시스템은 완전 구식이라 최대 사진 크기가 1600px가 한계다. (티스토리는 제한이 없지만 개인적으로 2048px 까지 시도해봤다) 본문의 너비를 600px로 맞추고 왼쪽에 마이너스 마진 500px, 오른쪽에 플러스 마진 500px를 줘서 사진을 중앙에 고정시켰다. 삽질이 드디어 끝났다고 생각하는 찰나, 다른 페이지를 띄워보니 역시 사진이 이리저리 움직이며 난리를 치고 있었다. 결국 이것도 실패.
5차 시도 - 컨테이너 너비 설정
margin:auto를 너무 맹신한게 화근이었다. 마이너스 마진으로 밀고 당기다 보니 몇몇은 완전히 이상한 수치가 적용되는 일이 생겨버린 것. 그래서 이것을 어떻게 해결할까 고민을 했다. 그리고 본문 코드를 면밀히 분석하여 어떻게 하면 img 요소만 집어낼수 있을까라는 방법을 궁리하기 시작했다. 가만보니 모든 이미지는 div style="text-align:center" 라고 되어있는 요소로 둘러싸여 있었다. 엄청나게 무식한(?) 방법이지만 attribute selector를 통해 일일히 문자열을 대조하여 요소를 선택하기로 했다. 덕분에 사진을 포함하고 있는 div를 제외하고 모든 div의 크기를 600px로 고정할 수 있었다. 사진을 포함하고 있는 요소는 너비를 강제로 1600px로 고정시킨 다음, 왼쪽으로 -500px margin을 넣어 중앙으로 고정시켰다. 컨테이너에는 display:flex 속성을 넣고, 내부에 있는 img에 margin:auto 속성으로 항상 중앙고정을 시켰다. 이제 모든게 다 원할하게 되는 것 같았다. 견본 블로그에서 모든 사진이 문제없이 다 중앙정렬이 되었다. 그러나...
평소에 사용하던 블로그에 적용했더니 어떤 글은 적용이 되고 어떤 글은 적용이 되지 않았다. 아니, 적용이 되었는데 margin이 이상하게 꼬였다. 이유는 알 수 없지만 margin:auto를 중첩해서 사용하다 보니 수치를 가져오는 기준점이 명확하지 않아 margin이 제멋대로 적용되는 문제가 생겨버렸다. 이런경우는 듣도 보도 못했지만 여러가지 실험을 거쳐보니 margin의 문제가 분명했다. position:relative를 남발하면 애써 조정해보았지만 별 소용이 없었다. 컨테이너에 text-align:center를 써먹어 보았지만 여전히 레이아웃이 뒤틀어졌다. 그래서 거의 성공했지만 결국 실패.
6차 시도 - 기상천외한 방법 시도
css box model 이라는게 참 오묘하다. 무슨 말이냐면, 언제나 내가 바라는대로 되는 법이 없다. 늘상 지혼자서 미쳐서 날 뛰고 수 많은 hack으로서 제어해야 되는게 현실. 그래서 잠시 고민을 거듭하다 (하루정도 작업 안하고 냅뒀다. 잠재의식이 대신 고민해주길 바라며) 생각해낸 것이 border를 사용하는 것. 애초에 padding 이나 margin이 전부 정렬시 문제를 일으키고 중앙정렬이 안 되게 만들었기 때문에 되도록이면 두가지 요소는 피하려고 애썼다. 이를 피하려고 reset style과 normallize를 사용했지만 별 차도가 없었다. 증상이 완화 되었지만 완전히 줄어들지는 않았다.
일단 모든 margin:auto를 다 없앴다. 레이아웃에 어떠한 영향도 미치지 않도록 했다. 이렇게 하면 모든 요소가 왼쪽으로 정렬이 된다. 애초에 flexbox는 margin:auto 없이 중앙 정렬이 안 된다. 그 다음 왼쪽에 500px짜리 border를 넣고, box-sizing을 content-box로 바꾸었다. 이렇게 하면 padding도 아닌 것이 margin도 아닌 것이지만 어쨌든 정렬은 된다. 그 다음 border 크기 만큼 모든 이미지 요소에 마이너스 margin을 넣어서 정렬을 시켰다. margin:auto를 쓰지 않았기 때문에 어떠한 정렬 오류도 발생하지 않았으며 사진의 크기에 관계 없이 무조건 중앙 정렬이 되었다.
결국 6번의 시행착오 끝에 이 말도 안되는 스킨이 만들어졌다. 이틀 삽질했는데, 가만 생각해보면 내가 왜 이딴 짓을 했을까라는 후회가 엄습한다.
사실 이 스킨은 처음으로 Windows 10에서 만든 스킨이다. VS code와 prepros를 사용하였다. 원래 macOS + coda + codekit이 주로 사용하는 워크플로 였는데, 그냥 요새 macOS도 마음에 안들고 맥에서 탈출하고 싶어서 바꾸게 되었다. 사실 맥을 쓰는 이유도 개발하는데 편하다는 이유인데, 최근 들면서 갈수록 macOS의 메리트가 사라져가는 중이다. 결국 이러다 xcode / FCPX / LGPX 사용하는 사람만 macOS에 남지 않을까라는 생각이 든다. 요즘은 뭐든지 윈도우가 더 빠르고 드라이버 지원도 잘 된다.
VS code 짧은 감상
- 빠르다
- 안정성이 좋다
- theme는 별로 이지만 그냥저냥 쓸만한 편
- 하지만 마소 작품 아니랄까봐 꼭 한두개씩 병신같은 부분이... (특히 자동 완성)
도대체 누가 widow라는 css를 쓰는걸까. 마이크로소프트 너네 우선순위가 뭔지 모르지?
Prepros도 기대 보다 좋았다. 오히려 컴파일은 codekit보다 훨씬 빨랐다. 물론 scss 파일이 20개가 넘어가는 티스토리 스킨이라면 이야기가 달라질 수 도 있겠지만, 아직까지는 합격.
하... 워드프레스 블로그 이전하는데나 매진해야지...
