Odstępy w Drupal Paragraphs: jak rozwiązać luki w układach komponentowych

Możesz zbudować świetny system paragrafów i i tak zobaczyć, jak się rozpada, gdy redaktor po raz pierwszy ułoży dwie białe sekcje jedna na drugiej. Odstępy to detal, który po cichu decyduje, czy układ komponentowy wygląda na dopracowany, czy zepsuty.

Odstępy w Drupal Paragraphs - pionowe marginesy i padding między i wewnątrz komponentów Drupal Paragraphs - to jeden z tych problemów, których nie widać na demo, a które zawsze pojawiają się na produkcji. Projektujesz każdy typ paragrafu tak, by sam w sobie wyglądał idealnie. Redaktorzy kochają nową elastyczność. Potem układają dwa białe paragrafy jeden na drugim i przerwa między nimi jest ogromna. Albo usuwają tytuł i zostaje dziwny pusty pas tam, gdzie wcześniej był nagłówek.

Każdy system oparty na paragrafach prędzej czy później na to trafia. My mieliśmy to w dystrybucji Droopler, na projektach klientów i świadomie zaplanowaliśmy pod to niedawną korporacyjną przebudowę. Ten artykuł wyjaśnia, dlaczego problemy z odstępami są nieuniknione, przedstawia trzy podejścia do ich rozwiązania, pokazuje konkretną implementację z kodem oraz scenariusze z produkcji, które decydują o tym, które podejście faktycznie potrzebujesz.

W tym artykule:

• Dlaczego problemy z odstępami zawsze się pojawiają
• Trzy podejścia do kontroli odstępów
• Jak wdrożyć kontrolę odstępów w paragrafach
• Scenariusze z produkcji i jak je rozwiązać
• Dobre praktyki odstępów w paragrafach

Dlaczego problemy z odstępami zawsze się pojawiają

Gdy po raz pierwszy budujesz typ paragrafu, nadajesz mu stały rytm pionowy: margines u góry, margines u dołu, wewnętrzny padding. Wygląda idealnie, bo testujesz go na „szczęśliwej ścieżce” - jeden paragraf, wszystkie pola wypełnione, osadzony między dwoma innymi, dobrze zachowującymi się sekcjami.

Prawdziwa treść nie trzyma się szczęśliwej ścieżki. Te same stałe odstępy, które na demo wydają się zbalansowane, zaczynają sprawiać kłopoty, gdy redaktorzy łączą komponenty w sposób, którego nie przewidziałeś:

• Dwa paragrafy z tym samym tłem, ułożone jeden na drugim. Gdy biała sekcja leży bezpośrednio na innej białej sekcji, ich marginesy się sumują. Zamiast jednej czytelnej przerwy dostajesz ogromną lukę, która wizualnie rozdziela stronę na dwie części.
• Opcjonalne pola pozostawione puste. Paragraf z ukrytym lub pustym polem tytułu zostawia po sobie przestrzeń, którą tytuł by zajął. Efekt to pas białej przestrzeni wyglądający jak błąd.
• Sekcje, które powinny czytać się jako jedna całość. Czasem redaktor chce, by dwa paragrafy tworzyły jeden ciągły blok - bez widocznego szwu. Stałe marginesy uniemożliwiają to, bo zawsze jest przerwa, która je rozpycha.
• Różna gęstość treści. Gęsta tabela danych i krótkie wezwanie do działania potrzebują innego oddechu. Jedna stała wartość nie może być dobra dla obu.

Źródło problemu jest proste: odstępy są kontekstowe, a CSS domyślnie jest absolutny. Wartość marginesu nie wie, czy paragraf nad nią jest biały czy ciemny, pełny czy pusty, ma być oddzielony czy połączony z sąsiadem. Redaktor wie. System nie wie - chyba że dasz redaktorowi sposób, by mu to powiedzieć.

Trzy podejścia do kontroli odstępów

Nie ma jednego poprawnego sposobu na odstępy w Drupal Paragraphs. Są trzy, a właściwe podejście zależy od tego, jak zróżnicowana jest treść i ile kontroli potrzebują redaktorzy.

Podejście 1: stałe odstępy bez kontroli

