본문 바로가기

Works/Blog Skin

이글루스 스킨 제작 일지

이글루스 스킨 제작 일지


이글루스 스킨을 제작하면서 만나는 별의 별 개같은 경우를 아주 상세히 열거하고, 어떻게 우회를 했는지도 간략하게 설명해보려 한다. 


일단 이글루스는 head 부분을 수정할 수 없기 때문에 meta 태그를 쓸 수가 없고, 따라서 view port를 수정할 수 없기 때문에 반응형 스킨의 적용이 불가능하다. 걍 동명의 티스토리 스킨 scss가 아까워서(사실은 입대 전에 잉여력 폭발해서) 이글루스에 적용시도를 해보았으나 티스토리 만들때 보다 더 작업이 많아졌다 -_-


이글루스는 스킨의 기본폰트가 굴림으로 뜬다 (님들아 자비 좀…) 티스토리는 돋움이 기본 폰트고, 네이버는 돋움 기본에 나눔고딕 설치 되어있을시에는 나눔고딕으로 로드를 하게 설정이 되어있다. 제발 좀… 굴림 좀 쓰지말자. 


스킨 곳곳에 em,abbr 같은 요소가 사용되었는데, 뭐 웹 표준이니까 굳이 태클은 안 걸겠지만 남들이 안 쓰는 것은 좀 안 써줬으면 하는 바램이다. 안 바뀐거 찾아서 바꾸기 졸 귀찮. 어짜피 html 수정도 거의 지원 안 하는 거나 마찬가지면서 더럽게 다양한 태그 쓰네.


댓글/ 트랙벡 헤딩 테러댓글/ 트랙벡 헤딩 테러

아랫부분에 heading 3으로 댓글과 트랙백을 대문짝 만하게 굳이 적어야 하는지 묻고 싶다. -_-; 하다 못해 paragraph로 넣었으면… 아니다, 말을 말자.


제발 zum 브랜딩 도배 좀 하지 말았으면 좋겠다… 도배 안 해도 알 사람은 이글루스가 zum 소속 이라는거 다 안다. 어디 구글 블로거나 티스토리가 브랜딩 도배를 하는 것을 보았는가?


인풋에 이미지 쑤셔 박기인풋에 이미지 쑤셔 박기


아오 시발 ㅋㅋㅋㅋ 진짜 매번 이글루스 스킨 만들때마다 빡치는거. 어떤 미친새끼가 input안에 src로 img를 넣는데냐(한숨)... 물론 이짓은 해도 w3c 권고사항 위반은 아니지만 사람이라면 하면 안되는 짓이다. 걍 input을 넣고 css로 스타일을 지정하면 되잖아… 도대체 왜 이런 짓을 하지? 손가락이 생기다 말아서 css도 못 씀?


도저히 눈뜨고 볼 수가 없어 인라인 이미지는 padding으로 밀어내고 svg 심어버림. 훨씬 보기 낫네 ^오^


이유는 알 수 없지만 스킨수정시에 css를 새로 넣어주지 않으면 스킨의 css가 로드 되지 않는 아주 괴상한 버그가 생겼다. 어짜피 수정 없이도 아~~~주 잘 쓸 수 있도록 완성도가 높게 만들었기 때문에 이 버그는 수정하지 않고 그냥 둔다. 어짜피 내 잘못이 아니라 이글루스 구조가 지랄 같아서 발생하는 문제다. 참고로 거의 95% 똑같은 CSS를 사용하는 티스토리 스킨은 아무 문제 없이 구동 잘 만 된다. 


+3월 6일자 추가내용

이글루스는 CSS를 2070줄 까지 제한을 걸고 있다. 본 스킨은 5천 줄이 넘어가므로 중간에 짤린다.


혹시나 스킨 수정 할 일이 있으면 CSS 파일을 다시 덮어 씌워주면 된다. 


위젯 이동은 상당히 힘들어졌다. 아무리 봐도 CSS animation과 이글루스 스킨에디터가 충돌을 일으키는 것 같다. 그래서 에디터 상에서는 스킨이 보이지도 않고 위젯을 옮기려면 마음대로 되지 않는다. 스킨은 이글루스 2단 오른쪽 사이드바 형태를 기본으로 하고 있으니, 거기서 사이드바 배치를 하고 스킨을 덮어 씌워버리면 별 상관이 없다. 이미 테스트 해보았으니 이 방법 고대로 하면 됨.


h2에 span 넣기h2에 span 넣기잼


h2안에 span을 넣어서 메뉴 구성을 했음… ㅋㅋㅋㅋ...ㅋㅋ..ㅋ... 이제 욕할 힘도 안난다.


리셋 스타일 적용된 모습리셋 스타일 적용된 모습


도대체 무슨 짓을 했길래 검색 페이지에서 CSS가 리셋 되는 걸까? 설마 페이지 스타일을 리셋스타일을  넣고 그걸 유저스타일 보다 나중에 불러오게 해놓은 것은 아니겠지? 그래… 아마 아닐거야 머리에 총 맞지 않은 이상 그런 또라이 짓을 할리가 없지.


그딴짓 할시간 없다.그딴짓 할시간 없단다.


!important 잼!important 잼


그리고 검색 결과에 !important 쓴놈 나와라. 한대 맞자 씨발놈아. 


CSS3 도입률 98%에 달하기 때문에 IE8이하는 지원 하지 않는다. 하기도 싫고, 할 마음도 없고 가장 중요한건 할 시간도 없다. (입대전 황금 같은 시간에 IE 구버전 호환 신경쓰고 있으랴?)


viewport 적용 시도. 앞서 말했듯 이글루스는 head를 수정할 수 없기에 meta 태그를 입력할 수가 없다. 설사 div.body 안에 meta 태그를 넣는다고 해도 지워버린다. 이전에 이글루스에서 구글 웹 마스터 도구를 쓰기 위해서 메타 태그를 넣어 보았을 때도 실패했다. 이글루스에서 플러그인으로 지원하는 광고 플랫폼이 올블릿이고, 2월 초부터 올블릿이 악성코드를 포함하고 있어 사파리/오페라/파이어폭스/크롬에서 차단이 되었던 것을 감안할때, 구글 웹마스터 도구가 없으면 올블릿을 때어내도 악성코드 유포 블로그 해제가 되지 않는다.


구글에 악성코드 유포 블로그로 낙인 찍힌 블로그는 불이익을 당하며, 웹마스터 도구가 없을때는 구글이 다시 인덱싱을 해주기 전까지 막연히 기다려야 한다. 웹마스터 도구가 설치되어있다면 재검토 요청을 할 수 있으나 이글루스는 재검토 요청을 할 수 없는 것이다. 이럴거면 구글 웹마스터 도구 인증 코드만 따로 넣을 수 있게 해주던가 무슨 해결방법이 필요하다. IE를 제외한 모든 웹 브라우저가 구글의 악성코드 탐지 솔루션을 체용하고 있는데 생각이 있다면 좀 고칠것.


이글루스의 운영방침이 좀비 블로그 양성을 막기 위해서 유저스크립트를 제한하는데, 정작 자신들이 제휴한 올블릿이 악성코드 덩어리인 좀비 플러그인이라는게 웃기지 않은가?


<meta name="viewport" content="width=device-width, initial-scale=1.0" />


현재 웹킷계열/블링크 계열 브라우저는 meta 태그를 이용해서 viewport를 설정하고 있다. 이 viewport 명시가 없으면 모바일 브라우저에서도 그냥 pc화면이 떠버린다. 사파리에서 처음 적용했고 크롬, 오페라, 파이어폭스가 모두 따라서 적용한 방식인데, 정작 W3C에서는 meta 태그를 올바른 용도로 사용하지 않고 있다고 하며 불만이 많다. W3C 측의 권고 안은 CSS를 이용해서 viewport를 적용하는 것이고 이는 빠른 시일내에 다른 브라우저에서도 적용이 될 것으로 보인다.


현재 CSS에서 viewport 설정이 가능한 것은 IE10과 오페라 밖에 없다. 


@viewport {

    zoom: 1.0;

    width: device-width;

}


표준 태그는 이렇게 생겼지만 아직 표준화가 완전히 되지 않은 기능이기 때문에 오페라나 IE10은 prefix를 붙여야 한다. 


/* ie10 */

@-ms-viewport {

    zoom: 1.0;

    width: device-width;

}

/* opera*/

@-o-viewport {

    zoom: 1.0;

    width: device-width;

}


CSS를 이용한 viewport 설정의 장점은 media query와 viewport를 섞어서 쓸 수 있다는 것이다. 이렇게 되면 스크린 사이즈 별로 개발자가 통제할 수 있는 영역이 더 많아 진다. 


특히 IE10에서는 윈도우8에 추가된 snap 기능을 이용하기 위해서는 필수적으로 viewport를 css에서 명시해주어야 하므로 최신 기술이 적용된 웹사이트를 개발하는 입장에서는 미래를 위해서 코드한 줄 쯤은 추가해놓는 것이 좋다. 


그리고 W3C측에서 css로 viewport를 적용하는 것을 표준 안으로 삼고있기 때문에 머지않아 크롬이나 파이어폭스, 사파리에서도 css로 viewport를 사용하는 것이 가능해질 것이다.