W dniu 2010-11-09 22:35, Marek pisze:
> <div style="width:500px">
> <div style="float:right; width:100px">tekst 2</div>
> <div style="float:left; width:100px">tekst 1</div>
> </div>
>
> Bez CSS tekst 2 będzie jako pierwszy.


Bo uzalezniasz strukture gdy juz masz w glowie projekt graficzny.

Postaw tekst 1 przed tekstem 2 jak Bozia przykazala (to spowoduje, ze
strone przeczyta dobrze screenreader, robot indeksujacy czy cokolwiek
innego, co ignoruje CSS). A teraz kombinuj jak to wyswietlic mozliwie
podobnie do tego co grafik namalowal ;-)


--
NotBear

do góry

W dniu 2010-11-10 00:26, NotBear pisze:
> Bo uzalezniasz strukture gdy juz masz w glowie projekt graficzny.

Autopoprawka - mialo byc: Bo budujesz strukture tresci gdy juz masz w
glowie projekt graficzny.

--
NotBear

do góry

On Tue, 09 Nov 2010 22:35:12 +0100, Marek wrote:

> W dniu 2010-11-09 10:33, Michał Gancarski pisze:
>> On Tue, 09 Nov 2010 10:19:28 +0100, Marek wrote:
>
>> Tu nie chodzi o "proste" layouty. Możesz podać przykład takiego, w którym
>> trzeba zniekształcać kolejność?
>
> Nie "trzeba" gdyż to określa zabieg celowy lecz "tak się dzieje". Obrazowo:
>
> <div style="width:500px">
> <div style="float:right; width:100px">tekst 2</div>
> <div style="float:left; width:100px">tekst 1</div>
> </div>
>
> Bez CSS tekst 2 będzie jako pierwszy.

Nadal nie wiemy czy to nie jest zabieg powstały po zasugerowaniu się
projektem grafika, a nie strukturą dokumentu. Bez treści ciężko ocenić.
Znajomość szerokości kolumn ułatwia rzecz.


>> Nie. Mały ekran to nadal mały ekran i mniejsza rozdzielczość. Nie zmieni
>> tego nawet najnowocześniejsza przeglądarka.
>
> U siebie w telefonie mam wyświetlacz mały tj. 640 x niewiele (nie
> pamiętam). Widzę fragment normalnej strony nawet z Flashami. Palcem ją
> przesuwam, oddalam, przybliżam. CSS jest chyba w pełni interpretowany.

Inaczej mówiąc, dostajesz upośledzone user experience.


> W
> niczym to nie przeszkadza przecież.

Wręcz przeciwnie. Oglądanie boiska przez lufcik nie jest niczym
interesującym, zarówno z punktu widzenia użytkownika jak i samego
właściciela strony, gdy najważniejsze linki zostaną schowane bo są trochę
za bardzo na prawo.


> W poprzednim telefonie 2 lata temu
> miałem podobnie choć wtedy jeszcze nie było dotykowych. Jakoś nawet nie
> pomyślałem o tym aby chcieć oglądać to w wersji bez CSS lub tekstowej.

Ale nie jesteś jedynym użytkownikiem telefonu komórkowego. Ja, na ten
przykład, w ogóle nie korzystam ze stron, które zmuszają mnie do
przewijania poziomego. Całe doświadczenie z www na smarfonach uważam za
mocno upośledzone właśnie dlatego, że dostaje się strony projektowane na
duże rozdzielczości, najczęściej bez żadnych prób ze strony autorów by temu
zaradzić. Istnieją powody, dla których popularne webowe aplikacje oferują
albo osobne interfejsy (np. lekka wersja Facebooka) albo też mają dla
każdego mobilnego systemu interfejs w formie osobnej aplikacji. "Poprawne"
interpretowanie CSSa wcale tu nie pomaga, a momentami wzmaga problem. Tryb
"artykułu" w przeglądarce na Kindle (to jest chyba Safari, w każdym razie
coś na WebKicie) uważam za strzał w dziesiątkę i kolejny zwiastun
konkretnego trendu, wedle którego strony i aplikacje www stoją przed
wyzwaniem coraz bardziej heterogenicznego środowiska, w którym pracuje ich
użytkownik.


