Dnia Tue, 28 Feb 2012 10:21:29 +0100, Marek napisał(a):

>> To zmień kolejność i floatuj w drugą stronę, w czym problem?
>
> O rany. Doradziłeś mi (kolejne) rozwiązanie, ja znalazłem w nim mankament i
> go skomentowałem. Jordan zaproponował ciekawe rozwiązanie na bazie CSS bez
> dokonywania zmian w kodzie HTML. Więc temat jest zamknięty, (...)

... do czasu, aż nie będziesz potrzebował podobnego rozwiązania dla układu
trzykolumnowego. Wtedy :last-child [1] nie da rady (który też nie jest zbyt
lubiany przez starsze wersje IE), a wersja z selektorem + bez problemu.

[1] :nth-child podobnie lubią starsze przeglądarki.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

Dnia Tue, 28 Feb 2012 20:52:21 +0100, Borys Pogoreło napisał(a):

>
> ... do czasu, aż nie będziesz potrzebował podobnego rozwiązania dla układu
> trzykolumnowego. Wtedy :last-child [1] nie da rady (który też nie jest zbyt
> lubiany przez starsze wersje IE), a wersja z selektorem + bez problemu.

Tak, oczywiście masz rację. Tylko wersja z "plusikiem" działa do przodu a
nie do tyłu. Więc i w 3 kolumnach się nie sprawdzi. Chodzi o to, że element
poprzedni nie zmieni w ten sposób swojego wymiaru gdy wystąpi następny,
prawda? Jeśli chcemy upakować więcej kolumn lub następna ma być szersza, to
poprzednią trzeba zawęzić. Operatorem "plus" tego nie zrobisz albo nie do
końca załapałem Twoją intencję.

Zapis:
section + aside { width : 700px; }

oznacza ustawienie szerokości aside a nie section.

do góry

Dnia Tue, 28 Feb 2012 21:05:19 +0100, Marek napisał(a):

> Zapis:
> section + aside { width : 700px; }
>
> oznacza ustawienie szerokości aside a nie section.

Tak. I ten mechanizm wymaga faktycznie odpowiedniej kolejności elementów,
gdzie zawsze widoczna kolumna jest jako ostatnia i to ona zmienia wymiary.
Ale bez problemu wszystkie kolumny sfloatujesz (co za słowo) na odpowiednie
miejsca, a notacja nie jest przesadnie skomplikowana:

a { width : i; } /* stała szerokość */
b { width : j; } /* stała szerokość */
c { width : k; } /* 100% kontenera */
a + c { width : k - i; }
b + c { width : k - j; }
a + b + c { width : k - i - j; } /* +/- marginesy pomiędzy */

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

Dnia Wed, 29 Feb 2012 17:31:15 +0100, Borys Pogoreło napisał(a):

>
> Tak. I ten mechanizm wymaga faktycznie odpowiedniej kolejności elementów,
> gdzie zawsze widoczna kolumna jest jako ostatnia i to ona zmienia wymiary.
> Ale bez problemu wszystkie kolumny sfloatujesz (co za słowo) na odpowiednie
> miejsca, a notacja nie jest przesadnie skomplikowana:
>
> a { width : i; } /* stała szerokość */
> b { width : j; } /* stała szerokość */
> c { width : k; } /* 100% kontenera */
> a + c { width : k - i; }
> b + c { width : k - j; }
> a + b + c { width : k - i - j; } /* +/- marginesy pomiędzy */

Załapałem Twoją intencję. Tak, ma to sens i będzie działało w
nienajświeższym IE również. Dzięki za kolejną koncepcję :-)

do góry

On Mon, 27 Feb 2012 22:20:34 +0100, Marek wrote:

[...]

>> Czyli CMS generuje HTMLa, w dodatku podmieniając atrybuty elemenentów. Nie
>> przeszkadza Ci, że zmienia "id" ale przeszkadza, że zmieni "class"?
>
> Dokładnie trafiłeś w sedno. Nie przeszkadza mi kostrukcja w kodzie HTML:
>
> <a href="dokument_TU_WSTAW_ID.html">link do mojego dokumentu</a>
>
> a bardzo mi przeszkadza:
>
> <p class="TU_WSTAW_KLASĘ">bla bla</p>
>
> Gdy w przeglądarce czy edytorze WYSIWYG popatrzysz na kod drugi, to
> niepoprawnie go wyświetli gdyż nie ma klasy w CSS o nazwie
> "TU_WSTAW_KLASĘ". Znacznik umieszczony w linku nie przeszkadza.

Niby w jaki sposób wyświetli go niepoprawnie? I dlaczego w CSSie nie ma
stylu dla tej klasy?


>>> Nie są w żadnym przypadku podmieniane nazwy klas CSS bo skąd CMS miałby
>>> wiedzieć na jakie?
>>
>> Bo go o tym poinformujesz? Skoro informujesz go o HTMLu, który ma
>> generować, to możesz go poinformować o atrybutach, które ma generować.
>
> Osobiście stronię od takich rozwiązań. Bardzo trudno poruszać się po kodzie
> obfitującym w "widoczne inaczej" sekcje. To tak jak programowanie w kodzie
> maszynowym zamiast w językach wyższego rzędu.

Nie rozumiem co tu napisałeś. Podgląd HTMLa w przeglądarce nie działa? :-)


>> CMS jest zawsze aplikacją dedykowaną konkretnemu serwisowi.
>
> U mnie nigdy tak nie jest. Praktycznie wszędzie CMS jest identyczny.
> Zmieniają się tylko zainstalowane lub włączone moduły. O funkcjonalności
> decyduje formatka HTML. Ona poza szatą graficzną zawera specjalne markery
> (nie zaburzające validacji ani wyglądu) sterujące CMSem.

