Grupa Robocza CSS w TPAC: Co nowego w CSS?

Opublikowany: 2022-03-10
Szybkie podsumowanie ↬ W zeszłym tygodniu Rachel Andrew wzięła udział w spotkaniu Grupy Roboczej CSS w W3C TPAC i podsumowuje niektóre dyskusje w tym poście — w tym te, w których możesz pomóc w podjęciu decyzji.

W zeszłym tygodniu uczestniczyłem w spotkaniu W3C TPAC oraz CSS Working Group tam. Wprowadzono różne zmiany w specyfikacjach i przeprowadzono dyskusje, które moim zdaniem są interesujące dla projektantów i programistów stron internetowych. W tym artykule wyjaśnię trochę, co dzieje się w TPAC, i pokażę kilka przykładów i dem rzeczy, które omawialiśmy w TPAC, w szczególności dla CSS.

Co to jest TPAC?

TPAC to Tydzień Posiedzeń Plenarnych Technicznych / Komitetów Doradczych W3C. Szansa dla wszystkich różnych grup roboczych, które są częścią W3C, by zebrać się pod jednym dachem. Impreza odbywa się co roku w innej części świata, w tym roku odbyła się w Lyonie we Francji. W TPAC grupy robocze, takie jak CSS Working Group, mają swoje własne spotkania, tak jak my w innych porach roku. Ponieważ jednak wszyscy znajdujemy się w jednym budynku, oznacza to, że osoby z innych grup mogą łatwiej przychodzić jako obserwatorzy i można dyskutować o interesach grup współpracujących.

Uczestnicy TPAC są zazwyczaj członkami jednej lub więcej Grup Roboczych, pracujących nad technologiami W3C. Będą to przedstawiciele organizacji członkowskiej lub Zaproszeni Eksperci. Podobnie jak w przypadku innych spotkań Grup Roboczych W3C, protokoły wszystkich dyskusji odbywających się w TPAC będą dostępne publicznie, zwykle w postaci dzienników IRC spisywanych podczas spotkań.

Grupa Robocza CSS

Grupa Robocza CSS spotyka się twarzą w twarz w TPAC i przy co najmniej dwóch innych okazjach w ciągu roku; jest to dodatek do naszych cotygodniowych rozmów telefonicznych. Na wszystkich naszych spotkaniach omawiane są różne kwestie poruszone w specyfikacjach i podejmowane są decyzje. Niektóre kwestie są przeznaczone do dyskusji twarzą w twarz ze względu na korzyści płynące z możliwości ich z całą grupą lub po prostu z możliwości poruszania się po tablicy lub oglądania demonstracji na ekranie.

Gdy problem jest omawiany na jakimkolwiek spotkaniu (bez względu na to, czy jest to bezpośrednie, czy telekonferencja), odpowiedni problem GitHub jest aktualizowany protokołem dyskusji. Oznacza to, że jeśli masz problem, który chcesz śledzić, możesz go oznaczyć gwiazdką i zobaczyć, kiedy zostanie zaktualizowany. Pełne protokoły IRC są również wysyłane na listę dyskusyjną w stylu www.

Oto wybór omawianych przez nas rzeczy, które moim zdaniem będą dla Ciebie najbardziej interesujące.

Więcej po skoku! Kontynuuj czytanie poniżej ↓

Paski przewijania CSS

Specyfikacja CSS Scrollbars ma na celu dostarczenie standardowego sposobu stylizacji rozmiaru i koloru pasków przewijania. Jeśli masz Firefox Nightly, możesz go przetestować. Aby zobaczyć poniższe przykłady, użyj Firefox Nightly i włącz flagi layout.css.scrollbar-width.enabled i layout.css.scrollbar-color.enabled , odwiedzając https://about:config w Firefox Nightly.

Specyfikacja daje nam dwie nowe właściwości: scrollbar-width i scrollbar-color . Właściwość scrollbar-width może przyjmować wartość auto , thin , none lub length (na przykład 1em ). Wygląda na to, że wartość length może zostać usunięta ze specyfikacji. Jak możesz sobie wyobrazić, programista mógłby stworzyć bardzo bezużyteczny pasek przewijania, bawiąc się szerokością, więc może lepiej pozwolić przeglądarce decydować o dokładnej szerokości, która ma sens, ale zamiast tego wyświetlać cienkie lub grube paski przewijania. Firefox nie zaimplementował opcji długości.

Jeśli użyjesz auto jako wartości, przeglądarka użyje domyślnych pasków przewijania: thin da ci cienki pasek przewijania, a none nie pokaże żadnego widocznego paska przewijania (ale element nadal będzie przewijalny).

Element przewijający z cienkim paskiem przewijania
W tym przykładzie ustawiłem scrollbar-width: thin .(duży podgląd)

W przeglądarce obsługującej paski przewijania CSS możesz zobaczyć to w akcji w demo:

Zobacz Pen CSS Scrollbars: scrollbar-width autorstwa Rachel Andrew (@rachelandrew) na CodePen.

Zobacz Pen CSS Scrollbars: scrollbar-width autorstwa Rachel Andrew (@rachelandrew) na CodePen.

Właściwość scrollbar-color dotyczy — jak można się spodziewać — kolorów paska przewijania. Pasek przewijania składa się z dwóch części, które możesz chcieć pokolorować niezależnie:

  • kciuk
    Suwak poruszający się w górę i w dół podczas przewijania.
  • tor
    Tło paska przewijania.

Wartości właściwości scrollbar-color to auto , dark , light i <color> <color> .

Użycie auto jako wartości słowa kluczowego zapewni domyślne kolory paska przewijania dla tej przeglądarki, dark zapewni ciemny pasek przewijania, w trybie ciemnym tej platformy lub niestandardowym trybie ciemnym, light tryb jasny platformy lub niestandardowy tryb światła .

Aby ustawić własne kolory, dodaj dwa kolory jako wartość, które są oddzielone spacją. Pierwszy kolor zostanie użyty do kciuka , a drugi do ścieżki . Należy zadbać o wystarczający kontrast między kolorami, w przeciwnym razie dla niektórych osób pasek przewijania może być trudny w użyciu.

Element przewijający z fioletowym i białym paskiem przewijania
W tym przykładzie ustawiłem niestandardowe kolory dla elementów paska przewijania. (duży podgląd)

W przeglądarce obsługującej paski przewijania CSS możesz zobaczyć to w demo:

Zobacz Pen CSS Scrollbars: scrollbar-color autorstwa Rachel Andrew (@rachelandrew) na CodePen.

Zobacz Pen CSS Scrollbars: scrollbar-color autorstwa Rachel Andrew (@rachelandrew) na CodePen.

Jednostki proporcji

Od jakiegoś czasu używamy chwytu dopełniającego w CSS, aby uzyskać pola proporcji, jednak wraz z pojawieniem się Grid Layout i lepszymi sposobami zmiany rozmiaru treści, posiadanie prawdziwego sposobu na robienie proporcji w CSS stało się bardziej palącą potrzebą .

W serwisie GitHub pojawiają się dwa problemy, które odnoszą się do tego wymagania:

  • Potrzebne jednostki proporcji
  • Współczynnik proporcji.

Jest teraz szkic specyfikacji na poziomie 4 CSS Sizing, a decyzja spotkania była taka, że ​​wymaga to dalszej dyskusji na GitHubie przed podjęciem jakichkolwiek decyzji. Tak więc, jeśli jesteś tym zainteresowany lub masz dodatkowe przypadki użycia, Grupa Robocza CSS będzie zainteresowana Twoimi komentarzami w tych kwestiach.

Pseudoklasa funkcjonalna :where()

W zeszłym roku CSSWG zdecydowało się dodać pseudoklasę, która działała jak :matches() , ale z zerową specyficznością, co ułatwia nadpisanie bez konieczności sztucznego zawyżania specyficzności późniejszych elementów w celu nadpisania czegoś w domyślnym arkuszu stylów.

Pseudoklasa :matches() może być dla Ciebie nowa, ponieważ jest selektorem poziomu 4, jednak pozwala określić grupę selektorów, do których chcesz zastosować kod CSS. Na przykład możesz napisać:

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

Lub za pomocą :matches()

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

Jeśli kiedykolwiek miałeś duży stos selektorów tylko po to, aby ustawić te same zasady, zobaczysz, jak przydatne będzie to. Poniższy CodePen używa przedrostków nazw webkit-any i -moz-any , aby zademonstrować funkcjonalność match matches() . Możesz również przeczytać więcej o match() na MDN.

Zobacz Pen :matches() i wersje z prefiksem autorstwa Rachel Andrew (@rachelandrew) na CodePen.

Zobacz Pen :matches() i wersje z prefiksem autorstwa Rachel Andrew (@rachelandrew) na CodePen.

Tam, gdzie często robimy tego rodzaju układanie selektorów, a więc gdzie :matches() będzie najbardziej przydatne, jest jakiś początkowy, domyślny arkusz stylów. Musimy jednak zachować ostrożność podczas nadpisywania tych wartości domyślnych, aby wszelkie nadpisywanie odbywało się w sposób, który zapewni, że będzie bardziej szczegółowe niż wartości domyślne. Z tego powodu zaproponowano wersję o zerowej specyficzności.

Kwestia, która była omawiana na spotkaniu, dotyczyła nazewnictwa tej pseudo-klasy, ostateczne rozwiązanie można zobaczyć tutaj, a jeśli zastanawiasz się, dlaczego wykluczono różne nazwy, zajrzyj do pełnego wątku. Nazywanie rzeczy w CSS jest bardzo trudne — ponieważ wszyscy będziemy musieli z tym żyć na zawsze! Po długiej debacie grupa głosowała i postanowiła nazwać ten selektor :where() .

Od czasu spotkania i podczas pisania tego posta pojawiła się sugestia zmiany nazwy matches() na is() . Przyjrzyj się problemowi i skomentuj, jeśli masz jakieś silne uczucia!

Logiczne skróty dla marginesów i dopełnienia

Jeśli chodzi o nazewnictwo rzeczy, pisałem o właściwościach i wartościach logicznych tutaj w Smashing Magazine w przeszłości, spójrz na „Zrozumienie właściwości i wartości logicznych”. Te właściwości i wartości zapewniają mapowanie względne przepływu. Oznacza to, że jeśli używasz trybów pisania innych niż poziomy tryb pisania od góry do dołu, takich jak angielski, rzeczy takie jak marginesy i dopełnienie, szerokość i wysokość są zgodne z kierunkiem tekstu i nie są powiązane z fizycznymi wymiarami ekranu.

Na przykład dla fizycznych marginesów mamy:

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

Logiczne mapowania dla nich (zakładając poziome-tb) to:

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

Możemy mieć dwa skróty wartości. Na przykład, aby ustawić zarówno margin-block-start jak i margin-block-end jako skrót, możemy użyć margin-block: 20px 1em . Pierwsza wartość reprezentująca krawędź początkową w wymiarze blokowym, druga wartość to krawędź końcowa w wymiarze blokowym.

Natrafiamy jednak na problem, gdy dochodzimy do czterowartościowego margin skróconego . Ta nazwa właściwości jest używana dla fizycznych marginesów — jak mamy oznaczyć logiczną czterowartościową wersję? Zasugerowano różne rzeczy, w tym przełącznik na górze pliku:

 @mode "logical";

Lub użyj bloku, który wygląda trochę jak zapytanie o media:

 @mode (flow-mode: relative) { }

Następnie różne sugestie modyfikatorów słów kluczowych, użycie znaków interpunkcyjnych lub utworzenie zupełnie nowej nazwy właściwości:

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

Możesz przeczytać numer, aby zobaczyć różne rzeczy, które są brane pod uwagę. Omawiane kwestie polegały na tym, że chociaż wersja logiczna może być ogólnie domyślna, czasami będziesz chciał, aby rzeczy odnosiły się do geometrii ekranu; musimy mieć obie opcje w jednym arkuszu stylów. Posiadanie ustawienia @mode na górze CSS może być mylące; zawiedzie, jeśli ktoś skopiuje i wklei fragment arkusza stylów.

Preferuję mieć jakąś wartość słowa kluczowego. W ten sposób, jeśli spojrzysz na regułę, możesz dokładnie zobaczyć, który tryb jest używany, nawet jeśli wydaje się nieco nieelegancki. Jest to rodzaj rzeczy, z którymi może sobie poradzić preprocesor; jeśli rzeczywiście chcesz, aby wszystkie twoje właściwości i wartości używały wersji logicznych.

Nie udało nam się rozwiązać tego problemu, więc jeśli zastanawiasz się, które z nich mogą być najlepsze, lub widzisz problemy z nimi, których nie opisaliśmy, skomentuj problem w serwisie GitHub.

Dyskusja na temat testów platformy internetowej

Na spotkaniu Grupy Roboczej CSS, a następnie podczas niekonferencyjnego Dnia Plenarnego Technicznego zajmowałem się dyskusją o tym, jak zaangażować więcej osób w pisanie testów dla specyfikacji CSS. Projekt Web Platform Tests ma na celu zapewnienie testów dla całej platformy internetowej. Testy te następnie pomagają dostawcom przeglądarek sprawdzić, czy ich przeglądarka jest poprawna pod względem specyfikacji. Celem Grupy Roboczej CSS jest, aby każdej normatywnej zmianie specyfikacji, która osiągnęła status Rekomendacji Kandydata (CR), towarzyszył test. Ma to sens, ponieważ gdy specyfikacja jest już w CR, prosimy przeglądarki o zaimplementowanie tej specyfikacji i przekazanie opinii. Muszą wiedzieć, czy coś w specyfikacji się zmieni, aby mogli zaktualizować swój kod.

Problem polega na tym, że niewiele osób pisze specyfikacje, więc konieczność pisania wszystkich testów przez autorów specyfikacji spowolni postęp CSS. Chcielibyśmy zobaczyć, jak inni ludzie piszą testy, ponieważ jest to sposób na wniesienie wkładu w platformę internetową i zdobycie głębokiej wiedzy na temat działania specyfikacji. Spotkaliśmy się więc, aby zastanowić się, jak możemy zachęcić ludzi do udziału w wysiłkach. Pisałem na ten temat w przeszłości; jeśli interesuje Cię pomysł pisania testów na platformę, zajrzyj do mojego artykułu 24 Ways pt. „Testowanie platformy internetowej”.

Kontynuuj pracę!

TPAC znacznie dodał do mojej osobistej listy rzeczy do zrobienia. Udało mi się jednak zebrać wskazówki dotyczące edycji specyfikacji, pisania testów i opracować plan uzyskania specyfikacji Multi-Column Layout — której jestem współredaktorem — z powrotem do statusu CR. Jako ktoś, kto nie jest fanem spotkań, przekonałem się, jak cenne są te spotkania twarzą w twarz dla platformy internetowej, dając tym z nas, którzy w nią uczestniczą, szansę podzielenia się wiedzą, którą indywidualnie rozwijamy. Uważam jednak, że ważne jest, aby następnie wziąć tę wiedzę i podzielić się nią poza grupą, aby pomóc większej liczbie osób zaangażować się w rozwój i korzystanie z platformy.

Jeśli interesuje Cię, jak funkcjonuje CSS Working Group i jak wymyśla się nowy CSS i trafia do przeglądarek, obejrzyj moją prezentację CSSConf.eu z 2017 r. „Skąd pochodzi CSS?” oraz informacje z fantasai w jej postach „An Inside View of the CSS Working Group at W3C”.