완전 골때리는 IE – 아오 ㅆ ㅂ 이게 현실이 될줄이야..

§

수년 후 지원해야 하는 IE 브라우져 갯수
수년 후 지원해야 하는 IE 브라우져 갯수 수년 후 지원해야 하는 IE 브라우져 갯수

몇년전 ㅋㅋㅋ 거리면서도, 속으로는 그래도 ‘에이 설마 이런일이 벌어지진 않을거잖아’ 라고 생각했다. (내 생각이 완전 잘못되었었다. 이게 웃을일이 아니었어. ㅠㅠㅠㅠ)

IE 11 까지 구분하는 javascript

function GetIEVersion() {
  var sAgent = window.navigator.userAgent;
  var Idx = sAgent.indexOf("MSIE");

  // If IE, return version number.
  if (Idx > 0) 
    return parseInt(sAgent.substring(Idx+ 5, sAgent.indexOf(".", Idx)));

  // If IE 11 then look for Updated user agent string.
  else if (!!navigator.userAgent.match(/Trident\/7\./)) 
    return 11;

  else
    return 0; //It is not IE
}

if (GetIEVersion() > 0) 
   alert("This is IE " + GetIEVersion());
else 
   alert("This is not IE.");

소스코드: https://jsfiddle.net/jquerybyexample/gk7xA/

작년까지 잘만 썼지만, 물론 IE 12 하고 13 에서 안 먹는다… 하…

마소는 뭐 잘났다고 IE10 부터 conditional tag 도 없애 버렸다. 아니 슈발, 이 편한걸 왜 없앴냐고?!!!!!!

<!--[if IE ]>
  <link href="FUCK_IE.css" rel="stylesheet" type="text/css">
<![endif]--> 

IE hack 은 예전부터 좋아하지 않았고, 이 conditional comment 로 쉽게 해결되었었는데, 이제는 user agent sniff 하는 방법 밖에 없다.

IE11 하나만 걸러내는데도 이렇게 복잡하다.

http://stackoverflow.com/questions/17907445/how-to-detect-ie11

Stackoverflow 에서 맨날 하는 소리. 브라우져 detection 하지 말고, 모든 브라우져에서 문제없는 css 를 작성하는게 best practice 야. 그렇게 해보렴.

아오.. ㅆ ㅂ 지금 불난데 부채질하나. 지금 css 때문에 이러냐고?

븅신같은 IE 에서 한글 url 이 다 깨져서 그것때문에 그러는건데 무슨 css? css 얘기를 왜 하냐고?!!

이것때문에 힘 다 빠져서 IE 에서도 한글 URL 제대로 보이는 플러그인 만들어 볼까 하는 생각이 싹 없어졌다.

어짜피 여기저기서 php 도움받아서 해야 할텐데, 급 귀찮아졌다. ㅠㅠㅠㅠ

[친구들한테 물어보니까 이건 core 에서 해결해야지 플러그인으로 구사하려면 mother of all plugin (엄청난 규모의) 이 될거라고 합니다. core 기능에 포함되야지 플러그인으로는 거의 불가능할거라고 하네요.]

그래도 이런식으로나마 한글 URL 을 IE 에서 보여줄 수 있게 작업해 놓으니 기분이 조으다.

워드프레스_한글_URL

* 참고삼아 알려드리자면 한글 URL 이 IE 에서 깨지는거는 워드프레스 문제가 아닙니다. 크롬이나 파폭같은 다른 정상적인 브라우져와 다르게, IE 는 non-latin 캐릭 URL 을 제대로 decode 해서 보여주지 못합니다.

IE 는 일종의 기능적 장애를 갖고 있는 겁니다. 쉽게 얘기해서 그냥 ㅂ ㅅ ㅅ ㄲ 에요.

lel

그래도 기술적으로 조금이나마 발전이 있었고, 이제 IE11, 12 에서는 ctrl+c,v 해서 주소를 넣으면 한글이 제대로 보여집니다. 물론 다른 한글 URL 페이지로 넘어가게 되면 제대로 한글 URL 을 구현하지 못하고 아직 깨지고 있습니다.

