On Thu, 11 Nov 2010 21:02:28 +0100, Marek wrote:

> W dniu 2010-11-11 00:35, NotBear pisze:
>> Niekoniecznie.
>> http://www.positioniseverything.net/articles/onetrue
layout/anyorder
>
> Czułem, że ktoś to zaraz wyciągnie i będę musiał rozwijać wątek :-)))
> Problem zaczyna się gdy kod HTML czasem jest wstrzyknięty przez CMS a
> czasem nie. Osobiście wolę generować niezmienny plik CSS i z poziomu CMS
> zmieniać tylko HTML niż odwrotnie. Nie wspomnę o tym, że dużo lepiej
> projektuje się stronę gdy widzisz jak ona wygląda a nie domyślasz się
> jak będzie wyglądała gdy CMS coś pozmienia w stylach.

To jest zbyt ogólnie. Jaki CMS? Jaki zakres kontroli nad nim posiadasz? Bez
odpowiedzi na te pytania nie da się w żaden sposób potwierdzić lub
zaprzeczyć temu co piszesz. Nie zmienia to też ogólnych zasad - jeśli masz
pełną kontrolę nad HTMLem i CSSem to nie ma powodu by coś psuć.


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 2010-11-11 21:31, Michał Gancarski pisze:
> To jest zbyt ogólnie. Jaki CMS?
Autorski.

> Jaki zakres kontroli nad nim posiadasz?

100%

> Bez
> odpowiedzi na te pytania nie da się w żaden sposób potwierdzić lub
> zaprzeczyć temu co piszesz. Nie zmienia to też ogólnych zasad - jeśli masz
> pełną kontrolę nad HTMLem i CSSem to nie ma powodu by coś psuć.

Prosty przykład. Dajmy na to, że jakiś projekt wymaga dostawienia
trzeciej kolumny pomiędzy istniejące dwie. Wygodnie jest skrajnie prawą
wyrzucić na prawo float: right. Lewa i opcjonalna środkowa niech mają
float:left.

Można też zrobić tak jak nie chcę bo nie będę widział tego w edytorze
WYSIWYG, że CMS zmodyfikuje CSS w zależności od ilości kolumn jaki
będzie miał wygenerować i tylko w trakcie pracy aplikacji będę widział
tego efekty. Podczas projektowania: tylko w wyobraźni. Nie wspomnę o
tym, że jeśli CSS ulegać będzie zmianom to należy zapomnieć o
cach'eowaniu przez przeglądarki tego. To kolejna wada takiego podejścia.
A jak zacznę ze stylami inline'owymi to w ogóle sieczka kodowa powstanie.

do góry

On 11.11.2010 20:48, Marek wrote:

> Uważaj tylko na jedną rzecz... jeśli on wyjedzie na wakacje, to
> będziesz zmuszona zamknąć interes bo zastępstwa nie znajdziesz :-D

Wyjaśnij, dlaczego to byłoby problemem? Bo dla dobrego developera i
dla dobrego grafika nie powinno być.
Przecież na podobnej zasadzie robi się redesign stron (zakładając, że
zmieniamy tylko szatę graficzną).

--
Bastet_Milo

do góry

W dniu 2010-11-11 23:38, Katarzyna 'Bastet' Świderska pisze:
> Wyjaśnij, dlaczego to byłoby problemem? Bo dla dobrego developera i dla
> dobrego grafika nie powinno być.
> Przecież na podobnej zasadzie robi się redesign stron (zakładając, że
> zmieniamy tylko szatę graficzną).

Bo Ci lepsi robią już interesy poza granicami za znacznie wyższą kasę...
Ci co zostali i mają prawdziwe pojęcie o HTMLu poza samą grafiką, to
niedobitki. Współpracowałem z wieloma utalentowanymi grafikami jednakże
nigdy mi się nie zdarzyło aby którykolwiek z nich miał pojęcie o
semantycznej składni HTML (jeśli miał w ogóle pojęcie o HTMLu). Owszem,
część z nich potrafiła zbudować wizualny layout w CSS/HTMLu lecz
praktycznie nie nadawał się do wykorzystania. Zdarzały się tabele w
takich layoutach, nagłówki zamiast na <hx> to na <p class="xxx"> itp.
Trzeba było wszystko od zera budować aby było można np. pozycjonować
stronę. Być może klątwa ciąży na mnie, ale takie właśnie mam doświadczenia.

