Autor:
Jakub Rychlicki
Opublikowano:
12 sierpnia 2024
Framer oferuje funkcję filtrowania listy, jednak zmiana kryteriów filtrowania wiąże się z koniecznością stworzenia komponentu z wariantami dla każdego wybranego zestawu opcji.
Takie rozwiązanie sprawdza się przy prostych filtrach, ale w przypadku bardziej rozbudowanych scenariuszy filtrowania generuje zbyt dużą liczbę wariantów. Opisane poniżej rozwiązanie eliminuje ten problem.
Zaawansowane filtrowanie oparte na tzw. polach wyboru, pozwala na precyzyjne selekcjonowanie danych poprzez zaznaczanie odpowiednich opcji.
Swobodna personalizacja pustego widoku listy, przycisku paginacji oraz ekranu ładowania, do stylu strony internetowej.
Układ Grid zapewnia responsywność na wszystkich urządzeniach.
Paginacja ogranicza liczbę wyświetlanych elementów na liście, co pozwala na dynamiczne, a co za tym idzie szybsze wczytywanie treści.
Ważne: podczas pracy z dużymi kolekcjami w CMS należy pamiętać, że może to wpłynąć na wydajność strony. Dzieje się tak, ponieważ wszystkie elementy listy są ładowane jednocześnie, co może spowolnić działanie strony. Problem ten jest szczególnie zauważalny w przypadku kolekcji zawierających 100 lub więcej elementów.
Poradnik video
Poradnik tekstowy
1. Dodanie Code Components
Code Components to zwykłe komponenty Reacta.
Wystarczy je dodać do projektu poprzez skopiowanie załączonych linków i wklejenie ich w dowolne miejsce w projekcie.
Rozszerzenie wymaga dodatkowych klas. Utwórz nowy plik Code Override lub nadpisz istniejący. Jeśli nie wiesz jak dodać niestandardową klasę do komponentu/elementu w Framer, sprawdź ten poradnik How to add a custom class to an element.
Niestandardowy checkbox musi posiadać dwa warianty: Unchecked oraz Checked.
Dla każdego elementu wewnątrz komponentu musisz ustawić pointer-events: none
Wykorzystaj plik Code Override, aby przypisać klasę do każdego checkboxa za pomocą funkcji „withClassForCheckbox”.
Następnie, użyj komponentu CheckboxWrapper, który zawiera następujące właściwości:
Name: Identyfikuje filtr, używany również do grupowania filtrów.
Value: Wartość.
Checkbox: Dowolny komponent utworzony przez nas.
4. Ustawienie komponentu CollectionItemFilter
Po dodaniu listy kolekcji do warstw, nadaj komponentowi Stack klasę za pomocą funkcji o nazwie „withClassForCollectionItem”, którą dodaliśmy wcześniej w pliku Code Override.
Następnie, wewnątrz komponentu Stack, możemy dodać komponent CollectionItemFilter, który zawiera następujące właściwości:
Name: Powinno być identyczne z nazwą ustawioną w CheckboxWrapper.
Value: Przekazujesz tutaj dowolne pole z CMS, które chcesz użyć.
Aby ukryć dodany komponent CollectionItemFilter, ustaw poniższe style:
Position: absolute
Z-Index: -1
5. Konfiguracja CollectionManager
Najpierw dodaj komponent CollectionManager do wybranej warstwy. Następnie połącz instancje komponentów z odpowiednimi polami:
Load More Button: Komponent pełniący rolę przycisku do załadowania kolejnych elementów z listy.
Empty Collection: Komponent wyświetlany, gdy podczas filtrowania nie zostanie znaleziony żaden element.
Loader: Komponent wyświetlany podczas ładowania listy.
6. Ustawienia
Za pomocą poniższych ustawień możesz dostosować działanie filtrowania i wygląd listy.
Match (dopasowanie)
Any: Wyszukuje dowolny element, który pasuje przynajmniej do jednego filtra.
Precise: Wyszukuje elementy pasujące do wszystkich filtrów.
Pagination (paginacja)
Limit: Maksymalna liczba elementów do wyświetlenia i załadowania za pomocą przycisku „Załaduj więcej”.
Duration of loading: Czas sztucznego ładowania listy w milisekundach.
Margin Top: Odstęp między przyciskiem „Załaduj więcej” a listą kolekcji.
Grid
Aby ułatwić dostosowanie wyglądu listy, wykorzystywany jest układ grid. Pozwala to na zdefiniowanie liczby kolumn oraz odstępów między nimi.
Za pomocą opcji Gap Mode możemy przełączyć się do trybu zaawansowanego, który pozwala nam ustawić odstępy między kolumnami i wierszami osobno.
Visibility of the Collection on Canvas (widoczność kolekcji w aplikacji Framer)
Ta opcja pozwala ukryć listę tylko w aplikacji Framer. Nie oznacza to jednak automatycznie, że lista będzie niewidoczna na stronie internetowej.
Jeśli kolekcja CMS zawiera wiele elementów, renderowanie całej listy może przeciążyć aplikację Framer, potencjalnie wpływając na pracę innych elementów na tej samej stronie zawierającej komponent CollectionManager.
Jakub Rychlicki
Front-End Developer
Przekształć swoje pomysły w rzeczywistość
Skontaktuj się z nami i pozwól nam sprawdzić jak możemy Ci pomóc.
Autor:
Adam Gałęcki
Opublikowano:
12 sierpnia 2024
Skoro się tutaj znalazłeś/łaś, prawdopodobnie chcesz, aby w konkretnej sekcji Twojej strony internetowej wyświetlała się Mapa Google z oznaczeniem danej lokalizacji (lub wielu lokalizacji). Rozwiązanie tego problemu jest całkiem proste.
Wystarczy zarejestrować swój nowy klucz API Google Maps i dodać oprogramowanie do odpowiedniej sekcji strony.
Dla niewtajemniczonych zaczniemy od wyjaśnienia, czym jest klucz API.
Następnie przejdziemy bezpośrednio do konkretów, czyli do: 1. Rejestracji Google Maps API 2. Ograniczenia dostępu Google Maps API do swojej domeny.
Czym jest klucz API Google Maps?
Klucz API (Application Programming Interface) – klucz interfejsu programistycznego aplikacji, to fragment kodu oprogramowania.
Najczęściej ma postać wygenerowanego ciągu znaków. Definiuje on, w jaki sposób programy mają się ze sobą komunikować i pozwala na implementacje jednego programu do drugiego.
API w przypadku Google Maps pozwala nam na dodanie do swojej strony internetowej lub aplikacji Mapy Google, oraz oznaczenia na niej konkretnej lokalizacji. Pozwala również na identyfikację użytkownika, który z niego korzysta.
Jak zarejestrować nowy klucz API do Google Maps?
Logowanie do konta Google
Pierwszym co musimy zrobić aby zarejestrować nowy klucz API dla Google Maps musimy zalogować się na platformie Google Maps dla developerów za pomocą swojego konta Google. Przycisk logowania znajduje się w prawym górnym rogu strony.
Logowanie do konta Google Maps
Jeśli nie posiadamy konta, musimy je najpierw założyć.
Następnie przechodzimy przez opcje konfiguracji swojego konta.
Konfiguracja konta Google Maps Cloud
1. Zaczynamy od naciśnięcia przycisku Get Started.
Konfiguracja konta Google Maps | Krok 1
2. Następnie uzupełniamy informacje o koncie.
Konfiguracja konta Google Maps | Krok 2
Dlaczego muszę podać dane do swojej karty płatniczej?
Model biznesowy Google Maps to model freemium – wszyscy użytkownicy otrzymają co miesiąc bezpłatnie 200 dolarów na połączenia API.
Dla większości stron internetowych taki miesięczny kredyt jest więcej niż wystarczający. Niezależnie od tego, czy chodzi o stronę kontaktową, czy o coś bardziej złożonego, jak np. wyszukiwarka sklepów.
Google potrzebuje danych karty kredytowej by naliczać opłatę po przekroczeniu progu 200 dolarów.
3. Po wypełnieniu wszystkich danych otrzymamy swój klucz API.
Konfiguracja konta Google Maps | Krok 3
Ale to jeszcze nie koniec…
Konfiguracja klucza API Google Maps
Teraz musimy skonfigurować opcje naszego klucza API i określić, w jakich celach będzie używany.
1. Najpierw przechodzimy do Konfiguracji Ekranu Zgody.
Konfiguracja klucza API Google Maps | Krok 1
2. Określamy, w jakim zakresie będziemy korzystać z API.
Konfiguracja klucza API Google Maps | Krok 2
Kolejno wypełniamy wszystkie niezbędne informacje.
3. Następnie wracamy do ekranu Dane logowania
Konfiguracja klucza API Google Maps | Krok 3
4. I przechodzimy do ustawień swojego klucza API.
Konfiguracja klucza API Google Maps | Krok 4
Ograniczenie dostępu klucza API Google Maps
W ustawieniach klucza API możemy ograniczyć dostęp klucza API tylko dla naszej witryny, aby zapobiec jego nieautoryzowanemu wykorzystaniu.
#1. Ustawiamy tutaj rodzaj ograniczenia.
#2. Oraz lokalizacje, w których jest ograniczony.
Ograniczenie klucza API Google Maps
Dodanie „/*” na końcu adresu domeny spowoduje, że klucz będzie działać na jej każdej podstronie.
Uzyskanie klucza API Google Maps
Klucz jest już odpowiednio skonfigurowany i gotowy do wykorzystania.
1. Teraz wystarczy już tylko kliknąć, w przycisk POKAŻ KLUCZ i go skopiować.
Kopiowanie odpowiednio skonfigurowanego klucza API Google Maps
Nie masz czasu na samodzielne wprowadzaniem zmian na firmowej stronie internetowej? Sprawdź, jak możemy Ci w tym pomóc.
Autor:
Michał Walczuk
Opublikowano:
12 sierpnia 2024
WordPress potrafi być niezawodnym oraz potężnym narzędziem, jeżeli jest wykorzystywany w odpowiednim celu. Próg wstępu jest dosyć niski, co sprawia, że chętnie sięgają po niego również początkujący web developerzy, a nawet ludzie, którzy nigdy nie mieli okazji programować.
WordPress ma 60% udziału w rynku CMS-ów
WordPress nie traci również na popularności. W momencie pisania artykułu (Maj, 2022) 42.9% stron internetowych w sieci działa właśnie na nim.
Jednym ze sposobów, aby sprawić, żeby to narzędzie było jeszcze lepsze jest podejście headless.
Celem artykułu jest przedstawienie zalet oraz wad tego podejścia, oraz krótki opis frameworka Frontity.
Czym jest Headless WordPress?
Zacznijmy od tego czym NIE jest headless CMS.
WordPress ma w zwyczaju obsługiwać zarówno front end jak i back end, setup polega na instalacji jednej instancji CMS i działania na niej. Pliki są ściśle powiązane z szablonem oraz są z nim zintegrowane.
To podejście jest najpopularniejsze oraz najczęściej wybierane przez początkujących użytkowników, którzy chcą w szybki sposób stworzyć prostą stronę internetową.
Podejście headless zapewnia nam wygodę oddzielenia warstwy wizualnej naszej aplikacji od warstwy zarządzania treścią. Zamiast bezpośrednio zapewnić wbudowaną komunikację między frontem a cms’em, wystawiane jest REST API z którym komunikuje się nasz front end (w tym przypadku head).
Jeżeli naszym celem jest skorzystanie z takiej architektury, jednym z rozwiązań może być wykorzystanie biblioteki React.
Pojawia się wtedy niestety kilka problemów, których jeżeli nie przemyślimy w odpowiedni sposób, mogą sprawić że nasza strona nie będzie funkcjonować w sposób poprawny z ogólnie przyjętymi zasadami oraz praktykami tworzenia tego typu stron.
Problematyka
Głównymi zaletami Frontity są problemy, jakie rozwiązuje po stronie następujących zagadnień.
SEO
Jeżeli zdecydujemy się na użycie biblioteki React, to nadal nasza strona będzie się renderować po stronie klienta, co będzie oznaczało, że stracimy wszelkie benefity SEO. Zalecane jest użycie frameworków takich jak Next.js, Gatsby lub Frontity który jest tematem tego artykułu.
Frontity zapewnia optymalizację SEO tworzonej strony internetowej, tak aby była poprawnie zaindeksowana. Framework zapewni nam dostarczenie gotowego oraz sformatowanego pliku HTML opartego o nasze komponenty napisane w React.
Gdy budujemy nasz projekt Frontity jego kluczowy kod jest inicjalizowany tylko raz. Framework zapewnia nam opcje pre-fetch’owania stron oraz ich danych out-of-the-box. Przez developerów została wykorzystana strategia Serverless Pre-rendering (SPR) w celu renderowania plików HTML „w locie”.
Jeśli zastosujemy strategię headless w kontekście rozwiązań CMS, nasza strona będzie o wiele lżejsza, co sprawi że doświadczenie użytkownika będzie o wiele lepsza niż przy tradycyjnym podejściu.
Security
Ponieważ front end naszej strony jest hostowany w odosobnieniu od CMS’a, to potencjalny atakujący ma utrudnione zadanie próbując wyrządzić nam szkody. Częstymi lukami w instalacjach WordPress są podejrzane lub słabo przetestowane wtyczki, które posiadają szereg podatności. Korzystając z podejścia headless uniemożliwiamy spory procent ataków, ot tak.
Flexibility
Gdy korzystamy z podstawowej wersji WordPress’a, jesteśmy skazani na język programowania PHP. Mamy dużą dowolność w doborze wtyczek oraz dopasowania naszego motywu, jednak nie dla każdego taka opcja jest odpowiednia. Wykorzystując React po stronie front, nadal możemy tworzyć i dostosowywać naszą treść w CMS.
Pozwala nam to wprowadzić porządek w przypadku większych projektów, gdzie może istnieć podział na dwa zespoły developerów, którzy specjalizują się w innych technologiach.
Ponadto możemy w dowolnym momencie zmienić architekturę (np. wybór innego frameworku front end) naszego projektu i nie będzie to stanowiło problemu.
Alternatywy dla Frontity
Używanie Gatsby wraz z WordPressem to kuszące rozwiązanie dla programistów stawiających na wydajność oraz bezpieczeństwo swoich aplikacji.
Jak już wcześniej wspomniałem, istnieją różne możliwości wdrożenia nowej architektury, jednym z godnych konkurentów Frontity może być Next.js lub Gatsby.
Jedną z różnic jest to, że Frontity zostało stworzone specjalnie pod integrację z WordPress. Zapewnia optymalizację, odpowiednie wtyczki oraz bogatą bibliotekę, pozwalającą nam na komunikację z CMS’em.
Next.js lub Gatsby są dosyć ogólnymi rozwiązaniami, które pozwalają nam głównie na dobór odpowiedniej strategii renderowania takich jak SSR lub SSG.
Samodzielny front end – Next.js
Jeśli decydujemy się na korzystanie z Next.js, to na nas spoczywać będzie odpowiedzialność stworzenia własnej architektury front end stworzonej do integracji z naszym CMS’em.
Zaletą korzystania z Next.js może być jego popularność, bez problemu powinniśmy znaleźć wśród community odpowiedź na zagadnienie z którym się trapimy.
Wewnętrzna wtyczka WooCommerce – Gatsby
Istnieje wiele materiałów ze strony twórców Gatsby pokazujących możliwości zintegrowania ich rozwiązania z WordPress oraz skonfigurowanie architektury headless CMS.
Dostępny jest również szereg pluginów oraz artykułówprowadzących nas za rękę. Bardzo ważna jest także możliwość zintegrowania naszego systemu z wtyczką WooCommerce.
Takie rozwiązanie nie jest niestety jeszcze dostępne we Frontity (mowa oczywiście rozwiązaniu o zaproponowanym przez twórców, ponieważ samodzielnie możemy stworzyć dla niego alternatywę).
Podsumowanie
Dostępne jest wiele ciekawych rozwiązań oraz opcji wyboru, ale najpierw powinniśmy się zastanowić nad kilkoma kwestiami:
Czy dane narzędzie rzeczywiście jest nam potrzebne? Sama nazwa nowej fancy technologii może przysłonić nam na chwilę rozumowanie, podczas gdy tradycyjne podejście jest bardzo często wystarczającym rozwiązaniem.
Do czego aplikacja ma służyć i w jaki sposób działać?
Jednym z wielu zagadnień do rozważenia jest kwestia samej struktury aplikacji i to jakie ma być jej główne zastosowanie. Może się okazać, że wcale nie potrzebujemy CMS’a lub nasze potrzeby są na tyle skomplikowane, że lepiej będzie napisać własne rozwiązanie od zera.
Kolejną sprawą jest wdrożenie. W przypadku headless CMS mamy do czynienia z dwoma instancjami komunikującymi się ze sobą. Wdrożenie zwykłego WordPress’a jest dosyć łatwe nawet dla niedoświadczonej osoby.
Mimo wszystko rozwiązanie headless jest zdecydowanie bardzo przydatne w przypadku kiedy szukamy sposobów na zoptymalizowanie naszej aplikacji lub zintegrowania jej z naszym ulubionym frameworkiem front endowym.
Chcesz wiedzieć więcej o technologiach, które wykorzystujemy?Zajrzyj do zakładki Case Studies, gdzie szczegółowo opisujemy nasze najciekawsze projekty.
Jako osoba, która swoją pierwszą stronę internetową zrobiła w wieku 16 lat (22 lata temuw 2002 roku) miałem okazję śledzić to co działo się na przestrzeni ostatnich dekad w procesie tworzenia stron internetowych.
Marek Golan, Programista z ponad 20-letnim stażem, CEO Dogtronic
A uwierzcie mi, działo się dużo. Bardzo dużo. Kiedyś głównym wyzwaniem było to by strona, którą programujemy wyglądała identycznie na wiodących 2-3 przeglądarkach, tj. Internet Explorer, FireFox, Opera. Wtedy przeglądarka Chrome, a dokładnie silnik Chromium nawet nie istniał. Nie istniało pojęcie Responsive Design, bo na ówczesnych telefonach nie dało się przeglądać stron internetowych więc o RWD nikt się nie martwił.
Martwiono się za to innymi rzeczami. W poniższym artykule przedstawię Ci przykłady technik, jakie wykorzystywano 20 lat temu przy tworzeniu stron internetowych.
Jedno się nie zmieniło. Grafik projektował, programista wdrażał.
Tabele – królowe layoutu
Tworzenie stron internetowych opartych na tabelach było popularnym podejściem w latach 90 i na początku lat 2000. Mimo że tabele zostały pierwotnie zaprojektowane do prezentowania danych w formie tabelarycznej, projektanci i deweloperzy szybko dostrzegli w nich narzędzie umożliwiające tworzenie układów strony.
Czemu? Bo każda ówczesna przeglądarka wyświetlała tabelepraktycznie tak samo, czego nie można było powiedzieć o innych elementach języka HTML.
Strona oparta na tabeli zazwyczaj miała główną tabelę, która określała główne sekcje strony, takie jak nagłówek, główną treść, boczny pasek nawigacyjny i stopkę.
Zagnieżdżanie tabel prowadziło do trudnego w czytaniu i zarządzaniu kodu.
Nieelastyczność
Układy oparte na tabelach były trudne do dostosowywania na różne rozmiary ekranów i urządzeń.
Długi czas ładowania
Duża ilość niepotrzebnego kodu sprawiała, że strony oparte na tabelach były wolniejsze.
Brak zgodności z semantyką
Używanie tabel do układu zamiast prezentacji danych było niezgodne z przeznaczeniem i semantyką tabel w HTML.
Maile oparte o tabele
Zwróćcie uwagę jak jak zbudowane są newslettery, które otrzymujecie na swoje skrzynki. Projektowanie w oparciu o tabele nadal używane jest w tworzeniu szablonów newsletterów.
Newslettery wysyłane pocztą e-mail mają swoje unikatowe wyzwania, które różnią je od standardowych stron internetowych. Jednym z głównych problemów jest fakt, że klienci pocztowi różnią się między sobą pod względem interpretacji i renderowania HTML i CSS.
Z tego powodu projektanci e-mail marketingu często korzystają z technik, które mimo, że są uważane za przestarzałe w kontekście współczesnego projektowania stron internetowych to by mieć pewność, że ich przekaz nie zostanie zniekształcony używają między innymi szablonów opartych o <table>
Ten newsletter ma prostą strukturę: nagłówek, główną część z treścią i paskiem bocznym oraz stopkę.
Przykład newslettera opartego o table.
Adobe ImageReady
Adobe ImageReady był narzędziem graficznym, które towarzyszyło Adobe Photoshop w latach 90. i na początku lat 2000. Było ono skoncentrowane na przygotowywaniu grafik do publikacji w sieci i oferowało funkcje, które ułatwiały tworzenie elementów stron internetowych, w tym animowanych GIF-ów, wycinków obrazów oraz optymalizacji grafik.
Jednym z głównych zastosowań ImageReady było tworzenie wycinków obrazów (ang. slicing). Pozwalało to projektantom na podział dużego obrazu projektu strony na mniejsze fragmenty, które można było potem wykorzystać jako różne elementy strony, takie jak przyciski, nagłówki czy tła.
Po przygotowaniu wszystkich wycinków obrazu i animacji w ImageReady, program mógł generować podstawowy kod HTML. Ten kod mógł być następnie zaimportowany do edytorów HTML, takich jak Dreamweaver, aby dodać treść i dodatkową funkcjonalność.
Jaki kod był generowany? Oczywiście oparty o tabelki 🙂.
Fonty i kolory bezpośrednio w HTML
Zanim CSS stał się powszechną praktyką w projektowaniu stron internetowych, wiele stylów, takich jak kolory i czcionki, było deklarowanych bezpośrednio w kodzie HTML. Było to nieefektywne i utrudniało aktualizacje, ale była to powszechna praktyka w początkowym okresie WWW.
Oto kilka przykładów:
Deklarowanie koloru tła i tekstu dla całej strony
Aby ustawić kolor tła i tekstu dla całej strony, używano atrybutów bgcolor i text w elemencie <body>.
<body bgcolor="#FFFFFF" text="#000000">
Deklarowanie koloru tła dla tabeli
Atrybut bgcolor był również używany w tabelach i komórkach tabeli.
<table bgcolor="#CCCCCC">
<tr>
<td bgcolor="#FF0000">To jest komórka o czerwonym tle.</td>
</tr>
</table>
Deklarowanie czcionek
Aby ustawić czcionkę dla tekstu, używano elementu <font>, który jest obecnie uważany za przestarzały i niezalecany.
<font face="Arial, Helvetica, sans-serif" size="3" color="#FF0000">To jest tekst w czerwonym kolorze i czcionce Arial.</font>
Używanie elementu < center > do wyśrodkowywania
Element <center> był używany do wyśrodkowywania zawartości, ale jest obecnie uważany za przestarzały.
<center>Ten tekst będzie wyśrodkowany na stronie.</center>
Deklarowanie koloru dla linków
Element <body> miał atrybuty do zmiany kolorów linków: link (dla zwykłych linków), vlink (dla odwiedzonych linków) i alink (dla aktywnych linków).
Chociaż takie bezpośrednie deklaracje były użyteczne w pierwszych latach istnienia WWW, szybko stały się problematyczne, gdy strony stały się bardziej złożone. CSS wprowadził wiele ulepszeń, takich jak oddzielenie stylu od struktury, co ułatwiło zarządzanie i aktualizowanie wyglądu stron.
Spacer GIF
W czasach, gdy CSS nie był jeszcze powszechny lub nie był w pełni wspierany przez wszystkie przeglądarki, Spacer GIF były jednym ze sposobów na osiągnięcie pewnych układów.
Spacer GIF (czasami nazywane „clear GIF” lub „1×1 GIF”) to niewidoczne obrazy (często o rozmiarze 1×1 pikseli), które można było skalować za pomocą atrybutów width i height w tagu <img> w celu wprowadzenia „pustego” miejsca na stronie.
Przykład użycia Spacer GIF:
<table>
<tr>
<td><img src="zdjecie1.jpg" alt="Zdjęcie 1"></td>
<!-- Użycie Spacer GIF do wprowadzenia odstępu między dwoma zdjęciami -->
<td><img src="spacer.gif" width="20" height="1" alt=""></td>
<td><img src="zdjecie2.jpg" alt="Zdjęcie 2"></td>
</tr>
</table>
W powyższym przykładzie spacer.gif jest używany do wprowadzenia odstępu o szerokości 20 pikseli między dwoma zdjęciami w tabeli.
Jednak z biegiem czasu, w miarę rozwoju CSS i przyjęcia się modelu pudełkowego (box model), technika używania Spacer GIF stała się zbędna. Możliwość kontroli marginesów, paddingu i innych aspektów układu za pomocą CSS sprawiła, że Spacer GIF stały się przestarzałą praktyką.
Ramki – wielostronicowy wygląd w jednym oknie
Ramki, znane też jako „frames” były popularne w latach 90. i wczesnych latach 2000. Pozwalały one na wyświetlanie wielu dokumentów HTML w jednym oknie przeglądarki, dzięki czemu można było mieć na przykład stały pasek nawigacji po jednej stronie ekranu i treść, która się zmieniała, po drugiej stronie.
Jak to działało?
Strony z ramkami korzystały z elementu <frameset>, który zastępował element <body>. Wewnątrz <frameset> definiowano różne ramki za pomocą elementu <frame>.
Przykłady:
Załóżmy, że chcemy podzielić stronę na dwie ramki wertykalnie: jeden pasek nawigacji (plik navbar.html) po lewej stronie i główną treść (plik content.html) po prawej.
Linki w jednej ramce mogły wpływać na to, co jest wyświetlane w innej ramce. Na przykład:
<a href=”page2.html” target=”content-frame”>Link do strony 2</a>
Ramki zostały w końcu uznane za przestarzałe i niezalecane do stosowania w nowoczesnym projektowaniu stron internetowych. Współczesne standardy HTML (np. HTML5) nie wspierają już elementu <frameset> ani powiązanych z nim elementów.
Podsumowanie
Przytoczone powyżej przykłady mające zastosowanie 2 dekady temu pokazują, jak technologie internetowe ewoluowały, dostosowując się do zmieniających się potrzeb użytkowników i twórców.
Jedno jest pewne: internet nigdy nie przestaje się rozwijać, a my możemy tylko czekać z niecierpliwością na to, co przyniesie kolejna dekada.
Nowoczesne strony internetowe
Szukasz wykonawcy dla wyjątkowej strony internetowej? Mamy ponad 20 lat doświadczenia w ich projektowaniu i wdrażaniu. Zobacz, co możemy dla Ciebie zrobić.