마소의 브라우져 개발 스케줄이 어떻게 되는지 모르지만, 어쩌면 1-2년 안에 해결될 수 도 있는 문제 입니다.

자꾸 코프레스에 이 한글 URL 깨지는 문제로 질문올라오고 개인적으로 호출당하고 그래서 좀 짜증? 번거스러웠었습니다.

IE 인 경우에는 워드프레스에서 decode 해서 uri 를 보내줘서 IE 가 제대로 된 URL 조합을 할 수 있도록 하면 해결되지 않을까 생각하시는 분이 계실텐데, core 에 이 기능을 포함해 달라고, 여기 https://make.wordpress.org/support/ 에 계신 core contributor 에게 request 하실 수 있습니다.

제가 이렇게 하지 않는 이유는, non-latin 캐릭을 쓰는 사이트 만의 문제이기도 하고, 더구나 이건 위에서 언급했듯이, IE 의 문제지, 워드프레스 문제가 아니거든요.

IE 가 ㅂ ㅅ 인데, 이걸 워드프레스가 맞춰줘야 하나요?

결론: Fuck IE 입니다.

hackya 는

Attorney, front-end developer, digital media artist, WordPress enthusiast, & a father of 4 wonderful children.

Tags: , , ,

카테고리: , ,

Ω