[...]

>>> Jeśli zakładamy, że
>>> robimy serwis klasyczny,
>>
>> "Klasyczny" tzn. jaki?
>
> Taki jak w zdaniu niżej wyjaśniłem. Opiszę może innymi słowami.
> Nie posiadający specjalnego przeznaczenia (np. WAP - tylko mobilne albo
> bankowość - dobrze uwzględnić mobilne, a może jeszcze coś)

Nie sądzę by dziś istniało coś takiego jak "przeznaczenie mobilne".
Smartfon czy netbook to urządzenia, które ilościowo sprzedaą się znacznie
lepiej niż duży laptop czy desktop. Są też równoprawnym narzędziem do
korzystania z sieci. Strona po prostu istnieje albo i nie istnieje i
korzysta się z niej dobrze albo nie. To, że w ogóle jeszcze patrzymy na coś
takiego jak "przeznaczenie mobilne" (to także mój grzech), jest zwykłym
błędem.


>>> który nie wymaga aby użytkownicy czegokolwiek,
>>> co łączy się z internetem musieli mieć dostęp do strony (np. bankowość,
>>> choć banki też tego nie przestrzegają zawsze), to można darować sobie
>>> takie zabawy. Posiadacz np. telefonu z jakąś prowizoryczną przeglądarką
>>> następnym razem kupi model z normalną przeglądarką widząc co sobie
>>> narobił. :-) Za jakiś czas pewnie wszystkie telefony będą je miały.
>>> Problem więc wydaje mi się niszowy.
>
>
>> Ponownie - to nie ma nic wspólnego z "prowizorycznymi" przeglądarkami.
>> Wręcz przeciwnie.
>
> Prognozujesz, że takich urządzeń nie potrafiących wyświetlić pełnej
> szaty będzie przybywało? Hmmm... ja obserwuję dokładnie odwrotną
> tendencję. Nowsze np. telefony coraz częściej mają pełne przeglądarki.

I mają "pełne" ekraniki? Nie sądzę. Ciągły wyścig po większe rozdzielczości
nic tu nie zmieni, bo telefon ma być telefonem i nawet gdyby cały składał
się z ekarnu, będzie mały.


>> Trochę nie rozumiem przykładu. Tzn. nie wiem konkretnie co masz na myśli.
>
> Zostawmy to. To mało istotne w naszej dyskusji. Niepotrzebnie zrodzi
> poboczny wątek.
>
>>> Trywialny przykład: mieliśmy layout dwukolumnowy, a teraz ma
>>> być trójkolumnowy. Tego nie da się zrobić w CSS.
>>
>> Trójkolumnowego layoutu? Nie mogę dyskutować nie widząc kodu i tego co na
>> co się zmienia.
>
> ok
>
> <div id="container">
> <div id="lewaKolumna">tu teksty</div>
> <div id="prawaKolumna">tu teksty</div>
> </div>
>
> Za pomocą CSS nie przerobisz tego na:
>
> <div id="container">
> <div id="lewaKolumna">tu teksty</div>
> <div id="srodkowaKolumna">tu teksty</div>
> <div id="prawaKolumna">tu teksty</div>
> </div>

To jest trochę niepełny przykład, bo jeśli niezależnie od layoutu w
dokumencie istnieją trzy logicznie oddzielne sekcje, to markup powinien
IMHO wyglądać tak:

<div id="container">
<div id="section1">tu teksty</div>
<div id="section2">tu teksty</div>
<div id="section3">tu teksty</div>
</div>

I potem:

http://scarywindmills.com/ta-sama-struktura.html
http://scarywindmills.com/a-jakby-inny-layout.html

W przyszłości zamiast DIVów będą np. elementy SECTION.


> W praktyce zawsze trzeba ingerować w HTML.

Nie zawsze. To zależy od HTMLa i dokonywanych zmian.


> Wyjątki stanowią sztywne
> serwisy, które zawsze będą miały takie same sekcje, w których być może
> tło się jedynie będzie zmieniać. Nie zrobisz np. ze strony głównej WP
> sklepu internetowego zmieniając tylko CSS. A taką różnorodność przerabiam.

