Kurs HTML od WebKod.pl

Ostatnio coraz częściej na grupach polecany jest kurs WebKod.pl. Z ciekawości postanowiłem rzucić na niego okiem.

Kurs HTML

Uwagi ogólne

• Prawdę mówiąc nie bardzo rozumiem, czemu wiele współczesnych kursów tworzenia stron internetowych rozpoczyna się od szybkiego kursu tworzenia plików i katalogów w systemie Windows. Wydaje mi się, że można założyć, że czytelnik zainteresowany tworzeniem stron WWW zna się przynajmniej na podstawowej obsłudze komputera. Można go co najwyżej odesłać do innych, gotowych materiałów na ten temat. Zwłaszcza, że nie wszyscy czytelnicy będą używać Windowsa.

• Nie rozumiem także wciąż sporej popularności Notepada++. Od dawna nie jest to ani najpopularniejszy, ani najlepszy edytor HTML-a, jaki istnieje na rynku. Mimo to pojawia się w bardzo wielu polskich kursach jako polecany edytor. A przecież dzisiaj mamy też rozwiązania działające nie tylko pod Windowsem, jak choćby Visual Studio Code czy Atom.

• Z kolei bardzo mi się podoba, że w kursie występują analogie do świata rzeczywistego, np. pusty element HTML jest przyrównany do pustego pudełka, do którego można coś włożyć. Dobrze dobrana analogia może naprawdę ułatwić przyswajanie wiedzy.

• Nie podoba mi się za to fakt, że praktycznie w całym kursie używane są sztucznie utworzone polskie terminy, które nie występują w żadnym innym źródle. Podanie ich angielskich odpowiedników oraz zalinkowanie odpowiednich źródeł pozwoliłoby czytelnikom wyszukać dodatkowe informacje w Google. Część terminów tak bardzo odbiega od pierwotnych terminów angielskich, że nawet te terminy znając, trzeba się mocno zastanowić, o co dokładnie chodzi.

Elementy HTML

Źródłem wszystkich źródeł w mniejszym lub w większym stopniu, nawet jeżeli autorzy różnych treści na temat różnych języków budujących stronę internetową o tym nie wiedzą, jest organizacja W3C.

Nie jest to prawda. Owszem, W3C do pewnego czasu ustalał zasady dla HTML-a i DOM, ale obecnie jedyną organizacją kontrolującą HTML i DOM jest WHATWG. Co więcej, JS zawsze był pod pieczą Ecma International, jako standard ECMA-262. Z kolei rzeczy związane z przesyłaniem danych przez Sieć oraz z protokołami to działka jeszcze innej organizacji – IETF. Niektóre standardy są z kolei rozwijane przez jeszcze inne organizacje (jak np. WebGL, będące pod kontrolą Khronos Group). W3C sprawuje za to kontrolę nad standardami związanymi z XML-em (SVG, RDF, OWL itd.), dostępnością (WCAG, ARIA), CSS-em (w tym także i Houdini), bezpieczeństwem (Content Security Policy) czy Web APIs (takich jak Generic Sensor API czy Clipboard API). Niemniej na tej długiej liście nie ma HTML-a ani DOM.

Zawartość, a treść elementu HTML

Prawdę mówiąc nie rozumiem tego podziału. W innych źródłach treść jest tożsama z zawartością, jak np. w kursie na MDN czy na KursHTML.edu.pl. I z tego, co widzę, specyfikacja HTML również zrównuje te terminy:

The contents of an element are its children in the DOM.

[Zawartość (treść) elementu to jego dzieci w DOM.]

Taka ogólna definicja sprawia, że pod definicję zawartości podpada zarówno tekst, jak i inne elementy HTML.

Co więcej, to, co w tym artykule nazywa się treścią, jest po prostu tekstową zawartością elementu HTML (taką samą, jaką uzyskamy przy pomocy element.textContent). To nie do końca jest to samo, co zostanie wyświetlone. Wyświetlona treść zależy także od medium, w którym następuje wyświetlanie – ale to już zupełnie inny temat.

Komentarz języka HTML

Nie należy przesadzać z ilością dodawanych przez nas, do kodu HTML, komentarzy języka HTML, jeżeli z jakiś przyczyn musimy dbać o to, aby wielkość pliku, który będzie posiadał wspomniany kod HTML, nie była zbyt duża. Wtedy warto również ograniczyć ilość białych znaków występujących w naszym kodzie HTML.

Nie zgodzę się z takim sformułowaniem rady. Wielkość pliku HTML należy zawsze ograniczać. Zwłaszcza, że obecnie na znaczeniu zyskuje sieć mobilna, w której płacimy za każdy zużyty bajt. Dodatkowo obecnie można bardzo łatwo rozdzielić kod na dwie wersje: tę, której używamy w czasie tworzenia projektu, oraz tę, która trafia do końcowego użytkownika. Wszystko dzięki tzw. systemom budowania projektów.