20 Comments

  • WordCracker says:

    IE11을 사용하는데 한글 URL이 깨져서 왜 그런가 생각하고 있었습니다.

    그래서 이 글을 보고 잠시 생각해보았습니다. permalink를 디코딩해주면 되겠다 싶어서 get_permalink() 부분을 urldecode(get_permalink())로 수정해주니까 IE11에서도 한글이 제대로 표시되네요ㅎㅎ

    이제 제 블로그의 한글 URL이 IE에서 제대로 표시되지만, 제가 IE11을 사용해서 다른 IE 버전에서도 제대로 보이는지는 모르겠네요.

    • Matthew says:

      아.. 이거 테마부터 다시 짜야 하나요? ㅋㅋㅋㅋ

      제 테마는 진짜 오래된거라서 get_permalink() 가 단 한번도 쓰이지 않았습니다.

      (get_permalink() 함수가 좀 최근에 나온 함수라, 저처럼 옛날에 만든 테마는 이 함수가 없어요.)

      테마 loop 부분부터 다시 짜야 하면 테마 작업이 커지는데…. 훔….

      아쉽지만 저는 당장 적용해보기 어렵겠네요. ㅋㅋㅋㅋ

      그런데 신기하네요. 몇칠전 소셜공유 버튼에도 urldecode 를 적용했는데 글씨 깨졌었거든요.

      워드님도 이부분 이상하지 않으세요? 같은 urldecode 인데, 소셜공유 버튼 은 글씨 깨지는게 고쳐지지 않거든요…

      • WordCracker says:

        모든 get_permalink()를 찾아서 수정해주면 좋겠지만, 저는 그냥 content.php 파일 하나에서만 수정해주었습니다. (아마 제 테마에서는 이 파일 내의 제목이 블로그 글과 아카이브 글의 제목에 적용되는 것 같습니다.)

        소셜 공유 버튼에서 글씨 깨지는 것이 조금 이상하긴 한데, 이것은 encoding이나 decoding을 안 해주면 한글 자체는 안 깨지거든요(다만 링크가 제대로 안 되는 문제가 있지만요). 제가 사용한 코드에서는 urlencode를 사용하면 링크는 제대로 작동하지만 디코딩을 제대로 못해서 그런지 한글은 깨져 나오고, urldecode를 적용해보면 제대로 작동하지 않고…

        • Matthew says:

          정리정돈이 잘된, 모던한, 근대적인 테마를 쓰시고 계신 것 같습니다. ㅋㅋㅋ

          제 테마는 워드프레스 2.X 시절, 그당시 기준으로 코딩된 테마라서요…

          내부를 살펴보면 워드프레스 함수보다는 그냥 순수 php 코드로 작성된 매우 원시적인 형태의 테마라서, 헐.. 이게 뭐야? 아마 이러실겁니다. ㅋㅋㅋ

          (겉모습만 멀쩡한거에요. ㅋㅋㅋㅋ)

          시간이 나면 워드프레스 함수도 적용하고 정리도 하고 그래야지 하면서 벌써 4년도 넘게 하지 않은… (일단 작동이 되니까 아쉬운게 없는거죠. ^^;;;)

          그런데 get_permalink() 를 사용하면 IE 에서 한글 URL 이 표시된다니까 그 부분이라도 한번 새로 작성하고 싶은 생각이 듭니다.

  • codei says:

    아 이거. IE는요. 멍청해서 urlencodeing 된거 아니면 읽지 못해요.
    아시다시피.
    그래서 모든 url 은 encode 해서 보내주고, 받을때 꼭 decode 해서 인식 해줘야 합니다.
    물론 이렇게 해도 안 되니 빡치신 거겠지만요 ㅎㅎ

    [참고로 크롬 사파리는 endcode 안해도 그대로 받아갑니다. 근데 이거 그대로 받아간게 아니라 내부에서 encode 한겁니다. 보내줄때는 원본으로 보내주구요. 이런 똑똑이들!]

    그리고 IE는 진짜 젭라… 버전 을 통일 하던가. IE를 없애던가. 호환 잘되는걸 내놓던가.
    굉장히 편협적이고 별 이상한 부분에서 규칙을 지치라고 하고.

    ie10이었던가 11이었던가?
    css 때문에 인풋 박스가 입력이 안되는 경우도 생겨요 ㅋㅋㅋ
    readlonry 였냐구요? 아니요? 그런거 넣고 말했겠어요? padding 하나 넣었는데 입력이 안되더라구요 ㅋㅋㅋ 세상에.

    • Matthew says:

      urlencode 때문에 짜증이 난게 아니고, IE detect 을 버전마다 일일히 해줘야 하니까 번거스러워서 짜증이 난거죠.

      물론 지난 4-5년간 IE 때문에 삽질한적이 한두번이 아니라, 안좋은 기억까지 밀려오고…

      사람이 살인충동을 느낀다고 하잖아요. 저는 정말 마소 찾아가서 IE 만든 인간들 다 죽여버리고 싶은 충동을 느낀 적 이 있습니다. >.<

      IE 때문에 잠도 못자고 밤 꼬박 세운적도 있고…

      console 에 에러도 안뜨는데 계속 작동이 되었다 안되었다 이지랄 하면서 사람 속썩이고…

      css 야 정 방법이 없으면 그림 떡칠이라도 하죠. js 는 정말… 아휴…..

      그나마 jQuery 라도 나와서 front-end 개발자들 다 살려준거죠… jQuery 없었으면 정말.. 상상이 되지 않습니다.

      • codei says:

        jQuery 도 1.9 버전이 그나마 잘 먹힙니다
        2.x 로만 올려도 IE에서는 거부 반응을 ㅋㅋㅋ
        모든 만악의 근원은 IE에서 부터 출발 하죠.
        [아니 왜 혼자 유별나게 구는 거야! 크릉!]

        • Matthew says:

          jQuery 2.X 로 올릴때, Resig 하고 구글하고 충분한 교감을 갖고 (사전에 서로 얘기된 부분이 있었겠죠.) 구글하고 jQuery 하고 동시에 IE8 지원을 끊겠다고 공표했고 그렇게 했습니다.

          그래서 다들, 와 짱!! 이제 IE8 대응 안해줘도 되는거냐? 라고 아주 잠깐 미국 front-end 개발자들이 신나했던 적이 있었습니다. ㅋㅋㅋㅋ

          “너가 구글이야?, 너가 구글이냐고?” “IE8 계속 대응하라고.” ㅋㅋㅋㅋ

          벌써 몇년전 일이죠. 요즘은 정말로 IE8 대응 안하는 플젝이 대부분 입니다. (한국을 제외한 국가들의 경우) 물론 한국 사정은 많이 다르겠죠.

          전세계에서 IE8 점유율이 (그것도 독보적으로) 가장 높은 대한민국. 한국은 주로 안 좋은거로 일등 많이 하더라구요.

          • Estoque says:

            원래 중국이 IE8 점유일이 굉장히 높았는데, (XP의 높은 점유율 때문) xp지원 종료하면서 텐센트가 최신 운영체제 + 브라우저 업그레이드 하면 혜택을 준다는 초강수를 둬서 많이 갈아 탔다죠…

          • Matthew says:

            중국쪽 사정은 제가 좀 잘 아는데, 중국 브라우져 통계에 대거 포함되는게 중국내 좀비PC 입니다.

            주로 DDoS 공격에 동원되는 PC 들인데, XP OS 가 대부분이거든요. 사람이 실제 사용하는게 아니라, 전세계적으로 예네들이 deploy 되서 DDoS 공격을 감행하거든요. (중국내에 해킹으로 밥먹고 사는 사람들이 많습니다.)

            그렇지만 실제 사용자 (bot 말고 사람) 들을 보면 IE 수치가 높지 않습니다.

            http://gs.statcounter.com/#browser-CN-monthly-201412-201607

            그럼에도 불구하고 중국내 현재 크롬점유율이 50% 가 넘는데 세계적인 추세와 비슷한 수치 입니다.

            관공서에서도 다 크롬쓰고 최신 윈도우 OS 씁니다. (한국과 달라요.)

            어떤 중국호텔들은 PC 도 비치가 되어 있는데, PC 키면 크롬 깔려있고, 구글도 VPN 으로 접속할수 있게 해놓고 그럽니다. ㅋㅋㅋ (중국에서는 원래 구글이나 gmail, 유튜브 접속이 안되거든요.)

  • Estoque says:

    역시 IE는 공공의 적입니다.

    저도 IE conditional이 왜 11부터 없어졌는지 이해가 안가더군요 -ㅁ-;; (세계 제일의 똥통 브라우저 주제에…)

    제 블로그도 IE 전용 스킨 만들어야 되는데 치일 피일 미루고 있네요… 한국에선 IE8 사용자가 아직도 꽤많은데 css3으로만 되어있어서 스킨이 하나도 제대로 안뜨고 있습니다. -ㅁ-;;

    웃긴게 IE6 개발한 사람들이, ‘우리는 세계 최고의 브라우저를 만들었고 더 이상 업데이트가 필요하지 않다’ 며 개발팀을 해체한 일화가 있죠…

    그러고 5년후 대재앙이 시작되는데…

    근데 움짤에 사파리가 없네요 ㅠㅠ

    사파리는 맥에서 진짜 좋은 웹브라우저인데… 속도면에서는 사파리 만한게 없어요 ㅋㅋ (게다가 KHTML로 크롬의 아버지…)

    • Matthew says:

      “사파리는 맥에서 진짜 좋은 웹브라우저인데… ”

      글쎄요…

      웹개발할때 가장 신경쓰이는 브라우져가 IE 하고 사파리 라서요…

      https://html5test.com/results/desktop.html

      돈 없는 불쌍한 파폭도 html5 대응 점수가 456 점이나 나오는데 사파리는 370 점이 나옵니다. (불쌍한 파폭, 죽지마… 파폭이 죽어가고 있어요. ㅠㅠㅠㅠ)

      IE 12 가 377 점 이었거든요. 이정도면 IE 와 다를바 없는 극혐이죠.

      (참고로 IE13 은 433점이 나오고 있습니다. IE 가 욕먹는 이유는 IE 가 IE13 (Edge) 하나가 아니라, IE8 까지 아직 널리 사용되고 있어 욕을 먹는거죠.)

      고로 IE 하고 사파리가 웹생태계의 가장 큰 적 입니다.

      특히 모바일에서, 사파리 기능도 떨어지고, 그렇다고 속도가 크롬보다 더 빠르지도 않습니다.

      http://www.hongkiat.com/blog/google-chrome-for-ipad/

      IE (Edge) 도 탭기능은 있는데 말이죠.. 쩝. 사파리는 노답입니다.

      • Estoque says:

        저도 얼마전 vw/vh 로 모바일 사파리 최적화 하느라 골때린적은 있는데

        깔끔한 폰트 랜더링 만큼은 깔수가 없더라고요

        크롬은 무슨 폰트간에 자글자글… IE는 더했으면 더했지 나은거 하나도 없고요

        게다가 맥에서는 제일 빠른 브라우저다 보니 개발 용도 빼고는 평상시에는 사파리를 쓰고 있습니다.

        한때 크롬이 사파리의 복제판 수준이었는데 블링크로 갈아타더니 저렇게 격차가 벌어졌군요 -ㅁ-

        • Matthew says:

          사파리가 윈도우에서 철수한 이유 중 하나가, 개판인 폰트 렌더링 때문이었습니다. -..-;;

          개발자들 한테 욕을 바가지로 쳐먹었거든요. 일반 사용자야 사파리 안쓰면 그만이고, 욕할 일도 없지만, 개발자들은 필수적으로 사파리에서 작업한 내용을 확인해야 하고.

          그런데 사파리 켜서 조금만 화면 보고 있어도 쉽게 눈이 피로해지고…

          그 이유가 폰트가 깔끔하게 렌더링 되지 않아서였구요.

          https://blog.codinghorror.com/whats-wrong-with-apples-font-rendering/

          애플딴에는 폰트 디자이너의 디자인을 최대한 살리기 위한 렌더링을 한다고 했지만, 이게 PC 사향이나 윈도우 OS 를 전혀 고려하지 않은 렌더링이었어서, 폰트 렌더링이 장난 아니었습니다.

          http://www.joelonsoftware.com/items/2007/06/12.html

          윈도우 사용자들은 폰트가 뿌연것 보다 (애플에서 말하는 부드러움) 글씨가 칼처럼 깔끔하게 보이는 걸 선호 합니다. (Estoque 님이 말씀하시는 자글자글이죠)

          크로스 브라우징 때문에 가끔 사파리 emulator 로 (browserstack) 사이트를 확인할때가 있는데, 저는 깨지는 것 없는지 최대한 빨리 확인하고 바로 꺼버립니다. 오래 쳐다보고 있으면 눈이 피로해지거든요.

          어느쪽이 더 좋고 나쁘고가 아니라 개인적 취향/선호도 인 것 같습니다. 각자의 눈이 어느 한쪽에 더 익숙해진 것 이라 생각합니다.

          • Estoque says:

            테스트 환경에 띄워놓으신 매버릭스때 사파리는 모든 사파리중에서도 흑역사입니다… ㅠㅠ

            요세미티 부터 완전히 바뀐 사파리는 정말 좋아졌어요… 저도 매버릭스까지는 크롬아니면 파폭만 썼는데 요세미티 부터 엄청 좋아졌더라고요… 인터페이스도 깔끔해졌고…

            제가 알기론 사파리가 보안문제 때문에 철수한줄 알았는데 아닌가보네요… 애플의 윈도우 버전 소프트웨어들(퀵타임/아이튠즈/사파리)이 시도때도 없이 보안 구멍이 생겨서 이 때문에 윈도우 보안까지 취약해지는 결과를 낳았는데 애플이 이걸 수정하기 귀찮아서 그냥 버렸다고 하죠…

            덕분에 애프터 이팩트에서는 퀵타임이 필수인데, 현재 퀵타임은 주요백신 사이트에서 설치하지 말라고 권장하는 프로그램인지라 윈도우에서 에팩 사용하시는 분들은 고민이 많으시더군요

            http://stackoverflow.com/questions/11487427/is-there-any-font-smoothing-in-google-chrome

            폰트랜더링 품질은 지금이야 많이 나아졌지만 예전에는 구글 크롬이 최하위권이었습니다. woff포맷을 제대로 못읽어서 랜더링 자체를 완전 짜글짜글하게 해버렸었죠. 이게 그냥 안티엘리어싱 문제가 아니라 글자를 읽을수가 없을 정도여서 (200이하의 font-weight는 글자가 아예 안보이기 까지 했습니다. )

            제가 예전에 여기에 대해 글을 쓴적이 있는데 http://est0que.tistory.com/2077 글작성후 약 6개월이 더 지나서야 버그가 수정되었더군요 -ㅁ-;

            사실 폰트랜더링은 취향차이라는 것을 저도 인정하지만 옛날 크롬은 좀 정도가 지나친 편이었죠

          • Matthew says:

            네. 크롬 .woff 문제는 쉽게 해결할 수 있는 work-around 이 몇가지 존재했었기 때문에, 큰 문제로 대두되지는 않았었습니다.

            저당시 사이트 로딩속도 때문에 웹폰트 쓰는 사이트가 많지도 않았구요. 웹폰트를 쓰는 경우에만 발생하는 문제였어서요…

            https://www.adtrak.co.uk/font-face-chrome-rendering/

            다른 해결 방식도 있었는데 지금 못찾겠네요…

            버그야 어느 브라우저 라도 있는거고, 쉽게 해결될 수 있는 방법이 존재한다면 큰 문제가 아니라고 생각합니다.

            사파리가 철수한 이유는 애플이 가장 잘 알고 있겠지만, 복합적인 사정들 때문이었던걸로 알고 있습니다.

            낮은 점유율, 암울한 수익모델, 계속 늘어나는 개발비용등, 여러모로 누가 봐도 철수 한게 잘한거죠.

    • codei says:

      사파리.. 점수는 둘째치고 왜 위치값하고 여백 값이 혼자 유독 다르답니까 ㅋㅋㅋ

      제가 코더분들에게 사파리도 이상해요. 맞춰주세요. 라고는 차마 요구 못 하겠던…
      [IE 맞추고 있는 도중에 말이죠.]

      • Matthew says:

        예전 사파리 버전에서 margin 버그가 많이 있었구요, 지금 버전도 margin-top 을 % 로 주면 버그 발생할걸요?

        댓글들을 보니 크로스 브라우징에 대한 글을 한번 쓰고 싶어지네요.

        사파리는 rendering 이 크롬하고 큰 차이가 없습니다. 단지 잘못된 코딩을 하는 경우, unforgiving (용서치 않는?) 합니다.

        “이 코딩, 규격에 어긋나잖아. 널 용서하지 않겠어!! ” 라고 하는거죠.

        크롬의 경우, 잘못된 코딩을 하더라도, “아, 너가 지금 이걸 이렇게 표현하려는거지?” 라고 그 코더의 맘을 읽고, 코더가 원하는데로 구사해 줍니다.

        (농담 아닙니다. 크롬에 AI 가 장착되어 있는지도.)

        크롬은 배려심이 많은 브라우져 인거죠.

        파폭도 크롬만큼은 아니지만 어느정도 이런 코딩의 잘못된 부분을 커버해주는데 IE 하고 사파리는 얄짤 없습니다.

        코더의 마음을 해석하는 능력이 0% 인, 멍청한 브라우져라서 그렇습니다.

      • Estoque says:

        .5 px 값이 먹히는 유일한 브라우저죠

        좋은건지 나쁜건지는 모르겠지만(…)

        게다가 vh 쓰면 무한스크롤 버그 나서 모바일용은 %로 변환 해줘야 합니다. -ㅁ- ;;;

Leave a Reply

Your email address will not be published. Required fields are marked *