How2HTML.pl

Dzisiaj przyjrzymy się nieco bliżej jednemu z popularniejszych kursów HTML w Polsce, How2HTML. Sprawdźmy, czy zasługuje na swoją popularność!

Uwaga ogólna

W kursie jest bardzo dużo błędów ortograficznych i interpunkcyjnych. Najbardziej razi pisownia wyrazów takich jak naprawdę (tutaj zapisywane jako na prawdę).

Strona główna

Na stronie głównej znajduje się minisłowniczek pojęć, a w nim także i samo HTML5:

Najnowsza zatwierdzona specyfikacja języka HTML (28.10.2014).

To nieprawda. Ostatnia zatwierdzona specyfikacja HTML to HTML 5.2 z 14 grudnia 2017 roku. Obecnie trwają pracę nad kolejną wersją, HTML 5.3, które można można śledzić na GitHubie. Nie można też zapomnieć, że równolegle istnieje HTML LS, które jest aktualizowane co kilka dni (a czasami wręcz kilka razy dziennie).

Niemniej informacja o tym, że najnowszą specyfikacją jest ta z 2014, jest cenną wskazówką co do tego, jak aktualny jest ten kurs. Zwłaszcza, ze obecnie specyfikacja HTML 5.0 jest oficjalnie uznana za zastąpioną przez nowszą.

HTML4, HTML5 czy HTML 5

  • Na tej podstronie znajduje się historia walki o poprawną nazwę HTML5. Problem polega na tym, że WHATWG już lata temu porzuciło tę nazwę, nazywając swój standard po prostu HTML, podczas gdy W3C wróciło do spacji, traktując 5 jako numer wersji, nie zaś – część nazwy (np. HTML 5.3).

    Inna rzecz, że przy opisywaniu tego typu informacji, moim zdaniem, wypada podawać linki do odpowiednich źródeł. Ogólnie jestem strasznym przeciwnikiem bezźródłowych treści, gdyż są po prostu nieweryfikowalne.

  • Nowy standard nie jest jeszcze oficjalnie zatwierdzony, jednakże jego implementacje od dawna można spotkać w nowych wersjach przeglądarek internetowych.

    Mam wrażenie, że poszczególne części kursu mają różną aktualność. Ta informacja bowiem zaprzecza informacji ze strony głównej, o wydaniu HTML5 jako standardu.

Deklaracja Html

Informacje na tej podstronie są błędne. Deklaracja dokumentu nie służy do informowania przeglądarki, z jakim typem dokumentu ma do czynienia. Ta informacja jest odczytywana z nagłówka Content-Type, a dokładniej – przesłanego w nim typu MIME. Zatem dokumentami HTML są wszystkie zasoby HTTP, których typ MIME to text/html.

Z kolei DOCTYPE jest pozostałością po trybie standardów i zaznacza to sama specyfikacja.

Znacznik HTML

Po deklaracji rodzaju dokumentu, czas na deklarację języka, w którym dokument zostanie napisany. Deklaracji języka html dokonujemy znacznikiem <html>.

Ta informacja jest błędna. Informacja, że mamy do czynienia z HTML-em, pochodzi z typu MIME. Co więcej, znacznik html może być całkowicie pominięty, co nie wpłynie w żaden sposób na działanie strony. Tak po prawdzie główną rolą tego znacznika jest definicja języka treści strony:

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 definiowania atrybutu lang na głównym elemencie html, podając język dokumentu. To pomaga narzędziom do syntezy mowy wykryć, jakiej wymowy powinny użyć, translatorom wykryć, jakich reguł używać, itp.]

Informacja o tym atrybucie jest w wypadku kursu całkowicie pominięta.

Znacznik HEAD

Pomiędzy znacznikami <head> i </head> zamieszcza się informacje m.in o rodzaju języka, którym będziemy się posługiwać (polski, angielski, itd.).

W tym celu powinno się używać wspomnianego już html[lang]. Co prawda istnieje metatag służący oznaczaniu języka, ale nawet specyfikacja ostrzega przed jego użyciem i proponuje użycie w zamian atrybutu [lang].

Polskie znaki HTML

  • Deklaracja ta warunkuje poprawne wyświetlanie polskich liter, w szczególności tych z ogonkami (ąćęłńśóźż). Dokonujemy tej deklaracji w sekcji <head>.

    Nie jest to do końca prawda, bo kodowanie znaków jest ustawiane poprzez nagłówek Content-Type. Dopiero w drugiej kolejności pod uwagę brany jest metatag.

  • Moim zdaniem informacja o kodowaniu ISO-8859-2 jest niepotrzebna, a przynajmniej – za mało restrykcyjna. Strony muszą używać UTF-8.

Edytor HTML

Oczywiście jeśli notatnik Wam w zupełności wystarcza ja nie widzę, żadnych przeciwwskazań, żeby nadal go używać.