do góry

On 12.11.2010 02:35, Marek wrote:
> W dniu 2010-11-11 23:38, Katarzyna 'Bastet' Świderska pisze:
>> Wyjaśnij, dlaczego to byłoby problemem? Bo dla dobrego developera i dla
>> dobrego grafika nie powinno być.
>> Przecież na podobnej zasadzie robi się redesign stron (zakładając, że
>> zmieniamy tylko szatę graficzną).
>
> Bo Ci lepsi robią już interesy poza granicami za znacznie wyższą
> kasę... Ci co zostali i mają prawdziwe pojęcie o HTMLu poza samą
> grafiką, to niedobitki.

No popatrz, a ja wciąż trafiam na takich wszystko umiejących. Wręcz
potykam się na każdym kroku ;).
Ci to zazwyczaj mają ciężko - projektują myśląc o kodzie. Wydaje mi
się, że to może ograniczać kreatywność.

> Współpracowałem z wieloma utalentowanymi
> grafikami jednakże nigdy mi się nie zdarzyło aby którykolwiek z nich
> miał pojęcie o semantycznej składni HTML (jeśli miał w ogóle pojęcie o
> HTMLu). Owszem, część z nich potrafiła zbudować wizualny layout w
> CSS/HTMLu lecz praktycznie nie nadawał się do wykorzystania. Zdarzały
> się tabele w takich layoutach, nagłówki zamiast na <hx> to na <p
> class="xxx"> itp. Trzeba było wszystko od zera budować aby było można
> np. pozycjonować stronę. Być może klątwa ciąży na mnie, ale takie
> właśnie mam doświadczenia.

Ale po cóż ma ten grafik znać doskonale kod?
Grafik musi mieć świadomość, że ja swoim CSS zrobię "czary-mary" i
wizualnie poukładam elementy strony tak jak on sobie wymyślił, nie
zmieniając wcześniejszej struktury dokumentu.

Jasne, powinien znać ograniczenia html/css żeby np. wiedzieć, że
pewnych efektów się nie da bez Ajaxa/jQuery/Flash...

pozdrawiam
--
Bastet_Milo

do góry

Użytkownik "Paweł Piskorz" <n...@p...nie?> napisał w wiadomości
news:ibe0ul$kog$1@inews.gazeta.pl...
>>
>> 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 :(
>

Istnieje również IE4 :). Ale ponieważ IE8 jest obowiązkową aktualizacją to
IMHO nie ma się nad czym zastanawiać.

do góry

W dniu 2010-11-12 09:54, Katarzyna 'Bastet' Świderska pisze:
>
> No popatrz, a ja wciąż trafiam na takich wszystko umiejących. Wręcz
> potykam się na każdym kroku ;).

Ok, udało Ci się wzbudzić we mnie zazdrość :-D

> Ci to zazwyczaj mają ciężko - projektują myśląc o kodzie. Wydaje mi się,
> że to może ograniczać kreatywność.

