Seria dokumentów -> seria tabel czy jedna ?

Wyobraźmy sobie serię faktur, w HTML wyrażamy to w najbardziej naturalny sposób, jako serię tabel.

  <table>
            <tr><th>Towar</th><th>ilosc</th><th>cena</th></tr>
            <tr><td colspan="3">Faktura nr 123 z dnia 20120.11.11</td></tr>
            <tr><td>CocaCola</td><td>1</td><td>1,80</td></tr>
        </table>
        <br/>
        <table>
            <tr><th>Towar</th><th>ilosc</th><th>cena</th></tr>
            <tr><td colspan="3">Faktura nr 124 z dnia 20120.11.11</td></tr>
            <tr><td>Ala ma Asa, As to Ali pies, nikt się z nim nie bawi bo szkolony jest</td><td>1234567</td><td>999,99</td></tr>
        </table>

Oczywiste jest, że ich estetyka się rozjedzie, tzreba by niesamowitą ilość atrybutów CSS aby zagwarantować jednolitość wszystkich dokumentów (najbardziej szerokości kolumn)

Drugi pomysł, to w HTMLu jako jedna tabela, z wygaszaniem widoczności tego i owego

  <table>
            <tr><th>Towar</th><th>ilosc</th><th>cena</th></tr>
            <tr><td colspan="3">Faktura nr 123 z dnia 20120.11.11</td></tr>
            <tr><td>CocaCola</td><td>1</td><td>1,80</td></tr>

            <tr style="bez borderów itd"></tr>

            <tr><td colspan="3">Faktura nr 124 z dnia 20120.11.11</td></tr>
            <tr><td>Ala ma Asa, As to Ali pies, nikt się z nim nie bawi bo szkolony jest</td><td>1</td><td>1,80</td></tr>

        </table>

Droga do jednolitej estetyki jest prostsza (tam mi się wydaje), ale przełożenie z obiektów modelu danych na obiekty HTML dużo mniej naturalne. Prawdopodobnie backendem będzie Map'a List pozycji dokumentowych, Lista List czy coś podobnego.

Który jest lepszy?
Jakie ciekawe przemyślenia podrzucicie?

Tabelki w HTML to nie jest nic złego. Mają bardzo złą reputację, bo w czasach IE6 i pokrewnych wynalazków, ludzie opierali na nich układ strony. A to był rak najczystszej postaci. Aczkolwiek też trzeba przyznać, że wtedy CSS i HTML nie miały połowy tego, co oferują aktualnie, więc trzeba było sobie jakoś radzić.

W każdym razie - to, o czym piszesz jest właśnie wręcz książkowym przykładem zastosowania tabelki w HTML. One właśnie do tego zostały stworzone - żeby przechowywać i prezentować dane tabelaryczne.

Jeszcze pytanie - co masz na myśli, gdy piszesz o tabeli z wygaszaniem widoczności tego i owego ? Co chcesz wygaszać/ukrywać? Bo za bardzo nie zrozumiałem tego fragmentu.

cerrato napisał(a):

Jeszcze pytanie - co masz na myśli, gdy piszesz o tabeli z wygaszaniem widoczności tego i owego ? Co chcesz wygaszać/ukrywać? Bo za bardzo nie zrozumiałem tego fragmentu.

W drugim przykładzie, obszar MIĘDZY fakturami nadal jest wewnątrz tabeli, tylko tego nie widać.
W ogóle WSZYSTKO jest jedną tabelą, nieco zmanipulowaną wizualnie

ludzie opierali na nich układ strony. A to był rak najczystszej postaci.

W tym względzie nie trzeba mnie przekonywać, jak na backendowca CSSy nie są mi obce, kilka książek Myersa zaczytałem na śmierć.
Jak tzreba to styluję Header Footer, lewą Navigation beztabelkowo

Wracając do pytania, przychylasz się do 1. czy 2. ?

Wybacz, ale nie odpowiem - bo nie wiem dokładnie, co takiego się u Ciebie dzieje.
Ale też nie rozumiem - co by miało się rozjechać? Jeśli ostylujesz tabelę w jakiś konkretny sposób, określisz rozmiary (znaczy - szerokości) kolumnt itp, to chyba każda z nich powina wyglądać identycznie. Nadal nie do końca rozumiem, w czym jest problem.

W każdym razie - jeśli będziesz miał tabele o określonych szerokościach i z takim samym układem kolumn/nagłówków itp, to chyba każda tak samo ostylowana będzie się tak samo zachowywać i wyglądać. Jak pisałem - na tabelkach można robić układy stron, jak na pałę wpiszesz rozmiar to (prawie) zawsze tak to będzie wyglądać.

Ja bym (jeśli nie ma powodów, dla których rózne tabele by miały się inaczej zachowywać) zrobił jednak osobne tabele. Jedna wielka potem może być bardziej upierdliwa w obsłudze - np. wydruki i łamanie się na kolejnych stronach, czy zaznaczenie myszką i skopiowanie.

@AnyKtokolwiek:

Oczywiste jest, że ich estetyka się rozjedzie, tzreba by niesamowitą ilość atrybutów CSS aby zagwarantować jednolitość wszystkich dokumentów (najbardziej szerokości kolumn)

Ale, że co?
Dla tabeli ustawiasz table-layout:fixed;
Dla każdej kolumny TD.nth-child(x) ustawiasz sobie taką szerokość i atrybuty, jakie chcesz.
Dla wewnętrznych nagłówków TD[colspan='3'] możesz sobie zdefiniować osobne style.
I będzie działać. Nie rozumiem, z czym masz tam problem.

A... i nie używaj inlinowego style tylko odpowiednich klas.

I jeszcze jedno pytanie, dotyczące danych tabelarycznych:

Stronicowanie (paginacja, raczej ajaxowane niż nie) czy scrolowanie (z Ajaxem)?

Wizualnie jakby świat szedł w stronę srcolowania, choć wiem z dyskusji, ze są też zwolennicy paginacji.

Pierwszy wariant, element html ~= obiekt biznesowy jest bardzo mało podatny na paginację, dobrze myślę?
Opcja (z sąsiedniego wątku) do drukowania jest uogólnia model scrolowania z inicjalnym ładowaniem dla N=max (choć uogólnia paginację też, na tej samej zasadzie)

@AnyKtokolwiek:

Jeżeli robisz stronę dla gimbusów, którzy będą ją smyrać paluszkiem, oglądając zdjęcia kotków, możesz robić doczytywanie na skrolowaniu.

Jeżeli robisz stronę dla ludzi z konkretnymi danymi, do którym mogą oni zechcieć wrócić albo zalinkować komuś innemu konkretne pozycje, to zrób paginację.

Mnie osobiście dynamicznie doczytywane strony doprowadzają do szału.

Popieram Freję - jeśli ma to być wykorzystywane biznesowo (a tak sądzę z innych Twoich postów - lista faktur itp.) to żadnego doczytywania razem ze scrollem, nie baw się w AJAXy itp. Po prostu - klikam na link "faktury", otwiera mi się odpowiednia podstrona na której mam załadowaną całą treść. Nawet jeśli to chwilę potrwa - lepiej troszkę poczekać, a potem mieć już dane załadowane, niż sobie czekać i je pobierać podczas przeglądania.