CSS 프레임워크에 대한 토론

최근 CSS 프레임워크에 대한 소개를 많이 봤습니다. 며칠 전에 "제 제한된 시야로는 CSS 프레임워크라고 부를 수 있는 것을 본 적이 없습니다~"라고 말한 적이 있습니다. 물론 가능합니다. 내 시야가 너무 작기 때문이거나, 세상이 너무 넓기 때문일 수도 있지만, 아직은 내가 볼 수 없는 것이 많다고 느낍니다.

먼저 제가 더 동의하는 개념을 살펴보겠습니다.

프레임워크는 두 가지 프레임워크, 즉 화이트박스(White-Box)와 블랙박스(Black)로 나눌 수 있습니다. -상자).

상속을 기반으로 하는 프레임워크를 화이트박스 프레임워크라고 합니다. 소위 화이트 박스에는 가시성이 있으며 상속된 상위 클래스의 내부 구현 세부 사항이 하위 클래스에 알려집니다. 화이트박스 프레임워크를 활용하는 애플리케이션 개발자는 하위 클래스를 파생하거나 상위 클래스의 멤버 메서드를 재정의하여 시스템을 개발합니다. 하위 클래스의 구현은 상위 클래스의 구현에 크게 의존하며 이러한 종속성은 재사용의 유연성과 완전성을 제한합니다. 그러나 이 제한을 해결하는 방법은 추상 부모 클래스만 상속하는 것입니다. 왜냐하면 추상 클래스는 기본적으로 구체적인 구현을 제공하지 않기 때문입니다. 화이트박스 프레임워크는 프로그램 뼈대이며 사용자 파생 하위 클래스는 이 뼈대에 대한 액세서리입니다.

객체 컴포넌트 어셈블리 기반의 프레임워크가 블랙박스 프레임워크입니다. 애플리케이션 개발자는 객체를 정렬하고 조립하여 시스템 구현을 얻습니다. 사용자는 구성 요소의 외부 인터페이스만 이해하면 되며 특정 내부 구현을 이해할 필요는 없습니다. 또한 어셈블리는 상속보다 유연하며 동적으로 변경될 수 있습니다. 상속은 정적 컴파일 타임 개념일 뿐입니다.

이상적인 상황에서는 기존 구성 요소를 조합하여 필요한 기능을 얻을 수 있습니다. 실제로 사용 가능한 구성 요소가 요구 사항을 충족하는 것과는 거리가 멀습니다. 기존 구성 요소를 사용하는 것보다 상속을 통해 새 구성 요소를 얻는 것이 더 낫습니다. 새로운 빌딩 블록을 조립하는 것이 더 쉽기 때문에 시스템 개발에는 화이트 박스와 블랙 박스가 모두 사용됩니다. 그러나 화이트박스 프레임워크는 블랙박스 프레임워크로 발전하는 경향이 있으며, 블랙박스 프레임워크는 시스템 개발이 달성하고자 하는 이상적인 목표이기도 합니다.

오늘날 인터넷에 떠도는 수많은 CSS 프레임워크를 되돌아보겠습니다. (YUI는 "YUI CSS Frameworks"가 아니라 "YUI Library CSS Tools"라고 합니다.) 그 중 실제로 얼마나 많은 프레임워크가 프레임워크 개념으로 작성되어 있는지 살펴보겠습니다. , 스타일 기본 클래스는 몇 개입니까? 물론, 프레임워크에 대한 모든 사람의 이해가 동일하지 않을 수도 있고, 제가 말하는 내용에 동의하지 않을 수도 있습니다.

CSS 프레임워크에 대해 다시 말씀드리자면, 제가 이런 것의 존재를 인식하지 못한 것은 아닙니다. 1~2년 전부터 그런 일을 해왔습니다. 대규모 웹사이트의 경우 프런트엔드 개발에는 솔루션이 필요합니다. 당연히 프레임워크가 첫 번째 선택입니다. 너무 멀어서 아쉽다, 너무 약하다ㅜㅜㅜㅜ 포인트는 딱 2개만 있으면 된다:

아래 컨텐츠 관리할 것들
클래스/컴포넌트
당연히 첫 번째 포인트 CSS는 할 수 없다는 점입니다. 두 번째로, 다른 언어에 비해 매우 약합니다.

약 1년 전 중형 웹사이트를 만들 때, 게을러지기 위해 콘텐츠를 모듈화하고 프로그래머들이 페이지를 구성하게 하려고 생각했습니다. 일반적인 방향은 기능 블록을 하나씩 캡슐화하는 것입니다. 프로그래머는 어떤 콘텐츠를 사용하려고 할 때에만 해당 페이지를 작성하고 싶지 않습니다. 코드를 반복할 필요가 없습니다. 안녕하세요 여러분. 정말 좋습니다.