Każdy typ paragrafu ma jedną, zahardkodowaną wartość odstępów. W formularzu administracyjnym nie ma żadnych opcji.

• Zalety: proste do zbudowania, w pełni spójne, redaktorzy nigdy nie muszą podejmować decyzji.
• Wady: psuje się przy każdym przypadku brzegowym z listy powyżej, nie daje elastyczności i po cichu generuje zgłoszenia do zespołu technicznego, gdy prawdziwa treść zderza się ze stałymi wartościami.
• Najlepsze dla: prostych stron z przewidywalnymi układami, gdzie redaktorzy składają strony z wąskiego, dobrze znanego zestawu wzorców.

Tu zaczyna większość projektów. Tu też większość projektów w końcu utknie, bo pierwsza niewygodna luka zamienia się w prośbę do developera, której stałe odstępy nie rozwiążą po stronie redakcji.

Podejście 2: wybieralne odstępy z kontrolą dla redaktorów

Każdy paragraf udostępnia opcje odstępów bezpośrednio w formularzu edycji. Redaktor wybiera margines i padding z małego zestawu nazwanych rozmiarów.

• Kontrola marginesu: none / small / medium / large
• Kontrola paddingu: none / small / medium / large
• Zalety: wystarczająco elastyczne, by obsłużyć przypadki brzegowe bez developera, i przenosi decyzję kontekstową tam, gdzie kontekst faktycznie jest - do redaktora przy danej stronie.
• Wady: nieco większa złożoność formularza administracyjnego; bez wytycznych dla redaktorów może prowadzić do niespójnych odstępów na całej stronie.
• Najlepsze dla: stron korporacyjnych ze zróżnicowaną treścią i systemów komponentowych, gdzie ten sam paragraf pojawia się w wielu różnych kontekstach.

To podejście polecamy każdej poważnej bibliotece komponentów wielokrotnego użytku. To też rozwiązanie, które dodaliśmy do Drooplera i projektów klientów, gdy stałe odstępy okazały się zbyt sztywne.

Podejście 3: automatyczne, kontekstowe odstępy

Zamiast pytać redaktora, pozwalasz CSS-owi wykrywać kontekst i dostosowywać się. Selektory sąsiednich elementów i reguły zwijania marginesów mogą na przykład usunąć podwojony margines, gdy dwa białe paragrafy leżą obok siebie.

• Zalety: niewidoczne dla redaktorów, bez dodatkowych pól, naprawia najczęstsze przypadki automatycznie.
• Wady: ograniczony zasięg, trudniejsze debugowanie, kruche w miarę rozrostu biblioteki komponentów. Najgorsze jest to, że zmienia odstępy w sposób, którego redaktor nie widzi ani nie kontroluje - po zmianie kolejności dwóch paragrafów margines lub padding może nagle się przesunąć, bez oczywistej przyczyny i bez możliwości naprawy z poziomu CMS-a.
• Najlepsze dla: prostszych układów i tylko dla bardzo małego zestawu naprawdę oczywistych przypadków.

W praktyce polecamy podejście 2 jako domyślne dla każdej nietrywialnej strony. Kontrola po stronie redaktora utrzymuje odstępy przewidywalne: to, co redaktor ustawi, to dostanie, a zmiana kolejności lub duplikacja paragrafu nigdy nie przynosi niespodzianki. Tej przewidywalności właśnie rezygnują reguły automatyczne. W momencie, gdy odstępy zmieniają się same - redaktor przesuwa sekcję, a padding cicho się zmienia - zaufanie do CMS-a eroduje szybciej, niż kosztowałaby jakakolwiek przesadnie duża luka. Jeśli już używasz reguł automatycznych, trzymaj je w absolutnym minimum i pozostaw redaktorom kontrolę nad resztą.

Jak wdrożyć kontrolę odstępów w paragrafach

Dodanie wybieralnych odstępów do typu paragrafu to niewielki kawałek pracy. Mechanika to ten sam wzorzec, którego używasz przy wariantach kolorystycznych: pole select mapowane na klasę CSS.

Implementacja sprowadza się do czterech kroków.

