W dniu 2010-12-09 19:26, Artur Muszyński pisze:
> W dniu 2010-12-08 17:56, Marek pisze:
>> Bardziej istotnym zagadnieniem jest to co jest "podstawowym elementem".
>> Bold i italic? Coś jeszcze? Jeśli tak, to sprawa się komplikuje.
>
> Tabelki?


Hej,

Mam tu spore wątpliwości natury technicznej. To wydaje mi się póki co
bardzo trudne do osiągnięcia lub w ogóle nie do zrealizowania.

Zerknij na moją wypowiedź w tej kwestii udzieloną Michałowi przed
chwilą. Na samym dole poruszamy temat edytowania tabel. Skąd je czerpać:
z bazy? A może umieszczać kod HTML ze stylami online dla każdej komórki?
Jak wyświetlać zawartość takich tabel w edytorze - bo przecież na
stronie WWW mogą obowiązywać style nadające zupełnie inny wygląd tabelom
więc edytor powinien nadawać taki sam styl aby redaktor widział co robi
(bo chyba po to jest edytor WYSIWYG). To z kolei implikuje, że edytor
taki powinien być konfigurowany dla każdego projektu oddzielnie, prawda?

Możemy jeszcze bardziej skomplikować zagadnienie. Serwis WWW może
posiadać skórki (np. wersja żałobna itp). W skórkach teoretycznie ta
sama tabela może zupełnie inaczej wyglądać. Tak więc w edytorze powinna
być opcja w/g jakiej skórki należy prezentować taką tabelę w edytorze.

Tworzy się sytuacja zahaczająca o absurd. Pewnie trzeba się do czegoś
ograniczyć. Pytanie: do czego?

do góry

On Fri, 10 Dec 2010 11:48:31 +0100, Marek wrote:

[...]

>>> Tylko tego brakowało! Czy sądzisz, że klienci wiedzą czym strong od
>>> bolda się różni? :-D Boldem niewiele zepsuje, strongiem może znacznie
>>> więcej. Mimo iż on to zepsuje to gromy mogą na mnie polecieć.
>>
>> Co może zepsuć "strongiem"?
>
> Pozycjonowanie.

W jaki sposób? Jeśli coś jest ważne to należy to oznaczyć.


>> Na poziomie edytora klient nie musi widzieć co
>> powstaje pod spodem. Ma ikonkę "B" ale w kodzie pojawia się STRONG.
>
> To chyba bardzo zły pomysł. W kodzie powinno być <b>.

Nie. To jest łata na przyzwyczajenia. Reszta to kwestia szkolenia.


> <strong> ma inne
> znaczenie semantyczne niż <b>.

B w ogóle nie ma znaczenia semantycznego.


> No i tu rodzi się dylemat - czy dawać
> drugi sposób boldowania? Klient tego nie zrozumie lub zrozumie a potem
> zapomni. Np. biorę kasę za pozycjonowanie a klient redagując treść w
> sposób nieodpowiedni psując mi całą robotę. Dlatego tak prosta czynność
> jak boldowanie może też powodować straty dla mnie. Również i stąd moje
> dylematy co do udostępniania edytora.

Szkolenie.


[...]

>> To zależy od sytuacji. Do prostych tabel można stworzyć style. Natomiast
>> jeśli to jest cennik np. ze sklepu internetowego to generowałbym go pewnie
>> z bazy. Jak? Nie wiem, musiałbym mieć pod ręką konkretny projekt, znać
>> narzędzia i wiedzieć, że potrafię ich użyć.
>
> Edytor to nie jest konkretny projekt tylko narzędzie uniwersalne.

Ale każdy projekt to jest decyzja co zrobić z edytorem. Rozpatrywanie
edytora w oderwaniu od projektu nie ma sensu.


> Jeśli
> tabela miałaby być z bazy ciągnięta, to jak ją redaktor wstawi w treść
> (lub w kilka miejsc w treści)? Jakimś znacznikiem specjalnym? Jeśli
> zaczniesz ich używać, to rośnie stopień złożoności takiego edytora bo
> wtedy nie tylko znaczniki HTML musi analizować. Z kolei nie wyobrażam
> sobie aby redaktor z palca wklepywał kod tabeli.