To jest przykład innego rodzaju, bo opisujesz dwa zupełnie różne dokumenty.
Skoro dokument się zmienia, to jego struktura powinna ulec zmianie,
zupełnie niezależnie od tego jak ma wyglądać jego layout. WP to portal z
newsami, artkułami i reklamami, a sklep to sklep - wypuszcza z siebie inną
treść, więc będzie też obudowany w innego HTMLa.


>>
>>> Nie da się zrobić layoutu pasującego do wszystkich stron WWW
>>> świata.
>>
>> Ale czy ja o czymś takim piszę?
>
> Tak to właśnie odebrałem - że strona powinna być tak zrobiona aby za
> pomocą CSS można było ją zmienić w każdą inną.

Nie da się i nie jest to potrzebne. Chodzi raczej o unikanie niepotrzebnej
roboty. W kontekście wątku jest to właśnie display: table zamiast TABLE.


>> A jest dziś jeszcze w ogóle sens w robieniu flashowych, animowanych galerii
>> zdjęć? To samo przez się brzmi podejrzanie.
>
> Dlaczego podejrzanie? :-) Flash chyba do takich celów służy.

Do galerii? No ja bym już czegoś takiego we Flashu nie robił, chyba, że
miałaby to być prezentacja, a nie strona.


> Mamy mało
> miejsca, chcemy pokazać dużo i do tego ciekawiej niż czysty HTML pozwala
> - wtedy Flash.

Ale na co nie pozwala rezygnacja z Flasha? Masz jeszcze do dyspozycji JS
aby dorzucić efekty.


>> No ja tu węszę błędne decyzje już na poziomie wyboru technologii. Dało się
>> tam chociaż linkować do konkretnego zdjęcia w galerii?
>
> Wszystko się da zrobić. Mówisz o linku HTML'owym po to aby Google go
> widziały czy o linku w sensie wykonywanej akcji "klik -> reakcja"?
>
> Jeśli o to pierwsze, to te zdjęcia z galerii prowadziły do kart
> katalogowych eksponatów, gdzie były już osadzone tradycyjnie. Dojście do
> tych miejsc jest również w "tradycyjny" sposób bo to tylko forma
> szybkiego przewodnika.

Chodzi o to, bym sobie mógł skopiować URLa, który sprawi, że flaszyk poda
mi konkretny eksponat, bez przeklikiwania się. Powiedzmy, że właściciel
galerii pisze maila do potencjalnego klienta i w nim zawarte jest coś
takiego:

"
Szanowny Panie Szczepanie!

W naszej galerii pojawiły się nowe eksponaty z XVIII wieku. Są to pięknie
zdobione pistolety, które może Pan obejrzeć pod następującymi adresami:

http://galeria.com/pistolety#nowy1
http://galeria.com/pistolety#nowy2
http://galeria.com/pistolety#nowy3
"

> Na czym błąd Twoim zdaniem polega bo nawet nie jestem w stanie domyślić
> się toru rozumowania. :-)

Nie wiem czy tam był błąd, nie zrozum mnie źle. Niemniej z Twojego opisu
nie wynika nic co wymagałoby Flasha, łącznie z "wyszarzaniem" miniaturki.
Tu powinien wystarczyć JS. Powstaje też pytanie na ile, z czysto
biznesowego punktu widzenia, właściwe jest uniemożliwienie obejrzenia
galerii użytkownikom iPhonów albo iPadów. Im dalej za zachodnią granicę tym
gorzej. Pokazanie "ciekawe" to także coś, co może oznaczać "bardziej
wkurzające", gdy ten sam klient wraca na stronę po raz dziesiąty.
Uprzedzając Twoje pytanie - tworzyłem już pełne flashowe galerie
pobierające dane z XMLów generowanych przez CMS.

*Nigdy więcej* :-)


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 2010-11-10 00:26, NotBear pisze:
> Bo uzalezniasz strukture gdy juz masz w glowie projekt graficzny.

No bo zawsze tak jest! :-D Najpierw trzeba konkretny projekt
zatwierdzony przez klienta mieć aby wiedzieć jak dobrać strukturę.
Przecież nie dam struktury HTML grafikowi i nie powiem mu "dorób do niej
projekt i zaakceptuj z klientem" :-)))

> Postaw tekst 1 przed tekstem 2 jak Bozia przykazala (to spowoduje, ze
> strone przeczyta dobrze screenreader, robot indeksujacy czy cokolwiek
> innego, co ignoruje CSS). A teraz kombinuj jak to wyswietlic mozliwie
> podobnie do tego co grafik namalowal ;-)

Nie da się bez JS :-) Ma tak właśnie być niestety. Oczywiście przykład
był uproszczony. W projekcie docelowym pojawia się czasem kolumna prawa
w zależności co CMS dostarczy plus parę innych kwestii. Dlatego
float:right jest potrzebny. Analizowałem już temat aby uniknąć w/w
sytuacji lecz tylko karkołomne (JS itp) rozwiązania byłyby alternatywą.

do góry

W dniu 2010-11-10 00:27, NotBear pisze:

> Autopoprawka - mialo byc: Bo budujesz strukture tresci gdy juz masz w
> glowie projekt graficzny.

Za szybko skomentowałem :-)

do góry

W dniu 2010-11-10 09:58, Michał Gancarski pisze:

> Nadal nie wiemy czy to nie jest zabieg powstały po zasugerowaniu się
> projektem grafika, a nie strukturą dokumentu. Bez treści ciężko ocenić.
> Znajomość szerokości kolumn ułatwia rzecz.

Zagadnienie jest dużo bardziej złożone. CMS generuje lub nie pewne
fragmenty struktury i float:right jest optymalnym rozwiązaniem. Inaczej
trzeba by pozycjonować elementy struktury za pomocą JS, a to jest chore.

> Inaczej mówiąc, dostajesz upośledzone user experience.

Tak, i miliony innych osób. Liczba rośnie :-)

> Wręcz przeciwnie. Oglądanie boiska przez lufcik nie jest niczym
> interesującym, zarówno z punktu widzenia użytkownika jak i samego
> właściciela strony, gdy najważniejsze linki zostaną schowane bo są trochę
> za bardzo na prawo.

Świata nie zmienisz. Póki co taka technologia zaczyna dominować. Gdy
wyjdą ekrany holograficzne pewnie przełom nastąpi :-)

> Ale nie jesteś jedynym użytkownikiem telefonu komórkowego. Ja, na ten
> przykład, w ogóle nie korzystam ze stron, które zmuszają mnie do
> przewijania poziomego. Całe doświadczenie z www na smarfonach uważam za
> mocno upośledzone > właśnie dlatego, że dostaje się strony projektowane na
> duże rozdzielczości, najczęściej bez żadnych prób ze strony autorów by temu
> zaradzić.

Tak zawsze będzie. Jeśli zleceniodawca nie widzi potrzeby tworzenia
takich rozwiązań, to ja go nie zmuszę. Po drugie - internet w telefonie
potrzebny jest w awaryjnych sytuacjach - gdy chcę sprawdzić kiedy pociąg
odjeżdża bo zapomniałem. Nawet z banku praktycznie nie korzystam w ten
sposób choć ma interface dla komórek. Już nie wspomnę, że zdarzyło mi
się na Allegro ceny sprawdzać - tam automatycznie w wersji "mobile"
interface ładuje się. Wkurzam się szukając opcji jak to przestawić na
normalny wygląd. Znajduję a potem dopiero zaczynam korzystać z Allegro.
Takie mam obserwacje.


> Nie sądzę by dziś istniało coś takiego jak "przeznaczenie mobilne".
> Smartfon czy netbook to urządzenia, które ilościowo sprzedaą się znacznie
> lepiej niż duży laptop czy desktop. Są też równoprawnym narzędziem do
> korzystania z sieci. Strona po prostu istnieje albo i nie istnieje i
> korzysta się z niej dobrze albo nie. To, że w ogóle jeszcze patrzymy na coś
> takiego jak "przeznaczenie mobilne" (to także mój grzech), jest zwykłym
> błędem.