1. Dodaj pola. Utwórz dwa pola typu list (text) na typie paragrafu, na przykład `field_margin` i `field_padding`. Nadaj im te same opcje: none, small, medium, large.
2. Renderuj wartości jako klasy. W szablonie paragrafu odczytaj wartości pól i zastosuj je jako klasy modyfikujące na elemencie opakowującym.
3. Zdefiniuj skalę odstępów w CSS. Użyj custom properties, aby cała skala była zdefiniowana w jednym miejscu i spójna między komponentami.
4. Ustaw sensowne domyślne wartości. Wstępnie wybierz medium, żeby redaktorzy zmieniali odstępy tylko wtedy, gdy trzeba, a nie przy każdym paragrafie.

Po stronie Twig wygląda to tak - odczyt dwóch pól i dodanie klas modyfikujących:

{% set spacing_classes = [
  'paragraph--margin-' ~ (content.field_margin['#items'].value|default('medium')),
  'paragraph--padding-' ~ (content.field_padding['#items'].value|default('medium')),
] %}
<div{{ attributes.addClass('paragraph', spacing_classes) }}>
  {{ content|without('field_margin', 'field_padding') }}
</div>

A oto CSS ze skalą zdefiniowaną raz jako custom properties:

:root {
  --space-s: 1.5rem;
  --space-m: 3rem;
  --space-l: 5rem;
}

.paragraph--margin-none   { margin-block: 0; }
.paragraph--margin-small  { margin-block: var(--space-s); }
.paragraph--margin-medium { margin-block: var(--space-m); }
.paragraph--margin-large  { margin-block: var(--space-l); }

.paragraph--padding-none   { padding-block: 0; }
.paragraph--padding-small  { padding-block: var(--space-s); }
.paragraph--padding-medium { padding-block: var(--space-m); }
.paragraph--padding-large  { padding-block: var(--space-l); }

Jeśli dodajesz odrobinę zachowania automatycznego - a trzymalibyśmy to w absolutnym minimum - ogranicz się do jednego lub dwóch jednoznacznych przypadków. Pojedyncza reguła sąsiedniego elementu (adjacent sibling) na przykład usuwa podwojoną lukę między dwoma sekcjami z tym samym tłem:

.paragraph--bg-white + .paragraph--bg-white {
  margin-block-start: 0;
}

Dokładnie taki model przyjęliśmy w Drooplerze. Kluczowa decyzja polegała na udostępnieniu dwóch osobnych kontrolek zamiast jednej. Margines i padding rozwiązują różne problemy: margines odsuwa paragraf od sąsiadów, a padding reguluje przestrzeń wewnątrz paragrafu, między krawędzią tła a treścią. Dajemy redaktorom trzy rozmiary dla każdej kontrolki. Ta kombinacja obejmuje prawie każdą sytuację, na którą redaktor trafia, bez przytłaczania go ustawieniami na poziomie pikseli.

Czytaj także: szybki sposób na edycję i dostosowanie paragrafu w Drupalu oraz moduł Geysir do szybszej edycji paragrafów.

Scenariusze z produkcji i jak je rozwiązać

Tak mocno opowiadamy się za kontrolą po stronie redaktora, bo widzieliśmy te scenariusze na żywo w wielu projektach. Żaden z nich nie jest hipotetyczny.

• Dwa białe paragrafy jeden na drugim. To klasyk. Dwie sekcje z tym samym tłem tworzą podwojony margines i ogromną lukę. Rozwiązanie: redaktor ustawia górny margines drugiego paragrafu na none i obie sekcje czytają się jako jedna całość.
• Hero, a za nim sekcja treści. Hero potrzebuje innego oddechu niż dwa bloki treści jeden po drugim. Przy wybieralnych marginesach redaktor zacieśnia lub rozluźnia przejście bez zgłoszenia do zespołu technicznego.
• Paragraf bez tytułu. Usunięcie tytułu zostawia niezręczny pusty pas w miejscu zarezerwowanym na nagłówek. Redaktor zmniejsza padding o jeden rozmiar i luka znika.
• Paragraf z obrazem na pełną szerokość. Grafika na pełną szerokość zwykle wymaga zerowego paddingu, żeby nic jej nie ramowało. Opcja „none” załatwia to od razu.
• Dwa paragrafy, które mają zlać się w jeden blok. Gdy redaktor chce brak widocznego szwu między sekcjami, jedynym działającym rozwiązaniem jest zerowy margines między nimi - a stałe odstępy po prostu tego nie dają.

