Tylko chodzi o wyośrodkowanie w pionie. W poziomie jest prosto. W pionie coś mi nie idzie.
Dane:
Czy ktoś ma pomysł jak to zrobić?
Dzięki. O vertical-align pomyślałem, ale od table-cell nie. Chyba z tego co wiem, to IE nie obsługuje jeszcze table-cell... No ale dobre i to.
Całe to nowe pozycjonowanie na divach i css przypomina mi bajkę o Nowych szatach cesarza... wszyscy się zachwyjcają aby nie wyjść na głupków...
Albo po prostu zobaczyli, że tworzenie na divach i w czystym CSS jest lepsze ;)
Marooned napisał(a)
Całe to nowe pozycjonowanie na divach i css przypomina mi bajkę o Nowych szatach cesarza... wszyscy się zachwyjcają aby nie wyjść na głupków...
Niestety, ale na tabelkach nie uzyskam czegoś takiego, że w jednej linii w galerii będzie mi się ustawiać tyle obrazków z opisami ile zmieści się przy danej szerokości okna przeglądarki.
Jedynym rozwiązaniem tutaj, byłoby dla każdego takiego obrazka robić tabelkę, co mi się jakoś nie widzi. Wolę więc zastosować element z nowego CSS i mieć wyświetlanie takie jakie sobie życzę w FF i Operze, a w IE odrobinę brzydsze, ale wciąż funkcjonalne, niż ograniczać funkcjonalność tylko dlatego, że jakaś przeglądarka jest zacofana.
Dodatkowo przy takim podejściu, galeria jest prawidłowo wyświetlana nawet w lynksie, który z tabelkami sobie nie radzi. Więc funkcjonalne jest wszędzie, a tylko lekko "pofalowane" w IE (ew. w innych które też nie interpretują jeszcze tego CSS).
A tabelki jak najbardziej są przydatne, ale nie do pozycjonowania, a do wyświetlania danych tabelarycznych, z czego również chętnie korzystam.
A tak poza tym... nagość jest piękna ;)
Trochę schodzę z tematu, ale w sumie problem jest rozwiązany, więc może mnie nie zbijecie ;):
A więc dla mnie są dwie główne zalety XHTML+CSS nad HTML ze starymi zwyczajami robienia grafiki/pozycjonowania:
Adam.Pilorz napisał(a)
Dodatkowo dochodzą takie rzeczy ideowe jak oddzielenie treści od prezencji.
To nie jest ideowe. Już na własnej skórze miałem okazję się przekonać, jak rozdzielenie prezentacji od treści znacząco wpływa na ułatwienie późniejszej modyfikacji. A trzeba zaznaczyć, że nie specjalizuję się w tworzeniu stronek i mam ich bardzo mało na koncie. Stąd też wnioskuję, że osoby które wiele tworzą powinny odczuwać częściej te zalety.
Ostatnio idę jeszcze o krok dalej: XML (dane) + XSL (struktura) + CSS (prezentacja). Ale jeszcze nie miałem okazji sprawdzić jak bardzo elastyczne jest taki sposób :)
XML+XSL+CSS to też fajna sprawa, ostatnio trochę się tym bawiłem. Wciąż jednak o wiele za mało umiem w tej dziedzinie, by stosować to do tworzenia stron użytkowych.
A jeśli chodzi o oddzielenie treści od prezencji może dlatego nie odczuwam tej różnicy tak silnie, bo i tak używam skryptów PHP z parserem TPL i bazą danych MySQL, więc tak czy inaczej mam to wszystko oddzielone od siebie. Statycznych stron nie tworzyłem już tak dawno, że nie odczułem tak tej różnicy.
Dryobates napisał(a)
Ostatnio idę jeszcze o krok dalej: XML (dane) + XSL (struktura) + CSS (prezentacja). Ale jeszcze nie miałem okazji sprawdzić jak bardzo elastyczne jest taki sposób :)
Ja miałem okazje, bardzo fajnie sie tak tworzy strony ale na dluższa mete jest to nieprzydatne ponieważ istnieja bardzo duże rzobieżnosci miedzy przeglądarkami:
Strona na IE 6 i Mozilli bedzie wyglądała podobnie
Na IE 5.5 wszystko sie rozkrzaczy
Na Operze nie właczy sie wcale
:/
Kooba napisał(a)
Dryobates napisał(a)
Ostatnio idę jeszcze o krok dalej: XML (dane) + XSL (struktura) + CSS (prezentacja). Ale jeszcze nie miałem okazji sprawdzić jak bardzo elastyczne jest taki sposób :)
Strona na IE 6 i Mozilli bedzie wyglądała podobnie
Na IE 5.5 wszystko sie rozkrzaczy
Na Operze nie właczy sie wcale:/
Ten ból już odczułem. O ile IE 5.5 to swobodnie olewam, bo odsetek użytkowników korzystających z niego jest już nikły, to z Operą jest problem. Ale jeżeli uda mi się załatwić xsltproc na serwerze, to dowolnym przeglądarkom będę mógł podawać już przetworzony html (chociaż traci się wtedy wiele zalet jak np. szybkość ładowania).
Dryo: A nie da się serwować przetworzonej wersji tylko userom przeglądarek nie obsługujących XML+XSL? Takich jak Opera (sick, a mawiają, że taka nowoczesna przeglądarka, a nie potrafi sobie z XSL poradzić :/ ), czy stare IE? Wtedy zachowujesz podstawową zaletę tego rozwiązania - serwowanie dokumentu XML, który może mieć więcej zastosowań niż tylko do oglądania jako strona internetowa.
Adam.Pilorz napisał(a)
Dryo: A nie da się serwować przetworzonej wersji tylko userom przeglądarek nie obsługujących XML+XSL? Takich jak Opera (sick, a mawiają, że taka nowoczesna przeglądarka, a nie potrafi sobie z XSL poradzić :/ ), czy stare IE? Wtedy zachowujesz podstawową zaletę tego rozwiązania - serwowanie dokumentu XML, który może mieć więcej zastosowań niż tylko do oglądania jako strona internetowa.
Można. Ale właśnie chciałbym mieć xsltproc, aby to automat za mnie robił, a nie samemu generować kod html, bo to się mija z celem. I wtedy zapewne wszystko prócz FF i IE6 będzie dostawało zwykły html i będzie się odrobinę wolniej ładować, ale za to FF i IE6 zyskają na szybkości.
Opery bym tak nie skazywał na klęskę. Opera dosyć niedawno zyskała wyświetlanie xml (podobno wykorzystują do parsowania ten sam silnik co FF), więc zapewne jak się pojawi większe wykorzystanie xsl to i xsl pojawi się w obsłudze.
Dryobates napisał(a)
Opery bym tak nie skazywał na klęskę. Opera dosyć niedawno zyskała wyświetlanie xml (podobno wykorzystują do parsowania ten sam silnik co FF), więc zapewne jak się pojawi większe wykorzystanie xsl to i xsl pojawi się w obsłudze.
I to jest właśnie błędne koło standartów sieciowych: obsługa xsl będzie jak zaczniemy go stosować, zaczniemy go stosować jak będzie obsługa :) Tak jest ze wszystkim.
Kooba napisał(a)
I to jest właśnie błędne koło standartów sieciowych: obsługa xsl będzie jak zaczniemy go stosować, zaczniemy go stosować jak będzie obsługa :).
Albo gdy geekowo-nerdowe kolka adoracji zaprojektuja odpowiednie bannery ktore bedzie mozna umiescic na dole bloga.
Dryobates napisał(a)
Można. Ale właśnie chciałbym mieć xsltproc, aby to automat za mnie robił, a nie samemu generować kod html, bo to się mija z celem. I wtedy zapewne wszystko prócz FF i IE6 będzie dostawało zwykły html i będzie się odrobinę wolniej ładować, ale za to FF i IE6 zyskają na szybkości.
I tu się pojawia problem. Czy rzeczywiście wszystkiemu poza FF i IE6? Przecież podstawową zaletą XML'a jest fakt, że aplikacje inne niż przeglądarki internetowe mają możliwość prostego parsowania dokumentu i wyciągania z niego potrzebnych mu danych. Jak w takiej sytuacji programista zobaczy w źródle strony piękny XML, napisze program, który to wykorzysta i okaże się, że dostanie od serwera HTML, bo aby otrzymać XML musi oszukiwać serwer mówiąc, że jest oparty na silniku Gecko albo jest Internet Explorerem :/. W tym wypadku raczej zrobiłbym na odwrót - przeglądarkom konkretnym, które XML+XSL nie rozumieją serwować XHTML, reszcie programów XML. Jak komuś pod jakąś nieprzewidzianą przeglądarką nie będzie działać, to o tym napisze i możesz ją dodać do listy.
No ale to tak w sumie trochę złażenie z tematu :P