큰 CSS 미디어 쿼리 실수

게시 됨: 2017-05-15

당신 주위의 모든 사람들이 당신이 일반적으로 옳지 않다고 생각하는[또는 최소한 아주 이상적이지는 않은] 행동을 하고 있는데도, 이런저런 이유로 아무 말도 하고 싶어하지 않는 것 같을 때 이상하게 느낀 적이 있습니까? 모두가 불행한 관찰자에게 최선의 인상을 주는 것을 보는 것은 매우 이상한 느낌입니다. 옛날 우화 "황제의 새옷"이 생각납니다.

저는 CSS 미디어 쿼리에 대해 항상 그렇게 느꼈습니다. 왜 모든 사람들은 일을 끝내지 못하는 것처럼 보이는 기술을 그렇게 받아들이고 있습니까? 왜 우리는 커뮤니티로서 함께 모여 실제적이고 의미 있는 방식으로 개선하지 않았습니까? 왜 우리는 더 나은 것을 생각해내지 못했습니까?

오늘날 CSS 미디어 쿼리는 반응형 웹 디자인의 기능적 초석이 되었습니다. 그러나 오늘날 모든 사람이 사용하는 용도로 설계된 것은 아니며 그 증거가 실제로 사용되고 있습니다. 나는 여전히 처음에는 잘 디자인된 것처럼 보이지만 속도를 따라가다 보면 완전히 어색해 보이는 태블릿 장치를 사용할 때 웹 사이트를 자주 발견합니다.

반응형 웹 디자인에 대한 이러한 접근 방식에는 근본적으로 잘못된 것이 있습니다. 우리는 아직 제대로 다루지 않았습니다. 저는 황제가 이 문제에 대해 벌거벗은 것을 외치는 몇 안 되는 목소리 중 하나가 되었으면 합니다. 고맙게도 이 시대에 이러한 대안적 관점을 가졌다는 이유로 화형을 당할 가능성이 거의 없다는 것이 기쁩니다.

CSS 미디어 쿼리의 문제점

CSS 미디어 쿼리는 무언가를 위해 설계되었지만 그것은 반응형 웹 디자인이 아닙니다. 내 경험에 비추어 볼 때 웹 사이트 작업에 사용할 때 직면한 7가지 큰 문제는 다음과 같습니다.

1. 직관적이지 않음:

"CSS 미디어 쿼리는 직관적입니다."라고 웹 디자이너가 말한 적이 없습니다. 미디어 쿼리를 정의하는 방법은 매우 간단하지만 실제 브라우저, 실제 장치 및 수많은 시나리오에서 상황이 어떻게 실행되는지 항상 명확하지 않습니다.

 @미디어 전용 화면 및 (최소 너비: 320px) 및 (최대 너비: 480px) {
    /** CSS 규칙은 여기로 이동 **/
}

위의 코드는 뷰포트가 320~480픽셀일 때 적용됩니다. 그러나 장치가 가로 모드에서 태블릿인 경우 스타일 규칙을 적용하는 것과 같이 보다 구체적인 작업을 수행하려는 경우에는 정확하지 않습니다. 이를 위해 미디어 쿼리를 설정하는 것이 [일종의] 불가능한 것은 아니지만 확실히 직관적이지 않거나 결정적이지 않습니다.

2. 제한적 조건:

CSS 미디어 쿼리는 동적이며 CSS에서 조건문 을 정의할 수 있습니다. 예를 들어, 뷰포트가 이것과 저것 사이에 있으면 다른 것도 수행하십시오. 그러나 대부분은 뷰포트 고려 사항으로 제한되며 현대 웹 디자인에서 의미가 있는 조건부 시나리오가 더 많이 있습니다.

탭바 모바일 디자인 가이드라인

