동적 (서버 측 생성) CSS를 사용하지 않는 이유는 무엇입니까?

서버 측에서 생성 된 HTML은 사소한 것이기 때문에 (그리고 AJAX 이전에 동적 웹 페이지를 만드는 유일한 방법 이었으므로) 서버 측에서 생성 된 CSS 는 그렇지 않습니다. 실제로, 나는 그것을 본 적이 없다. CSS 컴파일러가 있지만 정적으로 사용할 수있는 CSS 파일을 생성합니다.

기술적으로 특별한 라이브러리가 필요하지 않으며 HTML 스타일 태그는 정적 CSS 파일 대신 PHP (/ ASP / whatever) 템플릿 프로그램 스크립트를 참조해야하며 스크립트는 CSS 컨텐츠 유형 헤더를 보내야 합니다.

캐시 문제가 있습니까? 나는 그렇게 생각하지 않습니다. 스크립트는 no-cache 등의 헤더를 보내야합니다 . 디자이너에게 문제가 있습니까? 아니요, HTML 템플릿을 편집 할 때 CSS 템플릿을 편집해야합니다.

동적 CSS 생성기를 사용하지 않는 이유는 무엇입니까? 또는 있다면 알려주세요.

CSS가 동적으로 거의 생성되지 않는 가장 큰 이유는 캐싱에 적합한 후보이기 때문입니다. CSS는 클래스를 올바르게 조합하여 페이지를 스타일링 할 수있는 매우 유연한 방법으로, 모든 종류의 단서에 따라 스타일이 지정된 다양한 페이지의 다른 부분을 모두 얻을 수 있습니다. 이 페이지 뷰에 실제로 어떤 일이 발생하는지에 대해

CSS는 페이지마다 다를 필요 가 없기 때문에 다운로드 비용을 최적화하는 매우 일반적인 관행으로 이어집니다. 대부분의 사이트는 전체 사이트에 대한 모든 CSS를 한 번의 다운로드로 작성하므로 다른 페이지보기에 적용되는 부분은 하나의 다운로드 된 파일에만 존재합니다. 캐싱을 사용하면 클라이언트가 두 번째 다운로드를 기다릴 필요가 없습니다. 더 중요한 것은 컨텐츠 제공자로서 컨텐츠 업로드 비용을 두 번 이상 지불하지 않아도된다는 것입니다. 정적 컨텐트를 제공하는 데 더 적합한 서버에 정적 CSS를 배치하여 애플리케이션 서버의 실제 동적 컨텐트에 대한 리소스를 확보 할 수도 있습니다.

이 관행은 매우 일반적이므로 많은 브라우저 는 CSS가 정적 이라고 가정 합니다. 하고 있습니다 매우 그들은 이미 다운로드 CSS에 주저; 사용자가 페이지를 다시로드하더라도 이 특수 처리는 CSS에만 적용됩니다. 다른 컨텐츠 유형은 예상대로 다시로드됩니다.

마지막 프로젝트에서 응용 프로그램은 ajax 가로 드 한 서버 생성 CSS를 사용하고 있다고 생각합니다 (보고 있는지도의 위치에 따라 페이지는 완전히 다른 스타일로 표시되어 있기 때문입니다).

