Fundamentalne znaczniki w dokumencie HTML
Podstawową strukturę HTML łatwo uzyskać w edytorze Visual Studio Code dzięki obecnemu tam dodatkowi Emmet (podpowiadanie składni podczas pisania) – wystarczy, że w pliku z rozszerzeniem .html, .htm lub .php wpiszemy wykrzyknik !, dzięki czemu otrzymamy możliwość wstawienia do pustego dokumentu od razu domyślnej tzw. templatki HTML (ang. template = szablon):
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
</body>
</html>
Ponieważ na egzaminie instalacja Visual Studio Code również zazwyczaj jest stockowa (konfiguracja domyślna) to dodatek Emmet powinien być na komputerze egzaminacyjnym obecny.
Przypomnijmy teraz przeznaczenie tych fundamentalnych zapisów! Jako pierwsza w pliku występuje deklaracja doctype, która określa typ dokumentu i wersję HTML, w której go opracowano – w praktyce przekłada się to na sposób renderowania strony:
<!DOCTYPE html>
Informujemy tutaj przeglądarkę, iż ten dokument został zapisany w standardzie HTML 5. Oczywiście przeglądarka dysponuje mechanizmami zapewniającymi kompatybilność także ze wcześniejszymi standardami, takimi jak HTML 4.01 czy XHTML 1.1 – wcześniejsze deklaracje były jednak znacznie bardziej rozbudowane, gdyż zawierały tzw. wpis DTD (ang. document type definition):
HTML 4.01:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
XHTML 1.1:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Jak widzimy, są to długie zapisy z wieloma ukośnikami, przez co łatwo w nich popełnić wiele literówek! Na szczęście współczesny zapis jest dużo łatwiejszy w implementacji i nie ma już potrzeby używać tych starszych doctypes, znanych z HTML 4 czy XHTML 1.1.
Polskie znaki diakrytyczne
Kolejne działania posłużą nam do poprawnego ustawienia polskich znaków na stronie. Aby polskie znaki, czyli nasze rodzimy ogonki typu „ą”, „ę”, „ś”, „ć”, “ź” i reszta ekipy, wyświetlały się poprawnie, musimy zadbać o trzy kluczowe aspekty. Spokojnie, to nic skomplikowanego – wystarczy kilka drobnych ustawień i wszystko będzie wyglądać jak należy.
1. Określamy język dokumentu
Pierwszy krok to jasne powiedzenie przeglądarce czegoś w style: „Hej, to jest strona która powinna być wyświetlana w języku polskim!”. Dokonamy tego poprzez dodanie atrybutu lang="pl" w tagu <html>. Poprawny dla naszego języka tag powinien wyglądać zatem tak:
<html lang="pl">
Dzięki temu przeglądarka wie, że pracujemy w naszym rodzimym języku, a różne systemowe funkcje (np. podpowiedzi pisowni) również będą działać zgodnie z polskimi zasadami. Zwróćmy jednak koniecznie uwagę, iż templatka HTML wstawiona przez Visual Studio Code domyślnie ustawia dla dokumentu język angielski:
<html lang="en">
Koniecznie nie zapomnijmy tego zmienić na egzaminie!
2. Ustawiamy odpowiednie kodowanie znaków
Tutaj sprawa jest jeszcze prostsza. W sekcji <head> naszej strony dodajemy taki oto wpis:
<meta charset="utf-8">
To informacja dla przeglądarki jakiego zestawu znaków ma używać do wyświetlania tekstu. Najlepszym współczesnym wyborem standard jest UTF-8, ponieważ obsługuje wszystkie polskie ogonki (i nie tylko). Istnieje też inny zestaw znaków: ISO-8859-2 – ale to starszy standard, więc najlepiej trzymać się na egzaminie kodowania w UTF-8.
Uwaga! Tag <meta charset="utf-8"> powinien być pierwszym wpisem w sekcji <head>, jeszcze przed tytułem strony czy podpięciem arkuszy stylów albo skryptów. Jeśli dodasz go później, może się teoretycznie zdarzyć, że przeglądarka niepoprawnie zinterpretuje znaki – i np. zamiast słowa „żółw” zobaczymy „żółw”. A tego byśmy nie chcieli.
3. Sprawdzamy kodowanie samego pliku w edytorze
Dobrze, ustawiliśmy zatem język podstrony oraz kodowanie UTF-8 znaków, lecz co jeśli sam nasz plik nie jest zapisany w standardzie UTF-8? Wówczas problem ze znakami nadal może występować! Dlatego musimy sprawdzić, jak zapisuje plik nasz edytor kodu.
Na przykład dla Notepad++ wchodzimy w menu Format (lub w angielskiej wersji: Encoding) i jeśli jest tam coś innego wybranego aniżeli UTF-8 – zmieniamy kodowanie dokumentu. W Visual Studio Code rodzaj używanego kodowania widać w pasku stanu edytora (poziomy pasek na samym dole okna – sprawdź samodzielnie). I to wszystko – jeśli zadbamy o te trzy rzeczy, to polskie ogonki na pewno będą wyglądać tak jak powinny!
Co ważne – oczywiście mówimy teraz o polskich znakach zapisanych w samym pliku HTML, natomiast czym innym okażą się łańcuchy (napisy) wyjęte z bazy danych z użyciem języka PHP – do ich poprawnego wyświetlania potrzebujemy także ustawić kodowanie UTF-8 tuż po połączeniu się z bazą danych:
<?php
$connection = mysqli_connect("localhost", "root", "", "nazwa_bazy") die("Błąd połączenia!");
mysqli_set_charset($connection, "utf8");
?>
Zwróćmy też uwagę, iż parametr posyłany w PHP wewnątrz funkcji mysqli_set_charset nie zawiera myślnika: "utf8" podczas gdy zapis w tagu <meta> w HTML jak najbardziej go posiada: charset="utf-8" – pomylenie tych zapisów to częsty błąd, stąd warto o tym pamiętać!
Ustawienie tytułu strony
Gdy otwieramy stronę w przeglądarce, tytuł witryny widoczny jest w otwartej zakładce przeglądarki, jak również ten sam tytuł pojawia się w rezultatach wyszukiwania w Google. Definiujemy go w HTML przy użyciu znacznika <title> . Sprawa jest niezwykle prosta – umieszczamy stosowny wpis wewnątrz sekcji <head>:
<title>Hurtownia Ziarenko - lista dostępnych rodzajów kawy do kupienia</title>
Porozmawiajmy jeszcze o pozycjonowaniu realnej witryny w wyszukiwarkach – otóż tytuł podstrony jest kluczowy w kontekście SEO (ang. Search Engine Optimization). Mówiąc po ludzku – to właśnie tytuł ma duży realny wpływ na to, jak wysoko strona pojawi się w wynikach wyszukiwania Google. Roboty indeksujące i algorytmy rozpoznające realną zawartość dokumentów analizują tytuły i na ich podstawie oceniają, czy strona pasuje do zapytań użytkowników. Tytuł podstrony powinien być więc konkretny – najlepiej gdy zawiera kluczowe frazy, na które chcemy pozycjonować stronę. Na przykład zapis:
<title>Strona główna</title>
jest zbyt ogólny i mało semantyczny (czyli nie przekazuje znaczenia), stąd nie będzie pomocny dla Google aby ustalić w jakim celu dana podstrona znajduje się w sieci i kto może uznać ją za pomocną. Warto więc taki “suchy” tytuł zastąpić zapisem:
<title>Kurs HTML dla początkujących - Tabele</title>
Taki tytuł ustawiony na jednej z podstron bloga o programowaniu pięknie odpowiada na pytanie co znajduje się w tym dokumencie – a opowiedziano w nim osobom początkującym w HTML o tworzeniu tabel w tym języku. Ponadto jest to zapewne część całego kursu dostępnego dla internautów.
Nie przesadzajmy jednak z długością tytułu! Optymalna liczba znaków to około 50-60 – za długi tytuł może zostać obcięty w wynikach wyszukiwania, co sprawi że jego końcówka będzie zastąpiona wielokropkiem. Znamy zapewne takie wyniki wyszukiwania w Google z własnego doświadczenia.
Meta viewport – wygląd strony na różnych ekranach
Jeśli kiedykolwiek otworzyliśmy stronę na telefonie i dostrzegliśmy, że wygląda jak miniaturowa wersja strony z komputera (z poziomymi i pionowymi paskami przewijania oraz miniaturowym tekstem), to znaczy, że brakuje jej odpowiedniego ustawienia viewportu. A to właśnie (między innymi) ten meta tag jest kluczem do tego, aby strona wyglądała dobrze zarówno na monitorze, jak i na smartfonie czy tablecie. Jest to następująca linia:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
Zapis ten mówi przeglądarce mobilnej, jak powinna interpretować szerokość strony i jak ją wyświetlić. Rozbijmy go na czynniki pierwsze:
name="viewport"– tym atrybutem definiujemy, iż w tym tagu<meta>chodzi o konfigurację obszaru widocznego na ekranie użytkownika (ang. viewport).content="width=device-width"– ustawiamy szerokość strony na tyle pikseli, ile posiada ekran urządzenia. Dzięki temu strona nie będzie się domyślnie skalować “jak na desktopie”, lecz dostosuje się optymalnie także do szerokości telefonu czy tabletu.initial-scale=1.0– określa początkowe przybliżenie (ang. zoom) strony. Wartość 1.0 oznacza, iż strona będzie domyślnie wyświetlana w naturalnej skali, bez dodatkowego przybliżania czy oddalania bez wyraźnej potrzeby.
Jeśli pominiemy ten meta tag, to przeglądarka mobilna będzie renderować stronę w trybie desktopowym, co oznacza, że:
- Wszystko na podstronie może okazać się malutkie i trudne do odczytania.
- Użytkownik będzie musiał przybliżać widok i sporo przestrzeni przewijać w poziomie, żeby coś na stronie odczytać.
- Strona nie będzie responsywna, nawet jeśli dodamy tzw. zapisy Media Queries
@mediaw CSS.
Inne, opcjonalne znaczniki meta
W sekcji <head> istnieje zestaw tagów meta, które choć niewidoczne dla użytkownika, mają znaczenie dla pozycji realnej witryny w wynikach wyszukiwania. Oczywiście mają one mniejsze znaczenie w przypadku realizowania zadania egzaminacyjnego, lecz warto znać ich przeznaczenie bo przecież pytania ich dotyczące mogą także pojawić się na teście. Pora je krótko omówić!
Tekstowy opis strony
Jednym z ważniejszych meta tagów pod kątem SEO jest description, czyli tekstowy opis strony, który może pojawić się w wynikach wyszukiwania. Oczywiście ma to największe znaczenie w realnej witrynie opublikowanej w sieci, a niekoniecznie w zadaniu egzaminacyjnym, lecz poznamy teraz sposób zdefiniowania takiego opisu. Tworzymy go w następujący sposób:
<meta name="description" content="Naucz się HTML i CSS od podstaw! Darmowy kurs online z licznymi przykładami oraz praktycznymi ćwiczeniami do samodzielnego zrealizowania">
Co warto wiedzieć o opisie witryny:
- Powinien mieć maksymalnie 155 – 160 znaków – dłuższy może zostać przycięty.
- Warto w nim umieścić liczne słowa kluczowe związane z podstroną, ale bez sztucznego upychania “popularnych” fraz (czyli często wyszukiwanych – Google tego nie lubi).
- Musi być zachęcający, bo to on może przekonać użytkownika do kliknięcia w nasz link, gdy internauta ujrzy go w rezultatach wyszukiwania.
Przykład słabo zrealizowanego opisu:
<meta name="description" content="Strona o HTML i CSS.">
Jest krótki, ogólny i mało zachęcający do odwiedzin opis – jeśli taki tekst pojawi się internaucie w rezultatach wyszukiwania w Google to najpewniej go pominie, bo jest za mało konkretny. Brakuje tutaj także kluczowego słowa: “kurs” tak często używanego w kontekście poszukiwania materiałów edukacyjnych.
Co ciekawe – ludzie nadużywali kiedyś tego “opisowego” tagu, wpisując jak najwięcej słów kluczowych tak naprawdę nie mających nic wspólnego z zawartością podstrony, lecz popularnych w sieci (tzw. keyword stuffing – upychanie słów kluczowych). Właśnie dlatego Google przestało ten opis z dużą wagą uwzględniać. Czy warto go zatem wciąż dodawać? Tak, w rzeczywistej witrynie opublikowanej w sieci warto to zrobić – oczywiście w zadaniu egzaminacyjnym ma to małe znaczenie. Zwróćmy również uwagę, iż edytor Visual Studio Code pomija te tagi w domyślnie wstawianej dzięki Emmetowi templatce HTML – trzeba zatem zapamiętać ich budowę.
Autor strony
Możemy też dodać w sekcji <head> informację o autorze strony:
<meta name="author" content="Jan Programista">
W czasach istnienia usługi “Google+” (portal social media od Google) zapis ten miał sporą praktyczną wartość, jednak obecnie dużo lepszym rozwiązaniem jest umieścić link (w sekcji <body> albo np. w stopce) do portfolio autora:
<a href="https://mojastrona.pl">Jan Programista - Tworzenie stron www</a>
Takie rozwiązanie daje nam większą realną korzyść – zyskujemy dodatkowy link do naszego portfolio w witrynie np. stworzonej dla kogoś na zlecenie, co może poprawić widoczność naszych usług w Google (im więcej linków z zewnętrznych domen prowadzi do portfolio, tym lepsza jego pozycja w wyszukiwarce). Analogicznie jak z opisem witryny, tak samo z oznaczeniem jej autora – są to zabiegi opcjonalne, lecz wciąż stosowane przez twórców witryny.
Kompatybilność z Internet Explorer
Jeśli chcemy, by nasza strona poprawnie działała w starszych wersjach Internet Explorera (o ile ktoś ich jeszcze używa), to możemy dodać do templatki taki oto zapis:
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
Informuje on przeglądarkę, żeby renderowała dokument w najnowocześniejszym trybie dostępnym w IE. Atrybut chrome=1 jest opcjonalny, ponieważ dotyczy dość archaicznego dodatku (wtyczki, pluginu) do Internet Explorera o nazwie Google Chrome Frame.
Możemy też określić konkretną wersję IE, w której chcemy wyrenderować dokument – na przykład:
<meta http-equiv="X-UA-Compatible" content="IE=10">
Czy jednak to troszczenie się o użytkowników IE jest jeszcze współcześnie potrzebne? Raczej nie – Internet Explorer to już przeszłość, choć z drugiej strony tag nie zajmuje dużo miejsca w kodzie oraz istnieją witryny, które powinny być z zasady szeroko dostępne także dla użytkowników z archaicznymi przeglądarkami (np. banki, strony rządowe, instytucje publiczne).
Skrypty: html5shiv.min.js i respond.min.js
Internet Explorer 8 oraz jego starsze wersje nie rozpoznają nowych znaczników semantycznych, wprowadzonych w HTML 5, takich jak <article> , <section> , <aside> , <header> , <footer>. Aby zapewnić możliwość poprawnego wyświetlenia tych kontenerów w tych leciwych przeglądarkach stworzono skrypt o nazwie html5shiv.min.js, który dynamicznie stworzy brakujące elementy w strukturze strony i pozwoli je poprawnie ostylować w CSS. Dzięki temu nasza strona wygląda normalnie, nawet jeśli ktoś wpadnie na pomysł, żeby uruchomić ją na przedpotopowym systemie i starożytnej przeglądarce.
Kolejny problem ze starszymi wersjami IE to poprawna obsługa responsywności witryny i zapisów @media w CSS. I tutaj z pomocą przychodzi kolejny skrypt: respond.min.js, który dodaje wsparcie dla Media Queries w starszych wersjach IE. Dzięki niemu nasza strona może reagować na zmiany szerokości ekranu nawet w przestarzałych przeglądarkach.
Oczywiście na egzaminie zawodowym nie mamy dostępu do internetu (by pobrać oba skrypty) ani do starych wersji IE, stąd nie podepniemy tych kodów JS do naszej strony podczas egzaminu praktycznego. Warto jednak znać przeznaczenie tych popularnych skryptów, chociażby w ramach przygotowania do pytań testowych.
Poprawne podpięcie obu tych skryptów jest opatrzone warunkiem – całość wygląda tak:
<!--[if lt IE 9]>
<script src="html5shiv.min.js"></script>
<script src="respond.min.js"></script>
<![endif]-->
Zapis <!--[if lt IE 9]> to właśnie warunek – sprawdzamy z jaką przeglądarką mamy do czynienia i tylko jeżeli (ang. if) będzie to IE w wersji mniejszej od 9 (lt oznacza ang. less than, czyli mniejszy niż) to skrypty zostaną rzeczywiście wykorzystane podczas renderowania widoku dokumentu przez przeglądarkę.
Podpięcie arkusza CSS
Dołączenie arkusza stylów do dokumentu HTML oczywiście nie jest trudne. Warto skorzystać z wtyczki Emmet w Visual Studio Code – zapis link:css wstawi do kodu następujący znacznik:
<link rel="stylesheet" href="style.css">
Ponadto, jeśli edytujemy właśnie plik z rozszerzeniem .html lub .htm to możemy w Visual Studio Code przytrzymać klawisz Ctrl i kliknąć na nazwę style.css, co automatycznie wywoła możliwość utworzenia pliku o tej nazwie w folderze projektu.
Kilka uwag praktycznych:
- Nie dodajemy już w tym tagu atrybutu
type="text/css"– w HTML 5 jest on zbędny. - Ścieżka do pliku powinna być względna, czyli np.
css/style.csszamiast ścieżki bezwzględnej, np.C:\Users\Desktop\style.css– na docelowym serwerze takiego folderu zwyczajnie nie będzie - Warto wykonać na egzaminie prosty test podpięcia arkusza – np. zmieniamy tło całej strony na ciemne w CSS:
body { background: darkgray; }
Jeśli po odświeżeniu strona zrobiła się ciemna – arkusz stylów jest poprawnie podpięty! Prosty test dający nam potwierdzenie podania działającej ścieżki względnej do arkusza.
Podpięcie skryptu JavaScript
Podobnie jak dla CSS, pliki JavaScript podpinamy najlepiej z zewnętrznych plików – tym razem czynimy to za pomocą podwójnego tagu <script>:
<script src="script.js"></script>
Na co warto zwrócić uwagę:
- Nie zapomnijmy zamknąć tagu – brak
</script>to błąd – mamy przecież do czynienia z tagiem podwójnym! - Współcześnie nie dodajemy już atrybutu
type="text/javascript"– jest on zbędny w HTML 5.
Test podpięcia? Wystarczy prosty testowy alert() albo console.log():
alert("JavaScript działa!");
Jeśli po odświeżeniu strony pojawia się komunikat – wiemy, iż zewnętrzny skrypt został poprawnie podpięty!
Ikonka w zakładce – favicon
Z pewnością zauważyliśmy, że praktycznie każda współczesna strona internetowa posiada swoją małą ikonkę wyświetlaną na karcie przeglądarki. To właśnie tzw. favicon – drobiazg, który dodaje stronie odrobinę indywidualizmu i sprawia, że wygląda bardziej profesjonalnie. Jak dodać favicon do kodu naszej strony?
W najprostszym wariancie wystarczy, że w sekcji <head> umieścimy taki oto wpis:
<link rel="icon" href="favicon.ico" type="image/x-icon">
Najłatwiej tego dokonać dzięki pluginowi Emmet, wpisując: link:favicon
Sam plik favicon.ico wrzucamy do głównego katalogu strony… I gotowe – przeglądarka powinna automatycznie go wykryć i wyświetlić na zakładce obok tytułu strony. Oczywiście pliki w formacie ICO to już trochę przestarzałe rozwiązanie i współcześnie dużo częściej użyjemy plików w formacie PNG, które obsługują przezroczystość i lepiej wyglądają na nowoczesnych urządzeniach. Przykładowy zapis może wyglądać tak:
<link rel="icon" href="images/favicon.png">
Domykanie pojedynczych znaczników
Kolejna kwestia do omówienia dotyczy prawidłowego w HTML 5 “kończenia” (domykania) znaczników pojedynczych. Dawniej, np. w XHTML 1.1 znaczniki pojedyncze wpisywaliśmy w następującej postaci:
<meta charset="utf-8" />
Natomiast w HTML 5 nie trzeba już dodawać zamykającego ukośnika /, stąd współczesna konwencja jest nieco krótsza:
<meta charset="utf-8">
Pojawia się zatem pytanie – a co jeśli użyjemy w HMTL 5 wersji znanej z XHTML 1.1? Cóż, nic specjalnie złego się nie stanie – przeglądarka i tak poprawnie wyrenderuje znacznik (bo zapewnia kompatybilność wsteczną). Aczkolwiek, jeśli chcesz pisać zgodnie ze specyfikacją HTML 5, to lepiej od razu nauczyć się pomijać kończący pojedyncze tagi ukośnik.
Oczywiście wiele osób nadal używa tej wersji starszej (z powodu istniejących przyzwyczajeń lub osobistych preferencji) – jest to zwyczajnie kolejny przykład tego jak płynne, powolne oraz kompatybilne wstecz jest wprowadzanie nowych standardów internetowych (w końcu “nagłe” zmiany mogą mieć wpływ na miliardy już istniejących w sieci serwisów).
To co przekonuje mnie osobiście do rozwiązania znanego z HTML 5 to fakt, iż pomijanie ukośników w wielu tagach pojedynczych spowoduje zmniejszenie liczby znaków w wynikowym źródle. A mniejsze pliki to oczywiście szybciej ładujące się podstrony! Tęsknię jednak nieco za ładniejszym podświetlaniem pojedynczych znaczników w edytorach kodu, co miało miejsce kiedy kończące ukośniki były obecne (kiedy kliknęło się taki tag, to był ładnie podświetlony – niczym ciało funkcji albo klasy). Ot, takie ambiwalentne uczucie. Tak czy inaczej, pomimo istniejącego we mnie nawyku, z czasem całkowicie przestawiłem się na zapisy najnowsze i Wam także polecam nie dodawać ukośników do znaczników pojedynczych.