프로그레시브 웹 앱을 구축 중이라고 가정해 보겠습니다. OS에 따라 특정 UI 요소의 스타일을 다르게 지정하는 것이 유용할 때가 있습니다. 예를 들어 iOS 장치의 경우 하단에 탭 막대가 있는 것이 일반적이지만 Android의 경우 그 반대입니다. 그렇다면 이것이 CSS 미디어 쿼리와 함께 작동하도록 하려면 정확히 어떻게 해야 할까요?

CSS 미디어 쿼리는 그렇게 할 수 있는 기능으로 구축되지 않았기 때문에 할 수 없습니다. 이 외에도 CSS를 통해 수행해야 할 수 있는 다른 사용자 정의가 많이 있지만 단순에서 고급 조건까지 다양한 수준이 필요한 경우 미디어 쿼리는 옵션이 아닙니다.

3. 기본적으로 확장할 수 없음:

CSS 미디어 쿼리는 브라우저에 베이크된 기능입니다. 즉, 기본적으로 확장할 수 없습니다. 즉, CSS 인터페이스를 통해 기본적으로 CSS 미디어 쿼리에 추가 및 향상된 기능을 추가할 수 없습니다.

새로운 CSS 미디어 쿼리 기능이 [오랫동안] 웹 표준 프로세스에 의해 승인되더라도 이러한 기능이 편재되어 사용 가능하게 되기까지는 여전히 시간이 걸립니다. 또한 추가된 모든 기능이 사용자에게 유용한 것은 아니므로 원하는 기능을 얻지 못한 경우 특정 문제를 해결할 수 있는 다른 방법을 찾아야 합니다.

물론 CSS를 확장하는 방법도 있지만 자바스크립트를 정말, 정말 잘 알아야 하고, 대부분의 웹디자이너에게 실용적인 과정이 아니다.

4. 개조에 적합하지 않음:

어떤 사람들은 이것을 믿기 어려울 수 있지만 모바일 장치가 등장하기 전에 실제로 많은 웹 사이트가 있었고 그 중 모바일 친화적 인 웹 사이트는 없었습니다. 결과적으로 이러한 데스크탑 시대의 웹사이트는 업그레이드가 필요했습니다.

불행히도 CSS 미디어 쿼리는 이 작업에 그다지 좋은 옵션이 아닙니다. 이러한 웹 사이트는 모바일 장치가 관련되기 전에 구축되었기 때문에 사이드바, 테이블 기반 레이아웃, 탭 콘텐츠 등과 같이 반응형 웹 디자인에 적합하지 않은 디자인 요소가 많이 있습니다. 또한 이러한 웹 사이트의 상당 부분은 WordPress, Drupal, Magento 등과 같은 콘텐츠 관리 시스템(CMS)을 기반으로 하고 백엔드에서 CSS 미디어 쿼리 [프론트 엔드]를 효과적으로 통합하는 것은 조정하기가 극히 어렵거나 거의 불가능합니다.

저는 Magento Enterprise, WordPress 및 Coldfusion 기반 사용자 정의 CMS를 사용하는 웹사이트를 개조해야 했으며 CSS 미디어 쿼리를 사용하면 모든 프로젝트가 완전히 불가능했을 것입니다. 접근하다].

5. 코드 효율적이지 않음:

CSS 미디어 쿼리를 사용하여 웹 페이지를 반응형으로 만들려면 상당한 규모의 코드 곱셈이 필요합니다. 이러한 지시문이 [중단점과 함께] 작동하는 방식 때문에 모든 미디어 쿼리 블록에서 개별 스타일 규칙을 정의해야 합니다.

 섹션 {너비: 960px;}

/* 초상화 */
@미디어 전용 화면 및 (최소 장치 너비: 320px) 및 (최대 장치 너비: 480px) 및 (-webkit-min-device-pixel-ratio: 2) 및 (방향: 세로) {
    섹션 {너비: 100%}
}
/* 풍경 */
@미디어 전용 화면 및 (최소 장치 너비: 320px) 및 (최대 장치 너비: 480px) 및 (-webkit-min-device-pixel-ratio: 2) 및 (방향: 가로) {
    섹션 {너비: 100%;}
}

