iframe használata 2016-ban

Internet: PHP, CGI, stb.

Megkeresett egy ismerősöm, hogy egy iskolai projectben (webes szöveges kalandjáték) iframe-ket szeretne használni, viszont az oktatója kézzel-lábbal tiltakozik ellene.
Emlékeim szerint, jó 10 évvel ezelőtt a frame és iframe használata erősen nem volt ajánlott olyan indokokkal, hogy böngészőkompatibilitási problémák vannak, nem jól SEO-zható, stb.
Kérdés, mi a helyzet most? Elméletileg, a Google már jól tudja indexálni az iframe oldalakat. Mi a helyzet a mobil böngészőkkel? Milyen indokai lehetnek, az iframe használatának mellőzésének?

  • 4879 megtekintés

( dotnetlinux | 2016. 10. 22., szo – 09:53 )

Iframe egy oskovulet, par eve a table is. Div van helyette, ami jol css-zheto. Ha az iframe ugyanazon oldalrol tolt le tartalmat akkor minek az iframe? Ha masik oldalrol tolt le, akkor meg miert onnan? Iframe modern valtozata az embed html tag. De azt se hasznald.

Uj oldalnal legyen cel a html5, annak pedig iframe nem baratja.

Kezi szivatos kocsik mar nincsenek, ne szivasd magad iframe-mel

Erre gondoltam én is. thead, table, footer tag-ek valók egy üzleti alkalmazásban a táblázatokra, de az alapvető layout régi technikája (table, rowspan, colspan, stb.) nem lesz elég szép és reszponzív és ... (ide jön majd még sok bullshit)

Én is gondoltam, hogy trollkodom ezzel egy kicsit, de dnl valszeg arra gondolt, hogy ne táblával csináljunk layout-ot, ami stimmel. A ne használjunk táblát kicsit valóban mást jelent :)

Egyébként az iframe teljesen korrekt, ha megfelelően és a céljára van használva (teljesen ki akarsz valamit bontani az oldalból, semmi ne vonatkozzon rá, ...). Tényleges, saját tartalmat azzal behúzni tényleg usability fail.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Tudod, hogy nem vagyok webfejlesztő, nem trollkodásnak szántam. Alapvetően az érdekelt, hogy ha valamit megenged egy szabvány illetve ajánlás, akkor valami sznob őrület gátol meg egyeseket annak használatában, vagy komolyabb oka is van ennek a divaton túl.

off

De, hogy elborzasszak egyeseket, épp azon agyalok, hogy ha már nem fért fel a router-emre a webes felület, de az uhttpd még cipőkanállal felmegy, akkor a szerver oldali scriptek részben ash, részben awk lehetnének. Ha úgy tetszik, PHP helyett. Még az nem világos, hogyan tudok valamiféle jogosultságot kezelni, tehát input mezőben bekért felhasználónév, jelszó után annak helyessége esetén kínálja fel azt a weblapot, amellyel például be/ki lehet kapcsolni a wireless interface-emet majd, meg egyéb efféle marhaságot lehet csinálni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Trollkodásnak azt gondoltam, hogy mark-uplok egy 3 soros/5 oszlopos cellát a fenti elveknek megfelelően, tisztán divekkel és CSS-el :)

Még az nem világos, hogyan tudok valamiféle jogosultságot kezelni, tehát input mezőben bekért felhasználónév, jelszó után annak helyessége esetén kínálja fel azt a weblapot

Ha megelégszel azzal színvonallal, amit egy átlagos routertől várhatsz, akkor simán system()-el hívogatsz mindenféle binárist, ügyelve arra, hogy még véletlenül se escapelj usertől származó inputot, hogy triviálisan törhető legyél :) [egyébként passz, az olyan dolgoktól, amik u-val kezdődnek mindig félek, mert tök jó, hogy kis helyen is elfér, csak semmit nem támogat, amit használnék :) ]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem elsosorban a table-vel van a baj, hanem a table layout-ra valo hasznalataval (tipikusan ahol 2 oszlopbol az egyik egy oldalsav, a masik maga a tartalom). Ez mar 5 eve is gaz volt, hat meg ma.

De a mobilos bongeszes elterjedese miatt amugy sem kellemes, mert kis kepernyon max vizszintesen scrollozva fer el szepen (vagy CSS-bol csinalsz a tablabol display: block-okat mobilon, de akkor eleve minek ttable.

Legyünk őszinték: kliens oldalon eleve nem is látszik az a technológia, ami rendben lenne. Az, amit JS címén ma csinálnak a browserekben, attól a hátamon feláll a szőr. Az nonszensz, hogy egy mai, sokmagos PC-n egy weboldal renderelése másodpercekben mérhető ideig pörgeti 100%-on a cpu-t.

Ez nem kifogás, tény.
1-2 hete próbáltunk egy email sablont csinálni. Igaz ez más, de mégiscsak html.
Elindultam lelkesen div-vel, thunderbirdbe megalkottam, szép, jó. Aztán alakítani kellett rajta, mert máshol, pl. gmail weben és telefonon nem volt jó, ok ez még belefér. Aztán jött az hogy van az outlook nevű szartrágyadomb, na abba aztán teljes káosz, mivel kb. nem ismeri sem a div-et, sem a padding-ot, se a margint, se bizonyos css propertyket, így aztán mivel stackexchange-en írták, hogy bizony ha outlookon akarsz valamit, akkor kb. az egyetlen lehetőséged a table, így átírtam table-re. De az igazítás ott sem volt az igazi, mert ő valahogy másképp értelmezi ezeket, akkor jött a kókány, transzparens kép beszúrása helytartás céljából... Aztán az sem volt jó, mert már nem tudom... Már nem is emlékszek mik voltak. Végül elkészült egy valami, átküldtem a kollégának, hogy tegye be template-nek az osx mail-be. Abba a csodás mail programba egyszerűen képtelenség betenni, hogy ne essen széjjel, a képet is berakja, a font is jó legyen, kb. egy délelőttöt szívott vele, meg guglizott.
Itt fejeztük be. Legalább 2-3 napot elbasztunk vele, és a vége az lett, hogy hagyjuk. Láblécbe legyen aláírás, aztán mindenki csinálja úgy, ahogy akarja, meg ahogy tudja.
Azóta, már csak poénból is, meg szoktam nézni egy-egy hírlevél, vagy google-től kapott levél forrását, hogy a nagyok hogy csinálnak ilyen levelet... Hát, table-lel. Plusz tele van verve ilyen if gte mso 9, if ilyen, if olyan feltételekkel. Minden meg van adva 2-3 féle képpen, pl. színek, margók, stb css-ben és direkt paraméterben is, hogy nézzen is ki valahogy mindenhol, ha az a gyökér kliens nem tudja mondjuk a css-t. Hányinger.
Szóval összefoglalva, ha ilyen mailokat akarsz küldeni, kell rá egy külön programozó.
--
The Community ENTerprise Operating System

Igen is, meg nem is.

Egyrészt, ha valami nem reszponzív, akkor egy kép tuti nem az. Ami desktopon egy e-mail kliensben szépen néz ki, az mobilon olvashatatlanul apró, vagy oldalra kell scrollozni, stb.

Másrész egy jól tömörített képfájl is több helyet foglal mint az, amit szépen css-html kombóval megszerkesztettek. A fogadó fél sávszélességét és mail táhelyét is kíméljük, és a küldő fél is spórolhat pár kilobájtot. Ha az ember hírlevlet küld egy nagyobb felhasználóbázisnak, akkor pedig az a párszáz kilobájt levelenként nem is olyan kevés.

Harmadrészt egy kép nem igazán ... őőő... accessible... mi a jó magyar szó ide? Egy képernyőfelolvasó nem fog tudni mit kezdeni vele, de az egyébként nem korlátozott felhasználó ha kimásolna belőle pár mondatot azt se fogja tudni megtenni.

Negyedrészt ha az emailben dinamikus tartalom van (példa: FB értesítő emailek) körülményes és pazarló minden kiküldés előtt képeket generálni.

Ötödrészt: Felesleges is volna, ha a szabvány értelmesen követve volna :)

Nem. Mert hányinger. Mert nem lehet szöveget kimásolni. Mert nem lehet linket kattinthatóvá tenni. Mert vagy kicsi, vagy nagy képernyőn szarul néz ki. Mert a legtöbb spamszűrő megfogja, mert egy email üres tartalommal, egy csatolt képpel.
--
The Community ENTerprise Operating System

Mert mondjuk 2016 van, és esetleg adnál valami pofát a levelednek....
Most nyilván nem arról van szó, hogy televered js-sel, kiscicás képekkel, japán tinilány animgiffel, hanem valami betűtípust, méretet, színt, margót, igazítást adsz a szövegnek, táblázatnak, linkeknek. De még ez is sok.
--
The Community ENTerprise Operating System

