지금 CS가 너무 많습니까?

프론트 엔드 개발자는 CSS, 스타일 캡슐화, 요소 종횡비 설정, 미세한 색상 제어, 하위 요소 속성을 기반으로 요소 선택, 특정 레벨 관리, 요소가 부모 요소 폭에 응답하는 등 여러 해 동안 많은 기능을 열망했습니다.

이제, 우리는 우리가 원하는 것을 얻고 심지어 더 많은 것을 얻었지만 어떤 사람들은 질문하기 시작했습니다 - 우리는 지금 너무 많은

css를 가지고 있습니까?

어두운 시대 CSS 개발 초기에 웹 개발에 관여 한 나와 같은 사람이라면 CSS가 너무 많다는 아이디어는 우스운 것처럼 보입니다. 과거에는 프론트 엔드 개발자의 작업이 거의 전적으로 CSS의 한계를 중심으로 진행되었습니다. 예를 들어, Clearfix Hack을 사용하여 Floats를 클리어링하고 100% 패딩 핵을 사용하여 사각형 DIV를 만들기 위해 Square Div를 생성합니다. 인터넷 익스플로러가 명령을 실행하도록 무작위로 적용하는 것은 말할 것도 없습니다.

당시 브라우저는 교활한 적이었고 순수한 기술과 신비한 주문으로 패배해야했습니다. 요즘에는 완벽한 속성이 있습니다. MDN에 복사하여 붙여 넣기 만하면됩니다.

CSS의 새로운 시대 그러나 이제 상황은 매우 다릅니다. 개발이 훨씬 빠를뿐만 아니라 브라우저 제조업체도

도 개발자의 감정에 관심이 있습니다! 나는 처음에는 그것을 믿지 않았다. 그러나 저는 매년 CSS 상태 개발자 설문 조사를 수행합니다 (그건 그렇고 현재 진행 중입니다 - 참여하십시오!). 브라우저 개발 팀이 결과 (및 기타 데이터 포인트)를 사용하여 로드맵을 결정한다는 것을 알고 있습니다.

그 외에도 Google은 내 조사에 자금을 조달했으며 심지어 올해의 조사 질문을 선택하는 책임을 맡기 위해 Lea Verou를 고용했습니다.

그것은 단지 Google이 아닙니다. Safari와 Apple (때로는해야 할 일)을 부르는 것은 유행이되었지만 개발자의 말을 듣고 웹을 개선하는 것에 대한 Jen Simmons의 열정을 부정 할 수는 없습니다.

브라우저 제조업체는 자체 CS를 개선 할뿐만 아니라 Interop 2023과 같은 이니셔티브를 통해 경쟁 경계를 통해 협력하여 브라우저 간의 불일치와 비 호환성을 줄입니다.

너무 많은 좋은 것?

이 모든 결과는 우리가 이제 CSS 자원의 공급 과잉 문제에 직면하고 있으며 유지하는 데 어려움을 겪고 있다는 것입니다. CSS 그리드는 거의 5 년 동안 주요 브라우저에서 지원되었지만 사용할 때마다 참조 문서를 참조해야합니다. Subgrid는 멋져 보이지만 아직 시도하지 않았습니다.

Lea와 나는 많은 기능을 고려했지만 일부는 거부했습니다. 우리가 포함하지 않는 일부 기능은 다음과 같습니다.

완화 곡선을 더 잘 정의 할 수있는 완화 함수.
• 함수는 브라우저 나 장치에서 정의한 변수를 사용할 수 있습니다. linear() 스크롤 막대의 모양을 제어하는 ​​데 도움이되는 속성.
• 속성, 컨테이너 아동 요소의 마진 동작을 제어 할 수 있습니다. env()
이 모든 것이 매우 유용 할 수 있으며 과거 CSS 부족이 과거에있을 때 과거에 큰 뉴스가 될 것입니다. 그러나 오늘날의 맥락에서 그들은 더 큰 발표 (예 :
• 선택기 또는 CSS 중첩!)와 경쟁해야합니다. scrollbar-width 노동 흥분
Silvestar Bistrović가 쓴 것처럼, 그는이 모든 새로운 CSS 기능에 대해“흥분하지 않습니다”. Sara Soueidan은 트위터에서 그녀가“기능이 얼마나 눈부신 지가 아니라 목적이 아닌 목적”에 대해 걱정했다고 응답했습니다.
• 이것은 부정적인 태도 인 것 같지만 이해할 수 있다고 생각합니다. 아무도 너무 많은 새로운 기능을 따라 잡을 수 없습니다! margin-trim

  또 다른 예상치 못한 (또는 아마도 의도적인가?) 결과는 더 복잡한 CSS가 브라우저 엔진면을 개발하려는 새로운 회사의 장벽이 높아졌습니다.이 모든 새로운 기능의 추가 워크로드를 유지하고 문서화하는 것은 말할 것도 없습니다.