Na jednym projekcie klienta odstępy nie były drobnym szlifem wizualnym. Były jednym z najbardziej uporczywych źródeł frustracji. Platforma używała podobnego modelu komponentowego, zbudowanego nieco inaczej, i ciągłą walką było to, że właściwy rozmiar odstępów zależał wyłącznie od tego, co było w treści. Czasem sekcja potrzebowała więcej miejsca, żeby dobrze wyglądać, czasem mniej, a ułożone sekcje w tym samym kolorze zawsze „wybuchały”. W końcu musieliśmy dodać jawne kontrolki - small, medium, large - żeby redaktorzy mogli sami to naprawiać. Droopler poszedł tą samą drogą: kontroli odstępów nie było na start, te same problemy się pojawiły i dodaliśmy ustawienia marginesu oraz paddingu.

W tej historii jest też lekcja planistyczna. Przy niedawnej korporacyjnej przebudowie świadomie zaprojektowaliśmy system paragrafów tak, by kontrolę odstępów dało się dodać później bez przebudowy struktury. Nie było tego w początkowym zakresie, ale wszyscy zaangażowani wiedzieli z doświadczenia, że prośba przyjdzie. Zaplanowanie tego z góry zamienia przyszłą przebudowę w przyszłą zmianę konfiguracji.

Dobre praktyki odstępów w paragrafach

Kilka reguł konsekwentnie utrzymuje odstępy pod kontrolą, gdy biblioteka komponentów rośnie.

• Zacznij bez kontrolek, ale zaprojektuj pod nie. Na małej stronie możesz wystartować ze stałymi odstępami. Nie wolno natomiast zbudować systemu tak, by dodanie kontrolek później wymagało bolesnej przebudowy. Zostaw drzwi otwarte.
• Używaj CSS custom properties dla skali. Zdefiniuj small, medium i large raz. Gdy design się zmienia, zmieniasz trzy wartości zamiast przeszukiwać każdy komponent.
• Ogranicz liczbę opcji. Trzy lub cztery nazwane rozmiary wystarczą. Kontrola co do piksela brzmi kusząco, ale daje niespójne strony i zmęczenie decyzyjne. Ograniczenia to zaleta.
• Udokumentuj logikę odstępów dla redaktorów. Krótki przewodnik wizualny - jak wyglądają none, small, medium i large - zamienia zgadywanie w pewne decyzje. Najlepsze miejsce to żywa strona przykładowa na stagingu.
• Testuj na realnych kombinacjach treści. Problemy z odstępami pojawiają się dopiero, gdy paragrafy spotykają się ze sobą. Testuj ułożone sekcje z tym samym tłem, puste pola opcjonalne i scalone bloki, a nie pojedyncze paragrafy w próżni.

Wspólny wątek we wszystkich tych punktach to ten sam, który stoi za każdym dobrym systemem paragrafów: projektuj pod to, jak redaktorzy faktycznie łączą komponenty, a nie pod to, jak każdy komponent wygląda sam w sobie.

Chcesz, żeby odstępy na Twojej stronie Drupal po prostu działały?

Ten artykuł opiera się na realnym doświadczeniu produkcyjnym - budowie kontroli odstępów w dystrybucji Droopler, walce i naprawie tych samych problemów na projektach klientów oraz zaprojektowaniu niedawnego korporacyjnego systemu Paragraphs tak, by kontrolę odstępów dało się dodać w chwili, gdy będzie potrzebna. Ten wzorzec powtarza się przy każdej budowie opartej na komponentach, dlatego warto zaplanować go od początku.

Walczysz z lukami w układach paragrafów na własnej stronie albo planujesz system komponentowy, który ma być dobry za pierwszym razem? Nasz zespół buduje wdrożenia Paragraphs przyjazne redaktorom - od kontroli odstępów i kolorów po czystą architekturę Twig i CSS. Odwiedź nasze usługi Drupal, żeby zobaczyć, jak możemy pomóc.