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!