[HTML][CSS] Galeria z semantycznym kodem, Tabele? Lista? Pogodzić z... Opcje

[WebCM]

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.

[devnul]

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ę

[cbagov]

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

[WebCM]

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.

[devnul]

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ć

[cbagov]

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.

[devnul]

@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

[cbagov]

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

Ten post edytował cbagov 25.05.2008, 12:34:44

[WebCM]

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.

[cbagov]

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.

[Pilsener]

tabela służy do wyświetlania danych tabelarycznych a takimi na pewno nie są zdjęcia w galerii

- 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

[l0ud]

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

Ten post edytował l0ud 26.05.2008, 13:56:54

[Shili]

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.

[WebCM]

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.

Ten post edytował WebCM 26.05.2008, 16:45:02

[cbagov]

@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.

[devnul]

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

[Shili]

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ć ^^

[devnul]

Poza tym wielkość miniaturek - uwaga uwaga - można zmienić przez sam css, nie mówiąc już o php (tak, nawet bez GD

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ś.

[Shili]

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

[gekon]

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

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

Co do list definicji to możesz użyć ich w sposób pojęcie=podpis pod zdjęciem/opis, definicja=autor.

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.

Ten post edytował gekon 27.05.2008, 21:29:12