Osobiście uważam, że tego typu rady są szkodliwe. Istnieją potężne, darmowe edytory pokroju Atoma czy Visual Studio Code, które posiadają wszelkie wyobrażalne ułatwienia dla programistów. Notatnik nie ma żadnego z nich – nawet podświetlania składni. Co więcej, domyślnie zapisuje pliki w kodowaniu windowsowym, sprawiając tym spore problemy.

Nie chodzi o to, że nie da się pisać stron w Notatniku – bo się da. Niemniej po co się męczyć z czymś niedoskonałym i prymitywnym, skoro tuż obok istnieją programy tysiące razy lepsze i w dodatku darmowe?

Paragraf Akapit HTML

Dygresja polonistyczna: nienawidzę tej kalki z języka angielskiego. Paragraf i akapit mają w języku polskim mimo wszystko inne znaczenia. Mimo że definicja słownikowa pozwala na pewną wymienność tych pojęć, to jednak używa się ich w dwóch zupełnie różnych kontekstach. I uważam, że w tych kontekstach powinny pozostać. Paragraf niech zostanie paragrafem, a akapit – akapitem.

Linia Horyzontalna HTML

  • Znacznik hr nie oznacza już linii horyzontalnej, a separator tematyczny:

    The hr element represents a paragraph-level thematic break […]

    [Element hr reprezentuje separator tematyczny na poziomie akapitu […]]

  • Co więcej, przytoczona definicja wskazuje na fakt, że hr powinno być używane w obrębie jednej sekcji, do rozdzielania akapitów. Niepoprawnym jest natomiast używanie hr do oddzielania sekcji:

    There is no need for an hr element between the sections themselves, since the section elements and the h1 elements imply thematic changes themselves.

    [Nie ma potrzeby używania elementu hr pomiędzy sekcjami, ponieważ same elementy section i h1 implikują zmianę tematyczną.]

    Co prawda w przykładzie w kursie nie występuje znacznik sekcjonujący (taki jak section), niemniej występują nagłówki, które są niejako wyznacznikami sekcji.

Pogrubienie Tekstu HTML

  • Pogrubienia tekstu w języku HTML możemy dokonać za pomocą elementu <strong> oraz <b>.

    Nie jest to prawdą. Chociaż obydwa znaczniki renderowane są jako pogrubiony tekst, żaden z nich nie służy do pogrubiania. Nie można utożsamiać znaczników HTML z ich wyglądem!

    Znacznik strong służy do oznaczania tych fragmentów tekstu, które są szczególnie ważne w danym kontekście, np.

    <p><strong>Nieprawdą</strong> jest, że <code>strong</code> służy do pogrubiania.</p>

    Z kolei znacznik b służy do wyróżniania poszczególnych fragmentów tekstu, ale bez nadawania im ważności, np.

    <b>Język HTML</b> jest przegenialny!

    Co prawda różnica ta jest wyjaśniona na samym końcu tej podstrony, ale nie do końca właściwie (bowiem element b nie formatuje niczego – jest jedynie powiązany z pewną domyślną reprezentacją wizualną) oraz… na końcu. Obawiam się, że spora liczba osób do tego fragmentu może już nie dotrzeć.

  • Znacznik <strong> (ang. mocny, bądź wzmocnienie) jest nowym znacznikiem wprowadzonym w specyfikacji HTML5.

    Nieprawda. Element ten został wprowadzony w HTML 4.

  • Zaleca się używania elementu <strong>.

    Nieprawda. Wszystko zależy od tego, co chcemy osiągnąć. Jeśli chcemy pogrubić tekst dla samego pogrubienia, to wówczas najlepiej zastosować span z odpowiednimi stylami. Jeśli chcemy wyróżnić jakieś słowo (np. będące słowem przewodnim danego akapitu), wówczas można użyć b. Jedynie jeśli chcemy zaznaczyć ważność jakiegoś fragmentu tekstu, wówczas powinniśmy użyć strong.

Pochylenie Tekstu / Kursywa HTML

  • W gruncie rzeczy tutaj zarzuty są identyczne jak w przypadku strong i b.

    Pochylenia tekstu w języku HTML możemy dokonać poprzez elementy <em> oraz <i>.

    I znów: te znaczniki nie służą do formatowania tekstu, to jedynie ich domyślna reprezentacja wizualna. Znacznik em służy do oznaczania miejsc, w których ma zostać zmieniony akcent w wymowie (np. do wyrażenia ironii).

    Zaiste, <em>piękny</em> widok!

    Z kolei znacznik i służy m.in. do oznaczania terminów technicznych czy obcojęzycznych.

    Markdown to <i lang="la">de facto</i> standard.

  • Element <em> (ang. emphasize – podkreślenie, uwypuklenie) jest nowym znacznikiem wprowadzonym w specyfikacji HTML5.

    Nie jest, istniał już w HTML4.

  • Element <i> nie ma żadnego semantycznego znaczenia, służy jedynie do formatowania tekstu poprzez jego pochylenie.

    Zalecane jest używanie elementu <em>.

    Element i ma bardzo spore znaczenie semantyczne (o wiele szersze niż em!) i wręcz powinien być stosowany w większości przypadków.

Zmniejszenie Tekstu HTML

Znacznik small nie służy do zmniejszania tekstu. Służy do oznaczania tzw. małego druku (informacji pobocznych, not prawnych itd.). Zmniejszony rozmiar fonta to jedynie jego domyślna reprezentacja wizualna.

Nie można mylić znaczenia danego znacznika z jego reprezentacją wizualną, bo to dwie, całkowicie różne rzeczy! Znacznik small, mający rozmiar większy od nagłówka h1, wciąż bowiem będzie reprezentował mały druk – mimo że jego wygląd będzie temu przeczył.

Podświetlenie Tekstu HTML

I znów: semantyka nie ma nic wspólnego z reprezentacją wizualną! Znacznik mark służy do oznaczania tych wyrazów, które są istotne w innym kontekście. Brzmi to dość zawile, ale chodzi głównie o to, że oznacza się wyrazy, do których później się będzie odwoływać w innym miejscu (np. słowa wyszukane przy pomocy funkcji „Znajdź” w edytorze tekstu).

Przekreślenie Tekstu HTML

Znaczniki del, ins są znacznikami „edytorskimi”. Ich najsensowniejszym użyciem są oficjalne dokumenty, które muszą mieć odpowiednio oznaczane poprawki, najczęściej z datą i autorem edycji. Można o nich myśleć jako o HTML-owej implementacji trybu recenzji z Worda. Tego kontekstu bardzo brakuje w kursie.

Co więcej, przykłady w kursie są błędne lub niepełne, ponieważ znaczniki te oznaczają zmiany w obrębie konkretnego dokumentu, nie zaś – w relacji do innych dokumentów. Link odnoszący się do już nieistniejącego artykułu powinien być przekreślony przy pomocy s. Z kolei przykład ins można uznać za poprawny, niemniej brakuje owego kontekstu formalnego dokumentu.

Lista Uporządkowana HTML

A jak uzyskać inny rodzaj numerowania listy uporządkowanej, np. cyfry rzymskie, czy litery? Efekt ten możemy uzyskać używając języka CSS, jednak na razie, żeby nie wprowadzać za dużo nowości, nie będziemy się tym zajmować.

Nie jest to do końca prawda, ponieważ znacznik ol posiada atrybut [type], który określa rodzaj listy. W przypadku mocno formalnych dokumentów (ustawy, regulaminy) sposób numeracji listy staje się niezwykle istotną sprawą i w takim wypadku staje się wręcz częścią treści, nie zaś – elementem formatowania.

Lista Definicji HTML

Tylko taka krótka uwaga: to nie jest już lista definicji, a lista wartości klucz-wartość (specyfikacja HTML 5.x z kolei określa ją jako listę termin-opis).

Tytuł Listy HTML

W celu dobrania odpowiedniego nagłówka, będziemy musieli się zastanowić jak istotna jest nasza lista dla całości artykuły.

Ta porada jest szkodliwa. O doborze nagłówka nie decyduje ważność, a hierarchia treści. Jeśli lista znajduje się w artykule, który ma nagłówek h2, wówczas lista może mieć wyłącznie nagłówek h3. Wybranie niższego spowodowałoby, że powstałaby luka w hierarchii, co może być problemem choćby dla technologii asystującej. Wybranie wyższego spowodowałoby, że lista stałaby się równoważna artykułowi lub stałaby się ważniejsza od niego.

Adres URL, Protokoły HTTP

Konstrukcja URL-a jest niepoprawnie opisana. URL składa się z tzw. schematu (często utożsamianego niepoprawnie z protokołem), dwukropka, opcjonalnego podwójnego slasha i reszty, wśród której można znaleźć „władzę” (ang. authority; w przypadku adresów sieciowych będzie to domena) i ścieżkę. Taka składnia jest opisana w oficjalnym standardzie.

Czemu nie można utożsamiać schematu z protokołem, najdobitniej pokazują linki typu mailto:comandeer@comandeer.pl. Jak widać, nie mamy tutaj protokołu (mailto: nim nie jest), nie występuje też podwójny slash.

Domena Subdomena

  • Jeśli subdomena [www] nie zostanie przez nas utworzona, a w pasku adresu wpiszemy nazwę tej (nieutworzonej) subdomeny, zostanie nam wyświetlona treść domeny głównej.

    Nie jest to prawdą. Jeśli tej subdomeny nie utworzymy, to po prostu nie będzie działać. Niemniej większość hostingów taką domenę tworzy domyślnie.

  • Przekierowań dokonuje się w pliku znajdującym się na serwerze, tzw. .htaccess […]

    Nie jest to do końca prawdą. W taki sposób robi się przekierowania wyłącznie w serwerze Apache. Niemniej nie działa on w serwerze nginx czy IIS.