Niekoniecznie. Dawno temu przesiadałem się z layoutów nazwijmy
"tabelkowych" na CSS. Męczyłem się z tym straszliwie. Faktycznie
powstało takie zjawisko o jakim piszesz. Po pewnym czasie (nowsze wersje
CSS, przeglądarek) oraz porzucenie poprzedniego podejścia do zagadnienia
pozwoliło mi na sporo większe możliwości. Mało tego, zauważyłem nawet
odwrotne zjawisko. To programy graficzne zaczynają narzucać w pewnym
sensie ograniczenia. Czasem jest tak, że aby przygotować elementy
graficzne dla projektu WWW muszę rozbijać layout bo np. jakiś kawałek ma
być półprzejrzysty i nie może pod nim występować tło layoutu jaki klient
zatwierdził, albo inny kawałek musi być specjalnie spreparowany dla
Flasha, albo jeszcze inny musi być tak dostosowany aby teksty nie były
elementem graficznym bo pozycjonowanie ucierpi itp. Tak więc w efekcie
projekt w edytorze graficznym przypomina coraz częściej sieczkę a
dopiero na stronie WWW widać efekt końcowy. W takich realizacjach
projekt muszę trzymać bardziej w głowie niż na ekranie.

> Ale po cóż ma ten grafik znać doskonale kod?

Aby było mniej poprawek, czasem nawet dość kłopotliwych.

> Grafik musi mieć świadomość, że ja swoim CSS zrobię "czary-mary" i
> wizualnie poukładam elementy strony tak jak on sobie wymyślił, nie
> zmieniając wcześniejszej struktury dokumentu.

Chyba, że projekt jest dość złożony w sensie programowym (np.
współpracujące ze sobą online fragmenty strony WWW, komunikujące się ze
sobą Flashe itp). Wtedy niezły rebus może powstać z zadania
przygotowania grafiki.

do góry

On 2010-11-12 10:47, William Bonawentura wrote:
>
>> NIEstety mamy jeszcze IE7 :(
>>
>
> Istnieje również IE4 :).

Tylko w muzeum ;]

> Ale ponieważ IE8 jest obowiązkową aktualizacją
> to IMHO nie ma się nad czym zastanawiać.

http://ranking.pl/pl/rankings/web-browsers.html


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

do góry

On Thu, 11 Nov 2010 22:01:59 +0100, Marek wrote:

> W dniu 2010-11-11 21:31, Michał Gancarski pisze:
>> To jest zbyt ogólnie. Jaki CMS?
> Autorski.
>
>> Jaki zakres kontroli nad nim posiadasz?
>
> 100%

W takim razie nie rozumiem w czym problem, a zwłaszcza nie rozumiem pisania
o "wstrzykiwaniu kodu przez CMS". Ostatecznie kontrolujesz co "wstrzykuje".


>> Bez
>> odpowiedzi na te pytania nie da się w żaden sposób potwierdzić lub
>> zaprzeczyć temu co piszesz. Nie zmienia to też ogólnych zasad - jeśli masz
>> pełną kontrolę nad HTMLem i CSSem to nie ma powodu by coś psuć.
>
> Prosty przykład. Dajmy na to, że jakiś projekt wymaga dostawienia
> trzeciej kolumny pomiędzy istniejące dwie.

"Dostawienia" tzn.? W trakcie projektowania tak wyszło, czy może nagle po
roku okazało się, że ona tam ma być?


> Wygodnie jest skrajnie prawą
> wyrzucić na prawo float: right. Lewa i opcjonalna środkowa niech mają
> float:left.

Najwygodniej komu? Poza tym nadal piszesz o layoucie w oderwaniu od tego co
w tym dokumencie się tak naprawdę znajduje.


> Można też zrobić tak jak nie chcę bo nie będę widział tego w edytorze
> WYSIWYG, że CMS zmodyfikuje CSS w zależności od ilości kolumn jaki
> będzie miał wygenerować i tylko w trakcie pracy aplikacji będę widział
> tego efekty. Podczas projektowania: tylko w wyobraźni.

CMS WYSIWYG? W trakcie normalnego funkcjonowania strony (a nie na etapie
jej projektowania) to co najmniej rzadkość, nie mówiąc już o zazwyczaj
kulejących implementacjach. Oddawanie takiej kontroli użytkownikowi jest
wręcz niebezpieczne. Jednym z ważniejszych elementów szkolenia redaktorów
strony jest IMHO określenie zakresu modyfikacji, które będą mogli
wprowadzać i wyjaśnienie czemu one są tak ograniczone. Redaktor nie robi
składu, redaktor wrzuca treść. Jeśli zmiany w layoucie mogą następować
zmiany tak znaczące jak układ kolumn, to trzeba raczej starać się to
przewidzieć wcześniej.


> Nie wspomnę o
> tym, że jeśli CSS ulegać będzie zmianom to należy zapomnieć o
> cach'eowaniu przez przeglądarki tego.

Znów - zanim nie podasz konkretnego przykładu, np. podając link czy
wskazując o jakim CMSie mówimy, to pozostajemy w sferze ogółów. Zmienność
CSSa też nie oznacza braku cachowania. Elementy stałe można wyrzucić do
osobnego pliku, o ile będzie to w ogóle konieczne. "Zmienność" taka jak
pojawienie się co pewien czas dodatkowej kolumny zazwyczaj możliwa jest do
osiągnięcia przez dodanie jakiejś klasy odpowiedniemu elementowi i
dopisanie stylu w dokładnie tym samym pliku CSS, który był użyty do tej
pory.


> To kolejna wada takiego podejścia.
> A jak zacznę ze stylami inline'owymi to w ogóle sieczka kodowa powstanie.

To może zacznij klasami?


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 2010-11-14 04:18, Michał Gancarski pisze:
> W takim razie nie rozumiem w czym problem, a zwłaszcza nie rozumiem pisania
> o "wstrzykiwaniu kodu przez CMS". Ostatecznie kontrolujesz co "wstrzykuje".

No w tym, że wstrzykuję trzecią (środkową kolumnę). Wiem, że ją
wstrzykuje czasem a czasem nie. Zależy od tego co redaktor postanowi a
nie ja. Wiedza o tym fakcie niczego nie zmienia przecież. Moim zadaniem
jako webmastera jest być przygotowanym na to zdarzenie a nie go
zabraniać. Sam ten mechanizm stworzyłem i nie chce go sobie blokować.

Mało tego, zakładając hipotetycznie, że powinienem zrezygnować z tej
funkcjonalności: powód tej rezygnacji też mi się słaby wydaje (czyli
konieczność użycia float:right do realizacji tej funkcji i w
konsekwencji zmiana kolejności występowania w kodzie treści). Chciałeś
przykład layout, w którym trzeba przestawić kolejność kolumn więc dałem.

> "Dostawienia" tzn.? W trakcie projektowania tak wyszło, czy może nagle po
> roku okazało się, że ona tam ma być?

Nie, od samego początku było założone, ze ta kolumna tam będzie LUB nie
będzie.

> Najwygodniej komu?

Najwygodniej w sensie technologicznym. A za przyjęte rozwiązanie
webmaster, czyli ja odpowiada :-) No bo przecież nie klient odpowiada a
nikogo innego nie ma w tym łańcuszku :-)

> Poza tym nadal piszesz o layoucie w oderwaniu od tego co
> w tym dokumencie się tak naprawdę znajduje.
> CMS WYSIWYG?

Nie. Nie dopuszczam w każdym razie aby redaktor umieszczał kod HTML w
treści aby uniknąć zaburzenia semantycznej struktury dokumentu itp. Sam
w każdym bądź razie nie ma możliwości tworzenia kolumn. Podziału
kolumnowego w pewnym sensie dokonuje automat - nie wdając się w detale
(ale jednak wdaję się poniżej czytając co napisałeś). W jaki sposób to
się dzieje - określa webmaster.

> W trakcie normalnego funkcjonowania strony (a nie na etapie
> jej projektowania) to co najmniej rzadkość, nie mówiąc już o zazwyczaj
> kulejących implementacjach.
> Oddawanie takiej kontroli użytkownikowi jest
> wręcz niebezpieczne.

Nie wiem co masz na myśli mówiąc rzadkość. Załóżmy, że w lewej kolumnie
mamy nawigację, w prawej stałe sekcje jak newsy itp. Środkowa pojawia
się okazjonalnie gdy są jakieś szczególne wydarzenia: promocje towaru w
sklepie itp. Przypuszczam, że oddanie użytkownikowi kontroli w postaci
zaznaczenia checkboxa przy produkcie, że jest promowany nie oznacza de
facto "oddania kontroli" w omawianym rozumieniu.


