Új hozzászólás Aktív témák
-
copin
őstag
Miért? A mini szerverei, nem folyamatosan tömörítik az oldalt? Ezt a cuccot nem kéne összehozni a Dragonfly-al? Bővíteni lehetne onnan is az adatbázist. Amúgy, ahol nem adobe flasht használnak, ott mi az alternatíva? Te írtad, hogy nincs nagyon konkurenciája, de kétlem, hogy Svájcban ne szeretnék a videó megosztókat, vagy a hirdetők a flash megoldást. Mi a konkurencia? Gif?
Ezüstfény? Majd a jövőben. 
[ Szerkesztve ]
-
cousin333
addikt
"Miért? A mini szerverei, nem folyamatosan tömörítik az oldalt?"
De igen. És akkor mi van, hogy jön ez ide?
"Ezt a cuccot nem kéne összehozni a Dragonfly-al?"
A Dragonfly debuggolásra van. Ergo még nem kész oldalakat javítanak vele. Mégis hogyan gondoltad összehozni?
"Amúgy, ahol nem adobe flasht használnak, ott mi az alternatíva?"
Szerintem nincs igazán. A megfejtés: nem használnak. A felmérés lényege, hogy nem a legnépszerűbb oldalakat veszik sorra, hanem véletlenszerűen.
"We spared no expense"
-
cucka
addikt
Azért azt esetleg meg lehetett volna finoman említeni a cikkben, hogy csak azért nem valid az oldalak többsége, mert a webfejlesztők nem értenek ahhoz, amit csinálnak.
Csak egy példa: a "hivatalos" módja egy flash objektum beillesztésének az <embed> tag használata, ezt még a macromedia találta ki. A vicc, hogy ez nem szabványos, tehát a validator hibát dob. A valid megoldás az <object> tag használata, ami viszont nem megy nemtudommelyik explorer alatt.
1. megoldás: Teleszemetelem a kódot okádék explorer specifikus feltételekkel. Mivel ezek az explorert leszámítva minden program számára csak kommentek, a validator nem jelez hibát.
2. megoldás: Javascript-el írom ki a flash kirakó kódot. Csodálatos megoldás,
ezáltal ugyanolyan invalid marad, csak a validator nem fog rá hibát dobni. Olyan, mint besöpörni a szemetet a szőnyeg alá.
3. megoldás: <object>-be berakom az <embed>-et, így mindenhol jól látható lesz. Lesz_rom a szabványt meg a validatort, legfeljebb majd a nagy webes guruk panaszkodhatnak, hogy vajon miért nem szeretnek szabványosan kódolni a webprogramozók..Összességében véve értem én, hogy szép dolog szabványos html-t írni, meg törekedni kell ezeknek a szabványoknak a betartására, a probléma az, hogy az egész elméleti szabványosdi köszönőviszonyban sincs a valósággal, az ügyfeleket pedig nem a w3c validator eredménye érdekli, hanem hogy hogyan jelenik meg az oldala egy böngészőben.
(Ehhez hasonló, ahogy valakik kitalálták, hogy a táblázatokkal létrehozott layout nem menő. Nem azért, mert esetleg lenne bármilyen eszköz is a html/css/stb. nyelvben, ami kiválthatná a táblázatokat, mert nincsenek ilyen eszközök. Pontosabban papíron, pdf-ben, szabványokban és előadásokban vannak, a megrendelő által használt explorerben meg nincsenek. )
[ Szerkesztve ]
-
ddekany
veterán
Na azért a szabványosítás terén egész jól haladnak a böngészők (persze sohasem olyan gyorsan mint szeretnénk), szóval lassan de biztosan kikopnak a régi szörnyűségek (pl. embed). A valid-HTML meg stb hybe meg tud idegesítő lenni, de úgy látszik megtette a propaganda a hatását, pl. az MS is igyekszik implementálni a szabványt böngészők terén. Bár ha az IE 8-ba sem tesznek SVG támogatást, hát nem is tudom mit szólok... (Bezzeg a majdnem-saját vektoros formátumuk, a VML, az van IE5 óta. Milyen meglepő...)
És pl. HTML5-ből kitiltották az összes cuccot ami CSS-ben megoldható... kb mint a Strict HTML 4.
"Ehhez hasonló, ahogy valakik kitalálták, hogy a táblázatokkal létrehozott layout nem menő. Nem azért, mert esetleg lenne bármilyen eszköz is a html/css/stb. nyelvben, ami kiválthatná a táblázatokat, mert nincsenek ilyen eszközök."
Nem vagyok Web designer, de ahányszor próbálkoztam CSS-el layout-ot csinálni, kb annyiszor kellet valami kompromisszumos megoldást találnom ahelyett amit valóban szerettem volna, pedig tök triviális dolgokat akarok általában. Lényegében nekem az volt mindig a gondom, hogy nem tudja elég intelligensen lereagálni a dobozba kerülő szöveg hosszának változásár, sem a képernyő méretének a változását, meg úgy általában semmit... Ha tudok előre mindent, akkor persze bármit elhelyezek vele jó helyre, de ha nem...
És mint látom ezzel mások is így voltak, mert teli van pixelben megadott szélességű hasábokkal (így próbálja meg az ember monitor DPI-jét növelni...) meg efféle szörnyűségekkel minden.[ Szerkesztve ]
-
ddekany
veterán
Ja és a CSS és a táblák kapcsán igazából azt akartam mondani, hogy az egy dolog hogy böngészők is hibásan/hiányosan valósították meg, de ha 100%-osan valósítják meg, akkor sem találtam a szabványban (CSS 2 volt, azt hiszem) módot a layout megoldására. Konkrétan azt hiszem egyszer az volt, hogy az oldal menű (baloldali hasáb) olyan széles legyen, hogy ne törjön el benne egy menűpont sem, míg a jobboldali oszlop olyan széles legyen hogy, kitöltse a maradék helyet. És, a lényeg, a bal oldai menüpontok rendes szövegből vannak, nem ám raszergrafikából (ráadásul saját készítésű bulettel és hierarchia szerinti behúzásokkal). Azt hiszem ez volt az óóóóriási igényem (tök alap dolog lenne szerintem...), és legalábbis anno csak táblával sikerült, azzal viszont kb azonnal... Őőőő... most se tudom persze hogy adnám meg ezt CSS-ben, de ha béna vagyok akkor lökjétek a megoldást. (Mentségemre, nem vagyok Web designer, csak néha össze kell ütnöm ezt-azt saját célra...)
[ Szerkesztve ]
-
FTeR
addikt
konkrétan nyilatkoztak róla, h nem lesz benne svg és ha minden igaz adobe is leállítja a plugin támogatását.
html5-nek annyi köze van elődeihez, h az is leíró nyelv. de ez a meccs sincs még eldöntve. mert w3c a xhtml2-t fejleszti, míg a piaci szereplők a html5-öt. ennyit a szabványokról...
a legtöbb kompatibilitási gond megoldható ha pár default értéket átdefiniálsz a .css elején, aztán meg tapasztalat kérdése, h mennyire találod meg az arany közép utat. pl nekem még 1x sem volt szükségem böngészőkként külön css-re, pedig nem 1 cifra weblapot készítettem már.
-
ddekany
veterán
"white-space:no-wrap"
De attól még a két hasábnak otthont adó két div (a menü és a fő tartalom) szélessége nem lesz jó, ha jól emlékszem... Konkréten -- és remélem jól emlékszem -- a jobb oldali hasábot nem tudom elhelyezni úgy, hogy bizonyos betűméret fölött ne fedjenek egymásra a baloldalval. Esetleg valaki egy konkrét minimális működő példával elő tud állni ami bemutatja, hogy nem is rakás **** a CSS layout-os része? Vagy ennyit a szabványokról? Na, remélem én tudom rosszul...
-
ddekany
veterán
"konkrétan nyilatkoztak róla, h nem lesz benne svg"
Baaazzz... de miért nem?
Akkor most továbbra is használjon mindenki flash-t ha vektoros képeket akar? Akár bullet-eket, akár a céglogót... hogy végre ne legyen semmi pixelben megadva az oldalon, és rendesen skálázódon pl. DPI változáskor. És nem elég, hogy a raszteres átméretezés eredendően ronda a sok esetben (persze fotónél muszáj...), hanem kb csak most kezdenek odáig eljutni a böngészők, hogy feltalálták az resampling-ot... 
OK, Opera rég tudja, de FireFox csak 3-tól, IE meg legalábbis 6-ban még nem tudta. Meg néha utólag sharpen is kéne persze. Annyira gagyi ez a terület még..."html5-nek annyi köze van elődeihez, h az is leíró nyelv."
Ez mondjuk óriási túlzásnak tűnik... miért mondod ezt? (Mellékesen, HTML 5-ös mozgolódásnak szerves része csomó új JS-es API, meg a meglévők "szabványba" fogalálsa is, persze az szigorúan véve nem HTML5. De szóval ilyen alapon nem csak leíró nyelv... Ettől eltekintve lecsupaszított HTML 4 + néhány új attribútum, meg nincs DTD, és efféle apróságok. Nem?)
[ Szerkesztve ]
-
ddekany
veterán
Jó, igaz, a "jó az a parasztnak" igénytelen látszat-pró világunkban mondjuk kb minden mindegy (kivéve hogy mire mekkora számot írunk), de t.f.h. már-már megvetendő idealistaként mégsem szarunk mindenre a következő negyedéves bevételen kívül. És akkor én ott látom a gondot, hogy ez így egy ördögi kör: 72 dpi fölé sokkal nem érdemes menni a kijelző gyártónak, mert mindenből bolhavese lesz meg kezd rondán torzulni a layout. Tehát nem mennek sokkal főlé (kivéve speciálisan CAD-es monitork, stb), de épp ezért persze hogy nincs is igény rá szoftver oldalon sem. Valakinek meg kell tennie az első lépést, és gyakorlatilag csakis a szoftveresek tehetik meg! Egyébként meg hányszor volt már azzal szívás körülöttem, hogy felhasználónak túl kicsi a betű, de ha jól feljebb állítom a DPI-t akkor meg ez-meg-az leszarja ill hülyén néz ki... persze itt is lehet a fent vázolt szarni-bele filozófiát kövezni, végül ettől még lesz holnap is győzike meg kolbász, szóval minek a felhajtás...
-
FTeR
addikt
ha nem akarsz átlógást, akkor az overflow atribbal kell játszani. ha fix szélességet adsz meg, akkor ne csodálkozz, h nem nyomja szét a tartalom.
huh, most konkrétan nem jut eszembe az indoklás, de vmi olyami, h elég gáz az svg mint böngészős technológia. amiben van igazság, nem arra lett kitalálva, h html oldalakban használják.
alternatívának ott a silverlight (nyilván ez is rájátszott ms-nél), egy xml alapú leírónyelv, bármiből lehet vektorgrafikát konvertálni bele.
a skálázódás meg igen szépen jelen van benne (lásd, NY Times Reader).ugyan a html5-nek pont az az egyik sarköve, h ne dobja el teljesen kompatibilitást, szemben az xhtml2-vel, de ezt leszámítva teljesen újragondolták az egészet. mindkét speckónál az új web2-es multimédiás célok voltak a fő szempontok és ennek nyomán teljesen kihalt az eredeti html felfogás, ami már egy régen túlhaladott dolog.
szvsz xhtml2 több frappáns megoldást tartalmaz (elég sok az átfedés), de ezekért cserében csúnyán keresztbe vág a kompatibilitásnak...
ez egy jó összefoglaló[ Szerkesztve ]
-
cucka
addikt
Nagyon jól leírtad, hogy miért nincs igény rá - mert a monitor gyártók nem mennek egy bizonyos pixelméret alá, kivétel néhány nagyfelbontású képernyővel szerelt noti. (De azok azért elég ritkák, meg aki olyat vesz, az általában tisztában van a helyzettel).
Egyébként meg nem vagyok webdesigner, de a php/js/egyéb kódok mellett html/css kódot is szoktam írni, előre elkészített dizájn alapján. Hidd el, nekem nem fájna, ha svg-t kéne használni ezentúl raszteres képek helyett, mert ugyanannyi munka megcsinálni. Nem azért nem érdekes számomra az svg téma, mert annyira igénytelen lennék, hanem mert egyrészt nem az én dolgom, másrészt meg az egész problémát úgy tekintem, mint választ egy fel nem tett kérdésre.Ha már valamit gatyába kéne rázni a weben, akkor lehetne kezdeni a teljes html/css kidobásával. Jelen állapotban az egész egy nagy kupac trágya. Milyen leíró nyelv az, ahol nincsenek szabványok, csak ajánlások? Vagy amit össze-vissza értelmeznek a böngészők? Miért nem lehet megkövetelni, hogy a böngésző csak helyes kódot jelenítsen meg? Miért nem lehet egyértelműen megmondani, hogy az x verziójú html vagy css nyelv pontosan milyen eszközökkel rendelkezik? (Márhogy a valóság érdekel, nem pedig az, hogy egy csoport informatikus mit írt bele egy pdf-be meg a w3c honlapra).
Úgy látom, a Microsoft most igyekszik pótolni a hibát, amelyet elkövetett az IE6-7 böngészőkkel, így a kedves döntéshozóknak talán ilyen irányba kéne megreformálni a webet, nem pedig toldozgatni a jelenlegi "szabványokat". Igen, tudom, az xhtml2 elvileg erre lenne kitalálva, de akkor mégis miért merült fel egyáltalán a html5 kósza gondolata is?A következő, amin lehetne javítani, az a nagyon divatos AJAX. Egyszerűen elképesztő, hogy a manapság talán legjobban hype-olt technológia valójában mekkora egy összedrótozott hulladék. Egyirányú kommunikáció, szar xml kezelés, stb., a végeredmény pedig totális ergonómiai csőd.
[ Szerkesztve ]
-
FTeR
addikt
ilyenkor mindig megszoktam jegyezni, h ms részéről nem az a hiba, h az ie6/7 hogyan sikerült, hanem az, h 6 évig nem fejlesztett böngészőt.
ie6 korának legszabványosabb* böngészője volt és nagyon sok inkompatibilitás abból ered, h akkor még félkész** ajánlást implementáltak vagy abból, h adott defacto ie fícsört a w3c ~10 évvel később másképp implementált (tipikusan ilyen az xhtmlrequest).
az ie7 meg egyszerűen az arany középút. xhtml1 doctype mellett sokkal szabványosabb, mint html4 alatt. az ie8 szabványossága így is húzós lesz, hogy ie7 bevezette a módosításokat.*valóban csak ajánlások vannak, nem mintha a szabvány szentírás lenne
**nemtom lehet-e félkésznek nevezni vmit az ezredforduló környékén amit 2007-ban véglegesítettek (újra) egy olyan iparágban, ami 2 évenként megváltozik...
(először 2005-ben véglegesítették, amit visszavontak és tavaly véglegesítették újra, addig gyak beta volt, opera rakat ideig erre hivatkozott, h miért nincs implementálva sok fícsör, nem véletlen vannak a mai napig gondok ajaxos oldalakkal opera alatt, lásd pár google szolgáltatás, mégha már vagy 2 verzió óta nem indokolt a dolog)[ Szerkesztve ]
-
cucka
addikt
ilyenkor mindig megszoktam jegyezni, h ms részéről nem az a hiba, h az ie6/7 hogyan sikerült, hanem az, h 6 évig nem fejlesztett böngészőt.
Tudom, hogy megjelenésekor az IE6 korszerűnek számított. Ami problémás, hogy valahogy ma, 2008-ban is a piacvezető böngészőnek számít. Tudom, a meglévő szoftverek lecserélése sok időbe tellik, de azért el kell ismerni, az MS részéről sem volt túl nagy érdeklődés aziránt, hogy haladjanak a korral.
Az IE7 szabványkövetés szempontjából valóban nem tragikus, ugyanakkor mint böngésző, az. Az a probléma, hogy az MS-nek is meg van kötve a keze, mert szeretne visszafele kompatibilis megoldást készíteni, de sokszor ez ellentmond a jelenleg érvényben lévő ajánlásoknak. Pontosan ezért lenne célszerű lesöpörni mindent az asztalról és tiszta lappal indulni.Ha egyszer sikerülne eljutni oda, hogy minden böngésző egységesen kezeli a szabványban leírtakat, akkor onnantól egyszerűbb lenne annak továbbfejlesztése is. Ugyanígy lehetne kényszeríteni a felhasználókat a régi böngészők lecserélésére, tehát mindenki jól járna. És ez nem zárná ki a régi html/css dokumentumok megjelenítését, mivel a renderelő motorok maradhatnának.
AJAX-al nem csak az xmlhttprequest a probléma, hanem hogy nincs felkészítve arra, hogy valódi működő weboldalakat készítsünk vele. Például egy ajaxos oldalnál ha elküldöd a request-et, akkor a felhasználónak max. egy animált gif-es homokórát rakhatsz ki, arról fogalma sincs, hogy lassú a netje, lehalt a szerver, jön-e az adat vagy sem, stb. Pl. freemail.hu csodás ajaxos felületén is csak ennyit látsz, hogy várni kell. Azt nem lehet megmondani, hogy mire, mennyit, történt-e valami probléma, lehalt-e az oldal. Ez például egy súlyos ergonómiai hiba. Gondolom a back gomb funkciójának megváltozását, a bookmark-olás kiütését nem kell magyaráznom...
-
ddekany
veterán
"Nagyon jól leírtad, hogy miért nincs igény rá - mert a monitor gyártók nem mennek egy bizonyos pixelméret alá"
De itt az ördögi kört kell észrevenni. Talán mennének lassan, ha a szoftverek ezt támogatnák... de a Web a fejlődés útjába áll. (És ugye az nem 1-2 év lenne, amíg az ezen javító browserek és az azt kihasználó weblapok egyeduralkodová válnának, szóval sohasem túl korán.)
"Ha már valamit gatyába kéne rázni a weben, akkor lehetne kezdeni a teljes html/css kidobásával. Jelen állapotban az egész egy nagy kupac trágya."
Hát ezt egy pillanatra sem vitatnám, viszont ez sajnos nem fog megtörténni. Az IT ipar nem szereti az drasztikus változásokat, csak a fokozatosakat (utóbbiba a vektoros képek simán beleférnének, de valamiért mégsem akarják egyesek). Pedig azt gondolnám, hogy akár közép távon mindenkinek olcsóbb lenne egy a fájdalmas leckék után újratervezett, letisztult dologra átállni, ami ráadásul figyelembe veszi a Web megváltozott használati módját is (dokumentum VS alkalmazás távolság csökkenése), mintsem a mostani történelmileg megviselt technológiát tovább gyúrni... De magát a váltást senki nem meri megkockáztatni, vagy bírja meglépni. (Egyébként is, a szakmai érvek egyre inkább háttérbe szorulnak, ha az a kérdés, hogy melyik technológia lesz a nyerő.)
"A következő, amin lehetne javítani, az a nagyon divatos AJAX."
Multkor egy fórumon szánalmas gányolásnak és időbenvaló visszalépésnek neveztem, de persze kaptam arcomra, hogy már jó JavaScript Kit-ek vannak, amivel már csodás... Szóval ez is tök komoly, hogy a jövő alkalmazás fejlesztő platformja ez lesz. JavaScript-ben fogják írni az Office 2020-at, és a felület HTML-ből és CSS-ből lesz. Remek vízió. Tudom, buta vagyok, mert van JavaScript-re fordított Java is van, meg Google Gears... De hát azt a gányolós toldozós-foldozós mindenségit! A rendes előre tervezés a multé?
Hát nem tudom, mi fog ebből kisülni...[ Szerkesztve ]
-
FTeR
addikt
a dolog úgy nézett ki, h ms berakta kritikus frissítésnek az ie7-et, aztán mindenki felháborodva a fx védelmére kelt, h ms visszaél a monopoljával. irónikus módon moz srác azt nyilatkozta, h ms-nek sokkal jobban kéne kényszeríteni a váltást (lásd fx3 is milyen erőszakos volt).
ie7 az első ie ami default böngi lett nálam, sztem egyáltalán nem tragikus. vannak gyengeségei (mint a kedvencek), de ettől még egy jól használható letisztult böngi.
nyitott kapukat döngetsz, mivel ie8 épphogy szakít a kompatibilitással. usability szempontból több review is pozitívan nyilatkozott róla. persze mire megjelenik a többi böngi simán beéri az extra fícsöreit. persze érdemes megnézni, h ms mint platform gyártó, az ie8-ban programozható újdoságokat is rakott, ami a többi böngészőre nem nagyon jellemző (egyedül talán fx-ben van az adatbázisosdi, nemjut eszembe a neve).
azért az egységes kezeléshez normális szabvány is kéne. nem olyan, amin 10+ évig módosítgatnak és többször is egész verziókat sztornóznak...
az ajaxos rész implementálás kérdése, alapból az összes http hibakódot lekezeli. visszagomb és a history-nál kicsit le vagy maradva. ez már vagy 5 éve nem probléma. a trükk annyi, h az összes böngi lekezeli a uri fragment változtatást, ami ja-ből manipulálható...
-
cucka
addikt
IE7-el nekem igazából a fő problémám, hogy borzasztó lassúnak tűnik. IE8-nál tudtommal megmarad a kompatibilitási mód is. Előbb-utóbb jó lenne kipróbálnom, bár engem inkább webfejlesztői szempontból érdekel, szóval annyira nem sürgős..
Az ajax-os vissza gomb kezelésnek utánanézek, tényleg nem tudtam róla, hogy lehet. (Szerencsére még nem kellett komplett ajaxos site-ot csináljak, csak apróbb részleteket, pl. google suggest szerűséget.)
-
FTeR
addikt
ha programozó vagy, akkor nézd meg jquery-t (még ms is felvette mint hivatalosan támogatott platform). gyűlöltem javascriptezni, de jquery óta kedvemet lelem benne. (társadalmi célú hirdetésünket hallották)
ez csak egy alternatív jövő. példának okáért elméletben a silverlight leválthatná az egész mókát. a legszebb az egészben, h nme kizárólagos a dolog, mert .net-ből is lehet html dom-ot manipulálni és js függvényeket hívni és fordítva.
-
FTeR
addikt
egy sima statikus oldalt max 20 sor jquery mókával teljesen ajaxosítani lehet (ugyan nem feltétel, de növelheti a hatékonyságot, ha pár if besegít server oldalon is). ebben az a szép, h letiltott js esetén is teljesen funkcionális marad az oldal.
ie8 elég sokat javult sebességbe és ezalatt az ablak/tab kezelést értem. a page render szempontból eddig sem volt bajom vele. röhejes amikor már ezredmásodperceken versenyeznek.
fontos különbség, h ie8 alapból standard módban fut, a júzernek külön kattintani kell azért, h compatibiliti módba kapcsoljon (elméletileg html-ből vezérelhető a dolog, nemtom betából megmaradt-e ez a fícsör), ami kvázi egy emulálás. ez nagyban eltér attól, h az engine "mindenevő".
-
ddekany
veterán
"gyűlöltem javascriptezni, de jquery óta kedvemet lelem benne"
Ha most csak a JS-es részt nézem az egész platformba... Tulajdonképpen maga JS nem rossz mint minimalista script nyelv (bár vannak benne buta hibák, de alapvetően az eredeti céljára mint nyelv nem rossz, mert egyszerű de rugalmas). Az hogy milyen API-k voltak hozzá, hát hagyjuk, a Kit-ek azon valamennyire segítenek (tovább lassulás és stb árán...), meg talán a HTML 5 kapcsolódó része, stb. Na de... nehogy már ez legyen az "bázis" alkalmazás fejlesztési nyelv! Az ilyesmi szerintem úgy néz ki tisztességesen, hogy van valami VM-ed kliens oldalon (JVM, CLR, Dalvik, valami-tök-új, akármi), amin aztán lehet használni előre lefordított nem-script nyelveket is (#C, Java, Scala, stb), meg ha akarok modern Script nyelveket (Ruby, Groovy, stb) is, és középpájásokat is (pl. Fan), akármi ami kell a lazaság-szigor, és rugalmasság-sebesség spektrumon. Ehelyett most kb mintha azt akarnák, hogy van a JavaScript, a maga sebesség (lehet gyorsítani, de meddig?) és karbantarthatóság korlátaival, és kész. Ez rémesen gagyi, főleg így 2008-ban... visszalepés.
"ez csak egy alternatív jövő. példának okáért elméletben a silverlight leválthatná az egész mókát"
Hát... egyrészt remélem nem lesznek licensz meg más-platformon-gyakorlati-megvalósíthatóság gondok, visszaélések, de egyszerűség kedvéért t.f.h. nem lesznek. Akkor is kérdés (számomra, mert mondjuk buta vagyok...
), hogy mennyire lőnek be itt egy közép utat egy yet another flash/applet klón elkészítése helyett. Közép utat a desktop-alkalmazás és a "hiperlinkes dokumentumok / tetőtöl-talpig REST" világ közt... pl. van olyan Silverlight-only oldal, aminbelül lehet linkelni URI-val, (és így akár bookmark-okat elhelyezni, history-ban mozogni)? (Tudom, rakjak több silverlight-et több HTML oldalra... de ez erősen korláros megoldás.) Amit tartalmilag lehet olyan jól gépileg elemezni, mint akár csak a HTML-t (pedig az sem a csúcs, főleg persze a mostani gányolós oldalakkal)? -
FTeR
addikt
egyrészt sl-hez van rubby meg phyton is (egész pontosan bármelyik .net nyelv használható, van párszáz belőle). másrészt teljesen beépül a html DOM-jába. erezd szabadon a fantáziádat és azt mind lehet.
ez annyira így van, h sl1-nél controllok és .net híján az volt a javasolt eljárás, h html elemeket helyezünk az sl alapra és js-ből manipuláljuk.
harmadrészt .net-es/vistás WPF app minimális módosításokkal átemelhető SL-be.a sebesség persze összehasonlíthatalan, még a legyorsabb js motor is nagyságrendekkel lassabb...
alapból is hivatalosan több platformot (win mellett osx, symbian, win mobile) és böngit (ie melett fx és safari) támogat, hallgatólagosakról nem is beszélve (pl. opera, hivatalosan nincs támogatás, mégis gond nélkül megy és hibákat is javítottak). moonlightos mókát majd még meglátjuk, ha nem maradnak úgy le, mint a mono-val, akkor azzal sem lesz gond.
ettől függetlenül még mindig ott van az xbab, ami full .net csak böngészőben (lásd szepmuveszeti.hu virtuális séta). persez ez win only.
-
-
REDeath
őstag
érdekes, ha lesz időm biztos átolvasgatom a blogot.
viszont a "szabványokhoz" annyit, hogy sok esetben direkt nem azok, mert ha az lenne, akkor nem minden böngészőben jelenne meg ugyanúgy, holott ez a cél. egy kisebb paradoxon, amíg egyik napról a másikra nem lesznek egységesebbek a böngészőkKodály mondta volt: "Legyen a zene mindenkié". en inkabb neki hiszek, mint az ASVAnak
-
ddekany
veterán
Ezen elvileg segítenek az új szabványok... A DOCTYPE-ből/MIME-ből megállapítod hogy ez HTML 5 ill XHTML 2, és akkor nem kell a régi elcseszéseket emulálni. (Remélem ezúttal már nem lesz olyan színvonaltalanságig, mint amikor annyiban nem tudtak megállapodni a böngészőgyártók, hogy pontosan milyen esetben van quirks és milyen esetben strict mód.) Persze lehet mondani, hogy majd eltolják az implementációkat, és akkor megint lesznek ilyenek, de szerintem a mostani felállásban a Web designerek reakciója inkább az lesz, hogy "hát ez nem működik IE-ben/FF-ben, javítsák ki, addig nem használom ki".
Ja amúgy a szabványok többesszáma kapcsán... a pofám leszakad ettől a HTML 5-ös dologtól. Ez szerintem valami csodás demonstrációja ama elvnek, hogy a technológiák közül a szakmailag legjobb biztos vesztes -- u.i. az XHTML2-t attól tartok eláshatjuk, marad helyette a rövidtávú üzleti érdeknek megfelelő és persze kevésbé kockázatos középszerű praktikus gányolás. Állati inspiráló elv...
Ezüstfény? Majd a jövőben. 
És mint látom ezzel mások is így voltak, mert teli van pixelben megadott szélességű hasábokkal (így próbálja meg az ember monitor DPI-jét növelni...) meg efféle szörnyűségekkel minden.
Akkor most továbbra is használjon mindenki flash-t ha vektoros képeket akar? Akár bullet-eket, akár a céglogót... hogy végre ne legyen semmi pixelben megadva az oldalon, és rendesen skálázódon pl. DPI változáskor. És nem elég, hogy a raszteres átméretezés eredendően ronda a sok esetben (persze fotónél muszáj...), hanem kb csak most kezdenek odáig eljutni a böngészők, hogy feltalálták az resampling-ot... 
Hát nem tudom, mi fog ebből kisülni...
Új hozzászólás Aktív témák
it Az Opera MAMA projekt keretében olyan adatbázist hoznak létre, mely a szabványosabb weboldalak létrehozását segíti.
- OnePlus 9 Pro - gyorsulási futam
- sziku69: Fűzzük össze a szavakat :)
- Autós topik
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Diablo IV
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Fujifilm X
- Politika
- eBay-es kütyük kis pénzért
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen