Którą techniką najlepiej napisać kod galerii, aby był zgodny z najnowszymi trendami?

Lista i CSS
Widok miniatur obrazów w galerii jest listą, więc prawdopodobnie należy użyć znaczników <ul> i <li>. Problem w tym, że jej elementy nie dopasują się automatycznie tak jak komórki tabeli. Jest opcja: ilość obrazów w 1 wierszu. [...] Trzeba napisać trochę kodu CSS, więc aby to się opłacało, najlepiej dołączyć dodatkowy arkusz stylów. (?)
Efekt :: Kod HTML

Tabela
W przypadku dynamicznej aplikacji PHP, trzeba przekazać szablonowi, kiedy zaczyna się i kończy nowy wiersz (np. I i III element). Właściwie nie problem, choć im bardziej czytelny szablon (tzn. mniej zmiennych i instrukcji), tym lepiej.

Utworzyłem galerię przy pomocy listy. Byłoby dobrze, gdyby przeglądarki obsługiwały metodę wyświetlania display: inline-block. W IE 6 i FF 2 nie zobaczymy efektu. W FF 3 jest już dobrze. No cóż, pozostało użyć float: left. W tym przypadku wnętrze <li> wyrównuje się do góry (a najlepiej do środka lub do dołu).

Przykład: http://bugs.ugu.pl/gallery - każdy <li> ma ustaloną z góry długość, niezależnie od wyświetlanych miniatur

Pozostaje pytanie - czy w ogóle opłaca się stosować <ul> i <li> dla galerii, zważając na problemy, które mogą wystąpić?

Może w ogóle inaczej zorganizować widok galerii? Czekam na propozycje i pomoc.

Zdecydowanie Lista + CSS, a elementy się dopasują jeśli trochę pokombinujesz. I nie robiłbym tego na ul/li a raczej na dl,dt,dd ze względu właśnie na semantykę

Z uwagi na CSS i XML mozna powiedziec, ze nie ma to znaczenia.

Galeria zdjęć raczej nie jest listą definicji - odradzają to też na #web. Próbowałem zastosować <ul> i <li>. Niektóre obrazki przeskakują w następne pole (poprzednie zostaje puste). Aby osiągnąć prawidłowy efekt, trzeba ustalić taką samą wysokość i szerokość każdego znacznika <li>.

W systemie CMS chyba lepiej na razie stosować <table>, gdyż nie znamy wymiarów grafiki, którą webmasterzy umieszczą. Poczekam, aż przeglądarki u co najmniej 90% internautów będą interpretować display: inline-block. Wtedy utworzenie galerii opartej o listę nie sprawi problemu.

tabela służy do wyświetlania danych tabelarycznych a takimi na pewno nie są zdjęcia w galerii. Co do list definicji to możesz użyć ich w sposób pojęcie=podpis pod zdjęciem/opis, definicja=autor a wymiary zdjęć nie powinny mieć znaczenia bo zawsze możesz je przeskalować

Mowie, ze z uwagi na CSS, kazdy tag moze miec taki sam styl, co powoduje, ze faktycznie wystarcza 1 tag na caly kod i nie ma znaczenia jaki wybierzesz - z uwagi na XML gdzie znaczniki mozesz miec jakie sobie wymyslisz.

Oznacza to, ze czy P czy LI czy TABLE - jedno i to samo. Nalezy je jednak zostawic z uwagi na wykorzystanie konkretnych tagow przez wiele interpreterow, dla ktorych np. nie ma znaczenia CSS a ma znaczenie TAG.

Dlatego galeria czy na LI czy na TABLE czy na DIV moze dzialac tak samo. Osobiscie mam na DIV a rozmiar uploadowanej grafiki nie ma znaczenia bo system skaluje i/lub przycina albo tnac grafike albo tnac przez CSS.

@cbagov: powiem tylko jedno SEMANTYKA sprawdź może co to oznacza w kontekście sieci i z czym to się je i dopiero wtedy wróć do dyskusji

@devnul to i ja sie zrewanzuje - polecam haslo Rozumienie Tekstow Pisanych

I co z tego, że kod będzie w 100% semantyczny, jeżeli galeria może rozpaść się po dodaniu zdjęcia o innych wymiarach? Oczywiście można ustawić fabrycznie szerokość i wysokość każdego elementu <li>, lecz nie wiemy, jakie wymiary mają miniatury, które webmaster omieszka wstawić. PRAWDA?

Kiedy wreszcie będzie można użyć display: inline-block i dlaczego wprowadzili ten parametr dopiero w CSS 2.1? CSS 2 stał się standardem w 1998 roku (wersja 2.1 pewnie niedługo później). Mało kto się przez 10 lat przejmował wprowadzeniem pełnej obsługi stylów CSS 2. IE 6 i FF 2 wciąż są powszechnie używane. Nieprędko to się zmieni.

Co do miniatur - wystarczy je tworzyc samemu i zapamietac to, ewentualnie pobrac rozmiar z miniatury, nie widze problemu. A jakby tego malo bylo - jak pisalem wczesniej dla bezpieczenstwa wystarczy zrobic clipping przez CSS, ale to i tak obejmie tylko przypadki mega sczegolne.
I nie pisze z powietrza bo tak mam i to dziala bez klopotu.

- polemizowałbym. Układ 4-kolumnowy typu fotka-opis fotka-opis lub numer-fotka-opis-rozmiar-link to klasyczna tabelka. Ładnie ostylowana tabelka jest w pełni semantyczna i bardzo łatwo tworzyć dynamicznie wiersze i kolumny. Wolę ładną tabelkę, niż ktoś mi divóv od metra napaćka

Pilsener, a gdzie masz wtedy nagłowek takiej tabeli? Czy są jakieś logiczne zależności pomiędzy kolumnami a wierszami? Co jak co, ale nieuporządkowane zdjęcia nie są danymi tabelarycznymi...

zawsze można nakazać wyświetlać się liście analogicznie do tabeli, ale nie wiem - nie robiłem tego

Jednak w przypadku miniatur, o których była mowa w pierwszym poście uważam że tabela jest nadużyciem. Poza tym pociąga za sobą mimo wszystko więcej kodu, więcej pisania i więcej poprawek przy modyfikacji niż lista.

Prawie każdemu znacznikowi można nakazać, aby wyświetlał się jak tabela - patrz: display w CSS. Znów pytam - które przeglądarki w pełni obsługują te wartości? Tylko najnowsze! Mam nakazać użytkownikom instalację innego klienta? Prędzej opuszczą stronę, a webmasterzy zmienią system na inny. Pytanie - co się opłaca bardziej. Czy w ogóle da się zastosować display: table do 1 listy? Musimy zdefiniować wiersze / kolumny (?) oraz komórki (<li>).

Poruszmy tematykę semantyki CSS. Float raczej nie jest odpowiednią własnością do uzyskania efektu galerii np. 5 rzędów po 4 miniatury. Służy on do ustawienia opływania elementów. Dobry przykład: warstwa ze zdjęciem i podpisem w Wikipedii obok tekstu. Inny: wzajemne opływanie np. bloków z tekstem lub bloków układu strony. Zwiększcie szerokość 1 zdjęcia w galerii opartej o float: left - układ zacznie się sypać. Na siłę można zaradzić problemowi, dodając kolejne skomplikowane opcje CSS (przycięcie elementów w <li>?). Tylko po co się męczyć, jeśli i tak napiszemy znacznie więcej kodu niż w przypadku tymczasowego <table>? Właściwie przydałaby się jeszcze jedna wartość DISPLAY, działająca na tej zasadzie, że rozmieszcza równomiernie blokowe elementy listy obok siebie, a te, które się nie mieszczą, przenosi niżej.

Do <ul> i <li> wrócę, gdy wszystkie powszechnie używane przeglądarki zaczną interpretować display: inline-block. Chyba, że lepiej stworzyć 2 arkusze CSS - dla nowych (display: inline-block) i starych klientów (float)? Zażalenia wysyłajcie do M$ i zrzeszonych spółek - IE 7 wciąż jest w tyle pod względem obsługi CSS 2.

Poprawka: inline-block też na nic się zdaje bez podania szerokości <li>, ale widać różnicę w przeciwieństwie do float. Dodatkowy parametr overflow: hidden przytnie zawartość bloków.

Do poczytania: 2 ukryte funkcje w Firefoksie 3, problem float i galeria z użyciem inline-block.

@Shili - jesli miniatura bedzie miala opcje ladnego (funkcjonalnego) ostylowania [mam na mysli cos powaznego a nie jakis drobny background z gifa], to moze TAGow byc wcale nie mniej niz przy uzyciu tabeli.

@WebCM - powtarzasz moje slowa choc widze, ze wolisz sie rozwodzic, a co do float - specyfikacja wcale nie jest tak ograniczona jak piszesz
Float mozna stosowac do przewazajacej wiekszosci elementow blokowych.

Natomiast za pomoca display: mozna spokojnie zrobic galerie w dowolnym ukladzie, tak jak pisalem wczesniej.

@WebCM: style służą do prezentacji danych i nie mają kompletnie nic wspólnego z semantyką

Lista ma więcej możliwości modyfikacji niż tabela. Poza tym wielkość miniaturek - uwaga uwaga - można zmienić przez sam css, nie mówiąc już o php (tak, nawet bez GD ;)

Przycięcie elementów to jedna reguła, nie skomplikowana opcja - jedna linia w tekście. To jednak niewiele jak na mój gust.

Jeśli chodzi o ostylowanie - w przypadku, gdy chcemy stylować elementy mam wrażenie że trzeba napisać mniej więcej tyle samo kodu css w przypadku tabel ile w przypadku list (przy listach trzy lub cztery reguły więcej).

Wzajemne opływanie bloków strony (jeśli strona na przykład ma dużo dziwnych boxów) to dla mnie naprawdę dokładnie to samo, co wzajemne opływanie zdjęć. Ani jedno ani drugie to nie dane tabelaryczne, a skoro można uzyskać zamierzony efekt poprawnie, to ja osobiście lubię z tego korzystać ^^

z krzesła na głowę spadłeś? wiesz ile waży miniaturka 3 megabajtowego pliku jpeg przeskalowana za pomocą samych styli? zaszokuję Cię też 3 megabajty. A teraz pomnóż to razy ilość miniaturek na stronie, np 30 - wychodzi nam piękne 90 megabajtów. Nie wiem jak Tobie ale mi by się nie chciało czekać na załadowanie takiego czegoś.

Nie spadłam. Przecież jak byk w pierwszym poście jest mowa o miniaturkach, nie o oryginalnych plikach. I piszę o wielkości miniaturek, nie oryginalnych plików

A z uwagi na X/HTML ma to znaczenie (o ile ktoś zwraca uwagę na semantykę tej aplikacji XMLa/SGMLa).


Wydaje się to być nadużyciem.

A wracają do tematu: lista. Co do miniaturek nie wiem skąd mają pochodzić. Ale wydaje mi się, że jeżeli piszesz CMSa i koniecznie chcesz dać możliwość ustalenia ilości miniatur w wierszu, możesz użyć list zagnieżdżonych - chociaż lepszy rozwiązaniem jest float i clip. Chociaż IMHO powinieneś dać możliwość ustalenia tego w szablonie.

P.S.: Nie wiem czy z tym CMSem dobrze Cię zrozumiałem.

W XML to programista ustala semantyke

Po co używać display:table? Nie prościej tabelę zrobić?

- nagłówek to będzie tytuł galerii, kategoria etc, a w stopce nawigacja. Zależności są: uporządkowane, zorganizowane i celowe wyświetlenie obiektów graficznych w wiersze i kolumny. Tabela jest po to, aby uporządkować wyświetlanie jakiś danych - w tym wypadku miniaturek. Gdy zamiast miniaturek będą np. wyniki badań to też nie będzie to tabela? Trzeba mieć uprzedzenia, żeby w stercie miniaturek 4 na 20 nie widzieć tabeli - są wiersze, są kolumny, jest tabela, a co by innego?

A jak nie tabela to lista wypunktowana? A może lista definicji? Skoro nie tabela, to niby czemu lista wypunktowana? Gdzie punktory?

I jestem ciekawy, jak będziecie dynamicznie dostosowywać liczbę miniaturek i kolumn tak, aby się ładnie wyświetlało w każdej rozdziałce. Wypozycjonujecie każdego img'a relatywnie w procentach? Float dla każdego img'a?

Wystarczy lista nieuporządkowana i display-inline, jeśli to tylko obrazki.

Lista obrazków to nie tabela. Tabela w jednym wierszu ma kolumny, które ten konkretny wiersz opisują. Tutaj wszystkie komórki byłyby identyczne - dane nietabelaryczne.

Nie rozumiesz i nie widzisz subtelnej różnicy. To nie chodzi o kształt tabeli, tylko o prezentowaną treść. Miniaturki są ułożone na siatce ale nie są to dane tabelaryczne.
Tabela służy do prezentowania danych tabelarycznych a nie takich co wyglądają jak tabela.

Teraz o innym elemencie - spisie artykułów.

Aktualnie lista artykułów wygląda tak: zobacz zrzut. Jest tabelą zawierającą 2 komórki w każdym wierszu. W pierwszej znajduje się tag <img>.

Jak zmodyfikować kod, aby był semantyczny i działał poprawnie w większości przeglądarek? Czy tabela jest odpowiednim znacznikiem do opisania listy artykułów, która zawiera: obrazek, tytuł i opcjonalnie opis?

Tymczasowo użyłem listy <ul>: zobacz zrzut. Zawartość <li> raczej nie da się wyrównać do środka w pionie, co może spowodować utrudnienie w czytelności.

Ważne, aby można było dowolnie ostylować skórkę - małą ilością kodu i parametrów w CSS i HTML!

Jak dla mnie to jest klasyczna tabela - co drugi wiersz warto maznąć na trochę inny kolor. Tabele robisz bez zbędnych fajerwerków w kodzie (tylko table, td, tr, th + klasy), reszta w CSS. Wywal IMG a zamiast tego background w CSS - imgi strasznie spowalniają, stałe elementy graficzne tylko w CSS.

Choć z drugiej strony przypomina to też listę, jednak będzie z tym więcej zachodu - dla każdego <li> musisz dać obrazek w CSS, border i wyświetlanie blokowe. W każdym <li> 3 elementy (tytuł, data, tekst) - ale one muszą już być liniowe (odpadają nagłówki i <p>, zostaje <span>, <adress> czy coś tam innego). Jak dasz dla li display:block to bez problemu wyrównasz zawartość w pionie paddingiem. Elementy wewnątrz li spróbuj popchać floatem i marginesami, gdy się nie uda to pozostaje wypozycjonować relatywnie - jeśli jednak ilość tekstu będzie ulegała zmianie, możesz mieć nielichy problem z wypozycjonowaniem tego, pozostaje problem z dostosowaniem do innnych przeglądarek...

Do Ciebie należy wybór, jak to zrobić - mnie tam cieszy każdy dobry kod, co do tabel to mam liberalne podejście - zdecydowanie sprzeciwiam się budowaniu na nich szkieletu strony, a co do wyświetlania treści to nie ma o co drzeć szat. Wolę semantyczną tabelę niż modny ostatnio divitis.

To nie jest tabela, chociaż sformatowanie wygląda wypisz wymaluj na tabelę, ale to tylko wygląd. To jest nic innego jak lista. Prawda jest jednak taka, że do wycentrowania tego w pionie będziesz potrzebował dodatkowych elementów i prawdopodobnie js, aby wadliwe IE sobie z tym poradziło (jeśli rozmiar nie jest z góry ustalony). Jeśli jest centrowanie wymaga jedynie dodatkowego elementu.

Czy utrudnia czytelność to dla mnie temat dyskusyjny - wystarczy zrobić ciut większy odstęp pomiędzy kolejnymi elementami, lub wprowadzić jakąś delikatną linię.

Tak naprawdę moim zdaniem musisz teraz sam zadecydować czy chcesz się bawić w to, żeby wszystko było dokładnie tak, jak sobie wymyśliłeś, czy lepiej nadpsuć trochę semantykę dla kodu, który będzie Ci łatwiej napisać i bez obsługi js również będzie wycentrowany.

Gdy syntaktyka webowa bedzie jednoznacznie USTALONA, przegladarki beda interpretowac kod jednakowo i zgodnie wytycznymi a jezyki dojrzeja do stanu gdy nie bedzie ich kolejnych wersji, wtedy mozna bedzie wieszac sobie na szyi haslo "semantyka". Inaczej prezentowanie takiego skostnialego podejscia pachnie powierzchownoscia zrozumienia tematu albo wygodnictwem.

A podpiecie na sile powyzszego cytatu pod cytat ze mnie jest dziwne bo nie laczy sie z tematem i wymowa mojego cytatu.
Naduzywana na tym forum (sformulowanie) -semantyka-, odnosnie tagow prezentacji XML jest ustalana przez programiste. Kazdy moze tworzyc dowolne Namespace, tagi itd, jest dokumentacja mozna poczytac.
Po to powstala semantyka XML by odciac sie od semantyki HTML (o Boze to straszne).

Dopiero definicja struktury organizacyjnej dokumentu w sensie 'protokolu' moze dac prawo do wnikania w semantyke. A tak to jest tylko blablanie byle uzyc slowa zaklecia i ukryc sie za jego wieloznacznoscia.

Gdyby swiat tak strasznie sie przejmowal semantyka jak co niektorzy tutaj to mielibysmy dalej IE v.01 itp.
Kazde rozwiazanie mozna poprawic i wiele z nich przyszlo wlasnie dzieki zlamaniu zasad bo ktos wczesniej zle te zasady okreslil.

Co oczywiscie nie znaczy, ze nie stosuje sie do pewnych zasad - dajcie zyc... w koncu nic by mi nie dzialalo;) - ale skoro moge cos zrobic lepiej i chodzi to lepiej a omija np. semantyke i na dodatek to samo robi 80% swiatka bo trzeba stosowac jakis hack, trick, bo siedzialo sie godzinami probojac semantyki kiedy okazalo sie, ze po prostu jest np. BLAD w interpretacji przez przegladarke albo niezgodnosc wynikla z wielu innych codziennie spotykanych przez nas pomylek -w czasie tworzenia czegos na wyzszych szczeblach technologicznej drabiny webowej- ...

Takze kazdy nawiedzony glos o -swietej semantyce- traktuje jak dobry dowcip heh.

Bardziej semantycznie chyba nie moze byc ?: Galeria (lista,zbior) obrazów czy tez dowolnie ostylowanych templat.

Tabela oprocz innych zastosowan jest dretwa, za duzo znacznikow na takie cele, cala masa td, tr, table brr.

@Pilsener

<li> MOZE zawierac blokowe (HTML 4.01 - 7.5.3)
<p> owszem nie

Takze w <li> GENERALNIE mozna uzyc sobie <div> czyli wziac w <li> to co pod podanym linkiem siedzi w <div>ach.

Potwierdza to:
HTML 4 DTD ktory pokazuje ze LI ma %flow
a <p> ma %inline
jako zawartosc dopuszczalna.

wiec chyba nie ma o czym mowic.

A z PADDING radze uwazac i uzywac jak najmniej jesli chce sie uniknac zaskakujacych odstepow, lepiej umiescic TO cos w <span> albo drugim <div> i nadac margin: niz robic padding:.

ALE czasem mozna, trzeba zapamietac kiedy.

No chyba sobie jaja robisz. No albo po prostu nie rozumiesz.
Mam więc pytanie:
W tabeli bazie danych rozróżniasz tylko komórki (kolumny)? Nie, masz wiersze, które są opisane kolumnami.
Tak samo jest z każdą tabelą.

Tabele jest stworzona z wierszy. A wiersze są opisywane przez komórki. To są właśnie dane tabelaryczne. Zresztą masz to doskonale widoczne w kodzie. <td> jest zagnieżdżone w <tr>.
Podstawowymi elementami w tabeli są wiersze. I to właśnie jest zawartość tabeli. A dodatkowo wiersze są opisane kolumnami.

Ty zaś sugerujesz, że wystarczy coś zamknąć w siatce i będzie tabelą. Nie. Tak nie będzie.

I jeszcze odpowiedź na Twoja ciekawość. Dynamiczna ilość zdjęć w wierszu jest prostsza do osiągnięcia za pomocą elementów takich jak <ol> (<ul>) lub nawet <dd> niż za pomocą <table>.
Jak nie wiesz jak to cóż. To że czegoś nie wiesz to nie znaczy że się nie da bądź jest trudno

Wróćmy jeszcze do ostatniego problemu. Rzeczywiście najlepszym znacznikiem dla listy artykułów jest <ol>. Niestety automatyczna numeracja nie zastąpi numerów generowanych przez skrypt - atrybut start ma status "deprecated" (potępiony). Oczywiście taką listę można lepiej ostylować (choć tabelę też się da).

