TPAC의 CSS 작업 그룹: CSS의 새로운 기능은 무엇입니까?

지난주에 저는 W3C TPAC와 CSS Working Group 회의에 참석했습니다. 사양이 다양하게 변경되었으며 웹 디자이너와 개발자가 관심을 가질 만한 토론이 있었습니다. 이 기사에서는 TPAC에서 일어나는 일에 대해 조금 설명하고 특히 CSS에 대해 TPAC에서 논의한 것들의 일부 예와 데모를 보여줍니다.

TPAC이란 무엇입니까?

TPAC는 W3C의 기술 총회/자문 위원회 회의 주간입니다. W3C의 일부인 다양한 작업 그룹이 한 지붕 아래 함께 모일 수 있는 기회입니다. 매년 세계 각지에서 열리는 이 행사는 올해 프랑스 리옹에서 개최됐다. TPAC에서는 CSS 워킹 그룹과 같은 워킹 그룹이 연중 다른 시간과 마찬가지로 자체 회의를 합니다. 그러나 우리는 하나의 건물에 있기 때문에 다른 그룹의 사람들이 옵서버로서 쉽게 제공 될 수 있고 교차 근로 그룹 이익을 논의 할 수 있음을 의미합니다.

TPAC 참석자는 일반적으로 W3C 기술에 대해 작업하는 하나 이상의 작업 그룹의 구성원입니다. 그들은 회원 조직의 대표이거나 전문가를 초대합니다. W3C 실무 그룹의 다른 회의와 마찬가지로 TPAC에서 보유한 모든 토론의 분은 대개 회의 중에 IRC 로그가 스크라이브 된 IRC 로그로 공개적으로 사용할 수 있습니다.

CSS 작업 그룹

CSS 워킹 그룹은 TPAC에서 그리고 연중 최소 2번의 다른 기회에 대면합니다. 이것은 우리의 주간 전화 통화에 추가됩니다. 모든 회의에서 사양에 대해 제기된 다양한 문제가 논의되고 결정이 내려집니다. 일부 문제는 전체 그룹과 함께 토론할 수 있거나 모두가 화이트보드를 둘러보거나 화면에서 데모를 볼 수 있다는 이점 때문에 대면 토론을 위해 보관됩니다.

어떤 회의에서는 문제가있는 경우 (얼굴 대면 또는 텔레콘인지인지 여부) 관련 GitHub 문제는 토론 분으로 업데이트됩니다. 즉, 추적하려는 문제가 있는 경우 해당 문제에 별표를 표시하고 업데이트 시기를 확인할 수 있습니다. 전체 IRC 회의록은 www 스타일의 메일링 리스트에도 게시됩니다.

다음은 귀하가 가장 관심을 가질 것으로 생각되는 논의 사항입니다.

CSS 스크롤바

CSS Scrollbars 사양은 스크롤바의 크기와 색상을 스타일링하는 표준 방법을 제공하려고 합니다. Firefox Nightly가 있는 경우 테스트할 수 있습니다. 아래 예를 보려면 Firefox Nightly를 사용하고 Firefox Nightly에서 https://about:config 를 방문하여 layout.css.scrollbar layout.css.scrollbar-width.enabled 및 layout.css.scrollbar-color.enabled color.enabled 플래그를 활성화하십시오.

이 사양은 scrollbar-width 및 scrollbar-color 라는 두 가지 새로운 속성을 제공합니다. scrollbar-width 속성은 auto , thin , none 또는 length 값(예: 1em )을 사용할 수 있습니다. length 값이 사양에서 제거될 수 있는 것처럼 보입니다. 상상할 수 있듯이 웹 개발자가 너비를 가지고 놀면서 매우 사용할 수 없는 스크롤바를 만드는 것이 가능하므로 브라우저가 의미가 있는 정확한 너비를 결정하도록 허용하되 대신 가늘거나 두껍게 표시하는 것이 더 나을 수 있습니다. 스크롤바. Firefox는 길이 옵션을 구현하지 않았습니다.

auto 를 값으로 사용하면 브라우저는 기본 스크롤 막대를 사용합니다. thin 은 얇은 스크롤 막대를 제공하고 none 보이지 않는 스크롤 막대를 표시하지 않습니다(그러나 요소는 여전히 스크롤 가능함).

CSS 스크롤바를 지원하는 브라우저의 데모에서 다음과 같이 작동하는 것을 볼 수 있습니다.

scrollbar-color 속성은 예상대로 스크롤 막대 색상을 처리합니다. 스크롤바에는 독립적으로 색칠할 수 있는 두 부분이 있습니다.

• 무지
  스크롤할 때 위아래로 움직이는 슬라이더입니다.
• 길
  스크롤바 배경입니다.

scrollbar-color 속성의 값은 auto , dark , light 및 <color> <color> 입니다.

auto 를 키워드 값으로 사용하면 해당 브라우저의 기본 스크롤 막대 색상이 제공되고 dark 는 해당 플랫폼의 어두운 모드 또는 사용자 정의 어두운 모드에서 어두운 스크롤 막대를 제공하고 플랫폼의 light 모드 또는 사용자 정의 밝은 모드를 밝게 합니다. .

고유한 색상을 설정하려면 공백으로 구분된 두 가지 색상을 값으로 추가합니다. 첫 번째 색상은 엄지손가락 에 사용되고 두 번째 색상은 트랙 에 사용됩니다. 색상 사이의 대비가 충분하도록 주의해야 합니다. 그렇지 않으면 일부 사람들에게는 스크롤바를 사용하기 어려울 수 있습니다.

CSS 스크롤바를 지원하는 브라우저에서 데모에서 이것을 볼 수 있습니다:

종횡비 단위

우리는 얼마 동안 종횡비 상자를 달성하기 위해 CSS에서 패딩 해킹을 사용해 왔습니다. 그러나 Grid Layout의 출현과 더 나은 콘텐츠 크기 조정 방법으로 CSS에서 종횡비를 수행하는 실제 방법을 갖는 것이 더 시급하게 되었습니다. .

이 요구 사항과 관련하여 GitHub에서 두 가지 문제가 제기되었습니다.

• 필요한 화면비 단위
• 종횡비.

이제 CSS 사이징의 레벨 4에서 초안 사양이 있으며 회의의 결정은 결정이 내려지 기 전에 GitHub에 대한 추가 토론이 필요하다는 것입니다. 따라서 이에 관심이 있거나 추가 사용 사례가 있는 경우 CSS 작업 그룹에서 해당 문제에 대한 귀하의 의견에 관심을 가질 것입니다.

:where() 기능적 의사 클래스

작년에 CSSWG는 :matches() 처럼 작동하지만 특이성이 0인 의사 클래스를 추가하기로 결정했습니다. 따라서 기본 스타일시트의 항목을 재정의하기 위해 이후 요소의 특이성을 인위적으로 부풀릴 필요 없이 쉽게 재정의할 수 있습니다.

그러나 :matches() 의사 클래스는 레벨 4 선택기로 새로운 것일 수 있지만 일부 CSS를 적용 할 수있는 선택기 그룹을 지정할 수 있습니다. 예를 들어 다음과 같이 작성할 수 있습니다.

 .foo a:hover, pa:hover { color: green; }

또는 :matches()

 :matches(.foo, p) a:hover { color: green; }

동일한 몇 가지 규칙을 설정하기 위해 선택기를 많이 사용해 본 적이 있다면 이것이 얼마나 유용한지 알게 될 것입니다. 다음 CodePen은 matches() 기능을 보여주기 위해 webkit-any 및 -moz-any 의 접두어 이름을 사용합니다. MDN에서 match()에 대해 자세히 알아볼 수도 있습니다.

여기서 우리는 종종 이런 종류의 선택기를 쌓아두고, :matches() 는 어떤 종류의 초기, 기본 스타일 시트에 가장 유용합니다. 그러나 기본값보다 더 구체적으로 지도록 덮어 쓰기가 수행되는 기본값을 덮어 쓰는 경우를 덮어 쓰면됩니다. 이러한 이유로 제로 특이성 버전이 제안되었습니다.

회의에서 논의된 문제는 이 pseudo-class의 이름을 지정하는 것이었습니다. 여기서 최종 해결 방법을 볼 수 있으며, 다양한 이름이 제외된 이유가 궁금하다면 전체 스레드를 살펴보세요. CSS에서 이름을 지정하는 것은 매우 어렵습니다. 왜냐하면 우리 모두는 CSS와 함께 영원히 살아야 하기 때문입니다! 많은 토론 끝에 이 그룹은 투표를 하고 이 선택자를 :where() 라고 부르기로 결정했습니다.

회의 이후, 그리고 이 게시물을 작성하는 동안 matches() 를 is() 로 이름을 바꾸라는 제안이 제기되었습니다. 문제를 살펴보고 어느 쪽이든 강한 감정이 있으면 의견을 말하십시오!

여백 및 패딩에 대한 논리적 속기

이름 짓는 주제에 대해서는 과거에 여기 Smashing Magazine에 논리적 속성과 가치에 대해 쓴 적이 있습니다. "논리적 속성과 가치 이해하기"를 살펴보세요. 이러한 속성과 값은 흐름 상대 매핑을 제공합니다. 즉, 영어와 같이 수평 위에서 아래로 쓰기 모드 이외의 쓰기 모드를 사용하는 경우 여백 및 패딩, 너비 및 높이와 같은 항목이 텍스트 방향을 따르고 실제 화면 크기에 연결되지 않습니다.

예를 들어 물리적 여백의 경우 다음이 있습니다.

• margin-top
• margin-right
• margin-bottom
• margin-left

이들에 대한 논리적 매핑(horizontal-tb 가정)은 다음과 같습니다.

• margin-block-start
• margin-inline-end
• margin-block-end
• margin-inline-start

우리는 두 가지 가치 속기를 가질 수 있습니다. 예를 들어 margin-block-start 와 margin-block-end 를 모두 속기로 설정하려면 margin-block: 20px 1em 을 사용할 수 있습니다. 첫 번째 값은 블록 치수의 시작 모서리를 나타내고 두 번째 값은 블록 치수의 끝 모서리를 나타냅니다.

