크로스 브라우징 총정리

§

[이글은 front-end 개발자분들만을 위한 글 입니다. 그래서 다른분들에게는 재미없는 글 입니다.]

browsers

몇년에 한번씩 크로스 브라우징에 관한 글들이 개발자분들 블로그에 올라오곤 해서 유용하게 참고하곤 했던 기억이 나는데 요즘 통 보질 못했고, 그래서 제가 크로스 브라우징에 관한 글을 써봅니다.

일단 크로스 브라우징이란 html, css, 그리고 javascript 작성시 W3C 의 web standard (웹규격) 에 맞는 코딩을 함으로써 어느 브라우져에서나 기기에서 사이트가 제대로 보여지고 작동되도록 하는 기법을 말합니다. (웹규격 대신 웹표준이란 단어를 쓰기도 하는데, 웹에 표준이란 존재하지 않습니다.)

‘그럼 간단한거네? W3C 규격에 맞춰서 코딩하면 어느 브라우져에서도 깨지지 않고 잘 보이는 사이트가 만들어지겠네?’

라고 생각하시는 분들이 계실수도 있으나, 현실은 그렇지 않습니다. 각 브라우져 마다 작동되지 않는 javascript, html5 코드가 존재하고, 해석하지 못하는 css 코드가 존재하기 때문입니다. 물론 버그들도 존재합니다.

이래서 크로스브라우징은 그냥 개삽질이라고 하시는 분들도 계시나, 몇가지 요령을 터득하면 그냥 개삽질만은 아닙니다.

1. Can I Use 를 사용하자 (front-end 개발자 분들은 Can I Use 방문 할때마다 애드센스 광고 한번씩 눌러주는 습관을 가져봅시다. 이 사이트를 구축해준 분들도 정말 고마운 분들이고, 지속적으로 업데이트 하는 수고를 하고 계십니다.)

can_i_use

http://caniuse.com/#search=indexDB

사용방법은 간단합니다. 사이트 상단의 검색창에 내가 사용하고 싶은 css 나 javascript 명을 넣으면, 어떤 브라우져에서 작동되는지, 작동되지 않는지를 알려줍니다.

indexDB 를 검색해보면,

IE8 에서 아예 작동을 하지 않고, 엣지 (Edge) 브라우저와 사파리 브라우저, 사파리 모바일 브라우져에서는 partial support (부분적인 작동) 이 됨을 알수 있습니다.

그리고 아래 하단에 상세적인 추가 정보도 얻을 수 있습니다. 내가 작성하려는 javascript 나 css 가 모든 브라우져에서 작동하는지 확실히 기억하지 못하겠으면 Can I Use 부터 확인하는 습관을 들이는게 좋습니다.

2. 버그리포트를 자주 참고하자

Github 에는 여러가지 버그관련 정보가 공유됩니다. 요즘 flexbox 를 많이 사용해서 stackoverflow 에도 flexbox 관련 질문이 많이 올라오는데, 아래 페이지는 flexbox 버그 리스트를 모아둔 것 입니다.

https://github.com/philipwalton/flexbugs

Estoque 님도 얼마전 티스토리 테마를 다시 만드시면서 flexbox 버그 때문에 IE 에서 문제를 일으켜 고생하셨다고 하셨는데, 코딩을 하기전, 어떤 버그들이 존재하는지 정확히 인식하고 있다면 쓸데 없는 시간낭비를 하지 않아도 됩니다.

3. 코딩은 보수적으로 하자

내가 가장 최신의 css 와 javascript 을 쓴다고 윗대가리들이 윗분들이 그걸 이해하거나, 알아주거나, 월급을 더 올려주지 않습니다. 그렇지만 새로운, 검증되지 않은 코딩을 했다가 문제가 생기면 본인만 욕먹습니다. 결국 잘해야 본전인겁니다.

떠오르는 고사성어 하나가 온고지신 (溫故之新) 입니다. 새로운 코딩기법을 익히되, 기존 코딩기법을 유용하게 활용하자는게 제 생각입니다.

float 모델은 익히기도 쉽지않고, css 코드도 지저분해지죠. (media query 작성하다 보면 나중에 관리가 안될 정도로 복잡해져서 저도 float 모델을 좋아하지 않습니다.) 그래서 저도 깔끔하게 flexbox 모델로 레이아웃을 코딩하면 좋겠습니다. 익히기도 더 쉽고, 간단하고, 최종코드도 간결하게 작성되고. 얼마나 좋습니까? 그런데 버그가 존재한다는게, 지원하지 않는 브라우져들이 있다는게 함정이죠. (물론 flexbox 용 polyfill 을 적용하시면 되지만, 그럼 또 사이트 로딩속도가 느려지더라구요.)

4. 브라우져 트랜드를 간파하고 있자

내가 주로 개발용으로 사용하고 있는 브라우져가 현재 어떤 위치에 있고, 어떤 추세이고, 어떤 흐름인지 인식하고 있는 것 은 매우 중요하다고 생각합니다.

browser_score

파폭을 개발용 브라우져로 쓰고 계신분들 중, 아직도 파폭에 가장많은 css3 와 html5 feature 들이 탑재되어 있는 줄 아시는 분들이 적지 않습니다.

마찬가지로 사파리를 개발용 브라우져로 쓰고 계신분들은, 사파리가 얼마나 뒤쳐진 브라우져인지 인식하지 못하는 분들이 계시더라구요.

각 브라우져들의 기능 평가도를 보면 현재 크롬과 오페라가 가장 높은 점수를 보여줍니다. 엣지 (Edge 혹은 IE13) 도 점수가 많이 올라온 상태 입니다. 오히려 파폭과 사파리가 점수가 높지않아, 사이트 개발시 가장 신경써서 확인해야 하는 브라우져가 되어버렸습니다.

5. 브라우져 대응순서

가장 점유율이 높은 브라우져 부터 확인하는게 좋습니다.

StatCounter-browser_version_partially_combined-KR-monthly-201506-201606

http://gs.statcounter.com/#browser_version_partially_combined-KR-monthly-201506-201606

한국의 경우 현재 크롬의 점유율이 가장 높고, 그 다음이 IE11 로 나타납니다.

그럼 크롬부터 확인하고 두번째로 IE11 을 확인하시면 되겠죠?

점유율이 0.5%도 안되는 사파리 브라우져는 사실 확인 안하셔도 됩니다.

한국에서 사파리 브라우져 사용자는 어짜피 작동안되는 사이트에 익숙해져 있기때문에 사이트가 작동안되면 자신들이 알아서 IE 나 크롬 같은 브라우져로 사이트를 재방문 합니다. 어짜피 결재도 안되요. 애플은 exe 가 작동 안하거든요. 그래서 애플 사용자들은 신경 안써도 됩니다. (ActiveX 를 없앤다고 했지 exe 를 안쓴다고는 안했다. ㅋㅋㅋ)

그렇기도 하고, 0.5% 점유율도 안나오는 브라우져는 원래 “무시해도 된다.” 는 불문율이 존재합니다.

IE 와 사파리의 다른 점

browser_stack각 버전마다 따로 놉니다. 크롬이나 파폭, 오페라 처럼 항상 최신버전 하나만 사용되느게 아니라, IE8,9,10,11,12,13 이런식으로 여러버전이 존재합니다.

그래서 IE 하고 사파리는 모든 버전을 확인해줘야 합니다. 골때리죠? 네, 예네들이 좀 골때리는 브라우져들 입니다.

참고사항 : jQuery 는 1.X 까지만 IE8을 지원합니다. jQuery 2.X 부터는 IE8 지원이 되지 않습니다.
이제 ES6 시대인데 jQuery 를 버려야 겠어 라고 생각하시는 개발자 분들이 조금씩 보이는데, 아직은 시기상조 입니다.

https://kangax.github.io/compat-table/es6/

지원안되는 ES6 스크립트들이 아직 상당히 많습니다. 물론 자스 작성이 예전보다 상당히 간결해졌고 편해진게 사실입니다. 특히 IE9 이하 지원을 안해도 되면 매우 간결한 스크립팅이 가능합니다. 그런데, 정말 로딩속도/성능에 신경쓴다면, css3 를 적극 사용합시다. fadeIn 같은것도 jQuery 로 구현하나 바닐라 javascript 으로 구현하나, 속도면에서 css3 를 따라오지 못합니다.

el.classList.add(className)하고 css3 로 opacity 넣어주는게 그렇게 번거스럽나요? 귀차니즘에서 벗어나세요. 아무리 내 오너가/상사가 막장이고 미워도 인간적으로 이정도는 해줘야 하지 않을까요?

참고사항2: 크롬과 오페라는 동일한 브라우져라고 봐도 됩니다. 엔진뿐만 아니라 shell 까지 거의 동일합니다. 그럼에도 오페라를 확인하는 이유는 adblock 때문입니다. 오페라에는 기본적으로 adblock (광고 표시되지 않게 하는 기능) 이 장착되어 있습니다.

그래서 이 adblock 을 busting (깨는) 스트립트를 적용할때 내가 작성한/ctrl c+v 해온 adblock busting 스크립트가 제대로 작동하는지 확인할 때 매우 유용합니다.

jsFiddle_adblocker

권유사항: 하위버전 대응할때 대충하세요. 레이아웃만 안깨지면 그냥 넘어가세요. IE8/9 에서 border-radius 안먹는다고 PIE.htc 가져다 쓰지 마세요. 다른 polyfill 들도 그렇고, 이런 제품들은 사이트 로딩속도를 많이 느리게 만듭니다. 방문자에게 border-radius 로 돌린 레이아웃을 보여주는 것 보다, 빠르게 사이트를 접속할 수 있게 해주는게 더 큰 배려 입니다.

(IE8 같은 브라우져를 쓰는 방문자의 컴퓨터는 하드웨어 사양도 매우 낮다는/오래되었다는 뜻 입니다. 컴퓨터 성능에 따라 로딩속도 도 영향을 받습니다. 물론 낮은 컴퓨터 사양을 사용하는 방문자는 그만큼 구매능력도 낮다는 뜻이라서 돈이 되는 트래픽도 아닙니다. 그러니까 하위버전 브라우져 대응은 대충대충 하면 됩니다.)

hackya 는

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

Tags: , , , , , , , , ,

카테고리: , ,

Ω

