Ostatnio eksperymentuje z nowym (nowym dla mnie) podejściem do elementów graficznych layoutu strony.
Obrazki przechowuje w plikach .css w stylach background: url(data:image/png;base64,iVBORw0KGgo......)
zakodowane w base64..

Plusy:
- łatwiejsze grupowanie, znika potrzeba tworzenia map obrazków, nie pamiętam jak ta technika się nazwała, chodzi o to, że kiedy mamy wiele obrazków o małej wielkości, to celem unikniecia wielu połączeń z serweram, tworzymy jeden obrazek zawierający wszystkie mniejsze jeden obok drugiego, a potem przy pomocy stylu CSS background-position osadzamy je w dokumecie. Trzymając je w plikach .css ten problem znika
- omijamy algorytmy kompresujące na serwerach proxy, może to problem dotyczący niewielkiej ilości odwiedzających, ale z doświadczenia wiem, że np. sieci komórkowe obligatoryjnie kompresują wszystkie jpegi, przez co strona wygląda okropnie. Ten problem z pewnością będzie narastał w przyszłości.
- łatwiejsze zarządzenie cachowaniem HTTP,
- mniejsza ilość połączeń do serwera - oszczędność transferu
- szybsze ładowanie strony, mniej elementów do pobrania czy sprawdzenia aktualności cachu..

Minusy:
- 3-4% narzut wielkości (base64) - częściowo rekompensowany zmniejszoną ilością połączeń
- rozwiązanie mało konwencjonalne, przez co prawdopodobnie, gdzieś tam w świecie, jest platforma która tego nie wspiera (może jakieś urządzenie mobilne?)
- i jeszcze raz technika mało konwencjonalna, więc potencjalnie gorzej zoptymalizowana w przeglądarkach, przez co wolniejsza

Warto nie przekraczać granic absurdu, nie ma sensu galerii zdjęć ładować do plików .css
Jednak moim zdaniem jest to jest dobre miejsce dla wszystkich elementów graficznych podstawowego layoutu strony.


A jakie jest Wasze zdanie?

I tak i nie. Ogólnie, to robi się wtedy trochę bałaganu w kodzie, a co za problem pobawić się z 1 plikiem całego layoutu i ustawić background position? Zresztą ja czasami jak siędzę na modemie gsm, to wyłączam wczytywanie obrazków, ale style zostawiam. W twoim wypadku niepotrzebnie pobiorę obrazek.

Nie wiem skąd wziąłeś 3-4% ale to jest 1/3 czyli 33% około. Nie każdy serwer obsługuje kompresję gzip.


- Dalej, IE8 ogranicza wielkość tego ciągu do 32kb... :[
- Słabe cachowanie elementów.

Wg mnie nie, wystarczy napisać parser który zamieni uri w backgrund-image na content w base64 i odwrotnie, taka prekompilacja Sekunda roboty i żaden bałagan.


Nie.
Najlepszy stosunek wielkości do jakości uzyskuje się w różnych formatach (PNG, GIF, JPEG) w zależności od własności danej grafiki.
Nie wspomne już o półprzeźroczystych PNG.
Takie rozwiązanie się nie nadaje kompletnie i musisz tutaj przyznać się do nie przemyślenia do końca tego co napisałeś..


Z punktu widzenia usera -> Fail
Z punktu widzenia developera -> WIN :-]


Sam sobie odpowiedziałeś, więc przemilcze :-]


Dobrze wiedzieć, mnie to nie odstarsza.
Mam tylko nadzieje, ze inne przeglądarki nie ograniczają tego jeszcze bardziej..
Na upartego można złożyć z kilku obrazków tworząc wzorcowy pomnik ludzkiego szaleństwa :-]
Tak czy inaczej, to jest bez wątpienia największy minus.


Co przez to rozumiesz?
Wg mnie cachowanie jest bardzo dobre.

To przekreśla całość, bo developer nie może być wygrany skoro strona na którą wchodzi użytkownik źle się wyświetli w jakimś tam przypadku.

Zmiana jednego stylu, np dodanie podkreślenia powoduje że cały ten plik musi pobrać od nowa użytkownik.

To Twoje zdanie, wg. mnie jest odwrotnie.
To jedna z największych zalet oamawianej techniki.


A kto powiedzial że musisz wszystko trzymać w jednym pliku .css ?

Więc jaki jest wtedy tego sens?

Nie rozumiem pytania.
Sens nie ulega zmianie.
Zamiast jednego pliku, trzymasz to w kilku, różnica będzie niewielka.

Podstawy protokołu TCP/IP się kłaniają. Nie każdy serwer ma odpowiednio ustawiony Keep-Alive, a pamiętaj, że każde nowe połączenie TCP, to zasoby CPU + łącze. Sama negocjacja potrafi pożreć więcej czasu niż faktyczny przesył zbioru.

Nie rozumiem co ma keep-alive do ilości plików stylów.


Dokładnie! Taki jest właśnie cel tej całej zabawy, minimalizacja tych połączeń.
Zamiast wielu drobnych elementów graficznych, jeden - lub jeśli trzeba więcej - plików .css.
Dziękuje za czytanie ze zrozumieniem... (ironia)

Ma. Bo jeśli Keep-Alive jest odpowiednio skonfigurowane, to wszystko poleci jednym połączeniem.

Nadal nie rozumiem, co to ma do rzeczy.
Piszesz nie na temat.

Ta technika nazywa się spritem i jest o wiele wygodniejsza i łatwiejsza w implementacji niż twój sposób ...

CSS Spirites, i jest aktualnie na modzie, redukuje liczbę połączeń oraz nie trzeba pisać dodatkowych skryptów które nam parsują plik css żeby zmienić url na data:base64.. Wyżej wymieniony sposób nie przemawia do mnie, jak i pewnie do 90% developerów. Widziałem niekiedy w js jak ktoś wrzucał w taki sposób obrazki i odlanezienie ewentualna korekta obrazka osoby która nie napisała dany arkusz styli, jest masakrą, równie dobrze możemy zacząć programować malbolge, i szczerze współczuje każdemu kto będzie próbował w ten sposób pisać style..

Właśnie, największym problemem będzie aktualizacja sprite'a. A co, jeśli zechcesz dodać jeden obrazek do tego? Więcej problemów niż korzyści.

Piszesz bzdury, zamiana URL na dane binarne zakodowane w base64 jest o galaktykę prostrza niż tworzenie spritów. Dosłownie kilku linijkowy skrypt w PHP wystarczy.
Sprity się nie nadają ze względu na różnorodność formatów i wymiarów obrazków. Nie da się ich efektywnie kompresować
Nie przemawia? Bardzo dobrze, przecież wszyscy na raz nie mogą być innowacyjni

Jak narazie jedyna rzecz ktróra mnie zmartwiła, to 32KB limit wielkości grafiki - cholerny Internet Explorer

Jaka różnorodność formatów? Przecież na chwilę obecną wykorzystuje się praktycznie wyłącznie PNG. Co więcej da się to bardzo dobrze skompresować - przecież możesz sobie stworzyć kilka takich map w których znajdą się odpowiednie obrazy. Dzięki temu z jednej uda Ci się pozbyć kanału alpha, z drugiej jakiegoś tam zakresu barw itd. - wątpię by udało Ci się uzyskać lepszy stopień kompresji.
Co do łatwości edycji... CSS Sprites używa się raczej tam gdzie wydajność ma kluczowe znaczenie co z definicji oznacza, że nie może to być zbyt wygodne.

Co więcej:
- brak możliwości jakiegokolwiek indywidualnego zarządzania cachem - jest się skazanym na ustawienia dla arkusza - to może być w pewnych sytuacjach nieco problematyczne,
- brak cache'owania przez pośredniczące serwery - niestety samemu czasami muszę włączyć sobie Operę Turbo by móc w miarę humanitarnie korzystać z Internetu i bardzo irytowałby mnie jeżeli nie mógłbym z tego skorzystać.

JPEG, PNG, PNG-semi-transparent, GIF


A JPEG?


Nie da się, a już na pewno nie da się tego zrobić BARDZO dobrze.


Tak, pod warunkiem ze każdy składowy obrazek nie będzie miał więcej kolorów niż inny oraz będzie miał taką samą szerokość (lub w ostateczności wyskości, tyle że wtedy modyfikacja spritu to koszmar). W praktyce bardzo mocno ogranicza to sytuacjie w którym można efektywnie wykorzystać tę technikę.


Możesz dowolnie zarządzać cachem zarówno przez htaccess jak i nagłówki HTTP np. wygenerowane przez skrypt php.