동일한 웹사이트에서는 유사한 콘텐츠 블록이 여러 번 사용되는 것이 일반적이며, 이는 사진 목록, 사용자 아바타 목록, 그룹 아이콘 등의 모듈화도 가능하게 합니다. 지금 이 시간에 쓰시겠어요? 같은게 이렇게 쓰이나요?

　.photoListUesr,.photoListGroup{ /*_*/ }

　 불가능하다는 뜻은 아니지만, 갑자기 비슷한 것을 추가하고 싶다면? 이때 스타일을 조정해야 할 수도 있습니다. 그리고 나는 어떻습니까? 이런 식으로 사용해 보았습니다.

이 경우 처음부터 공통 표현식을 분리하고 .photoList를 프로토타입으로 사용하고 추가 클래스를 통해 세부 사항을 처리합니다. 며칠 전에는 객체지향 XHTML과 CSS 프로그래밍에 대해 글을 썼습니다. 사실 나머지 절반은 상세한 예제였지만, 너무 많은 예제를 작성해야 했기 때문에 끝내지 못했습니다. ^^ 물론 이것도 몇 가지 문제가 있습니다. 즉, 초기 프로토타입의 정의는 매우 신중해야 하며, 향후에 수정되더라도 그럴 필요가 없도록 노력해야 합니다. 수정되었습니다. CSS를 사용하면 기본적으로 프레임워크는 최대 하나의 웹 사이트에만 적합할 수 있습니다. 물론 웹 사이트가 충분히 크면 이 방법을 사용하는 것이 합리적입니다.

HTML과 CSS가 모듈화될수록 파일이 분산되어 문제가 더욱 심각해집니다. HTML은 응용 프로그램이 결국 하나의 복사본을 병합하고 출력하므로 처리하기 쉽지만 CSS는 일반적으로 폐기되고 직접 사용됩니다. 지금의 예에서 CSS를 웹 페이지로 가져오는 방법은 다음과 같습니다.

　@import url(/xxx/photoList.css);
　@import url(/xxx/UserCt. css);
　 @import url(/xxx/GroupCt.css);

그런 다음 프로그램을 사용하여 페이지를 결합하는 것을 고려할 수도 있지만 사용하기 쉽고 요청 수에 비례합니다. 일반적으로 모든 사람은 파일을 수동으로 병합하도록 선택합니다. 인간의 두뇌는 컴퓨터보다 지능이 뛰어나지만, 많은 경우 인간 두뇌의 컴퓨팅 능력은 컴퓨터만큼 좋지 않습니다. CSS 릴리스 메커니즘을 처리하기 위해 서버 측 프로그램을 사용하는 아이디어가 있었던 적이 있습니다. 일반적인 방향은 웹 사이트 액세스 로그를 통해 전체 사이트의 다양한 페이지 사용을 분석하고 프로그램을 사용하여 어떤 대중이 사용하는지 계산하는 것입니다. 순서(CSS 파일의 순서가 우선순위에 영향을 미칩니다) 등 다양한 계산 및 압축된 출력이 필요합니다.

불행하게도 이러한 복잡한 프로그램은 하나의 사이트 또는 동일한 시리즈의 사이트 그룹에만 적합할 수 있습니다. 조금 번거롭기는 하지만 포털 수준의 웹사이트에서는 이 방법을 사용해야 한다고 생각합니다. 물론 팀 전체가 동일한 디자인 패턴을 사용해야 한다는 전제가 있습니다.

추신: 위의 CSS 퍼블리싱 프로그램은 아직 시도해보지 않았습니다. 관심 있는 친구가 시도해 볼 수 있습니다. 사고가 발생하면 책임을 지지 않습니다.

물론 위의 내용은 CSS 프레임워크라고 할 수 없으며 아마도 시스템 수준의 솔루션이라고만 할 수 있을 것입니다. 결국 CSS는 설명적인 언어일 뿐입니다.

어젯밤 Yueying과 오리구이를 먹다가 이에 대해 이야기를 나눴는데 Yueying이 나에게 통합 프런트 엔드 솔루션이 있는지 물었습니다. JS가 컴포넌트화될 때에도 동일한 문제가 발생하며 유사한 게시 메커니즘이 JS에도 적용되어야 합니다. 하지만 아직 완전히 통합된 솔루션을 찾지 못했을 수도 있습니다. 아마도 Yueying이 저에게 몇 번 더 오리 구이를 해줄 것이고 제가 알아낼 수 있을 것입니다.

이상은 CSS 프레임워크에 대한 논의입니다. 더 많은 관련 글은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!