Co to jest "formatka HTML"? Czy dobrze rozumiem, że nie możecie w pełni w
szablonach decydować o HTMLu odpowiedzialnym np. za nawigację? To wygląda
na pieruńsko niewygodną w wielu CMSach rzeczy czyli brak możliwości pełnego
decydowania o generowanym HTMLu. Nie wszystko da się załatwić CSSem.


>> To nie musi
>> oznaczać modyfikacji samego CMSa ale jeśli CMS nie dostarcza narzędzi,
>> które pozwalają na zareagowanie inaczej w dwóch różnych sytuacjach... to
>> jest jakaś stara Joomla?
>
> Nie w tym rzecz. CMS jest autorski. Mie ma potrzeby aby moduł np.
> generujący menu wiedział o tym, że ma reagować inaczej gdy dokument
> wyświetlany na tej samej stronie ma obrazki lub nie ma - czyli pojawi się
> lub nie kolumna <aside> w naszym przypadku.

Ten wątek udowadnia, że taka potrzeba istnieje :-)


> Takie sprawy rozwiązuje się za
> pomocą CSS. Jordan zaproponował zgrabne rozwiązanie - zerknij tam. Jestem
> zwolennikiem przejrzystości kodowania tak aby rozwiązania zastosowane przez
> ich autora były samokomentujące się. Dlatego wstawianie znaczników w
> miejsce klas psuje taką koncepcję.

To jest rozwiązanie tylko jednego specyficznego problemu, a takich napotyka
się dziesiątki. CMS w ogóle nie powinien dyktować HTMLa (może go proponować
ale nie powinien o nim decydować). Idealnie - powinien udostępniać
struktury danych i API, które pozwala wyciągnąć z niego w dowolnym miejscu
dowolnego szablonu dowolny zbiór informacji na temat wprowadzonej do niego
treści. Wordpress w dużym stopniu to np. robi. Możesz generować nawigację
jego funkcjami (co jest zapewne odpowiednikiem "modułu" w Waszym CMSie) ale
możesz go zapytać o strukturę zawierającą info o wybranych podstronach i
wygenerować nawigację jak chcesz. Częściową, całkowitą, zależną od sytuacji
itp. Z HTMLem, o którym w pełni decydujesz. Za pomocą tej samej struktury
zresztą możesz np. stworzyć breadcrumbsy.


>> Generowanie różnych klas dla różnych widoków jest podstawową praktyką przy
>> korzystaniu z CMSa, na tym polega "separacja". To dlatego np. Worpdress ma
>> funkcje generujące klasy dla BODY, które pozwalają ostylować inaczej każdy
>> widok (stronę, kategorię, taksonomię, post, archiwum, cokolwiek), czy
>> dodaje klasy typu "current_page_item" jeśli z URLa wynika, że aktualnie
>> jesteś na danej podstronie.
>
> A nie lepiej podmienić plik CSS gdy potrzebujemy coś inaczej mieć
> ostylowane lub zarządzać mediami na poziomie CSS? Chyba tylko wtedy
> istnieje potrzeba zmiany stylu (dla drukarki inaczej dla ekranu inaczej).
> Kwestię ostylowania podstron też prosto można rozwiązać bez używania
> "wstrzykiwanych" klas.

Jest ciężko, skoro zacząłeś ten wątek. Klasy to jest narzędzie, którego
należy używać, a nie unikać. Od tego są. Jedna klasa załatwia cały ten
wątek, wszystkie te sztuczki i obchodzenie za pomocą fikuśnych selektorów.
Zmień trochę layout, a okaże się, że pojawi się kolejny problem. Tymczasem
gdy masz dużo różnych klas, masz dużo "wieszaków" na style. Stąd tak
cholernie podoba mi się np. Wordpressowa funkcja body_class();


> Wystarczy dla podstron zbudować inną formatkę z
> innymi klasami. Wtedy ktoś kto grzebie w naszym kodzie zobaczy jak wyglądać
> będzie taka podstrona bez uruchamiania CMS i łatwo będzie mógł ja
> zmodyfikować. Gdy natomiast CMS będzie podrzucał w locie jakąś klasę to
> marnie widzę szansę na zlokalizowanie kodu bez konsultacji z jego autorem.

Ale jakiego kodu? Zawsze widzisz generowany HTML, niezależnie od tego jak
wygenerowany został. I stylujesz ten HTML jak chcesz. Z klasą czy bez.


>>> Owszem, wtedy jest czasem
>>> trudniej coś ostylować gdy raz jakiś blok pojawia się a innym razem nie.
>>
>> Gdy raz jakiś blok się pojawia, a raz nie, to masz do czynienia z dwoma
>> różnymi widokami.
>
> Może nie do końca rozumiem tą koncepcję. Co znaczy "widok" w tym przypadku?
> Skąd jest on brany i jakie są kryteria wyłonienia właściwego? Jeśli to
> jakiś moduł programowy go określa - wydaje mi się niepotrzebnym tworzenie
> takiego modułu jeśli CSS to załatwia. Wydaje mi się to szalenie złożoną
> ideą do prostych zadań. Załóżmy, że mamy dokument z 3 kolumnami, z których
> każda z nich może pojawić się lub nie. Czy to oznacza, że musimy
> wygenerować 6 widoków spełniających wszelkie kombinacje? Czyli liczba
> widoków może dążyć do nieskończoności gdy kolumn jest więcej.

I od tego masz dodatkową klasę (np. <body class="columns-2">), by sobie móc
ostylować różne warianty.


--
M.G.

do góry