Własność [atrybutu] zapisywana jest zawsze w cudzysłowie podwójnym " " bądź pojedynczym ' '.

Nie jest do końca prawdą. Atrybuty w HTML5 nie muszą być otaczane cudzysłowami.

Tekst Linka HTML

Ta podstrona jest w moim odczuciu szkodliwa. Sprowadzenie tekstu linka wyłącznie do SEO jest wręcz zabójcze dla dostępności i użyteczności. Tekst linka powinien informować o tym, dokąd link prowadzi. I to w taki sposób, żeby nie był on zależny od kontekstu, gdyż niektóre czytniki ekranowe pokazują linki w formie listy.

Nofollow Dofollow Linki HTML

  • Atrybut ten [[rel]] stosowany jest głównie na potrzeby pozycjonowania.

    Absolutnie nie! Ten atrybut służy do określania relacji pomiędzy obecnie przeglądaną stroną, a zasobem, do którego linkujemy. Innymi słowy: definiuje typ linku.

  • Atrybut rel przyjmuje wartości dofollow (ang. podążaj) oraz nofollow (ang. nie podążaj). Domyślnie przyjmuje on wartość dofollow, dlatego stosujemy go tylko w drugiej sytuacji.

    Wartość dofollow nie istnieje. Poza tym wartości tego atrybutu jest o wiele więcej.

Zewnętrzne Linki HTML

Dobrą praktyką jest stosowanie protokołu http:// przed nazwą domeny, wtedy przeglądarka od razu wie, że jest to link zewnętrzny.

Nie jest to dobra praktyka, lecz wymóg. Linki bez protokołu są praktycznie zawsze traktowane jako relatywne.

Wymiary Obrazu HTML

Atrybutów width i height możemy jedynie używać do określania rozmiarów elementu <img> do określania rozmiarów innych elementów html, będziemy używać języka CSS.

Nie jest to do końca prawda, bo wiele elementów w HTML posiada te atrybuty, m.in. canvas, iframe, video.

Figure Figcaption Obraz HTML

Sugerowanie, że figure > figcaption służy do podpisywania zdjęć, jest bardzo mocnym nagięciem funkcji tych elementów. Co prawda jest zaznaczone, że te znaczniki służą do oznaczania samodzielnych części dokumentu, niemniej nie zostaje podany żaden wyznacznik tej samodzielności (np. możliwość przeniesienia na podstronę będącą indeksem ilustracji).

Sekcje Tabeli HTML

Każdą tabele można podzielić na trzy sekcje, które definiują nagłówek, ciało, a także stopkę tabeli. Taki podział może przydać się nam przy formatowaniu tabeli, gdy będziemy do niej dodawać zasady CSS. Jednak nie jest on konieczny do wprowadzenia. Jest to raczej kwestia semantyczna.

Uważam ten tekst za niezmiernie niefortunny. Stwierdzenie, że podział tabeli na nagłówek, ciało i stopkę pomaga w stylowaniu, samo w sobie jest dość niebezpieczne. Dodanie do tego informacji, że jest to opcjonalne, bo to „tylko semantyka”, jest jeszcze gorsze. Z punktu widzenia dostępności taki podział jest wręcz niezbędny. Wspominają o tym specjaliści od dostępności, m.in. Heydon Pickering czy Adrian Roselli.

Elementy Blokowe i Liniowe HTML

Zawartość tej strony jest bardzo dużym uproszczeniem. Nie wszystkie wymienione elementy blokowe są blokowe (np. li zachowuje się jak element blokowy, ale jest tak naprawdę elementem listy, co pozwala mu być poprzedzonym przez punktor). Nie wszystkie wymienione elementy liniowe są liniowe (np. linki zachowują się różnie w zależności od kontekstu i swojej zawartości).

Warto też zwrócić uwagę na to, że specyfikacja HTML5 odeszła od nazywania elementów blokowymi i liniowymi, wprowadzając kilka innych kategorii.

Klasy i id

Występuje pełna dowolność w nadawaniu nazw atrybutu id. Ja jednak polecam używanie nazw angielskich, wtedy nasz kod będzie prawdziwie międzynarodowy…

Nieco bym rozluźnił tę zasadę, żeby wprowadzić punkty nawigacyjne w języku strony – w myśl zasady, że URL jest częścią UI.