그러나 4가지 값의 약식 margin 에 관해서 문제가 있습니다. 그 속성 이름은 물리적 여백에 사용됩니다. 논리적 4값 버전을 어떻게 표시합니까? 파일 맨 위에 있는 스위치를 포함하여 다양한 제안이 있습니다.

 @mode "logical";

또는 미디어 쿼리처럼 보이는 블록을 사용하려면:

 @mode (flow-mode: relative) { }

그런 다음 구두점 문자를 사용하거나 완전히 새로운 속성 이름을 만드는 키워드 수정자에 대한 다양한 제안:

 margin: relative 1em 2em 3em 4em; margin: 1em 2em 3em 4em !relative; margin-relative: 1em 2em 3em 4em; ~margin: 1em 2em 3em 4em;

당신은 고려중인 다양한 것들을 보려면 문제를 읽을 수 있습니다. 논리적 인 버전이 일반적으로 기본적으로 끝날 수 있지만 때로는 화면 기하학과 관련된 것들을 원할 것입니다. 하나의 스타일시트에 두 가지 옵션을 모두 가질 수 있어야 합니다. CSS 상단에 @mode 설정이 있으면 혼란스러울 수 있습니다. 누군가가 스타일시트의 덩어리를 복사하여 붙여넣는다면 실패할 것입니다.

내 취향은 일종의 키워드 값을 갖는 것입니다. 그렇게 하면 규칙을 보면 약간 촌스러워 보이더라도 어떤 모드가 사용되고 있는지 정확히 알 수 있습니다. 전처리기가 처리할 수 있는 종류입니다. 모든 속성과 값이 논리적 버전을 사용하기를 정말로 원했다면.

우리는 이 문제를 해결할 수 없었습니다. 따라서 이 중 어느 것이 가장 좋을지 생각이 나거나 설명하지 않은 문제가 있는 경우 GitHub에서 문제에 대해 의견을 말하십시오.

웹 플랫폼 테스트 토론

CSS 워킹 그룹 회의와 비컨퍼런스 스타일의 기술 총회에서 나는 CSS 사양에 대한 테스트 작성에 더 많은 사람들을 참여시키는 방법을 논의하는 데 참여했습니다. 웹 플랫폼 테스트 프로젝트는 모든 웹 플랫폼에 대한 테스트를 제공하는 것을 목표로 합니다. 그런 다음 이러한 테스트는 브라우저 공급업체가 브라우저가 사양에 대해 올바른지 여부를 확인하는 데 도움이 됩니다. CSS 워킹 그룹에서 목표는 후보 권고 (CR) 상태에 도달 한 사양에 대한 규격의 변경 사항이 테스트를 동반해야한다는 것입니다. 사양이 CR에 있으면 브라우저에 해당 사양을 구현하고 피드백을 제공하도록 요청하므로 이는 의미가 있습니다. 코드를 업데이트할 수 있도록 사양에 변경 사항이 있는지 알아야 합니다.

문제는 우리가 사양을 쓰는 사람들이 거의 없기 때문에 사양 작성자가 모든 테스트를 작성 해야하는 것은 CSS의 진행 상황을 늦추는 것입니다. 우리는 웹 플랫폼에 기여하고 사양이 어떻게 작동하는지에 대한 깊은 지식을 얻을 수있는 방법이기 때문에 테스트를 작성하는 다른 사람들을보고 싶습니다. 그래서 우리는 사람들이 노력에 참여하도록 격려할 수 있는 방법에 대해 생각하기 위해 만났습니다. 나는 과거에 이 주제에 대해 쓴 적이 있습니다. 플랫폼에 대한 테스트를 작성하는 아이디어에 관심이 있다면 "웹 플랫폼 테스트"에 대한 24가지 방법 기사를 살펴보세요.

작업과 함께!

TPAC은 내 개인 할 일 목록에 상당히 추가되었습니다. 그러나 나는 사양 편집, 테스트 작성에 대한 팁을 얻을 수 있었고, 내가 공동 편집자인 Multi-Column Layout 사양을 다시 CR 상태로 되돌리기 위한 계획을 세울 수 있었습니다. 회의를 좋아하지 않는 사람으로서 저는 이러한 대면 회의가 웹 플랫폼에 얼마나 가치가 있는지 알게 되었고, 웹 플랫폼에 기여한 사람들에게 우리가 개별적으로 개발 중인 지식을 공유할 수 있는 기회를 제공합니다. 그러나 더 많은 사람들이 플랫폼을 사용하고 개발하는 데 참여할 수 있도록 해당 지식을 그룹 외부에 공유하는 것이 중요하다고 생각합니다.

CSS 작업 그룹이 어떻게 작동하는지, 그리고 새로운 CSS가 어떻게 발명되어 브라우저에서 끝나는지에 관심이 있다면 제 2017 CSSConf.eu 프리젠테이션 "CSS는 어디에서 왔습니까?"를 확인하십시오. 그리고 그녀의 게시물 "An Inside View of the CSS Working Group at W3C"에 있는 fantasai의 정보.