Kiedy pierwszy raz uczyłam się projektowania stron (przez konsultacje z osobą bardziej zaawansowaną technicznie oraz czytanie książek – papierowych!), podejście do rozmieszczania tekstów na stronie obejmowało układy tabelaryczne. Było to odejście od pierwotnego zamysłu – wykorzystywania znaczników tabeli zgodnie z przeznaczeniem – układania powtarzających się sekwencji, pozwalało to na podział treści na kolumny, rozdział funkcjonalny (w jednym wierszu tabeli nagłówek, w ostatnim stopka).
Przez wiele lat takie podejście funkcjonowało, aż zostało wyparte przez kontenery – pojęcie wprowadzone wraz z upowszechnieniem się biblioteki Bootstrap. Założenie jest takie, że treść umieszczało się w znacznikach
i nadawało konkretne klasy, co pozwalało na ułożenie końcowe – responsywne, z odpowiednimi ustawieniami fixed-width. Było to nawet całkiem sprytne rozwiązanie, pozwalające na używanie ponownie pewnych znaczników zgodnie ze znaczeniem (tabel tylko tam, gdzie faktycznie – potrzebowano tabel). Również odpowiadało to na możliwości, z którymi stykała się część użytkowników: mając dostęp tylko do backendu WordPressa nie miała dostępu do plików css i serwera z plikami. Kiedyś motywy nie pozwalały na dodawanie zewnętrznego CSS – tak jak to teraz ma WordPress wbudowany we rdzeniu – obejścia tego tematu były dwa:
- poprzez stworzenie motywu potomnego (a potem wysłania go na serwer)
- poprzez dodanie klasy do kontenera () zawierającego treść – w edycji wpisu, strony.
W obecnych czasach, stosujemy coś nowego – bloki, które pozwalają na łatwą edycje z predefiniowanymi ustawieniami konkretnych części strony. Myślę, że jest to odpowiedź i unowocześnienie, które pozwala uwolnić znaczniki i przywrócić znaczenie div-om co w powiązaniu z funkcją rdzenia (dodatkowego CSS) pozwala na ogromną elastyczność.