Spójrzcie jeszcze na dotychczasowe tabelkowe rozwiązanie. Dopóki przeglądarki nie zaczną obsługiwać w pełni CSS 2, można zapomnieć o takim efekcie w przypadku użycia <ol>. Można jednak uzyskać też ciekawy efekt: zobacz zrzut - tylko tak jak pisałem - tytuły bez opisów psują wygląd.

Chcę uniezależnić plik CSS od szablonów, które znajdują się tylko w 1 katalogu - VIEW. Skórki zawierają tylko: arkusze stylów, główny layout i ikony. Co robić? "Inwestować" w listę <ol> i czekać z nadzieją, aż będę mógł spokojnie zastosować display: table dla <ol> i display: row dla <li> (jeśli tak jest poprawnie, bo brakuje jeszcze display: cell)?

Nie masz chyba 2 kont WebMC ?

Nie masz sie tez nad czym chyba zastanawiac bo:
DEPRECATED?
Jest po pierwsze -value- a po drugie w drafcie HTML 5 nadal -start- wystepuje.
Po drugie probojesz byc bardziej semantic niz oni a HTML 5 nie jest jedynym rozwiazaniem jak wiadomo. W organizacji przy projekcie pracuja setki ludzi i zamiast medytowac nad takim drobiazgiem proponuje skupic sie na rozwiazaniach dzialajacych.
Zanim cos zostanie ustalone uplynie duzo wody, zreszta..

proponuje sie zapoznac np z tym zdaniem:

The value attribute for the li element is no longer deprecated as it is not presentational. The same goes for the start attribute of the ol element

Mike, ja to wszystko wiem, kiedyś nawet robiłem to w ten sposób - ale wyobraź sobie, że klient chciał dodać do listy artykułów nie tylko liczbę kliknięć, ale także średnią ocenę, więc moje piękne <ol> poszło na kompost - i myślisz, że klient to docenił, z jakim bólem datę i 15 pierwszych słów artykułu ostylowałem? W tabeli dwie pętle załatwiają sprawę - dodajesz pole do bazy i się pojawia a tabelka automatycznie się rozciąga - a z listą jak? Masz wiersze a w nich numer, tytuł, opis, datę - nie przypomina to danych tabelarycznych?
Ja tylko proponuję drobne odstępstwo (a może nawet i nie) od twardej semantyki na rzecz praktyki, możesz mnie za to spalić na stosie

- po prostu w sposób sarkastyczno-prowokujący strzelam tabelą w Twój autorytet

Tego typu problemy (jak zgodność ze specyfikacją HTML 5.0 czy XHTML) nie powodują przecież, że 99% stron to zupa z tagów.

Czy za semantykę warto umrzeć? Czy jeśli dodam liczbę kliknięć i średnią ocenę to będzie to już tabela, czy dalej tylko lista? Można bez tabeli osiągnąć efekt tabeli, ale czy warto? Semantyka ma mi pomagać, a kiedy zaczyna przeszkadzać i osiągnięcie efektu tabeli zajmuje dwa razy więcej czasu i kodu to czy dalej jest to zgodne z ideą semantyki?

Pilsener: Popieram. Zrobiłem trochę eksperymentów. Nie można całkowicie oddzielić szablonów od plików CSS w projekcie. Zmiana <ol> lub <div> na <table> wymaga także zmian w CSS. Aby określić minimalną wysokość elementu - dla <ol> i <div> trzeba dodać min-height, zaś dla <table> height. Za pomocą display: table / table-row też nie osiągniemy pożądanego rezultatu, gdy zabraknie table-cell - czyli trzeba odpowiednio przygotować kod HTML (min. 3 poziomy znaczników).

Można też tak napisać kod CSS, aby dodanie kolumny do tabeli sprawiło kłopot.

Wróćmy jeszcze do sprawy <img> czy background-color. Rzeczywiście znaczniki <img> trochę spowalniają. Gdy zaś obrazek ma być klikalny, tło raczej odpada. Właściwy wybór jednak zależy od tego, czy użyjemy tabeli, czy OL / DIV.

Bez problemu zrobisz klikalny obrazek na tle diva, tabeli czy innego dowolnego znacznika i do tego bez *.jpg czy *.gif jako SRC, zabezpieczony jednoczesnie przed sciagnieciem (pomijam oczyw PrtScr).