[look997]

#css #frontend #webdev #html #firefox #chrome
Użyłem display:flex i position:sticky bo pozycjonowania elementu do prawej krawędzi widoku.

W Chrome wszystko ok.
W Firefoksie nie działa, zachowuje się jak position:absolute - nie zajmuje przestrzeni w treści.

Sposobem jest dodanie elementu ZA prawym elementem, z szerokością 0.1px - wtedy prawy element działa jak sticky, i jednocześnie ten element hackujący nie zajmuje miejsca (również w content.scrollWidth itp. miejscach).

Żywy przykład (ten sam na obrazku): https://dopog.csb.app/

Pytanie:
* Czy da się to naprawić bez tego hack-u?
* Czy jest to błąd Firefoksa, który jest do poprawienia, czy Mozilla chce, żeby tak to działało?
* Dodatkowo: Próbowałem szerokość elementu hackującego na 00833333237097px i calc(1px / 120.00001144409178) - w zaokrągleniu najmniejsze możliwe działające szerokości, przy mniejszych element się zeruje i hack przestaje działać. Z czego te wartości wynikają? Ze specyfiki języka w którym CSS jest obliczany w Firefoksie? Ile ta liczba dokładnie wynosi?

[czlowiekboruta]

@look997: To mówisz że w Chrome działa? ( ͡° ͜ʖ ͡°) U mnie akurat na macu

[look997]

@czlowiekboruta: A nie możesz przesunąć w prawo?

[look997]

@czlowiekboruta: Dałem auto przewijanie do prawej, żeby nie trzeba ręcznie przewijać żywego przykładu.

[czlowiekboruta]

@look997: A, ok, głupie scrollbary xD Mój błąd, sticky jednak powinno działać jak static, nie jak absolute, czyli faktycznie coś nie teges. Możliwe że to efekt tego błędu:
https://bugzilla.mozilla.org/show_bug.cgi?id=1488080

[look997]

@look997: Napisałem że ten hackujący element nie zajmuje miejsca, ale właściwie to nieprawa - jak ustawić 5 takich elementów 0.1px, to zachowuje się to tak, jakby zajmowały one razem 1px i testowa czerwona kreska jest widoczna oraz w content.scrollWidth jest wartość o 1 większa.

Dlatego też kombinowałem z niższymi szerokościami, żeby móc zmieścić więcej takich elementów hackujących. Przy szerokości calc(1px / 120) czerwona kreska jest widoczna dopiero przy 45

[czlowiekboruta]

@look997: A odpowiadając na pytanie to mozilla i inne przeglądarki zwykle dążą do tego, żeby być zgodnymi ze standardami. Czasem standard może być niejasny w niektórych kwestiach albo interpretacja standardu bywa powodem, więc zwykle są to po prostu bugi. Szczególnie przy świeżych rzeczach typu wspomniane sticky (sam flex też jest stosunkowo świeży). Chociaż bywają "błędy" irytujące i zrobione z premedytacją, np. interpretacja "100vh" na iOS, który to ignoruje dolny pasek

[czlowiekboruta]

@look997: Apropo minimalnej szerokości w pikselach itp. - to pewnie wynika z arytmetyki liczb zmiennoprzecinkowych w silniku danej przeglądarki. Nie przykuwałbym wagi do dokładnej wartości bo nie ma to specjalnego znaczenia. Jak znalazłeś obejście problemu to je zastosuj i nie trać dalej czasu ( ͡° ͜ʖ ͡°)

[look997]

@czlowiekboruta: Wydaje mi się, że jak sticky był dopiero wprowadzany, to bawiłem się tym i też były te dziwactwa z prawą krawędzią. Wtedy olałem bo tylko się bawiłem, ale teraz to mi może potrzebne.

Mam wątpliwości, czy to nie zostanie poprawione i nie zacznie inaczej działać.
Raczej jeśli już, to będzie tak jak w Chrome, czyli niegroźnie ale nadal nie wiem czy warto taki hack używać.

Jakby szło bardziej oficjalnym sposobem, to chętnie

[look997]

@czlowiekboruta: Przykład dziwnego działania tego buga:
Gdy ustawić position:static, przewinąć do prawej krawędzi, zmienić w devTools na sticky - prawidłowo zachowuje szerokość, nadal zajmuje przestrzeń w widoku.
Jak w tym momencie przewinąć w lewo, to traci szerokość, stopniowo przestaje zajmować przestrzeń aż dobija do zera zajmowanej przestrzeni - wtedy nie da się wrócić, przewinięcie do prawej krawędzi pokazuje, że prawy element znów działa jak position:absolute.