W dniu 2010-12-11 14:54, Michał Gancarski pisze:
> 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.

IMHO jednak semantyka pogarsza się w tej kolejności: tag->class->style.
Korzystając z okazji podam przykład, który fajnie wygląda (bo
semantycznie) w tutorialu, ale gorzej w rzeczywistości:
<li class="google">Google</li>
<li class="zune">Zune</li>
Gdzie w klasach są zdefiniowane ikonki (background-image). To jest dobre
dla tekstów wklepanych ręcznie, ale nie w CMS (jeśli lista ikonek nie ma
być z góry określona).

artur

do góry

W dniu 2010-12-10 14:26, Michał Gancarski pisze:
>
> Na stronie WWW? Podaj przykład z życia raczej.

Nie chcę cytować URL jednakże konkretnie: mamy stronę opisującą jakiś
zabieg kosmetyczny. Opisana jest technologia tego zabiegu i promujemy
nazwę tej technologii.

Na końcu dłuższego artykułu są wyróżnione przeciwwskazania. Zależy nam
bardzo aby rzuciły się one w oczy czytającemu i w żadnym przypadku nie
stały się celem pozycjonowania.

> Co jest nieeleganckiego w "span"?

Zmienia się przelicznik kodu do treści gdy boldy zaczniemy robć jako:

<span style="font-weight:bold">xxx</span>

zamiast

<b>xxx</b>

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

Ja z tym nie mam problemów :-) Mnóstwo opcji redagowanego dokumentu
uzależnionych jest od sekcji w jakiej go tworzymy. Np. jeśli serwis jest
sklepem to dokument może mieć cechy cena i rozmiar w kategorii obuwia, a
w akcesoriach do tenisa tylko cena. To tylko wierzchołek góry tego co
"samo" się dostosowuje do potrzeb danego typu dokumentu.

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

Hmmm... dziwne dla mnie byłoby takie podejście szczerze mówiąc. Przede
wszystkim niepotrzebnie kosztowne.

> 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.

Ale tylko o nim mówimy.

>> 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.

Ok. Mamy serwis z białym tłem czarne litery 12px Arial. W edytorze też
tak widzimy. Skórka się zmienia bo ktoś umarł. Strona staje się czarna,
białe litery, Times 10px. Edytor wyświetla nasz dokument po staremu
jeśli go nie przerobimy.

A co jeśli serwis ma N skórek do wyboru przez użytkownika? N edytorów
będzie potrzebnych?

do góry

W dniu 2010-12-10 23:20, Artur Muszyński pisze:
> Na jednym biegunie masz Wiki - czysta semantyka. Na drugim:
> content-editable HTML - czysta forma. Nie wiem, czy da się połączyć
> zalety obu.

No to wróciliśmy do punktu wyjścia :-)

do góry

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

> 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.

Przyjmuję Twoje stanowisko, ale pozwolisz że będę upierał się przy
swoim -- lepiej stosować klasy niż style liniowe. Poza tym co
zasugerował Artur w swojej wypowiedzi -- tam gdzie można powinno się
stosować same tagi. Zwłaszcza w kontekście coraz szerszej obsługi przez
przeglądarki selektorów proponowanych dla CSS3 jest to coraz prostsze.
--
Niżej podpisany, zamieszkały w http://minio.xt.pl ,
Mirosław Zalewski

do góry

On Sat, 11 Dec 2010 23:54:39 +0100, Mirosław Zalewski wrote:

> grudzień roku pamiętnego 2010, prawdopodobnie 11. Wielka mądrość na
> czytelników pl.comp.www spłynęła, gdy tako rzekł(a) Michał Gancarski:
>
>> 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.
>
> Przyjmuję Twoje stanowisko, ale pozwolisz że będę upierał się przy
> swoim -- lepiej stosować klasy niż style liniowe. Poza tym co
> zasugerował Artur w swojej wypowiedzi -- tam gdzie można powinno się
> stosować same tagi. Zwłaszcza w kontekście coraz szerszej obsługi przez
> przeglądarki selektorów proponowanych dla CSS3 jest to coraz prostsze.

Spoko, z tym się zgadzam w pełni :-)


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 11.12.2010 19:14, Marek pisze:

> Zmienia się przelicznik kodu do treści gdy boldy zaczniemy robć jako:
>
> <span style="font-weight:bold">xxx</span>
>
> zamiast
>
> <b>xxx</b>
>

Co nie jest ani troche lepsze.
<b> jest semantycznie tak samo wartosciowe jak span.
W tym miejscu powinien byc <strong>





--
Piotr Siudak
s...@x...pl

do góry

On Sun, 12 Dec 2010 11:58:49 -0000, Piotr Siudak <s...@x...pl> wrote:

>> Zmienia się przelicznik kodu do treści gdy boldy zaczniemy robć jako:
>>
>> <span style="font-weight:bold">xxx</span>
>>
>> zamiast
>>
>> <b>xxx</b>
>>
>
> Co nie jest ani troche lepsze.
> <b> jest semantycznie tak samo wartosciowe jak span.
> W tym miejscu powinien byc <strong>

Jeżeli WYSIWYG ma w UI [ B ] i [ I ], to powinno być <b> i <i> w kodzie.
Inaczej użytkownik będzie nadużywał <strong> i <em> do pogrubiania/kursywy.

--
http://pornel.net
this.author = new Geek("porneL");

do góry

On Sun, 12 Dec 2010 14:12:17 -0000, porneL wrote:

[...]

>> Co nie jest ani troche lepsze.
>> <b> jest semantycznie tak samo wartosciowe jak span.
>> W tym miejscu powinien byc <strong>
>
> Jeżeli WYSIWYG ma w UI [ B ] i [ I ], to powinno być <b> i <i> w kodzie.

Chyba, że będzie generowany odpowiedni span. To jest jednak imho lepsze.
Wiadomo, że intencja jest jaka jest - pogrubienie i kursywa, niemniej w
zależności od designu tak zaznaczone fragmenty mogą uzyskiwać dodatkowe
stylowanie. Kursywa np. może dostawać czcionkę szeryfową, pogrubienie
dodatkowo ciemniejsze tło itp. [B] i [I] na przyciskach nie służą
powiadomieniu CSMa o tym co ma zrobić tylko poinformowaniu użytwkonika co
się mniej więcej stanie.

[...]


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 12.12.2010 15:12, porneL pisze:
> On Sun, 12 Dec 2010 11:58:49 -0000, Piotr Siudak <s...@x...pl> wrote:
>> Co nie jest ani troche lepsze.
>> <b> jest semantycznie tak samo wartosciowe jak span.
>> W tym miejscu powinien byc <strong>
>
> Jeżeli WYSIWYG ma w UI [ B ] i [ I ], to powinno być <b> i <i> w kodzie.
> Inaczej użytkownik będzie nadużywał <strong> i <em> do pogrubiania/kursywy.
>

problemem jest uzytkownik który naduzywa guzika [B] i [I] a nie to czym
skutkuje nacisniecie guzika. Powinno skutkowac <strong> i <em> bo to
jest to czego _tak_naprawde_ chce uzytkownik. Mimo ze może nawet nie wie.

--
Piotr Siudak
s...@x...pl

do góry

On Sun, 12 Dec 2010 14:28:26 -0000, Michał Gancarski
<m...@g...com> wrote:

>>> Co nie jest ani troche lepsze.
>>> <b> jest semantycznie tak samo wartosciowe jak span.
>>> W tym miejscu powinien byc <strong>
>>
>> Jeżeli WYSIWYG ma w UI [ B ] i [ I ], to powinno być <b> i <i> w kodzie.
>
> Chyba, że będzie generowany odpowiedni span. To jest jednak imho lepsze.
> Wiadomo, że intencja jest jaka jest - pogrubienie i kursywa

HTML ma dwa elementy dokładnie do wyrażenia tej intencji i <span> nie jest
wśród nich.

> niemniej w zależności od designu tak zaznaczone fragmenty mogą uzyskiwać
> dodatkowe
> stylowanie. Kursywa np. może dostawać czcionkę szeryfową, pogrubienie
> dodatkowo ciemniejsze tło itp.

Jak chcesz w edytorze przycisk, który ma wyróżniać tekst, ale w inny
sposób, niż pogrubienie, to zrób do tego inny przycisk. I może wtedy
wstawiać <b class="inne-wyróżnienie"> :)


Jeśli chodzi ci o problem, że stylami da się zepsuć <b>, to <span> też da
się zepsuć:

span[style*=bold] {background:red}


Semantyczność <span> i <b> jest w obu przypadkach bylejaka, ale kod z <b>
przynajmniej działa bez CSS, jest krótszy i jak pogrubienia w kodzie
zaczną ci przeszkadzać, to będzie łatwiej zmienić/usunąć <b>, niż parsować
style w <span>.

--
http://pornel.net
this.author = new Geek("porneL");

do góry