Internet Explorer 8에서 하루 동안 웹을 사용했습니다.

이 기사는 주어진 사용자 인구 통계를 나타내는 다양한 제약 조건에서 웹을 사용하려고 시도하는 시리즈의 일부입니다. 나는 우리가 그들의 필요에 공감하는 방식으로 디자인하고 개발한다면 피할 수 있는 실제 사람들이 직면한 어려움에 대한 프로필을 올리기를 희망합니다.

지난 번에는 스크린 리더를 사용하여 하루 동안 웹을 탐색했습니다. 이번에는 10년 전 오늘인 2009년 3월 19일에 출시된 Internet Explorer 8을 사용하여 하루를 보냈습니다.

세계에서 누가 IE8을 사용합니까?

시작하기 전에 면책 조항: IE8 지원을 시작해야 한다고 말하는 것이 아닙니다 .

IE8을 지원하지 않는 모든 이유가 있습니다. Microsoft는 3년 전에 공식적으로 IE8, IE9 및 IE10 지원을 중단했으며 Microsoft 경영진은 Internet Explorer 11 사용을 중단하라고 말하기까지 합니다.

그러나 우리 개발자들이 그것이 사라지기를 바라는 만큼 그것은 그저 그렇습니다. 습관. 다이 . IE8은 특히 서구 세계의 거품이 아닌 곳에서 브라우저 통계에 계속 표시됩니다.

브라우저 통계는 약간의 소금으로 받아들여야 하지만 전 세계적으로 IE8 사용에 대한 현재 추정치는 데스크톱 시장 점유율의 약 0.3%에서 0.4%입니다. 추정치의 하단은 w3counter에서 가져온 것입니다.

더 높은 추정치는 StatCounter("사용 가능" 사용 표에서 사용하는 것과 동일한 데이터 피드)에서 가져옵니다. 전 세계 IE8 데스크톱 브라우저 비율은 약 0.37%로 추정됩니다.

특정 지역에서 IE8 사용량이 더 높을 수 있다고 생각하여 대륙별로 데이터를 드릴했습니다.

지역별 IE8 사용량

다음은 대륙별 IE8 데스크톱 비율입니다(2018년 2월 - 2019년 1월 데이터).

아시아의 누군가는 오세아니아의 누군가보다 IE8을 사용할 가능성이 5배 더 높습니다.

각 국가의 IE8 사용 비율에 주목하면서 아시아 통계를 더 자세히 살펴보았습니다. IE8 사용에 대해 매우 명확한 상위 6개국이 있으며 그 이후에는 세계 평균과 비교하기 위해 수치가 낮아집니다.

이 데이터는 아래 지도에 요약되어 있습니다.

놀랍게도 IE8은 이란 데스크톱 사용자의 약 4%를 차지합니다. 이는 오세아니아의 IE8 사용자 비율의 40배 입니다.

다음으로 아프리카의 국가 통계를 살펴보았습니다. 전체 IE8 사용량이 아시아와 거의 같았기 때문입니다. 명백한 승자가 있었고(에리트레아), 사용률이 1% 이상이거나 그 주변인 여러 국가가 그 뒤를 이었습니다.

아래 지도에 요약되어 있습니다.

IE8을 평소보다 많이 사용하는 아시아 국가는 지리적으로 대략적으로 일괄 처리되지만 아프리카에는 패턴이 없는 것 같습니다. 우연이 아닌 한 내가 볼 수 있는 유일한 패턴은 세계에서 가장 큰 IE8을 사용하는 여러 국가에서 인터넷 액세스를 검열하는 것으로 유명하므로 더 안전한 브라우저로의 업데이트를 권장하거나 허용하지 않을 것입니다.

귀하의 사이트가 순전히 서양인을 대상으로 하는 경우 IE8에 대해서는 별로 신경을 쓰지 않을 것입니다. 그러나 급성장하는 아시아 또는 아프리카 시장이 있고 특히 중국, 이란 또는 에리트레아의 사용자에 관심이 있는 경우 웹 사이트의 IE8 경험에 매우 관심이 있을 수 있습니다. 예 — 2019년에도!

누가 여전히 IE를 사용하고 있습니까?

그래서, 이 사람들 은 누구인가? 그들은 정말로 우리 사이를 걷고 있습니까?!

그들이 누구든지 당신을 귀찮게 하기 위해 오래된 브라우저를 사용하고 있는 것은 아닙니다. 아무도 의도적으로 더 나쁜 브라우징 경험을 선택 하지 않습니다.

다음과 같은 이유로 누군가가 이전 브라우저를 사용하고 있을 수 있습니다.

• 인식의 부족
  그들은 단순히 그들이 구식 기술을 사용하고 있다는 것을 인식하지 못합니다.
• 교육 부족
  그들은 업그레이드 옵션과 그들에게 열려 있는 대체 브라우저를 모릅니다.
• 계획 부족
  바쁘다는 이유로 업그레이드 프롬프트를 닫지만 더 조용한 기간 동안 업그레이드할 계획이 없습니다.
• 변화에 대한 거부감
  마지막으로 소프트웨어를 업그레이드했을 때 새로운 UI를 배워야 했습니다. "고장난 게 아니라면 고치지 마세요."
• 위험 회피
  마지막으로 업그레이드했을 때 컴퓨터 속도가 느려지거나 즐겨 사용하는 기능이 손실되었습니다.
• 소프트웨어 제한
  OS가 너무 오래되어 업그레이드할 수 없거나 관리자 권한이 잠겨 있을 수 있습니다.
• 하드웨어 제한
  최신 브라우저는 일반적으로 하드 디스크 공간, 메모리 및 CPU를 더 많이 요구합니다.
• 네트워크 제한
  제한된 데이터 허용량 또는 느린 연결은 75MB의 소프트웨어 다운로드를 원하지 않는다는 것을 의미합니다.
• 법적 제한
  하나의 특정 브라우저만 사용하는 회사 컴퓨터에 있을 수 있습니다.

아직도 전 세계에 IE8에 집착하는 사람들이 있다는 것이 정말 놀라운 일입니까?

나는 이 익명의 영혼 중 한 사람이 되어 IE8을 사용하여 하루 동안 웹을 검색하기로 결정했습니다. 집에서 같이 놀 수 있어요! Microsoft 웹 사이트에서 "Windows 7의 IE8" 가상 머신을 다운로드한 다음 VirtualBox와 같은 가상 장치에서 실행합니다.

IE8 VM: 시작이 좋지 않음

IE8 VM을 부팅하고 예상대로 Internet Explorer 프로그램을 클릭했는데 이것이 내가 본 것입니다.

흠, 알았어. IE8에서 가져온 기본 웹 페이지가 더 이상 존재하지 않는 것 같습니다. 글쎄, 그 수치. Microsoft는 공식적으로 IE8 지원을 중단했는데 왜 IE8 랜딩 페이지가 계속 작동하는지 확인해야 합니까?

나는 세계에서 가장 널리 사용되는 사이트로 전환하기로 결정했습니다.

Google

단순한 사이트이므로 잘못 이해하기 어렵습니다. 그러나 공정하게 말하면 멋지게 보입니다! 나는 무언가를 검색하려고 시도했다 :

레이아웃이 내가 익숙한 것과 약간 다르게 보이지만 검색은 잘 작동했습니다. 그러던 중 자바스크립트가 꺼진 상태에서 하루 동안 인터넷을 사용할 때와 동일한 검색 결과 레이아웃을 본 것이 기억났습니다.

참고로 JavaScript가 활성화된 최신 브라우저에서 검색 결과가 어떻게 표시되는지는 다음과 같습니다.

따라서 IE8은 Google 검색의 JS 버전이 아닌 것 같습니다. 나는 이것이 반드시 의도적인 디자인 결정이라고 생각하지 않습니다. 단지 JavaScript에서 오류가 발생했을 수 있습니다.

그래도 최종 결과는 괜찮습니다. 검색 결과를 얻었고, 이것이 제가 원하는 전부였습니다.

유튜브 영상을 보기 위해 클릭했습니다.

유튜브

이 페이지에 대해 상당히 많은 부분이 깨졌습니다. IE의 약간의 단점과 관련이 있습니다.

예를 들어 로고가 확대되고 잘립니다. 이것은 SVG를 지원하지 않는 IE8까지이며 실제로 보고 있는 것은 YouTube에서 제공하는 대체 옵션입니다. SVG가 지원되지 않는 경우 로고를 표시할 수 있도록 background-image CSS 속성을 적용했습니다. background-size 를 제대로 설정하지 않은 것 같아서 조금 더 확대한 것 같습니다.

참고로 다음은 Chrome의 동일한 페이지입니다(Chrome이 대신 SVG를 렌더링하는 방법 참조).

그리고 그 자동 재생 토글은 어떻습니까? 이상한 모양의 확인란처럼 렌더링됩니다.

이것은 IE가 이해하지 못하는 사용자 정의 요소(머티리얼 디자인 요소인 종이 토글 버튼)를 사용하기 위한 것으로 보입니다.

이것이 제대로 렌더링되지 않은 것은 놀라운 일이 아닙니다. IE8은 우리가 요즘 사용하는 기본적인 의미 마크업에도 대응하지 못합니다. <aside> 또는 <main> 을 사용하면 기본적으로 div로 렌더링되지만 적용한 스타일은 무시됩니다.

HTML5 마크업을 활성화하려면 이러한 요소가 존재한다는 것을 브라우저에 명시적으로 알려야 합니다. 그런 다음 평소처럼 스타일을 지정할 수 있습니다.

 <!--[if lt IE 9]> <script> document.createElement('header'); document.createElement('nav'); document.createElement('section'); document.createElement('article'); document.createElement('aside'); document.createElement('footer'); </script> <![endif]-->

그건 그렇고, IE 조건부로 싸여 있습니다. <!--[if lt IE 9]> 는 대부분의 브라우저에 대한 HTML 주석이므로 건너뜁니다. 그러나 IE에서는 DOM 노드를 실행/렌더링하는 "IE 9 미만인 경우"만 전달하는 조건부입니다. 그 안에.

따라서 비디오 페이지는 실패했습니다. YouTube.com을 직접 방문하는 것은 그다지 좋지 않습니다.

단념하지 않고 경고를 무시하고 YouTube 검색 창에서 동영상을 검색해 보았습니다.

IE8 트래픽은 YouTube가 내가 실제 사용자라는 것을 신뢰하지 않을 만큼 충분히 의심스럽고 내 검색 요청을 처리하지 않기로 결정했습니다!

Gmail에 가입하기

IE8에서 하루를 보내려면 이메일 주소가 필요합니다. 그래서 새로 설정하려고 합니다.

우선 Gmail을 사용해 보았습니다.

여기 이미지와 텍스트에 대해 약간의 차이가 있습니다. IE8이 미디어 쿼리를 지원하지 않기 때문이라고 생각합니다. 그래서 데스크톱에서 모바일 이미지를 보여주려고 합니다.

이 문제를 해결할 수 있는 한 가지 방법은 Sass를 사용하여 두 개의 스타일시트를 생성하는 것입니다. 하나는 최신 브라우저용이고 다른 하나는 레거시 IE용입니다. 미디어 쿼리에 믹스인을 사용하여 IE 친화적인 모바일 우선 CSS(Jake Archibald의 자습서 참조)를 얻을 수 있습니다. 믹스인은 레거시 IE CSS를 "평평하게"하여 IE를 항상 미리 정의된 특정 너비(예: 65em)인 것처럼 처리하여 해당 너비에 대한 관련 CSS만 제공합니다. 이 경우 가정한 화면 크기에 맞는 background-image 를 보고 더 나은 경험을 했을 것입니다.

어쨌든 '계정 만들기'를 클릭하는 것을 멈추지 않았습니다. IE8과 최신 브라우저에서 보이는 방식에는 몇 가지 차이점이 있습니다.

첫눈에 유망하지만 양식을 채우는 데 버그가 많았습니다. 필드를 채우기 시작할 때 '레이블'이 방해가되지 않으므로 입력 텍스트가 난독화됩니다.

이 레이블의 마크업은 실제로 <div> 이며 일부 영리한 JS는 입력에 포커스가 있을 때 텍스트를 이동시킵니다. JS는 IE8에서 성공하지 못하므로 텍스트가 제자리에 고정되어 있습니다.

모든 정보를 입력한 후 "다음"을 누르고 기다렸습니다. 아무 일도하지.

그런 다음 IE 창의 왼쪽 하단에 있는 작은 노란색 경고 기호를 발견했습니다. 나는 그것을 클릭했고 그것이 JS 오류에 대해 불평하는 것을 보았다:

Gmail을 포기하고 MSN으로 전환했습니다.

핫메일에 가입하기

나는 10년 된 브라우저에서 이메일이 제한되지 않을까 걱정하기 시작했습니다. 하지만 Hotmail에 갔을 때 가입 양식은 괜찮아 보였습니다. 지금까지는 아주 좋았습니다.

그러다가 보안문자를 발견했습니다. '이건 어쩔 수 없구나...'라고 생각했다.

놀랍게도 CAPTCHA가 작동했습니다!

양식에서 유일하게 기발한 것은 약간 버그가 있는 레이블 위치 지정이었지만 등록은 원활했습니다.

그 스크린샷이 괜찮아 보이나요? 고의적인 실수를 발견할 수 있습니까?

맨 왼쪽 입력은 내 성이 아니라 내 이름 이어야 합니다. 나중에 돌아와서 이 페이지 를 확인했을 때 "이름" 레이블을 클릭하고 맨 왼쪽 입력에 포커스를 적용했습니다. 이것은 접근 가능한 마크업의 중요성을 보여줍니다. CSS와 시각적 연결 없이도 어떤 입력 상자가 어떤 레이블에 적용되었는지 정확히 결정할 수 있었습니다(두 번째이긴 하지만!).

어쨌든 가입 절차를 완료할 수 있었고 MSN 홈페이지로 리디렉션되어 훌륭했습니다.

기사를 읽고도 IE8을 사용하고 있다는 사실을 잊어버릴 수도 있었습니다.

이메일이 등록되면 인터넷의 나머지 부분을 확인할 준비가 되었습니다!

페이스북

나는 Facebook 사이트를 방문했고 즉시 모바일 사이트로 리디렉션되었습니다.

Facebook은 저사양 모바일 장치에서 전 세계의 많은 사용자를 지원해야 하므로 기본 버전의 Facebook을 제공해야 하므로 이는 영리한 대체 전술입니다. 이전 데스크톱 브라우저에 동일한 경험 기준을 제공하지 않는 이유는 무엇입니까?

회원가입을 해보니 계정을 만들 수 있었습니다. 엄청난! 하지만 그 계정에 로그인했을 때 의심의 대상이 되어 YouTube에서 검색했을 때와 마찬가지로 CAPTCHA에 직면했습니다.

이번에는 그렇게 쉽지만은 않았습니다.

새 코드를 요청하고 페이지 새로고침을 여러 번 시도했지만 CAPTCHA 이미지가 로드되지 않아 사실상 계정이 잠겼습니다.

오 글쎄. 소셜 미디어를 좀 더 사용해 보겠습니다.

트위터

나는 트위터 사이트를 방문했고 정확히 동일한 모바일 리디렉션 경험을 했습니다.

하지만 이번에는 계정 등록조차 할 수 없었습니다.

이상하게도 Twitter는 로그인하면 기뻐하지만 처음부터 등록하는 것은 아닙니다. 이유는 모르겠지만 가입 페이지에 유사한 보안 문자 시나리오가 있고 이전 브라우저에서는 작동하지 않을 수 있습니다. 어쨌든 새 계정을 만들 수 없습니다.

기존 트위터 계정으로 로그인하는 것이 어색했습니다. 편집증이라고 부르세요. 하지만 2013년의 CFR Watering Hole Attack과 같은 취약점(IE8에서 특정 URL을 방문하는 것만으로도 컴퓨터에 멀웨어가 설치됨)과 같은 취약점으로 인해 내 계정이 손상될 수 있다는 사실이 걱정스러웠습니다.

그러나 교육을 위해 나는 인내했습니다(임시 새 비밀번호 사용).

매우 기본적인 <textarea> 를 사용하더라도 트윗할 수도 있습니다.

결론적으로 트위터는 기본적으로 IE8에서 괜찮습니다. 이미 계정이 있는 한!

나는 오늘의 소셜 미디어 작업을 마쳤습니다. 뉴스를 확인하러 가자.

BBC 뉴스

뉴스 홈페이지는 매우 기본적이고 투박해 보이지만 혼합된 콘텐츠 보안 경고와 함께 기본적으로 작동합니다.

로고를 살펴보십시오. YouTube에서 이미 보았듯이 IE8은 SVG를 지원하지 않으므로 PNG 대체가 필요합니다.

BBC는 <image> 폴백 기술을 사용하여 IE에서 PNG를 렌더링합니다.

... SVG를 사용할 수 있을 때 PNG를 무시하려면:

이 기술은 이전 브라우저가 <image> 및 <img> 태그를 모두 준수하는 데 사용되어 알려지지 않은 <svg> 태그를 무시하고 대체를 렌더링하는 반면 최신 브라우저는 SVG 내부에서 렌더링 <image> 를 무시한다는 사실을 이용합니다. Chris Coyier가 이 기술을 더 자세히 설명합니다.

나는 기사를 보려고 시도했다:

읽을 수 있습니다. 헤드라인, 내비게이션, 추천 이미지를 볼 수 있습니다. 그러나 나머지 기사 이미지는 누락되었습니다.

이것은 예상된 것이며 BBC 지연 로딩 이미지 때문입니다. IE8이 '지원되는 브라우저'가 아니라는 것은 지연 로딩을 가능하게 하는 JavaScript를 얻지 못하므로 이미지가 전혀 로드되지 않는다는 것을 의미합니다.

흥미롭게도 BBC iPlayer에 액세스하려고 하면 어떻게 되는지 알 수 있을 거라고 생각했습니다.

그리고 다른 스트리밍 서비스에 대해 궁금해했습니다.

넷플릭스

IE8에서 Netflix를 로드할 때 빈 흰색 페이지를 기대하고 있었습니다. 실제로 괜찮은 랜딩 페이지를 보고 매우 놀랐습니다.

나는 이것을 최신 Chrome 버전과 비교했습니다.

약간 다른 클릭 유도문안(버튼 텍스트)이 있습니다. 아마도 내가 사용하는 브라우저가 아니라 다변수 테스트일 것입니다.

렌더링에서 다른 점은 중앙 집중식 텍스트와 반투명 검정 오버레이입니다.

중앙 집중식 텍스트가 없는 것은 Netflix가 항목을 정렬하기 위해 Flexbox를 사용하기 때문입니다.

이 클래스의 text-align: center 는 IE8(및 실제로 모든 이전 브라우저)의 중앙 정렬을 수정합니다. 최대 브라우저 지원을 위해 이전 '안전한' CSS를 사용하여 CSS 폴백 접근 방식을 따른 다음 이를 지원하는 브라우저에 대해 보다 현대적인 CSS로 레이아웃을 강화할 수 있습니다.

배경이 없는 것은 IE8 이하에서 지원되지 않는 rgba() 를 사용하기 때문입니다.

전통적으로 다음과 같은 CSS 폴백을 제공하는 것이 좋습니다. 이전 브라우저에는 검정색 배경을 표시하지만 최신 브라우저에는 반투명 배경을 표시합니다.

 rgb(0, 0, 0); /* IE8 fallback */ rgba(0, 0, 0, 0.8);

이것은 매우 IE 전용 수정이지만 기본적으로 다른 모든 브라우저는 rgba 를 지원합니다. 더욱이 이 경우 멋진 Netflix 타일을 모두 잃게 되므로 배경 필터가 전혀 없는 것이 좋습니다! 브라우저 간 지원을 보장하는 확실한 방법은 필터를 배경 이미지 자체에 굽는 것입니다. 간단하지만 효과적인.

어쨌든, 지금까지는 정말 좋았습니다. IE8은 실제로 홈페이지를 꽤 잘 표현했습니다! 오늘 IE8에서 브레이킹 배드 를 실제로 볼까?

내 이미 잠정적인 낙관론은 로그인 페이지를 보는 즉시 무너졌습니다.

그래도 로그인할 수 있었고 축소된 대시보드를 볼 수 있었습니다(멋진 자동 확장 예고편 없음).

막연한 기대감으로 프로그램을 눌렀는데 당연히 검은 화면만 떴다.

아마존

좋아, 소셜 미디어와 비디오가 나왔다. 남은 것은 쇼핑하는 것뿐입니다.

나는 Amazon을 확인하고 완전히 놀랐습니다. 최신 브라우저에서 경험할 수 있는 경험과 거의 구별할 수 없습니다.

예전에 좋은 홈페이지에 끌려간 적이 있습니다. 제품 페이지를 클릭하고 이것이 단지 우연인지 확인하겠습니다.

아니요! 상품페이지도 잘봤습니다!

Amazon은 이전 버전과의 호환성에서 나를 놀라게 한 유일한 사이트가 아니었습니다. Wikipedia는 Gov.UK 정부 웹사이트와 마찬가지로 훌륭해 보였습니다. IE8에서 완전한 자동차 충돌처럼 보이지 않는 사이트를 갖는 것은 쉽지 않습니다. 내 경험의 대부분은 확실히 덜 세련되었습니다...!

그러나 사용되지 않는 경고 알림이나 펑키한 레이아웃은 오늘 내가 본 최악의 것이 아닙니다.

완전히 부서진 사이트

일부 사이트는 너무 깨져서 연결조차 할 수 없었습니다!

일시적인 VM 네트워크 문제인지 궁금했는데, 페이지를 새로고침할 때마다 발생했고, 나중에 같은 사이트로 돌아와도 마찬가지였습니다.

이것은 하루 종일 몇 가지 다른 사이트에서 발생했으며 결국 이것이 HTTP의 사이트에는 영향을 미치지 않고 HTTPS 에서만 ( 모든 HTTPS 사이트는 아님) 결론을 내렸습니다. 그래서, 무엇이 문제였습니까?

Wireshark를 사용하여 네트워크 트래픽을 분석하여 GitHub에 다시 연결을 시도했습니다. "설명: 프로토콜 버전"이라는 치명적인 오류로 인해 연결 설정에 실패한 것을 볼 수 있습니다.

IE8의 기본 설정을 보면 TLS 1.0만 활성화되어 있지만 GitHub는 2018년 2월에 TLSv1 및 TLSv1.1에 대한 지원을 중단했습니다.

TLS 1.1 및 TLS 1.2에 대한 확인란을 선택하고 페이지를 다시 로드한 다음 — 짜잔! — GitHub를 볼 수 있었습니다!

이 문제를 디버깅하는 데 도움을 준 매우 재능 있는 친구 Aidan Fewster에게 감사드립니다.

저는 모두 하위 호환성을 지지하지만 이것은 흥미로운 딜레마를 나타냅니다. PCI 보안 표준 위원회에 따르면 TLS 1.0은 안전하지 않으며 더 이상 사용해서는 안 됩니다. 그러나 TLS 1.1 이상을 강제 실행하면 일부 사용자는 항상 잠겨 있게 됩니다(모든 사용자가 고급 설정에서 TLS 1.2를 활성화할 만큼 기술에 정통한 것은 아닙니다).

안전하지 않은 더 오래된 표준을 허용하고 사용자가 계속해서 당사 사이트에 연결할 수 있도록 함으로써 우리는 사용자를 돕는 것이 아니라 더 안전한 기술로 이동할 이유를 제공하지 않음으로써 사용자를 해치고 있습니다. 그렇다면 구형 브라우저를 지원하려면 어디까지 가야 할까요?

이전 브라우저 지원을 시작하려면 어떻게 해야 합니까?

어떤 사람들은 "구형 브라우저 지원"에 대해 생각할 때 IE를 위한 독점적인 오래된 해킹을 생각할 수 있습니다. 그 당시 BBC는 IE7에서 iframe 콘텐츠를 지원하기 위해 엄청나게 힘든 일을 해야 했습니다.

또는 Internet Explorer의 "특이한 모드"에서 작동하도록 하는 방법을 생각할 수도 있습니다. 표준과 매우 다르게 렌더링하는 IE 고유의 작동 모드입니다.

그러나 "이전 브라우저 지원"은 "IE용 해킹"과 매우 다릅니다. 나는 후자를 옹호하지 않지만 우리는 실용적으로 전자를 하도록 노력해야 합니다. 웹 개발자로서 내가 지키려고 하는 주문은 다음과 같습니다.

"다수를 위해 최적화하고 소수를 위해 노력하며 보안을 희생하지 마십시오."

이제 IE8의 세계에서 벗어나 레거시 브라우저 지원을 위한 일반적이고 지속 가능한 솔루션에 대해 이야기하겠습니다.

이전 브라우저를 지원하기 위한 두 가지 광범위한 전략이 있으며 둘 다 P로 시작합니다.

1. 폴리필링
   누락된 브라우저 기능을 채워 모두를 위한 기능 동등성을 위해 노력하십시오.
2. 점진적 향상
   핵심 경험에서 시작한 다음 기능 감지를 사용하여 기능을 계층화하십시오.

이러한 전략은 서로 배타적이지 않습니다. 그들은 함께 사용할 수 있습니다. 두 접근 방식 모두 각각 고유한 뉘앙스가 있는 구현 결정을 내려야 합니다. 이에 대해서는 아래에서 더 자세히 다루겠습니다.

폴리필링

일부 웹 사이트 또는 웹 페이지의 경우 JavaScript는 기능에 매우 중요하며 가능한 한 많은 브라우저에 작동하는 JavaScript를 전달하기를 원합니다.

이를 수행하는 방법에는 여러 가지가 있지만 먼저 역사 수업입니다.

ECMAScript의 간략한 역사

ECMAScript는 표준이고 JavaScript는 해당 표준의 구현입니다. 즉, ES5는 "ECMAScript 버전 5"이고 ES6은 "ECMAScript 버전 6"입니다. 혼란스럽게도 ES2015는 ES6과 동일합니다.

ES6은 릴리스 이전에 해당 버전의 대중화된 이름이었지만 ES2015가 공식 이름이며 후속 ECMAScript 버전은 모두 릴리스 연도와 연결됩니다.

참고 : 이 모든 것은 Brandon Morelli가 JavaScript 버전의 전체 역사를 설명하는 훌륭한 블로그 게시물에서 유용하게 설명합니다.

작성 당시 최신 표준은 ES2018(ES9)입니다. 대부분의 최신 브라우저는 최소 ES2015를 지원합니다. 거의 모든 브라우저는 ES5를 지원합니다.

기술적으로 IE8은 ES5가 아닙니다. ES4도 아닙니다(존재하지 않습니다. 프로젝트가 중단되었습니다). IE8은 JScript라고 하는 ECMAScript 3의 Microsoft 구현을 사용합니다. IE8은 ES5를 일부 지원하지만 ES5 표준이 발표되기 몇 달 전에 출시되었기 때문에 지원이 일치하지 않습니다.

트랜스파일과 폴리필링

ES5 JavaScript를 작성할 수 있으며 거의 ​​모든 고대 브라우저에서 실행됩니다.

 var foo = function () { return 'this is ES5!'; };

이전 버전과의 호환성을 영원히 가능하게 하기 위해 이와 같이 모든 JavaScript를 계속 작성할 수도 있습니다. 그러나 JavaScript의 진화하는 버전에서 사용할 수 있게 된 새로운 기능과 구문 설탕을 놓치게 되어 다음과 같은 것을 작성할 수 있습니다.

 const foo = () => { return 'this is ES6!'; };

이전 브라우저에서 해당 JavaScript를 실행하면 오류가 발생합니다. 브라우저가 이해할 수 있는 이전 버전의 JavaScript로 코드를 변환해야 합니다(즉, 자동화된 도구를 사용하여 ES6 코드를 ES5로 변환).

이제 코드가 Array.indexOf 와 같은 표준 ES5 메서드를 사용한다고 가정해 보겠습니다. 대부분의 브라우저에는 기본적으로 구현되어 있으며 제대로 작동하지만 IE8은 중단됩니다. IE8은 ES5 표준이 발표되기 몇 달 전에 출시되어 지원이 일치하지 않는 것을 기억하십니까? 그 한 가지 예는 String 에 대해 구현되었지만 Array 에 대해서는 구현되지 않은 indexOf 함수입니다.

IE8에서 Array.indexOf 메서드를 실행하려고 하면 실패합니다. 그러나 이미 ES5로 작성하고 있다면 다른 무엇을 할 수 있습니까?

누락된 메서드의 동작을 폴리필 할 수 있습니다. 개발자는 전통적으로 코드를 복사하여 붙여넣거나 외부 타사 폴리필 라이브러리를 가져와 필요한 각 기능을 폴리필합니다. 많은 JavaScript 기능은 각각의 Mozilla MDN 페이지에 좋은 폴리필 구현을 가지고 있지만 동일한 기능을 폴리필할 수 있는 여러 방법이 있다는 점을 지적할 가치가 있습니다.

예를 들어 IE8에서 Array.indexOf 메서드를 사용할 수 있도록 하려면 다음과 같이 폴리필을 복사하여 붙여넣습니다.

 if (!Array.prototype.indexOf) { Array.prototype.indexOf = (function (Object, max, min) { // big chunk of code that replicates the behaviour in JavaScript goes here! // for full implementation, visit: // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/indexof#Polyfill })(Object, Math.max, Math.min); }

자신의 JS를 가져오기 전에 폴리필을 호출하고 Array.indexOf 이외의 ES5 JavaScript 기능을 사용하지 않는 한 페이지는 IE8에서 작동합니다.

Polyfills는 모든 종류의 누락된 기능을 연결하는 데 사용할 수 있습니다. 예를 들어 :last-child (IE8에서 지원되지 않음) 또는 placeholder 속성(IE9에서 지원되지 않음)과 같은 CSS3 선택기를 활성화하기 위한 폴리필이 있습니다.

폴리필은 크기와 효율성이 다양하며 때때로 jQuery와 같은 외부 라이브러리에 종속됩니다.

"폴리필"이 아닌 "심"이라는 말을 들을 수도 있습니다. 이름에 너무 집착하지 마십시오. 사람들은 두 용어를 같은 의미로 사용합니다. 그러나 기술적으로 말하면 shim은 API 호출을 가로채고 추상화 계층을 제공하는 코드입니다. 폴리필은 브라우저 에서 일종의 shim 입니다. 특히 JavaScript를 사용하여 이전 브라우저에서 새로운 HTML/CSS/JS 기능을 개조합니다.

"수동으로 폴리필 가져오기" 전략 요약:

• 폴리필 선택을 완벽하게 제어합니다.
• 기본 웹사이트에 적합합니다.
• ️ 추가 도구 없이 기본 ES5 JavaScript로 작성해야 합니다.
• ️ 모든 폴리필을 미세하게 관리하기 어렵습니다.
• ️ 필요 여부에 관계없이 모든 사용자는 즉시 폴리필을 받게 됩니다.

바벨 폴리필

ES6 코드를 ES5로 변환하는 것에 대해 이야기했습니다. 트랜스파일러 를 사용하여 이 작업을 수행합니다. 그 중 가장 인기 있는 것은 Babel입니다.

Babel은 프로젝트 루트에 있는 .babelrc 파일을 통해 구성할 수 있습니다. 여기에서 다양한 Babel 플러그인 및 사전 설정을 가리킵니다. 일반적으로 필요한 각 구문 변환 및 브라우저 폴리필에 대해 하나씩 있습니다.

이들을 미세하게 관리하고 브라우저 지원 목록과 동기화하는 것이 어려울 수 있으므로 오늘날 표준 설정은 해당 미세 관리를 @babel/preset-env 모듈에 위임하는 것입니다. 이 설정을 사용하면 지원하려는 브라우저 버전 목록을 Babel에 제공하기만 하면 됩니다.

 { "presets": [ [ "@babel/preset-env", { "useBuiltIns": "usage", "targets": { "chrome": "58", "ie": "11" } } ] ] }

@babel/preset-env 의 useBuiltIns 구성 옵션은 애플리케이션의 진입점에서 import "@babel/polyfill" (또 다른 모듈)와 함께 마법이 일어나는 곳입니다.

• 생략하면 useBuiltIns 는 아무 작업도 수행하지 않습니다. @babel/polyfill 전체가 앱에 포함되어 있어 상당히 무겁습니다.
• "entry" 로 설정하면 @babel/polyfill 가져오기를 여러 개의 더 작은 가져오기로 변환하여 .babelrc (이 예에서는 Chrome 58 및 IE 11)에 나열한 대상 브라우저를 폴리필하는 데 필요한 최소 폴리필을 가져옵니다. .
• "usage" 으로 설정하면 코드 분석을 수행하고 실제로 사용 되는 기능에 대해서만 폴리필을 가져옴으로써 한 단계 더 나아갑니다. "실험적"으로 분류되지만 "너무 적음"이 아니라 "polyfill too much" 측면에서 오류가 발생합니다. 어쨌든 "entry" 또는 false 보다 더 큰 번들을 생성하는 것이 어떻게 가능한지 알 수 없으므로 선택하는 것이 좋습니다.

Babel을 사용하면 프로덕션에 배포하기 전에 JavaScript를 변환 및 폴리필할 수 있으며 특정 최소 브라우저 기준선에서 지원을 대상으로 지정할 수 있습니다. NB, 또 다른 인기 있는 도구는 TypeScript로, 이론상 IE8을 즉시 지원하는 ES3로 변환하는 자체 트랜스파일러가 있습니다.

폴리필을 위한 @babel/preset-env 사용 요약:

• 폴리필의 미세 관리를 도구에 위임합니다.
• 자동화된 도구는 필요하지 않은 폴리필이 포함되지 않도록 합니다.
• 더 크고 복잡한 사이트로 확장합니다.
• ️ 필요 여부에 관계없이 모든 사용자는 즉시 폴리필을 받게 됩니다.
• ️ 애플리케이션 번들에 무엇이 포함되어 있는지 정확히 파악하기 어렵습니다.

Webpack 및 동적 가져오기로 폴리필을 지연 로드

새로운 import() 제안을 활용하여 애플리케이션을 초기화하기 전에 기능을 감지하고 폴리필을 동적으로 다운로드할 수 있습니다. 실제로는 다음과 같습니다.

 import app from './app.js'; const polyfills = []; if (!window.fetch) { polyfills.push(import(/* webpackChunkName: "polyfill-fetch" */ 'whatwg-fetch')); } Promise.all(polyfills) .then(app) .catch((error) => { console.error('Failed fetching polyfills', error); });

이 예제 코드는 아주 좋은 기사인 "Lazy Loading Polyfill With Webpack And Dynamic Imports"에서 뻔뻔하게 복사하여 기술에 대해 자세히 설명합니다.

요약:

• 불필요한 폴리필로 최신 브라우저를 부풀리지 않습니다.
• ️ 각 폴리필을 수동으로 관리해야 합니다.

폴리필.io

polyfill.io는 Financial Times에서 구축한 서비스로서의 폴리필입니다. 이것은 polyfill.io에 단일 스크립트 요청을 하는 페이지에서 작동하며 선택적으로 폴리필에 필요한 특정 기능을 나열합니다. 그런 다음 해당 서버는 사용자 에이전트 문자열을 분석하고 그에 따라 스크립트를 채웁니다. 이렇게 하면 자체 폴리필 솔루션을 수동으로 제공할 필요가 없습니다.

다음은 IE8에서 이루어진 요청에 대해 polyfill.io가 반환하는 JavaScript입니다.

다음은 동일한 polyfill.io 요청이지만 최신 Chrome에서 요청이 발생한 곳은 다음과 같습니다.

사이트에서 필요한 것은 단일 스크립트 호출입니다.

요약:

• 웹 앱에 쉽게 포함할 수 있습니다.
• 폴리필 지식의 책임을 제3자에게 위임합니다.
• ️ 반대로, 이제 타사 서비스에 의존하고 있습니다.
• ️ 폴리필이 필요하지 않은 최신 브라우저에서도 차단 <script> 호출을 수행합니다.

점진적 향상

Polyfilling은 이전 브라우저를 지원하는 데 매우 유용한 기술이지만 웹 페이지가 커질 수 있고 범위가 제한될 수 있습니다.

반면에 점진적 향상 기술은 최신 브라우저에서 사용자를 위한 전체 기능을 유지하면서 모든 브라우저에 대한 기본 경험을 보장하는 훌륭한 방법입니다. 대부분의 사이트에서 달성할 수 있어야 합니다.

원칙은 HTML(및 스타일 지정, 선택 사항)의 기준선에서 시작하여 JavaScript 기능으로 페이지를 "점진적으로 향상"하는 것입니다. 이점은 브라우저가 레거시 브라우저이거나 JavaScript가 전달되는 어느 시점에서든 손상된 경우에도 사이트가 계속 작동해야 한다는 것입니다.

"프로그레시브 향상"이라는 용어는 종종 "눈에 거슬리지 않는 JavaScript"와 같은 의미로 사용됩니다. 그것들은 본질적으로 같은 것을 의미하지만 후자는 JavaScript에서만 사용되는 많은 속성, ID 및 클래스로 HTML을 어지럽혀서는 안 된다는 점에서 조금 더 나아갑니다.

컷더머스타드

"겨자 자르기"(CTM)의 BBC 기술은 점진적 향상의 시도되고 테스트된 구현입니다. 원칙은 HTML의 견고한 기본 경험을 작성하고 개선된 JavaScript를 다운로드하기 전에 최소 지원 수준을 확인하는 것입니다. 원래 구현은 표준 HTML5 기능이 있는지 확인했습니다.

 if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) { // Enhance for HTML5 browsers }

새로운 기능이 등장하고 구형 브라우저가 점점 구식이 됨에 따라 겨자 기준선이 변경될 것입니다. 예를 들어, ES6 화살표 함수와 같은 새로운 JavaScript 구문은 이 인라인 CTM 검사가 레거시 브라우저에서도 구문 분석 에 실패함을 의미합니다. CTM 검사를 안전하게 실행하지 못하고 실패하더라도 다른 제3자 JavaScript 중단과 같은 예기치 않은 부작용이 있을 수 있습니다. (예: 구글 애널리틱스).

변환되지 않은 최신 JS를 구문 분석하려는 시도를 피하기 위해 type="module" 의 블로그에서 가져온 CTM 기술에 이 "현대적 방식"을 적용할 수 있습니다. type="module" 선언하고 안전하게 건너뛸 것입니다. 대조적으로, 최신 브라우저는 <script nomodule> 선언을 무시합니다.

 <script type="module" src="./mustard.js"></script> <script nomodule src="./no-mustard.js"></script> <!-- Can be done inline too --> <script type="module"> import mustard from './mustard.js'; </script> <script nomodule type="text/javascript"> console.log('No Mustard!'); </script>

이 접근 방식은 ES6 브라우저를 기능에 대한 새로운 최소 기준으로 만족스럽게 취급하는 경우(작성 당시 글로벌 브라우저의 ~92%) 좋은 방법입니다.

그러나 JavaScript의 세계가 진화하는 것처럼 CSS의 세계도 진화하고 있습니다. 이제 Grid, Flexbox, CSS 변수 등(각각 다양한 대체 효과가 있음)이 있으므로 "현대"와 "레거시"가 뒤섞일 수 있는 이전 브라우저의 CSS 지원 조합에 대해 알 수 없습니다. 스타일링 결과가 깨져 보입니다. 따라서 사이트는 점점 더 CTM 스타일링 을 선택하므로 이제 HTML이 핵심 기준이 되었으며 CSS와 JS가 모두 향상된 기능으로 처리됩니다.

지금까지 살펴본 JavaScript 기반 CTM 기술에는 JavaScript를 사용하여 어떤 식으로든 CSS를 적용하는 경우 몇 가지 단점이 있습니다.

1. 인라인 자바스크립트가 차단됩니다. 브라우저는 스타일을 지정하기 전에 JavaScript를 다운로드, 구문 분석 및 실행해야 합니다. 따라서 사용자는 스타일이 지정되지 않은 텍스트의 플래시를 볼 수 있습니다.
2. 일부 사용자는 최신 브라우저를 사용할 수 있지만 JavaScript를 비활성화하도록 선택합니다. JavaScript 기반 CTM은 스타일이 지정된 사이트를 완벽하게 얻을 수 있는 경우에도 스타일이 지정된 사이트를 가져오는 것을 방지합니다.

'궁극적인' 접근 방식은 CSS 미디어 쿼리를 필수 리트머스 테스트로 사용하는 것입니다. 이 "CSSCTM" 기술은 Springer Nature와 같은 사이트에서 활발히 사용되고 있습니다.

 <head> <!-- CSS-based cuts-the-mustard --> <!-- IMPORTANT: the JS depends on having this rule somewhere in the CSS: `body { clear: both }` --> <link rel="stylesheet" href="mq-test.css" media="only screen and (min-resolution: 0.1dpcm), only screen and (-webkit-min-device-pixel-ratio:0) and (min-color-index:0)"> </head> <body> <!-- content here... --> <script> (function () { // wrap in an IIFE to prevent global scope pollution function isSupported () { var val = ''; if (window.getComputedStyle) { val = window.getComputedStyle(document.body, null).getPropertyValue('clear'); } else if (document.body.currentStyle) { val = document.body.currentStyle.clear; } if (val === 'both') { // references the `body { clear: both; }` in the CSS return true; } return false; } if (isSupported()) { // Load or run JavaScript for supported browsers here. } })(); </script> </body>

이 접근 방식은 매우 취약합니다. 실수로 body 선택기의 clear 속성을 무시하면 사이트가 '손상'되지만 최고의 성능을 제공합니다. 이 특정 구현은 최소한 IE 9, iOS 7 및 Android 4.4에서만 지원되는 미디어 쿼리를 사용하며, 이는 상당히 합리적인 최신 기준입니다.

"Cuts mustard"는 다양한 형태로 두 가지 주요 원칙을 달성합니다.

1. 광범위한 사용자 지원;
2. 개발 노력을 효율적으로 적용했습니다.

사이트가 모든 단일 브라우저/운영 체제/네트워크 연결/사용자 구성 조합을 수용하는 것은 불가능합니다. 야후! 의 Graded Browser Support 모델에 따르면, cut-the-mustard와 같은 기술은 브라우저를 C-등급 및 A-등급 브라우저로 합리화하는 데 도움이 됩니다. .

Cuts-The-Mustard: 안티 패턴?

"코어" 대 "고급"의 글로벌 이진 결정을 적용하는 것이 사용자에게 가능한 최상의 경험이 아니라는 주장이 있습니다. 다른 방법으로는 어려운 기술적 문제에 대해 온전한 상태를 제공하지만 브라우저가 글로벌 CTM 테스트에서 기능의 90%를 지원하고 이 특정 페이지가 실패하는 기능의 10%도 사용하지 않는다면 어떻게 될까요? 이 경우 CTM 검사가 실패했기 때문에 사용자는 핵심 경험을 얻게 됩니다. 그러나 우리는 그들에게 완전한 경험을 줄 수 있었습니다.

그리고 주어진 페이지 가 브라우저가 지원하지 않는 기능을 사용하는 경우는 어떻습니까? 글쎄요, 컴포넌트화를 향한 움직임에서 우리는 페이지 레벨 폴백이 아니라 기능별 폴백(또는 오류 경계)을 가질 수 있습니다.

우리는 웹 개발에서 매일 이 작업을 수행합니다. 웹 글꼴을 가져오는 것을 생각해 보십시오. 브라우저마다 글꼴 지원 수준이 다릅니다. 우리는 무엇을해야합니까? 우리는 몇 가지 글꼴 파일 변형을 제공하고 브라우저가 다운로드할 것을 결정하도록 합니다.

 @font-face { font-family: FontName; src: url('path/filename.eot'); src: url('path/filename.eot?#iefix') format('embedded-opentype'), url('path/filename.woff2') format('woff2'), url('path/filename.woff') format('woff'), url('path/filename.ttf') format('truetype'); }

HTML5 비디오에도 유사한 대체가 있습니다. 최신 브라우저는 사용하려는 비디오 형식을 선택하지만 <video> 요소가 무엇인지 이해하지 못하는 기존 브라우저는 단순히 대체 텍스트를 렌더링합니다.

 <video width="400" controls> <source src="mov_bbb.mp4" type="video/mp4"> <source src="mov_bbb.ogg" type="video/ogg"> Your browser does not support HTML5 video. </video>

SVG에 대한 PNG 폴백에 대해 BBC에서 이전에 사용한 중첩 접근 방식은 <picture> 반응형 이미지 요소의 기초입니다. 최신 브라우저는 제공된 media 속성을 기반으로 가장 적합한 이미지를 렌더링하지만 <picture> 요소가 무엇인지 이해하지 못하는 기존 브라우저는 <img> 대체를 렌더링합니다.

 <picture> <source media="(min-width: 650px)"> <source media="(min-width: 465px)"> <img src="img_orange_flowers.jpg" alt="Flowers"> </picture>

HTML 사양은 모든 브라우저에 대한 기본 폴백 메커니즘을 제공하는 동시에 이를 이해하는 최신 브라우저에 대한 기능과 최적화를 허용하기 위해 수년에 걸쳐 신중하게 발전했습니다.

JavaScript 코드에 유사한 원칙을 적용할 수 있습니다. foo 메소드에 복잡한 JS가 포함된 다음과 같은 기능을 상상해 보십시오.

 class Feature { browserSupported() { return ('querySelector' in document); // internal cuts-the-mustard goes here } foo() { // etc } } export default new Feature();

foo 를 호출하기 전에 이 브라우저의 browserSupported 메서드를 호출하여 기능이 이 브라우저에서 지원되는지 확인합니다. 지원되지 않는 경우 페이지에 오류가 발생한 코드를 호출하려고 시도조차 하지 않습니다.

 import Feature from './feature'; if (Feature.browserSupported()) { Feature.foo(); }

이 기술을 사용하면 폴리필을 가져오는 것을 방지하고 각 개별 브라우저에서 기본적으로 지원하는 것을 사용할 수 있으며 지원되지 않는 경우 개별 기능을 정상적으로 저하시킬 수 있습니다.

위의 예에서 모든 브라우저에서 구문 을 이해할 수 있도록 코드가 ES5로 변환된다고 가정하고 있지만 코드가 폴리필( polyfill )이라고 가정하지는 않습니다. 코드를 변환하지 않으려면 동일한 원칙을 적용할 수 있지만 type="module" 을 사용하면 기본적으로 필요하지만 이미 최소 ES6 브라우저 요구 사항이 있으므로 주의해야 합니다. 몇 년 안에 좋은 솔루션이 될 가능성:

 <script type="module"> import Feature from './feature.js'; if (Feature.browserSupported()) { Feature.foo(); } </script>

우리는 HTML을 다루었고 JavaScript를 다루었습니다. CSS에서도 현지화된 대체를 적용할 수 있습니다. CSS에는 @supports 키워드가 있어 CSS 기능에 대한 지원 여부에 따라 CSS를 조건부로 적용할 수 있습니다. 그러나 보편적으로 지원되지 않는다는 점에서 아이러니하게도 주의해야 합니다. 세심한 적용이 필요할 뿐입니다. CSS에서 기능 쿼리를 사용하는 방법에 대한 훌륭한 Mozilla 블로그 게시물이 있습니다.

이상적인 세상에서 우리는 글로벌한 겨자 수표가 필요하지 않습니다. 대신, 각각의 개별 HTML, JS 또는 CSS 기능은 자체 포함되어야 하고 고유한 오류 경계가 있어야 합니다. 웹 구성 요소, 섀도우 DOM 및 사용자 정의 요소의 세계에서 이러한 접근 방식으로의 전환이 더 많이 나타날 것으로 예상합니다. 그러나 사이트를 전체적으로 예측하고 테스트하기가 훨씬 더 어려워지며, 예를 들어 한 구성 요소의 스타일이 다른 구성 요소의 레이아웃에 영향을 미치는 경우 의도하지 않은 부작용이 발생할 수 있습니다.

두 가지 주요 이전 버전과의 호환성 전략

전략으로서의 폴리필 요약:

• 대부분의 사용자에게 클라이언트 측 JS 기능을 제공할 수 있습니다.
• 이전 버전과의 호환성 문제를 폴리필에 위임할 때 코딩이 더 쉬울 수 있습니다.
• ️ 구현에 따라 폴리필이 필요하지 않은 사용자에게는 성능이 저하될 수 있습니다.
• ️ 응용 프로그램의 복잡성과 브라우저의 사용 기간에 따라 많은 폴리필이 필요할 수 있으므로 매우 제대로 실행되지 않습니다. 우리는 그것을 받아들일 준비가 가장 덜 된 브라우저에 메가바이트의 폴리필을 배송할 위험이 있습니다.

전략으로서의 점진적 향상 요약:

• 기존 CTM을 사용하면 코드를 쉽게 분할하고 수동으로 테스트할 수 있습니다.
• 모든 사용자에 대한 경험의 기준선을 보장합니다.
• ️ 고급 경험을 처리할 수 있는 사용자에게 핵심 경험을 불필요하게 전달할 수 있습니다.
• ️ 기능을 위해 클라이언트 측 JS가 필요한 사이트에는 적합하지 않습니다.
• ️ 강력한 프로그레시브 향상 전략과 성능이 뛰어난 첫 번째 렌더링의 균형을 맞추기 어려운 경우가 있습니다. '전체' 경험을 얻는 사용자의 90%가 손해를 입기 위해 '핵심' 경험을 과도하게 우선시할 위험이 있습니다(예: noJS에 작은 이미지를 제공한 다음 지연 로드에서 고해상도 이미지로 교체한다는 것은 한 번도 보지 않은 자산에 많은 다운로드 용량을 낭비했습니다.

결론

IE8은 한때 최첨단 브라우저였습니다. (아니요, 심각합니다.) 오늘날의 Chrome과 Firefox에서도 마찬가지입니다.

오늘날의 웹사이트가 IE8에서 완전히 사용할 수 없다면 10년 후의 웹사이트는 HTML, CSS 및 JavaScript의 개방형 기술을 기반으로 구축되었음에도 불구하고 오늘날의 최신 브라우저에서 거의 사용할 수 없게 될 것입니다.

잠시 멈추고 그것에 대해 생각해 보십시오. 좀 무섭지 않아? (즉, 10년이 지난 후에도 브라우저를 버릴 수 없고 브라우저를 만든 회사에서 더 이상 사용하지 않는다면 언제 할 수 있습니까?)

IE8은 오늘날의 희생양입니다. 내일은 IE9, 내년에는 Safari, 1년 후에는 Chrome이 될 것입니다. IE8을 '기존 브라우저 선택'으로 바꿀 수 있습니다. 요점은 개발자가 구축하는 브라우저와 사람들이 사용하는 브라우저 사이에는 항상 약간의 차이가 있다는 것입니다. 우리는 조롱을 멈추고 강력하고 포괄적인 엔지니어링 솔루션에 투자하기 시작 해야 합니다. 이러한 전략의 부작용은 접근성, 성능 및 네트워크 탄력성 측면에서 배당금을 지불하는 경향이 있으므로 여기에 더 큰 그림이 있습니다.

우리는 스크린 리더 번호에 대해 생각하지 않는 경향이 있습니다. 우리는 우리 자신의 잘못이 아닌 다른 방법으로 우리 콘텐츠를 소비하지 않는 사용자를 지원하기 위해 최선을 다하는 것이 도덕적으로 옳다는 것을 당연하게 여깁니다. 이전 브라우저를 사용하는 사람들에게도 동일한 원칙이 적용됩니다.

우리는 광범위한 레거시 및 최신 브라우저에서 어느 정도 계속 작동해야 하는 강력한 사이트를 구축하기 위한 몇 가지 상위 수준 전략을 다루었습니다.

다시 한 번 면책 조항: IE를 위해 해킹 하지 마십시오 . 그것은 요점을 놓치고 있을 것입니다. 그러나 모든 종류의 사람들이 모든 종류의 이유로 모든 종류의 브라우저를 사용하며 모든 사람이 웹에 액세스할 수 있도록 하기 위해 우리가 취할 수 있는 몇 가지 견고한 엔지니어링 접근 방식이 있음을 명심하십시오.

다수를 위해 최적화하고 소수를 위해 노력하며 보안을 희생하지 마십시오.

SmashingMag에 대한 추가 정보:

• 웹 표준: 무엇을, 왜, 그리고 어떻게
• 스마트 번들링: 레거시 브라우저에만 레거시 코드를 제공하는 방법
• 자리 표시자 속성을 사용하지 마십시오
• 브라우저 없는 웹을 위한 디자인