Od kiedy to proxy nie cachują CSS? Co za bzdury wygadujesz??

1. O ile GIF-ów się jeszcze używa o tyle JPEG-ki do tworzenia interfejsu? To chyba jakieś nieporozumienie. A to właśnie interfejsy się robi w CSS-ie.
2. Czemu niby jeden duży obraz, zawierający w sobie jedynie powiedzmy tylko odcienie szarości nie miałby się dać ładnie skompresować?
3. Nie widzę też powodu dla którego poszczególne obrazy w takiej mapie miałby mieć takie same wymiary - nie jest to konieczne do utworzenia takiej mapy. Oczywiście stała szerokość i wysokość nieco uprościłaby używanie jej. Zresztą zawsze można sobie taką mapę podzielić na siatkę o stałej szerokości - puste białe, prostokątne przestrzenie bardzo ładnie się kompresują więc nie będzie to problemem.
4. Masz rację co do tego, że takie mapy edytuje się niezbyt przyjemnie, ale taka jest ich cena. Cena za to, że pozbywamy się całej masy niepotrzebnych informacji (nagłówków z formatu PNG czy innego) które w każdej innej technice (włącznie z zapisywaniem obrazów w arkuszu) muszą być powielone dla każdego pliku.
5.

[CSS] pobierz, plaintext 
body {
  background-image: url(...);
}
 
#sth {
  background-image: url(...);
}
[CSS] pobierz, plaintext 

Jakim sposobem chciałbyś ustawić osobny nagłówek dla tła z body i #sth?
6. Co do tych proxy źle się wyraziłem. Oczywiście arkusze CSS zostaną poddane kompresji, ale obrazy w nich zawarte nie będą mogły być poddane kompresji stratnej - a to właśnie ona daje największego kopa.

Tak, JPEGi do interfejsów.


Nie rozumiem pytania.


Nie ma to jak puste białe przestrzenie....


Nie rozumiem pytania.


Ale kiedy ja nie chce żeby grafika mojego layoutu była kompresowana. Jako developer chce żeby moja strona wyglądała zawsze tak samo. Zysk na "zniszczeniu" grafiki przez wątpliwej jakości algorytm kopresujący nie będzie "kopem", przeciwnie, pracą na marne, w rezultacie jedna różnica to popsuty wygląd strony.

Wybacz ale jeżeli najpierw rzucasz jakieś hasła, a potem przy naszym dopytywaniu się czy ich negowaniu piszesz, że nie rozumiesz czegoś, albo zarzucasz że ktoś pisze nie na temat (patrz posty @erix). Nie rozumiesz chyba na czym polega kompresja stratna i co niesie ona ze sobą. W dodatku jeszcze nigdzie nie podałeś żadnego uargumentowania, testów czy czegokolwiek konkretnego przy swoich opiniach.

Odnoszę wrażenie że czego by się tu nie podało i tak będziesz na upartego wszystko negował - nawet nie rozumiejąc co się do Ciebie pisze.

wNogachSpisz, nie rozumiem ciebie. Chcesz coś przedyskutować, ale od razu zakładasz, że to TY masz rację i atakujesz każdego, kto ma odmienne zdanie. Albo się ogarnij, albo dyskutuj sam ze ścianą, to przynajmniej nikt nie przebije twojej argumentacji.

Odnośnie problemów z generowaniem CSS Sprites : Generator, jest jeszcze wiele innych generatorów na necie.

Co do ogólnie pomysłu też raczej wolę CSS-Sprites, niż pakować źródło obrazka do CSS'a.

Zapomniałeś jeszcze o bmp i kilku innych, które obsługują przeglądarki (jak choćby animowany png). Ale mam wrażenie, że "nie rozumiem pytania" dla wielu osób świadczy nie o tym, że tego nie rozumiesz, ale że nie chcesz zrozumieć. Gdyby było inaczej samodzielnie byś potrafił podejść do problemu i stwierdzenia danej osoby. Inna sprawa, że w wielu przypadkach z gifa można na rzecz png zrezygnować i jest on mniejszy. No ale do tego trzeba nieco wiedzieć o optymalizacji grafiki, której to wiedzy najprawdopodobniej Ci nieco brakuje. Dlatego ostatecznie do wyboru masz tylko png, jpg i czasem gif dla animacji oraz kwestia zastanowienia co będzie w danej sytuacji lepszym rozwiązaniem.

Przykładem tego jest poprawianie czegoś, co w efekcie i tak wychodzi na to samo lub gorsze w efekcie. Z jednej strony postulujesz swoje rozwiązanie jako mające redukować liczbę połączeń do serwisu, a już kilka postów gdy wytyka Ci się wady rozwiązania piszesz, że uniknąć tego można... zwiększając liczbę odwołań do serwera poprzez podział na kilka plików css. Tak. Super rozwiązanie, które prowadzi do punktu wyjścia Tyle że zamiast iluś obrazków masz ileś plików css z zakodowanymi danymi jako base64. Pewne dane choćby nie wiem co robić są już niezwykle trudne do kompresji i zużywanie pamięci lub czasu procesora na próbę tego jest zwyczajną głupotą. Dlatego kompresji poddaje się jedynie pliki tekstowe, ale już grafikę nie. I dla testów weź sobie plik jpg zobacz ile ma, a potem zrób z niego base64 i spróbuj gzipować (bo tak zrobi serwis przy próbie wysyłki css) oraz porównaj rozmiary, a zobaczysz bezsens swojego rozwiązania. Każdy czytający ten temat od początku dojdzie do tego co właśnie napisałem i stwierdzi, że sam się pogubiłeś w tym co piszesz już. Użycie sprite'ów jest znacznie wygodniejsze, a to co Ty proponujesz (base64) używane jest jedynie w przypadku niewielkich grafik, ale dla czegoś co ma być już zastępstwem dla sprite'ów jest po prostu marnotrastwem łącza i mocy serwera. Zamiast bowiem zaserwować od razu dane jako sprite i właściwy css, które to mogą iść jako osobne połączenia niezależnie, walisz kilka plików CSS w najgorszym wypadku, a CSS są przetwarzane kaskadowo i na serwerze jeszcze będą gzipowane a po stronie usera dekompresowane, przetwarzane i dopiero wyświetlane. Nie tylko masz gorsze parametry od zrobionego z głową sprite'a, ale jeszcze serwer i klienta zmuszasz do dodatkowej pracy. Świetne rozwiązanie - nie ma co, gratuluję

Od tego co piszesz (redukcja liczby połączeń) są właśnie sprite'y. To user decyduje czy chce wyświetlać grafikę i ściągać cokolwiek. Ty go chcesz uszczęśliwiać na siłę. Pakujesz mu obrazki poprzez CSS, choć wyraźnie on chce je zablokować. Kosztem przykładowo sprite'a z plikami, każesz mu pobierać znacznie większe niż normalnie pliki CSS. I tutaj kompresja niewiele zmieni. Wcale nie rozumiesz algorytmów kompresji i to jest luka w Twoim rozumowaniu. Sprite'y mają w zasadzie jedno ograniczenie poważne - nie mogą zawierać animacji. Ale widziałem już przykłady, że poprzez odpowiednie zabawy z nimi i JS można zasymulować ją. Ja wolę nie wiedzieć ile miałby css z animowanymi gifami przejechanymi base64, który musiałby user pobierać czy chce czy nie.

Konole... Jaki problem z aktualizacją sprite'a? Sensownie przemyślany sprite podczas aktualizacji będzie wymagał jedynie niewielkiej modyfikacji grafiki i dodania jej parametrów do css, bez ruszania czegokolwiek w starych danych. Nie mówię o sytuacjach nawet gdy zmieniasz layout i cała zabawa to... podmiana linku do innego sprite'a, bez ruszania pozostałej części css (co nieraz się praktykuje). Ale do tego faktycznie trzeba rozumieć jak powstają sprite'y. Gdy to załapiesz, obserwując choćby kod wynikowy generatorów, to samodzielne tworzenie do nich css staje się banalne. Summa sumarum nawet utworzenie css do pliku z kilkudziesięcioma małymi elementami będzie mniej obciążające i zajmie mniej zasobów niż Twoje rozwiązanie, a dodatkowo będzie nieco elastyczniejsze przy aktualizacjach. Wystarczy trzymać się tylko kilku zasad prostych