CSS podstawy – Kurs CSS

  • Sam sposób zapisu selektorów i reguł CSS jest dowolny jeśli chodzi o używanie białych znaków, czyli spacji i enterów. Natomiast dobrą praktyką jest taki zapis.

    Jest to jedno z tych miejsc, w których aż się prosi, żeby podać jakikolwiek link, który potwierdzałby, czemu jest to dobra praktyka i że ktoś ją faktycznie stosuje.

  • W którym zatem miejscu możemy umieścić element <style>?

    w zasadzie w całym dokumencie html, zarówno w sekcji <body> jak i <head>, z jednym warunkiem, zawsze powyżej elementu, którego formatowanie dotyczy

    Kurs powołuje się na specyfikację z 2014, która zabrania umieszczania style w body. Co prawda w nowej wersji specyfikacji ta restrykcja już nie istnieje, niemniej nie sądzę, żeby kurs się do tej wersji odwoływał. Takie przynajmniej odnoszę wrażenie po już przeczytanej części kursu. Żeby było jeszcze ciekawiej, HTML LS nie zezwala na style w body.

    Co więcej, wymieniony warunek również nie musi być spełniony, ponieważ style są globalne dla całej strony (oprócz tych aplikowanych wewnątrz Shadow DOM). To oznacza, że nieważne, kiedy je dodamy, będą dotyczyć wszystkich elementów na stronie. Jedyny minus deklaracji stylów po stylowanym elemencie to niepotrzebne przerysowywanie strony.

  • Element <link> umieszczamy zawsze w sekcji <head>.

    Nieprawda. Akurat element link jest dozwolony w body (w obydwu standardach). Co prawda jedynie niektóre typy link mogą być w body, niemniej arkusze stylów są jednym z nich. Pozwala to na bardzo ciekawe optymalizacje.

  • Nie bardzo rozumiem sens sekcji Co wpisujecie w Google, aby znaleźć się na tej stronie?. Bo przecież nie jest to tani chwyt na Google, prawda?
  • Brakuje mi też wspomnienia o tym, że stylowanie po [id] to zła praktyka.

Layout Strony

Kod podany na tej podstronie jest antywzorcem z punktu widzenia dostępności, ponieważ dwa linki do tego samego zasobu nie dość, że znajdują się obok siebie, to mają jeszcze różne etykiety.

Najlepiej byłoby potraktować logo jako część nawigacji, co rozwiązałoby problem.

DIV HTML – Sekcje Strony

Element <div> może być użyty do wielu celów na stronie. Natomiast element <header> powinien zawierać elementy sekcji nagłówkowej. Są to elementy tzw. specjalnego przeznaczenia. Możemy ich używać wszędzie na stronie tak jak elementu <div>, ale żeby nasz kod był zgodny z dobrymi praktykami powinniśmy stosować je zgodnie z ich przeznaczeniem.

To dość niefortunne tłumaczenie znaczenia tych znaczników. Brakuje od samego początku kursu wyraźnego podziału na warstwę semantyki i warstwę prezentacji, co owocuje właśnie takimi problemami.

Section HTML5

Ostatni przykład z zagnieżdżaniem sekcji nie ma sensu, ponieważ główna sekcja nie ma żadnego nagłówka (a sekcja bez nagłówka jest praktycznie divem). Ten kod powinien wyglądać tak:

<section>
	<h2>Krótkie historyjki</h2>
	<section>
		<h3>Dlaczego łabędzie połykają kamień, gdy odchodzą?</h3>
		<p>Łabędzie znane są…</p>
	</section>
	<section>
		<h3>Powrót Kormoranów.</h3>
		<p>Doskonale wyszkoleni wodni rybacy przygotowują się do powrotu.</p>
	</section>
</section>

Wsparcie elementów HTML5

Kod pokazujący dołączenie HTML5 Shiva jest nieaktualny, bo Google Code od lat już nie istnieje. Można zamiast tego odwołać się choćby do JSDelivr:

<!--[if lt IE 9]>
	<script src="https://cdn.jsdelivr.net/npm/html5shiv@3.7.3/dist/html5shiv-printshiv.min.js"></script>
<![endif]-->

Input type HTML

  • Element <input> jest samozamykającym się elementem. Jednak prawidłowy jego zapis wymaga jeszcze deklaracji typu. Typu deklaracji dokonujemy poprzez atrybut type (ang. typ).

    Nieprawda, atrybut ten jest opcjonalny:

    The missing value default is the Text state.

    [Domyślną wartością w przypadku niezadeklarowania jest Text.]

  • Wartość ta, czy inaczej te dane, przesyłane są dalej formularzem. Możemy np. podać swój adres email wpisując go w pole input, i wtedy powiemy, że wartością pola input jest ten nasz adres email. Wartość może również sami nadać elementowi input stosując atrybut value.

    Nie jest to do końca prawda. W specyfikacji HTML bowiem od samego początku istnieje błąd i atrybut [value] nie określa faktycznej wartości pola, a domyślną.

  • Stosowanie atrybutu value, będzie miało również sens, gdy zablokujemy użytkownikowi możliwość edycji danego pola. Jak tego dokonać? Możemy tego dokonać stosując atrybut disabled.

    Problem polega na tym, że wyłączone pola formularzy nie zostaną przesłane do serwera. Odpowiada za to algorytm wysyłania formularzy.

    W takim wypadku lepiej użyć atrybutu [readonly].

Placeholder HTML

W praktyce natomiast może być różnie i nie zawsze będziemy chcieli dodawać element label, czasem użycie samego atrybutu placeholder będzie po prostu wygodniejsze.

Jak zostało zauważone na tej podstronie nieco wcześniej, nawet specyfikacja HTML przed tym przestrzega. Tłumaczyłem to swego czasu.

Input Radio HTML

Za pomocą paragrafu dodamy jeszcze opis czego dany wybór dotyczy […]

Do takich celów powstał dedykowany znacznik fieldset wraz ze znacznikiem legend:

<fieldset>
	<legend>Dodatki:<legend>

	<label><input type="radio" name="food"> Frytki</label>
	<label><input type="radio" name="food"> Ziemniaki</label>
	<label><input type="radio" name="food"> Ryż</label>
</fieldset>

Submit HTML

Osobiście uważam, że input[submit] powinien być wspomniany w drugiej kolejności, po przedstawieniu lepszego od niego w niemal każdym aspekcie elementu button.

HTML lang pl – deklaracja języka

  • Cieszy mnie, że kwestia języka treści nie została jednak pominięta i pojawia się w kursie. Nie rozumiem jednak tego rozbicia. Podczas gdy znacznik html poznajemy na samym początku, jego jedyny (poznany w kursie oczywiście!) atrybut – niemal na samym końcu. A przecież mówimy tu o jednym z najbardziej podstawowych elementów strony.
  • Nieprawdą jest, że w HTML4 do określania języka najczęściej stosowano metatag ani to, że [lang] to nowy sposób z HTML5. Ten atrybut istniał także w HTML4.

Title HTML – tytuł strony

  • Nie opisywałbym dobrania odpowiedniego tytułu jako działania SEO, bo jest to przede wszystkim działanie na rzecz dostępności i użyteczności strony.
  • Nie istnieje lista dozwolonych separatorów tytułu. Wewnątrz znacznika title można użyć niemal dowolnych znaków Unicode. Ba, można nawet używać znaczników, które ostatecznie i tak zostaną przekonwertowane na tekst.

Niesamowite spłycenie tematu. Oprócz tych dwóch zastosowań, link można wykorzystać do podpięcia manifestu web aplikacji, RSS, Atoma, innych wersji językowych strony, strony autora, strony z płatnościami, strony z regulaminem…

Box Model CSS

Mam wrażenie, że w tym rozdziale po prostu opisano nadawanie rozmiarów elementom HTML bez wspomnienia o faktycznym box modelu.

Tyle. Co prawda nie jest to kurs zły (widziałem gorsze i to o wiele), niemniej oparty jest na starej wersji specyfikacji HTML5. Dodatkowo popełnia jeden z podstawowych błędów i skupia się na warstwie prezentacyjnej HTML-a, niemal całkowicie pomijając kwestię semantyki. A szkoda.

A tak przy okazji: wesołych świąt!

