Miriam Suzanne jest autorką, artystką i deweloperką stron internetowych z Denver w stanie Kolorado, a obecnie pracuje nad ciekawymi specyfikacjami CSS, takimi jak Container Zapytania i Warstwy kaskadowe.
Ten post jest częścią projektu designcember. Wydarzenie poświęcone projektowaniu stron internetowych zaproponowane przez web.dev.
Miriam Suzanne jest pisarką, artystką i programistką z Denver w stanie Kolorado. Jest współzałożycielką agencji internetowej OddBird, redaktorką tekstów CSS Tricks, członkiem podstawowego zespołu Sass i ekspertem W3C zaproszonym do grupy roboczej ds. usług porównywania cen. Ostatnio zajmuje się opracowaniem nowych funkcji CSS, takich jak warstwy kaskadowe, zapytania kontenerów czy zakres. Miriam jest opublikowaną pisarką, dramaturgą i muzyką. Rozmawialiśmy o jej współpracy z Sass i CSS.
Rachel: Zaczęłam się o tym dowiedzieć dzięki schematowi siatki Susy. Co Cię do tego skłoniło?
Miriam: W 2008 roku układ strony internetowej wyglądał zupełnie inaczej. Deweloperzy odeszli od układu tabeli na rzecz bardziej semantycznych (ale nadal zagadkowych) pływających siatki. W przypadku jednowymiarowych 12-kolumnowych „platform siatki” rozwinął się skutek, co pozwoliło stworzyć wstępnie zdefiniowaną (zwykle statyczną) siatkę z wstępnie zdefiniowanymi klasami CSS. Jeśli potrzebujesz czegoś bardziej swobodnego, byłeś(-aś) samodzielnie. Witryny musiały zostać szybciej responsywne, ale zapytania multimedialne nie są jeszcze dostępne i pojawiają się liczne problemy ze zgodnością przeglądarek związane z kreacjami płynnymi.
Korzystałam z metody CSS Systems Natalie Downe, która mądrze reagowała zarówno na rozmiar czcionki, jak i widoczny obszar, ale denerwowały mnie te powtarzające się funkcje matematyczne i hazardy w przeglądarkach. W tym samym czasie Sass zaczęła przyciągać uwagę i pasowała do moich potrzeb. Pierwsza wersja robocza Susy była bardzo prosta – wystarczyło kilka miksów, żeby rozliczyć potrzebne triki. Zadanie było minimalne i zawierało tylko niezbędny kod. Możliwość dostosowania siatki bez żadnych zdefiniowanych wstępnie klas.
Rachel: Jak udało Ci się przejść od pracy z preprocesorem CSS do pracy nad specyfikacjami CSS? Czy uważasz, że praca z procesorem wstępnym była dobrym wykształceniem specyfikacji?
Miriam: Z mojego doświadczenia wynika, że w dużym stopniu się pokrywam, a ja wciąż jestem aktywny po obu stronach tego podziału. Myślę, że jest to w dużej mierze zasługa zespołu Sass, którym kieruje się Natalie Weizenbaum, która w perspektywie długoterminowej pracuje nad tworzeniem narzędzi, które płynnie integrują się z postępami w zakresie standardów internetowych. Wykraczanie poza uniwersalne, uniwersalne rozwiązania i tworzenie długoterminowej elastyczności jest kluczowe, jeśli zastanawiamy się nad przyszłością podstawowych standardów internetowych.
Jak możemy tworzyć narzędzia uwzględniające różnorodność potrzeb i metod dla deweloperów, a jednocześnie zachęcać i ułatwiać ułatwienia dostępu oraz inne ważne kwestie?
Rachel: wprowadziliśmy w CSS kilka funkcji, które w zasadzie zastąpią funkcje, które wcześniej były częścią rozwiązania Sass. Czy istnieją ważne powody, aby nadal używać narzędzi takich jak Sass?
Miriam: Tak, dla niektórych osób, ale tutaj nie ma uniwersalnej odpowiedzi. Weźmy na przykład zmienne. Zmienne Sass mają zakres leksyktyczny i są kompilowane na serwerze, w tym uporządkowane struktury danych, takie jak listy i obiekty, manipulowanie kolorami itp. To świetne rozwiązanie w przypadku logiki systemu projektowania, która nie musi być uruchamiana w przeglądarce.
Zmienne CSS częściowo się nakładają i mogą również przechowywać wartości, ale stanowią zupełnie inny zestaw mocnych i słabych stron kaskadowych. Sass nie obsługuje właściwości niestandardowych, a CSS nie potrafi obsługiwać uporządkowanych danych. Obie te usługi są przydatne i bardzo skuteczne, ale mogą się różnić konkretne potrzeby.
Uważam, że świetnie byłoby mieć dostęp do narzędzi, których już nie potrzebują. Niektóre projekty nie wymagają jednocześnie zmiennych po stronie serwera i klienta. Wszystko wspaniale! Zbyt łatwo jednak zakładać, że są one identyczne i po prostu zastępują drugie. zawsze pewna logika projektowa będzie działać po stronie serwera, a inne – po stronie klienta – nawet jeśli dotrzemy do punktu, w którym języki zapewniają te same funkcje. Firmy przetwarzające dane są z nami długoterminowo.
Rachel: Czy jest coś, co Cię zaskoczyło w związku z większym zaangażowaniem w tworzenie standardów? Czy jest coś, co Twoim zdaniem ludzie mogą nie wiedzieć o tym procesie?
Miriam: Zanim się zaangażowałam, proces tworzenia standardów wydawał mi się tajemniczy, magiczny i nie wiedziałam, czego się spodziewać. Obawiałam się, że mogę nie mieć wystarczającej wiedzy o funkcjach wewnętrznych przeglądarki, żeby coś współtworzyć, ale w rzeczywistości nie potrzebują oni więcej inżynierów. Potrzeba większej liczby programistów i projektantów, którzy tworzą strony i aplikacje w środowisku naturalnym.
Bardzo zaskoczyło mnie to, że bardzo niewielu z nich skupia się głównie na standardach, ale niewiele z nich zajmuje się tworzeniem lub projektowaniem stron internetowych. W3C składają się „wolontariusze” organizacje członkowskie (często opłacane przez te organizacje, ale nie jako główne zadanie), a członkostwo nie jest tanie. Odciąga to uczestników od codziennych projektantów i programistów, zwłaszcza tych, którzy pracują dla klientów w małych agencjach lub samodzielnie. Moją rolę jako zaproszonego eksperta pełnię rolę wolontariatu, to kosztowne hobby, gdybym nie znalazła zewnętrznego finansowania tej pracy.
W rzeczywistości ten proces jest otwarty, publiczny i wymaga zaangażowania ze strony dewelopera, ale zawsze jest tak dużo rozmów, że jednocześnie trudno znaleźć odpowiedni dla siebie. Zwłaszcza jeśli nie jest to Twoja bieżąca praca.
Rachel: od wielu lat zapytania o kontenery są głównym Graalem dla wielu programistów stron internetowych. Bardzo się cieszę, że je otrzymujemy. Mam wrażenie, że wiele osób zastanawia się nad przydatnością zapytań kontenerów – czy uważasz, że mają one też potencjał, aby zyskać większą kreatywność?
Miriam: oczywiście, choć ja nie uważam ich za całkiem oddzielne. Każdy z nas ma ograniczone czasy, dlatego staramy się napisać łatwy w użyciu i wydajny kod. Gdy coś jest trudne do zrobienia w praktyce, mniej prawdopodobne jest, że wykażemy się kreatywnością w możliwościach.
Mimo to branża internetowa jest obecnie zdominowana przez duże korporacje, więc te kwestie biznesowe zawsze mają więcej czasu niż artyści internetowi. Sądzę, że wiele stracisz, jeśli zignorujemy kreatywność w internecie jako główny przypadek użycia funkcji. Z radością zobaczę, jak członkowie zespołu CSS bawią się nad prototypem zapytania kontenera. Jhey Tompkins stworzył wyjątkowo sprytną i interaktywną demonstrację żaluzji weneckich CSS w formie komentarza do starego mema anty CSS. Myślę, że jest jeszcze wiele do zbadania i nie mogę się doczekać, aż zobaczę, co jeszcze wymyślą.
Rozmowa koncentrowała się też na zapytaniach opartych na rozmiarze, ale z radością zobaczę, co użytkownicy robią z zapytaniami dotyczącymi stylu – możliwość pisania stylów warunkowych na podstawie wartości właściwości lub zmiennej CSS. To niezwykle przydatna funkcja, która jak dotąd jest w większości niezbadana. Uważam, że otwiera to jeszcze więcej kreatywnych możliwości.
Rachel: Czy jest coś, czego nie możemy zrobić (lub w przyszłości chcemy zrobić) w usłudze porównywania cen, co Twoim zdaniem może być przydatne?
Miriam: Jestem bardzo ciekawy innych parametrów, nad którymi pracuję. Warstwy kaskadowe dają autorom większą kontrolę nad problemami ze specyficznością, a zakres powinien ułatwiać bardziej precyzyjne kierowanie na selektory. Oba te kwestie są jednak ogólnie związane z architekturą. Uwielbiam takie elementy jak przełączniki CSS, deklaratywne tworzenie stylów interaktywnych czy oś czasu kontenerów, które pozwalają nam płynnie przenosić wartości między multimediami a punktami przerwania kontenera. Ma to bardzo praktyczne konsekwencje w przypadku elastycznej typografii, ale stwarza też wiele możliwości tworzenia responsywnej grafiki i animacji.
Rachel: Kto jeszcze robi w internecie coś ciekawego, ciekawego lub kreatywnego?
Miriam: Ach, nawet nie wiem, jak na to odpowiedzieć – jest naprawdę wiele osób pracujących twórczo w tak różnych dziedzinach. Zarówno CSSWG, jak i Open-UI pracują nad wieloma fascynującymi standardami, w tym pracą nad fragmentacją. Często jednak czerpię najwięcej inspiracji z twórczości internetowych oraz tego, jak ludzie wykorzystują te narzędzia w produkcji w sposób niepowiązany bezpośrednio z handlem. To ludzie tacy jak Jhey, Lynn Fisher, Yuan Chuan i wiele innych osób, które przenoszą granice możliwości wizualnych i interaktywnych technologii internetowych. Nawet osoby pracujące bardziej nastawione na biznes mogą wiele nauczyć się od swoich technik artystycznych.
Doceniam również bardziej konceptualną sztukę internetową osób takich jak Ben Grosser, którzy skłaniają nas do ponownego zastanowienia się nad tym, co chcemy osiągnąć w internecie, a w szczególności w mediach społecznościowych. Zobacz np. jego nowy tag minus.social.
Rachel: Śledź na bieżąco pracę Miriam nad CSS na stronie css.oddbird.net i dowiedz się, co jeszcze robi na jej stronie internetowej – miriam.codes i na Twitterze @TerribleMia.