Wydajność jest na tyle ważną obecnie sprawą, że wypada o nią dbać na każdym kroku, nawet w tak – wydawałoby się – błahych sprawach.

Element rodzic

Element main w tym przykładzie nie posiada swojego elementu rodzica.

To nie jest dokładnie prawda. Owszem, jeśli rozpatrujemy to wyłącznie na przykładzie kodu HTML, wówczas ten element faktycznie nie ma rodzica. Niemniej, jeśli przekleimy ten kod do przeglądarki, wówczas zauważymy, że przeglądarka sama wygenerowała cały szkielet strony, ze znacznikami html i body:

Zasady parsowania HTML dokładnie opisują, w jaki sposób się to dzieje.

Wymagane elementy dzieci

Pierwszym elementem dzieckiem każdego elementu html musi być element head. Natomiast drugim, a zarazem ostatnim elementem dzieckiem każdego elementu html musi być element body.

Nie jest to prawda. Wszystkie te znaczniki można pominąć:

• Znacznik html:

  Tag omission in text/html:

  An html element’s start tag can be omitted if the first thing inside the html element is not a comment.

  An html element’s end tag can be omitted if the html element is not immediately followed by a comment.

  [Pominięcie tagów w text/html:

  Tag otwierający elementu html może zostać pominięty, jeśli pierwsza rzecz wewnątrz elementu html nie jest komentarzem.

  Tag zamykający elementu html może zostać pominięty, jeśli bezpośrednio po nim nie następuje komentarz.]

• Znacznik head:

  Tag omission in text/html:

  A head element’s start tag can be omitted if the element is empty, or if the first thing inside the head element is an element.

  A head element’s end tag can be omitted if the head element is not immediately followed by ASCII whitespace or a comment.

  [Pominięcie tagów w text/html:

  Tag otwierający elementu head może zostać pominięty, jeśli element jest pusty lub jeśli pierwszą rzeczą wewnątrz elementu head jest element.

  Tag zamykający elementu head może zostać pominięty, jeśli bezpośrednio po elemencie head nie występuje biały znak ASCII lub komentarz.]

• Znacznik body:

  Tag omission in text/html:

  A body element’s start tag can be omitted if the element is empty, or if the first thing inside the body element is not ASCII whitespace or a comment, except if the first thing inside the body element is a meta, link, script, style, or template element.

  A body element’s end tag can be omitted if the body element is not immediately followed by a comment.

  [Pominięecie tagów w text/html:

  Tag otwierający elementu body może zostać pominięty, jeśli element jest pusty lub jeśli pierwszą rzeczą wewnątrz elementu body nie jest biały znak ASCII lub komentarz, z wyłączeniem sytuacji, w której pierwszą rzeczą wewnątrz elementu body jest element meta, link, script, style lub template.

  Tag zamykający elementu body może zostać pominięty, jeśli bezpośrednio po elemencie body nie występuje komentarz.]

Tym samym poniższy kod HTML jest poprawny składniowo, co można sprawdzić w oficjalnym walidatorze:

<!DOCTYPE html>
<title>Test</title>
<p>Whatever</p>

Ba, nawet tak dziwna konstrukcja jest poprawna składniowo:

<!DOCTYPE html>
	<html lang="en">
		<head>
			<title>Test</title>
		<p>Whatever</p>
	</body>

Należy przy tym zauważyć, że dzięki w/w zasadom parsowania HTML-a elementy html, head, body zostaną utworzone nawet wówczas, gdy nie umieścimy ich w kodzie.

Podstawowa struktura dokumentu HTML

• Pierwszą rzeczą, jaką musimy umieścić w kodzie HTML dokumentu HTML jest informacja na temat wersji języka HTML, którą chcemy się posługiwać.

  O tym wspominałem już wielokrotnie na łamach WebKrytyka. Zastanawiałem się nawet, czemu niemal wszystkie kursy HTMl-a w Polsce uparcie powtarzają tę samą bzdurę.

  DOCTYPE nie określa użytej wersji HTML, jest potrzebny wyłącznie do włączenia renderowania w trybie zgodności ze standardami:

  DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications.

  [DOCTYPE jest wymagany z powodu kompatybilności wstecznej. Jeśli się go pominie, przeglądarki często używają innego trybu renderowania, który jest niekompatybilny z pewnymi specyfikacjami. Umieszczenie DOCTYPE w dokumencie zapewnia, że przeglądarka podejmie wszelkie kroki, by ściśle trzymać się odpowiednich specyfikacji.]

  Dzięki tej informacji przeglądarka internetowa wie czego może spodziewać się po naszym kodzie HTML i jak ma go interpretować (rozumieć).

  Nieprawda. Istnieje tylko jeden sposób parsowania i renderowania HTML-a. Co więcej, jest to de facto standaryzacja parserów przeglądarek, jakich używały od lat. Innymi słowy: HTML4 od lat był parsowany według takich samych zasad, które obecnie są po prostu spisane.

• Element head musi być pierwszym elementem dzieckiem elementu html, natomiast element body musi być drugim, a zarazem ostatnim elementem dzieckiem elementu html.

  O opcjonalności w/w znaczników już wspominałem.

• Brakuje informacji o zaleceniu nadawania atrybutu [lang] znacznikowi html:

  Authors are encouraged to specify a lang attribute on the root html element, giving the document’s language. This aids speech synthesis tools to determine what pronunciations to use, translation tools to determine what rules to use, and so forth.

  [Autorzy są zachęcani do dodawania atrybutu [lang] do głównego elementu html, określając w ten sposób język dokumentu. To pomaga narzędziom do syntezy mowy dobrać odpowiednią wymowę, narzędziom tłumaczącym dobrać odpowiednie reguły tłumaczenia itp.]

Atrybuty HTML

Wartość atrybutu HTML należy podać po znaku = oraz pomiędzy podwójnym ("wartość") lub pomiędzy pojedynczym ('wartość') cudzysłowem.

Sprawa jest bardziej skomplikowana. W wielu przypadkach cudzysłowy dla atrybutów można pominąć. Rada związana z używaniem cudzysłowów bardziej dotyczy zachowania spójności stylistycznej w kodzie HTML.

Atrybut lokalny

Prawdę mówiąc pierwszy raz spotykam się z taką nazwą. Nie jest ona definiowana przez specyfikację HTML, która wyróżnia jedynie atrybuty globalne. Jest to spowodowane tym, że domyślnie każdy atrybut jest definiowany w ramach konkretnego elementu. Tym samym nie ma potrzeby dodatkowego nazywania tego typu atrybutów.

Atrybut wymagany

Moim zdaniem wypadałoby od razu wspomnieć, że atrybut [alt] jest wykorzystywany także przez technologię asystującą do przekazania informacji o zawartości obrazka osobom, które z różnych przyczyn tego obrazka nie mogą zobaczyć. Dodatkowo zaprezentowana wartość atrybutu [alt] jest złym przykładem. Technologia asystująca zazwyczaj sama oznajmia użytkownikowi, że natrafiła na obrazek, więc słowo zdjęcie jest całkowicie niepotrzebne. Dużo dobrych przykładów wartości atrybutu [alt] znajduje się w samej specyfikacji HTML.

Atrybut wymagany pod warunkiem

Element meta wraz z atrybutem http-equiv o wartości content-language oraz atrybutem content o wartości pl informuje przeglądarkę internetową o tym, że bazowym językiem, jaki posiada treść reprezentowana przez zawartość danego dokumentu HTML jest język polski.

Warto przy tym zauważyć, że ten znacznik jest niezalecany:

This feature is non-conforming. Authors are encouraged to use the lang attribute instead.

[Implementacja tej funkcji jest niezgodna ze standarami. Autorzy są zachęcani do używania zamiast tego atrybutu [lang].]

Co więcej, warto chwilę pochylić się nad pochodzeniem znaczników meta[http-equiv]. Nazwa atrybutu pochodzi od wyrażenia HTTP header equivalent (ang. odpowiednik nagłówka HTTP). Takie też zadanie mają te znaczniki: symulować zachowania określane nagłówkami HTTP. Problem w tym, że akurat nagłówek HTTP Content-Language oraz meta[http-equiv=Content-Language] znaczą coś zupełnie innego. Znacznik służy do określania domyślnego języka treści na stronie WWW, z kolei nagłówek HTTP służy do określania zakładanego targetu strony:

The „Content-Language” header field describes the natural language(s) of the intended audience for the representation.

[Nagłówek Content-Language opisuje naturalny język lub języki zakładanej grupy odbiorców danej reprezentacji (strony).]

Tym bardziej używanie tego znacznika meta jest niezalecane.

Adres zasobu internetowego

• Ciąg znaków .png jest informacją dla przeglądarki internetowej o tym, że nasz docelowy zasób internetowy o nazwie zwierze-01 posiada rozszerzenie .png, czyli jest plikiem typu PNG, który może reprezentować obrazek formatu PNG.

  To nieprawda, bo przeglądarki internetowe nie analizują URL-ów. Wszelkie informacje o tym, z jakim typem pliku mamy do czynienia, wyciągają z tzw. typu MIME. Jest on przekazywany przy pomocy nagłówka HTTP Content-Type lub też zgadywany przez przeglądarkę. Z kolei rozszerzenie może byc użyte przez serwer do ustawienia odpowiedniego typu MIME zwracanego zasobu.

• Ponadto adresem niektórych zasobów internetowych może być adres URI. Adres URI jest podobny do adresu URL z tą różnicą, iż za pomocą adresu URI możemy precyzyjniej określić, który zasób internetowy znajdujący się w danym miejscu rzeczywiście nas interesuje.

  Taki podział nie istnieje i de facto wszyscy używają tylko jednego terminu, URL. WHATWG wręcz odrzuca wszelkie inne terminy (takie jak URI i IRI):

  Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.

  [Standaryzacja wokół terminu URL. URI i IRI jedynie wprowadzają zamieszanie. W praktyce ten sam algorytm jest używany dla obu rzeczy, więc rozróżnianie pomiędzy nimi nie pomaga nikomu. URL dodatkowo zdecydowanie wygrywa konkurs popularności wyszukiwania.]

  Dodatkowo wytłumaczenie terminu URI jest błędne. URI należałoby rozumieć po prostu jako nadzbiór URL-ów. Niemniej na Sieci URL-e i URI-e to de facto to samo, ich składnia jest identyczna. Tym samym przy pomocy URL-a również można określić dokładne miejsce w danym zasobie.

Brakujące elementy HTML podstawowej struktury HTML

Nie bardzo widzę potrzebę sens rozbijania informacji o podstawowej strukturze HTML na dwie lekcje. Osobiście zrobiłbym to w jednej, a w kolejnych lekcjach skupił się na znaczeniu każdego elementu takiej struktury.

Kategorie główne

Faktycznie, znaczniki HTML są podzielone na kategorie. Niemniej wyszczególnione w specyfikacji kategorie są inne od tutaj zaprezentowanych. To, co jest tutaj wymienione, to po prostu podrozdziały rozdziału specyfikacji opisującego elementy HTML.

Sekcje

Element body nie jest sekcją, tylko sectioning root (ang. korzeń sekcjonujący). Oznacza to, że nagłówki zawarte w body nie „wypływają” na zewnątrz. Niemniej miałoby to znaczenie tylko wówczas, gdyby przeglądarki zaimplementowały algorytm outline’u.

Kategorie ogólne

Podział na kategorie zaprezentowany w tej lekcji to jedyny podział występujący w specyfikacji. Nie do końca jednak widzę potrzebę ponownego dzielenia elementów HTML, skoro już to wcześniej zrobiliśmy.

Zawartość opływająca

Nie do końca zgodzę się z takim tłumaczeniem nazwy tej kategorii. Opływanie w kontekście standardów sieciowych raczej kojarzy się ze słowem float. Co więcej, opływanie ma dość konkretne znaczenie, np. obrazek opływany przez tekst to obrazek, który jest otoczony przez tekst z jednej strony.

W przypadku elementów z grupy flow content chodzi raczej o swobodne „pływanie”. To elementy, które po prostu można wrzucić do grupującego elementu i wszystko będzie dobrze. Nie muszą w żaden sposób siebie nawzajem opływać.

Na to, że mówimy tutaj o elementach praktycznie bez dodatkowych ograniczeń, wskazuje także definicja (a raczej jej brak) ze specyfikacji HTML:

Most elements that are used in the body of documents and applications are categorized as flow content.

[Większość elementów używanych wewnątrz ciała dokumentów i aplikacji jest umieszczona w kategorii treść pływająca.]

Zawartość namacalna

To tłumaczenie jest bardzo niezręczne. Żaden znacznik HTML nie jest namacalny. W terminie palpable chodzi o elementy, które produkują treść przeznaczoną dla użytkownika. Innymi słowy: możliwą do uchwycenia przy pomocy zmysłów. WCAG w tym kontekście używa o wiele lepszego słowa – perceivable – postrzegalny.

Sekcja zawartości

To tłumaczenie jest błędne. Sectioning content to zawartość sekcjonująca (tworząca sekcje).

Nagłówek zawartości

Tutaj sytuacja analogiczna: błędne tłumaczenie. Heading content to zawartość „nagłówkująca” (tworząca nagłówki).

Taki wybór tłumaczenia dziwi mnie o tyle, że w innych przypadkach content było traktowane jako podmiot, a nie przydawka.

Konteksty HTML

Konteksty występowania danych elementów są informacjami nienormatywnymi. Lepiej posługiwać się tzw. content model (ang. modelem zawartości). Model ten określa, jakie dokładnie elementy-dzieci i w jakiej konfiguracji mogą się znajdować w konkretnym elemencie. Jest to zatem odwrotność kontekstu, który określa, w jakim rodzicu dany element się może znaleźć.

Kontekst wewnętrzny

W tym momencie dochodzi do wymieszania dwóch różnych (w/w) pojęć, co wprowadza chaos terminologiczny. Konteksty to inny koncept niż model zawartości.

Z tego też powodu pozwolę sobie pominąć cały rozdział poświęcony na opis poszczególnych kontekstów, ponieważ nie ma on żadnego pokrycia w tym, jak definiuje to specyfikacja HTML.

Kontekst logiczny

To, co jest opisywane w tej lekcji, jest tak naprawdę opisem semantycznego HTML-a. Nie widzę żadnego powodu, by termin semantyka zastąpić terminem kontekst logiczny.

Zarys korzenia sekcji

Cały dział opisujący nagłówki (Progres V) nie tylko nie jest zgodny ze stanem rzeczywistym, ale dodatkowo jest szkodliwy. Wszelkie mechanizmy w nim opisane nie zostały zaimplementowane w przeglądarkach. Dodatkowo algorytm outline’u zostanie prawdopodobnie usunięty ze specyfikacji. Tym samym powinno się stosować nagłówki tak, jak robiło się to w HTML4.

