Miriam Suzanne jest autorką, artystką i programistką stron internetowych z Denver w Kolorado. Obecnie pracuje nad ciekawymi specyfikacjami CSS, takimi jak zapytania o kontener i warstwy kaskadowe.
Ten post jest częścią Designcember. To święto projektowania stron internetowych, które przygotowaliśmy dla Ciebie na web.dev.
Miriam Suzanne jest autorką, artystką i programistką stron internetowych z Denver w Kolorado. Jest współzałożycielką OddBird (agencji internetowej), stałą autorką CSS Tricks, członkinią zespołu Sass i zaproszonym ekspertem W3C w grupie roboczej CSS. Ostatnio skupia się na opracowywaniu nowych funkcji CSS, takich jak warstwy kaskadowe, zapytania o kontenery i zakres. Miriam jest autorką powieści, sztuk teatralnych i muzyki. Rozmawialiśmy o jej pracy z Sass i CSS.
Rachel: o Twojej pracy dowiedziałam się po raz pierwszy dzięki siatce Susy. Co Cię skłoniło do jej stworzenia?
Miriam: W 2008 roku układ stron internetowych wyglądał zupełnie inaczej. Deweloperzy odeszli od układu tabeli na rzecz bardziej semantycznych (ale nadal nie do końca poprawnych) siatek z elementami pływającymi. Nastąpił boom na uniwersalne 12-kolumnowe „frameworki siatki”, które zapewniały wstępnie zdefiniowaną (zwykle statyczną) siatkę z zestawem wstępnie zdefiniowanych klas CSS. Jeśli potrzebujesz czegoś bardziej dostosowanego, musisz sobie poradzić sam. Było jasne, że strony internetowe muszą stać się bardziej responsywne, ale zapytania o media nie były jeszcze dostępne i występowało wiele problemów ze zgodnością przeglądarek w przypadku płynnych elementów zmiennoprzecinkowych.
Korzystałem z podejścia CSS Systems Natalie Downe, które sprytnie reagowało na rozmiary czcionek i widocznego obszaru, ale frustrowały mnie powtarzające się obliczenia i obejścia przeglądarki. W tym samym czasie Sass zaczynał zyskiwać popularność i idealnie pasował do moich potrzeb. Pierwsza wersja Susy była bardzo prosta: zawierała tylko kilka miksinów do obliczeń i dodawania potrzebnych mi obejść. Celem było ograniczenie kodu do minimum i wyświetlanie tylko niezbędnych informacji. W pełni konfigurowalne siatki bez wstępnie zdefiniowanych klas.
Rachel: Jak przeszłaś od pracy nad preprocesorem CSS do pracy nad specyfikacjami CSS? Czy uważasz, że praca nad preprocesorem była dobrym przygotowaniem do pisania specyfikacji?
Miriam: z mojego doświadczenia wynika, że te dwie dziedziny w dużej mierze się pokrywają, a ja nadal jestem bardzo aktywna w obu z nich. Myślę jednak, że to w dużej mierze zasługa zespołu Sass, a w szczególności Natalie Weizenbaum, który ma bardzo długoterminową wizję – stara się opracowywać narzędzia, które płynnie integrują się z rozwijającymi się standardami internetowymi. Jeśli myślisz o przyszłości podstawowych standardów internetowych, musisz wyjść poza uniwersalne, „oparte na opiniach” rozwiązania i skupić się na długoterminowej elastyczności.
Jak możemy tworzyć narzędzia, które uwzględniają różnorodność potrzeb i podejść deweloperów, a jednocześnie zachęcają do stosowania ułatwień dostępu i innych ważnych rozwiązań?
Rachel: W CSS pojawia się wiele funkcji, które zastępują te tradycyjnie dostępne w Sass. Czy są jakieś ważne powody, dla których warto nadal używać np. Sass?
Miriam: Tak, w przypadku niektórych osób, ale nie ma tu uniwersalnej odpowiedzi. Weźmy na przykład zmienne. Zmienne Sass mają zakres leksykalny i są kompilowane na serwerze z uporządkowanymi strukturami danych, takimi jak listy i obiekty, manipulacja kolorami itp. Jest to przydatne w przypadku logiki systemu projektowania, która nie musi działać w przeglądarce.
Zmienne CSS mają pewne podobieństwa do zmiennych JavaScript, ponieważ też mogą przechowywać wartości, ale mają zupełnie inne zalety i wady związane z kaskadowością. Sass nie obsługuje właściwości niestandardowych, a CSS nie obsługuje danych strukturalnych. Oba są przydatne i skuteczne, ale Twoje konkretne potrzeby mogą się różnić.
Uważam, że to świetnie, gdy użytkownicy mogą eliminować narzędzia, których już nie potrzebują, a niektóre projekty mogą nie wymagać zmiennych po stronie serwera i klienta. Wszystko wspaniale! Jednak założenie, że są one identyczne i że jedno po prostu zastępuje drugie, jest zbyt uproszczone. Zawsze będą istniały przypadki, w których część logiki projektu będzie wykonywana po stronie serwera, a część po stronie klienta – nawet jeśli języki będą oferować zasadniczo te same funkcje. Przetwórcy wstępni są z nami na dłuższą metę.
Rachel: Czy jest coś, co Cię zaskoczyło, gdy bardziej zaangażowałaś się w tworzenie standardów? Czy jest coś, o czym ludzie mogą nie wiedzieć w związku z tym procesem?
Miriam: zanim zaangażowałam się w ten proces, wydawał mi się tajemniczą i magiczną czarną skrzynką, więc nie wiedziałam, czego się spodziewać. Obawiałem się, że nie mam wystarczającej wiedzy o wewnętrznej budowie przeglądarek, aby wnieść swój wkład, ale w rzeczywistości nie potrzebują oni więcej inżynierów przeglądarek. Potrzebują więcej deweloperów i projektantów, którzy tworzą strony internetowe i aplikacje.
Zaskoczyło mnie, że bardzo niewiele osób zaangażowanych w ten proces skupia się przede wszystkim na standardach, ale też bardzo niewiele z nich zajmuje się głównie tworzeniem lub projektowaniem stron internetowych. W3C składa się z „wolontariuszy” z organizacji członkowskich (często opłacanych przez te organizacje, ale nie jest to ich główne zajęcie), a członkostwo nie jest tanie. To sprawia, że wśród uczestników jest mniej projektantów i deweloperów, którzy na co dzień pracują w małych agencjach lub jako freelancerzy. Moja rola zaproszonego eksperta byłaby całkowicie dobrowolna, a więc drogim hobby, gdybym nie znalazł zewnętrznego finansowania tej pracy.
W rzeczywistości proces ten jest dość otwarty i publiczny oraz wymaga zaangażowania programistów, ale jednocześnie toczy się tak wiele rozmów, że trudno się w nich odnaleźć. Zwłaszcza jeśli nie jest to Twoja praca na pełny etat.
Rachel: Zapytania o kontenery od wielu lat są dla wielu programistów internetowych czymś w rodzaju Świętego Graala. Bardzo się cieszę, że je otrzymamy. Mam wrażenie, że wiele osób zastanawia się nad przydatnością zapytań o kontener. Czy uważasz, że mogą one również zwiększyć kreatywność?
Miriam: Oczywiście, chociaż nie postrzegam ich jako całkowicie odrębnych. Wszyscy mamy ograniczony czas i staramy się pisać kod, który jest łatwy w utrzymaniu i wydajny. Gdy coś jest trudne do zrobienia w praktyce, rzadziej szukamy kreatywnych rozwiązań.
Branża internetowa jest jednak obecnie zdominowana przez duże korporacje, dlatego ich interesy biznesowe zawsze mają większe znaczenie niż twórcy internetowi. Myślę, że wiele tracimy, jeśli ignorujemy kreatywność w internecie jako główne zastosowanie funkcji. Z wielkim entuzjazmem obserwuję, jak niektórzy twórcy grafiki CSS eksperymentują z prototypem zapytań o kontener. Jhey Tompkins stworzyła szczególnie sprytne i interaktywne demo żaluzji w CSS jako komentarz do starego mema anty-CSS. Myślę, że w tej dziedzinie jest jeszcze wiele do odkrycia i nie mogę się doczekać, co jeszcze wymyślą ludzie.
Rozmowa dotyczyła też zapytań opartych na rozmiarze, czyli pierwotnego zastosowania, ale jestem ciekawy, jak użytkownicy wykorzystają zapytania dotyczące stylu – możliwość pisania stylów warunkowych na podstawie wartości właściwości lub zmiennej CSS. To niezwykle przydatna funkcja, która jest jeszcze w dużej mierze nieodkryta. Myślę, że otwiera to jeszcze więcej możliwości twórczych.
Rachel: Czy jest coś, czego nie możemy zrobić w CSS (lub wkrótce będziemy mogli zrobić), a co Twoim zdaniem byłoby przydatne?
Miriam: bardzo się cieszę z innych specyfikacji, nad którymi pracuję. Warstwy kaskadowe zapewnią autorom większą kontrolę nad problemami z dokładnością, a zakres powinien pomóc w dokładniejszym kierowaniu selektorów. Ale oba te problemy dotyczą architektury na wysokim poziomie. Mój wewnętrzny artysta bardziej ekscytuje się takimi rzeczami jak przełączniki CSS, deklaratywny sposób tworzenia interaktywnych stylów czy „osie czasu” kontenerów, które pozwalają płynnie przechodzić między wartościami w punktach przerwania multimediów lub kontenerów. Ma to bardzo praktyczne implikacje w przypadku elastycznej typografii, ale otwiera też wiele możliwości twórczych w zakresie elastycznej grafiki i animacji.
Rachel: Kto jeszcze wykonuje w tej chwili w internecie naprawdę interesującą, zabawną lub kreatywną pracę?
Miriam: Nie wiem nawet, jak na to odpowiedzieć. Tak wiele osób wykonuje kreatywną pracę w różnych dziedzinach. Zarówno CSSWG, jak i Open-UI prowadzą wiele interesujących prac nad standardami, w tym nad fragmentacją, w których Ty też uczestniczysz. Największą inspirację czerpię jednak od artystów internetowych i z tego, jak ludzie wykorzystują te narzędzia w sposób niezwiązany bezpośrednio z komercją. Osoby takie jak Jhey, Lynn Fisher, Yuan Chuan i wiele innych, które przesuwają granice możliwości technologii internetowych w zakresie wizualnym i interaktywnym. Nawet osoby zajmujące się bardziej biznesowymi zadaniami mogą wiele się nauczyć z technik artystycznych.
Cenię też bardziej koncepcyjną sztukę internetową, którą tworzą tacy artyści jak Ben Grosser. Jego prace skłaniają nas do ponownego przemyślenia, czego oczekujemy od internetu, a w szczególności od mediów społecznościowych. Sprawdź na przykład jego nowy serwis minus.social.
Rachel: śledź pracę Miriam nad CSS na stronie css.oddbird.net i dowiedz się, czym jeszcze się zajmuje, na jej stronie miriam.codes i na Twitterze @TerribleMia.