27 Comments

  • Estoque says:

    글 잘읽었습니다. IE11 플렉스 박스는… 저 같은 경우 쓸수 있을 정도까지만 만들어놓고 완벽작동은 아예 포기한 상태입니다. ㅠㅠ

    사파리의 경우 저도 구버전은 확인안합니다. ㅋㅋ 어짜피 호환성 때문에 구형 OSX 쓰는 사람들은 극소수라서… 그리고 구형 쓰시는 분들은 대부분 크롬이나 파폭쓰죠.

    IE의 경우 예전에는 IE5 까지도 근성으로 대응했었는데 요즘은 IE10 이하는 신경도 안쓰고 있습니다. 예전에는 IE8 대응을 안했더니 사이트가 안들어가진다고 징징대는 사람들이 있었는데 요즘은 그런사람들이 아예 없더러고요… 저같은 경우 html에 id 붙여서 IE는 아예 새로운 CSS만 불러오게 해서 사용중인데, 이마저도 요즘은 귀찮아서 안하고 있습니다. ㅋㅋ

    Can I Use 저도 애용하고 있습니다. ㅋㅋ 정말 좋은 사이트죠 -_-bb

    코딩은 보수적으로 하자 > 공감합니다. 저같은 경우 배포용스킨은 이거 고쳐주세요, 저거 고쳐주세요 소리 듣기 들어서 완전 보수적이게 코딩해놓죠… 아직까지도 크로스브라우징 문제로 컴플레인 거는 사람은 없는 걸보니 성공한것 같습니다. ㅋㅋㅋ

    애드블럭의 경우 저같은 경우에는 그냥 본문을 지워버리는 초강수를 두고 있습니다. (예전에 어떤 이상한 놈이 와서 애드블럭이 좋아요 이러고 다녀서…) 단기적으로는 불만이 있었는데 좀 지나니 그런것도 없더라고요… 대표적으로 sk의 11번가가 애드블럭을 쓰면 사이트로딩이 하나도 안되는데 나름 머리 많이쓴 전략 같아요

    제가 쓴 부트스트랩글에 있는 대한민국 개발자들의 절규에서도 알수 있듯 한국은 유독 IE8을 고집하더라고요… 특히 군복무 시절에 쓰던 PC가 전부 IE8을 썼다는게…(충격과 공포…)

    정작 전산실은 크롬쓰던데 다른 사무실은 IE8 쓰게 만들더군요 -_-

    • Matthew says:

      “애드블럭의 경우 저같은 경우에는 그냥 본문을 지워버리는 초강수를 두고 있습니다.” – 죄송한데 Estoque 님 사이트도 광고 한개도 안보입니다. 그냥 오페라 기본 adblock 만으로도 광고 다 막히는데요?

      • Estoque says:

        제가 테스트 해보니 본문은 아예 안보이네요

        애초에 본문만 막고 댓글이랑 다른 기능은 다 쓸수 있게 설정해둔 상태라… 메인화면은 뜨는게 정상입니다.

        • Matthew says:

          워드님께도 말씀드렸지만, adblock 이 어떤 한가지 제품이 있는게 아닙니다.

          Estoque 님도 javascript 조금 아시니까 조금만 생각해봐도 adblock 막는 스크립트 피하는 새로운 adblock extension 을 만드실 수 있을 것 같은데요…

          • Matthew says:

            Chrome extension 만드는 것 어렵지 않아요.

            https://www.sitepoint.com/create-chrome-extension-10-minutes-flat/

            자스만 작성하실 줄 아시면 extension 만드실 수 있습니다. (한번 해보세요. 재미 있습니다. 금방 만들어요. ㅎㅎㅎ)

            반대로 생각하면, adblock 대응 스크립트는 만들기 어렵지만, adblock extension 은 누구나 만들어 쓰고 공유할 수 있다 가 됩니다.

            그래서 adblock 을 쓰는 사용자들을 적대적으로 대하지 않고, JSFiddle 처럼 방문자들의 협조를 구하는게 가장 바람직한 대응책이라고 말합니다.

            또 컨텐츠를 막는 것 보다는, 광고를 억지로 보여지게 하는 방식도 있는데, 이것 역시 적대감을 형성해서 좋은 방법이 아니라고 말합니다.

            요즘 adblock 을 쓰는 젊은 성인 사용자는 과반수가 넘는다고 합니다.

            26% of internet users say they use an AdBlocker. In Europe the rate is even higher.
            Ad blocking is most popular with younger users – 41% of American internet users aged between 18 and 29 used adblocking software, rising to 54% when only young men are counted.

            https://www.quora.com/What-is-the-percentage-of-Internet-users-that-employ-AdBlock-Plus-or-similar-ad-blocking-plugins

            내 사이트를 방문하는 방문자들을 적대시 해서 절대 득이 되지 않을 겁니다.

            adblock 사용자 분들을 적으로 보고 배타적으로 대하는 것 보다는, 그 분들도 포옹하는 사고 (마인드) 가 더 좋지 않을까요?

          • Estoque says:

            크롬확장도구 끌리네요… 예전부터 한번 만들어봐야지 하고는 있었는데 ㅎㅎ

            제가 adblock 막은건 거창한 방법은 아니고 adblock이 차단하는 class가 존재하더군요 예전에 어떻게 알아냈는데 지금은 가물가물… 어쨌든 그 class를 본문영역에 넣어버리니까 애드블럭이 그냥 지워버립니다. -ㅁ-;

            물론 hackya님이 하신데로 본문영역을 살리고 광고만 날리는 방법도 얼마든지 있겠죠

            사실 저도 애드블럭은 개인의 선택이다 라는 입장이었는데, (물론 저도 유투브 애드블럭은 씁니다. 중간광고 넘나 싫어서)

            2년전인가 별 이상한 놈이 나타나서는 ‘adblock 사랑해요, 난 광고보기 싫으니까 내 블로그에 광고도 안다는데 넌 보기싫은거 왜다냐’ 라며 이딴 광대역 LTE급 오지랖을 하는 사람이 있어서 빡쳐서 한 조치랍니다.

            애드블럭 사용자들이 간혹 글 안보인다고 하소연할때가 있는데 그때는 그냥 애드블럭 끄라고 해줍니다.

          • Matthew says:

            어그로 끄는 인간들은 그냥 상종 안하면 좋습니다. ㅎㅎㅎ

            거기에 반응을 보이면 희열을 느낀답니다. (그러니까, 자기가 욕먹을걸 예상하고 있고, 예상대로 욕을 먹길 바란답니다.)

            악플러, 어그로 들은 그래서 그냥 반응을 보이지 않는게 최상의 선택이라는 말을 들은적이 있습니다.

            저는 제 필요에 의해서 (개발관련) 크롬확장도구를 만들어 쓰곤 했었습니다.

            예를들자면요, 훔.. 이런 얘기 공개적으로 하기 좀 그런데, 제 경우, 가끔 너무나도 뻔한 javascript 이나 jQuery 작성이 생각이 나지 않을때가 있거든요.

            아니면 css 에서 border shorthand 쓸때 syntax 순서가 헷갈린다던지..

            집에서 일하는거면 그냥 찾아보면 되지만, 예전에 (몇년전) 계약직으로 파견되서 근무하고 있을때, 이렇게 막히는 부분이 있으면 구글링 하기가 엄청 눈치 보이더라구요.

            너무나 기본적인건데 그걸 구글링해서 찾아보기가 참….

            요럴때 cheat sheet (컨닝 페이퍼) 이 있으면 참 좋겠다 싶어서, 크롬에다 제가 가끔 혼동오는 css/js syntax 를 깨알같이 적은 cheat sheet 을 달아놓고 슬쩍 슬쩍 열어서 찾아보고 쓰곤 했었습니다. ㅋㅋㅋㅋㅋ

  • WordCracker says:

    좋은 정보 감사합니다.

    저도 만약 블로그를 운영하지 않았다면 adblock을 설치하여 광고가 표시되지 않도록 했을 것 같습니다. 하지만 애드센스 광고 수익에 의존하는 블로거들에게는 큰 문제가 될 것 같네요…

    방문자들이 비난을 하겠지만 특정 카테고리의 글에서는 adblock을 해제해야 글을 볼 수 있도록 방금 바꾸었습니다.ㅎㅎ

    • Matthew says:

      “방문자들이 비난을 하겠지만 특정 카테고리의 글에서는 adblock을 해제해야 글을 볼 수 있도록 방금 바꾸었습니다.ㅎㅎ”

      네?

      오페라 기본 adblock 만으로도 워드님 사이트에 아무런 광고도 보이지 않는데요? 테스트는 해보셨나요?

      웹에 공개되어 있는 스트립트는 기본적인 adblock 스크립도 막지를 못합니다.

      아래 Github 에 공유되어 있는 adblock-killer 스크립트는 현재 막을 수 있는 방법이 아예 없구요.

      https://github.com/reek/anti-adblock-killer

      • WordCracker says:

        크롬에서 테스트했는데, 잘 되네요.
        http://www.thewordcracker.com/intermediate/add-a-second-style-sheet-to-wordpress-theme/
        혹시 오페라에서 이 글에서도 광고가 모두 차단되어 나오나요?

        • Matthew says:

          죄송합니다.

          광고 차단 기능을 해제해야 컨텐츠를 볼 수 있습니다. (해제 후 새로고침 해주세요)

          I am really sorry, but please turn off Adblock.

          워드프레스에서 스타일시트 파일(style.css)과 함수 파일(functions.php)을 자식 테마(차일드 테마) 폴더에 추가하여 자식 테마를 만들 수 있습니다. 이와는 별도로 다음 단계에 따라 새로운 스타일시트 파일을 추가할 수 있습니다.
          .
          .
          .

          광고 차단기능을 해제 해야 본문글이 보인다고 써 있는데, 글과는 다르게 본문글 잘 보입니다. ^^;;;;

          • WordCracker says:

            그럼 오페라에서는 jQuery 스크립트가 안 먹히는 거네요… 크롬의 adblock extension에 대해서는 잘 되니까 그냥 이대로 나가야겠네요.ㅎㅎ

          • Matthew says:

            아니오… 크롬에서나 오페라 에서나 본문글 잘 보입니다….

          • Matthew says:

            본의 아니게 제가 지금 adblock 테스팅을 해드리고 있네요….

            adblock extension 이 한개가 있는게 아니라요… 찾아보시면 수십개 정도 되요… javascript 이나 jQuery 하고 아무런 상관없이 작동하는 제품들도 있습니다.

          • WordCracker says:

            별 생각 없이 http://persnacons.tistory.com/393 글에 나와 있는 방법을 사용했는데, 이게 제대로 먹히지 않는 것 같네요.ㅠㅠ

          • Matthew says:

            저 티스토리 블로그에 어느분이 정답에 가까운 댓글을 달아 주셨네요.

            “요즘 안티-애드블록과 애드블록의 싸움 형세는 애드블록 쪽이 우세라서…. 악덕광고자가 아닌 분들이 고생이 많습니다.
            사실 기술적으로 안티-애드블록이 애드블록을 이기기는 앞으로도 좀 힘들겁니다. 굳이 원리를 말하자면 이 케이스로 예를 들어서 광고 차단 방지 스크립트 이전에 먼저 스크립트를 넣을 수 있는 권한을 가질 수 있는 것이 클라이언트 쪽이기 때문에….
            퍼스나콘님처럼 괜찮은 콘텐츠를 보여주는 분께는 예외 설정이 답! 이번에도 여러 글 잘 보고 갑니다.”

            “광고 차단 방지 스크립트 이전에 먼저 스크립트를 넣을 수 있는 권한을 가질 수 있는 것이 클라이언트 쪽이기 때문에”

            이 글도 맞는 내용이지만 반쪽짜리 답변입니다.

            방문자의 브라우져에서 자스를 먼저 넣을 수 있는 권한도 있지만, 나중에 넣을 수 있는 권한도 있습니다.

            저 티스토리에 방지 스크립트, 저는 setTimeout 함수로 간단히 우회할 수 있거든요. ^^;;;;

            더구나 제가 위 댓글에서도 말씀드렸듯, 저분은 광고가 display:none 되서 보이지 않는 경우만을 고려하고 계십니다.

            opacity: 0 은 display:none 과 다른 성격입니다.

            opacity:0 은 표현되지만 단지 투명도가 0 이라서 투명하게 보이는거거든요. 안보이는게 아닌거죠. 광고 = opacity:0 이런식의 adblock 이라면 저 티스토리 블로그에서 작성한 adblock 대응 스크립트는 무용지물이 됩니다.

          • WordCracker says:

            이상하네요. 제 환경에서는 잘 되네요. 현재 워드프레스 관련 카테고리는 막아놓은 상태이거든요. 오페라에서도 방금 테스트했는데, “광고 차단 기능을 해제해야 컨텐츠를 볼 수 있습니다” 이 문구가 표시되지 않고 그냥 본문 글 자체가 보이지 않네요.
            크롬에서는 AdBlock이라는 차단 익스텐션을 사용하여 테스트했는데, 크롬에서는 원하는대로 잘 작동하네요.
            왜 같은 오페라와 크롬에서 다르게 작동하는지 모르겠네요.

          • Matthew says:

            제가 워드님 코드를 확인해 보지 않았지만, 대략 이런식으로 adblock 스크립트를 넣으셨을 것 같거든요.


            $(document).ready(function(){
            if ($('myAdContainer').height() == 0) {
            // 대응 : 죄송합니다....
            }
            });

            광고 안보이게 하는거는 height 을 0 으로 줘도 되지만 opacity 를 0 으로 줘도 안보입니다.

            opacity 를 0 으로 줘서 안보이게 하는 adblock 이라면 워드님 adblock 은 무용지물이지요.

            이상한게 아니구요.

            모든 가능한 상황을 고려해서 adblock 을 만드셔야 합니다. 웹에 공개된 방법이라면, 그 대응책은 벌써 나와 있다고 생각하시면 됩니다.

  • codei says:

    3. 코딩은 보수적으로 하자

    /애도
    /엉엉
    /분노

    그래요. 최신 코딩법 기껏 보고 배우면 뭐해요. IE에서 안 된다고 하는데.

    • Matthew says:

      저도 IE 몹시 싫어하지만 이런 부분도 있습니다. css/js 코딩하는데 1시간. IE 대응 하는데 5시간.

      front-end 개발자들은 IE 한테 고마워 해야한다. IE 때문에 front-end 개발이 몹시 어려워졌고 그덕에 front-end 개발자들 인건비도 높게 뛰었고 직장도 많이 늘어난거 아니냐?

      라고 당시 Yahoo 개발자 한명이 글을썼다가 완전 핵폭탄을 맞았지만 저는 속으로 이런 주장에 동의 했습니다.

      누구나 코딩을 할 수 있지만 IE 대응은 (특히 IE6 하고 7) 많이 어려웠고 꼼수를 부려야 하는 스킬이 필요해서 당시 IE 대응 잘하던 front-end 개발자들은 분명 득을 본 부분이 있었거든요.

  • Stella Park says:

    저는 요즘도 8까지로 요구 받는 경우가 대부분인데, 혹시 쇼핑몰이나 의료기관에서 10까지 크로스브라우징 하는 곳도 있나요?

    • Matthew says:

      gmail 도 IE8 지원을 끊은지 몇년 되었는데 요즘 IE8 까지 크로스브라우징 해달라는 클라는 없고 (천조국의 경우) 한국은 잘 모르겠습니다.

      천조국 경우는 IE browser market share 가 다 합쳐서 5% 되나… 가장 많이 쓰이는게 IE11 인데, IE11 점유율이 한 3% 정도 밖에 안되서, IE 크로스브라우징 안되도 클라한테 클레임도 안들어 옵니다. ㅎㅎㅎ

  • Amerimnos says:

    와 정말 꿀정보 감사합니다. 이런 꿀같은 정보를!

  • Seungjae says:

    좋은글 잘보고 갑니다. 감사합니다.

  • anno says:

    많은 도움이 되겠네요! 잘 읽고 갑니다 감사합니다~

  • Yoonji Oh says:

    좋은글 잘 보고 갑니다!

Leave a Reply

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