Nie tylko o przeglądarkach...

U mnie menu troszke rozjechane ale bialej plamy brak.

Sprawdzałem przeglądarkę Camino i tam białej plamy nie ma. Natomiast rozjechane menu jest.

Nie mam natomiast czasu dochodzić, co skaszaniliście w samym menu. ;-)

A może coś zostało skaszanione w samym Firefoksie? Nie dopuszczasz takiej możliwości?

Może jestem jakiś dziwny, ale pod moim FF ta strona wygląda dokładnie tak samo, jak pod Operą.

Poproszę o podanie wersji systemu, wersji przeglądarki, no i zrzut ekranu przedałby się

Teraz pytanie jaka przeglądarka zachowuje się tu poprawnie w stosunku do kodu strony...

Uhm. Bardzo dobre pytanie.

"Co wyczynia Firefox?" - to jest neutralne zdanie swiadczace o tym, ze dopuszczasz mozliwosc, ze zle dziala tu Opera? Heh... To jak tam z ta drzazga w oku?

Akurat tak się złożyło, że we wszystkich testowanych przeglądarkach, tylko w Gecko jest inaczej, więc to mnie uprawniło do zatytułowania postu tak, jak właśnie jest zatytułowany.

Pierwsze przypuszczenia (jak ja uwielbiam WebDeveloper extension - czas jaki zajelo znalezienie tego, ponizej minuty):
ul#menu li {list-style-position:inside;}
ul#menu a, ul#navmenu a { display: block; }

No ciepło, ciepło. Jesteś o krok od rozwiązania zagadki. Przyczynę znalazłeś bezbłędnie

Nie pokusze sie jeszcze o wniosek czyja to wina, ale ustawienie tych dwoch wartosci powoduje, ze blokowy anchor przeskakuje do nowego wiersza jesli element listy jest wewnatrz jej pol.

No szkoda, że nie pokusisz się. Mógłbyś zdobyć laur zwycięzcy

Na bugzilli mamy mnostwo bledow tego typu w ktorych na koncu okazywalo sie, ze to wyzej wymienione zgodnie popelniaja ten sam blad. Chocby dlatego, ze zarowno panowie z Opery jak i z KHTML-a podczas swoich prac (i mozesz to sprawdzic w bugzilli KDE) wybierali zachowanie zgodne z IE, a nie ze specyfikacja...

Na tej samej bugzilli jest więcej błędów, które wskazują na odwrotne zachowanie. Wbrew pozorom, czy też przeróżnym sugestiom, jakie miałem nieprzyjemność ostatnio słyszeć developerzy Gecko nie mają monopolu na prawdę. I dobrze.

Na tyle na ile ja rozumiem specyfikację CSS2:

list-style-position: inside; powoduje wygenerowanie wewnątrz elementu listy elementu inline dla markera.
http://www.w3.org/TR/CSS2/generate.html#propdef-list-style-position

Jeżeli teraz A będzie display: block; to ten element inline (marker) zostanie zamknięty w element blokowy zgodnie z http://www.w3.org/TR/CSS2/visuren.html#anonymous-block-level

Czyli Fx wyświetla to poprawnie. Przy czym jest to moja - niekoniecznie poprawna - interpretacja tego

Bardzo dobre odwołanie do specyfikacji Choć wnioski ostateczne nie są do końca poprawne.

Czy jednak inaczej?...

A co powiesz na:

Most block-level elements in CSS generate one principal block box. In this section, we discuss two CSS mechanisms that cause an element to generate two boxes: one principal block box (for the element's content) and one separate marker box (for decoration such as a bullet, image, or number). The marker box may be positioned inside or outside the principal box. Unlike :before and :after content, the marker box does not affect the position of the principal box, whatever the positioning scheme.

[ http://www.w3.org/TR/CSS2/generate.html#q11 ]

Co do mnie zas - zalozylem, ze skoro pytasz o rozwiazanie, to go nie znasz. Skoro zas go nie znasz, to stawianie zarzutow jest co najmniej niewlasciwe. Patrzac jednak na Twoja reakcje wnioskuje, ze odpowiedz znales/znalazles, ale dla samej radosci publicznej dyskusji ciagniesz to dalej. Gratuluje.

Nie zamierzam wdawać się po raz kolejny w czczą pyskówkę. W chwili pisania postu odpowiedzi nie znałem. To, że napisałem post nie oznacza, że siedziałem z założonymi rękami. Sam szukałem rozwiązania. Znalazłem go wcześniej, jednak nic nie pisałem na ten temat, bo po prostu ciekaw byłem opinii. Zacytowany przeze mnie fragment specyfikacji, który bardzo dobrze wyjaśnia, że zachowanie Gecko jest błędne przesłał mi pablO. Jeśli on nie dopisze nowych informacji do tego błędu, to ja to uczynię przy najbliższej okazji.

W sumie dobrze, że pojawił się ten post. Jest idealną odpowiedzią do stwierdzenie jakie padło w jednym z komentarzy:

Opera ma swoje sposoby, „lepsze i dokładniejsze” rozumowanie niektórych standardów i to się odbija na stronach.

Jak to się mówi? Przyganiał kocioł...? I jeszcze raz powtórzę: punkt widzenia zależy od punktu siedzenia.

Ale gdy mamy element blokowy jako treść tego (li), to:
- pozycjonowanie (li) się nie zmieni - li jest jako principal box,
- ale sam (marker) zgodnie z poprzednio wspomnianą regułą będzie jako "dislay: block" (...wrapping any inline boxes in an anonymous block box...),
- czyli chyba jednak gecko to renderuje poprawnie...

Ale w innym fragmencie specyfikacji znowu mamy:

inside - The marker box is the first inline box in the principal block box, after which the element's content flows.

Czyli zawartość elementu powinna opływać markera, a tego nie czyni. Mowa jest również bloku liniowym. [ http://www.w3.org/TR/CSS2/generate.html#propdef-list-style-position ]

A najciekawsze jest to, że w drafcie CSS2.1 punkt 12.6 jeszcze nie występuje, więc jak to będzie w przyszłości nie wiadomo...

W CSS 2.1 nie ma bo najpewniej ten punkt wyleciał z tej specyfikacji. Dlatego odnosząc się do CSS 2.1 musimy przede wszystkim analizować: http://www.w3.org/TR/CSS21/generate.html#propdef-list-style-position

inside
The marker box is the first inline box in the principal block box, after which the element's content flows. CSS 2.1 does not specify the precise location of the marker box.

A tu znowu mamy, że specyfikacja nie określa precyzyjnie położenia markera Co jest moim zdaniem totalnym pogłębieniem niejasności.

Czy powyzszy cytat to ze mnie? Nie przypominam sobie takiej wypowiedzi...

Nie. To nie ty to powiedziałeś.

quiris: czy bazujac na tej analizie mozna rozumowac, ze zachowanie Gecko jest zgodne (albo, nie jest niezgodne) z CSS 2.1? (przyjmujac jednoczesnie, ze faktycznie jest niezgodne z CSS 2.0)

W świetle tego co jest napisane w CSS 2.1 jednoznacznego rozstrzygnięcia wskazać nie można. A skoro nie można orzec, trzeba bazować na tym jak to rozwiązali inni i który rodzaj implementacji jest hmm... użyteczny. Znakomita większość (jeśli nie wszystkie) implementacji wyświetla marker inaczej niż Gecko. Dodatkowo sposób wyświetlania Gecko co tu dużo mówić psuje listy. Jakoś nie mogę wyobrazić sobie zastosowania praktycznego sposobu wyświetlania Gecko. Taka jest moja opinia. Mniej więcej podobny tok rozumowania przyjęli developerzy wymieniając uwagi na ten temat we wspomnianym błędzie.

Co tu dużo mówić, jedno jest pewne - zachowanie Gecko jest inne niż w pozostałych przeglądarkach, a potrzeba zachowania interoperacyjności w standardzie CSS 2.1 - to co próbuje uzyskać grupa robocza CSS wymaga, żeby było spójne.

Podobne zachownie. Opera do wersji 8.5 dla elementu body ustawiała domyślnie 8px dopełnienie, zamiast powszechnie ustawianego w innych przeglądarkach marginesu 8px. Podstawą takiego zachowania był zapis: http://www.w3.org/TR/CSS2/sample.html Oczywiście nie można było powiedzieć, że pozostałe przeglądarki nieprawidłowo działają w tym względzie, bo przytoczony artykuł jest informacyjny, a nie normatywny. Czyli znowu, na dwoje babka wróżyła. Ja jednak z ulgą i radością powitałem zmianę tego zachowania w Operze 9 właśnie w imię zachowania interoperacyjności z innymi przeglądarkami.

na Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 wszystko działa elegancko, nic sie nie rozjezdza.

Neochan: Błędu już dawno nie ma na tej stronie. Zmieniłem po prostu style, tak żeby działało to sensownie w Fireofoksie. Poczytaj: http://my.opera.com/quiris/blog/show.dml/286303