A o artefaktach jpeg słyszał i wie dlaczego ich stosowanie jest czasem strzałem w stopę? Aż mi się wspomniała jedna graficzka (całkiem inteligentna kobieta), która podesłała mi puzzle pocięte i rozrzucone na białym tle... ale skompresowane do pliku jpg, co jest w takiej sytuacji głupotą, bo artefakty kompresji sprawiły, że nie mogłem tych puzzli ułożyć bez problemów.

I tutaj kłaniają się znajomości grafiki oraz algorytmów kompresji. Kto je nieco ogarnia zredukuje parę rzeczy w grafice i tym samym poprawić może znacząco współczynnik kompresji przy niezauważalnej utracie jakości lub nawet bez utraty choćby bita danych. To co uważasz za świetne rozwiązanie w porównaniu z użyta z głową optymalizacją grafiki nawet nie będzie mieć porównania.

...których wielkość nawet tysięcy pikseli liczona jest w bajtach, a wielkość i tak uzupełniana jest do wielokrotności minimalnej jednostki alokacji dysku, czyli zazwyczaj krotności od 512B do nawet 32(!) kB. Tak, argument po prostu kładący na łopatki

Dlatego jeśli już piszesz o jakimś rozwiązaniu to posłuchaj także zdania osób, które oprócz stosowania rozwiązań jakie opisujesz znają się także dobrze na: protokole tcp/ip, algorytmach kompresji, obróbce grafiki w stopniu bardziej zaawansowanym oraz wielu mechanizmów, o których zwyczajny webmaster zwyczajnie nie wie, bo nie ma w tej dziedzinie wiedzy nie tylko teoretycznej, ale i praktycznej. A są tutaj tacy, ale ich spojrzenie na problem i wytykane uchybienia bagatelizujesz, "nie rozumiesz pytań" lub stwierdzasz, że "nie mają związku z tematem"

Sęk w tym, że współcześnie stosowane formaty kompresji obrazów wykrywają jednolite przestrzenie albo się powtarzające. Również i JPEG, na podstawie predefiniowanych bloków 8x8px dobiera odpowiednie "kafelki", które kodują poszczególne elementy obrazu. Te puste białe przestrzenie zajmą niewiele miejsca. To nie jest jak w BMP, że każdy piksel musi być zakodowany dokładnie trzema bajtami. Format definiuje obszar "300x300 pikseli jest dokładnie białe i nic więcej". Nawet tak zapisane zdanie zajmuje mniej niż 90000 bajtów, nie?


Zasada jest prosta, od paru lat - JPEG tylko i wyłącznie do zdjęć. Do 99.99999999999999% innych elementów nadaje się idealnie PNG, który - przy wykorzystaniu odpowiednich optymalizatorów - pozwala zejść dość nisko z wagą obrazków. GIF się już chyba nie stosuje, za skąpy. No chyba że chodzi o animacje, to co innego.


Hmm, dlaczego musi być powielone? Ostatnio obiło mi się narzędzie do budowania sprite'ów oparte na algorytmach sztucznej inteligencji. Jeśli mnie zakładki nie mylą, to jest to: http://spritegen.website-performance.org/ Mit obalony.


Ok, słuchasz muzyki z mp3, czy z FLAC? 90%, że nie zauważyłbyś różnicy między jednym a drugim, chyba że masz naprawdę wrażliwe ucho i dobry sprzęt. Tak samo z obrazami - bez kilkukrotnego powiększenia nie dostrzeżesz różnicy między dobrze zoptymalizowanym JPEG a BMP. Zmysły ludzkie mają to do siebie, że można je oszukać, przede wszystkim przez psychikę. A myślisz, że dlaczego są obrazki statyczne, które sprawiają wrażenie się poruszających? Wykorzystują właśnie to zjawisko.

Jeszcze potrzebujesz argumentów?

Chyba mnie nie zrozumiałeś. Mapa pozwala na ich pozbycie się - nie muszą zostać powielone. Chodzi mi tu o pewne "nagłówki" formatu zawierające informacje chociażby o jego wymiarach itp. itd.

Ba... Zapomnijmy nawet, że bmp posiada wariant, który używa algorytmu RLE co potrafi znacząco zredukować rozmiar pliku No ale kto się nie interesuje, to nie wie i potem pisze na necie głupoty, że bmp jest zawsze 3 bajty x wysokośc x szerokość + nagłówek w wielkości pliku, jpg zawsze kaszani jakość ale jest mały, zaś png jest ogromny w porównaniu do jpg zawsze. To są właśnie mity. Wystarczy optymalizować, znając się na tym.

