IFR - a FIR egy alternatívája
A Fahrner Image Replacement technológiának (és "leszármazottainak") alapötlete, hogy az oldalban lévő
Mi tehető azonban abban az esetben, ha rendszeresen megjelenő cikkeink főcímeit, vagy előre nem meghatározott szövegeket kellene képpé alakítani? Készíthetünk rá egy szerver oldali programot, ami legenerálja a képeket, de még így is túl sok munkát adunk a szervernek, amikor köztudott, hogy a kliensek óriási kihasználatlan kapacitással rendelkeznek. Erre ad megoldást az IFR.
Az Inman Flash Replacement azt a megközelítést alkalmazza, hogy a "képek" akár a kliens oldalon is összeállhatnak, egy dinamikusan programozott Flash animáció segítségével. Az animáció eldöntheti, hogy miként kell megjeleníteni a szöveget, némi JavaScript pedig arról gondoskodik, hogy csak akkor jelenjen meg a Flash file, ha a plugin telepítve van.
Az eredeti (első generációs) IFR megvalósítását illetően érkeztek kifogások és ötletek, melyek hatására Shaun publikált egy javított verziót is. Mint más hasonló megoldások, ez sem tökéletes, a potenciális problémák listáját is összegyűjtötte a szerző.
■ <h1>, <h2>, stb. fejléceket képekkel cseréljük le, annak érdekében, hogy azok szebben megjelenő oldalt eredményezzenek. Természetesen mindezt CSS felhasználásával érhetjük el.Mi tehető azonban abban az esetben, ha rendszeresen megjelenő cikkeink főcímeit, vagy előre nem meghatározott szövegeket kellene képpé alakítani? Készíthetünk rá egy szerver oldali programot, ami legenerálja a képeket, de még így is túl sok munkát adunk a szervernek, amikor köztudott, hogy a kliensek óriási kihasználatlan kapacitással rendelkeznek. Erre ad megoldást az IFR.
Az Inman Flash Replacement azt a megközelítést alkalmazza, hogy a "képek" akár a kliens oldalon is összeállhatnak, egy dinamikusan programozott Flash animáció segítségével. Az animáció eldöntheti, hogy miként kell megjeleníteni a szöveget, némi JavaScript pedig arról gondoskodik, hogy csak akkor jelenjen meg a Flash file, ha a plugin telepítve van.
Az eredeti (első generációs) IFR megvalósítását illetően érkeztek kifogások és ötletek, melyek hatására Shaun publikált egy javított verziót is. Mint más hasonló megoldások, ez sem tökéletes, a potenciális problémák listáját is összegyűjtötte a szerző.
hát...hát?
Nem hasonlitanam annyira a FIR technikahoz hiaba is probal meg az elnevezessel is arra hajazni.
A FIR alap otlet rettento elegans a csere automatikusan megtortenik mindent a bongeszo intez.
Itt mar scriptelni kell, ellenorizni egyre tobb a buktato.
ellenerveim:(anelkul, hogy vegigiolvastam volna amiket felhoztak, bocsi)
* Egy oldalon akar tobb szaz ilyen flashhel kicserelt obketum is lehet ami elegge lelassithatja a betoltodest majd a scrollozost egy lassab gepen
Leteszteletem: Feladatkezelo: IE megnyit kb 10Mb memoria hasznalat majd elso oldal megnyitasa 17Mb innentol kb 1-2 Mb oldalankent. A technikat leiro oldalt meglatogatva memoria hasznalat:58MB !!
* nem egeszen igaz ez a szerveroldal - kliens oldal eroforraskihasznalas javulas :
ugyanis a szerveren egy jo cache mehanizmus eseten pontosan egyszer kell legyartani a kepeket mig kliens oldalon tobb millio flash gyartas tortenik.
* probalj meg kijelolni egy hosszabb doksit. A flashek szovegei nem lesznek benne
Javaslat:
Az ilyen tipusu dolgokat amik onloadra toltodnek es cserelgetnek elemeket gyonyoruen lehetne behavior-okkel es mozilla alatt moz-bindinggal megoldani es persze pluszba odarakni az onloadost a tobbi browsernek.
Re: hát...hát?
-boogie-
Szerver terhelés, lassulás
szerintem...
Szerver oldalon (a cikk stb letrejottekor) legeneraljuk a kepet egyszer utanna mar csak kepet kell kiszolgalni, esetleg az ilyen kepeknek adhatunk specko nevet, es beallithatunk kesselest...
a fless ilyen jellegu hasznalata szerintem nem celszeru.
--
üdv: kmm...
re: szerintem...
Más kérdés, hogy Jano által és az oldalon a hozzászólásokban szereplő problémák teljesen jogosak... Például engem baromira zavar, hogy az AdBlock kiegészítő szépen felfülezi az összes ilyen szöveget, és olvashatatlanná teszi az oldalt, illetve hogy tényleg lassúbb és bénább lesz tőle a böngészés...
-boogie-
nyilvan en sem azt gondoltam,
az igazi problema talan a tenylegesen gyakran valtozo adatok megjelenitese kepekkel, az termeszetesen nem celszeru szvsz, de nem is ertem MINEK?
hiszen eleg szep feliratokat lehet produkalni kepek appletek objektek stb nelkul...
--
üdv: kmm...
Jó!
Erre való a flash, nem komplett oldalak készítésére. Akinek a kb 4 megabájt memória sok, annak valószínűleg nincs javascriptje vagy/és flash-je telepítve. Sokat dob a megjelenésen és a kijelölésre ritkán van szükség a címekben...
mepet
memória
Valoszinu valamit felreertettel:
Nem 4MB hanem inkabb a 10-szerese! Termeszetesen egy olyan oldalon ahol sokszor alkalmazzak a technikat.
A technika maga szerintem is erdekes. De nagyon nagyon oda kell figyelni mikor alkalmazzuk.
Forum hozzaszolasoknal egy oldalra tul sok ilyen objektumkerulhet ami belassit egy jo gepet is. (Nalam 1800+ Amd + 256Mb Ram).
Es csak 1 oldal volt. Mi van akkor ha elterjed? Mi lesz akkor a tabokban netezo emberrel?
Szerintem tul nagy kliens oldalon az eroforras igyenye ilyenkor.
Es valoban ilyenkkor szerveroldali kepgenereralas is tulzott lenne. Mind helyfoglalas mind savszeleseegben.
Ha egy hosszabb cikk cimeinek, alcimeinek formazasara hasznaljuk.
Akkor markliens oldalon is elviselheto mondjuk mert abbol joval kevesebb van. Viszont ilyenkor mar szerver oldalon is generalhatnank helyproblema nem olyan nagy. Mar csak a savszelesseg marad.
Amire viszont tenyleg jol alkalmazhato szerintem:
Nagyobb oldal elemek es bannerek hasznalata.
Vagy funkcioval biro reszek. Pl egy hirforgato rendszer.
Mondjuk mint a stopon van a 4 fules tartalomjegyzek helyett.
egyebkent ha valaki flashes cimekkel keszult oldalt akar latni. megha azok nem is dinamikusan vannak cserelve:
www.szombathely.hu
IFR vs. PFR
Internet Explorerben 4.0 óta (!) elég szép támogatottsággal bír. A Corelnek is beszállító Bitstream segítségével fejlesztették ki a szabványt (RFC 3073 - W3C) több, mint öt éve.
* Web Fonts - W3C Working Draft 21-July-1997
Ajánlott olvasmány:
Cikk 1997-ből
Font Fusion
Font Fusion
truedoc.com
Fonts for developers
Embedding Fonts Tutorial
W3C - Fonts and the Web
indezine - Font Resources
Font Embedding
Levlista hozzászólás (1997)
--
Szeretettel: Károly György Tamás
kgyt##kukac##kgyt.hu - http://kgyt.hu