Responsywne tabele w HTML i CSS: jak je tworzyć poprawnie

Responsywna tabela nie polega na tym, żeby za wszelką cenę upchnąć wszystkie kolumny na ekranie telefonu. Najczęściej masz trzy rozsądne opcje: przewijanie poziome wewnątrz tabeli, uproszczenie danych na mobile albo zamiana w karty, jeśli tabela ma mało kolumn.

Najgorsze rozwiązanie to tabela, która rozszerza cały viewport i powoduje poziomy scroll strony. Użytkownik wtedy nie wie, czy przewija tabelę, czy całą witrynę. Google też nie lubi układów, które na mobile są technicznie dostępne, ale praktycznie nieczytelne.

Szybka decyzja: tabela, scroll czy karty?

Typ danych	Najlepszy układ	Dlaczego
Cennik z 3-4 kolumnami	Normalna tabela lub karty na mobile.	Dane są krótkie i łatwe do porównania.
Raport z wieloma kolumnami	Tabela w kontenerze z poziomym przewijaniem.	Nie tracisz relacji między kolumnami.
Lista cech produktu	Karty lub sekcje accordion.	Użytkownik czyta po jednym produkcie.
Dane finansowe	Tabela semantyczna ze scrollowaniem.	Precyzja i nagłówki są ważniejsze niż efekt wizualny.

Najbezpieczniejszy wzorzec: wrapper z overflow

Jeżeli tabela ma pozostać tabelą, owiń ją w kontener. Scroll ma dotyczyć kontenera, nie całej strony.

<div class="table-scroll">
  <table>
    <caption>Porównanie pakietów strony internetowej</caption>
    <thead>
      <tr>
        <th scope="col">Pakiet</th>
        <th scope="col">Zakres</th>
        <th scope="col">Czas</th>
        <th scope="col">Dla kogo</th>
      </tr>
    </thead>
    <tbody>...</tbody>
  </table>
</div>

.table-scroll {
  max-width: 100%;
  overflow-x: auto;
  -webkit-overflow-scrolling: touch;
}
.table-scroll table {
  width: 100%;
  min-width: 640px;
  border-collapse: collapse;
}
.table-scroll caption {
  text-align: left;
  font-weight: 700;
  margin-bottom: .75rem;
}

To rozwiązanie jest nudne, ale działa. Użytkownik mobile widzi, że tabela ma własne przewijanie, a reszta strony nie rozjeżdża się na boki.

Semantyka i dostępność

Nie buduj tabeli z samych divów, jeśli prezentujesz dane tabelaryczne. HTML ma elementy table, thead, tbody, th, td i caption po coś. Czytniki ekranu mogą dzięki temu połączyć komórki z nagłówkami.

• Dodaj caption, gdy tabela potrzebuje tytułu lub kontekstu.
• Używaj th scope="col" i th scope="row".
• Nie chowaj ważnych kolumn tylko dlatego, że ekran jest mały.
• Nie używaj tabel do layoutu strony.
• Nie blokuj zoomu na mobile.

Kiedy zamienić tabelę w karty?

Karty są dobre, gdy użytkownik porównuje pojedyncze rekordy, a nie skanuje dużą siatkę danych. Na przykład lista pakietów usług może działać jako karty. Ale tabela kosztów z wieloma miesiącami, stawkami i sumami zwykle powinna zostać tabelą.

@media (max-width: 640px) {
  .pricing-grid {
    display: grid;
    gap: 1rem;
  }
  .pricing-card {
    border: 1px solid #e5e7eb;
    border-radius: 1rem;
    padding: 1rem;
  }
}

Najczęstsze błędy

• Ustawianie width: 100vw na tabeli lub kontenerze.
• Brak max-width: 100% i overflow-x: auto.
• Zbyt długie teksty w komórkach bez łamania lub skrótu.
• Chowanie kolumn, które są potrzebne do decyzji zakupowej.
• Brak testu na realnym telefonie lub w narrow viewport.

Checklist wdrożenia

1. Sprawdź, czy dane naprawdę wymagają tabeli.
2. Dodaj semantyczne nagłówki i caption.
3. Owiń tabelę w kontener ze scrollowaniem poziomym.
4. Ustal minimalną szerokość tylko dla tabeli, nie dla strony.
5. Przetestuj viewport 360-390 px.
6. Sprawdź, czy document.documentElement.scrollWidth nie jest większy niż window.innerWidth.

FAQ

Czy poziomy scroll tabeli jest błędem?

Nie, jeśli scroll jest ograniczony do tabeli i użytkownik rozumie, że może przesunąć dane. Błędem jest poziomy scroll całej strony.

Czy na mobile lepiej zawsze robić karty?

Nie. Karty są dobre dla krótkich porównań, ale przy większych danych utrudniają skanowanie kolumn.

Czy można ukrywać kolumny na telefonie?

Można, ale tylko kolumny pomocnicze. Nie chowaj ceny, statusu, terminu ani informacji potrzebnej do decyzji.