크로스 브라우징

1. 정의

브라우저는 chrome, safari, firefox등 다양한 종류가 있다. 그리고 그 다양한 종류만큼 서로간에 다른 내부적인 렌더링 엔진이 서로 다르다.

렌더링 엔진이 다르다는 것은 어떤 곳에서는 사용 가능한 css 옵션이 어디에서는 사용될 수 없거나, 어느 브라우저에선 사용가능한 javascript 문법이 어느 장소에서는 사용이 불가능하는 등의 격차를 야기한다.

따라서, 개발자는 해당 격차를 최소한 하는 것이 사용자 경험 측면에서도 유리하다고 할 수 있다.

물론, 모든 브라우저를 다 맞춰서 제작하는 것은 불가능에 가깝다. 그래서 타겟팅을 명확하게 할 필요가 있다. 물론, 점유율이 높은 크롬이 잠재적인 고객 층 역시 높으므로 우선지원하는 것이 맞지만, 만약 회사의 매출에 20% 가 IE 8, 9 와 같은 구형 브라우저의 사용층이라면 당연히 이 사용자들을 지원하는 것이 옳다. 즉, 점유율과 매출을 둘 다 따져보고 지원의 우선순위를 결정해야 한다.

2. 그렇다면 어떻게 해야하는가

사실, 고객들이 가장 심각하게 받아들이게 되는 경우는 역시나 브라우저간 css적인 문제점이 클것이다 (바로 눈에 보이기때문에)
특히, 레이아웃과 관련된 css 옵션들에 대해서 깨져버리는 경우들을 생각해보면 몹시 골치가 아프다.

• Can I use
  위 사이트는 내가 사용하려는 css가 어디까지 지원이 가능한지를 검색해서 알 수 있는 내용이다. 만약 어떤 특정한 css를 사용하려는데, 이게 사용이 될지 안될지 명확하지 않다면 검색해보는것을 습관하해야한다

• CSS 초기화
  브라우저마다 기본 내장된 css default가 다르기 때문에 필수불가결적으로 global하게 css를 하나의 기준으로 맞추고 시작해야 한다

• prefix
  브라우저마다 자신들이 지원이 가능한 css의 prefix를 가지고 있다 (ex -webkit- 은 크롬과 사파리에서, -moz-는 파이어폭스에서 사용이 가능)
  그래서 css 디자인을 할 때, 이런 prefix를 붙인 디자인 역시 추가를 해줄 필요가 있다.

• 브라우저 버전별 디자인 분리
  이건 정말 개인적인 생각이긴하지만, 크로스 브라우징을 위해 css를 건들다보면 css상에 내용이 상당히 많아지고 길어진다.
  내용이 길어진다는 것은 보기가 어려워진다는 것을 뜻하고, 그것은 유지보수적으로 몹시 힘들어진다는 것을 의미한다. (일일이 다 찾아야하니)

따라서, 크로스 브라우징을 위한 css를 따로 분리하면 좋겠다는 개인적인 생각이 든다.
만약 styled component와 같은 CSS-IN-JS 스타일의 디자인을 한다면, 맨 처음 앱이 구동될 때 useEffect를 통해

이런식으로 현재 접속한 브라우저가 무엇인지를 초기에 확인한 후, 그 값에 따라 class명을 설정해준 뒤,
각 styled-component에서 제공하는 css 메서드를 이용, 해당 클래스별로 css를 달리 삽입해주는 것도 방법이 될 수 있을것으로 보인다.

javascript의 경우

babel을 통한 폴리필을 업데이트하여 최신 문법이 구형 브라우저에도 문제없이 호환되도록 설치, 추가해준다

.