Nagłówek treści

Informacje zawarte w tej lekcji są szkodliwe z punktu widzenia technologii asystującej. Nagłówek h1 oznacza główny nagłówek strony i powinien wystąpić tylko raz. Co więcej, wspomniane sekcje nie są tworzone, ponieważ żadna przeglądarka nie zaimplementowała algorytmu outline’u – o czym wspominałem przed chwilą.

To także sprawia, że większość działu Progres VI zawiera informacje niezgodne ze stanem rzeczywistym.

Dane kontaktowe

Treść reprezentowana przez zawartość elementu address może odnosić się tylko do treści reprezentowanej przez zawartość elementu body lub tylko do treści reprezentowanej przez zawartość elementu article […]

Taki opis jest zgodny z definicją elementu address w specyfikacji HTML. Niemniej w specyfikacji HTML 5.2 definicja ta była bardziej rozluźniona:

The <address> element represents contact information for a person, people or organization.

[Element address reprezentuje informacje kontaktowe dla osoby, osób lub organizacji.]

Trwa dyskusja nad wprowadzeniem tej zmiany do obecnej specyfikacji HTML. Według mnie taka zmiana jest potrzebna, bo obecna definicja tego elementu jest dziwnie ograniczająca.

Treść główna dokumentu HTML

Maksymalnie jeden element „main” może znaleźć się w części BODY dokumentu HTML.

To nie jest do końca prawda. Specyfikacja zezwala na wiele elementów main, pod warunkiem, że tylko jeden jest widoczny:

A document must not have more than one main element that does not have the hidden attribute specified.

[Dokument nie może zawierać więcej niż jednego elementu main, który nie posiada atrybutu [hidden].]

Ranga wartości treści

Pomijając dość niefortunną nazwę lekcji, jej treśc niejako podważa dotąd opisywany podział na sekcje. W chwili, gdy uznajemy, że o poziomie nagłówka decyduje nie jego zagnieżdżenie w sekcji, a numer w nazwie, koncept sekcji zaczyna się sypać.

Semantyka tekstu – element „dfn”

Nie mogę się zgodzić, że informacja niesiona przez znacznik dfn przeznaczona jest dla przeglądarki internetowej. Na jej poziomie jedyne, co ten znacznik zmienia, to domyślne stylowanie danego fragmentu tekstu. Sam znacznik z kolei może być wykorzystany przez automatyczne analizatory treści do wyciągania dodatkowych metadanych albo przez technologię asystującą (pod warunkiem, że przeglądarka dany znacznik przekazuje do drzewka dostępności). Dotyczy to większości znaczników odpowiadających za dodatkowe znaczenia tekstu.

Semantyka tekstu – element „cite”

Element cite służył pierwotnie do oznacza wyłącznie tytułów dzieł. Taka też definicja wciąż figuruje w specyfikacji HTML:

The cite element represents the title of a work […].

[Element cite reprezentuje tytuł dzieła […].]

Rozszerzona wersja definicji znajdowała się w specyfikacji HTML 5.x:

The <cite> element represents a reference to a creative work. It must include the title of the work or the name of the author (person, people or organization) or an URL reference, or a reference in abbreviated form as per the conventions used for the addition of citation metadata.

[Element cite reprezentuje odniesienie do dzieła. Musi on zawierać tytuł dzieła lub nazwę autora (osoby, osób lub organizacji), lub odniesienie w postaci URL-a, lub odniesienie w skrótowej formie, takiej jak w konwencjach używanych przy cytowaniu.]

Osobiście nie zgadzam się z żadną definicją, chociaż bliżej mi do definicji od WHATWG. W przypadku wspominania danego dzieła, umieszczałbym w cite zarówno autora, jak i tytuł dzieła, traktując je jako całość. Zgodziłbym sie na zaznaczenie jedynie autora cytatu w cite, ale tylko i wyłącznie wewnątrz blockquote.

Niemniej wszystkie trzy definicje odnoszą się do opisu dzieła, nie zaś – autora. Nawet definicja od W3C zakłada, że chodzi o użycie nazwiska autora w kontekście konkretnego utworu lub dzieła. A to sprawia, że wyjaśnienie podane w lekcji jest błędne, tak samo jak przykład.

Semantyka tekstu – element „data”

To wytłumaczenie nie ma sensu. Definicja elementu data brzmi następująco:

The data element represents its contents, along with a machine-readable form of those contents in the value attribute.

[Element data reprezentuje swoją zawartość, wraz z jej formą możliwą do odczytania przez maszyny, umieszczoną w atrybucie [value].]

Innymi słowy, używamy tego znacznika, gdy treść prezentowana użytkownikowi różni się znacząco od tej, która byłaby zrozumiała dla zautomatyzowanych systemów czytających treść. Przykładem mogą być wartości liczbowe zapisywane tekstem dla użytkownika i liczbą dla maszyn:

<p><data value="10">Dziesięć</data> lat dostał.</p>

Semantyka tekstu – element „var”

Ten znacznik nie jest ograniczony wyłącznie do zmiennych matematycznych. Może służyć także do oznaczania zmiennych lub stałych w programach komputerowych, ale także w innych kontekstach. Za specyfikacją HTML:

The var element represents a variable. This could be an actual variable in a mathematical expression or programming context, an identifier representing a constant, a symbol identifying a physical quantity, a function parameter, or just be a term used as a placeholder in prose.

[Element var reprezentuje zmienną. Może to być faktyczna zmienna w wyrazeniu matematycznym lub w kontekście programowania, identyfikator reprezentujący stałą, symbol identyfikujący wielkość fizyczną, parametr funkcji lub po prostu termin użyty jako zaślepka w treści.]

Semantyka tekstu – element „samp”

Podany przykład jest bardzo niefortunnie dobrany. Użytkownika ani systemu automatycznego przetwarzania danych w tym kontekście nie interesuje fakt, że data została wygenerowana przez inny program. Istotna jest tutaj informacja, że to data określająca ostatnie logowanie – a więc znacznik time. Bardziej fortunnym przykładem mogłoby być np.:

<p>Program w odpowiedzi na żądanie mógłby zwrócić <samp>OK</samp>.</p>

Semantyka tekstu – element „kbd”

Warto by dopowiedzieć, że znacznik kbd oznacza dowolny input ze strony użytkownika, nie tylko taki przy pomocy klawiatury. Za specyfikacją HTML:

The kbd element represents user input (typically keyboard input, although it may also be used to represent other input, such as voice commands).

[Element kbd reprezentuje dane wprowadzane przez użytkownika (zwykle przy pomocy klawiatury, niemniej może reprezentować inne typy wprowadzanych danych, jak np. komendy głosowe).]

Żeby jednoznacznie zaznaczyć, że oczekujemy naciśnięcia klawiszy, można użyć zapisu kbd > kbd:

<p>Naciśnij <kbd><kbd>Y</kbd></kbd></p>.

Niemniej sama specyfikacja zaznacza, że taki poziom precyzji nie jest potrzebny i jedno kbd starczy.

Semantyka tekstu – element „i”

Znacznik i ma o wiele szersze znaczenie i oznaczanie idiomów zdecydowanie nie jest jego najpopularniejszym powodem użycia. Za specyfikacją HTML:

The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts.

[Element i reprezentuje fragment tekstu w alternatywnym nastroju lub głosie, lub fragment tekstu o odmiennej jakości od otaczającego go tekstu, taki jak desygnacja taksonomiczna, termin techniczny, wyrażenie idiomatyczne, fraza obcojęzyczna, transliteracja, myśl lub nazwa statku w zachodnim tekście.]

Semantyka tekstu – element „u”

Ten znacznik nie służy wyłącznie do oznaczania błędów. Za specyfikacją HTML:

The u element represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt.

[Element u reprezentuje fragment tekstu zawierający niewyartykułowaną, ale równocześnie bezpośrednio wyrenderowaną, nietekstową adnotację, taką jak oznaczenie tekstu jako nazwy własnej w chińskim tekście (chiński znak typograficzny nazw własnych) lub oznaczenie tekstu jako zawierającego błąd ortograficzny/gramatyczny.]

Wypada przy tym zauważyć, że prawie zawsze istnieje bardziej pasujący do sytuacji znacznik, a sama specyfikacja odradza używanie znacznika u:

The default rendering of the u element in visual presentations clashes with the conventional rendering of hyperlinks (underlining). Authors are encouraged to avoid using the u element where it could be confused for a hyperlink.

[Domyślna prezentacja elementu u w reprezentacjach wizualnych wchodzi w konflikt z konwencjonalną prezentacją linków (podkreślenie). Autorzy są zachęcani do unikania elementu u w miejscach, w których może być pomylony z linkiem.]

Semantyka tekstu – element „em”

Ten element nie ma nic wspólnego z podlinkowaną emfazą, będącą środkiem stylistycznym. Chodzi o emfazę typograficzną, związaną ze zmianą akcentowania w mowie.

Treść w postaci mapy klikalnych obszarów

Prawdę mówiąc w roku 2019 nie widzę za bardzo sensu w uczeniu i używaniu znacznikow map. Mamy wszak SVG, które pozwala nam na robienie o wiele ciekawszych rzeczy niż toporne mapy obrazków. Jak bardzo starym i nieprzystającym do obecnej rzeczywistości elementem jest map, świadczy choćby inicjatywa jego zamiany w element do osadzania rzeczywistych map na stronach WWW.

Treść pochodząca z innej technologii

Tę lekcję można spokojnie usunąć, bo ostatnimi pluginami były Flash i Java, które są martwe od lat. Obecnie embed może posłużyć do zamieszczenia SVG albo plików multimedialnych. Jest zatem alternatywą dla znacznika object

