크로스 브라우징 총정리

§

[이글은 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: , , , , , , , , ,

카테고리: , ,

Ω