Eeeee... to to mnie zagiąłeś. Powyżej forsowałeś ideę konieczności
tworzenia layoutu umożliwiającego prezentację na "prowizorycznych"
przeglądarkach mobilnych.

> I mają "pełne" ekraniki? Nie sądzę. Ciągły wyścig po większe rozdzielczości
> nic tu nie zmieni, bo telefon ma być telefonem i nawet gdyby cały składał
> się z ekarnu, będzie mały.

Ale CSS będzie interpretował coraz częściej o ile już to nie jest
standardem. Strony będą w nim wyglądały normalnie a nie ogołocone z
layoutu. Nawet niedawno nabyłem drukarkę (tak, drukarkę!), w której na
małym wyświetlaczu jakieś strony można oglądać :-))))

> To jest trochę niepełny przykład, bo jeśli niezależnie od layoutu w
> dokumencie istnieją trzy logicznie oddzielne sekcje, to markup powinien
> IMHO wyglądać tak:
>
> <div id="container">
> <div id="section1">tu teksty</div>
> <div id="section2">tu teksty</div>
> <div id="section3">tu teksty</div>
> </div>

I to właśnie nazwałem sztywnym portalowym podejściem, gdzie musi być
miejsce na bannery o ustalonych rozmiarach, nawigację, jakieś newsy i
zawsze te sekcję tam będą. DLatego to szczególny przypadek. Na co dzień
takie projekty nie powstają. Każda firma chce mieć zupełnie inny layout.
Nierzadko jakieś Flashe są stosowane: jedne wzdłuż, inne w pionie a
jeszcze inne bardziej fikuśne. Kombinacji jest tak dużo, że taki layout
jak w/w nie sprawdzi się zupełnie. Projekt graficzny bardzo rzutuje na
strukturę HTML'a przecież.

Najbardziej banalna komplikacja:

<div id="container">
<div id="section1">tu teksty</div>
<div id="containterDlaJakiegosTlaTylkoWTymProjekcie">
<div id="section2">tu teksty</div>
<div id="section3">tu teksty</div>
</div>
</div>


> Nie da się i nie jest to potrzebne. Chodzi raczej o unikanie niepotrzebnej
> roboty. W kontekście wątku jest to właśnie display: table zamiast TABLE.

Aaahaaa - no to się nie dogadaliśmy. :-)
Kontekst jest co prawda zupełnie inny: pytanie było czy tabela na DIVach
i CSS jest dopuszczalną formą tworzenia layoutu bo tabel w sensie
znaczników HTML - nie jest.

Tak więc nasza dyskusja jest mocno nie na temat :-)

> Do galerii? No ja bym już czegoś takiego we Flashu nie robił, chyba, że
> miałaby to być prezentacja, a nie strona.

Strony w większości moich realizacji (o ile nie we wszystkich) pełnią
funkcje prezentacyjne w jakiejś części funkcjonalności. Nigdy nie
robiłem strony z dokumentacją techniczną np. Praktycznie zawsze istnieje
potrzeba pokazywania jakiejś galerii.

> Ale na co nie pozwala rezygnacja z Flasha? Masz jeszcze do dyspozycji JS
> aby dorzucić efekty.

O rany :-) Serio piszesz? :-) Dżdżownicą też się da buta zawiązać :-D

> Chodzi o to, bym sobie mógł skopiować URLa, który sprawi, że flaszyk poda
> mi konkretny eksponat, bez przeklikiwania się. Powiedzmy, że właściciel
> galerii pisze maila do potencjalnego klienta i w nim zawarte jest coś
> takiego:

Tak, oczywiście :-) Flash to tylko prezentacja a nie layout i logika
systemu.