Zagnieżdżony kontekst przeglądarki internetowej

To tłumaczenie jest błędne. Nie istnieje coś takiego jak kontekst przeglądarki internetowej. Specyfikacja HTML posiada za to koncept tzw. browsing context (ang. kontekstu przeglądania). W praktyce kontekst taki jest tożsamy z globalnym obiektem window. Nie jest natomiast oknem czy też kartą przeglądarki, która zawiera także interfejs graficzny (pasek adresu, przyciski Wstecz i Dalej itd.).

Atrybut „typemustmatch” elementu „object”

Ten atrybut został usunięty ze specyfikacji. Co więcej, przykład nie działa co najmniej w Chrome i Firefoksie.

Zdolność fallback

Strasznie dziwne tłumaczenie. Specyfikacja używa terminu fallback content, który raczej tłumaczyłbym jako treść zastępcza.

Treść w postaci zasobu multimedialnego

Różne przeglądarki internetowe mogą obsługiwać różne typy zasobów multimedialnych, lecz z reguły zasób multimedialny typu .mp3 oraz zasób multimedialny typu .mp4 obsługiwany jest przez większość przeglądarek internetowych w najnowszej wersji.

Ta informacja jest na tyle uproszczona, że jest przez to błędna. Nie istnieje coś takiego jak zasób multimedialny typu .mp4. To rozszerzenie pliku wskazuje na kontener, wewnątrz którego wykorzystane mogą być różne kodeki, takie jak H.264 czy HEVC. Jak skomplikowana jest sytuacja z formatami multimediów, dobrze pokazuje (zdezaktualizowana już) tabelka formatów na MDN. Obecnie trwają prace nad jednym, wspólnym formatem dla wszystkich przeglądarek, AV1.

Element media – atrybut „autoplay”

Warto tutaj dodać informacje o tym, jak przeglądarki obsługują samoodtwarzające się multimedia. Pokazany przyklad najprawdopodobniej nie zadziała na urządzeniach mobilnych, ponieważ odtwarzany film nie jest wyciszony.

Element media – dodatkowy zasób internetowy

Za pomocą elementu track możemy wskazać dla przeglądarki internetowej zasób internetowy, który ma pełnić rolę dodatkowego, tekstowego, pojawiającego się w określonym czasie zasobu internetowego przeznaczonego dla zasobu internetowego reprezentowanego przez któryś z elementów HTML należących do kategorii element media.

To zdecydowanie najdziwniejsza definicja napisów do filmów, jaką widziałem.

Struktury HTML

Nie do końca rozumiem, czemu termin struktur HTML został w ogóle wprowadzony. Wszystko w HTML-u tworzy pewne struktury. Wydaje się to być nadmiernym rozbuchaniem terminologicznym.

Wiersz tabeli HTML

Każda tabela HTML zbudowana jest z poziomych wierszy ułożonych pionowo.

Dość niefortunne wyjaśnienie, ponieważ wiersze tabeli wcale nie muszą tworzyć pionowej kupki. Dodatkowo takie sformułowanie powoduje większy narzut poznawczy (poziome elementy w pionowym ułożeniu). O wiele bezpieczniej jest stwierdzić, że tabele składają się z poziomych wierszy oraz pionowych kolumn lub, jeszcze ogólniej, dane tabelaryczne są dwuosiowe.

Komórka tabeli HTML

Zgodnie ze specyfikacją atrybut [border] powinien być zastąpiony przez CSS.

Nagłówek tabeli HTML

Użycie słowa nagłówek w tym kontekście może prowadzić do chaosu terminologicznego. Specyfikacja definiuje caption jako tytuł tabeli:

The caption element represents the title of the table that is its parent, if it has a parent and that is a table element.

[Element caption reprezentuje tytuł tabeli, która jest rodzicem elementu caption.]

W praktyce caption zawiera najczęściej nie tylko sam tytuł, ale także opis zawartości tabeli.

Część TFOOT tabeli HTML

Nie jest wymogiem, aby element „tfoot” był ostatnim elementem dzieckiem elementu „table”, jednak najczęściej tego typu rozwiązanie jest najlogiczniejsze.

Taki wymóg istnieje:

Contexts in which this element can be used:

As a child of a table element, after any caption, colgroup, thead, tbody, and tr elements, but only if there are no other tfoot elements that are children of the table element.

[Konteksty, w których ten element może być użyty:

Jako dziecko elementu table, po wszelkich elementach caption, colgroup, thead, tbody i tr, ale tylko wtedy, gdy wewnątrz elementu table nie ma innych dzieci będących elementami tfoot.]

Jest on potwierdzony w modelu zawartości elementu table:

Content model:

In this order: optionally a caption element, followed by zero or more colgroup elements, followed optionally by a thead element, followed by either zero or more tbody elements or one or more tr elements, followed optionally by a tfoot element, optionally intermixed with one or more script-supporting elements.

