CSS 모범 사례 : 잘못된 CSS의 9 가지 징후

게시 됨: 2020-12-16

CSS 또는 Cascading Style Sheets — 웹 페이지의 모양과 작동 방식을 정의하는 언어입니다. 웹 개발자는 많은주의를 요하지 않는 "쉬운"언어로 간과하는 경우가 많습니다. 가장 일반적인 속성 중 일부를 암기하고 일반적인 흐름과 더 모호한 속성을 검색하는 것이 갈 길입니다. 그러나 경험이 많은 개발자가 알다시피, 무언가를하는 좋은 방법과 나쁜 방법이 항상 있기 때문에 간과 할만한 언어는 없습니다.

CSS를 사용하면 오류를 발생시키는 컴파일러가없고 잘못된 구현에 대한 경고 나 알림이 없으므로 잘못된 방식으로 작업을 수행하기가 매우 쉽습니다. JavaScript와 같은 프로그래밍 언어에는 좋은 코드 품질을 추적하는 수많은 도구가 있으며 일부는 특정 기능이 올바른 방식으로 구현되지 않았다는 메시지를 개발자에게 던지기도합니다.

프로그래밍 언어들

이 비교적 짧은 게시물에서는 개발자가 직면하는 일반적인 문제와 해결 방법에 대해 살펴 보겠습니다. 이것은 특정 시각적 구성 요소에 대한 특정 구현 세부 사항에 관한 것이 아닙니다. 대신이 목록은 사고 과정, 아키텍처 및 접근 방식에 중점을 둡니다.

CSS 복잡성

CSS는 어렵습니까? 아니! 확실히 아닙니다. 매우 기본적인 구조 규칙이 몇 가지 있습니다. 선택자 (클래스, ID, 요소)가 있고 속성이 있고 범위가 있습니다. C, Java 또는 PHP와 같은 언어보다 훨씬 적습니다. 개발자는 스타일을 읽고 몇 분만에 전체 아이디어를 얻을 수 있습니다. 물론 여백과 패딩의 차이를 알기 위해 w3schools를 살펴볼 수 있지만 언제 사용하려면 경험이 필요합니다. 그러나 그것은 로켓 과학이 아닙니다.

이제 상황을 좀 더 복잡하게 만드는 것은 선택자가 다음 항목을 덮어 쓰는 경쟁 방식과 한 속성이 다른 속성에 미치는 영향 (예 : display : block vs display : inline)입니다. 그런 다음 여백 축소, Z- 인덱스 스택, GPU 대 CPU 성능 속성, 상자 모델 및 타이포그래피 속성과 같은 작은 세부 정보가 있습니다.

무엇보다도 브라우저에서 항상 동일한 방식으로 구현되지 않는 새로운 CSS 기능, 일부는 전혀 구현되지 않고 다른 기능은 다른 속성이 필요합니다.

비교적 새로운 사용자 지정 속성에 대한 브라우저 지원

위의 두 단락을 살펴보면 프론트 엔드 개발자가 CSS로 작업 할 때 두 가지 주요 단계를 볼 수 있습니다. 하나는“ 오, 그게 다야? ”이고 두 번째는“ 오 ****, 그게 다가 아니야 ”입니다. 이것이 "CSS 복잡성"을 의미합니다.

확장하기 어려운 작은 것들이 많이 얽혀 있습니다. 하나의 구성 요소 만 구축하면 간단합니다. 보이는대로 스타일을 지정하고 작동합니다. 그러나 단일 구성 요소를 더 큰 응용 프로그램에 넣으면 추가 스타일이 적용됩니다. 버튼과 같은 다른 클래스와 동일한 클래스로 끝날 수 있으며 스타일은 전체 애플리케이션에 적용되어 모든 것을 깨뜨릴 것입니다. 스트레스입니다!

WordPress CSS : 초보자를위한 기본 가이드

CSS 작성 방법 : 복잡성과의 싸움

똑똑한 사람들이 생각 해낸 몇 가지 해결책이 있습니다. 개요는 다음과 같습니다.

  • 충돌 가능성을 줄이는 클래스 이름 규칙을 정의하는 BEM, SMACSS 등과 같은 CSS 명명 규칙.
  • JS의 CSS는 실제로 JS 파일에 CSS 구성 요소를 작성할 수있게 해주는 새로운 방법입니다 (나쁘게 들리지만,보기에는 좋지 않지만 적어도 의미가 있습니다). 대부분 React, Vue 및 기타에서 유효합니다.
  • CSS Modules는 하나의 파일에서 모든 스타일로 끝나는 사람을 위해 JS의 CSS에 대한보다 건전한 접근 방식입니다. CSS 모듈은 각 구성 요소의 스타일을 캡슐화하여 다른 구성 요소로 유출되지 않도록하여 재사용을 더 쉽게 만듭니다. 또한 스트레스를 많이 줄여줍니다!

첫 번째 – 명명 규칙 은 사용자를 도울 도구가 없기 때문에 구현하기 가장 어려울 것입니다. 컨벤션 을 이해하고 적용 하는 것은 개발자 에게 모든 것을 맡깁니다. 당신은 여전히 ​​클래스 이름을 생각해야하고, 그것들이 여전히 충돌해서는 안되며, 전체 팀이 그것을 따르도록해야합니다. 꽤 힘들어요!

JSCSS 모듈의 CSS 는 구현 수정입니다. 코드 출력을 전체적으로 변경하여 스타일을 유출하는 것이 사실상 불가능합니다. 그러나 그들은 완전히 다른 사고와 구축 설정을 필요로합니다. 항상 실행 가능하거나 원하는 것은 아닙니다.

모든 것을 한곳에 담아

여기에서 가장 좋은 조언은 다음과 같습니다 . 가장 일반적이고 성공적인 명명 규칙을 연구하고 회사 또는 생태계의 코딩 표준에 맞는 규칙을 사용하십시오. 구성 요소 분리를 이해하고 대규모 앱을 빌드하는 단일 단위 및 범위 측면에서 생각을 시작합니다. 처음부터 큰 앱이 아니므로 관리가 불가능합니다.

React와 같은 라이브러리 또는 Vue와 같은 프레임 워크를 포함하는 스택에서 작업하는 경우 스타일을 관리 할 수있는 추가 도구를 살펴보세요. 초급에서 중급 수준의 CSS 개발자에게 큰 도움이 될 것입니다! 그리고 더 나은 것이 당신의 방식으로 오지 않는 한 그들을 버리고 싶지 않을 수도 있습니다.

새로운 도구에 눈을 뜨십시오! 그들은 개발자 커뮤니티가 이미 발견하고 수정 한 문제를 해결하는 방법을 제공 한 문제와 싸우지 못하게합니다.

이제 CSS 복잡성이 무엇을 의미하는지와이를 해결하기위한 몇 가지 시작 팁을 설명 했으므로 더 자세한 개요를 살펴보고 직접적인 예제를 제공하겠습니다.

웹 사이트 디자인 팁 : 웹 디자인에서 게임을 강화하는 방법

잘못된 CSS의 9 가지 징후

이 목록은 긴 마일이 아니라 완전하지 않습니다. 안타깝게도 다른 수많은 문제에 직면하고 Stackoverflow와 같은 사이트에서 특정 문제에 대한 직접적인 해결책을 찾을 수 있기를 바랍니다.
그러나 게임을 향상시키고 싶다면 몇 줄의 CSS로 문제를 해결할 때 그들이하는 일을 이해해야합니다. 마크 업을 변경해야하는 이유와 몇 가지 선택기, 속성을 변경해야하는 이유는 무엇입니까?

여백이 이상하게 작동합니다.

개발자가 직면하는 일반적인 문제는 두 요소가 여백 (위 / 아래)을 더하지 않는 경우입니다. 예를 들어 여백이있는 두 개의 <p> 요소가 있습니다 : 20px 0 ;. 이들 사이의 총 공간은 40 픽셀이 아니라 20 픽셀입니다. 이는 여백 붕괴 때문입니다. 요소가 떠 있거나 절대 위치에있는 경우는 예외입니다. 이 "제외"는 거의 모든 정의에서 거의 모든 곳에 있습니다.

Z- 색인 : 9999999, 여전히 Z- 색인 위에 없음 : 1

우선, 이렇게 높은 Z- 색인을 작성할 필요가 거의 없습니다. 99999999999999 이상의 값도 본 적이 있습니다. 첫째, Z- 색인 최대 값은 2147483647이므로 위의 모든 것은 쓸모가 없습니다. 둘째, 그렇게 작동하지 않습니다. 맨 위에있는 요소는 Z- 색인 값뿐만 아니라 누적 컨텍스트에 의해 정의됩니다. 아래 그래픽을 참조하십시오.

stackimg 컨텍스트가 작동하는 방식

올바른 속성을 애니메이션하지 않음

다소 간단한 질문이지만 일부 개발자는 애니메이션 및 접근 방식과 관련하여 어려움을 겪습니다. 첫째, 무엇을 애니메이션 할 수 있습니까? 시작 값, 끝 값 및 그 사이의 모든 것을 가질 수있는 모든 것. 불투명도는 이러한 속성입니다. 0에서 시작하여 1에서 끝날 수 있으며 0.3, 0.6758, 0.9875 등의 사이에 무한 단계를 추가 할 수 있습니다. 인라인과 그리드 사이에 중간 단계가 없기 때문에 "표시"를 애니메이션 할 수 없습니다.

비효율적 인 애니메이션

애니메이션에서 FPS가 나쁜 가장 일반적인 이유는 애니메이션이 잘못된 속성 때문입니다. 절대 요소의 "left"속성을 변경하면 CPU를 사용하여 계산하게됩니다. 그러나 transform을 사용하면 GPU가됩니다. 그리고 우리 모두가 알고있는 GPU는 그래픽을하는 것이 더 좋습니다.

브라우저에서 GPU와 CPU 애니메이션 비교

그러나 왼쪽 / 변형과 같은 대안이없는 경우 그림자를 어떻게 애니메이션할까요? 글쎄, 애니메이션 불투명도! 시작, 상태, 종료 상태가있는 두 개의 요소가 있습니다. 그런 다음 시작과 끝을 페이드 인합니다. 이렇게하면 그림자가 확장되는 것처럼 보이며 실제로는 페이드 만됩니다.

가능하면 레이아웃에 영향을 미치는 요소를 애니메이션하지 마십시오. 레이아웃 계산은 비용이 많이 들고 CPU는 제한된 양의 계산 만 수행 할 수 있습니다. 종종 16ms마다 1 개 미만으로 FPS가 60 미만이됩니다.

너무 깊은 선택자

수정 자란 무엇입니까? 다른 클래스에 추가하고 일부 속성을 바꿀 수있는 클래스입니다. 예 : .button의 색상은 빨간색입니다. .button-primary, 색상 : 파란색. 따라서 .button-primary를 .button에 추가하면 파란색으로 끝나고 싶습니다. 쉬워요. 매번 그렇게 쉬운 것은 아니지만. 그리고 매번 이와 같은 구성 요소는 아닙니다.

때로는 특정 페이지에있는 다른 구성 요소의 하위 구성 요소를 덮어 쓰려고합니다. 따라서 다음과 같은 결과를 얻게됩니다. .page-name .section-name .component-1 .component-2 {…} 이미 4 단계 깊이입니다. 하지만 결과는 .page-name .componen-2 {…} 만 수행 할 수 있다는 것입니다. 짧을수록 좋습니다! 왜냐하면 어떤 이유로 새로운 스타일을 덮어 써야한다면 5 단계 깊이, 6 단계, 그 이상으로 갈 필요가 없기 때문입니다.

딥 셀렉터는 무섭고 사람들은 결국! important를 사용합니다. ! important는 제어 할 수없는 인라인 스타일을 덮어 쓰려는 경우에 사용해야합니다. 그렇지 않으면, 당신이 옳은 일을하고 있지 않다는 것은 위험 신호입니다.

너무 큰 파일

물론 대규모 애플리케이션의 경우 많은 스타일이있을 수 있으며 이는 완전히 이해할 수 있습니다. 하지만 항상 그렇게 큰가요? SASS에서 클래스를 확장하는 잘못된 방법 (믹스 인을 통해)은 큰 선택기 체인을 생성하여 모두보기 위해 스크롤하는 데 몇 초가 걸립니다. 적절한 확장자는 해당 파일을 많이 줄입니다. 크기를 두 배로 줄일 수도 있습니다.

번들링-자산-통제 불능-속도에 미치는 영향

일부 속성 만 사용되는 포함 된 프레임 워크도 대용량 파일의 일반적인 이유입니다. 부트 스트랩 / 기초, font-awesome, animate.css 및 기타 유사한 프레임 워크 / 라이브러리 몇 개를 함께 묶으면 약 2 %를 사용하는 거대한 파일이 생성됩니다. 정리하고, 깔끔하게 유지하고, 정말로 필요한 것만 사용하십시오. 많은 경우 프레임 워크가 필요하지 않습니다.

필요하지 않은 프레임 워크

Bootstrap, Foundation, UIKit 및 기타 모든 프레임 워크는 훌륭합니다! 그들은 실제 문제를 해결하고 웹 개발 커뮤니티에 매우 가치가 있습니다. 대시 보드와 사이트를 만드는 데 필요한 HTML이나 CSS를 알 필요가 없습니다. 그러나 그 경우에서 벗어나 CSS 작성을 시작하면 몇 가지 문제가 발생합니다.

최고의 CSS 프레임 워크

  • 빌드 방법과 포함 방법을 올바르게 이해해야합니다.
  • 그들이 제공하는 사용자 정의 설정 및 믹스 인을 찾으려면 설명서를 읽어야합니다.
  • 당신은 그들의 마크 업을 따르고 당신의 팀에게 그렇게하도록 가르쳐야합니다.
  • 독특한 뷰를 만들기 위해 확장하고 스타일을 지정하는 방법을 진정으로 이해해야합니다.

적절하게 포함한다는 것은 필요한 것만 사용한다는 것을 의미합니다. 이러한 프레임 워크가 사용자 정의를 구축하는 것을 금지하는 대신 도움이되도록하려면 내부 작업이 평균보다 더 나은지 알아야합니다. 그리고 사용자 정의 디자인을 얻으려면 설정과 속성을 수정해야합니다. 그리고 커스텀 CSS를 작성하세요. 그리고 그 사용자 정의 CSS는 프레임 워크가 제공하는 모든 것을 덮어 씁니다.

따라서 그러한 CSS 프레임 워크가 실제로 필요하지 않지만 여전히 하나가 있고 제대로 활용되지 않은 경우, 이것은 무언가 잘못되었다는 위험 신호입니다. 그리고 한 번 시작하면 프로젝트 수명주기가 끝날 때까지 사용하게 될 것입니다. 그래서 그것은 중요한 결정입니다.

콘텐츠가 크기를 정의하도록 허용하지 않음

이것은 초보자 수준의 문제에 가깝지만 매우 일반적인 문제입니다. 콘텐츠에 가치있는 자유를 제공해야합니다.

예를 들어 사이트의 너비 속성을 1200px로 설정하지 않으려 고합니다. 최대 너비 를 1200px로 설정하려고합니다. 이렇게하면 뷰포트에서 사이트가 반응 형을 유지할 수 있습니다.

그런 다음 입력 필드의 높이는 40px가 아니어야하며 1em 패딩이 있어야합니다. 이제 글꼴 크기, 내용이 크기를 정의합니다. 내부 콘텐츠가 커지면 요소가 깨지지 않습니다.

크기를 정의 할 때 이러한 사고 방식은 전체 응용 프로그램에서 여전히 중요합니다. 그리고 각 속성은 그것을 고려해야합니다. 이상적으로는 미디어 쿼리도 작성해야하므로 콘텐츠 영역의 너비에 %를 설정하지 마십시오.

콘텐츠 정의 크기

최대 너비가있는 경우 브라우저가 해당 최대 너비 아래로 축소되면 콘텐츠가 브라우저 너비를 채우고 정상적으로 축소됩니다. 그렇지 않으면 해당 크기에 대한 미디어 쿼리를 작성해야합니다. 그런 다음 사이트에 작성된 다른 사용자 정의 크기에 대해. 이것은 잘못된 접근 방식으로 인해 추가 된 복잡성입니다. 우리가 이미 논의한 다른 모든 요점과 거의 동일합니다.

자바 스크립트 해킹

JavaScript는 놀라운 일을 할 수 있습니다! 그러나 항상 필요한 것은 아닙니다. 잘 지원되고 기능이 필요하지 않으며 (나중에 자동으로 가장 잘 테스트되는) CSS만으로 많은 작업을 수행 할 수 있으며 다른 FE 구성원도 JS를 알 필요가 없습니다.

물론 표준 토글 기능이 있습니다. 체크하면 체크 박스 입력을 사용하여 스타일을 변경할 수 있습니다. : checked, 쉽게 트리거 할 수있는 배경 오버레이가 있으며 간단한 <ol> 목록 이상을 생성하는 counter와 같은 속성이 있습니다. .

여기서 조언은 먼저 CSS 솔루션을 찾는 것입니다. 팝업을 만들고 싶다고 가정 해 보겠습니다. 중간에 표시됩니다 (위치 : 고정). 그런 다음 [X] 아이콘에서 닫거나 주변을 클릭 할 때 닫습니다. JS에서는 팝업 콘텐츠를 제외한 모든 것을 트리거하는 이벤트를 작성해야합니다. 하지만 여전히 팝업 콘텐츠에있는 [X]에서 트리거됩니다.

대신 CSS에서 팝업 바로 아래에 100vw, 100vh 크기 및 Z- 색인이있는 다른 <div>를 작성할 수 있습니다. 그런 다음 JS에서 해당 div를 대상으로 지정할 수 있습니다.

또 다른 예-콘텐츠에 배치 할 수있는 버튼을 원합니다. 그러면 그 뒤에 오는 모든 콘텐츠가 "확장"됩니다. CSS로 간단하고 JS로 조금 더 복잡합니다. CSS를 사용하면 다음과 같이 할 수 있습니다.

 Label.button-버튼의 스타일을 시각적으로 지정합니다.
 Input : not (: checked) ~ * {display : none}-동일한 컨테이너에서 그 뒤에있는 모든 항목을 숨 깁니다.

"동일한 컨테이너에있는"그 비트는 JS에서 사용자 정의 로직이 필요합니다. 또한 DOM 트리를 탐색해야하는 모든 요소를 ​​선택해야합니다. 그런 다음 CSS 스타일을 적용하면 style =””태그가됩니다. 어떤 이유로 든 문제를 해결해야한다면! important가 필요합니다. 고맙게도 CSS에서는 매우 간단합니다.

좋은 웹 디자이너가되는 길

결론

보시다시피 이러한 문제는 거의 발생하지 않습니다. 그것들을 모두 다루려면 책이 필요합니다. 그러나 바라건대, 그들은 당신에게 좋은 출발점을 제공하고 잘못된 접근으로 인해 발생할 수있는 잠재적 인 문제에 대해 생각하도록 상기시켜 줄 것입니다. 그러한 문제를 찾는 것은 많은 경험과 많은 독서를 동반합니다. 그리고 여기에서 결론에 도달했다면, 독서와 함께 올바른 길을 가고있는 것입니다. 이제 연습 할 시간입니다!

DevriX WordPress 개발 리테이너

WordPress 플랫폼을위한 장기 개발, 지원 및 혁신. DevriX는 중소기업과 빠르게 변화하는 스타트 업을위한 기술 파트너십을 제공합니다. 우리는 워드 프레스 솔루션을 구축하고 한 달에 최대 20,000,000 페이지 뷰를 생성하는 플랫폼을 확장합니다.

일하자.