위의 코드를 작성할 때 원래 의도는 내 페이지의 <section> 요소를 모든 모바일 장치에서 유동 [폭 100%]으로 만드는 것이었습니다. 그러나 기본 장치 감지 기능이 없기 때문에 새 속성이 모든 관련 시나리오에 적용되도록 하기 위해 모든 모바일 지향 CSS 미디어 쿼리 블록에서 스타일 규칙을 타협하고 정의해야 합니다.

이것은 스타일시트 캐스케이드의 기능적 효율성과 Do-not-Repeat-Yourself 의 좋은 개발 원칙이 뒷자리를 차지해야 함을 의미합니다.

6. 워크플로 복잡성 증가:

CSS 미디어 쿼리는 레이아웃 크기 조정에 거의 전적으로 초점을 맞춘 반응형 웹 디자인의 매우 특정한 측면만 처리합니다. 따라서 그 이상을 수행하려면 JavaScript에 의존하여 차이를 보완해야 합니다. 이는 코드 및 도구에 대한 추가 학습 요구 사항을 소개합니다.

또한 [미디어 쿼리]가 중단점을 처리하는 비결정적인 방식으로 인해 원래 의도한 대로 작동하는지 확인하기 위해 수많은 가상 및/또는 물리적 장치에서 웹 페이지를 테스트하는 데 더 많은 시간과 돈을 소비해야 합니다. . 그리고 레이아웃을 크게 변경하면 모든 것을 다시 테스트해야 합니다.

CSS 미디어 쿼리를 사용하는 간단하고 의도적인 작업으로 최신 웹 페이지를 구축하는 데 필요한 단계 수를 크게 늘릴 수 있습니다.

7. 성능 저하:

CSS 미디어 쿼리가 작동하는 방식 때문에 웹사이트를 반응형/모바일 친화적으로 만들기 위해 다른 방법보다 훨씬 더 많은 CSS 코드가 필요하게 됩니다. HTTPArchive.org의 데이터에 따르면 CSS 파일 크기는 지난 5년 동안 114% 증가했습니다. HTML 파일 크기의 증가는 같은 기간 동안 약 53%로 최고조에 달했습니다.

특히 이상적이지 않은 모바일 광대역 네트워크를 사용하는 모바일 장치의 경우 이전보다 [반응형 웹 디자인 컨텍스트에서] CSS 미디어 쿼리를 구현한 후 속도가 느려지기 때문에 이 독특한 상황은 웹사이트에 성능에 영향을 미칩니다.

그리고 파일 크기 증가 문제를 제외하고 CSS 미디어 쿼리에는 실제로 웹 페이지의 성능을 향상시키는 내부 메커니즘이 없습니다. 이를 위해 고급 JavaScript 기술을 활용하여 이러한 개선 사항을 활성화해야 합니다.

왜 아직도 이것을 사용하고 있습니까?

웹사이트의 몇 퍼센트가 CSS 미디어 쿼리를 사용하고 있는지 묻는다면 당신의 대답은 무엇입니까? 웹 디자이너가 수년에 걸쳐 견뎌야 했던 모든 스트레스로 인해 지금쯤이면 우리가 채택의 고비를 넘었다고 생각할 수 있지만 매우 잘못된 생각입니다.

전체 웹에서 CSS 미디어 쿼리를 사용하는 웹사이트의 비율은 약 0.2%입니다. jQuery를 사용하는 웹사이트의 비율이 18%인 것과 대조됩니다. 이것이 의미하는 바는 jQuery로 구동되는 웹사이트를 접할 가능성이 반응형 웹사이트(둘 다 발생하는 웹사이트 제외)보다 90배 더 많다는 것입니다.

특정 사람들이 복잡하고 불필요하다고 생각하는 핵심 기술[JavaScript]에 기반한 툴킷이 겉보기에 덜 복잡하고 틀림없이 더 중요한 문제[모바일 친화성]를 해결하기 위한 것[CSS]보다 훨씬 앞서는 이유는 무엇입니까? ? 분명히 여기에는 채택을 방해하는 심각한 문제가 있으며 해결해야 합니다.

CSS 미디어 쿼리는 특정 문제를 처리하기 위해 웹 브라우저로 들어가는 방법을 찾았지만 반응형 웹 디자인의 전체 무게를 어깨에 짊어지기 위해 초안을 작성했습니다. 이것은 마치 3학년 리코더 리사이틀을 위해 연습하다가 헨델의 메시아를 트롬본 솔로 연주하기 위해 마법처럼 로열 앨버트 홀로 옮겨지는 것과 같습니다. 공정하지 않다!

현대 웹 디자인의 모든 도전과제에도 불구하고 우리가 여전히 이 미디어 쿼리 사업을 하고 있다는 것은 매우 놀라운 일입니다. 프로그레시브 웹 앱 디자인과 같은 새로운 분야의 몇 가지 새로운 문제 외에도 몇 가지 중요한 레거시 문제를 다루기에는 충분하지 않습니다. 그래서 대안을 마련해야 할 때라고 생각합니다. 그러나 그것은 정확히 무엇입니까?

해결 방법이 무엇입니까?

이 모든 것에 대한 해결책은 정말 매우 간단합니다. 바로 JavaScript입니다. 자, 그 갈퀴를 잡기 전에 설명할 기회를 주십시오.

JavaScript는 확장성이 더러운 단어가 아닌 HTML5 삼위일체의 유일한 구성 요소입니다. 더 많은 HTML을 사용하여 HTML 마크업을 확장할 수 없으며 CSS를 사용하여 기본적으로 CSS를 확장할 수 없습니다. 그러나 JavaScript를 사용하여 기본적으로 JavaScript를 확장할 수 있으며 CSS에서도 동일한 작업을 수행할 수 있습니다.

JavaScript로 CSS를 조작하는 것은 W3C의 웹 표준 커리큘럼에서 광범위하게 논의됩니다. document.stylesheets DOM 인터페이스를 사용하면 HTML의 <link> 태그를 사용하여 참조하는 모든 외부 스타일시트를 포함하여 웹 페이지에 적용된 스타일시트에 액세스할 수 있습니다. 쉽지 않은 일이지만 가능합니다.

따라서 초기 답변을 확장해야 합니다. 단순한 JavaScript가 아니라 JavaScript 지원 CSS 입니다. JavaScript는 믿을 수 없는 기능을 갖춘 멋진 플랫폼이지만 CSS는 대부분의 웹 디자이너가 작업하는 곳입니다. 웹 디자이너가 JavaScript 기능을 활용하기 위해 CSS 규칙 세트를 작성할 수 있는 이 둘 사이에 일종의 기능적 다리를 만들 수 있다면 웹 디자인의 판도를 바꿀 수 있을 것입니다.

코드를 보여주세요

지난 2년 정도 동안 저는 rKit이라고 하는 새로운 JavaScript 지원 CSS 도구 키트에 대해 작업해 왔습니다. 전체 아이디어는 반응형 웹 디자인을 위한 CSS 미디어 쿼리를 대체할 뿐만 아니라 웹 디자이너/개발자가 최신 웹사이트 및 웹앱을 구축할 때 직면하는 알려진 [그리고 알려지지 않은] 문제 중 일부를 해결하는 디자이너 친화적인 도구를 구축하는 것이었습니다.

개념에는 많은 것이 있지만 다음은 설명할 CSS의 빠른 코드 스니펫입니다.

 #my-element[rk="if @viewport.width 사이 320과 480"]{배경색: #0000ff;}

rKit에서 CSS 규칙은 수정된 속성-값 선택기처럼 보입니다. 그런 다음 값 섹션 내에서 표현식을 정의할 수 있습니다. 이 표현식의 구문은 간단하고 직관적으로 설계되었습니다.