+1

Claws Mailt használok, plain textet küldök, fogadni tudok HTML-t, bár legtöbbször lusta vagyok egyetlen kattintásra, így textben olvasom azt is. Azokat pedig utálom, akik HTML-only levelet küldenek, de ilyen is van. Meg tudom nézni, de nem szeretem az ilyesmit.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Amikor katona voltam, írtam papír alapon levelet. Nem vettem elő a színes ceruza készletet - nem is volt - annak érdekében, hogy gyerekes marhaságokkal dekoráljam az egészet. Leírtam a gondolataimat, a címzett fél elolvasta, megértette. Ehhez képest mennyiben más az e-mail? Mi az, amit nem tudsz unicode textben elmondani valakinek? Ráadásul, ha minden kötél szakad, ott vannak a mellékletek, lehet agyon design-olt pdf-et, képet, bármit küldeni.

Arculat... Ezt is gondolom, valamelyik unatkozó hülye találta ki valamelyik multinacionális cégnél.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egy katonától én sem várom azt, hogy színes ceruzával illusztrált levelet küldjön nekem. De teszem azt egy szülinapi köszöntőnek nem árt egy kis szín, hangulat. Ezért vesz az ember képeslapot, rajzol rá szivecskét, vagy ha gyerek küldi: pálcikaembereket. Még a bankom is úgy küldi a számlakivonatot, hogy a levélen szépen dizájnolt fejlécben látszik a cég neve, és a borítékon is látszik a bank neve, címe mellett a logó.

Az email kiváltja a papír alapú levelezést. Akár a postaládába dobott hírleveleket, színes katalógusokat is. Lehet őket nem szeretni, de nem mind való ördögtől. Én egyszer feliratkoztam egy hírlevélre, ami napi idézeteket küldött. És nem plaintextben volt odab*va két sor szöveg, hanem szépen meg volt tervezve, és ez az esztétikai keret hasznos eleme volt az üzenetnek.

Lehet túlzásba is vinni. Lehet visszaélni vele. Lefogadom hogy sokkal inkább ezért utálod a html emaileket, nem azért amire jó :)

"még valóban belefér"

És a szürke szöveg? A kék link? Miért pont kék? Ha zöldet akarok azzal már ízlést sértek? Egy fenét, nincs ilyen, hogy mi fér bele és mi nem. Megint annak a kérdése hogy mit akarsz küldeni. Más elvárások vonatkoznak más felhasználás esetén. Ami pedig gusztustalan tolakodó vacak, az egy csatolt pdf-ben, vagy egy weboldalon is az lesz.

Én remélem nekem küldenek továbbra is, mert az agyam eldobnám, ha a feladatleírások amiket kapok nem lennének értelmesen tagolva fejlécekkel, vagy a beillesztett kódot szétbarmolná a hülye plaintext wordwrap, vagy a listák nem lennének áttekinthetőek.

Bár...

Tudod mit szeretnék?

Markdown támogatást.

Egyébként ide is. Fenének kell ez a bbcode :)

Oh... https://addons.mozilla.org/en-US/thunderbird/addon/markdown-here/

jajj, hagyjad már az ilyen fancy dolgokat...

régen az emberek pottyantós wc-be csinálták a dolgukat, s fancy WC-papír (3 réteg!? rózsaszín!? guriga!?) sem volt. kiürítettem magamat, utána könyebb volt. ehhez képest mennyiben más az angol wc? mi az, amit nem tudsz kert végében lévő pottyantóson elintézni, de angol wc-n igen? ráadásul, ha minden kötél szakad, lehet közelebb is építeni az a pottyantóst, meg gyakrabban üríteni, meg etc.

angol wc... ezt is, gondolom, valamelyik unatkozó hülye találta ki valamelyik nyugati országban...

vannak, akiknek egyszerűbb minden ellen sírni, mint tényleg változtatni a világon.
--
blogom

"Főleg hogy a legtöbb email kliens vagy maga a böngészőben fut"

Ez az elmélet. A gyakorlat meg az, hogy pl a legnagyobb mail szolgáltató (gmail), aki egyben az android atyja, a saját natív androidos gmail kliensét nem tudja -nem akarja?- rendesen megcsinálni. Reszponzív emaileket pl egyáltalán nem jelenít meg, csak a desktop nézetet, frankón lekicsinyítve hogy beleférjen a viewport-ba. Media queries? Ugyan már.

Van egyáltalán media queries támogatás?

A gond az, hogy az emailben lévő html-nek semmi köze a mai modern html-hez. Megragadt úgy, ahogy 10 éve hagyták, és mindenki aki html emailt próbál megjeleníteni lebutítja arra a szintre. Persze mindenki máshogy teszi, és ebben nem csak a gugli a hibás.

Egyébként pont ezt mondom. Ott a Gmail app-ban a webkites webview. Ott van a thunderbirdben a gecko. Outlookba is mehetne az engine amit az edge használ. A webkliensek számára ott a böngésző amiben megnyílik a levél. Simán renderelhetnék a modern html-t, css-sel, animációkkal, transzformációkkal, csak a scripteket és egyéb biztonság szempontjából kérdéses elemeket szűrjék.

Mégsem ez történik.

Csak egy példa:
Egy levél előnézeti képe iframe-mal oldható meg elegánsan.

Az embed/object nem kezeli normálisan a független CSS filet, és örököl ezt-azt.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Másik példa: van a szerveremen egy tetszőleges, adatokat tartalmazó file (mondjuk toplista.txt, de lehet akár toplista.xml vagy toplista.xls), amit meg szeretnék jeleníteni egy div-ben.

A HTML+DOM-ban tudtommal erre az egyetlen lehetőség a frame/iframe.

Az AJAX elvárja az embertől hogy programozzon le kézzel egy webservert (klienset) annak minden nyűgjével együtt.
(a HTML többi része barátságos leíró természetű, azt mondom hogy img kép / embed hang / iframe url és akkor a böngészők íróinak kell lekódolniuk 1x az adat megszerzését, és nem nekem kell minden egyes alkalommal)

szerk: ez főleg SzBlackY kommentjére válasz: "Tényleges, saját tartalmat azzal behúzni tényleg usability fail."

Fali usability lenne, ha lenne másik eszköz saját tartalom megjelenítésére, de, amennyire tudom, nincsen.
(Például az ember akar egy statikus blogot üzemeltetni szerveroldali nyelv nélkül, RO módon, csak feltöltögetni a file-okat, na, hát erre nincsen eszköz, max a frame/iframe)

Az AJAX elvárja az embertől hogy programozzon le kézzel egy webservert (klienset) annak minden nyűgjével együtt.

Mit finnyáskodsz? Épp tegnap írtam meg, hogy a php-hoz hasonlóan egy weboldal html kódjába inline lehessen shell parancsokat írni, s az dinamikusan generálja az oldal egy részét. Egyébként awk-ban írtam, nem is volt túl bonyolult. Ami kellemetlen volt, az az idézőjelek, aposztrofok, de végül úgy döntöttem, ideiglenes file-t generálok, s azt futtatom, így minden a helyére kerül. Mindezt a router-emen futó LEDE-n lévő uhttpd-re.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én is írtam már ilyesmit routerre. (Mondjuk én lassan írtam, mert nem értek a programozáshoz egyáltalán, és nagyon sokáig tartott kideríteni hogy az ash vagy mi eldobja a cikluson belül definiált változókat.)
(Egy Go (játék) állást tárolt stringként és adott oda kérésre, sőt, néha még le is mentette a nem felejtő memóriájába)

Csak az embed menu.html fájó (pl megalkották miatta a PHP-t meg a JavaScriptet) hiányossága a nyelvnek. És statikus környezetben marad az, hogy a menu.html kap egy külön frame-t.

off

az ash vagy mi eldobja a cikluson belül definiált változókat

Szerintem pipe-oltál a ciklusba, amiből az következik, hogy a ciklus önálló process-ként subshell-ben fut, így a foglalt memória terület is teljesen el van szeparálva, ezért a változók nem látszanak a hívó shellből. Annyiban zavaró, hogy ránézésre olyan, mintha az eredeti shellben futna, hiszen semmiféle hívás nem látszik a kódban. Ez egyébként bash-ben is így van. Próbáld ki:

a='alma'; echo "$a"; read a <<<'korte'; echo "$a"
alma
korte

Valamint:

a='alma'; echo "$a"; echo 'korte' | read a; echo "$a"
alma
alma

A második esetben az 'a' változó ugyan felveszi a 'korte' értéket, de az az 'a' változó egy másik shellben egy másik memóriaterületen került foglalásra. A pipe-ból való kilépés után a subshell kilép, fel is szabadul a memóriaterülete, majd az eredeti shell 'a' változója érintetlen marad.

Ez a kód jobban láthatóvá teszi, mi is történik valójában:

a='alma'; echo "$a"; echo 'korte' | (read a; echo "$a"); echo "$a"
alma
korte
alma

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ha lenne másik eszköz saját tartalom megjelenítésére

Gyakorlatilag te magad is felsoroltad a lehetőségeket:
* Összerakhatod szerver oldalon (nem is kell hozzá programozás, egy felpimpelt Apache pl. a statikus menu.html-t megoldha neked [mod_include])
* Összerakhatod kliens oldalon (simán tudsz írni egy ~10 soros JS kódot, ami az oldal betöltése után megnézi, kell-e dolgokat ide-oda bepakolni, és ajax-szal letölti pket)
* Vegyítheted a kettőt: a kliens oldal lekéri a szevertől az adatokat és bepakolja a helyére. (írtad példának az xls-t... nem egészen xls, de egy pár hete futottam bele, hogy egy oldalra beágyazott kugli docs-os táblázat használhatatlan mobilon, meg úgy eleve nem az igazi... a G ad egy API-t, hogy JSON-ban megkapd a tábla tartalmát, úgyhogy az iframe-t lecseréltem egy scriptre, ami az így kapott JSON-ból állít elő egy táblát az aktuális oldalon, annak a formázásával)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( Fisher v | 2016. 10. 22., szo – 10:08 )

Általában a same origin policy megsértéséből szokott probléma lenni. Amúgy élő megoldás, használják pár helyen, és engem is érdekelne, hogy azon túl hogy csak, mert 2016 van, miért olyan rossz.

( toMpEr | 2016. 10. 22., szo – 10:40 )

Az iframe biztonsagi eszkozkent teljesen elfogadott (sott ajanlott!) es tamogatott, ha ugyanarrol az oldalrol akarsz betolteni adatot arra valoban nem celszeru. (helyette inkabb ajax)

( joco01 v | 2016. 10. 22., szo – 11:23 )

Szerintem általában hülyeségek az általánosítások :), az évente változó divat helyett esetleg az évente változó technológia számít valamennyit. Ha idegen, kevéssé megbízható tartalmat akarsz beágyazni, jó az iframe (és nem csak reklám a use case, de ez egy jó szemléltető eszköz). Sőt, olyan is van, hogy megbízható a tartalom, még az origin is ugyanaz, de valami oknál fogva az oldal egy része más stacket használ, és az ütközések elkerülése végett így választjuk el a főoldaltól (ugyanakkor ha csak egy kis görgethető ablak kell az oldalon belül, arra van sokkal kényelmesebb CSS megoldás, mint egy tök új oldalt összerakni). Ha egy másik domainnel akarsz kommunikálni, annak egyik módja, hogy a cél domainből betöltesz egy iframe-et, postMessage API-val kommunikálsz vele, ő meg XHR-ezik vígan a saját domainjén (erre alternatíva a JSONP, de mostanában már az XHR alapból tud CORS-t, tehát az iframe ilyen használata ki fog halni, ha van sokkal kényelmesebb módszer).

De ezek csak ellenpéldák, a legtöbb tipikus oldalon nincs sok haszna iframe-ezni. Mivel az ismerősöd pont nem egy tipikus oldalt készít, hanem egy játékot, ott meg miért ne, még az is lehet, hogy van.

Fentebbre üzenem, a table és barátai se haltak ki. Dizájnra tényleg nem olyan kényelmes, szerintem soha nem is volt az (esetleg a régi időkben, amikor a CSS még nagyon buta volt, ez volt a kisebbik rossz, mert evvel tutira egymás mellé/alá lehetett így tenni a dolgokat). De egy mezei adattábla esetén még mindig sokkal kényelmesebb, mint div-eket teletömni CSS-sel. De web komponensekből összerakott táblát is láttam már, ott a plusz logika miatt kellett valami a table és barátai helyett, viszont ezt messze nem nevezném még tipikusnak.

--

( uid_17720 | 2016. 10. 22., szo – 13:54 )

Nem kell tűzzel-vassal irtani az iframe-et. Mint mindennek, ennek is megvan a meghatározott célja és feladata. Bizonyos esetekben ezt érdemes használni, azonban az esetek túlnyomó többségében nem szerencsés. Arra meg főleg nem érdemes használni, hogy az oldal szerkezetét alakítsd ki vele, arra vannak más, szemantikailag is megfelelő tagek. Ezt érdemes szem előtt tartani.

( uid_19334 | 2016. 10. 23., v – 14:58 )

Iframe? Az rosszabb a szandál-zokninál is.

Az lesz.
Nem-tudom-ki nagyon szépen megfogalmazott egy ehhez kapcsolódó 'paradoxont'. Hogy egy vers (vagy egy haiku) sokkal több információt képes átadni, sokkal jobb tömörítés mint egy távirat.

Próbáltam arra építkezni hogy tudod mi a baj a szandál-zoknival 2016-ban. Ha sikerrel jártam volna, mondhattam volna kevés szóval sokat.

Te egy technológiai kérdésre esztétikai választ adtál. A szandál egy teljesen megfelelő lábbeli, ahogy a zoknimak is megvan a maga funkcionalitása. Sőt, található mindkettejük alkalmazásának olyan metszetet, ahol jogos a kettő együttviselése.
Innen kezdve, a hasonlatod erősen szakmaiatlan, mert a mérnöki tudományok, nem egy valamilyen szubjektív vélemény alapján mérlegelnek, hanem objektív, mérhető szempontok alapján. Például a technológiai adatlapokat sem szabadversben írják, mondván, majd a sugallmazás alapján megérzi a mérnök a tápfeszültség szükséges nagyságát.
Ezért a balladai homály helyett, megfogalmaznád, exact,technológiai érvekkel az iframe használhatatlanságának indokait? Vagy mindez kívül esik a szakmai kompetenciádnak?
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Szerintem az, hogy aszexuális, férfiatlan. Olyasmi, mint amikor egy nő vastag, például frottír fehér zoknival visel magassarkú cipőt, vagy például papucscipőt, vagy minek hívják, talán balerina cipőnek, nem tudom így hirtelen. Ha valami lélekölő, vágyölő, visszataszító, az ez.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, szeretem. Utálom, ha egy férfi behódoló kéztartással fog velem kezet, de azt is, amikor arrogáns módon ráborítja a kezét az enyémre. Legyen egyenes, férfias, nyílt. A nő pedig legyen nőies. Ne érts félre, semmi extrára nem gondolok, csak ne menjen el az ember maradék életkedve attól, amikor egy emberre ránézve a diszharmónia definícióját látja maga előtt megtestesülni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A római legionáriusok vagy a japán szamurájok aszexuális, férfiatlan puncik voltak? Pedig ők is zokni szandál kombót viseltek!
Az emberiségnek le kéne szakadnia már arról, hogy mindenféle esztétikai és divatideológiák mentén éljék az életüket, mert kurva fárasztó mikor 90. alkalommal kell valakinek elmagyarázni, hogy hiába van Gucci cipőd, az ötven kilós fémlemez akkor is le fogja vágni a lábujjadat a gecibe, mert nincs a cipő orrában fémbetét.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( bandy | 2016. 10. 24., h – 11:24 )

Ezekszerint a Google re-catpcha és a Facebook (like gomb) fejlesztőknek is elfelejtettek szólni, hogy ne iframe-ezzenek már, 2016 van, már nem trendi...

A like gombnak valószínű performancia okai vannak: ha több van belőle, akkor nem kell minden like gombohz külön http request. A másik ok a script preferenciának az lehet, hogy a google/facebook az iframe-el nem tudja olyan hatásosan logolni a felhasználók szokásait.

Pont pár napja törölte el azt a részt a Google az EULA-ból, hogy nem osztja meg termékei között a megszerzett felhasználói követési adatokat: Google intensifies tracking: check your private settings

> A másik ok a script preferenciának az lehet, hogy a google/facebook az iframe-el nem tudja olyan hatásosan logolni a felhasználók szokásait.

Nekem mint fejlesztőnek, üzemeltetőnek, vagy épp felhasználónak pont nem érdekem az, hogy third party adatokat gyűjtsön a felhasználókról/rólam, eleve ezért preferálnám az iframe-es megoldásokat.

Nagy kár, hogy ez keveseknek szempont.