> Jednym z ważniejszych elementów szkolenia redaktorów
> strony jest IMHO określenie zakresu modyfikacji, które będą mogli
> wprowadzać i wyjaśnienie czemu one są tak ograniczone. Redaktor nie robi
> składu, redaktor wrzuca treść.

I tak jest. Redaktor w moim CMS robi jeszcze parę rzeczy więcej:
"konfiguruje" treść. Chodzi o włączanie i wyłączanie pewnych opcji przy
danym dokumencie, które sterują jego wyświetlaniem czy zachowaniem się.
Np. opcja "promocja na stronie głównej" spowoduje automatyczne powstanie
środkowej kolumny.

> Jeśli zmiany w layoucie mogą następować
> zmiany tak znaczące jak układ kolumn, to trzeba raczej starać się to
> przewidzieć wcześniej.

I jest to w 100% przewidziane i zaprojektowanie.

>> Nie wspomnę o
>> tym, że jeśli CSS ulegać będzie zmianom to należy zapomnieć o
>> cach'eowaniu przez przeglądarki tego.
>
> Znów - zanim nie podasz konkretnego przykładu, np. podając link czy
> wskazując o jakim CMSie mówimy, to pozostajemy w sferze ogółów. Zmienność
> CSSa też nie oznacza braku cachowania.

Ufff... jeszcze i to widzę, że będziemy drobiazgowo rozpatrywać. Ok,
dobra. A więc zmienność CSS musi skutkować wyłączeniem lub ograniczeniem
cache'owania CSS dla przeglądarek - a więc niepotrzebnie powiększone
transfery. Jeśli zakładamy, że CSS w każdej chwili może zostać
zmodyfikowany, to nie może on mieć nagłówka Expires ustawianego daleko w
przyszłość. W przeciwnym razie przeglądarka nawet nie spyta serwera o to
czy jest nowsza wersja CSS i wyświetli nową treść ze starym CSS.

> Elementy stałe można wyrzucić do
> osobnego pliku, o ile będzie to w ogóle konieczne. "Zmienność" taka jak
> pojawienie się co pewien czas dodatkowej kolumny zazwyczaj możliwa jest do
> osiągnięcia przez dodanie jakiejś klasy odpowiedniemu elementowi i
> dopisanie stylu w dokładnie tym samym pliku CSS, który był użyty do tej
> pory.

To prawda. I jak tak postępuję. Nie mam potrzeby tworzenia dodatkowych
plików CSS. Lewej i środkowej kolumnie robię jedną klasę z float:left, a
prawej z float:right (w konsekwencji przestawiając tym samym kolejność
występowania w HTMLu tej kolumny). Mam stałe CSS, mogę je sobie
cache'ować swobodnie a jedyną niedogodnością jest to, że jakieś
urządzenie mobilne z upośledzoną przeglądarką w złym miejscu wyświetli
kolumnę. Mam rację?

Jednakże ja osobiście jestem przeciwnikiem modyfikowania CSS
dynamicznie. W tej chwili przerabiamy tylko jakiś konkretny przypadek. W
rzeczywistości więcej takich sytuacji zdarza się. Jestem zwolennikiem
(jak napisałem) statycznego CSS i jedynie HTML może być dynamicznie
generowany.


>> To kolejna wada takiego podejścia.
>> A jak zacznę ze stylami inline'owymi to w ogóle sieczka kodowa powstanie.
>
> To może zacznij klasami?

No jak klasami? Musiałbym namnożyć ich gdybym każdą możliwą kombinację
miał oklasować (np. różne szerokości marginesów w przypadku gdy coś
występuje lub nie). Nie ma takiej potrzeby moim zdaniem. Po to jest
float:right aby go używać. Prawda? :-)

do góry