Tworzysz problemy w oderwaniu od kontekstu. Nie da się o tym dyskutować. W
jednym projekcie wygodniej będzie wstawić cennik z bazy, w innym tabelą.
Wady i zalety są tutaj konkretne, uzależnione od projektu.


> Nie trzymaj się wyrażenia "cennik" jako faktycznie cennika. To mogą być
> takie elementy jak tu:
>
> http://www8.hp.com/pl/pl/contact-hp/phone-assist.htm
l

Znów - nie wiem jak to jest zrobione od strony redaktora więc nie
wypowiadam się czy zrobiono dobrze i czy dałoby się lepiej.


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 2010-12-10 12:40, Michał Gancarski pisze:

>>
>> Pozycjonowanie.
>
> W jaki sposób? Jeśli coś jest ważne to należy to oznaczyć.

Może coś być wizualnie ważne a coś innego może być ważne z punktu
widzenia pozycjonowania. Wyboldować można napis "nie dotykać urządzenie
elektryczne" jednakże nie na tą frazę chcemy pozycjonować stronę lecz na
"szafa grająca" więc z punktu Googli nie powinna być ta pierwsza fraza
traktowana jako ważna (czyli ujmowana strongiem). Wtedy szafę oznaczamy
strongiem a ostrzeżenie wizualne boldem. Oczywiście jeśli łaty <b> nie
powinno się stosować to wtedy trzeba znacznie dłuższą łatę <span
style="..."> stosować, co jest jeszcze bardziej nieeleganckie. Prawda?

>> <strong> ma inne
>> znaczenie semantyczne niż<b>.
>
> B w ogóle nie ma znaczenia semantycznego.

No więc o tym mówię.

>
> Ale każdy projekt to jest decyzja co zrobić z edytorem. Rozpatrywanie
> edytora w oderwaniu od projektu nie ma sensu.

Ja wyłącznie taki wariant przyjmuję. Sekcja redakcyjna CMS jest zawsze
taka sama dla wszystkich projektów. Dlaczego więc nie można edytora
dawać jako narzędzia nie związanego z projektem? Tworzenie dla każdego
projektu indywidualny CMS to koszty, których praktycznie nikt nie
zaakceptuje. Mało tego, jeśli zmieni się szata graficzna serwisu to i
część redakcyjną trzeba będzie przerabiać. W tym momencie CMS przestaje
nim być w zasadzie.

do góry

On Fri, 10 Dec 2010 13:30:37 +0100, Marek wrote:

> W dniu 2010-12-10 12:40, Michał Gancarski pisze:
>
>>>
>>> Pozycjonowanie.
>>
>> W jaki sposób? Jeśli coś jest ważne to należy to oznaczyć.
>
> Może coś być wizualnie ważne a coś innego może być ważne z punktu
> widzenia pozycjonowania. Wyboldować można napis "nie dotykać urządzenie
> elektryczne"

Na stronie WWW? Podaj przykład z życia raczej.


> jednakże nie na tą frazę chcemy pozycjonować stronę lecz na
> "szafa grająca" więc z punktu Googli nie powinna być ta pierwsza fraza
> traktowana jako ważna (czyli ujmowana strongiem).
> Wtedy szafę oznaczamy
> strongiem a ostrzeżenie wizualne boldem. Oczywiście jeśli łaty <b> nie
> powinno się stosować to wtedy trzeba znacznie dłuższą łatę <span
> style="..."> stosować, co jest jeszcze bardziej nieeleganckie. Prawda?

Co jest nieeleganckiego w "span"?


>>> <strong> ma inne
>>> znaczenie semantyczne niż<b>.
>>
>> B w ogóle nie ma znaczenia semantycznego.
>
> No więc o tym mówię.
>
>>
>> Ale każdy projekt to jest decyzja co zrobić z edytorem. Rozpatrywanie
>> edytora w oderwaniu od projektu nie ma sensu.
>
> Ja wyłącznie taki wariant przyjmuję. Sekcja redakcyjna CMS jest zawsze
> taka sama dla wszystkich projektów.