CSS의 과신 CSS가 취급에 적합하지 않은 지역으로 확장 될 수 있다는 매우 합리적인 우려도 있습니다. Sara Soueidan은 또한 새로운 CSS 스위치의 실험적 구현에 반응 할 때 이것을 지적했습니다 (이것은 논의하는 티켓입니다) : . 많은 사람들은이 동작이 CSS를 통해 순전히 스위치 상태를 관리하는 대신 새로운 HTML 요소에 의해 가장 잘 처리된다는 매우 합리적인 지적을 만들었으며, CSS는 접근성 문제를 제대로 해결할 수 있도록 최선의 매체가 아닐 수 있습니다.

이것은 CSS가 JavaScript를 통해 이전에 처리 된 컨텐츠를 인수 할 때 종종 좋은 것으로 간주됩니다. 일반적으로 브라우저가로드 해야하는 코드의 양을 줄입니다. 따라서 CSS 스위치에 대해 조심스럽게 낙관적이며 CSS 태스크 포스가 커뮤니티의 우려를 제대로 처리 할 것이라고 믿습니다. 그러나 언젠가 우리는 CSS가 경계를 넘어 HTML과 JavaScript의 의무를 침해 할 수 있다고 걱정하기 시작할 것입니다.

has() 새로운 기대치

아마도 이것이 바로 변경해야 할 것일 수도 있습니다. 어쩌면 우리는 CSS 개발자가 모든 CSS 기대치를 이해해야할까요? 이 기대는 CSS가 한때 나중에 생각한 것으로 간주되었을 때에서 비롯된 것입니다. 불쾌한 문법은 고객의 요청에 따라 버튼을 파란색으로 바꾸는 법을 배워야합니다. 그러나 오늘날의 CSS는 한 사람, 특히 다른 프론트 엔드 작업 밖에서 마스터하기에는 너무 커질 수 있음을 인정해야한다고 생각합니다.

Michelle Barker가 말했듯이 이것은 나의 마지막 결론입니다. 나는 가능한 모든 CSS 기능을 사용하지 않을 것이라는 사실을 받아 들였습니다. 그리고 이것은 여전히 ​​CSS 에 대한 설문 조사를 실시한 에서 나온 것입니다! 그러나이 새로운 기능은

일부 사람들에게 확실히 유용합니다 . 누군가가 그들에 대한 블로그 게시물을 작성하고, 그들과 함께 멋진 코드 펜을 만들고, 그들에게 말할 것입니다. 이 사람은 모든 머리카락을 가진 시원하고 젊고 활기찬 개발자가 될 것입니다. 다시 말해, 그것은 나가되지 않을 것입니다. 좋습니다. 아마도이 새로운 개발자가 한 번에 너무 많이 배워야함으로써 압도 당할까 걱정할 것입니다. 그러나 가

를 배제 할 필요가없는 것은 이러한 업데이트 된 대안으로 인해 정확하게 대체된다는 것을 기억하십시오. 나는이 거래를 언제든지 받아 들일 것임을 알고 있습니다.

그러나 그것에 대해 생각하십시오. 지난 몇 년 동안, 우리는 적응 해야하는 장치의 수가 크게 증가했을뿐만 아니라, 우리 각자는 약간 다른 방식으로 네트워크를 소비한다는 사실을 깨닫기 시작했습니다. CSS 가이 새로운 현실에 적응해서는 안됩니까? 이제, 나는 모든 것이 조금 향수를 느끼게한다는 것을 인정해야한다. 내가 언급했듯이, 연례 CSS 상태 설문 조사가 열려 있습니다. CSS가 너무 많든 아니든이 설문 조사는 브라우저 개발자에게 자신의 느낌을 알려주는 좋은 방법입니다. 10 분이 있으면 채우십시오.

위 내용은 지금 CS가 너무 많습니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!