Co do podziału to erix utrafił w sedno. Jpg tylko tam, gdzie liczą się duże ilości przejść tonalnych, a więc do zdjęć. Niemal każde inne to png. Zwłaszcza w paletach o zredukowanej liczbie kolorów. Tutaj nawet gif może okazać się większy niż png. Gif został już jedynie do animacji, ale jeśli upowszechni się animated png to i on zniknie z rynku.

Prawda też z kompresją i jej współczynnikiem. Zapewne 95-99% ludzkości nie odróżni bmp od jpg ze współczynnikiem kompresji 80-85. Różnice zauważą dopiero około 70-75, bo wtedy zaczną ujawniać się artefakty związane z kwantyzacją i interpolacją kolorów. Co zaś do obrazków oszukujących, to jest to kwestia kultury, obycia, wychowania. Zazwyczaj bazują one bowiem na tym JAK postrzegamy otaczający świat i co już poznaliśmy by z obrazem skojarzyć. Jeśli ktoś jakiegoś elementu nie zna, to obraz nie będzie dla niego niezwykły.

Ech, nie chodzi mi tu o to, aby się popisywać, czego tu BMP nie potrafi, bo zamiast trzymać się tematu, to przejdziemy zaraz do dyskusji o steganografii...


Można spokojnie zapomnieć, że animated png istnieje. Już tyle lat obiecują i guzik z tego wynika. Toć CSS3 eksperymentalnie już działa w większości przeglądarek.


Dlatego wspomniałem o psychice.

Celem tego fragmentu było uświadomienie autorowi, że to, iż gdzieś, coś w necie wyczytał i jakiś pogląd pokutuje w powszechnej opinii, znaczy tylko tyle, iż ma on ugruntowaną pozycję, ale niekoniecznie jest prawdziwy. Czasem jest tylko w części prawdziwy. To tak jak było z kampanią M$ "Get the facts!", która pokazywała Linuxa jako kiepski OS, a Windę pod niebiosa wynosiła. Tyle, że wybiórczo i stronniczo podawała fakty Autor moim zdaniem robi podobnie.

Co bowiem z tego, że niektórzy się produkują i piszą autorowi, skoro z góry on zakłada, że jego zdanie jest "lepsze"? Napisałeś mu o konfiguracji serwerów - zlał to. Napisano mu o kompresji - uznał że gzipowany tekst i tak będzie lepszy, a kompresja stratna to zawsze zło Wspomniano, że jego podejście jest upierdliwe dla usera i w części przypadków nachalne - też zignorował. A to wszak nie jedyne zarzuty wobec tego rozwiązania.
I oby jak najszybciej było w nich w pełni natywnie i zgodnie ze specyfikacją wdrożone, a nie z prefiksami Sam apng nie używam, ale świadomość jego istnienia u mnie jest, podobnie jak wielu egzotycznych formatów, o których pewnie tylko bardziej zainteresowani webmasterzy wiedzą. Autor podchodzi do swego rozwiązania: "nie wiem co do mnie piszą, nie rozumiem tego - musi być więc gorsze". Z takim podejściem daleko nie zajedzie.
Ja celowałbym w doświadczenie. Psychika ma swoją rolę, ale to częstokroć z perspektywy doświadczenia wiemy co widzimy. Bo dzięki niemu możemy obraz ten sam zinterpretować na wiele sposobów. Sam byłem "ofiarą" wielu "stereotypów", które dla mnie w większości były zabawne. Ale to nie temat na takie rozważania

Odkopię temat. Zastanawiam się nad tytułowym rozwiązaniem jako uzupełnieniem do sprite. Szablony często zawierają mnóstwo powtarzalnych elementów (background-repeat) które mają zmienne rozmiary (ilość sprite będzie niewiele mniejsza od liczby oryginalnych plików). Myślałem nad napisaniem parsera których by takie pliki unifikował w osobny arkusz CSS (w trybie roboczym) + specjalny arkusz dla IE<7. Dzięki temu unikam wielu zbędnych połączeń dla niewielkich plików, CSS gzipuje a IE serwuje arkusz zastępczy.

Zaznaczam że traktuję to jako uzupełnienie dla sprite nie jako zastępstwo. Czy to w ogóle ma sens czy są jakieś wady które to z miejsca dyskwalifikują?