11 komentarzy do “How2HTML.pl”

  2. Drogi Comandeerze,
    czy masz jakieś dobre źródło wskazówek nt. definiowania zawartości nagłówka H1? Chodzi mi o to,że w wielu miejscach (skupiających się głownie na SEO, nie semantyce) spotykam się ze wskazówką, że znacznik H1 powinien być na każdej podstronie inny, np. na stronie produktu sklepu powinen zawierać jego nazwę, a na stronie o firmie coś w stylu „O firmie”. Natomiast moja intuicja mówi mi, że H1 powinien zawierać na każdej podstronie to samo — nazwę witryny, np. nazwę firmy, sklepu czy nazwisko osoby, ewentualnie z jakimś krótkim hasłem po myślniku. Tytuł konkretnej strony powinien natomiast wylądować już w H2.
    Poza tym niezależnie od semantyki, wydaje mi się, że wyszukiwarka Google i tak jest odporna na takie „sztuczki” i potrafi wyciągnąć sobie to, co potrzeba, jeśli tylko kod jest napisany po prostu dobrze, nie trzeba się specjalnie mądrzyć.

    Odpowiedz

    1. Jeszcze kilka lat temu powiedziałbym tak samo: h1 – tytuł całej witryny, h2 – tytuł podstrony.

      Niemniej obecnie muszę się – z bólem serca – zgodzić ze specjalistami od SEO: h1 to powinien być tytuł podstrony. Jeśli weźmiemy pod uwagę, jak działają czytniki ekranowe i że pozwalają na nawigację przy pomocy nagłówków, to logicznym jest, że nagłówki powinny się odnosić do danej podstrony → https://blog.comandeer.pl/html-css/a11y/2017/07/04/o-naglowkach-slow-kilka.html#g%C5%82%C3%B3wny-nag%C5%82%C3%B3wek

      Natomiast logo/nazwa strony może zostać umieszczone po prostu wewnątrz nav, jako pierwszy element menu. Tak robi np. Heydon Pickering → http://www.heydonworks.com/

      Odpowiedz

      1. Comandeer, jeśli mogę, zająłbym ci jeszcze chwilę. 😉

        Osobiście bardziej przekonuję się do sposobu opisanego w zalinkowanym przez ciebie wpisie:
        http://www.456bereastreet.com/archive/201104/html5_document_outline_revisited/
        Z tego, co zrozumiałem, polega on na użyciu dwóch H1, dla tytułu całej witryny i podstrony oddzielnie.

        Zastanowiłem się nad tym, bo przecież strony mają menu nawigacyjne, sidebary itp. I co z nimi? Jeśli będzie tylko jedna H1, H2 znajdujące się wewnątrz menu bądź sekcji sidebara będą kompletnie nielogicznie podlegać pod …artykuł/wpis/podstronę.
        Na przykład, na moim blogu byłby taki outline:
        —- H2: Menu nawigacyjne
        — H1: Tytuł wpisu na blogu
        —- H2: Pierwszy podtytuł
        —- H2: Drugi …
        —- H2: Ostatnie komentarze (sidebar)
        —- H2: Kategorie wpisów (sidebar)
        Trochę porąbane, nie?
        To może zrobić nagłówki widgetów i menu H1-kami? Byłoby bardziej logicznie, ale czy wtedy tych H1 nie byłoby za dużo? Zapewne.

        Natomiast w zalinkowanym sposobie z H1-kami też jest problem. Bo jak chcę uzyskać taki outline:
        — H1: Tytuł mojej witryny
        —- H2: Menu nawigacyjne
        —- H2: Ostatnie komentarze (sidebar)
        —- H2: Kategorie wpisów (sidebar)
        — H1: Tytuł wpisu na blogu
        —- H2: Pierwszy podtytuł
        —- H2: Drugi …
        to muszę umieścić sidebar PRZED treścią strony (bo inaczej w outline widgety podpadną pod artykuł, a nie pierwszą H1-kę). Ale wtedy będzie to nielogiczne z perspektywy osób tab-ujących po mojej stronie (mam pasek boczny z prawej, nie z lewej), poza tym sidebar będzie ładował się przed treścią.

        Poza tym oddzielną sprawą jest backend. Bardzo upierdliwe z perspektywy backendu (szablonów) wydaje mi się żonglowanie znacznikami w zależności od kontekstu. Artykuł ma mieć tytuł w <h1>, gdy jest pojedynczy, ale gdy wyświetlamy na głównej/blogowej stronie listę artykułów, tytuły mają już być w <h2>. Nosz kurw… Szkoda, że pomysł outline opartego na sekcjach nie wszedł do życia.

        Mistrzu, co robić jak żyć? ;P

        Odpowiedz

        1. Na podanej przez ciebie stronie internet-bez-barier.com niestety też jest tak jak wspomniałem — widgety paska bocznego mają nagłówki w H2, przez co podpadają pod H1 tytułu artykułu i z tego powodu, z perspektywy outline’u, są jego częścią, co jest nielogiczne dla mnie.

          Odpowiedz

          1. Mam wrażenie, że za bardzo dogmatycznie podchodzisz do kwestii outline’u. Akurat w tym wypadku semantyka jest mniej ważna od dostępności czy użyteczności. Jeśli przyjmiemy, że nagłówki są wyznacznikami poszczególnych sekcji (co ma sens, zważając na fakt, że użytkownicy czytników ekranowych używają o wiele częściej nawigacji nagłówkami niż landmarkami), to stąd już bardzo blisko do zauważenia, że h1 powinno dotyczyć tego samego co main (względnie main > article, main > section). Owszem, wówczas h2 w sidebarze będą niejako podlegać temu h1, ale nie stanowi to problemu z punktu widzenia dostępności czy użyteczności. Hierarchia nagłówków bowiem dalej jest sensowna: główna treść jest najważniejsza (h1), a pozostałe, poboczne sekcje mają odpowiednio mniejszą ważność (h2).

            Co do podwójnego h1: tylko to jedno źródło tak naprawdę poleca tę technikę. Co ciekawe, sama strona jej nie używa. Na podstronach h1 mają tytuły artykułów, a na stronie głównej w ten znacznik opakowano logo. Osobiście wydaje mi się, że ta technika wprowadza pewien problem. Jeśli przyjmiemy, że h1 ma wskazywać na główną treść (być odpowiednikiem main), to przy wykorzystaniu dwóch h1 dla określenia witryny i artykułu dochodzimy do paradoksalnej sytuacji, w której outline witryny jest całkowicie osobny od outline’u podstrony.

            Jeśli chcielibyśmy wykorzystać h1 do oznaczenia tytułu witryny na każdej podstronie, mimo wszystko optowałbym za modelem tradycyjnym, czyli tylko tytuł witryny w h1, a tytuł podstrony w h2.

          2. Zaznaczam, że swoimi uwagami nie miałem na celu podważania twojej wiedzy. Uważam cię za fachowca, od którego można dużo się nauczyć. Po prostu staram się nie ufać autorytetom „z góry”, a szukać samodzielnie odpowiedzi na nurtujące pytania.

            Mamy kilka możliwości:
            — podejście klasyczne: niewygodne z perspektywy a11y, logiczne w outline;
            — podejście |h1| = podstrona: wygodne w a11y; nielogiczne w outline;
            — podejście |h1| x 2 = podstrona + witryna: średnio wygodne dla a11y, w miarę logiczne w outline, choć podstrony nie są częścią artykułu;
            — podejście wiele |h1| = dla podstrony, widgetów, menu i innych: zapewne kiepskie i dla a11y, i dla SEO i dla outline.

            Każde z powyższych podejść ma jakąś wadę. Może nie tyle dogmatyzują outline, co staram się, żeby był logiczny, bo po coś przecież jest. Najlepszym rozwiązaniem byłoby:
            — zaimplementowanie w przeglądarkach internetowych nagłówków HTML5, czyli takich, które są względne wobec sekcji, a nie globalne oraz wykorzystanie tej metody w kodzie;
            — skonstruowanie czytników dla niepełnosprawnych tak, by najwyższa |h1| w |main| miała priorytet nad najwyższą |h1| w ogóle (np. żeby była ogłaszana wcześniej).
            Niestety zrealizowanie powyższego celu jest niemożliwe, dlatego, zgodnie z twoją sugestią, wybiorę metodę „h1 = podstrona”, pozostawiając outline bez sensu. Nie jest to rozwiązanie, to bardziej workaround, trochę jak skiplinki. 😉
            Dzięki za merytoryczną dyskusję. Mam też nadzieję, że w przyszłości w jakiś sposób moje powyższe podpunkty się zrealizują w praktyce.

            A co do czytników: miałbyś jakiś poradnik dla webmajtrów niedoświadczonych w a11y? Nie chodzi mi o oczywiste banały jak alt w img, lecz np. na co zwracać uwagę w komunikatach czytnika ekranowego, gdy się z nim testuje strony. (Może to pomysł na wpis na twojego bloga, do którego linku swoją drogą próżno szukać na twojej głównej domenie.)

          3. Zaznaczam, że swoimi uwagami nie miałem na celu podważania twojej wiedzy. Uważam cię za fachowca, od którego można dużo się nauczyć. Po prostu staram się nie ufać autorytetom „z góry”, a szukać samodzielnie odpowiedzi na nurtujące pytania.

            Nie odebrałem tego jako atak.

            Mam też nadzieję, że w przyszłości w jakiś sposób moje powyższe podpunkty się zrealizują w praktyce.

            Są plany zmiany mechanizmu outline’u (h1 byłby nagłówkiem kontekstualnym, reszta miałaby na sztywno określony poziom). Niemniej nie wiadomo, co z tego wyniknie.

            A co do czytników: miałbyś jakiś poradnik dla webmajtrów niedoświadczonych w a11y? Nie chodzi mi o oczywiste banały jak alt w img, lecz np. na co zwracać uwagę w komunikatach czytnika ekranowego, gdy się z nim testuje strony.

            Hmmm, poleciłbym obadać materiały od Paciello Group. Na razie nie mam w planach opisywania dokładnie pracy z czytnikiem (co nie znaczy, że tego kiedyś nie zrobię).

  3. Dziękuję za odpowiedź. Z perspektywy mniej semantycznej, a bardziej programistycznej, znacznie rozsądniejsze wydaje mi sie podejście polegające na umieszczenie logo witryny w nawigacji i tytułu podstrony zawsze w h1, a nie pieprz***e się ze zmieniającym się h1 w div lub coś podobnego. Choć to rozwiązanie ma swój sens w semantyce. Niemniej ja wolałbym po prostu na stronie głównej logo zostawić tak jak na podstronach, a stronie głównej w tym _standardowym_ h1 dać po prostu ponownie tytuł strony.

    Odpowiedz

  5. >> Osobiście uważam, że tego typu rady są szkodliwe. Istnieją potężne, darmowe edytory pokroju Atoma czy Visual Studio Code

    Te kombajny? Nie, dziękuję…

    Odpowiedz

Skomentuj Soanvig Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.