그러나 ajax로 추가 CSS를 검색하여 문제를 해결하는 사용 사례는 매우 드물기 때문에 이런 상황이 발생하지 않을 수 있습니다. 일반적으로 배치시 사전 처리되고 (LESS + 축소) 사전 처리되고 캐시 가능한 ( 예를 들어 다음 페이지는 이전에 캐시 한 스타일 시트를 다시 사용할 수 있으므로 초기 시간이 더 짧습니다.

실제로 동적 CSS의 사용 사례가 있습니다. 나는 세 가지 다른 종류로 작업했습니다.

1. Less — Less CSS는 기본적으로 "변수, 믹스 인, 연산 및 함수와 같은 동적 동작"을 추가하는 CSS 언어 확장입니다. 또한 "중첩 규칙"을 허용하므로 매우 편리합니다. 필자는 일부 반복을 제거하여 CSS 작성을 덜 장황하게 만들기 위해 주로 Less를 사용했습니다.

2. URL 재 작성 — 캐시 문제가 없다는 진술의 증거로 PHP를 사용하여 스크립트를 올바른 캐시 헤더가있는 CSS 파일로 오랫동안 제공했습니다. 나는 주로 웹 루트에없는 라이브러리의 CSS 파일을 제공하기 위해이 작업을 수행합니다.

3. 동적 보고서 — 내가 작업 한 한 프로젝트에서 시스템의 모든 종류의 데이터에 대한 보고서 작성기가있었습니다. style보고서 작성기에서 사용자가 선택한 색상에 대한 동적 스타일 규칙을 태그 (내부 언급 한대로)로 출력 합니다.

^{참고 : CSS를 URL에 직접 출력 하거나 ( 1 또는 2 와 같이 ) 스크립트에서 이미 생성중인 페이지에 포함시키지 않으면 정적 컨텐츠를 제공하는 것보다 서버에 상당한로드가 추가됩니다. 따라서 트래픽이 상당한 경우 매번 동적으로 수행 할 수 있지만 사용 사례에서 허용하는 경우 정적 파일로 캐시하려고합니다 .}

그러나 왜 더 일반적이지 않습니까? CSS가 실제로 콘텐츠를 출력하도록 구축되지 않은 한 가지 주요 이유가 있다고 생각합니다. 따라서 큰 필요는 없습니다. 우리가했던 것처럼 사용자가 선택한 동적 색상 또는 배경 이미지를 출력하는 것 외에도 (이미지가 content 인 경우 img태그 를 사용하는 것이 좋습니다 ), 동적으로 수행해야 할 다른 작업은 무엇입니까?

대부분의 동적 스타일 변경은 다른 정적 CSS 문서를 참조하여 생성 할 수 있습니다 .

생각했던 것처럼 확실히 가능하지만 그렇게해야 할 이유는 많지 않습니다.

CSS를 동적으로로드하는 데는 두 가지 측면이 있습니다 ...

1. 서버에서 동적으로 CSS 파일 생성

   이것은 매우 간단하며 많은 웹 사이트가이를 수행합니다. 일부 조건에 따라 CSS를 변경하는 경우 유용합니다. 예를 들어, 사용자의 지리적 위치에 따라 사이트 테마를 선택하는 경우

2. JS 스크립트 로더를 통해 요청시 CSS 파일로드

   DOM의 큰 부분을 동적으로 만든 다음 필요한 스타일을로드하는 경우 유용 할 수 있습니다. 그러나 LABjs의 저자는 다음과 같이 말합니다.

   동적으로로드 된 CSS 파일의로드가 완료되었는지 확인하는 것은 실제로 매우 복잡하고 크로스 브라우저를 수행하는 데 어려움이 있습니다. "로드"이벤트는 원하는대로 예상되지 않습니다. 이러한 지원을 추가하면 LABjs에 사소한 크기가 추가됩니다.

1. 우리는 이것을한다. 항상. 특히 색상 등이 데이터베이스에서 나오는 SaaS 애플리케이션의 고객 별 브랜딩과 같은 경우.
2. 배포 전이나 배포 중 또는 응용 프로그램이 부팅 단계 인 경우 응용 프로그램을 부팅하는 동안 CSS를 미리 생성하는 것이 사용자 관점에서 훨씬 빠릅니다. 일반적으로 가능할 때마다 정적 CSS 파일을 미리 생성하는 것이 좋습니다.
3. 사용자의 관점에서 최대 속도를 얻으려면 정적 CSS 파일을 CDN으로 전달하고 브라우저가 응용 프로그램 서버가 아닌 CDN에서 파일을 가져 오는 것이 가장 좋습니다. 이는 일반적으로 CSS 파일을 배포 전 또는 배포 중에 미리 생성 할 수 있고 배포의 일부가 미리 생성 된 정적 CSS 파일을 CDN으로 전달하는 경우에만 가능합니다. CDN은 이제 매우 저렴하고 사용하기 쉽습니다. Amazon CloudFront 및 Rackspace의 Cloud Files를 확인하십시오.

캐시 문제가 있습니까? 나는 그렇게 생각하지 않습니다. 스크립트는 no-cache 등을 보내야합니다.

모두 매우 훌륭하지만 페이지를로드 할 때마다 사용자에게 다운로드하도록 요청하는 일반적으로 정적 인 정보입니다. 따라서 그럴만한 이유가 더 낫습니다.

이제 그 이유는 무엇입니까?

다양한 매개 변수를 기반으로 스타일을 변경하려면 여러 스타일 시트가 있고 HTML을 생성하여 올바른 스타일을 다운로드하면됩니다.

동적 CSS는 매우 사소하지만 응용 프로그램이 더 제한적 임에도 불구하고 (정적 스타일 시트를 사용하여 동적으로 생성 된 HTML이 대부분의 일상적인 요구를 해결하고 CSS 자체가 반동적을 달성하기위한 몇 가지 메커니즘을 통합하는 방법 참조) 많은 경우에 사용되는 것을 보았고 필요할 때마다 직접 사용합니다.

종종 '동적'부분은 여러 스타일 시트를 하나로 결합하고 (HTTP 요청 수를 줄이기 위해) 축소 (대역폭 사용을 줄이기 위해)하지만 변수 대체와 같은 간단한 것 (예 : 전체에 사용되는 색상에 대한 변수 사용) 스타일 시트)는 당신의 인생을 훨씬 쉽게 만들 수 있습니다. 그러나 CSS에는 약간의 경고가있는 상당히 간단한 구문이 있기 때문에 일반적으로 범용 텍스트 처리 시스템이나 PHP와 같은 스크립팅 언어로 충분합니다. 따라서 많은 상용 CSS 처리 시스템이 보이지 않습니다.