Ha nem akarod, hogy a harmadik fél adatot gyűjtsön rólad és a felhasználóidról, akkor nem építed be semmilyen formában a termékeit az oldaladba.
iframen keresztül is tudja loggolni a usereid szokásait, lévén a legtöbb droid facebookozik és gmailes email címe van. Innen kezdve lehet, hogy nem tudja a Kis Pisti az oldaladon Lasersabre98, de ugyanúgy ismerni fogja, mit szeret, mit nem és milyen reklámot kell betenni a képébe.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Oké, szóval ha egy megoldás csak részben oldja meg a problémát, akkor már nem is érdemes használni :)

Egyébként tök jó, nem építek be semmit az oldalamba. Donate gombot sem, reklámot sem, social media gombokat sem. Ezzel garantáltam hogy se bevételem, se felhasználóbázisom sincs (mert átmennek a kényelmesebben használaható, lájkolható alternatívára inkább.

Amit keversz az a bevétel és az alamizsna fogalma. Ahogy kevered a like gombot és a közösségi média jelenlétet is.
Beépíthetsz reklámot az oldaladba amit ráadásul magadnak managelhetsz. És minő meglepetés, nem fogja meg majd az adblock.
A likevadászat helyett a közösségi médiát tartalom promótálásra, és a közösségi médiát a felhasználói bázis előszűrésére használhatod. Többek közt azért is mert te határozod meg a közösségi médiában megjelenő tartalom mennyiségét.
Donate helyett sokkal több értelme van a fizetős tartalomszolgáltatásnak. Ezzel sokkal könnyebben kitermelhetsz egy stabilan fizető felhasználóbázist, ahelyett, hogy 2 havonta könyörögni kelljen a Donate gomb megnyomásáért.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Nézd, én innen indultam:

"nem akarod, hogy a harmadik fél adatot gyűjtsön rólad"

És úgy látom, hogy hiába nem akarom, mert bizonyos esetekben kénytelen vagyok az igényeknek megfelelni.

Pl oké, mondhatod azt, hogy nem kell lájk gombot raknom az oldalamra, de ha mégis szeretném, ha mégis úgy látom, hogy a felhasználóimnak jót tenne, akkor nincs alternatívám biztonságosabb módszert alkalmazni, minthogy egy FB scriptet betoljak az oldalamba. (ha jól tudom).

Hasonlóan a reklámokkal. Gondolom nekik is érdekük hogy minél több adatot gyűjtsenek, ezért nem nagyon fognak olyan megoldást adni, ami a felhasználóim követését nehézzé teszi számukra. Namost hozzá kell tennem, hogy még egyszer sem építettem reklámot egy oldalamba sem, úgyhogy ez csak feltételezés az alapján amit láttam. De úgy láttam, hogy a legtöbb oldalban a reklám beépített scriptekkel kerül, a legtöbb alkalmazásba pedig third party libek által. Amit te említettél, a saját magam által menedzselt reklámokat, és én szabom meg a feltételeket, _véleményem szerint_ csak a nagy oldalak üzemeltetői engedhetik meg maguknak, a ló túloldaláról: Ahol a reklámozó érdeke felkerülni az oldalra.

Miért is? Mi előnyöd származik abból, hogy azokat az információkat amiket be tudsz gyűjteni és felhasználni a felhasználóidról aprópénzre váltod?

Egyetlen igénynek kell megfelelned, hogy az oldal pénzt termeljen. Kibaszottul sok pénzt. Ehhez az oldalad minden aspektusát neked kell kézben tartanod. Nem neked kell a felhasználóidhoz igazodni, hanem ők hozzád. Egy felhasználó, különösen ha nem látsz belőle bevételt egy senki, egy nulla. Minden oldalletöltés ami nem termel bevételt, neked kerül pénzbe. Ha megnézed az átlag reklámmegjelenítésért befolyó összegeket, máris nincs értelme a dolognak, míg kibaszottul nagy látogatószámot nem érsz el. De nagy látogatószámnál, miért is kezdenél filléreskedni? Miért elégednél meg a megszerezhető bevételek 5-10%-ával?
Miért tesz jót a felhasználóidnak a like gomb? Nő tőle az epéniszük? A likeolgató felhasználó nem termel hasznot az oldalnak, mert öt perc után már azt is elfelejti, hogy merre járt.
A felhasználónak édes mindegy mennyi javascriptet, milyen fontot, milyen oldalszerkezetet raksz össze, míg számára releváns tartalmat tolsz a képébe. Picsogni fog? Igen. Okoskodni fog, hogy jobbat is tud csinálni? Igen. Le kell szarnod az egészet? Igen.
Ha jó a tartalmad vissza fognak jönni, újra és újra.

Egy tematikus oldalnál havi 15-20k körül lehet hirdetéseket elszórni. Milyen látogatószámnál fizet ennyit a Google? 2013-as Adsense statisztika alapján durván 20000 oldalletöltést kell elérni, de ez erősen változik annak függvényében, hogy hova is rangsorol a nagy G.
Miért nem engedheted meg, hogy magad manageled az oldalad monetarizációját? Azért mert munkát kell bele ölni?
Azért olyan a web amilyen mert a legtöbb oldal készítője félseggel csinálja amit csinál. A kicsi oldalaknál az ingyenes, könnyű pénz ígérete ami mozgatja őket és nem veszik észre, hogy többe kerül nekik a megjelenítés, mint amennyi bevételük van a reklámból.
A hirdetés aggregátorok nem ördögtől valóak, de ha nagy akarsz lenni akkor nem kell mindenáron lefeküdni nekik. Amíg nagyon kicsi az oldal, addig nem jelent akkora bevételt, hogy megérje a vele foglalkozást. Ha közepes az oldal és nincs más monetarizáció az oldal mögött, akkor képes kitermelni a működési költségeket. De van az a méret, ahol már sokkal jobban megtérül a saját út.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Azt hiszem kiszállok ebből a témából főleg mert nem értek annyira hozzá hogy értelmesen tudjak válaszolni.
Én csak azt látom amit látok. Weboldalakat 3rd party scriptekkel tele, Andoridos játékokat egy játékon belül 3-4 féle videós reklámmal megtámogatva, mindegyik látványosan 3rd party lib által, ami ocsmány pofátlan engedélyeket kér.

Ha volna jobb, biztonságosabb út, ami meg is éri... akkor miért így csinálják?

Lustaság, kockázatkerülés, olcsójános szemlélet. Plusz, mert a fejlesztőnek ez kerül a legkevesebb erőfeszítésébe.
Nekiállnál 2-3 éves játékfejlesztésnek, úgy, hogy nem tudod milyen lesz a fogadtatása? Nem. Nekiállnál olyan játéknak, ami a fejlesztés végén 10 USD áron menne el és van már 3 tucat belőle a piacon? Nem. Egyszemélyes cégként, üzemeltetnél szervert csak a reklámok kiszolgálására és alkalmaznál külön embert a reklámozók felhajtására? Nem.
Innen kezdve, marad a free cimke, és a reklámokkal, kémlibekkel telebaszott alkalmazások, miközben filléreket kapsz havonta.
Mindenki hibás itt. A felhasználó aki nem hajlandó észrevenni, hogy a privacy-ja drágább, mint 5-10 USD, ehelyett neki ingyé kell minden. A fejlesztő, aki inkább betesz 3-4 kétes forrású libet, csak azért, hogy valami pénze legyen ugyanannak a lejárt ötletnek a 1000+1 alkalommal való újracsomagolásával.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( janoszen v | 2016. 10. 24., h – 16:52 )

A Google-nak semmi baja az iframekkel, de nem ezert hasznaljak. Az iframe hatarozott elonye, hogy sandbox-jellegu hatasa van ha masik domainrol tolt be. Vagyis csinalhatsz pl. egy olyan iframet, amiben benne van a hitelkartya szamat bekero urlap, megsem tud belekokanyolni JS-el a parent oldal. PCI-DSS szerint a SAQ A szintu megfeleleshez vagy ezt kell hasznalni. Konverzio optimalizalas celjabol eppen ezert iframet szokas hasznalni. (Kevesebb lepes.)

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

Van egy kulon erre kitalalt sandbox attributum az iframe-eknel: ha bekapcsolod, akkor sem az iframe-ben futo html nem lat ra az ot beaagyazo oldalra, se az ot beagyazo oldal az iframe-ben levo tartalomra. + van meg par extra parametere amivel korlatozhato az iframe, pl. js/pluginok/popup kikapcsolas.
http://blog.dareboost.com/en/2015/07/securing-iframe-sandbox-attribute/

Ha megnezed, a default az, hogy nem tudsz hozzanyulni az iframeben levo tartalomhoz. Ha a beagyazott oldal kifejezetten megengedi, akkor nyulhatsz hozza. Ezt ugye a banki fizeto oldalak nem teszik meg. Errol bovebben: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin