이전 브라우저 지원
오늘날에는 이전 브라우저 지원에 대해 크게 걱정할 필요가 없습니다. Internet Explorer 8이 종료된 이후로는 괜찮았습니다.
그러나 문제는 여전히 남아 있습니다. Internet Explorer 9 및 기타 브라우저를 어떻게 지원해야 합니까? 우선, Internet Explorer 9 지원을 고려하고 계십니까?
고려해야 할 몇 가지 사항을 살펴보겠습니다.
브라우저가 아닌 기능을 생각하세요
세상에 두 가지 기능과 두 가지 브라우저만 있다고 가정해 보겠습니다.
- 브라우저 A는 기능 A를 지원하지만 기능 B는 지원하지 않습니다.
- 브라우저 B는 기능 B를 지원하지만 기능 A는 지원하지 않습니다.
어떤 브라우저가 어떤 기능을 지원하는지 감지하고 거기에서 작동하는 것이 가능합니다.
// This is JavaScript
if (Browser A) { // Code for A}
if (Browser B) { // code for B}
하지만 브라우저가 더 많으면 어떻게 될까요? 세상에 브라우저 C, D, E가 포함되어 있다면 어떨까요? 브라우저에 대해 생각하고 있다면 필요한 기능을 지원하기가 어려워집니다.
더 좋은 방법이 있습니다. 기능이 존재하는지 확인할 수 있습니다. 존재하는 경우 사용하십시오. 그렇지 않은 경우 대체 코드를 제공하세요.
다음 코드 블록은 브라우저 A에서 브라우저 Z까지 작동합니다.
// This is JavaScript
if (feature A) { // Code if browser contains feature A} else { // Code if browser doesn't contain feature A}
이제 브라우저에 대해 걱정할 필요가 없습니다.
기능 사용 여부 결정
많은 사람들은 해당 기능을 지원하는 브라우저 수에 따라 기능 사용 여부를 결정합니다. 하지만 위에서 주장했듯이 브라우저는 중요하지 않습니다.
중요한 것은 기능에 대한 대체 코드를 쉽게 코딩할 수 있는가입니다. 폴백을 쉽게 코딩할 수 있다면 해당 기능을 사용해 보세요. fallback을 쉽게 코딩할 수 없다면 이 기능을 사용하지 마세요.
지원할 브라우저 결정
아직 컷오프가 필요합니다.
어떤 브라우저를 지원할 예정인가요?
어떤 브라우저를 지원하지 않을 예정인가요? 브라우저를 지원하고 싶지 않다면 이에 대한 대체 코드를 작성하는 것은 의미가 없습니다.
최선의 대답은 다음과 같습니다. 누가 귀하의 사이트를 사용하고 있는지 살펴보십시오. 그들은 어떤 브라우저를 사용합니까? 그에 따라 따르십시오.
예, Internet Explorer 6에서 귀하의 웹사이트를 방문하려는 이상한 사람들이 있을 수 있습니다. 하지만 거의 아무도 사용하지 않는 브라우저에 대한 추가 코드를 작성할 시간과 에너지가 있습니까?
에너지를 다른 곳에 더 잘 쓸 수 있을까요?
지원 수준
저는 다음과 같은 4가지 수준의 지원이 있다고 생각합니다:
- 모든 것이 모든 브라우저에서 동일하게 보이고 작동해야 합니다
- 사이트는 동일하게 보여야 하지만 기능은 브라우저마다 다를 수 있습니다.
- 기능은 동일해야 하지만 브라우저마다 모양이 다를 수 있습니다.
- 모양과 기능은 브라우저마다 다를 수 있습니다
이전 브라우저에 어떤 종류의 지원을 제공하고 있나요? 왜요?
마무리
생각해 보세요:
- 지원하려는 이전 브라우저를 지원하려는 이유는 무엇입니까?
- 어떤 수준의 지원을 제공하고 있나요?
- 할당한 리소스만큼 가치가 있나요?
이전 브라우저 지원 — CSS
CSS 기능에 대한 대체 기능을 제공하는 방법에는 두 가지가 있습니다.
- 속성 대체
- 기능 쿼리
속성 대체
브라우저가 속성이나 해당 값을 인식하지 못하는 경우 브라우저는 해당 속성을 모두 무시합니다.
이런 일이 발생하면 브라우저는 찾은 이전 값을 사용하거나 대체합니다.
이는 대체를 제공하는 가장 쉬운 방법입니다.
예를 들면 다음과 같습니다:
.layout { display: block; display: grid; }
이 예에서 CSS Grid를 지원하는 브라우저는 display: grid를 사용합니다. . CSS 그리드를 지원하지 않는 브라우저는 display: block으로 대체됩니다. .
기본값 생략
사용 중인 요소의 기본값이 display: block인 경우 , display: block을 생략할 수 있습니다. 선언. 즉, 한 줄의 코드로 CSS Grid를 지원할 수 있습니다:
.layout { display: grid; }
CSS 그리드를 지원하는 브라우저는 grid-template-columns와 같은 다른 CSS 속성을 읽을 수 있습니다. . CSS 그리드를 지원하지 않는 브라우저는 지원하지 않습니다.
즉, 대체 값에 대해 걱정하지 않고 추가 CSS 그리드 속성을 작성할 수 있습니다.
.layout { display: grid; grid-template-columns: 1fr 1fr 1fr 1fr; grid-gap: 1em; }
기능 쿼리 또는 @supports , CSS 속성 또는 해당 값이 지원되는지 여부를 브라우저에서 지원하는지 알려줍니다.
if/else과 같은 CSS 기능 쿼리를 생각해 볼 수 있습니다. JavaScript의 명령문. 다음과 같습니다:
@supports (property: value) { /* Code when property or value is supported*/}
@supports not (property: value) { /* Code when property or value is not supported */}
@supports 브라우저가 CSS 만 읽도록 하려는 경우 유용합니다. 특정 속성을 지원하는 경우.
위에서 본 CSS 그리드 예의 경우 다음과 같이 할 수 있습니다:
@supports (display: grid) { .layout { display: grid; grid-template-columns: 1fr 1fr 1fr 1fr; grid-gap: 1em; padding-left: 1em; padding-right: 1em; }}
이 예에서는 padding-left 및 padding-right @supports를 모두 지원하는 브라우저에서만 읽을 수 있습니다. 그리고 CSS 그리드.
Jen Simmons는 @supports의 더 나은 예를 가지고 있습니다. 직장에서. 그녀는 기능 쿼리를 사용하여 브라우저가 -webkit-initial-letter와 같은 속성을 지원하는지 여부를 감지합니다. .
@supports (initial-letter: 4) or (-webkit-initial-letter: 4) { p::first-letter { -webkit-initial-letter: 4; initial-letter: 4; color: #FE742F; font-weight: bold; margin-right: 0.5em; }}
Jen의 예는 우리에게 다음과 같은 질문을 던집니다. 사이트가 여러 브라우저에서 동일하게 보여야 합니까? 이에 대해서는 나중에 살펴보겠습니다. 하지만 먼저 기능 쿼리에 대해 자세히 알아보세요.
기능 쿼리 지원
기능 쿼리는 큰 지원을 받았습니다. 현재의 모든 주요 브라우저는 기능 쿼리를 지원합니다.
기능이 지원되지만 기능 쿼리가 지원되지 않으면 어떻게 되나요?
이것은 까다로운 부분이었습니다. Jen Simmons와 다른 전문가들은 이러한 가능성에 대해 경고했습니다. 이 글에서 이를 처리하는 방법을 읽어보실 수 있습니다.
내 의견은 다음과 같습니다. 저는 더 이상 IE 11을 지원하지 않으므로 위에서 언급한 방식으로 기능 쿼리를 사용합니다.
속성 대체와 기능 쿼리를 동시에 사용
다음 코드를 살펴보세요. 브라우저는 어떤 패딩 값을 적용하나요?
@supports (display: grid) { .layout { display: grid; grid-template-columns: 1fr 1fr 1fr 1fr; grid-gap: 1em; padding-left: 1em; padding-right: 1em; }}
.layout { padding-left: 2em; padding-right: 2em; }
대답은 다음과 같습니다. 모든 브라우저는 2em를 적용합니다. 왼쪽 및 오른쪽 패딩.
왜요?
이는 padding-left: 2em 때문에 발생합니다. 및 padding-right: 2em 나중에 CSS 파일에서 선언되었습니다. 나중에 선언된 속성은 이전에 선언된 속성을 재정의합니다.
padding-left: 2em을 원할 경우 및 padding-right: 2em 신청만 하지 않는 브라우저에 CSS 그리드를 지원하면 속성 순서를 바꿀 수 있습니다.
.layout { padding-left: 2em; padding-right: 2em; }
@supports (display: grid) { .layout { display: grid; grid-template-columns: 1fr 1fr 1fr 1fr; grid-gap: 1em; padding-left: 1em; padding-right: 1em; }}
참고 :계단식 특성으로 인해 CSS에서 대체 코드를 먼저 선언하는 것이 항상 좋은 습관입니다.
이는 @supports을 모두 사용하는 경우에도 마찬가지입니다. 그리고 @supports not , @supports not을 선언해야 합니다. 먼저. 이는 코드의 일관성을 높여줍니다.
/* Always write "@supports not" first if you use it */@supports not (display: grid) { .layout { padding-left: 2em; padding-right: 2em; }}
@supports (display: grid) { .layout { display: grid; grid-template-columns: 1fr 1fr 1fr 1fr; grid-gap: 1em; padding-left: 1em; padding-right: 1em; }}
이제 사이트가 여러 브라우저에서 동일하게 표시되어야 하는지에 대해 이야기해 보겠습니다.
사이트는 여러 브라우저에서 동일하게 표시되어야 합니까?
어떤 사람들은 사이트가 여러 브라우저에서 동일하게 보여야 한다고 믿습니다. 그들은 브랜딩이 중요하다고 생각하며, 브랜드를 보존하려면 사이트가 일관되게 보여야 한다고 강조합니다.
다른 사람들은 그렇지 않다고 말합니다. 그들은 점진적인 향상의 정신을 받아들여야 한다고 믿습니다. 더 나은 브라우저를 사용하는 사용자에게 더 많은 사랑을 줄 수 있습니다.
두 가지 견해 모두 옳지만 각도가 다릅니다.
가장 중요한 관점은 사용자로부터 나옵니다. 귀하의 사이트는 사용자에게 목적을 제공할 수 있습니까?
그렇다면 일관성에 대해 너무 엄격할 필요는 없습니다. 더 나은 브라우저로 사용자에게 더 나은 경험을 제공하세요!
마무리
CSS 기능에 대한 지원을 제공하려면 다음을 사용할 수 있습니다.
- 속성 대체
- 기능 쿼리
CSS를 작성할 때 더 나은 지원을 제공하는 브라우저를 위한 다른 코드 세트보다 먼저 대체 코드를 선언해야 합니다.
이전 브라우저 지원 — JavaScript
이전 브라우저에 JavaScript 지원을 제공하는 것은 쉽습니다. 대부분의 경우 폴리필만 사용해야 합니다.
하지만 할 수 있는 일이 더 많습니다.
폴리필이란 무엇인가요?
폴리필은 브라우저에 JavaScript 기능을 구현하는 방법을 알려주는 코드 조각입니다. 폴리필을 추가하면 더 이상 지원에 대해 걱정할 필요가 없습니다. 효과가 있을 겁니다.
Polyfill의 작동 방식은 다음과 같습니다.
- 해당 기능이 지원되는지 확인
- 그렇지 않은 경우 해당 기능을 지원하는 코드를 추가합니다
다음은 작업 중인 폴리필의 예입니다. 브라우저가 Array.prototype.find를 지원하는지 확인합니다. . 브라우저가 Array.prototype.find를 지원하지 않는 경우 , 브라우저에 지원 방법을 알려줍니다.
이 코드는 MDN에서 찾을 수 있습니다.
if (!Array.prototype.find) { Object.defineProperty(Array.prototype, 'find', { value: function(predicate) { // 1. Let O be ? ToObject(this value). if (this == null) { throw new TypeError('"this" is null or not defined'); }
var o = Object(this);
// 2. Let len be ? ToLength(? Get(O, "length")). var len = o.length >>> 0;
// 3. If IsCallable(predicate) is false, throw a TypeError exception. if (typeof predicate !== 'function') { throw new TypeError('predicate must be a function'); }
// 4. If thisArg was supplied, let T be thisArg; else let T be undefined. var thisArg = arguments[1];
// 5. Let k be 0. var k = 0;
// 6. Repeat, while k < len while (k < len) { // a. Let Pk be ! ToString(k). // b. Let kValue be ? Get(O, Pk). // c. Let testResult be ToBoolean(? Call(predicate, T, « kValue, k, O »)). // d. If testResult is true, return kValue. var kValue = o[k]; if (predicate.call(thisArg, kValue, k, o)) { return kValue; } // e. Increase k by 1. k++; }
// 7. Return undefined. return undefined; }, configurable: true, writable: true });}
참고 :폴리필은 심의 하위 집합입니다. shim은 이전 환경에 새로운 API를 제공하는 라이브러리입니다.
폴리필 사용
폴리필을 사용하는 방법에는 두 가지가 있습니다:
- 위의 예처럼 수동으로 폴리필
- 라이브러리를 통해 한 번에 많은 폴리필 추가
수동으로 폴리필
먼저 폴리필을 검색해야 합니다. 당신이 필요합니다. 구글링을 하면 찾을 수 있을 것입니다. 똑똑한 개발자들이 필요한 거의 모든 것에 대한 폴리필을 만들었습니다.
폴리필을 찾았으면 위 프로세스를 사용하세요. 이전 브라우저에 대한 지원을 제공하기 위해.
한 번에 많은 폴리필 추가
일부 라이브러리에는 많은 폴리필이 포함되어 있습니다. ES6-shim은 그러한 라이브러리의 한 예입니다. 이전 브라우저의 모든 ES6 기능을 지원합니다.
최첨단 JavaScript 기능 사용
최첨단 JavaScript 기능을 사용하려면 빌드 프로세스에 Babel을 추가하는 것을 고려해 보세요.
Babel은 JavaScript를 컴파일하는 도구입니다. 이 컴파일 과정에서 다음을 수행할 수 있습니다:
- 필요한 심/폴리필을 추가하세요
- 전처리기를 JavaScript로 컴파일
두 번째 사항에 대한 추가 정보:
Babel은 빌드 프로세스에서 오프라인으로 작동합니다. 이는 사용자가 전달한 파일을 읽은 다음 이러한 파일을 브라우저가 읽을 수 있는 JavaScript로 변환할 수 있습니다.
이것이 의미하는 바는 Flow, TypeScript 및 기타 멋진 기술과 같은 최첨단 기능을 사용할 수 있다는 것입니다. 먼저 Babel을 통과하면 브라우저에서 모두 작동합니다!
폴리필만으로는 충분하지 않으면 어떻게 되나요?
폴리필이 기능을 지원하기에 충분하지 않은 경우 문제의 브라우저에 제공하는 지원 수준을 재고해 볼 수 있습니다.
다양한 브라우저에서 동일한 기능을 제공해야 합니까? 대신 점진적인 향상을 고려해야 할 수도 있습니다.
어쩌면 이 기능을 사용하지 않는 방식으로 코딩할 수도 있을까요?
아마도 그럴 수도 있겠지만, 당신은 표류를 할 것입니다.
브라우저가 이 기능을 지원하는지 어떻게 알 수 있나요?
먼저 caniuse.com을 확인합니다. 원하는 JavaScript 기능의 이름을 작성하면 브라우저 지원 수준을 확인할 수 있습니다.
다음은 Abort Controller를 사용한 예입니다
caniuse.com에서 정보를 제공하지 않으면 MDN을 확인합니다. 대부분의 기사 하단에서 브라우저 지원을 확인할 수 있습니다.
Abort Controller를 사용한 예는 다음과 같습니다.
JavaScript 비용에 주의하세요
폴리필을 사용하면 더 많은 JavaScript 코드를 추가하게 됩니다.
JavaScript를 더 추가할 때의 문제는 JavaScript가 더 많다는 것입니다. 그리고 JavaScript가 많아지면 더 많은 문제가 발생합니다:
- 오래된 브라우저는 일반적으로 오래된 컴퓨터에 있습니다. 처리 능력이 충분하지 않을 수 있습니다.
- 자바스크립트 번들은 사이트 로드를 지연시킬 수 있습니다. 이에 대한 자세한 내용은 Addy Osmani의 "JavaScript 비용"을 참조하세요.
마무리
JavaScript 기능에 대한 지원을 추가하는 것은 쉽습니다. 대부분의 경우 폴리필을 추가하고 하루에 끝냅니다. 하지만 그렇게 할 때는 JavaScript 비용에 유의하세요!
때로는 이 기능을 완전히 버리는 것이 좋을 수도 있습니다.
이전 브라우저를 지원하는 이유는 무엇인가요?
왜 오래된 브라우저에 관심을 가져야 합니까?
오래된 브라우저를 사용하는 사람은 누구입니까? 아마도 오래된 컴퓨터를 사용하는 사용자일까요?
오래된 컴퓨터를 사용한다면 새 컴퓨터를 살 돈이 없을 수도 있습니다.
새 컴퓨터를 살 돈이 없다면 그들은 아마도 당신에게서 아무것도 사지 않을 것입니다.
그들이 당신에게서 아무것도 사지 않는다면 왜 당신은 그들의 브라우저 지원에 신경을 써야 합니까?
사업가에게 그것은 완벽하게 합리적인 생각의 흐름입니다. 그런데 왜 우리 개발자들은 여전히 구형 브라우저 지원을 고집하는 걸까요?
분석해 보겠습니다
원래의 사고 과정에는 너무나 많은 가정이 존재합니다.
"누가 오래된 브라우저를 사용합니까? 아마도 오래된 컴퓨터를 사용하는 사용자일까요? 오래된 컴퓨터를 사용한다면 새 컴퓨터를 살 돈이 없을 수도 있습니다.".
사람들이 오래된 컴퓨터를 사용하기 때문에 오래된 브라우저를 사용하는 것은 사실이지만 사람들이 새 컴퓨터를 구입할 여유가 없다고 가정할 수는 없습니다.
- 아마도 회사에서 구매를 원하지 않을 수도 있습니다.
- 컴퓨터에 만족하고 업그레이드를 원하지 않을 수도 있습니다.
- 컴퓨터를 업그레이드할 지식이 없을 수도 있습니다.
- 새 컴퓨터에 액세스할 수 없을 수도 있습니다.
- 아마도 브라우저가 좋지 않은 휴대전화에 묶여 있을 수도 있습니다.
가정하지 마세요.
새 컴퓨터를 살 돈이 없다면 그들은 아마도 당신에게서 아무것도 사지 않을 것입니다. 그들이 당신에게서 아무것도 사지 않는다면 왜 당신은 그들의 브라우저 지원에 신경을 써야 합니까?
이 점에 대해 이야기하려면 다른 영역으로 확대해야 합니다.
휠체어 접근성
싱가포르에 가본 적이 있다면 거의 모든 계단 옆에 경사로나 엘리베이터가 있다는 것을 알 수 있을 것입니다.
그런데 왜? 정부와 민간기업은 왜 엘리베이터와 경사로에 돈을 쓰는가? 사람들을 낮은 곳에서 높은 곳으로 데려갈 수 있는 계단이 충분할 때 계단을 건설할 이유가 무엇입니까?
계단을 이용하지 못하는 분들도 계시더라구요. 그들은 발로 걸을 수 없습니다. 그들은 휠체어에 앉아야 하고, 계단을 스스로 올라갈 수도 없습니다. 엘리베이터와 경사로는 이러한 사람들을 위한 것입니다.
그리고 더 많은 사람들이 엘리베이터와 경사로의 혜택을 받는 것으로 나타났습니다.
- 무릎이 약한 분들
- 자전거나 스쿠터를 가지고 있는 사람들
- 유아용 카트를 밀고 있는 부모
바퀴가 달린 물건을 밀고 있는 자신을 발견하면 두 번 생각하지 않고 경사로나 엘리베이터를 이용할 것입니다. 당신에게도 이익이 됩니다.
하지만 문제는 경사로나 엘리베이터를 운영하여 단 한 푼도 벌 수 없다는 것입니다. 그렇다면 왜 구축해야 할까요?
그럴만한 가치가 있으니까요.
그리고 가치가 항상 돈을 의미하는 것은 아닙니다.
지구 온난화를 고려
당신은 지구에 살고 있습니다. 지구 온난화에 대해 어떻게 생각하시나요?
어떤 사람들은 상관하지 않습니다. 숲이 불타도 괜찮습니다. 기업이 강을 오염시키고 엄청난 양의 이산화탄소를 대기 중으로 방출해도 괜찮습니다. 영향을 미치지 않습니다.
하지만 관심을 갖는 사람들이 있습니다. 그들은 우리가 살고 있는 지구를 사랑합니다. 그들은 자녀들에게 더 살기 좋은 곳을 제공하고 싶어합니다. 그들이 관심을 갖는 데에는 많은 이유가 있습니다. 그리고 그들은 아마도 가능한 한 많은 자원을 절약하고 싶어할 것입니다.
당신은 어디에 서 있나요?
운영하면서 지구를 파괴하는 회사에 돈을 주시겠습니까?
아마도 그럴 것입니다. 아마도 당신은 그렇지 않을 것입니다. 어쩌면 당신은 상관하지 않을 수도 있습니다. 세 가지 옵션 모두 유효합니다.
그리고 다시 한 번 말씀드리지만, 항상 돈이 중요한 것은 아닙니다.
웹은 모두를 위한 것입니다
웹의 꿈은 정보를 공유하여 소통하는 공동의 정보 공간입니다.
— 팀 버너스-리
우리 프론트엔드 개발자는 웹의 관리자입니다. 웹이 어떻게 될지는 우리에게 달려 있습니다. 모든 사람에게 경사로와 엘리베이터를 만들도록 강요할 수는 없지만 스스로 만들 수는 있습니다.
선택은 전적으로 귀하에게 달려 있습니다.
원하지 않으시면 신경쓰지 않으셔도 됩니다.
내가 아는 가장 좋은 프론트엔드 개발자는? 그들은 걱정합니다. 그들은 포괄적이기를 선택합니다. 이것이 우리를 프론트엔드 개발자로 만드는 이유입니다.
우리는 걱정합니다.
그러나 때로는 제약과 한계도 있습니다. 그리고 우리는 이러한 한계를 극복하기 위해 노력하고 있습니다.
이 글은 원래 제 블로그에 게시된 글입니다.
더 나은 프런트엔드 개발자가 되는 데 도움이 되는 더 많은 기사를 원하시면 제 뉴스레터에 가입하세요.
무료로 코딩을 배우세요. freeCodeCamp의 오픈 소스 커리큘럼은 40,000명 이상의 사람들이 개발자로 취업하는 데 도움을 주었습니다. 시작하세요