No sorka, nie może być taka sama dla dużego serwisu prasowego, bloga czy
sklepu.


> Dlaczego więc nie można edytora
> dawać jako narzędzia nie związanego z projektem?

Bo jest elementem projektu, a nie osobnym narzędziem. Jest tylko jednym z
aspektów konkretnego rozwiązania.


> Tworzenie dla każdego
> projektu indywidualny CMS to koszty, których praktycznie nikt nie
> zaakceptuje.

Zależy od projektu. A edytory też można konfigurować, dodając i odejmując
im opcje. Poza tym redakcja serwisu to nie tylko edytor.


> Mało tego, jeśli zmieni się szata graficzna serwisu to i
> część redakcyjną trzeba będzie przerabiać.

Niby w jaki sposób? Ponownie - podaj *bardzo konkretny* przykład. Mnie
trochę męczy już dyskusja o ogólnikach.

[...]




--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

grudzień roku pamiętnego 2010, prawdopodobnie 10. Wielka mądrość na
czytelników pl.comp.www spłynęła, gdy tako rzekł(a) Michał Gancarski:

> > Wtedy szafę oznaczamy
> > strongiem a ostrzeżenie wizualne boldem. Oczywiście jeśli łaty <b>
> > nie powinno się stosować to wtedy trzeba znacznie dłuższą łatę
> > <span style="..."> stosować, co jest jeszcze bardziej
> > nieeleganckie. Prawda?
>
> Co jest nieeleganckiego w "span"?

W spanie nic. Tylko tutaj nie chodzi o span ale o span ze stylem
liniowym. Taka konstrukcja zaburza zasadę oddzielenia struktury
dokumentu od jego wyglądu (z tego samego powodu nie budujesz layoutu
strony w oparciu o tabelę, chociaż istnieją sytuacje gdy użycie tabeli
byłoby prostsze).
--
Niżej podpisany, zamieszkały w http://minio.xt.pl ,
Mirosław Zalewski

do góry

On Fri, 10 Dec 2010 16:20:29 +0100, Mirosław Zalewski wrote:

> grudzień roku pamiętnego 2010, prawdopodobnie 10. Wielka mądrość na
> czytelników pl.comp.www spłynęła, gdy tako rzekł(a) Michał Gancarski:
>
>>> Wtedy szafę oznaczamy
>>> strongiem a ostrzeżenie wizualne boldem. Oczywiście jeśli łaty <b>
>>> nie powinno się stosować to wtedy trzeba znacznie dłuższą łatę
>>> <span style="..."> stosować, co jest jeszcze bardziej
>>> nieeleganckie. Prawda?
>>
>> Co jest nieeleganckiego w "span"?
>
> W spanie nic. Tylko tutaj nie chodzi o span ale o span ze stylem
> liniowym. Taka konstrukcja zaburza zasadę oddzielenia struktury
> dokumentu od jego wyglądu (z tego samego powodu nie budujesz layoutu
> strony w oparciu o tabelę, chociaż istnieją sytuacje gdy użycie tabeli
> byłoby prostsze).

Nie jest tu potrzebny styl liniowy. Wystarczy klasa.


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

On Fri, 10 Dec 2010 16:20:29 +0100, Mirosław Zalewski wrote:

> grudzień roku pamiętnego 2010, prawdopodobnie 10. Wielka mądrość na
> czytelników pl.comp.www spłynęła, gdy tako rzekł(a) Michał Gancarski:
>
>>> Wtedy szafę oznaczamy
>>> strongiem a ostrzeżenie wizualne boldem. Oczywiście jeśli łaty <b>
>>> nie powinno się stosować to wtedy trzeba znacznie dłuższą łatę
>>> <span style="..."> stosować, co jest jeszcze bardziej
>>> nieeleganckie. Prawda?
>>
>> Co jest nieeleganckiego w "span"?
>
> W spanie nic. Tylko tutaj nie chodzi o span ale o span ze stylem
> liniowym. Taka konstrukcja zaburza zasadę oddzielenia struktury
> dokumentu od jego wyglądu (z tego samego powodu nie budujesz layoutu
> strony w oparciu o tabelę, chociaż istnieją sytuacje gdy użycie tabeli
> byłoby prostsze).

