시중에는 많은 CSS 방법론이 있는데 저는 그것들을 모두 싫어합니다. 더 많은 것(tailwind & al.)과 더 적은 것(BEM, OOCSS 등). 하지만 결국에는 모두 결함이 있습니다.
물론 사람들은 좋은 이유로 이러한 접근 방식을 사용하며, 해결된 문제 중 상당수는 제가 직면한 문제이기도 합니다. 그래서 이번 포스팅에서는 CSS를 정리하는 방법에 대한 나만의 가이드라인을 적어보고자 합니다.
이것은 누구나 바로 사용할 수 있는 완전히 설명된 CSS 방법론이 아닙니다. 어쩌면 약간의 추가 작업을 통해 하나로 바뀔 수도 있지만, 이 게시물의 목적은 단순히 CSS를 작성할 때 이러한 결정을 내리는 방법을 보여주는 것입니다.
경험상, 나는 내장된 요소 유형을 최대한 많이 사용하고 추가 보풀은 최소화하려고 노력합니다.
수천 가지 유형의 버튼이 필요하다는 것은 더 깊은 수준에서 디자인에 문제가 있을 수 있다는 신호이므로 어떤 경우에는 프레임워크별 클래스가 사용될 때까지 CSS가 비활성이라는 매력을 느낍니다. , 대부분의 경우 버튼이 단지 이고 더 이상의 마법이 없는 버튼처럼 보일 때 이상적이라고 생각합니다.
div.btton이 버튼으로 바뀌어야 합니다.
모든 디자인 요소가 의미상 적합한 HTML을 갖고 있는 것은 아니며, 이러한 경우에는 일반적으로 맞춤 요소를 사용합니다.
자바스크립트 없이 사용자 정의 요소 이름이 사용되는 사례를 많이 본 적이 없지만, 이는 내가 원하는 방식으로 보이는 명확한 HTML을 작성하기 위한 놀랍도록 확실한 선택임이 입증되었습니다.
디자인 측면에서 완전히 분리된 요소는 시간이 지남에 따라 JavaScript로만 구현할 수 있는 요구 사항을 개발할 가능성이 더 높으며, 이는 HTML이나 HTML을 변경할 필요가 없는 요구 사항을 구현할 수 있는 명확한 경로를 제공합니다. CSS.
div.vsep는 수직 구분 기호로 바뀌어야 합니다.
클래스는 완전히 새로운 요소 유형이 아닌 기존 노드 이름의 수정자로 작동해야 하며, 서로 다른 요소 유형에 대해 유사하지만 다른 효과를 갖는 경우가 많습니다.
위험한 버튼은 버튼입니다.위험
요소를 수정하는 일부 방법은 클래스가 유용한 단순한 켜기/끄기 스위치가 아니라 키-값 쌍처럼 동작합니다.
이러한 경우 일치하는 선택기가 있는 사용자 정의 속성은 거의 사용할 때마다 최상의 옵션임이 입증되었습니다. 하이픈으로 연결된 클래스와 달리 속성과 값이 구문 수준에 표시되므로 편집자가 이를 강조 표시하기 쉽고 육안으로 빠르게 구문 분석하기가 더 쉬우며 JavaScript를 사용하여 인터페이스하기가 더 쉽습니다.
언젠가 attr() 함수가 콘텐츠 이상의 용도로 CSS에 적용될 수 있기를 여전히 희망하는 사람들에게 이는 미래 보장을 위한 추가 계층이기도 합니다.
ID는 정의에 따라 문서 내에서 고유합니다. 따라서 특정 ID를 대상으로 하는 규칙은 제한되며 나중에 이 유형의 요소가 레이지에 두 개 이상 있어야 하는 것으로 밝혀지면 리팩터링이 필요할 수 있습니다.
따라서 ID는 한 문서에 두 개 이상의 요소를 포함하는 것이 타당하지 않은 경우에만 아껴서 사용해야 합니다.
실용성과 가독성 측면 모두에서 클래스에 비해 이점이 적으므로 요소와 스타일 간의 명확한 1:1 관계를 식별할 수 없는 경우 일반적으로 클래스 측면에서 오류를 범하는 것이 가장 좋습니다.
실제 응용 프로그램에는 나타나는 상황에 따라 미학적으로 더욱 만족스럽게 만들기 위해 개별적인 조정이 필요한 요소가 어느 시점에 이르게 됩니다.
이 경우 스타일 속성을 사용하는 것이 좋습니다. 이를 사용하는 것이 나쁜 습관으로 간주되는 이유는 유틸리티 클래스를 포함한 모든 종류의 인라인 스타일에 적용됩니다. 문제는 속성이 아니라 스타일과 마크업을 혼합하는 것입니다.
인라인 스타일에 대한 스타일과 클래스의 한 가지 차이점은 하나는 목적을 나타내고 일반 CSS 사용을 허용하며 대부분 보편적인 반면 다른 하나는 그렇지 않다는 것입니다.
간단히 말하면 width: 100px은 보편적으로 정의된 의미를 갖는 반면, .width-100은 무엇이든 의미할 수 있습니다.
매우 드문 경우지만, 요소별 스타일이 너무 복잡해 명시적으로 인라인 처리하면 가독성이 떨어지거나 불가능할 수도 있습니다(예: 미디어 쿼리가 필요한 경우).
이러한 경우 유틸리티 클래스는 보기 흉하더라도 기본적으로 유일한 옵션입니다.
이상적인 세상에서 이들은 특정 믹스인 클래스와 별도로 처리될 수 있으며 더 쉽게 구분하기 위해 접두사를 사용하는 것도 고려했지만 궁극적으로 이들을 보기 흉하지 않게 만드는 좋은 방법을 찾지 못했습니다.
유틸리티 클래스에 접두사를 붙여서 요소의 유형을 지정하는 일반 클래스와 달리 요소에 일종의 기능을 추가한다는 아이디어가 마음에 듭니다.
그게 전부였습니다. 물론, 두 프로젝트가 동일하지 않으며 때로는 실용성을 유지하기 위해 규칙을 약간 구부려야 하지만 전반적으로 이것이 화면의 내용을 특정 방식으로 보이게 만드는 방법을 결정하는 프레임워크입니다.
당신의 생각은 무엇입니까? 당신은 그것을 싫어합니까? 말이 된다고 생각하시나요? 댓글로 알려주세요 ?
부인 성명: 제공된 모든 리소스는 부분적으로 인터넷에서 가져온 것입니다. 귀하의 저작권이나 기타 권리 및 이익이 침해된 경우 자세한 이유를 설명하고 저작권 또는 권리 및 이익에 대한 증거를 제공한 후 이메일([email protected])로 보내주십시오. 최대한 빨리 처리해 드리겠습니다.
Copyright© 2022 湘ICP备2022001581号-3