>> Na czym błąd Twoim zdaniem polega bo nawet nie jestem w stanie domyślić
>> się toru rozumowania. :-)
>
> Nie wiem czy tam był błąd, nie zrozum mnie źle. Niemniej z Twojego opisu
> nie wynika nic co wymagałoby Flasha, łącznie z "wyszarzaniem" miniaturki.
> Tu powinien wystarczyć JS. Powstaje też pytanie na ile, z czysto
> biznesowego punktu widzenia, właściwe jest uniemożliwienie obejrzenia
> galerii użytkownikom iPhonów albo iPadów. Im dalej za zachodnią granicę tym
> gorzej. Pokazanie "ciekawe" to także coś, co może oznaczać "bardziej
> wkurzające", gdy ten sam klient wraca na stronę po raz dziesiąty.
> Uprzedzając Twoje pytanie - tworzyłem już pełne flashowe galerie
> pobierające dane z XMLów generowanych przez CMS.
>
> *Nigdy więcej* :-)

Ciekawe :-) Bo ja nie odczuwam takiego obrzydzenia :-)
Nawet nie bardzo sobie wyobrażam jak poradziłbyś sobie w JS np. z
nazwijmy "pseudo" virtual trip'em po N-poziomowym planie budynku, na
którym prezentowane są mieszkania, które są do sprzedaży, albo zostały
już sprzedane, albo są zarezerwowane (zabarwiają się wtedy poszczególne
lokale na właściwy kolor). Potem to wszystko dla X osiedli :-) Należy
pamiętać, że redaktorzy na bieżąco nanoszą statusy mieszkań a więc JS
musi z serwerem gadać cały czas. Serio w JS robiłbyś to?

do góry

On 2010-11-09 22:49, Marek wrote:
> W dniu 2010-11-09 13:27, Paweł Piskorz pisze:
>> On 2010-11-08 22:42, Marek wrote:
>>
>> Jedynym przeciwwskazaniem jest to, że prawIE przeglądarki tego nIE
>> obsługują. Ale jeżeli badzIEw Cię nIE interesuje - hulaj do woli.
>> CSSem możesz robić co Ci się żywnie podoba, nie zmieni to nijak
>> znaczenia HTML-owych elementów, jedynie ich wygląd.
>
> A wiesz? Niedawno to sprawdziłem. Pod IE8 nie widziałem problemów.
>
> http://phrogz.net/CSS/vertical-align/index.html
>
> Wersja na DIVach działa elegancko.

NIEstety mamy jeszcze IE7 :(


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

W dniu 2010-11-10 12:50, Paweł Piskorz pisze:
> NIEstety mamy jeszcze IE7 :(

No to oglądacie gorzej :( A już powoli 9tka zaczyna pukać do drzwi...

do góry

On 10.11.2010 12:01, Marek wrote:

> Przecież nie dam struktury HTML grafikowi i nie powiem mu "dorób do
> niej projekt i zaakceptuj z klientem" :-)))

A dlaczego nie?
Przecież takie rozwiązanie byłoby bardzo dobre.

Ja od jakiegoś czasu próbuje wymusić coś takiego na grafiku :)

pozdrawiam
--
Bastet_Milo
http://hekate-design.pl

do góry

W dniu 2010-11-10 12:01, Marek pisze:
> No bo zawsze tak jest! :-D Najpierw trzeba konkretny projekt
> zatwierdzony przez klienta mieć aby wiedzieć jak dobrać strukturę.

Na szczescie nie zawsze. :-) Niestety, nadal za czesto...

Ten projekt (graficzny) tez sie z powietrza nie wzial. Ktos z klientem
usiadl i sie dowiedzial, ze potrzeba na stronie aktualnych plotek, fotki
prezesa, powitalnego oredzia. Nawet jesli nie powstal z tego
100-stronicowy dokument czy makieta, to jest to dobry moment, zeby
myslec nad struktura informacji.


> Przecież nie dam struktury HTML grafikowi i nie powiem mu "dorób do niej
> projekt i zaakceptuj z klientem" :-)))

Grafik dostaje jakies zalozenia projektowe. Nic nie stoi na
przeszkodzie, zeby wspoluczestniczyc w procesie ubierania tychze w
graficzna forme.

Tak, wiem, brzmi to idealistycznie, ale nawet jesli handlowcem,
opiekunem klienta, architektem informacji, projektantem i grafikiem jest
jedna osoba, to da sie to wszystko zrobic to z glowa.

--
NotBear

do góry