어쩌면 당신은 그들을 인식하지 않고 야생에서 그들을 보았을 것입니다. 동적 스크립트를 보내는 서버는 일반적으로 URL 재 작성을 사용하여 URL을 정적으로 제공되는 내용과 구별 할 수 없게합니다. 이는 일부 브라우저 (주로 IE)가 특정 상황에서 올바른 MIME 유형 감지를 위해 확장을 사용하여 전송 한 Content-Type 헤더를 무시 (또는 무시)하기 때문에 필요합니다.

캐싱 관련 : 스타일 시트는 GET 요청과 함께 가져와 캐시 가능하게 만드는 것이 적절한 사용자 경험에 절대적으로 중요합니다. 요청이있을 때마다 스타일 시트를 다시 다운로드 할 때 페이지 리플 로우를보고 싶지는 않습니다. 대신 스타일 시트 처리의 출력을 변경하는 모든 매개 변수를 쿼리 문자열에 넣어야합니다. 다른 쿼리 문자열은 다른 URL을 생성하여 캐시 누락이 발생하므로 매개 변수가 변경 될 때마다 클라이언트가 모든 것을 캐시하더라도 스타일 시트가 다시 다운로드됩니다. 각 요청마다 잠재적으로 다르고 부작용에 의존하는 CSS가 실제로 필요한 경우 비 동적 부분을 정적으로 제공되는 스타일 시트에 배치하고 동적으로 절대적으로 필요한 항목 만 제공하십시오.

동적 CSS를 사용하고 싶었던 몇 가지 시나리오가 있지만 CSS 기본 사항을 이해하는 데 약간의 도움이 필요한 디자이너를 사용하는 경우가 종종 있습니다. 믹스에서 동적 언어를 던지면 실제로 폭발 할 수 있습니다.

이것을 볼 수있는 또 다른 방법은 "다른 사람이 실제로 내 문제가 아닌 고통스러운 모든 수동 작업을 수행하는 것입니다."