Miriam Suzanne jest autorką, artystką i programistą stron internetowych z Denver w stanie Kolorado. Obecnie pracuje nad ciekawymi specyfikacjami CSS, takimi jak Container Zapytania czy Cascade Warstwy.
Ten post jest częścią projektu Designcember. Uczczenie projektowania stron internetowych stworzone przez web.dev.
Miriam Suzanne jest autorką, artystką i twórcą stron internetowych z Denver w stanie Kolorado. Jest współzałożycielką agencji internetowej OddBird (agencją internetową), redaktorką dla pracowników CSS Tricks, członkiem podstawowego zespołu Sass i specjalistką W3C Consentd Expert w grupie roboczej ds. CSS. Ostatnio zajmuje się tworzeniem nowych funkcji CSS, takich jak Warstwy kaskadowe, Zapytania dotyczące kontenerów i Zakres. Miriam jest offline powieściopisarzem, dramatopisarzem i muzykiem. Rozmawialiśmy o jej współpracy z Sass i CSS.
Rachel: Dowiedziałem się o Waszych pracach dzięki strukturze siatki Susy. Co skłoniło Was do jej stworzenia?
Miriam: W 2008 roku korzystanie z układów w internecie było zupełnie inne. Deweloperzy odeszli od układu tabeli do bardziej semantycznych (ale i zwariowanych) pływających siatek. W 12-kolumnowej „strukturze siatki” zgodnej z uniwersalną siatką nastąpił ogromny wzrost popularności – dzięki wykorzystaniu wstępnie zdefiniowanej (zwykle statycznej) siatki z zestawem wstępnie zdefiniowanych klas CSS. Jeśli potrzebujesz czegoś bardziej spersonalizowanego, nie musisz się o nic martwić. Wyraźnie było widać, że witryny muszą działać bardziej elastycznie, ale zapytania o multimedia nie były jeszcze dostępne, a wokół płynów zmiennoprzecinkowych pojawiły się problemy ze zgodnością przeglądarek.
Korzystałam z metody CSS Systems Natalie Downe, która w świetny sposób odpowiadała zarówno na rozmiar czcionki, jak i na widoczny obszar, ale denerwowała mnie liczba powtarzających się działań matematycznych i wymagań przeglądarki. W tym samym czasie Sass zaczęła przyciągać uwagę i wszystko odpowiadało mi to, czego potrzebuję. Pierwsza wersja robocza Susy była bardzo prosta: wystarczyło dodać kilka wariantów, aby obliczyć obliczenia i dodać potrzebne triki. Celem było ograniczenie do minimum i wygenerowanie tylko najważniejszego kodu. W pełni personalizowane siatki bez żadnych wstępnie zdefiniowanych klas.
Rachela: Jak udało Ci się przejść z procesu wstępnego przetwarzania usług porównywania cen do pracy nad specyfikacjami CSS? Czy uważasz, że praca na wstępnym procesorze była dobrym tłem do pisania specyfikacji?
Miriam: Z mojego doświadczenia wynika, że te obszary w dużym stopniu się pokrywają, a ja wciąż jestem aktywny po obu stronach tej przepaści. Myślę jednak, że jest to w szczególności zasługa zespołu Sass, którym kieruje Natalie Weizenbaum, która przyjmuje bardzo długoterminową perspektywę i stara się tworzyć narzędzia, które płynnie integrują się z rozwijającymi się standardami sieciowymi. Wykraczamy poza uniwersalne podejście i zapewnianie elastyczności w dłuższej perspektywie jest kluczowe, jeśli myślisz o przyszłości podstawowych standardów internetowych.
Jak możemy tworzyć narzędzia, które uwzględniają różnorodne potrzeby i podejścia programistów, a jednocześnie promują i ułatwiają ułatwienia dostępu oraz inne ważne kwestie?
Rachel: W CSS pojawiło się wiele rzeczy, które zasadniczo zastępują funkcje, które dotychczas były częścią Sass. Czy są jakieś ważne powody, aby nadal korzystać z takich rozwiązań jak Sass?
Miriam: tak, w przypadku niektórych osób nie ma tu uniwersalnej odpowiedzi. Weźmy na przykład zmienne. Zmienne sass mają zakres leksykalny i są skompilowane na serwerze. Wykorzystują one uporządkowane struktury danych, takie jak listy i obiekty, manipulacja kolorami itp. W ten sposób znakomicie sprawdza się w przypadku logiki systemowej, która nie wymaga uruchamiania w przeglądarce.
Zmienne CSS w pewnym stopniu się pokrywają, ale również mogą przechowywać wartości, ale zapewniają zupełnie inny zestaw mocnych i mocnych stron kaskadowych. Sass nie obsługuje właściwości niestandardowych, a CSS nie obsługuje uporządkowanych danych. Obie te metody są przydatne i dają duże możliwości, ale Twoje konkretne potrzeby mogą być różne.
Myślę, że to świetnie, gdy ktoś ma możliwość wyeliminowania narzędzi, których już nie potrzebuje, a niektóre projekty mogą nie wymagać zmiennych po stronie serwera i klienta. Wszystko wspaniale! Zbyt łatwo jednak zakładać, że są one identyczne i jednocześnie zastępują drugie. Zdarzają się przypadki użycia, w których część logiki projektowej ma miejsce po stronie serwera, a inne po stronie klienta, nawet jeśli dojdziemy do punktu, w którym języki zapewniają zasadniczo te same funkcje. Osoby wstępnie przetwarzające dane są u nas długoterminowo.
Rachel: Czy przy pracy nad tworzeniem standardów zaskoczyło Cię coś, co Cię zaskoczyło? A może coś, z czego Twoim zdaniem widzowie nie zdają sobie sprawy?
Miriam: Zanim się angażuję, proces tworzenia standardów wydawał się tajemniczy i magiczny. Nie wiedziałam, czego się spodziewać. Obawiałem się, że nie mam wystarczającej wiedzy na temat przeglądarek, ale w rzeczywistości nie potrzeba więcej inżynierów. Potrzebują większej liczby programistów i projektantów, którzy tworzą strony internetowe i aplikacje w środowisku naturalnym.
Z zaskoczeniem stwierdzam, że niewiele z nich koncentruje się głównie na standardach, ale niewiele z nich zajmuje się przede wszystkim tworzeniem lub projektowaniem stron internetowych. W3C składa się z „wolontariuszy”, od organizacji członkowskich (często opłacanych przez te organizacje, ale nie jako ich podstawowe zadanie), a członkostwo nie jest tanie. Odbiega to od tych, którzy na co dzień zajmują się projektantami i programistami, zwłaszcza tych z nas, którzy pracują dla klientów w małych agencjach lub jako freelancer. Gdyby nie udałoby mi się znaleźć funduszy na tę pracę z zewnątrz, chciałbym być w pełni wolontariatem, a to kosztowne hobby.
W rzeczywistości ten proces jest dość otwarty i publiczny, a wszystko to wymaga zaangażowania ze strony programistów. Jednak w rzeczywistości toczy się tak wiele rozmów jednocześnie, że znalezienie odpowiedniej firmy może być trudne. Zwłaszcza, jeśli nie są to Twoje codzienne obowiązki.
Rachela: zapytania dotyczące kontenerów są od wielu lat świętym Graalem dla wielu programistów stron internetowych. Bardzo się cieszę, że je dostajemy. Mam wrażenie, że wiele osób zastanawia się nad przydatnością zapytań dotyczących kontenerów. Czy uważasz, że one także mogą uwolnić kreatywność?
Miriam: Oczywiście, chociaż nie uważam tych relacji za oddzielne. Każdy z nas ma ograniczony czas, a my staramy się napisać wydajny i sprawny kod. Gdy coś jest trudne do zrobienia, jesteśmy mniej kreatywni na tym, co jest możliwe.
Mimo to branża internetowa jest obecnie zdominowana przez duże interesy korporacyjne i kwestie związane z tymi kwestiami zawsze poświęcają więcej czasu niż twórcy stron internetowych. Myślę, że wiele tracimy, jeśli zignorujemy kreatywność internetową jako główny przypadek użycia funkcji. Z radością obserwuję, jak artyści z CSS bawią się prototypem zapytania o kontener. Jhey Tompkins przygotował wyjątkowo sprytną i interaktywną wersję demonstracyjną żaluzji weneckich CSS, które komentują stare memy antyCSS. Myślę, że jest w tej branży o wiele więcej do odkrycia i nie mogę się doczekać, aby zobaczyć, co jeszcze wymyślą inni.
W rozmowie koncentrowaliśmy się też na zapytaniach dotyczących rozmiaru, tak jak w pierwotnym przypadku użycia. Jednak z przyjemnością zobaczę, co użytkownicy robią z zapytaniami dotyczącymi stylu – możliwości pisania stylów warunkowych na podstawie wartości właściwości lub zmiennej CSS. To ogromna funkcja i jak dotąd w większości niezbadana. Myślę, że otwiera to jeszcze więcej kreatywnych możliwości.
Rachel: Czy jest coś, czego według Ciebie nie można zrobić w CSS (lub w przyszłości można by to osiągnąć)?
Miriam: Bardzo się cieszę, że pracuję nad innymi specyfikacjami. Warstwy kaskadowe dają autorom większą kontrolę nad problemami dotyczącymi szczegółowości, a zakres powinien pomóc w bardziej precyzyjnym kierowaniu na selektor. Oba te są jednak ogólnym zagadnieniem architektonicznym. Wykonawca we mnie bardziej interesuje się takimi funkcjami jak przełączniki CSS, deklaratywny sposób tworzenia interaktywnych stylów czy „osi czasu” kontenera, które pozwalają płynnie przechodzić między punktami przerwania multimediów lub kontenera. Ma to bardzo praktyczne znaczenie w przypadku responsywnej typografii, a jednocześnie daje wiele kreatywnych możliwości w zakresie responsywnej grafiki i animacji.
Rachel: Kto jeszcze wykonuje teraz w internecie naprawdę ciekawą, zabawną lub kreatywną pracę?
Miriam: Nie do końca wiem, jak odpowiedzieć na to pytanie. Jest tak wiele osób pracujących kreatywnie w różnych dziedzinach. Zespół CSSWG i Open-UI pracują nad wieloma interesującymi standardami, w tym prac nad fragmentacją. Największą inspiracją dla mnie są jednak twórcy stron internetowych i informacje o tym, jak ludzie wykorzystują te narzędzia w produkcji, a nie w sposób niepowiązany bezpośrednio z handlem. Osoby takie jak Jhey, Lynn Fisher czy Yuan Chuan oraz wiele innych, którzy przesuwają granice możliwości technologii internetowych w sposób wizualny i interaktywny. Nawet osoby pracujące w większości biznesu mogą wiele nauczyć się od swoich technik artystycznych.
Doceniam też bardziej konceptualną sztukę internetową, którą przedstawiają ludzie tacy jak Ben Grosser, którzy nieustannie skłaniają nas do refleksji nad naszymi celami w internecie, a zwłaszcza w mediach społecznościowych. Wypróbuj jego nowe minus.social.
Rachel: Śledź pracę Miriam w zakresie usług porównywania cen pod adresem css.oddbird.net, a teraz dowiesz się, co jeszcze robi na stronie miriam.codes i Twitter @TerribleMia.