Marcin Mika materiały do zajęć imiki Marcin Mika

8 klasa — 5. Wykończenie strony i debugowanie HTML oraz CSS

2026-09-06

Klasa 8 · Lekcja 5 z 6 · HTML i CSS w CodePen

Cel lekcji

  • Opisujesz błąd przez porównanie oczekiwanego i rzeczywistego wyniku.
  • Sprawdzasz HTML, selektory CSS i nadpisywanie reguł w narzędziach przeglądarki.
  • Poprawiasz jedną rzecz naraz i zapisujesz wynik testu.
  • Dopracowujesz stronę na wąskim ekranie oraz sprawdzasz klawiaturę i czytelność.

Wstęp

Gotowy kod nie zawsze oznacza gotową stronę. Menu może prowadzić w niewłaściwe miejsce, jedna karta może stracić kolor, a na telefonie pojawić się poziomy pasek przewijania. Dzisiejsza lekcja polega na świadomym sprawdzaniu projektu. Nie oceniaj go wyłącznie według tego, czy wygląda ładnie na Twoim monitorze.

Debugowanie to znajdowanie przyczyny błędu i jej usuwanie. Błędy są normalną częścią pracy. Twoim zadaniem jest wykonać powtarzalny test, a nie losowo zmieniać wiele linijek. Otwórz etap 4 i zachowaj jego kopię przed eksperymentami.

Pięć kroków poprawiania błędu

  1. Opisz problem: co miało się wydarzyć, a co widzisz? Zamiast „nie działa” napisz „link Projekt nie przewija do sekcji”.
  2. Znajdź najmniejszy fragment związany z objawem: link i id albo element i jego selektor.
  3. Sprawdź zapis i reguły. Porównaj nazwy znak po znaku.
  4. Zmień jedną rzecz. Dzięki temu wiesz, która poprawka wpłynęła na rezultat.
  5. Powtórz pierwotny test i sprawdź sąsiednie elementy. Dopiero wtedy zapisz poprawioną wersję.

Przeglądarka próbuje naprawiać część błędów HTML. Z tego powodu widoczna strona nie jest dowodem poprawności źródła. W CSS pojedyncza błędna deklaracja może zostać pominięta, podczas gdy inne nadal działają.

Narzędzia deweloperskie przeglądarki

Kliknij prawym przyciskiem myszy element w podglądzie i wybierz „Zbadaj” lub „Inspect”. W drzewie elementów znajdź odpowiedni fragment HTML. W panelu reguł sprawdź, które style do niego pasują. Przekreślona deklaracja często oznacza, że została nadpisana, a ostrzeżenie przy wartości może wskazywać błędny zapis.

CodePen pokazuje wynik w osobnym dokumencie podglądu. Jeśli inspektor zaznaczy pasek edytora zamiast karty projektu, ponownie wybierz element wewnątrz podglądu. Tymczasowe zmiany wykonane w narzędziach przeglądarki nie zastępują edycji kodu w CodePen i mogą zniknąć po odświeżeniu. Sprawdzoną poprawkę przenieś do właściwego panelu i zapisz.

Trzy celowe usterki do rozwiązania

Najpierw wykonaj je na kopii projektu. Każdą wprowadzaj i naprawiaj oddzielnie.

  • Zmień href=”#projekt” na href=”#projektt”. Link pozostaje widoczny, lecz cel nie pasuje do id. Porównaj obie nazwy.
  • Zmień klasę jednej karty z karta na karrta. Tylko jeden element traci wspólne style. Znajdź przyczynę w HTML, zamiast tworzyć przypadkową drugą regułę.
  • Usuń średnik między color a background-color w próbnej regule poniżej. Odczytaj obie deklaracje i przywróć separator.
.karta {
  color: #172033
  background-color: white;
}

Powyższy kod jest celowo błędny. Wersja poprawiona:

.karta {
  color: #172033;
  background-color: white;
}

Czytelność i wąski ekran

Responsywność oznacza dopasowanie układu do dostępnego miejsca. Na telefonie dwie karty mogą znaleźć się jedna pod drugą, a menu zawinąć się do kolejnej linii. Nie ukrywaj problemu regułą overflow-x: hidden na całej stronie: może ona odciąć treść zamiast naprawić przyczynę.

Sprawdź czytelność przy powiększeniu 200%, widoczność linków i fokusu, długość wierszy i odstępy. Jeśli dodajesz zdjęcie, użyj legalnego materiału z prawdziwym adresem i odpowiedniego alt. Obraz informacyjny opisujemy krótko w kontekście strony; dekoracyjny może mieć pusty alt. Nie wpisuj po prostu „obrazek”.

Proces debugowania: zauważ problem, znajdź element, sprawdź kod, zmień jedną rzecz i przetestuj ponownie.

Ćwiczenie krok po kroku

Zadanie: wykonaj przegląd strony i prowadź krótki dziennik usterek. Przeznacz około 10 minut na pokaz narzędzi, 25 minut na testy i 10 minut na poprawki końcowe.

  1. Otwórz kopię etapu 4. Zapisz trzy oczekiwane działania: przejście do sekcji, rozwinięcie instrukcji i reset notatki.
  2. Wykonaj trzy celowe usterki opisane wyżej, każdą osobno. Dla każdej zapisz objaw, przyczynę, poprawkę i wynik ponownego testu.
  3. Po usunięciu usterek dodaj poniższy CSS na końcu arkusza. Reguła @media zmienia wybrane style tylko przy szerokości do 600 pikseli.
  4. Zwęź podgląd do około 360 pikseli, a następnie poszerz go. Sprawdź menu, karty i długie odsyłacze.
  5. Przejdź stronę klawiaturą. Sprawdź także otwieranie details i działanie resetowania.
  6. Przeczytaj wszystkie teksty, popraw literówki i usuń treści robocze. Sprawdź, czy sekcja źródeł odróżnia własne opracowanie od materiałów zewnętrznych.
  7. Zapisz etap 5 i oddaj link lub pliki razem z dziennikiem trzech usterek.
img { display: block; max-width: 100%; height: auto; }
p, li, a { overflow-wrap: anywhere; }
@media (max-width: 600px) {
  body { padding: 12px; }
  h1 { font-size: 28px; }
  header, footer { padding: 16px; }
  .karta { flex-basis: 100%; }
}

Jak zapisać wynik testu

Przykład: „Objaw: karta Ilustracja nie miała białego tła. Przyczyna: w HTML wpisałem karrta. Poprawka: zmiana na karta. Test: obie karty mają wspólny wygląd po odświeżeniu”. To konkretna informacja, którą inna osoba może sprawdzić.

Sprawdzenie składni

W walidatorze HTML W3C sprawdzamy kompletny dokument. Sam fragment panelu HTML może wywołać komunikaty o brakujących częściach dokumentu. Do kontroli opakuj go szkieletem z lekcji 1. Zapis CSS można sprawdzić w walidatorze CSS W3C. Brak błędów składni nie gwarantuje czytelności i działania wszystkich linków, dlatego test ręczny pozostaje potrzebny.

Dla chętnych: poproś kolegę lub koleżankę o wykonanie jednego zadania na stronie bez podpowiadania. Zapisz, przy którym elemencie odbiorca się zawahał, i popraw jego opis.

Sprawdź swoją pracę

  • Udokumentowałem trzy usterki i sprawdziłem poprawki.
  • Menu, details i reset działają po końcowym zapisie.
  • Nie ma uciętej treści ani niepotrzebnego przewijania poziomego przy wąskim podglądzie.
  • Przy powiększeniu i nawigacji klawiaturą strona pozostaje użyteczna.
  • W kodzie nie pozostały celowo błędne przykłady.

Podsumowanie

Debugowanie jest pracą opartą na obserwacji i sprawdzaniu hipotez. Dobra poprawka usuwa przyczynę i przechodzi ponowny test. Strona jest teraz przygotowana do ostatniego przeglądu: sprawdzenia źródeł, prywatności i wiedzy z całego cyklu.

Materiały i źródła

Pytania kontrolne

  1. Jak opisać błąd, żeby druga osoba mogła go odtworzyć?
  2. Dlaczego zmieniamy jedną rzecz naraz?
  3. Czy poprawny wygląd dowodzi poprawności HTML?
  4. Co może oznaczać przekreślona deklaracja w inspektorze?
  5. Czy zmiany w inspektorze zapisują się automatycznie w CodePen?
  6. Jak wykryć niezgodność href i id?
  7. Co sprawdzasz po zwężeniu podglądu?
  8. Dlaczego po walidacji nadal trzeba przetestować stronę ręcznie?
ilość wywołań: 8