참고 : rk 는 상수 속성 식별자입니다.

위의 코드는 아래의 CSS 미디어 쿼리와 기능적으로 동일합니다.

 @미디어 전용 화면 및 (최소 장치 너비: 320px) 및 (최대 장치 너비: 480px) {
    #my-element {background-color:#0000ff;}
}

그러나 rKit으로 할 수 있는 일이 훨씬 더 많습니다. 다음은 또 다른 빠른 예입니다.

 #my-element[rk="if @self.width between 320 and 480"]{background-color: #00ff00;}

단순히 엔터티 참조를 @viewport 에서 @self 로 변경하여 일반적으로 요소 쿼리라고 하는 것을 기본적으로 설정했습니다. 이제 #my-element 의 너비가 320에서 480픽셀 사이일 때 지정된 선언 [ background-color: #00ff00 ]이 적용됩니다.

순수 선언 대신 클래스를 사용할 수도 있습니다.

 #my-element[rk="if @self.width가 320에서 480 사이이면 addClass(c_mobile_320)"]{}
.c_mobile_320 {배경색: #00ff00;}

이것은 빙산의 일각에 불과합니다. rKit을 사용하면 이벤트 관리, 돌연변이 관찰, 수량 쿼리, 라우팅, 데이터 바인딩 [최대 7-way] 및 기타 여러 멋진 작업과 같은 멋진 작업을 모두 순수 CSS 코드를 사용하여 작성하지 않고도 수행할 수 있습니다. 자바스크립트 한 줄.

rKit은 출시될 때 무료이며 오픈 소스가 될 것입니다. 또한 렌더링 차단이 전혀 없는 방식으로 설치할 수 있는 특수 성능 팩도 제공하므로 웹 페이지가 레일 위의 로켓처럼 로드됩니다.

이것을 모으는 데는 꽤 오랜 시간이 걸렸지만 곧 [확실히 Godot 이전에] 여기에 올 것입니다. 저는 웹 디자이너[와 개발자]가 그것으로 무엇을 할 수 있는지 정말 보고 싶습니다.

결론

내가 CSS 미디어 쿼리를 강타하고 있다는 생각으로 이 게시물에서 벗어나지 않기를 바랍니다. 난 아니에요. 그것은 과일 샐러드로 끝나는 토마토를 두들겨 패는 것과 같습니다. 앞서 말했듯이 CSS 미디어 쿼리는 반응형 웹 디자인을 위해 설계된 적이 없습니다. 그것은 편의상 채택되었고 우리 모두는 그것을 사용하여 모든 문제를 해결하려고 시도하는 실수를 저질렀습니다.

슬프게도, 웹 커뮤니티인 우리는 초기 실수를 상당한 방식으로 개선하거나 더 나은 대안을 내놓음으로써 그 초기 실수를 수정하는 데 전혀 노력을 기울이지 않았습니다. 그러나 슬프게도 쇼는 계속되어야 하고 웹사이트는 구축되어야 하며 발전이 우선되어야 합니다. 변화가 필요한 때입니다.

rKit은 하나의 옵션이자 하나의 답변일 뿐입니다. 처음도 아니고 확실히 마지막도 아닐 것입니다. 그러나 최소한 올바른 방향으로 나아가는 올바른 단계입니다. 과거의 일부 문제를 수정한 다음 현재와 미래의 문제를 수정하기 위해 반복할 수 있는 기회입니다. 현상 유지와 어떻게 일치하는지 보는 것은 흥미로울 것입니다.

모든 말을 하자면, 실수를 하는 것 자체가 목적은 아닙니다. 학습 경험이어야 합니다. 운이 좋다면 다음에 올바른 작업에 올바른 도구를 사용하는 방법을 배우게 될 것입니다. 포장도로에서 자전거를 탈 수 있다고 해서 뉘르부르크링에 자전거를 가져와야 하는 것은 아닙니다. 포르쉐를 가져와!