[Model zawartości:

W tej kolejności: opcjonalnie element caption, po którym następuje zero lub więcej elementów colgroup, po których opcjonalnie następuje element thead, po którym następuje zero lub więcej elementów tbody albo jeden lub więcej elementów tr, po których następuje opcjonalnie element tfoot, opcjonalnie wszystkie te elementy wymieszane mogą być z jednym lub więcej elementami skryptowymi.]

Wymóg ten pojawił się 16 grudnia 2015 roku.

Formularz HTML – atrybuty z grupy FORM

Specyfikacja nazywa te atrybuty attributes for form submission (ang. atrybuty służące do wysyłki formularza).

Formularz HTML – element „input” typu „checkbox

Ponadto, aby zasób internetowy, do którego zostaną przekazane dane formularza HTML, z którym została powiązana nasza przykładowa grupa pól wyboru typu checkbox mógł obsłużyć daną, która reprezentowana była przez wspomnianą grupę pól wyboru typu checkbox, z której mogliśmy wybrać więcej niż jedno pole, do nazwy danej każdego elementu input, który tworzył wspomnianą grupę pól wyboru typu checkbox należy dodać ciąg znaków [].

Pomijając karkołomny język tego zdania, nie jest to prawdą. Taki wymóg istnieje tylko w przypadku używania PHP, inne technologie (np. Node.js) mogą sobie bez problemu radzić z nazwami bez []. Co więcej, w PHP również da się takie dane obsłużyć, używając surowych przesłanych danych, a nie tych, które PHP zmielił do tablicy $_POST:

<?php

function getPOSTData() {
	$raw = file_get_contents( 'php://input' );
	$split = explode( '&', $raw );
	$data = [];

	foreach( $split as $entry ) {
		list( $key, $value ) = explode( '=', $entry );
		$key = urldecode( $key );
		$value = urldecode( $value );

		if ( !array_key_exists( $key, $data ) ) {
			$data[ $key ] = urldecode( $value );
			continue;
		}

		if ( !is_array( $data[ $key ] ) ) {
			$data[ $key ] = [ $data[ $key ] ];
		}

		$data[ $key ][] = $value;
	}

	return $data;
}

var_dump( getPOSTData() );

Powyższy kod to dość naiwna implementacja parsowania danych przesłanych metodą POST w PHP (nie bierze pod uwagę choćby danych binarnych). Analogicznie można to zrobić dla danych otrzymanych GET, pobierając pełny URL z $_SERVER[ 'REQUEST_URI' ].

Kategorie HTML związane z formularzem HTML

Sama specyfikacja zaznacza, że jest to podział historyczny:

Mostly for historical reasons, elements in this section fall into several overlapping (but subtly different) categories in addition to the usual ones […].

[Głównie ze względów historycznych elementy w tej sekcji należą do kilku nakładających się na siebie (ale subtelnie różniących się) kategorii, niezależnie od zwykłych kategorii […].]

Z tego też powodu podział ten nie ma de facto żadnego znaczenia praktycznego.

Kurs CSS

Tutaj miała się pojawić recenzja kursu CSS, ale… ten artykuł i bez tego jest już nieprzyzwoicie długi. Dlatego też kurs CSS pojawi się za miesiąc.

Podsumowanie

Nie bardzo rozumiem założenia tego kursu. Zaczyna się dość niewinnie, od stworzenia katalogu, w którym będziemy przechowywać naszą stronę, by szybko przejść do teoretycznych kruczków i smaczków wyciągniętych wprost ze specyfikacji HTML. Czytelnik bombardowany jest wręcz niezliczoną liczbą szczegółów i terminów, które w codziennej pracy webdevelopera nie przydają się absolutnie w niczym. ¾ tego kursu można spokojnie zastąpić odesłaniem do oficjalnego walidatora, który zadba o poprawność składniową HTML-a naszej strony.

Co więcej, informacje zawarte w kursie opierają się o stare wersje standardu HTML, a dodatkowo nie uwzględniają niemal w ogóle jakichkolwiek dobrych praktyk obecnych w środowisku. Widać to zwłaszcza po tym, z jaką wręcz przesadzoną skrupulatnością opisany jest niemal każdy aspekt podziału strony na sekcje. I znów: w większości to jest wiedza czysto teoretyczna, mająca nikłe przełożenie na praktykę.

Tak, jak Samurajowi zarzucałem nadmierny nacisk na praktykę, tak tutaj muszę zarzucić coś zgoła przeciwnego: zbytni nacisk na teorię. Tutaj praktyki de facto nie ma. Wszystkie informacje przekazywane są niejako w pustce, w oderwaniu od kontekstu i żywego przykładu, na którym można by przećwiczyć. Dodatkowo liczba wprowadzanych pojęć oraz to, w jaki sposób są tłumaczone na polski, pogłębia istniejący chaos spowodowany brakiem kontekstu.

Z tego też powodu nie mogę polecić kursu HTML z WebKod.pl