A, w zasadzie to nie zaburza.


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 2010-12-10 12:00, Marek pisze:
> Mam tu spore wątpliwości natury technicznej. To wydaje mi się póki co
> bardzo trudne do osiągnięcia lub w ogóle nie do zrealizowania.

Na jednym biegunie masz Wiki - czysta semantyka. Na drugim:
content-editable HTML - czysta forma. Nie wiem, czy da się połączyć
zalety obu.

artur

do góry

grudzień roku pamiętnego 2010, prawdopodobnie 10. Wielka mądrość na
czytelników pl.comp.www spłynęła, gdy tako rzekł(a) Michał Gancarski:

> > W spanie nic. Tylko tutaj nie chodzi o span ale o span ze stylem
> > liniowym. Taka konstrukcja zaburza zasadę oddzielenia struktury
> > dokumentu od jego wyglądu (z tego samego powodu nie budujesz layoutu
> > strony w oparciu o tabelę, chociaż istnieją sytuacje gdy użycie
> > tabeli byłoby prostsze).
>
> A, w zasadzie to nie zaburza.

Jak nie zaburza, kiedy zaburza? Stosując style liniowe masz dwa miejsca
które określają wygląd dokumentu -- zewnętrzny styl CSS oraz atrybut
określonego tagu. Jeśli dodatkowo taki styl liniowy jest generowany
przez CMS którego nie jesteś autorem, to zmiana wyglądu dokumentu może
być naprawdę uciążliwa (a generalnie po to stosuje się zewnętrzne
style, aby zmiana wyglądu była prosta).

Uwaga o tym że wystarczy klasa jest skierowana do Marka, bo on podał
przykład spana ze stylem liniowym, więc on powinien wiedzieć dlaczego
używa tam stylu liniowego a nie klasy.
--
Niżej podpisany, zamieszkały w http://minio.xt.pl ,
Mirosław Zalewski

do góry

On Sat, 11 Dec 2010 12:40:34 +0100, Mirosław Zalewski wrote:

> grudzień roku pamiętnego 2010, prawdopodobnie 10. Wielka mądrość na
> czytelników pl.comp.www spłynęła, gdy tako rzekł(a) Michał Gancarski:
>
>>> W spanie nic. Tylko tutaj nie chodzi o span ale o span ze stylem
>>> liniowym. Taka konstrukcja zaburza zasadę oddzielenia struktury
>>> dokumentu od jego wyglądu (z tego samego powodu nie budujesz layoutu
>>> strony w oparciu o tabelę, chociaż istnieją sytuacje gdy użycie
>>> tabeli byłoby prostsze).
>>
>> A, w zasadzie to nie zaburza.
>
> Jak nie zaburza, kiedy zaburza? Stosując style liniowe masz dwa miejsca
> które określają wygląd dokumentu -- zewnętrzny styl CSS oraz atrybut
> określonego tagu. Jeśli dodatkowo taki styl liniowy jest generowany
> przez CMS którego nie jesteś autorem, to zmiana wyglądu dokumentu może
> być naprawdę uciążliwa (a generalnie po to stosuje się zewnętrzne
> style, aby zmiana wyglądu była prosta).

Separacja nie oznacza wyprowadzenia deklaracji CSS do innego pliku tylko
dbanie o to by struktura dokumentu HTML była możliwie niezależna od
graficznego layoutu i założonego wyglądu o odzwieciedlała jedynie
semantykę. To czy do elementu wrzucisz parametr "class" czy "style" na
strukturę nie wpłynie. Pierwsze rozwiązanie jest bardziej eleganckie ale z
pewnością nie bardziej "separujące". W obu przypadkach elementy HTML
zajmują się strukturą, a CSS wyglądem.

W przypadku CMSa, nad którym nie masz kontroli, też nie ma to znaczenia.
Równie dobrze tenże CMS może po prostu nie generować żadnych klas dla
interesujących Cię elementów i jesteś w kropce tak czy siak, niezależnie od
tego jak chcesz "separować" wygląd i strukturę.

[...]


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry