No dobra, pytanie do ekspertów.
Znowu moim poligonem doświadczalnym jest forum GOL 
Pewien przyjazny nam inaczej forumowicz zwrócił uwagę na rozjeżdżające sie w Operze checkboxy na górze. Wziąłem to pod lupę, wyciągnąłem ten element, konkretnie tabelę i rzeczywiście, na dole załączam wynik. Wygląda zupełnie inaczej w IE (kolumny równe) i w Operze (kolumny rozjeżdżają się). Strona jest Valid, można sprawdzić. Czym jest powodowane to spore rozjeżdżanie się elementów?
Chcę tylko zwrócić uwage że komórki są ok dopóki ich zawartość nie przekroczy 5-6 znaków. IE też przesuwa zawartość, ale nieznacznie, Opera, że tak powiem, idzie na całość.. Podobnie Firebird. Czy nie powinno być zmian?
Sprawdźcie htmla (mam nadzieje że URL zadziała): [tutaj]
Re: różnice w renderowaniu tabel z <inputem>
Originally posted by oksza
Strona jest Valid, można sprawdzić.
To, ze strona czy css jest valid nie oznacza prawie nic - tylko to, ze domknales tagi, nie masz bledow w skladni, itepe. Strona moze dzialac lub nie, byc brzydka lub nie, miec sens lub nie, byc accessible lub nie, niezaleznie od valid code.
Uzywasz tabel do wizualnego formatowania, co nie ma sensu. Kazda komorka ma ponadto te sama class, co rowniez nie ma sensu.
Originally posted by oksza
Czym jest powodowane to spore rozjeżdżanie się elementów?
Nie wiem, nie patrzylem. Ja nie znam sie na tabelach uzywanych do takich rzeczy. Mam nadzieje, ze wspomniani eksperci pomoga ci w rozwiazaniu problemu.
powodzenia,
M.
Dzieje się tak, ponieważ nie jest określone, jak szerokie mają być kolumny.
Można to zrobić w następnujący sposób: do każdej tabelki dodać na przykład coś takiego:
<colgroup span="9" width="11%">Zapewne da się to także zrobić przy pomocy CSS, ale na razie nie doczytałem jak.
Originally posted by pablik
Zapewne da się to także zrobić przy pomocy CSS, ale na razie nie doczytałem jak.
Dzieje się tak, ponieważ nie jest określone, jak szerokie mają być kolumny.
Można to zrobić w następnujący sposób: do każdej tabelki dodać na przykład coś takiego:
Wiem, że można tak zrobić. Tylko moje pytanie: czemu Opera ustawia elementy niezdefiniowanej tak dziwacznie? Wydaje mi się że powinno to wyglądać bardziej równo, vide IE/mozzila.
Originally posted by Moose
Uzywasz tabel do wizualnego formatowania, co nie ma sensu.
To nie mój kod
Może i nie ma, ale poprawny kod powinien generalnie wyglądać tak samo we wszystkich przeglądarkach - przynajmniej mniej więcej. A może się mylę?
Z tego co wiem w specyfikacji nie jest zdefiniowane jak domyślnie powinny wyglądać tabelki (w specyfikacji HTML 4.01 nie zauważyłem), może w CSS są podane domyślne wartości. Jeśli nie ma podanego w kodzie strony ani w specyfikacji domyślnego wyglądu, to chyba przeglądarki mają dowolność jeśli chodzi o wyświetlanie.
Osobiście przepisałem kiedyś swój plan lekcji w ramach nauki HTML-a (nie definiowałem wyglądu) i się przekonałem, że Opera, Firebird i IE wyświetliły go całkiem inaczej.
Originally posted by oksza
To nie mój kod
No nie koniecznie. Np. w domyślnym stylu Opery dla body jest ustawiony padding: 8px, podczas gdy w innych przeglądarkach margin: 8px:
http://www.opera.com/docs/specs/
I prawdą jest, że Opera ma jakiś dziwny algorytm ustawiania szerokości tych kolumn, dlatego powinno się na sztywno narzucić pożądaną szerokość.
Originally posted by quiris
No nie koniecznie. Np. w domyślnym stylu Opery dla body jest ustawiony padding: 8px, podczas gdy w innych przeglądarkach margin: 8px:
http://www.opera.com/docs/specs/
I prawdą jest, że Opera ma jakiś dziwny algorytm ustawiania szerokości tych kolumn, dlatego powinno się na sztywno narzucić pożądaną szerokość.
Dzięki. Z waszych wypowiedzi wynika że nie jest to problem standardów, raczej hmm... dobrych chęci. Nie zmienia to faktu że fajnie by było gdybym miał w ręku argument: "wszystko wygląda tak samo" - z miłośnikami IE niestety tak trzeba rozmawiać.
Witam!
Ja tez w sprawie tabelek...
Ostatnimi czasy koresponduje ze znajomym (nb. dobrym programista) i wywiazala sie dyskusja nt. Opery (zaczelo sie od tego, ze jego strona nie wyswietlala sie pod O). A teraz po kolei obala on moje argumenty odn. wyzszosci Opery nad dzielem Billa i spolki.
Oto drugi z testow, ktory mi przyslal (pierwszy dotyczyl szybkosci interpretera js - Opera przegrywa z IE o 18%) - no i nie wiem co mu odpowiedziec, bo rzeczywiscie w O jest cos nie tak...
Nie znam html'a, wiec nie wiem czym konkretnie roznia sie te dwa sposoby deklaracji tabeli/kolumn i dlaczego Opera wyswietla je w rozny sposob...
Pozdrowienia.
PS. zalacznik w pliku .txt bo htmla forum nie przyjmuje...
test.txt
Widze:
<col style="width:100px; background-color:yellow; padding: 5 5 5 5">
Polecam:
http://ln.hixie.ch/?start=1070385285&count=1
Pytam:
Kto zezarl miary w padding? A nuz to w kilogramach...
Czytam:
(pure!!!) HTMLa
I nijak sie zgodzic nie moge. HTML to moze i jest, ale od czystosci to mu daleko. Polecam WC-Picker albo Mr Muscle... A i stary Ludwik albo E tez sobie dac rade powinno!
M.
Originally posted by jaqbk
Oto drugi z testow, ktory mi przyslal (pierwszy dotyczyl szybkosci interpretera js - Opera przegrywa z IE o 18%) - no i nie wiem co mu odpowiedziec, bo rzeczywiscie w O jest cos nie tak...
Wiesz, punkt widzenia zależy od punktu siedzenia. Na pewno można znaleźć skrypty szybciej wykonywane w Operze niż MSIE. Jednak prawdą jest, że silnik JScript udał się Microsoftowi jak mało co. Jest naprawdę wydajny. Inna sprawa, że nie jest to czysty ECMAScript, tylko microsoftowa odmiana JScript zawierająca szereg niestadardowych funkcji.
[/quote]
Nie znam html'a, wiec nie wiem czym konkretnie roznia sie te dwa sposoby deklaracji tabeli/kolumn i dlaczego Opera wyswietla je w rozny sposob...
Twój kolega daje Ci do oglądania jakiś plik z pozoru wyglądający na poprawny.
Po pierwsze DTD jest niepoprawny. Wymusza on działanie Opery w trybie "dziwnym": http://www.opera.com/docs/specs/doctype/ i dlatego Opera traktuje te zapis padding:2 5 2 5 jako padding:2px 5px 2px 5px. Zgodnie ze specyfikacją CSS2 (gdyby zadeklarowany był poprawny DTD) taka definicja powinna być zignorowana.
Po drugie wg specyfikacji CSS2: http://www.w3.org/TR/CSS2/tables.html#q4 kolumnom mogą być nadawane tylko cztery wartości: 'border', 'background','width', 'visibility'. Zauważ, że nie ma tej liście padding, dlatego działanie Opery jest zgodne ze standardem. Bardzo dobre wyjaśnienie tego zagadanienia jest opisane przez Hixiego w linku podanym przez Moose'a.
dzieki za wyjasnienia
tymczasem dostalem kolejnego maila - tym razem z przykladem (podobno) niepoprawnego wcinania i position: absolute
jeszcze raz dzieki i pozdrowienia
test2.txt
Originally posted by jaqbk
tymczasem dostalem kolejnego maila - tym razem z przykladem (podobno) niepoprawnego wcinania i position: absolute
Sprawa jest hmm... śliska. Zadałem tu i ówdzie pytania, jak coś będę wiedział jednoznacznie to dam znać.
Originally posted by quiris
Sprawa jest hmm... śliska. Zadałem tu i ówdzie pytania, jak coś będę wiedział jednoznacznie to dam znać.
Zrobiłem stronę testową: http://quiris.klub.chip.pl/width.html
Więc po pierwsze. Jednoznacznie należy stwierdzić, że MSIE nadając (dla width:auto) szerokość 100% (zamiast możliwie najmniejszą zgodnie z odpowiednim algorytmem) elementowi pozycjonowanemu absolutnie, łamie ustalenia standardu CSS2.1: http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width
Wiem, że standardu CSS2.1 jeszcze nie ma, ale w standardzie CSS2 te sprawy nie są jednoznacznie sprecyzowane. CSS2.1 został stworzony m.in. w tym celu, aby doprecyzować niejasne obszary i jest kwestią kilku miesięcy jak ujrzymy ostateczną wersję CSS2.1
Po drugie: Pomijając MSIE, które jest całkowicie niezgodne ze standardem, są dwie szkoły wcinania:
1) Mozilla: najpierw wcina, a potem wylicza szerokość elementu absolutnie pozycjonowanego
2) Opera: najpierw wylicza szerokość elementu, a później wcina.
W tej chwili nie mam jednoznacznej odpowiedzi, która metoda jest poprawna (ja osobiście skłaniałbym się do tego co proponuje Opera, ale jest to moja subiektywna opinia)
Jak powiedzialem na forum web-design, nie dodales szerokosci do parent DIVs. Poniewaz ten element jest absolutely positioned, nie ma szerokosci jako takiej (nie ma skad inheritowac).
Dodaj szerokosc, i zobacz co sie dzieje.
M.
Originally posted by Moose
Dodaj szerokosc, i zobacz co sie dzieje.
Wiem, że po ustawieniu na sztywno width, będzie identycznie w Mozilli, w Operze i w MSIE.
Zauważ, że staram się odpowiedzieć na konkretny zarzut (przykład) i w tym przykładzie mamy width:auto, bo to właśnie dzięki złożeniu position:absolute (z position:fixed jest to samo), text-indent oraz width:auto widzimy te różnice w renderowaniu.
Mam w tej chwili tylko jeden dylemat: Który sposób wyliczania szerokości jest prawidłowy? Czy ten Mozilli (Safari identycznie się zachowuje), czy ten Opery?
Z tego co przeszukałem nie uzyskałem jednoznacznej odpowiedzi i boję się, że jej nie uzyskam.
No nie -- z tego, co widzialem, to parent DIVs nie maja ustawionej szerokosci, nawet auto. Jesli mi oczy wysiadly, to zwracam honor.
M.
Originally posted by Moose
No nie -- z tego, co widzialem, to parent DIVs nie maja ustawionej szerokosci, nawet auto. Jesli mi oczy wysiadly, to zwracam honor.
Jeśli nie ma ustawionej żadnej to domyślna jest auto: http://www.w3.org/TR/CSS21/visudet.html#the-width-property
Ok. Aby pozbyć się wątpliwości ustawiłem width:auto.
Nie wiem, co ci poradzic. Z mojej praktyki wynika, ze absolutely positioned elements wymagaja szerokosci parent element. Dlatego zawsze mam 100% na body i swiety spokoj
M.
Originally posted by Moose
Dlatego zawsze mam 100% na body i swiety spokoj
No tak, w normalnych, praktycznych zastosowaniach wystarczy poustawiać dodatkowe własności i zapominamy o sprawie. Tu rozważamy sobie typowo akademicki problem.
No i chyba sprawa raczej definitywnie się rozwiązała.
Rijk van Geijtenbeek uważa, że to Mozilla (Safari, Konqueror) mają rację, a jeśli nawet racji nie mają to i tak robią to lepiej niż Opera 7.23. Oczywiście nie zmienia to faktu, że Internet Explorer robi to całkowicie błędnie.
No i na koniec pomyślna wiadomość. Rijk sprawdził jak wygląda moja strona testowa w Operze 7.30. No i wygląda identycznie jak Mozilla Firebird 0.7 .
Tak więc bug został już w tej chwili usunięty i na Gwiazdkę pewnie dostaniemy betę 7.30
Sorki, ze jeszcze raz zawracam Wam glowe, ale moj znajomy nie daje za wygrana
Oto kolejna wersja "testu przegladarek" - doszlo pare "kwiatkow".
Oto fragment listu:
Mysle, ze test z czterema tabelkami zadziwi nawet forum Opery. Nie mówiac juz o Tobie. Mam troche doswiadczenia w programowaniu, a nie potrafilem wymyslec, jak ona to robi. Jak to mozliwe aby w jednej kolumnie tabeli komórki mialy rózna szerokosc, albo tez tabelka nagle "zapomniala", ze ma "border="1" i "text-align:center". Zmiana czegokolwiek w iDOCTYPE nie wplywa na koncowy efekt. Mozilli i Netscape dalem tylko 0,5 pkt., bo mialy drobne kuchy. Zapomnialy ukryc obramowanie "hiddnietej" komórki i troche to niestarannie wyglada. Pozdrawiam, do nastepnego testu.
Jak tak dalej pojdzie, to chyba go poprosze, zeby sam zaczal tu pisac (jesli bedzie mial ochote) - ciezko jest rozmawiac przez posrednika nie majacego zbyt duzego pojecia o temacie rozmowy... ;-)
Pozdrowienia
test4.txt
Witam,
Postanowiłem dorzucić coś od siebie.
Właśnie konstruuję szkielet skromnej strony i natrafiłem na różnice w jej renderowaniu pomiędzy Operą a IE. Co ciekawsze, ie zaczął się na niej wywalać. Zastanawiam się, która przeglądarka renderuje stronę prawidłowo. Pomijam to, że ie wogóle nie uwzględnia ":hover" w stylu.
link do strony (mam nadzieję że będzie się otwierać - różnie to bywa): http://www.beebee.host.sk/temp/plik.html
załączam także kod w pliku tekstowym.
Proszę o opinie i wskazówki. Dodam że strona się waliduje w 100%, więc wynika z tego że kod nie jest jakimś wymysłem.
pozdrawiam, alek
plik.txt
Originally posted by alek
Właśnie konstruuję szkielet skromnej strony i natrafiłem na różnice w jej renderowaniu pomiędzy Operą a IE. Co ciekawsze, ie zaczął się na niej wywalać. Zastanawiam się, która przeglądarka renderuje stronę prawidłowo. Pomijam to, że ie wogóle nie uwzględnia ":hover" w stylu.
To, że kod się waliduje to nie jest jednoznaczne z tym, że wszystkie przeglądarki bedą wyświetlać taką stronę jednakowo!
Problem jest w tym, że używasz definicji typu documentu DOCTYPE, który akurat wymusza w Operze tryb QuirksMode: http://www.opera.com/docs/specs/doctype/ (tam masz podane różnice w interpretacji kodu html w tych trybach). Ten sam DTD w MSIE 6.0 wymusza działanie w trybie zgodności ze standardami.
To działanie powoduje, że szerokość zawartości + dopełnienie + szerokość obramowania traktowana jest jako szerokość width (emulacja działania MSIE 3.0-5.5), gdy tymczasem w tybie zgodności ze standardami szerokość width jest tylko szerokością zawartości. Czyli twoje złożenie spanów w trybie standardowym tak naprawdę ma więcej niż 100%, ponieważ musisz jeszcze uwzględnić szerokości ramek 1px, dlatego w MSIE 6.0 spany nie mieszczą się w linii i są zawijanie.
Ustaw sobie poprawny DOCTYPE i popraw style.
Wpisz w okienku (bez spacji w słowie javascript) adresu (działa w Operze, MSIE i Mozilli):
javascript:alert(document.compatMode);i naciśnij enter. Okienko, które się pojawi pokaże Ci, którego trybu używa przeglądarka. CSS1Compat oznacza tryb standardowy.
:hover w MSIE działa tylko na linkach.
Originally posted by jaqbk
Jak tak dalej pojdzie, to chyba go poprosze, zeby sam zaczal tu pisac (jesli bedzie mial ochote) - ciezko jest rozmawiac przez posrednika nie majacego zbyt duzego pojecia o temacie rozmowy... ;-)
Brakuje mi pliku: test2.js do tego testu i rzeczywiście, mógłby się kolega pofatygować osobiście. Przecież tyle tych błędów, że wskazana byłaby pomoc w ich identyfikacji i przesyłaniu bugreportów
.Jak dostanę ten brakujący plik to postaram się ustosunkować do zarzutów.
Originally posted by quiris
To, że kod się waliduje to nie jest jednoznaczne z tym, że wszystkie przeglądarki bedą wyświetlać taką stronę jednakowo!
Problem jest w tym...
Dzięki za cenne uwagi - na pewno zostaną uwzględnione
alek
A czy zagnieżdżanie elementów blokowych w elementach "liniowych" jest poprawne?
Bo AFAIK nie...
Originally posted by daroc
A czy zagnieżdżanie elementów blokowych w elementach "liniowych" jest poprawne?
Przepraszam, ale gdzie masz elementy blokowe w elementach liniowych (wewnętrznych)?
Mea culpa - zapomnialem o skrypcie.
test2.js.txt
Originally posted by jaqbk
Mea culpa - zapomnialem o skrypcie.
Eee... no takich kwiatków to się nie powinno robić (zawartość pliku test2.js):
Nie mogłem się powstrzymać
Reszta raportu jutro
quiris napisał(a)
Spróbuję się ustosunkować do każdego z siedmiu testów:
5) Nie wiem co tu ma być źle, bo u mnie we wszystkich trzech przeglądarkach wygląda to identycznie (+1 dla wszyskich)
7) Hmm... Gdzie tu widać naruszenie standardu? To czy przeglądarka ma rysuje pionowy pasek, to raczej jest kwestia kosmetyki niż naruszenia standardu. Punktacja Mozilla 1pkt, Opera i MSIE 0.5pkt (za kosmetykę)
Dzieki za tak szybka odpowiedz.
ad. 5 - Wygladalo gorzej w O7.21. Teraz rzeczywiscie jest OK.
ad. 7 - Jak dla mnie w tym punkcie to IE ma nienaganna "kosmetyke". Chociaz scrollbar tak bardzo mi nie przeszkadza...
Jeszcze dwie sprawy:
- pojawila sie nowa wersja testu, z punktacja za kazdy etap i "mniej agresywnymi" tekstami (jest w zalaczniku)
- zaprosilem mojego wujka do wspolpracy na tym forum - jesli sie zgodzi to powinno byc ciekawie...
Pozdrowienia.
test4.txt
Spróbuję się ustosunkować do każdego z siedmiu testów:
1) Ten test już był tu omawiany i udowodniłem, że MSIE błędnie aplikuje padding dla elementu COL (http://www.w3.org/TR/CSS2/tables.html#q4). Kolor w Operze jest, natomiast nie wiem, dlaczego go nie ma w Mozilli, wszak zgodnie, ze specyfikacją można nadawać kolumnom własność background. Moja punkacja: MSIE 0.5 pkt (za kolor), Mozilla 0.5 pkt(za padding), Opera 1 pkt.
2) Jedynie Opera poprawnie reaguje na próbę parsowania zewnętrznego pliku JS, który musi zawierać jedynie czysty kod JS. Obecność np. komentarzy htmlowych w takim pliku powinna być skwitowana wyszuceniem błędu parsowania przez interpretera JS. Że MSIE ignoruje te komentarze jeszcze mogę zrozumieć, natomiast nie rozumiem dlaczego Mozilla powiela niezgodne ze standardami zachowanie. Opera wyrzuca błąd składni i słusznie:
[url]http://quiris.klub.chip.pl/test2.js[/url] Unknown context Syntax error while loading (line 7) --> ----^
Punktacja: Opera 1pkt, Mozilla i MSIE 0 pkt
3) Ten test też już był omawiany. Powtórzę, jakkolwiek nikt nie potrafił mi udzielić jednoznacznej odpowiedzi, że Opera narusza standard, to jednak faktem, jest, że nie wygląda to najlepiej (w sumie jest to bardzo, szczególny przypadek, objawiający się praktycznie tylko w tych szczególnych okolicznościach, position: absolute, text-indent i krótki tekst jednoliniowy. Zachowanie zostało poprawione w 7.30. Punktacja: MSIE i Mozilla +1pkt, Opera 0 pkt. Acha przy okazji polecam, parę testów koledze na text-indent i position-absolute ( http://www.hixie.ch/tests/adhoc/css/box/absolute/ oraz http://www.hixie.ch/tests/adhoc/css/box/block/text-indent/ ) niech porówna sobie wyniki w MSIE i w Operze
4) To nie jest błąd, raczej efekt uboczny obsługi przez Operę niestandardowej kolekcji document.all, gdzie stosuje się właśnie notację w nawiasach zwykłych, np. document.all.table.rows(i).cells(1) Mozilla, rzeczywiście wywala błąd, dlatego, że nie obsługuje kolekcji document.all Punktacja. Mozilla 1pkt; MSIE, Opera 0.5pkt (wszak działa przy notacji takiej i takiej).
5) Nie wiem co tu ma być źle, bo u mnie we wszystkich trzech przeglądarkach wygląda to identycznie (+1 dla wszyskich)
6) edit: to co było napisane w tym miejscu było błędem wynikającym z niedopatrzenia
Wkrótce pojawi się poprawna wersja komentarza. 7) Hmm... Gdzie tu widać naruszenie standardu? To czy przeglądarka ma rysuje pionowy pasek, to raczej jest kwestia kosmetyki niż naruszenia standardu. Punktacja Mozilla 1pkt, Opera i MSIE 0.5pkt (za kosmetykę)
Punktacja ostateczna: Opera: 4.0 pkt, Mozilla 4.5 pkt, MSIE 3.5pkt.
Testowałem na:
1) Opera/7.23 (Windows NT 5.0; U) [en]
2) Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031215 Firebird/0.7+
3) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Komentarz nr 6 był niestety błędnie sformułowany. Poprawna wersja wkrótce.
Originally posted by quiris
1) Ten test już był tu omawiany i udowodniłem, że MSIE błędnie aplikuje padding dla elementu COL (http://www.w3.org/TR/CSS2/tables.html#q4). Kolor w Operze jest, natomiast nie wiem, dlaczego go nie ma w Mozilli, wszak zgodnie, ze specyfikacją można nadawać kolumnom własność background.
Trochę więcej szczegółów na ten temat w moim żurnalu: http://my.opera.com/quiris/journal
Originally posted by quiris
Komentarz nr 6 był niestety błędnie sformułowany. Poprawna wersja wkrótce.
Utworzyłem dwa nowe zestawy testowe dotyczące punktu 6. Szczegóły w moim żurnalu: http://my.opera.com/quiris/journal/4. Wprawdze english tym razem, ale specjalnych przemyśleń tam nie zawierałem. Postawiłem pytania. Każdy może sobie odpalić testy i zobaczyć jak to wygląda. Wg moich doświadczeń i tego co ujrzałem punktowałbym następująco: Mozilla 1pkt, Opera 0.5 pkt (za trzecią tabelę), MSIE 0 pkt (generalnie algorytm renedrujący tabele w MSIE olewa zupełnie deklaracje: display:table, display:table-row; display: table-cell i renderuje tradycyjne htmlowe tabele na swój dziwaczny sposób).
Oczywiście, jeśli pojawią się nowe nieznane okoliczności z uwagi na grząski temat punktacja może ulec zmianie.
Witam!
Dostalem odpowiedz na argumentacje quirisa z 16/12/2003:
Witam.
W zalaczeniu nowe testy. Moje uwagi i odp. (dziela zebrane) na dyskusje nt. wszystkich dotychczasowych testów + koment. do nowych, lub pominietych w dyskusji.
Test 1. Recenzent pisze:
Ten test juz byl tu omawiany i udowodnilem (sic!), ze MSIE blednie aplikuje padding dla elementu COL. Kolor w Operze jest, natomiast nie wiem, dlaczego go nie ma w Mozilli, wszak zgodnie, ze specyfikacja mozna nadawac kolumnom wlasnosc background. Moja punkacja: MSIE 0.5 pkt (za padding), Mozilla 0.5 pkt(za kolor), Opera 1 pkt.
Moja interpretacja jest nastepujaca: IE i Opera prawidlowo ustalily kolor tla, za co dostaly po 1 pkt. Mo/Ns - nie, wiec 0 pt. To, ze standard CSS ustala, iz jakis atrybut odnosi sie do pewnej grupy elementów, nie oznacza, iz NIE WOLNO GO STOSOWAC DO INNYCH. Nikt nie ma oczywiscie obowiazku stosowac rozszerzen MS, ale ta "nadgorliwosc" moze byc moim zdaniem ukarana jedynie pod haslem "dokopac M$ za wszelka cene". Inna sprawa, ze nie powinno sie stosowac tzw. fanaberii M$, jesli sie chce, aby strona byla czytelna we wszystkich przegladarkach.
Test 2. Nieprawda jest, jakoby:Odpowiedzi zreszta dostarczyl autor recenzji dolaczajac zapis rzekomego bledu skladni:Jedynie Opera poprawnie reaguje na próbe parsowania zewnetrznego pliku JS, który musi zawierac jedynie czysty kod JS.
Unknown context
Syntax error while loading (line 7)
-->
----^
W linii 7 znajduje sie koniec html-owego komentarza i to wlasnie nie spodobalo sie Operze. Zachowala sie tutaj wyjatkowo ortodoksyjnie, domagajac sie dodatkowego komentarza JS "//". Inne przegladarki potrafia rozpoznac koniec komentarza, skoro w 1 linii byl poczatek. Wystarczy, aby zapis w zewnetrznym pliku, który jak twierdzi recenzent nie moze zawierac nic, oprócz czystego kodu JS wygladal nastepujaco: i Opera test przechodzi bezblednie. Swoja droga ciekaw jestem, skad recenzent czerpie informacje, które podal. Poza tym uwazam, iz nie powinno sie w recenzji uzywac argumentów typu: "To,ze MSIE ignoruje te komentarze jeszcze moge zrozumiec, natomiast nie rozumiem dlaczego Mozilla powiela niezgodne ze standardami zachowanie.", bo moga swiadczyc o braku obiektywizmu ich autora. Mozna by teraz ew. dyskutowac na ile pkt. Opera zasluguje. Moim zdaniem na 0,5 pkt.
Test 3. Zostal juz omówiony, dobrze, ze w wersji 7.30 Opery blad zostal poprawiony. Zdumiewa tylko komentarz recenzenta, który stwierdzil:Aby udowodnic, ze sie myli, elementom powyzszym dodalem ramke, co chyba rozwiewa wszelkie watpliwosci ... Ton recenzji pozostawiam bez komentarza.Nalezy stwierdzic, ze MSIE nadajac (dla width:auto) szerokosc 100% (zamiast mozliwie najmniejsza zgodnie z odpowiednim algorytmem) elementowi pozycjonowanemu absolutnie, lamie ustalenia standardu CSS2.1: oraz Oczywiscie nie zmienia to faktu, ze Internet Explorer robi to calkowicie blednie...
Test 4. Recenzent napisal:To nie jest blad, raczej efekt uboczny obslugi przez Opere niestandardowej kolekcji document.all, gdzie stosuje sie wlasnie notacje w nawiasach zwyklych, np. document.all.table.rows(i).cells(1)
Mozilla, rzeczywiscie wywala blad, dlatego, ze nie obsluguje kolekcji document.all Punktacja. Mozilla 1pkt; MSIE, Opera 0.5pkt (wszak dziala przy notacji takiej i takiej). Bylem szczerze zdziwiony taka argumentacja, poniewaz nieszczesna Microsoftowa kolekcja document.all nie zostala w tescie uzyta tylko standardowa metoda document.getElementById. Aby rozwiac watpliwosci dlaczego Mozilla/NS "wywalaja blad" rozbilem instrukcje na dwie i obecnie wygladaja nastepujaco:
var t=document.getElementById('table')
try {t.rows(0).cells(0).style.color = 'red'}
nie trzeba chyba nikogo przekonywac, ze drugi wiersz winien wygladac:
try {t.rows[0].cells[0].style.color = 'red'} Mam nadzieje, ze dalsza dyskusja na ten temat jest zbyteczna. Nalezy ubolewac, ze duet IE/Opera toleruje takie bledy (do tej pory tylko IE byl pietnowany za "przymykanie oka" na niechlujstwo twórców stron int.), ale równiez i to, iz recenzent przeinaczyl fakty.
Test 5. Wbrew pozorom bardzo prosty test z paskami sprawil klopot duetowi Mozilla/NS w trybie Strict. Nie namalowaly w tym miejscu nic!!!! Moze ktos ma jakas koncepcje - ja nic nie potrafie wymyslec. Opera w trybie Trans. "odjela sobie" 0,5 pkt. za mala niedokladnosc.
Test 6. I znów musze nie zgodzic sie z recenzentem. Pisze on slusznie, zeco do reszty mam odmienne zdanie. IE uznal (moim zdaniem slusznie), ze wyjecie elementu z tabeli = tego elementu nie ma i w zwiazku z powyzszym zachowal sie konsekwentnie, jak w przypadku czwartej tabelki gdzie zastosowano metode deleteRow(2). Mozilla potraktowala temat podobnie, dostala jednak 0,5 pkt w trybie Trans., gdyz pozostawila ramki po usunietej komórce. Netscape 7.1 chyba "nie zauwazyl" position:absolute i zachowal sie, jakby bylo position:static - wiec 0 px. Niestety Opera pogubila sie calkowicie, osobiscie nie potrafie wymyslec, co próbowala zrobic ...position:absolute nakazuje .... przegladarce wyjecie wiersza z tabeli ...
Test 7. Tu przegladarki natrafily na problem, co zrobic, skoro w tabelach nie ma parametru align="cos" (deprecated w HTML 4.0). Byly dwie mozliwosci: albo role tego parametru przejmie text-align i tabelki beda rozmieszczone tak, jak teksty nad nimi (IE), badz parametr ten zostanie zignorowany i wszystkie tabelki bede domyslnie dosuniete do lewego marginesu (Mo/Ns). Osobiscie wydaje mi sie wlasciwsze rozwiazanie pierwsze, poniewaz w drugim nie ma zadnej mozliwosci pozycjonowania elementów (nie tylko tabelek) po usunieciu parametrów "deprecated". Widac to wyraznie w tescie nr 8, gdzie nie mozna Mo/Ns "zmusic", aby element div zostal wysrodkowany. Stad punktacja: IE-1pt., Mo/Ns- 0,5 pt. Opera natomiast otrzymala 0 pkt., poniewaz zachowala sie niezrozumiale. Wszystkim tabelkom ustalila align:right (taki parametr byl w stylu def. glówna tabele), natomiast zignorowala calkowicie align:left i align:center w komórkach 1 i 2 .
Test 8. Nie wymaga komentarza. Dziwi zachowanie duetu Mozilla/Netscape !!!
Test 9. Znów dziwi zachowanie duetu Mo/Ns, który pominal w zewnetrznym arkuszu stylów pierwszy element, tylko dlatego, ze arkusz zostal opatrzony naglówkiem: <style type="text/css"> </style> Przyklad taki (jako wzorcowy) jest czesto stosowany w dokumentacji W3C i nie ma zadnej wzmianki na temat, ze nie ma on zastosowania do zewnetrznych arkuszy stylów. Natomiast jedynie Opera zachowuje sie poprawnie przy notacji: <style type="text/css"></style> robiac blad, bo miedzy <style type="text/css"> a <!-- powinien byc co najmniej jeden znak rozdzielajacy (spacja, zmiana wiersza), ale byloby to "czepianie sie" i brak obiektywizmu.
Test 10. Najwiecej klopotu dostarczylo przegladarkom prawidlowe wyliczenie szerokosci elementu pozycjonowanego absolutnie (ramka zielona), który powinien byc równy poprzednim tabelkom i elementowi z ramka czerwona. Jedynie IE 5.5 w obu trybach i IE 6.0 w trybie Transitional wykonaly zadanie (1 pkt), duet Mo/Ns otrzymaly po 0,5 pkt za drobne niedokladnosci w obliczeniu wysokosci obiektu. Opera otrzymalaby 1 pkt. w trybie Trans., gdyby nie fakt, ze niewidoczna czesc elementu (ojciec ma parametr overflow:hiden) próbuje przewijac przy pomocy wlasnego pionowego scrollbara (!). Oczywiscie usuniecie atrybutu position:absolute powoduje, ze wszyscy wykonuja zadanie prawidlowo, ale wtedy nie byloby testu !!!
Możesz ten tekst potraktować, jako mój głos w dyskusji Waszego forum
i opublikować go (wraz z akt. testami). Zwłaszcza dobrze byłoby, gdyby
przeczytał go recenzent, którego opinię mi przesłałeś.
Pozdrawiam
Tomek
Ps. Jutro będę miał wyniki Safari na Mac'u.
test.zip
Szczerze mówiąc zaczyna mnie męczyć ta dyskusja, ze swej strony mógłbym sypnąć kilkudziesięcioma testami z bogatego zasobu testów Hixiego: http://www.hixie.ch/tests/ których nie przechodzi MSIE, ale czy to miałoby sens.
Mój adwersarz i tak interpretuje testy w maksymalnie korzystny dla MSIE sposób, np. standard mówi, że kolumnom można nadawać tylko cztery właściwości, inne powinny być ignorowane. Odpowiedź: no owszem, no fakt, ale przecież chyba dobrze, że MSIE coś od siebie dodaje, no i maks. notacja za ewidentne naruszenie standardu. Za to, jak Opera dziwacznie zawija wiersze, mimo, że nikt nie potrafił mi wskazać, że to jest niezgodne ze standardem, to oczywiście zero dla Opery bo narusza standard CSS2.
Dlatego w dalszej dyskusji chciałbym przyjąć ostry punkt odniesienia: standard, tzn. tylko i wyłącznie zapisy standardów CSS2 oraz XHTML 1.0 Strict. Strona testowa winna przechodzić test poprawności z użyciem walidatora zarówno html jak i CSS. Nie dopuszczam użycia notacji atrybutu style="" - z uwagi na zwięzłość przejrzystość testu, style winny być zgrupowane w jednym miejscu i za pomocą klass, bądź identyfikatorów powinny być aplikowane poszczególnym elementom.
Jeśli te warunki będą spełnione to mogę dyskutować dalej. Nie chcę się odnosić do żadnych quirks mode, które powielają tylko błędne zachowania przeglądarek.
Originally posted by quiris
Nie chcem się odnosić do żadnych quirks mode
Nie chcem, ale muszem!
Originally posted by Moose
Nie chcem, ale muszem!
Ale kwiatek...
Poprawione.
Originally posted by jaqbk
To, ze standard CSS ustala, iz jakis atrybut odnosi sie do pewnej grupy elementów, nie oznacza, iz NIE WOLNO GO STOSOWAC DO INNYCH.
Oczywiście, że przeglądarka może robić co jej się żywnie podoba. Może np. stosować do elementów typu inline właściwości wysokość i szerokość (a co tam, przecież może to być przydatne tfórcom stron). Co tam standard, przecież standard może się mylić... itp, itd.
Inna sprawa, ze nie powinno sie stosowac tzw. fanaberii M$, jesli sie chce, aby strona byla czytelna we wszystkich przegladarkach.
To po kiego czorta MSIE dostała 1pkt za tę fanaberię.
Test 2. Nieprawda jest, jakoby: Odpowiedzi zreszta dostarczyl autor recenzji dolaczajac zapis rzekomego bledu skladni:
Unknown context
Syntax error while loading (line 7)
-->
----^
W linii 7 znajduje sie koniec html-owego komentarza i to wlasnie nie spodobalo sie Operze. Zachowala sie tutaj wyjatkowo ortodoksyjnie, domagajac sie dodatkowego komentarza JS "//". Inne przegladarki potrafia rozpoznac koniec komentarza, skoro w 1 linii byl poczatek.
Co robią przeglądarki mało mnie obchodzi. Standard stwierdza [http://www.w3.org/TR/REC-html401/interact/scripts.html#h-18.3.2], że interpreter JS może dopuścić aby na początku elementu SCRIPT pojawił się znak komentarza ", bo // to komentarz dla JS (interpreter JS ignoruję tę linię).
Ale to dotyczy tylko skryptów osadzonych w kodzie html za pomocą znacznika script, zewnętrzny plik JS nie powinien zawierać nic innego niż czysty kod JS. Tu nawet Opera zachowuje się nieco liberalnie dopuszczając <!-- na początku. IMHO nie powinna tego robić, dlatego daję jej w tym momencie 0 pkt (będę rozpatrywał to w kategoriach czarne-białe), inne przeglądarki Mozilla, Safari, MSIE mają też 0pkt ale to już wiemy dlaczego.
Specyfikacja stwierdza: Another solution to the problem is to keep scripts in external documents and refer to them with the src attribute. Skrypty w zewnętrznych dokumentach to są skrypty określonego zdefiniowanego języka, a nie mieszanka skryptów i htmla.
Test 3. Zostal juz omówiony, dobrze, ze w wersji 7.30 Opery blad zostal poprawiony.
Ja nie napisałem, że błąd został poprawiony, tylko poprawiono zachowanie przeglądarki.
Originally posted by jaqbk
Test 4. Recenzent napisal:
Mozilla, rzeczywiscie wywala blad, dlatego, ze nie obsluguje kolekcji document.all Punktacja. Mozilla 1pkt; MSIE, Opera 0.5pkt (wszak dziala przy notacji takiej i takiej). Bylem szczerze zdziwiony taka argumentacja, poniewaz nieszczesna Microsoftowa kolekcja document.all nie zostala w tescie uzyta tylko standardowa metoda document.getElementById. Aby rozwiac watpliwosci dlaczego Mozilla/NS "wywalaja blad" rozbilem instrukcje na dwie i obecnie wygladaja nastepujaco:
var t=document.getElementById('table')
try {t.rows(0).cells(0).style.color = 'red'}
nie trzeba chyba nikogo przekonywac, ze drugi wiersz winien wygladac:
try {t.rows[0].cells[0].style.color = 'red'} Mam nadzieje, ze dalsza dyskusja na ten temat jest zbyteczna. Nalezy ubolewac, ze duet IE/Opera toleruje takie bledy (do tej pory tylko IE byl pietnowany za "przymykanie oka" na niechlujstwo twórców stron int.), ale równiez i to, iz recenzent przeinaczyl fakty.
Przytoczę fragment rozmowy pomiędzy mną i marcoosem:
ja: Dziwię się bo to jest getElementById(), taka kombinacja składni.
marcoos: Nie, dlaczego? To tak jak z document.getElementById(...).innerHTML, jeśli document.all i getElementById() zwracają referencję do tego samego obiektu, to powinien mieć te same metody. Tak więc, jeśli ktoś zaimplementował document.all, to naturalne, że metody z .all będą dostępne także przez getElementById inaczej takie innerHTML działałoby ci w document.all, a w getElementById - nie, co byłoby mało fajne, bo jednak innerHTML jest szybkie i wygodne
Należy ubolewać nad nieznajomością rzeczy przez piszącego test i nazywanie błędem tego, co błędem nie jest.
Proszę zobaczyć moje dwa dodatkowe testy:Test 6. I znów musze nie zgodzic sie z recenzentem. Pisze on slusznie, ze co do reszty mam odmienne zdanie. IE uznal (moim zdaniem slusznie), ze wyjecie elementu z tabeli = tego elementu nie ma i w zwiazku z powyzszym zachowal sie konsekwentnie, jak w przypadku czwartej tabelki gdzie zastosowano metode deleteRow(2).
http://quiris.klub.chip.pl/css/html_tables.html
http://quiris.klub.chip.pl/css/css_tables.html
Proszę zwrócić uwagę, że w MSIE tak naprawdę nie jest wyjmowany wiersz a komórka, a z tym to i w Operze nie ma problemu. Co oczywiście nie zmienia faktu, że Opera ma problemy z tym testem.
Z pozycjonowaniem elementów tabeli najlepiej radzą sobie Mozilla i Safari.
Autor testu zdaje się nie znać definicji właściwości width wg standardu CSS2: http://www.w3.org/TR/CSS2/visudet.html#propdef-widthOriginally posted by jaqbk
Test 10. Najwiecej klopotu dostarczylo przegladarkom prawidlowe wyliczenie szerokosci elementu pozycjonowanego absolutnie (ramka zielona), który powinien byc równy poprzednim tabelkom i elementowi z ramka czerwona. Jedynie IE 5.5 w obu trybach i IE 6.0 w trybie Transitional wykonaly zadanie (1 pkt),
Otóż: This property specifies the content width of boxes generated by block-level and replaced elements. width oznacza szerokość zawartości. Na tym: http://www.w3.org/TR/CSS2/box.html#box-dimensions rysunku można zobaczyć co to jest zawartość pudełka (content). Jeśli do zielonego pudełka dokłada się padding z lewej i z prawej stony to nie należy się dziwić, że ramka się wystaje, bo odległość o prawego do lewego obramowania to: szerokość obramowania + prawy padding + szerokość + lewy padding + szerokość obramowania. MSIE 6.0 w trybie Strict działa zgodnie ze standardem w tym zakresie dlatego wyświetla test prawidłowo (wg autora, nieznającego definicji width, nieprawidłowo)
Originally posted by jaqbk Test 9. Znów dziwi zachowanie duetu Mo/Ns, który pominal w zewnetrznym arkuszu stylów pierwszy element, tylko dlatego, ze arkusz zostal opatrzony naglówkiem: <style type="text/css"> </style> Przyklad taki (jako wzorcowy) jest czesto stosowany w dokumentacji W3C i nie ma zadnej wzmianki na temat, ze nie ma on zastosowania do zewnetrznych arkuszy stylów.
I bardzo dobrze, że nie reaguje. Zewnętrzne pliki ze stylami powinny zawierać jedynie czysty definicje stylów. Takich podstawowych rzeczy uczą w szkółkach http://www.w3schools.com/css/css_howto.asp:
An external style sheet can be written in any text editor. The file should not contain any html tags.
CSS nie jest jednak językiem programowania, gdzie błąd składni powoduje błąd wykonania całego programu. Wadliwa składnia CSS jest po prostu ignorowana. Widać, że Mozilla ma inny algorytm parsowania pliku CSS, niż Opera, czy MSIE, które radzą sobie z tym problemem. Właśnie dlatego przestrzegają, żeby pliki CSS zawierały tylko definicje styli, aby uniknąć przykrych niespodzianek w postaci niekonsekwencji zachowań różnych przeglądarek.
Z ubolewaniem muszę stwierdzić, że Opera błędnie aplikuje definicję: table {text-align: center;} dla elementów blokowych.Originally posted by jaqbk
Test 7. Tu przegladarki natrafily na problem, co zrobic, skoro w tabelach nie ma parametru align="cos" (deprecated w HTML 4.0). Byly dwie mozliwosci: albo role tego parametru przejmie text-align i tabelki beda rozmieszczone tak, jak teksty nad nimi (IE), badz parametr ten zostanie zignorowany i wszystkie tabelki bede domyslnie dosuniete do lewego marginesu (Mo/Ns). Osobiscie wydaje mi sie wlasciwsze rozwiazanie pierwsze, poniewaz w drugim nie ma zadnej mozliwosci pozycjonowania elementów (nie tylko tabelek) po usunieciu parametrów "deprecated". Widac to wyraznie w tescie nr 8, gdzie nie mozna Mo/Ns "zmusic", aby element div zostal wysrodkowany. Stad punktacja: IE-1pt., Mo/Ns- 0,5 pt. Opera natomiast otrzymala 0 pkt., poniewaz zachowala sie niezrozumiale. Wszystkim tabelkom ustalila align:right (taki parametr byl w stylu def. glówna tabele), natomiast zignorowala calkowicie align:left i align:center w komórkach 1 i 2 .
Popatrzmy co mówi standard [http://www.w3.org/TR/CSS2/text.html#propdef-text-align]:
This property describes how inline content of a block is aligned. Proszę zwrócić uwagę na inline content oznacza elementy wewnętrzne, czyli na pewno nie są to <div>!
Wyrównanie elementów blokowych możemy regulować za pomocą margin-left oraz margin-right (zgodnie ze standardem CSS):
1) centrowanie: div {margin-left:auto; margin-right:auto}
2) do lewej: div {margin-left:0; margin-right:auto}
3) do prawej: div {margin-left:auto; margin-right:0}
I to właśnie za pomocą tej konstrukcji (zgodnej ze standardem) zmuszamy Mozillę do określonego zachowania. Natomiast jestem zmuszony zgłość bugreporta w stosunku do zachowania Opery.
Test 5. Wbrew pozorom bardzo prosty test z paskami sprawil klopot duetowi Mozilla/NS w trybie Strict. Nie namalowaly w tym miejscu nic!!!! Moze ktos ma jakas koncepcje - ja nic nie potrafie wymyslec. Opera w trybie Trans. "odjela sobie" 0,5 pkt. za mala niedokladnosc.
Po usunięciu cellpadding="0" w Mozilli też jest w porządku.
Ponieważ jest już O7.50, odniosę się do ostatniego testu, pod tą przeglądarką.
Nalezy zauważyć, że Opera zaczęła emulować niezgodne ze standardami działanie w teście drugim. W O7.50 wszystkie 3 komórki maję tę samą zawartość.
Zgodnie z zapowiedziami nie ma już dziwnego zawijania wierszy w teście trzecim.
W teście szóstym również występuje znaczna poprawa. Po odświeżeniu widoku komóki zaczynają się poprawnie wyświetlać.
Ja od siebie moge tylko wtrącić że postulowane przeze mnie zmiany (quiris, to twoja sprawka? ) w sposobie renderowania tabelek, które pokazywałem na początku wątku, zostały uwzględnione w 7.5.
Teraz wyglądają one dokładnie tak samo jak w IE/Moz.
Jako kontratest w mojej dyskusji z Szanownym Piewcą Nieomylności MSIE podam: http://my.opera.com/forums/showthread.php?s=&postid=405895#post405895
Wygrzebałem ten wątek, bo natrafiłem na ciekawą wypowiedź Iana Hiksona wyszydzającą znakomite wsparcie standardów w MSIE:
Buzz: Hallucinogenic drugs?