티스토리 #2스킨 모바일 사이드바 편집

 

계정 정지 일주일 먹은 김에 모바일 사이드바 작업을 하게 되었다,

 

이번에 의도치 않게 티스토리 계정을 일주일 정지란 징계처분을 당하게 됐습니다, 무심코 예전에 올랐던 글들을 수정하면서 카카오TV링크에 연결된 비공개 처리됐던 영상 하나를 생각 없이 활성화한 것이 화근이 된 것 같네요.

계정정지 기간은 일주일.. 그동안 미뤄왔던 스킨의 모바일 사이드바 편집이나 해봐야겠다고 좋은 쪽으로 생각하곤 지금 사용 중인 스킨의 모바일 사이드바 편집을 좀 해봤습니다.

사용한 지 꽤 되어서 정확한 스킨의 이름이 어떤 건지 기억이 가물가물 하긴 하는데 아마 티스토리에서 기본으로 제공해 주던 반응형 스킨이었던 것으로 기억되네요.(나중에 검색해 보니 : 티스토리 #2 스킨이었네요)

 

커스텀하여 사용 중인 티스토리 #2 스킨

티스토리 자체 제공 스킨

이 스킨을 사용하기 시작한 이유는 당시 티스토리 스킨 중 개인 개발자의 라이선스 제약등에서 조금은 자유로운 티스토리 자체제공 스킨 이면서도 기능적으로 사이드바 등의 정보가 한눈에 들어오는 직관적 디자인과 포스팅에  집중된 사용성이 마음에 들어  이 스킨을 사용하게 되었습니다. 

직관적 이면서도 나름 기능과 심플함에 커스텀해가며 사용하던 스킨인데 마음에 안 드는 부분이 몇 군데 있었거든요, 가장 눈에 거슬리던 부분은 모바일에서의 디자인이.. 좀 못났다? 너무 광활한 심플디자인? 

한마디로 사이드바와 상단 모바일 Top Cover 디자인이 너무 광활하며 사이드 바에서 뿌려주는 정보 또한 카테고리로 제한된, 모바일에서 뭔가 만들다 만 그런 느낌이 들더군요;;; 그래서 이번에 마음먹고 모바일 상단 커버 사이즈와 사이드바의 위치와 배치를 조금 손보게 되었네요..

수정전 사이드바의 원본 사진은 아래와 같습니다. (수정 전과 수정 후 비교)

사이드바 수정 전

사이드바 수정 후

사이드 바에 좀더 많은 정보를 넣었습니다.

 

위에 이미지와 같이 수정전의 사이드바 디자인은 전체화면으로 모바일 디스플레이를 덮고 있으며 표시된 내용은 카테고리 목록만 나와있어서 전체적으로 공간에 잉여면적을 너무 차지하죠?

그래서 아래 이미지처럼 디스플레이 공간의 70% 정도만 사이드바가 차지하고 또한 사이드바에 하단 관리목록과 프로필 레이어를 커스텀한 소셜링크 등과 함께 최근게시글 목록과 리플목록 그리고 링크목록등을 불러와 잉여공간에  뿌려줬습니다.

그리고 우측 20% 영역을 차지하는 콘텐츠 목록 화면엔 display:none 속성으로 콘텐츠 표시가 안 되는 텅 빈 화면만 출력되더군요 ( 사이드바가 전체화면으로 출력이 되는 디자인이니 보이지 않는 사이드바 뒤쪽 출력을 디자인할 이유가 없겠죠;;;) 그래서 이 부분도 모바일 화면에 맞게 모바일 해상도에 출력되는 콘텐츠 박스를 불러와 생성시켜줘야 하더군요...

아래 글쓰기와 관리등에 사용하는 관리 리스트는 기존에 사용하던 ioc. 배경과 스타일을 사용하려 하다 보니 백그라운드 ioc이미지의 위치 잡기도 뭐 하고 또한 기존 이미지와 뭔가 좀 다른 자유로움을 느끼고 싶어서 아예 이 리스트를 따로 긁어와 class를 모바일용 전용으로 네임을 다시 부여하고 이미지도 필요한 부분만 짤라네 다시 편집하여 사용해 봤습니다.

원본과 사이드바를 수정한 후의 비교 영상

 

웨일 브라우저에서 본 PC와 MOBILE 화면 출력 모습

전체적으로 대충 이런 식으로 편집하였고 남은 부분은 사이드바를 외부 document body 클릭으로 닫히게 하려면 사이드바에 사용된 스킨의 script.js 파일에서 사이드바를 닫는 버턴에 부여된 이벤트를 이너영역이나 content 영역에 만들어 줘야 할 것 같습니다.

스킨의 내비게이션에 관련된 script.... 

  var Area = {};

    Area.Menu = (function() {

        var $wrap = $(".wrap_skin"),
            $btnCategory = $(".area_head .btn_cate"),
            $btnCloseCategory =  $(".wrap_sub .btn_close");

        $btnCategory.on("click", function() {
            $wrap.addClass("navi_on");
        });

        $btnCloseCategory.on("click", function() {
            $wrap.removeClass("navi_on");
        })

    })();

이 부분이 navi_on 클래스를 부여하는 선택자가 버턴 영역에 활성화되어 있어 이 부분을 아래 코드 식으로 추가해서 Document. body에 만들어 주려 해 봤는데 잘 안......

그리고 이게 활성화된다 해도 그러면 우측 영역만이 아닌 전체 문서의 다른 영역에서 이벤트가 발생해도 사이드바가 닫히는 불상사가 생길 듯도 하고 해서 해당 영역에 이너영역을 만들어주어 거기에 전체적인 버턴 이벤트를 주는 게 어떨까 고민 중입니다...

// 사이드바 외부를 클릭하면 사이드바 닫힘
        $(document.body).mouseup(function (e){
            if(wrap.hasClass("navi_on").length==0) {
                $wrap.hide();
                $wrap.removeClass("navi_on");
            } 
        });

 

이제 한 가지 숙제를 마치고 나니 또 한 가지의 숙제가 남았군요.. 항상 이렇더라고요 뭔가 하나 해결하면 또 다른 문제점이 생기고... 그러면 또한 고민하고 그 문제의 해결에 집중하게 되고... 그러다 보면 또 해결하고... 티스토리 스킨을 사용하면서 누구나 느끼고 겪는 문제가 아닐까요? 아주 프런트앤드 개발 쪽으로 능통한 분이 아니시라면 많은 티스토리 블로거들이 공통적으로 겪는 과정이 아닐까 싶네요..

*모바일 사이드바 1차 편집 영상

 

 

편집 후 발견된 오류들 몇 가지

 

1. 프로필 레이어 : pc 해상도 출력 시 모바일 사이드바에 만들어 넣은 프로필 레이어와 제목 박스가 카테고리 사이드 바에 잠시 출력되었다 사라지는 버그 (pc의 프로필 레이어 코드를 긁어와 모바일에 퍼블리싱해 주면서 pc의 코드와 중복되는 현상이 아닐까 생각 중) 수정해 보고 오류가 안 잡히면 모바일 용으로 따로 클래스를 생성한 후 모바일 클래스를 pc에서 display :none 처리해 주면 되지 않을까 생각 중이다.

2. 모바일 사이드바 하단 관리목록이 모바일에서 최하단 스크롤 시 사라졌다 다시 타타나는 버그 : position :absolute 속성으로 조상 뷰의 기준을 잡았는데 포지션 속성을 fixed로 잡고 뷰포드에 고정시켜야 하나? 고민 중이다. (position :absolute; > position: fixed; 으로 변경하여 대충 수정 해결)

3. 우측 콘텐츠 박스와 전체적인 뷰에 백그라운드로 속성을 준 class = cont_sub 가 사이드 바 스크롤 시 함께 스크롤되는 현상을 잡아줘야 하는데 고민이다. ( 이 부분 때문에 pc에서는 스크립트 파일에 변수를 추가해 ($sidebar = $(". wrap_sub"); // 사이드바 선택자 추가)  사이드바 외부 이벤트로 열린 사이드 내비게이션에 대한 remove 이벤트가 가능한데 모바일에서 wrap_sub 이 사이드영역에 갇혀있고 cont_sub이 이벤트를 방해하여 사이드바 외부 이벤트로 네비를 닫을 수가 없다..)

이 부분 어떻게 해결하지?? 변수에 명시해 줘야 하나? 아니면 해당 영역들 css 수정으로 가능할까?? 결국 이문제는  반만 해결되고 절반은 해결이 안 된듯하다..

*그 외에 해결할 과제들 :

1. 사이드 바 편집 시 긁어온 코드들의 필요 없는 부분들 삭제 / 정리 

2. 사이드 바의 동적 애니메이션 영역인 script.js 파일에서 사이드바의 외부 클릭으로 pc와 mobile 모두에서 사이드바 출력 시 부여되는 navi_on 클래스를 제거하는 (removeClass) 외부 이너 박스 레이아웃에  생성해 주고 생성된 클래스로 스크립트 코드를 조립해야 한다. (절반의 성공이니 절반만 지우자;;; ) 외부 클릭에 이벤트를 발생할 변수를 지정해 줘서 사이드바가 닫히긴 한다. 그런데 범위를 너무 광범위하게 잡은 듯... 아무 데나 클릭해도 닫;;;;;;;  아무래도 이벤트가 발생할 범위를 사이드 바 밖으로 지정해 줘야겠다....

이후 버그수정 과정들. 기록 (1-2의 과정을 거쳐 3.번의 방법으로 해결함

 

사이드바의 외부 클릭 닫기 기능과 PC / MOBILE 에서의 사이드바 외부 영역창 어둡게 만들기 기능등은 구현하였다.

블로그 내 관련 글 링크 

외부 선택자로 사이드바 닫기 : 사이드바 외부 이벤트로 닫기 구현 기록-#2 스킨 

https://lookchang.tistory.com/213

리모컨형 토글 메뉴버턴 달기 : 티스토리 #2 스킨-스크롤 토글 버턴 만들기

https://lookchang.tistory.com/214

 

#2 스킨의 모바일 사이드바 편집에 애를먹는 스킨의 구조적 문제 관련 내용

 

그런데 아무래도 처음 설계 과정부터 모바일의 단순한 기능에 맞춰서 설계한 스킨이라 계획 한 커스텀 환경과는 사이드바의 설계적 구조의 호환성을 지니지 못하는 관계로 몇 가지 버그들이 존재한다.

예를 들면 이 스킨의 레이아웃 구조중 PC / PC형 태블릿 / 모바일로 넘어가는 반응형 구조중 서브창이 사이드바의 토글메뉴로 넘어가는 구조이다 보니 레이아웃 박스의 클래스를 그대로 가져갈 경우 상단 사이드와 서브창의 베너에서 모바일 사이드창으로 넘어가는 과정에 무리가 있어서 모바일 구조의 레이아웃을 추가하고 일부 중요한 class의 엘러멘트 요소를 가져오다 보니 태블릿(중간 해상도 미디어쿼리)  창에서 모바일로 넘어가는 변경과정에 태블릿 상단 창이 사이드로 넘어가며 보였다 사라지는 현상 등이 있다.

이를 구조적으로 조정하기 위해선 사이드바의 내비게이션 클래스인 "wrap_sub" 클래스를 모바일 사이드 바에선 새로운 클래스로 독립시켜야 하는데 그렇다고 따로 모바일 클래스에 반영하는 레이아웃을 생성하고 클래스를 부여하여 만들긴 작업량이 많아진다.

주어진 문제를 해상도에 따른 클래스 변경이란 방법을 사용하여 극복하려고, 레이아웃의 클래스를 자바스크립트를 이용해 미디어쿼리의 738px 해상도 이하로 넘어갈 때 엘레먼트 요소의 class 명을 변경해 주는 스크립트를 사용하여 모바일 해상도의 사이드 서브레이아웃 박스를 스크립트 실행으로 변경하면서 css 적용을 통한 장애극복을 구현해 보았는데 스크립트를 잘못 짠 건지... 동작은 되는데 미디어쿼리만큼 정확히 반응하질 못한다.

예를 들면 738px 보다 윈도창이 작아지면 "class=wrap_sub"를 "mdwrap_sub"로 변경하고 738px보다 크면 "mdwrap_sub" 클래스를 "wrap_sub"으로 만들어라 하는 구문을 주었는데 실질적 반응에 3~10px 정도의 오차가 발생하여 딜레이가 생기며 css 적용과정과 불협화음이 생긴다...

*문제가 발생한 코드 들.. 아래 코드들은 약간의 문제가 있는 코드이며 기록만 남깁니다.

처음에 클래스 변경을 위해서 사용해 본 script는 두 가지입니다. 하나는 클래스 명을 변경해 준 코드이고 두 번째는 클래스에 "bobile_on"이라는 모바일용 클래스를 추가해 준 코드입니다. 두 가지 방식모두 딜레이 오차가 발생하는 것 같습니다;;;

1. 기존의 "wrap_sub" class를 해상도에 따라 "mdwrap_sub"로 클래스 변경을 해주는 스크립트

 <script type="text/javascript">

    $(window).resize(function() {  // 리 사이징시 클래스 변경 
        if($(window).width() <= 738) { //738px 과 같거나 작을때 
            $(".wrap_sub").attr('class','mdwrap_sub');} //해당 클래스를 변경한다.
            else{$(".mdwrap_sub").attr('class','wrap_sub');} //아니면 원래 클래스로 변경한다
        
    }); 
    
    $(document).ready(function() { //  로드후  클래스 변경 
        if($(window).width() <= 738) {
            $(".wrap_sub").attr('class','mdwrap_sub');}
            else{$(".mdwrap_sub").attr('class','wrap_sub');}
        
    });   
</script>

2."wrap_sub" 클래스에 해상도에 따라 add "mobile_on" 클래스를 추가 선언해 준 스크립트

<script type="text/javascript">

 $( window ).resize(function() { //리사이즈 시 

   var windowWidth = $( window ).width();
       $wrapc = $(".wrap_sub");
   
      if(windowWidth <= 738) {
      $wrapc.addClass("mobile_on");}  // add class
      else {
      $wrapc.removeClass("mobile_on");  //remove class 
       }
     });
     
 $(document).ready(function() {  //로드후 

   var windowWidth = $( window ).width();
       $wrapc = $(".wrap_sub");
   
      if(windowWidth <= 738) {
      $wrapc.addClass("mobile_on");} 
      else {
      $wrapc.removeClass("mobile_on");
       }
     });
     </script>

위에 스크립 소스는 오차가 조금 있어서 모달창 등의 사이즈 변경을 위한 클래스 작업등에 사용할 순 있겠지만 정밀하게 미디어쿼리와 반응하는 레이아웃 작업에는 아무래도 무리가 있을 듯해 보인다... (문제를 해결한 코드는 본문 아래에 있습니다.)

몇 가지 오류는 시간을 두고 정리해 보도록 하고 중간휴일에 지저분하게 낙서된 소스들을 좀 정리하여 불필요한 태그들을 제거하고 정리하는 작업부터 해야 할 듯하다...

위에 코드들을 적용하지 않은 이유들..

 

1. 번 클래스 명을 아예 변경해 주는 스크립트 적용 시  : 파이어 폭스나 네이버 웨일 브라우저에서는 해상도에 따른 클래스 변경이 잘 작용되나 구글이 자랑하는 크롬 브라우저에서는 리사이즈 시나 로드 시 해상도에 따른 클래스 변경 정확도가 떨어지는 문제가 있고 (크롬 브라우저의 스크롤바 이슈로 이 넓이까지 계산한 디버깅이 이유인 듯하다;;)

2. 번 클래스 추가 방법의 스크립트 적용 시: 클래스 추가를 해도 기존의 wrap_sub의 클래스가 상속되어 오기 때문에 클래스 추가에 대한 완전한 클래스 분리가 힘들다는 문제점이 있더군요 (즉 완전히 독립된 클래스가 아니기 때문에 결국 상속된 클래스가 적용되니  지금의 문제 해결에는 도움이 안 된다.)

이리저리 오류원인과 이를 해결할 방법을 구상하던 중  아래 스크립트 코드를 이용해 구글이나, 사파리 등에서 발생한다는 스크롤바 넓이 값 까지 계산하게 되는 "window.Width" 값 오류를 수정 하였습니다.

 

3. 해상도 변경 감지로 클래스 변경 사용한 코드 (성공한 코드)

 

이후 이런 오류들의 이유와 해결 방법을 구글링을 해본 후 아래코드로 변경 후 일단은 리사이징이나 새로 페이지를 로드 시 클래스 적용은 잘되는 듯합니다.

<!-- 해상도로 클라스 변경 //-->

<script type="text/javascript">            
$(window).resize(function (){
 var width = window.innerWidth; // window.innerWidth 를 width 란 변수로 담아 준다. */
 if (width <= 738) {           // 738 보다 작거나 같으면 
    $("#mFeature").attr('class','mdwrap_sub');  //#mFeature 란 아이디 선택자에 mdwrap_sub 클래스를 준다 
 }
 else if(width >= 738){       // 738 보다 크거나 같으면
    $("#mFeature").attr('class','wrap_sub');  //#mFeature 란 아이디 선택자에 wrap_sub 클래스를 준다 
 }
 });
 $(document).ready(function(){
 var width = window.innerWidth;
 if (width <= 738) {         // 738 보다 작거나 같으면
    $("#mFeature").attr('class','mdwrap_sub');  //#mFeature 란 아이디 선택자에 mdwrap_sub 클래스를 준다 
 }
 else if(width >= 738){      // 738 보다 크거나 같으면
    $("#mFeature").attr('class','wrap_sub');  //#mFeature 란 아이디 선택자에 wrap_sub 클래스를 준다 
 }
});
</script>

코드를 짤 때 처음엔 한 블록 안에 resize 펑션과 ready 펑션을 구성하려 했는데 그랬더니 리사이즈펑션은 돌아가는데 ready펑션에 문제가 있어서 페이지를 새로고침 하면 클래스 변경 적용에 오류가 있어서 결국 resize 펑션을 먼저 돌린 후 뒤에 ready 펑션을 다시 만들어주니 정상 작동합니다.

그리고 클래스 명으로 선택자를 정하여 클래스 변경을 하였던 것을 이번엔 선택자를 id로 변경하여 선택 후 이 선택자의 클래스를 변경하는 타깃으로 작성해 봤습니다.  이유는 클래스 추가와 삭제와는 다르게 처음 문서에 표기되어 있는 클래스인 "wrap_sub" 클래스를 타깃으로 하긴 사이즈 변경 시나 새로고침시 선택자를 변경 전과 변경 후로 선택하려는 목표가 애매한 부분이 있어서 아예 id를 선택자로 주고 선택된 아이디의 클래스를 변경해 주는 것으로 설정해 봤습니다.

그리고"window"창의 넓이값을 구한 함수를"window.Width"가 아닌 "window.innerWidth"로 구현을 해봤다.

원래 "innerwidth" 값 하나만 사용할 경우 "wiudth"처럼 스크롤바까지 포함하여 계산된다 적힌 글을 본 것 같은데 다행히 지난번 스크립트처럼 크롬등에서 스크롤바 넓이 값으로 인한 15~16px 정도의 오차가 이번엔 발생하지 않는다. 이 함숫값이 ie9 이하 버전의 브라우저에서는 호환이 안된다는 글 또한 어디선가 본 기억이 있지만, 어차피 이 스킨에 사용된 라운딩 값이나 일부 백그라운드 처리등도 윈도 ie8등에선 호환오류가 있는듯하니 그 정도면 호환성이 아주 많이 떨어지진 않는다 여겨진다.(하위 버전의 브라우저 호환성 등의 문제는 차차 따로 하위 브라우저에 대응하는 코드를 설계해 보려 예정 중입니다)

그런데? 웹 표준 따위는 철저히 무시한 무뤠배 브라우저인 ie7~ie8 따위는 사실 개발자 입장에서도 철저히 무시하는 게 맞다고 생각합니다.

지금 포스팅의 주제와는 좀 많이 벗어난 이야기지만 자신들의 필요에 위해서 아직도 익스플로 브라우저를 사용하시는 분들이 계시죠 그렇지만  꼭 그분들의 필요까지 고려하며 죄인처럼 브라우저 호환성을 맞춰줘야 할까 싶네요... (다른 접근 방법이 없는 것도 아니고;;;) 결국 이 분들이 이용하는 서비스를 제공하는 카드사나 은행웹들 그리고 관공서들 이들이 예산을 핑계로 자신들의 책임을 도외시한 부분이 액티브 x컨트롤의 추방인데 왜 다른 애매한 개발자 님들이 이들의 책임회피 부분을 담당하며 호환성 맞추느라 땀을 흘려야 하는지 참 이율배반적이라는 생각이 많이 듭니다;;;

구유물인 액티브 X 부분은 익스로, 브라우저 서핑은 크롬이나 웨일, 에지 등으로... 이게 맞다고 보입니다, 왜 굳이 자신들이 필요해 설치한 익스의 호환성 보기로 웹 사이트에 접근하곤 디자인이 깨진다, 레이아웃이 엉망이다 이런 표현들을 하는지 답답합니다.

그건 웹 사이트의 문제가 아니라 선생님들께서 사용하시는 익스플로러가 웹이 표현하고자 하는 디자인을 표현하지 못하는 고장 난 엔진 이기 때문 임을 아시길 바랍니다.

서비스 제공자인 웹사이트에서 책임져야 할 보안의 의무와 책임을 사용자인 클라이언트에게 넘기는 액티브 액스 컨트롤은 사용자들에게도 많은 불이익을 가져옵니다. 모바일에서도 충분히 액티브 컨트롤 설치를 하지 않아도 이제는 은행앱 등의 개발이 가능한 시점에 아직도 구시대의 유물로 여전히 사용자에게 책임을 전가하는 구시대의 웹 사이트들은 더 이상의 지원이 끊겨야 사라질 것이라 생각합니다.

개인적으론 호환성에 맞춰서 개발이 진행될게 아니라 아예 익스 6~8 등으로 웹 접근 시 접근 자체가 차단되게 설계가 돼야 맞다고 보입니다 그러면 웹 서핑이 필요한 분들은 다른 브라우저를 스스럼없이 사용하는 문화가 정착될 것이고 그래야 구유물인 고장 난 엔진 익스플로러와 이에 기생해서 자신들의 책임과 의무를 애꿎은 다른 개발자들과 소비자에게 넘기고 그들의 시스템을 오히려 보안과 기능성을 불안정하게 만드는 자기기만적이고 기생충과 다름없는 비양심  웹 사이트들이 웹에서 추방될 것이라 사료됩니다.

어쨌든 지금은 크롬에서도 크게 오류 없이 돌아가는 것을 확인했고, 사용 중인 티스토리#2 스킨을 사용 중인 블로그에 위에 코드를 적용하여 해상도 사이즈 변경을 감지하고 클래스를 변경할 수 있었습니다.

처음에 구상하고 생각한 것보단 구현에 손이 많이 가긴 했지만, 기존 부모태그인 "wrap_sub' 클래스와는 완전히 독립시킨"mdwrap_sub" 모바일 클래스를  이용한 모바일 에서의 사이드바 기능을 이렇게 구현하여 봤습니다.

*아래 동영상을 보시면 첨부 이미지에 표시된 사이드바 영역의 부모 클래스인 "wrap_sub" 클래스가 해상도 사이즈 변경 시 "mdwrap_sub" 클래스 명으로 변경되는 것을 확인하실 수 있습니다.

해당 클래스 변경에 관한 동영상 첨부

클래스를 변경하는 모바일 화면

 

위에 기록들을 바탕으로 모바일 사이드바를 수정하였고 이런 기록을 바탕으로 지금 수정 중인 티스토리 #2 스킨을 손보실 분이나 비슷한 스크립트 코드를 구상 중 이신분이 게시면 참고하시라 기록으로 남겨둡니다.

이외에 티스토리#2 스킨에 모바일 사이드바 형식을 수정하기 위해서는 사이드바 수정 후 몇 가지 자잘하게 해결해야 할 문제들이 있습니다. 예를 들면 모바일 사이드 바 편집 후 사이드 바 오픈 시 보이는 30%의 본문 영역을 모바일에서 상, 하 스크롤을 방지하기 위해서 스킨 BODY 시작에 <body id="tt-body-index" class="scrollbody side_on" style=""> 클래스 "scrollbody side_on"를 부여하고 만들어 넣은 "overflow-y: hidden; touch-action"(수직 스크롤 X , 모바일 터치 액션 X ) 나 z-index 값 조정 등등의 내용들에 대한 문의는 답글을 남겨주시면 기록에 대한 내용을 설명해 드리겠습니다.