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?