A modern böngészők miatt nem fejlődik a web
A nyáron megjelent a Weblaboron egy blogmark Old Browsers Are Holding Back The Web címen. Ebben a bejegyzésben az ott leírtakra szeretnék reagálni.
Röviden arról szól az írás, hogy ha felhagynánk a régi böngészők (Internet Explorerek) támogatásával, mennyi új lehetőséget tudnánk használni a fejlesztés során. Nicholas C. Zakas is válaszolt a felvetésekre, igaza is van: el kell fogadni a felhasználók döntését, ha ők nem tudnak vagy nem akarnak váltani, akkor foglalkozni kell velük (rengetegen használnak még Windows XP-t, amire legfeljebb 8-as Internet Explorert lehet feltelepíteni).
Ráadásul lehet, hogy az elején, amikor webfejlesztéssel kezdünk el foglalkozni, valóban több munkával járhat az ezekre a böngészőkre való sitebuild, de meggyőződésem és tapasztalatom, hogy mivel a CSS és a JavaScript egy-egy problémára általában több alternatívát is kínál, egy idő után eleve úgy oldjuk meg a feladatot, hogy a bugok ne jöhessenek elő. Ennek eredménye, hogy egy komolyabb projektnél is legfeljebb pár stílust kell átírnunk, hogy akár IE7-en is jól jelenjen meg az oldal (az IE6-ot meg sem merem említeni; ott is).
A cikk szerzője negyvenöt új lehetőséget sorol fel, amikkel nem élhetünk, ha nem a legújabb szoftvereket használjuk. Ahhoz, hogy magam is átlássam ezeket az elérhető / fejlesztés alatt lévő technológiákat, a blogmarkban lévő felsorolás minden elemének utánaolvastam, átgondoltam, hogy miként lehet ezeket alternatív módszerekkel helyettesíteni.
Újdonságok?
A végeredmény az lett, hogy a lista kétharmada (29 elem) különösebb erőfeszítés nélkül megvalósítható CSS 2-vel, JavaScripttel vagy Flash segítségével régi böngészőkben is, kicsit több, mint egynegyede (12 elem) csak korlátozottan, míg kevesebb, mint egytizede (4 elem) egyáltalán nem. Ez azt jelenti, hogy az eredeti cikk állítása – miszerint a régi böngészők visszafogják a web fejlődését – nem igaz. A fennmaradó egyharmadban lévő technológiák hasznosságát döntse el mindenki maga, persze, jó ha vannak, de meg lehet nélkülük lenni (árnyékok, SVG, aszinkron szkriptbetöltés, Crossorigin Resource Sharing stb.).
Ha alaposan szemügyre vesszük, a lista legtöbb eleme valamilyen módon a látvánnyal van kapcsolatban (CSS transzformációk, <canvas>
, border-radius
és társaik), az ilyen-olyan effektusok létrehozását könnyítik meg. Node egy új website létrehozásának tárgyalásán mi az ügyfél első mondata, miután előadtuk, hogy mi vagyunk a legjobbak? „Persze-persze, nézzen ki jól, de az oldalam legyen a kereső első tíz találata között, lehetőleg az első ötben.” A negyvenöt technológiából hány olyan van, amelyik ebben segíti a munkánkat? Egy sincs. Ha átnézzük az egész HTML 5 szabványt, az <a rel="tag">
-en kívül nem nagyon találunk ilyet, ráadásul arról sincs semmi ajánlás, hogyan használjuk, a keresők hogyan értelmezik, bármi.
Mire való az internet? - szoktam feltenni a kérdést. Erre sokan elkezdenek gondolkozni, pedig nyilvánvaló: információátadásra. A HTML mint adattároló nyelv viszont erre a jelenlegi formájában rendkívül korlátozottan alkalmas, hiszen csak karaktersorokra tudunk benne keresni. Hiába van fenn Magyarország nagyjából összes eladó ingatlana a neten, de ha beírom a keresőbe, hogy „50-60 négyzetméter alapterületű, kétszobás ház Pest megyében, 12 és 16 millió forint közötti áron”, kapok egy rakás weboldalt, és ezeket nekem kell egyesével végignyálaznom, hogy megtaláljam a megfelelőt, ráadásul a találatok nagy része irreleváns. Pedig a site-okon ott van minden, csak a keresők részben nem kezelik az összefüggéseket, részben pedig mivel a HTML-ben nem muszáj strukturáltan tárolni adatainkat.
Valószínűleg sokan hallottak már a szemantikus webről, ami röviden arról szól, hogy a megjelenített információt metaadatokkal látjuk el, így segítve a gépi feldolgozást. Erre szükség is van, mert ha beírom a keresőbe, hogy „bács-kiskun megyei pékség”, akkor az első oldal tíz találatából három foglalkozik pékségekkel, a többi állásajánlat. Ha én a munkámat harminc százalékosan végzem el, megköszönik a részvételt, és másnap kereshetek új állást. Akkor miért foglalkozik addig bárki is a Server Sent Events-ekkel, a WOFF fontokkal vagy a Multiple Columns stb. problémájával, amíg nem tudjuk maradéktalanul teljesíteni az ügyfél kérését? Hisz legfeljebb egy-két főnévből álló szavakra tudjuk optimalizálni az oldalát, de az azok közti összefüggést persze nem lehet megadni.
Fejlődés?
Mi a közös az altamirai barlangrajzokban, az egyiptomi sírfeliratokban, az újságokban és a HTML-ben? Az, hogy egyikből sem tudunk több információt kinyerni, mint amit odaírtak vagy odarajzoltak, az adattárolás technológiája nem fejlődött az elmúlt negyvenezer évben, csak a médium változott! Az emberiség eljutott odáig, hogy egy-két évtizeden belül humán expedíciót indít a Marsra, a számítógépek műveltségi vetélkedőn Amerika legjobbjaival vetekszenek, a Higgs-bozont hamarosan megtaláljuk; de az adatainkat az interneten kőkorszaki technológiával osztjuk meg.
Miért alakult ez így? 1999-ben Tim Berners-Lee és a W3C elérkezettnek látta az időt a HTML fejlesztésének a lezárására, és elkezdtek dolgozni az XML alapú szemantikus weben, ahol az adatokat kiegészítő (meta)információkkal lehet ellátni; ennek első fázisa a HTML-ről való áttérés volt XHTML-re.
Ezt torpedózta meg a WHATWG a HTML 5-tel; lássuk, kikből áll a csoport: az Apple, a Mozilla és az Opera, két böngésző- és egy szoftverfejlesztő társaság. Egy browsert csak látványos dolgokkal lehet eladni, a szemantikus web viszont az elején egyáltalán nem az. A böngészőgyártás pedig nagy üzlet, a Mozilla 2010-ben bő százmillió dolláros bevételének 98%-át keresőcégektől kapta. Node, tisztelt kollegák, miért akarja mindenki a fenti cégek szekerét tolni?
A webfejlesztők elé dobtak a HTML 5-tel és CSS 3-mal egy marék bizsut, amivel csillogóvá változtathatják oldalaikat, de legalábbis kényelmes lesz tőlük a fejlesztés. A lelkes fiatal blogírók hosszú oldalakon keresztül elemzik a <nav>
elem titkait, a CSS színátmenetektől a grafikuslányok fehérneműje lesz nedves (most érkezett a hír: a fiúké is), a szakfórumok rendszeresen visszatérő témája az „újdonságokat” nem ismerő böngészők és fejlesztőcégeik becsmérlése. Évek, évtizedek mennek el, amíg az emberek megtanulják használni az új eszközöket, ráadásul, ha a ballasztot kivesszük a HTML5-ből, kiderül, hogy az újítások nem nagyon elegek még egy HTML 4.02-s verziószámhoz sem.
Éppen ezért paradox módon a modernnek nevezett böngészők miatt nem fejlődik a web, mert miattuk a sitebuilderek nem a lényeges dolgokra koncentrálnak, hisz amíg mi a lekerekített sarkokkal és a <header>
-ekkel bohóckodunk, addig ügyfeleink honlapján megosztott adatokat, tartalmat ugyanúgy nem találják meg az érdeklődők. Ezért mi, webfejlesztők vagyunk felelősek, mert kritika nélkül elfogadjuk, amit elénk tesznek, nem tartva szem előtt megrendelőink érdekeit (és a sajátunkat sem, mert mi sem kapunk ugyanúgy normális találatokat).
A múlt nem váltaztatható meg, de a jövő igen. Ez csak és kizárólag rajtunk múlik.
■
hazafele vennem kell egy nagy
Tyrael
:)
Az Adobe-t és társaikat se
félreérted
A HTML5 (+CSS3) alapvető célja a szemantikusság fokozása. Ha szeretnénk egy normálisan megjelenő weboldalt létrehozni HTML4/XHTML+CSS2 technológiával akkor a kliens számára leküldött HTML kód 75%-a (durva becslés) csak és kizárólag olyan adat, ami a megjelenést határozza meg. Míg ha használjuk az új módszereket, akkor ez az arány simán megfordítható, ezzel pedig egy baromi nagy lépést teszünk a szemantikus weboldalak felé. Nagyon jó példa erre a multiple backgrounds. A példában említett probléma megvalósításához a régi módszerekkel minimum egy plusz
div
tagre és dupla mennyiségű CSS kódra van szükség.Hogy miért ezek a featurök készültek el, és miért ezeket propagálják a böngésző gyártók? Mert végsősoron a weboldal tulajdonosok határozzák meg, hogy hogyan nézzenek ki weboldalak. Mi pedig a kivitelezés során szeretnénk megvalósítani az ő elképzeléseiket. Eközben szeretnénk a kivitelezés során olyan szempontokat is szem előtt tartani, amikre a megrendelő nem gondol, mert neki nem fontos. Neki az a fontos, hogy az oldala működjön, az ügyfele megtalálja és azok az ügyfelei találják meg akik fizetnek neki, hogy tudjon nekünk fizetni.
<szőrszálhasogatás>
Azt írod, hogy se a barlangrajzokból sem az egyiptomi sírfeliratokból nem lehet az ábrázoltakon felül több információt kinyerni. Ez nettó baromság. Hogy milyen technikával/festékkel készült, általános információt ad a készítő személyéről, a környezetről, amiben élt, a technikai fejlettségről.
Egy-egy egyiptomi ábrázolásnál egy figura mérete, a többi figurához viszonyított pozíciója, testtartása annyi plusz információt hordoz, amiről könyveket képesek kutatók megtölteni.
</szőrszálhasogatás>
Ostorozod a keresőket is, hogy nem képesek a te többszörösen összetett kereső kifejezésedre értelmes választ adni, csak arról árulkodik, hogy zéró fogalmad van arról mennyire bonyolult az információ feldolgozás. És akkor a feldolgozott adatok strukturált, formalizált, kereshető tárolásról még nem is beszéltünk. Javaslom, hogy sétálj be egy egyetem könyvtár tanszékére (vagy csak egy nagyobb könyvtárba), és kérj bevezető szakirodalmat az információ keresés, információ visszakeresés, osztályozás témakörökben, olvasd el, és akkor talán lesz minimális rálátásod a probléma bonyolultságára. És akkor a gépi feldolgozás még ad neki egy kis bukét…
Ez mind olyan önmagában is bonyolult terület, amiknek kezelésére tök egyedi megoldásokat szoktak keresni/fejleszteni. A keresés ezekben pedig teljesen egyedi formalizált keresési megoldásokat fejlesztenek.
Hogy egy ilyen bonyolult kereső kifejezésre releváns találatokat kapj olyan hatalmas és bonyolult hardver és szoftver infrastruktúrára lenne szükség, amit véleményem szerint nem képes és nem is akar senki fenntartani. Hogy miért is? Mert a kereséseknek csak végtelenül elenyésző része ennyire bonyolult.
Segítsünk a keresőknek a HTML kódban átadott információk értelmezésében? A HTML5 adja microdata megoldást, ami a korábbi szétaprózott megoldásokat egységesíti. És működik. Bár ezek használatával növeljük a kliensnek adott kód mennyiségét, de ez a többlet segíti a gépi feldolgozást.
Abban egyet kell értenem veled, hogy a fejlődés fájdalmasan lassú. De attól, hogy elsőre nem mindig világos, hogy egy-egy új fejlesztés milyen áttételes haszonnal jár, nem kell az egészet lehúzni a WC-n.
A bonyolult keresésekre a
Ebben a kérdésben egyébként a keresők oldaláról is előrelépés tapasztalható, hiszen számos lehetőséget biztosítanak már most is erre. (Például névjegykártyákat is képesek megjeleníteni a Google találatai között. Többek között ezt a lehetőséget támogatja a Google+ közösségi portál is, de természetesen bárki integrálhat a saját HTML5 oldalába ilyen, jól kereshető névjegykártyát. És a lehetőségek egyre csak bővülnek, a HTML5 lehetőséget ad rá.)
Tehát ebben a tekintetben a HTML5 szerintem is előrelépés. Univerzális elképzelésről pedig még nem tudok a szemantikusság terén, maximum úgy lenne megoldható, ha a szemantikus dokumentumok azt is meghatároznák, hogy a kereső hogyan keressen bennük. (Ez pedig jó nagy terhet tenne a fejlesztők nyakába)
Most csak röviden válaszolok,
<div>
-ben vagy [code]<article>[code]-ben van az adat.Meg hányan használják a mikroadatokat? Elenyésző számban.
iddqd
Vagy én téged vagy te nem olvastad el elég figyelmesen a posztot: azokat a - szerintük - legszórakoztatóbb kifejezéseket szedték össze, amivel az iddqd blogra keveredtek a kedves felhasználók. Nem hinném, hogy ezek lennének jellemzőek a keresésekben.
Mondjuk amilyen találatokat mostanság a google produkál... jó, ha az első két-három relevánsnak nevezhető. :-(
Ma pl. egy konkrét repülőgép típusról akartam némi infót gyűjteni, erre kaptam két találatot, a többi közt még pornó site is előfordult.
Másik véglet a bing, ami meg a relevánsnak nevezhető találatokból is csak a töredékét találja meg sok esetben.
Csak azt szerettem volna
Talán nézz utána a HTML5
Pár mondatban tudnád vázolni
Íme; feltételezem, hogy ehhez
érdekes
Oké persze az ügyfél szeretne valamit, de nem telik sok energiába belátni, hogy az jelen esetben marhaság(kereső első helyezés), logikátlannak tűnik így, hogy a szabványtól ennek teljesítését várjuk el.
pl jön a tag, hogy ő egy erotikus oldalt akar indítani, úgyhogy a 'csöcs' kulcsszóra első találatként hozza a 'gogöl'. A probléma két pontban felvázolható:
1. jó eséllyel van másik 1millió weboldal ami hasonló témakörben mozog, és bizony ők is első helyen kívánnak megjelenni a kereső találati listájában, az adott kulcsszóra
2. A kereső első találati helyének száma, hogy is mondjam...kissé limitált.
Mégis miként kellene a html5(vagy akár 6-nak, 7-nek...)-nek ezt az ütközést feloldania?
További probléma, hogy a felvetés úgy kezeli a webes keresőket, mintha azok bármi szabvány részét képeznék. Ez azért nem egészen így van. Ezeket cégek üzemeltetik, az pedig hogy a kereső találati listáját miként állítják össze kizárólag az ő döntésükön múlik(ami egyébként jó is, ugyanis a példához visszanyúlva bárki mondhatja, hogy az ő oldalán a csöcs bizony releváns kulcsszó, miközben a valóságban mondjuk rotációs kapát próbál eladni).
Mellesleg a rel attributtumon kívül a html5 microdata attribok segítségével eléggé bő információ megadható egy-egy weboldal tartalmáról, szóval még csak az sem teljesen igaz, hogy olyan annyira korlátozottak lennének a lehetőségek.
Egyébként az ilyen ügyfelek második helyen szereplő kérése amúgy azért az szokott lenni, hogy legyen az oldalon különféle látványos mütyűr, mert az menő. Áttételesen ilyenkor eléggé nem mindegy, hogy egy adott funkciót egy böngésző natívan támogat(netán HW gyorsítással karöltve), vagy azon idő sokszorosát kell beleölni a funkció implementálásába, hogy az mindenhol működjön.
Nem nehéz az első öt
Tehát túl kéne lépni az egy szóra való optimalizáláson, és összefüggésekben kéne gondolkozni. Ehhez az első lépés, hogy metaadatokat adunk meg az oldalunkon a keresést segítendő.
Hogy nem-e?
De. Nehéz bekerülni az első 5 találat közé. Mint mondtam sok sok oldal kíván bekerülni arra a pár első helyre, a helyek száma viszont véges, nem kerülhet oda be mindenki.
Persze túl kell lépni az egy kulcsszavas keresésen, de a helyzet, hogy az ügyfél nem azt várja el. Ő 1-2 kulcsszóra akar még mindig dobogós találatként megjelenni. Szóval már az ügyfél elvárásai sem egyeznek a felhasználó kereső szokásaival. De az is jó, ha valami remek összetett keresési feltételre kihozol jó helyezést, aztán a büdös életben senki sem keres úgy a keresőben.
"Mindegy, mennyi időt ölsz bele, ha a látogatóknak sok erőfeszítésébe kerül az ügyfeled oldalát megtalálni, ha egyáltalán sikerül."
Igen, amennyiben úgy tekintünk az oldalra, hogy a kizárólagos szerepe az, hogy egy webes keresőn ráleljenek az emberek, és nem mint egy online megjelenési felület, amire célirányosan csábítjuk a usereket akár más forrásból is.
Az eredeti szösszenet ugye a jelölést hiányolja, ami nyilván nem igaz, hisz ott a microdata, tele lehet aggatni kereső számára hasznos információval az oldalt. Viszont így lényegben minden információ megadható a keresőnek, szóval html oldalról én a problémát megoldottnak látom. Ahhoz hogy a kereső mit kezd az adattal a html-nek sok köze nincs(és lényegében annak sem, hogy a böngésző amiben nézik régi vagy új, tehát ezen a ponton veszti értelmét az egész felvetés). A leírásod alapján te itt valójában inkább azt hiányolod, hogy a böngésző nem tartalmaz kellően okos mesterséges intelligenciát, ami kitalálná a felhasználó minden vágyát, és aszerint adná számára a találatokat.(A felhasználó anyanyelvén megadott folyékony mondatszerkezet mint keresési feltétel már bőven ez a kategória)
Az már más kérdés, hogy a keresők ezt nem vehetik szentírásnak, mert a világ nem tökéletes. Amíg üzleti érdek a keresőben való jó pozíció, addig mindig lesz, aki megpróbálja manipulálni a találatokat, ha pedig erre szabvány szinten lehetősége van, akkor épp az értelmét veszti el az egész.
Éppen ezért ennek alárendelni a fejlesztés irányát nem lenne túl átgondolt.
Persze túl kell lépni az egy
Microdata usage statistics szerint a top egymillió site-nak kevesebb mint egy százaléka használja, míg a HTML 5 doctype-ot több, mint tíz százalék.
még a végén fizetni kell az ügyfélnek?
A szabványt patkoljuk át azért, mert az ügyfél filléreskedik. Logikus.
Az ingyenes kereső a kerső üzemeltetőjének kénye kedve / anyagi érdeke szerint működik. Ha neki úgy jó, akkor holnap megfordítja a találatok sorrendjét az ügyfélnek pedig kuss, mert semmi köze hozzá, hogy milyen sorrendben listázódnak a találatok.
"Nem azzal van a baj, hogy nem lehet használni HTML oldalon, hanem azzal, hogy az emberek a vizuális dolgokkal vannak elfoglalva, és nem a metaadatokkal, ez látszik a fenti statisztikából."
A lehetőség adott, az hogy a fejlesztő és az ügyfél magasról tesz rá, nem a szabványról állít ki szegénységi bizonyítványt.
Az egész problémád amit felvázoltál alapvetően a keresők sara, és nem veszed észre, hogy máson akarod leverni a balhét.
Baromira lényegtelen, hogy 1 millió új html tag bevezetésével vagy html5 microdata segítségével kategorizálod az oldaladon szereplő adatokat, amíg az adatok kiértékelését végző 3.fél azt vesz belőle figyelembe, amit ő akar.
"Az általában pénzbe kerül, a
A szabványt patkoljuk át azért, mert az ügyfél filléreskedik. Logikus.
A keresők elemi érdeke, hogy
A keresők elemi édeke, hogy minél többen használják a fizetett szolgáltatásaikat, tehát a megvásárolható kiemelt poziciót. :)
Ha pedig ezt úgy érik el, hogy tesznek rá, hogy a fejlesztő az oldalban mit kavar a metaadattal, akkor épp eként cselekszenek majd.
Provokáció?
Ha visszafogottabb lett volna, akkor jó vitaindító lenne, de mivel nagyon átesett a ló túloldalára így maximum csak flame születhet belőle.
A HTML5 ugyanúgy XML alapú, nincs szó visszalépésről. Egy HTML5-öt ostorozó cikkben Zakas –ra hivatkozni kicsit furcsa. A twitter fiók leírásában is csak véletlenül szerepel a HTML5? (amit az MS fejlesztésekről írt az előző hónapban azt értelmetlen lenne megkérdőjelezni, de annak a cikknek a gondolatai mégsem illenek ide) Miért a webfejlesztő a hibás, ha a Google nem tudja kitalálni, hogy ha te pékségre keresel rá, akkor sütit szeretnél vagy pedig állást?
A legtöbb helyen az ok és okozat nem nagyon volt párba. Szerintem.
Amikor az Ajax megjelent sokan mondták, hogy de hát ez nem új, ezt rejtett iframe-mel is meg lehetett csinálni. Vagy amikor a tabless elkezdett terjedni, de hát ebben semmi plána nincs, táblázattal ezt sokkal egyszerűbb. Dejavu.
Ne felejtsük, semmit sem kötelező használni!
Nem tudom eldönteni, hogy ez
Nicholas C. Zakas cikke - bocs, ezt tényleg elfelejtettem linkelni. A hetedik bekezdésben van a lényeg, de persze egészében kell olvasni.
Én is hozzátenném a magamét a flémekhez.
A gondolatmenet jó, de a
1, jelenleg is lehet olyan keresőt vagy szolgáltatást írni, ami strukturáltan lement bármely oldalról bármilyen adatot, tehát lemásolhatom a komplett adatbázis publikus részét, csak persze site-onként picit más lesz az algoritmus, és most tekintsünk el attól, hogy ez nem legális - de megoldható; emiatt nem oszt és nem szoroz, ha bizonyos - például megszámlálható, mert az könnyebb - dolgokról plusz metainformációt helyezünk el az oldalban
2, meg kell oldani, hogy ne lehessen minden adatot indexelni, mint ahogy most is van rá meta tag, hogy az adott oldal nem olvashatja a kereső; ha megmondod, hogy a hirdető telefonszámát nem tárolhatja el, a látogatónak mindenképp el kell látogatni az adott site-ra, ha fel akarja hívni az illetékest
Jó bejegyzés.
Szerintem nem csak bizsu amit kaptunk, hanem azért érték is. Egyre kevesebb markup-al egyre több mindent lehet megcsinálni, ami szerintem segíti a szemantikus web fejlődését pláne ha régi böngészők támogatását mellőzhetjük, ami miatt még mindig érvénytelen markup-ot kell használni, vagy extra div-eket betolni. Tény, hogy nem ezen múlik, de azért ez is számít. Egy másik szempont pedig, hogy egyre több mindent tudunk kliens oldalra vinni harmadik féltől származó plugin nélkül (grafikonok, képkivágás, tömörítés stb...). Ezek mind még jobban töredezettebbé tették a web-et és nehezítették az információ átadását és az újdonságok által nyújtott kényelmi lehetőségek pedig lehetővé teszik, hogy jobban fókuszáljunk az említett problémára és mindemellett növelik a hatékonyságot.
Valami frusztráció egyébként érezhető a cikkben, amivel részben egyet értek. Ha visszatekintek az elmúlt évtizedre, nekem is elkezd remegni a szemhéjam.
Sorrend
Természetesen frusztrált vagyok, mert az eszköz (az internet), amivel nap mint nap dolgozom, fabatkát sem ér, nem teljesíti a célját. Kb. olyan, mintha a kezedbe nyomnák a világ legjobb mobiltelefonját: tízezer kvadrillió gigahertzes processzor van benne ugyanennyi gigabájt memóriával, a képernyője és a kamerája atomi felbontású, öt mikrogramm a tömege, az energiaforrása sosem merül le, de, ha beszélni szeretnél valakivel, akkor konkrétan oda kell menned hozzá fél méterre.
verseny
Tyrael vetettel fel, hogy addig volt fejlődés a böngésző piacon és a weben, amíg az IE versenyzett a Netscape-el. Aztán a Microsoftnak sikerült egy elképzelhetetlenül nagy szeletet kiharapni a piacból. És mi is történt ezután kb 5-6 évig? Ja. Igen, emlékszem. Semmi.
Aztán jött a Firefox, és megmozdult valami. Akkortájt indult a CSS Zen garden, ami rövid idő alatt bebizonyította, hogy (relative) kevés információ közlő HTML körítéssel is át lehet adni az információt, így nem kell feltétlenül a rendelkezésre álló HTML eszközöket bevetni a formázás, a reprezentáció miatt, ezzel javítva a klienseknél jelentkező jel/zaj arányt. Ekkor döbbent rá a fejlesztők gondolkodó része, hogy a táblázatot layout definiálására használni botorság. Az más kérdés, hogy sokan átestek a ló túloldalára.
Aztán a Firefox is jól bepunnyadt, rögzültek a "frontok". Megjelent ugyan a Safari, az Opera is kezdett elmozdulni a "jé de érdekes állat, zárjuk is be gyorsan" állapotból. De igaziból semmi nem történt.
És ekkor jelent meg a Chrome, ami rövid idő alatt megint felrázta a böngésző piacot, és igaziból azóta sem hagy senkinek nyugalmat. Folyamatosan fejlesztenek, folyamatosan implementálják a már elfogadott, szabványosnak kikiáltott dolgokat. Csak a Microsoft és a Mozilla korábbi gyakorlatával ellentétben ad némi esélyt is a többi szereplőnek illetve a fejlesztőknek. Értem ezalatt azt, hogy - ugyan egyesek számára agresszívnak tűnő módon - előbb specifikálnak, fogadják/fogadtatják el az újításokat és utána implementálnak.
A visszafelé kompatibilitáshoz pedig még annyit fűznék hozzá, hogy valóban, a jelenlegi oldalakat is lehetne úgy kivitelezni, hogy működjön IE6-al, 5.5-el vagy akár Netscape4-el. De miért fordítsam a fejlesztési idő 40%át egy olyan böngésző verzió támogatására, aminek a teljes részesedése valahol 1-2% körül van, amikor ezt a munkát fordíthatom arra, hogy a célközösség 98%-ának jobb szolgáltatást tudjak nyújtani.
Azt írod, hogy egy csomó HTML5 újdonságot meg lehet valósítani Flash-el is. Ezzel csak az a probléma, hogy azt kell feltételeznem, hogy a felhasználóm rendelkezik ezzel a 3. fél által szállított komponenssel. És mi van azokkal a felhasználókkal, akik nem tudnak/akarnak Flasht futtani?
Mindig a
<header>
és<nav>
elemek feleslegességét bizonygatod, hogy nem hordoznak többlet információt, nem könnyebb feldolgozni mint egy<div id="header">
markupot. Tényleg sokat agyaltam ezen a problémádon és a következőre jutottam. Ha most nekem - háttér ismereteim, szakmai képzettségem hiányát nem véve figyelembe - egy keresőt kellene fejlesztenem, akkor kb úgy állnék hozzá, hogy a HTML egyes részeit a markuptól függően súlyoznám, így próbálnám megkeresni az adott oldal tényleges tartalmát. Sokkal egyszerűbbnek tűnik "lepontozni" egy<header>
tag-et, mint végignézni minden<div>
tag-et, megnézni, hogy mi az id tulajdonsága, és akkor még nem kezeltük a nyelvi változatokat, az elütéseket. Ugyanez igaz a<nav>
elemre. Találok az oldalon két listát, amiben vannak hivatkozások. Amelyiket jelölte a fejlesztő hogy az a navigáció hivatkozásokat tartalmazza, lentebb sorolnám fontosságban, mert az feltételezhetően a site minden oldalán szerepel, ezzel torzítja a hivatkozott URL-ek relevanciáját. Ha az<article>, <section>
elemek pedig szerinted nem segítik előre a szemantikus web ügyét, akkor tényleg nem tudom mit mondjakBeszélgettünk az irodában
<article>
-nél több információt tárolni vele.Vesd össze az alábbi két kódot, és mondd meg, melyikből lehet több adatot kinyerni? Az elsőben szándékosan nem táblázatot használtam a kontraszt kedvéért:
<header>Bérleti díj: 50 000 Ft/hó</header>
<aside>Alapterület: 107 m²</aside>
<figure>Ingatlan állapota: jó állapotú</figure>
<article>Szobák száma: 2</article>
<epitoelem>tégla</epitoelem>
<berleti_dij deviza="huf" ido="honap">50 000</berleti_dij>
<alapterulet mertekegyseg="m²">107</alapterulet>
<allapot>jó</allapot>
<szobak_szama>2</szobak_szama>
</ingatlan>
Most nem találom, ki írta, de
Sokkal inkább az a lényeg, hogy megtalálják az oldalt a keresőben és ha már megvan a szükséges oldal, akkor már ott, a lap saját keresőjével keresgéljenek.
Tehát nem is érdeke az oldal tulajdonosának, hogy ennyire megkönnyítse a keresők dolgát, sőt...
A keresőkben ott van most is
Épp ez az, hogy nincs benne
Egyrészt az ilyen helyeken gondoskodnak róla, hogy konkrét keresési eredményt a bot ne nagyon tudjon kisajtolni az oldalból. Ahol mégis, ott meg épp azért, mert nincs rendszerezve, szabványosítva stb., az adat, nem adja meg a szükséges összefüggéseket, így elég sok munkát adnak a kereső fejlesztőjének, ha az adatbázisukból akar találatokat generálni.
Pontosabban igazad van: adatot talál, csak információt nem.
(ha még jól emlékszem huszonsok éves tanulmányaimra adat vs információ témában ;-) )
mi is a bejegyzés címe?
A felhozott példa markupja nem jó, mert rossz elemeket használsz. Mit is szeretnél? Strukturált adatot előállítani. Akkor miért nem használod azt az elemet, ami erre való? Ez pl egy olyan probléma, amit még akár táblázatban is lehetne reprezentálni, de most vegyük elő inkább a definíciós listát!
<article>
meg<figure>
elemet használ mindenre az ugyanúgy tévúton jár, mint aki annakidején az összes táblázatot száműzte az oldalairól, még azokat is amik valóban táblázatos adatok voltak.Kérlek, olvasd el az utolsó
A példában - mint jeleztem is - direkt használtam rossz markupot (amivel az volt a célom, hogy látható legyen, mennyire nem hordoznak plusz információt egy
<dd>
-hez képest), mert ez jellemző a website-ok 99,99%-ára, nagyon kevesen használják a schema.org által nyújtott készletet. Egyébként az általad készített definíciós lista is jóval kevesebb információt hordoz, mint az én XML-em, már csak a schema.org korlátolt elemkészlete miatt is.Úgy érzem, hogy elbeszélünk egymás mellett, a lényeg a 16-os hozzászólásban van.
tagek
Desktopon. Mobil platformon mekkora?
"ez jellemző a website-ok 99,99%-ára, nagyon kevesen használják a schema.org által nyújtott készletet."
Node várj, mert eddig nem erről volt szó. Ha a lehetőség megvan, de egyszerűen tesznek rá a fejlesztők, az nem az eszköz hibája.
"Egyébként az általad készített definíciós lista is jóval kevesebb információt hordoz, mint az én XML-em, már csak a schema.org korlátolt elemkészlete miatt is."
Valóban, cserébe te a probléma megoldására létrehoztál 6 új tag-et.
Egy problémára.
El tudod képzelni, hogy hány új tag-et jelentene az élet minden területét lefedni, ami csak megjelenhet egy weblapon? (Az hogy xml, ezért tetszőleges nevű tag-et hozol benne nem játszik. Ha rajtad kívül senki nem tudja, hogy egy adott tag milyen speciális jelentéssel bír, akkor ugyanott vagy, ahonnan indultál.)
Mobil platformon mekkora?Az
már androidon sem igazán
Az nagyon jó, most viszont nem lehet. Persze neki lehet állni külön tartalmat fejleszteni desktopra és mobilra, ahelyett hogy html5 + css3 responsive layoutot tolna az ember. Nyilván az ügyfél is sokkal boldogabb lesz, mikor a dupla melóért dupla pénzt kérsz.
Nos csak annyi, hogy ez már önmagában is mutatja, hogy milyen szinten átgondolatlan amit akarsz. A microdata ráadásul ugyanezt csinálja csak másként(a jövőben bővíthető, ha bármi hiányzik belőle), cserébe - a te megoldásoddal ellentétben - nem vágja ki az ablakon a visszafelé kompatibilitást.
Persze neki lehet állni külön
Az utolsó bekezdésedben leírtakat nem igazán értem, én nem adtam megoldást - egyelőre - a problémára, csak felhívtam rá a figyelmet.
Az utolsó bekezdésedben
Ez esetben nem értem miért hoztál elő egy telejsen buta példát. :)
Szar a linux, mert...
De fejleszteni kiváló rajta :)
Van igazságod
sok igazság van benne, ha ez érzelmi kérdés volna, akkor lehet, hogy "szívemből szólnál". Azért egy-két dolgot én túlsarkítottnak vélek; talán a hosszabb verzió pontosabb volt, én azt is végigolvastam volna (cikk formájában).
- Az internetet mindig a felhasználóval együtt kell tekinteni. Mert más az, ha egy szoftver nézi az oldalt, és nagyon más, ha ember. Emiatt nem is igen várható a jövőben sem, hogy pl. a lakáshirdetéseddel egyformán elégedett lesz Gugli is és Júzer is.
- A HTML (akárhány) elsősorban szöveges, másodsorban egyéb médiatartalom leírására / megjelenítésére szolgál. És erre elég jól megfelel. A keresők meg ebben a szöveges tartalomban keresnek, nem az (akár egyedi struktúrájú) adatbázisodban. (Be is b.. ugye.) Ez a kettő (mármint a te keresőűrlapod a Gugliéval) soha nem is lesz egyenértékű, ne várd, hogy a Gugli találja meg az eladó lakásodat. Szóval bármennyire is szeretnél, nemigen fogsz tudni olyan megoldást kitalálni, amivel a keresők is igényeidnek megfelelően boldogulnának, és a Júzernek is tetszik.
- Barlangrajz. Azért Kr.e. 3000-ben a Lakatos Józsi még nem tudott a Winettou falára rajzolni... Lehet, hogy neked jobban tetszene, ha csak az adatokat továbbítanánk. Mármint azt, hogy "53 nm", "13 000 000", stb., csicsa-micsák nélkül. Akkor Gugli is megtalálná a kéglit, DE nem böngésző lenne a kliensnél, hanem vmi nagyon furmányos adatbáziskezelő; be lennénk szorítva nagyon szűk adatbázis-szabványokba (adatstruktúrák kötöttek lennének); éhen halna az összes grafikus-frontendes, mert a kliensszoftveren múlna az adatmegjelenítés formája; mi is hamar munka nélkül maradnánk, mert egyszerűbb lenne olyan kliensszoftvereket írni, amivel létre is hozható a webes adatbázis tartalma.
Szóval ilyen nem lesz, mert a piac nem akarja. Addig, amíg szerveroldalon kell adni az adatokhoz a körítést, nem fognak annyira pontosan szerepelni a szöveges keresők. De ez nem is olyan nagy baj.
- A HTML5/CSS3 szerintem is egy nagy zsákutca lett, de arra jó (úgy kb. 15%-a), hogy pár csili-vilit könnyebb megvalósítani benne. Akinek meg régebbi böngészője van, annak nem lesz lekerekítve a div sarka, na és. Én akkor akadok ki, mikor a régebbi böngészőhöz odab...ák még a fél megás js-t, hogy "megtanítsa" HTML5-re. Csak az marad ki a számításból, hogy régi browser általában gyengébb vasat is jelent, és 5 percig 100%-on izzik a proci és / vagy elfogy a RAM, mire lefut a "tanítószkript".
A HTML5/CSS3 szerintem is egy
Szerintem a webfejlesztés nem a csilli-villi megvalósításáról szól. A HTML5 meg végképp nem.
Szó sincs fél megás tanítószkriptekről. Egyetlen "tanítószkriptről" van szó, amit érdemes használni, az pedig alig néhány kilobájt, és nem hogy lassulna, hanem épp hogy gyorsul tőle az oldal, feltéve, hogy a HTML5 lehetőségeit kihasználva hatékonyabban készíted el az oldal szerkezetét. Tudom, teszteltem nagyon régi gépen is. Egyébként ez a tanítószkript helyettesíthető akár egy még rövidebb scripttel is. Mindössze annyit tesz, hogy létrehoz javascriptben egy-egy új objektumot az új html5 tagekből, ezután a böngésző már magától képes kirenderelni. (Tehát a tényleges DOM szerkezetbe ez a script bele sem nyúl) Az olyan dolgokat persze nincs értelme "megtanítani" a régi böngészőknek, mint a canvas, viszont azokon a gépeken, ahol a HTML5 canvas nem működik, ott garantált, hogy a flash is fagyasztja a gépet. Viszont régi gépen új böngészővel még eldöcög a canvas. Tehát ebben a tekintetben sincs visszalépés.
Ha pedig régi böngészőkre akarunk fejleszteni, akkor ne válasszuk a HTML5-öt. Bár hozzáteszem, az Internet Explorer 5.0 elterjedtsége ma már igen csekély...
Szerintem sem
Az alig néhány kB-os szkriptet linkeld be légyszíves, hátha tanulhatok belőle vmi újat. Eddig én nem láttam ilyet.
Itt a script:
3 kilobájt alatt van. Ez lehetővé teszi az összes HTML5 tag használatát az Internet Explorer korai verzióiban is. Viszont ha nincs olyan szemantikus tag az oldaladban, akkor ez a script nem is szükséges az oldal működéséhez. Ha pedig csak néhány tag-re van szükséged, akkor tag-enként is engedélyezheted JavaScriptből, így még gyorsabb.
A flashről: nem egy olyan 306-512 megabájt RAM-os, gyenge processzoros gépet láttam már, amin a Flash fagyasztja az egész oprendszert, míg egy Chrome lazán elviszi a Canvast, elviselhető FPS-el.
Az Internet Explorer 8-ban egyáltalán nincs gond a HTML5-el. Erőfeszítés nélkül megoldható, hogy ugyanolyan szépek legyenek az oldalak, mint a legújabb Chrome-ban. Az IE7-ben egy pár soros conditional comment-be illesztett CSS-re lehet szükséged. IE5.5-IE6 kompatibilitás érdekében én inkább egy alternatív, végletekig leegyszerűsített CSS-t használok, hiszen ahol ilyen böngészőket használnak, általában a gép teljesítménye sincs a toppon, ezért jobb, ha nem terheljük őket mindenféle bonyolult elrendezéssel, és dekoratív képekkel. Ennek további előnye az, hogy nem kell hosszú-hosszú órákat azzal tölteni, hogy az elrendezést megoldjuk külön ezekhez a verziókhoz is. Ráadásul a látogató sem fog káromkodni, hogy használhatatlanul lassú az oldal a gépén. Viszont ha nagyon muszáj IE5.5+-ban megoldható tökéletesen a HTML5 támogatása. A HTML5 video tag esetén érdemes egy Flash vagy egyéb plugin fallbacket használni, és meg is van oldva a támogatottság a számítógépek 99%-án. A mobilokról pedig ne is beszéljünk, ott tulajdonképpen csak a HTML5-öt érdemes használni. (Ha WAP-os támogatottság is szükséges, akkor szükség lesz egy alternatív oldalra is)
Kösz a linket
troll
hogy lett a néhány kilobyte-ból nem egész kB-os?
hol láttad ez, mint dependenciát?
én sehol, és behúzva a fájl minden egyébb nélkül nem dobott hibát, de ennél tovább nem teszteltem.
ha nem találod a csomagban a fájlt, akkor itt az eredeti nem optimalizált/minify-olt verzió, 10kb alatt van még így is.
vs.
a te állításod az volt, hogy a kiváltás bonyolult, és nagy terheket ró a gépre. (btw. szerintem te a komplett modernizr-re gondolsz, amit mindent osszepakolva valoban nagyobb)
szoval ezek utan nem ertem hogy hogyan allithatod a kovetkezo mondatodban, hogy a te velemenyed is az, hogy milyen konnyen kivalthato, plusz feljebb elismered hogy:
innentől kezdve megfordítanám a kérdésedet:
erre:
Ha bizonyos dolgokat egyszerübb megoldani, és ilyen könnyen támogatható a régebbi böngészőkben is, akkor miért ne?
ps: szerintem ennél jóval több előnye van, csak a te álláspontodból érvelek.
Tyrael
Mi ez?
Összességében továbbra is azt állítom, hogy kevés (majdnem semennyi) olyan igazán lényeges dolog nincs a HTML5-ben, amit ne tudnánk a korábbi szabványokkal megoldani. Ráadásul "szét is szakadt", nem valószínű, hogy valaha is tényleges szabvány lesz belőle. Emiatt - én - nem szívesen használom, mert azért minek használjak új tag-eket, stb., hogy tehessem melléjük a különböző js-eket?
Szakmailag minden tiszteletem a tiéd, de ha ezért a véleményemért trollnak nevezel - hát akkor magadat minősítetted, de rendesen. Nem először van olyan érzésem, hogy kipécézel és belém kötsz. Jó lenne most már valami okot is megtudnom, ha így van.
Mivel emberi tulajdonságok terén eléggé optimista vagyok, én még próbálom feltételezni, hogy pusztán összekeverted, mit is értek (és hol) hasznosságon ill. kiválthatóságon.
a szemelyeskedest szerintem
Ha elengedhetetlen hozzá a jQuery 1.7.x, akkor ...
Ott a Ha, valamint írtam azt is, hogy csak belenéztem, nem volt rá több időm, nem teszteltem, stb.
de hogy merult fel a jquery?
vagy miert pont a jquery?
ha nem tesztelted, nem neztel utana, akkor miert feltetelezed, hogy megis valotlant allit a vitapartnered azzal, hogy osszvissz nehany kilobyte kodot kell hozzaadni a boldogsaghoz?
azzal hogy bedobtad ezt a jquery-es kerdest pontosan ezt tetted, kiegeszitve azzal hogy nem tesztelted, ezaltal kimentve magad a kesobbi tevedes tenye alol, de a gyanutlan olvasoban meg is azt az erzetet keltve, hogy volt valami okod feltenni ezt a kerdest.
ebben ezek szerint elter a velemenyunk.
Mire alapozod, ezt? Pont a napokban jött egy ilyen nyilatkozat amiben mar joval kozelebbi datum szerepel a "szabvany" eletbelepesere, plusz megoldast kinal az erosen jelenlevo feature-creep-re is.
Ha semmit nem használsz ki belőle, akkor valóban felesleges. De a kérdésed második fele kicsit olyan, mintha az alpha channel png-k létjogosultságát vitatnád azzal az érvvel, hogy IE6ban AlphaImageLoader-t kell hozzá használni.
viszonylag ritkán szólok hozzá, ha nem először válaszolok a te hozzászólásodra, annak biztos van valami oka, de biztosíthatlak róla, hogy nem "pécéztelek" ki. :)
Tyrael
Hagyjuk
Én nem irányítottam senki ellenében a hozzászólásaimat, leírtam a véleményemet, plusz az aggályaimat. Talán ez nem tilos. A "gyanútlan olvasó" dolga, hogy Ő mit gondol. Látszik, hogy ebben a témában a többség (veled együtt) "tolja a HTML5 szekerét", hát én nem. Te sokkal inkább próbálod/próbáltad befolyásolni a "gyanútlan olvasókat", mint én, bár lehet, hogy ez nem volt szándékos.
De ezt a fajta kötözködést én nem kívánom folytatni.
sajnalom, ha ezt
a troll szocska azert kerult bele, mert nagyon nem szeretem, mikor valaki ervelestechnikai hibakat hasznalva probalja hamisnak beallitani a vitapartnere allaspontjat.
azzal hogy a kilobyte-okon lovagoltal, majd a fel mega vs nehany kilobyte-ba belekotottel hogy nincs 1kB alatt a meret, es feltettel egy loaded questiont amivel azt sugaltad, hogy a jquery-re szukseg van a lib mukodesehez.
ehelyett csak annyit kellett volna tenned, hogy kiprobalod (vagy elhiszed bemondasra), hogy van ilyen nehany kilobyte-os script, es elismered, hogy a hozzaszolasod azon resze teves volt.
szerintem.
Tyrael
script méretek
Modernizr 2.6.2
jQuery 1.8.2
Ez összesen 50,51kb ez elég messze van azért a fél megától. Ha az ember használ modernizr-t akkor pedig nincs szükség a HTML5shiv-re sem.
A linkelt Modernizr minden komponenst tartalmaz, ebből ha kidobálod, amire neked nincs szükséged, akkor sok-sok kb-ot meg lehet spórolni
Tiltakozás!
Érdeklődés
Az is valami?
Csak civilizáltan, ha
Félreérted
Már-már sztrájkhangulatot sugallt, ezért javasoltam komolyabb böjtöt. (Megelőzendő, nehogy a fórumozást szüneteltesse. :))
Szerk.: számomra az lenne igazán horrorisztikus, ha a WL-ről szoknék le egy-két hétig. (Persze biztos van itt néhány ember, aki szívesen venné...)
Végigolvasva a cikket és a
Azt felhozni, hogy tudok olyan a tudomány jelenlegi állása szerint a számítógép számára értelmezhetetlen keresési kérést feltenni, amire hülye választ ad, kevés kiinduló alap egy bejegyzéshez. A fentieket átolvasva nekem az ugrott be, hogy szegény html5-ön és a böngészőkön van elverve a mesterséges intelligencia jelenlegi fejlettsége, vagy inkább fejletlensége :) A keresők akkor tudnak jó eredményt adni, ha a kereső (személy) tudja mit keres, és képes ezt meg is fogalmazni a gép számára érthetően (valaki helyesen rávilágított az adat és információ közti különbségre). De a gép nem ember, egy számunkra feloldható és ráadásul különböző emberi nyelveken leírható (a gépek jelenleg nem képesek jól fordítani, tehát nem értik a nyelveket) bonyolult összefüggést nem képes jól kiértékelni. Az ingatlanos keresés pedig bonyolult, mert tudnia kell, hogy mi az a lakás, mik a méretei, hol helyezkedik el, mennyibe kerül, milyen nyelven tettük fel a kérdést stb. Ebből találati eredményt generálni pedig intelligencia kérdése, nem a feldolgozott adatoké, nem az azokat leíró nyelvé (érdekes kérdés az is, hogy a html adattároló, vagy két ember közötti információátadó nyelv-e), legyenek azok akárhogy is leírva. Azt azért észre kell venni, hogy egy keresésben mi a szerepe a számítógépnek, és mi az embernek.
Ettől függetlenül érdemes a keresőket segíteni megfelelő meta tagekkel és egyebekkel, de a lehetőségek eléggé korlátozottak, és azok is maradnak. Tehát a megfogalmazott probléma és a html5 nyelv között én igencsak értelmezhetetlennek tartom a kapcsolatot.
Röviden
Jó lenne, ha mindenki rendszerben próbálna meg gondolkozni, és nem kritika nélkül fogadná el azt, amit elé raknak. Senki nem mondta azt, hogy 1, köszönjük, de ebből nem kérünk, mert az ügyfelünknek nem tudunk ettől jobb szolgáltatást nyújtani, 2, ha már megint különutakon jártok a schema.org-gal (mert ugye már voltak korábban kidolgozott szemantikus leírónyelvek), akkor legalább dolgozzatok gyorsan, mert tavaly augusztus óta nem kerültek fel új sémák.
Hogy megoldható valahogy
Másrészt meg értem, hogy a böngészőgyártók a csilivili dolgokra kezdtek el gyúrni, de ez miért gátolná meg őket abban, hogy a fontos dolgokkal foglalkozzanak? A látványos, meg a hasznos dolgok nem állnak szemben egymással. A böngészőgyártók is a web fejlődésében érdekeltek, így ezt a gondolatmenetet továbbra sem értem.
És azért szerintem fejlődött egy keveset a web 99 óta :)
Másrészt meg értem, hogy a
Akkor asszem most húztad át
Indokold
Olvasd el HG hozzászólását
És?
Bocs, ha erősen fogalmaztam legutóbb, de nekem kötözködésnek (v. kötöszködésnek?) tűnt.
Nem az
Kizárja?
Igaz
Jó lenne, ha mindenki
Azért az sem ártana, ha tisztában lennék az MI fejlesztés jelenlegi szintjével, akkor legalábbis talán nem támasztanánk irreális elvárásokat.
Az pedig hogy a schema.org -os meta adat nem része a html core szabványnak pontosan azért jó, mert a kettő egymástól függetlenül bővíthető-alakítható. Ha valamivel bővítenék az adat listát, akkor esetleg nem kell addig várnod rá, míg a vének tanácsa összeül, és hosszú évek alatt összepatkol belőle egy html6-ot. Lehet persze azon szomorkodni, hogy lassú a schema.org bővítése, de akkor ezt így rögtön emelhetnéd négyzetre, ha még a w3c tüttyögne rajta.
Az eredeti felvetéssel az a gondom, hogy a megjelnítés teljesen független a szemantikus leíró adattól, így baromira nem lennénk beljebb semmivel, ha nem tolnák a html5+css3 szekerét. A leíró adatok a kereső motorokra tartoznak, a megjelenítendő tartalom pedig a böngészőkre, a kettő között nulla a kapcsolat. A böngésző fejlesztők nem biztos hogy a rengeteg felszabadult idejüket azzal töltenék, hogy keresőmotort csiszolgatnak, szóval nem igazán tudom hova tenni, hogy miért lenne a helyzet bármivel is jobb.
Azért az sem ártana, ha
Ha elkezdünk a dizájndolgokkal foglalkozni, akkor nincs elég erőforrás a metaadatokkal való munkára, mint ez jelenleg látható. Most mindenki az animációkkal, a <header>-ekkel és a box-shadow-kkal van elfoglalva. Elvileg nem zárják ki egymást, gyakorlatilag viszont igen.
Pont ez a baj
A böngésző mit kezdene a
A böngésző semmit
Asszem akörül lenne a jó megoldás, ha te és Gábor "megegyeznétek". T.i. a kereső leginkább a tartalommal foglalkozzon, a látogató pedig "pótolja ki" azt az "IQ-t", ami a keresőből hiányzik. Persze nincs kecske-káposzta IT-ben sem, úgyhogy közelíteni kell egymáshoz ezeket a sarokpontokat.
A jelenlegi helyzet az, amit
Mindenesetre az érzésem szerint egészen biztos, hogy a böngészők feature fejlesztésének semmi köze a html és a keresők kapcsolatához.
Túlzás
Köszönöm, hogy érdemben
1, 2000-ben az XHTML-lel alapozták meg, hogy az adatokat meg tudjuk jelölni a HTML dokumentumunkon belül, azaz szemantikus információt is adhassunk át (az első RDF specifikáció 1999-ben készült)
2, a HTML 5-tel 2004-ben kezdtek el foglalkozni, a W3C 2007-ben
3, a Microdata első specifikációja 2009-ben jelent meg
4, a schema.org 2011 június elején indult el
Az egyik korábbi hozzászólásomban pedig linkeltem statisztikákat, amiben látszik, hogy a Microdata elterjedése 1% alatti, a HTML5-é 10% fölötti. Ez alapján látom úgy, hogy bár elvileg nem zárják ki egymást, gyakorlatilag pedig mégis. Ha lenne rá igény, akkor gőzerővel azon dolgoznának, hogy vegyék fel az új elemeket a listába.
Kemény...
Csak azt sajnálom, hogy itt is igaz a mondás:
bevert fej
Lásd még Tas vezér vs. Ond...
Tévedés! :)
HZ: Szerintem Tass. És - ha jól tudom - nem valószínű, hogy volt baseballütőjük... :)
Ennél hitelesebb forrást nem
És Tas vezérnek volt egy (funkcióját tekintve) baseball ütőre hasonlító buzogánya! ;-)
Hozzá akarok szólni
1. Az XHTML 1.1-et nagyon szerettem. Megtanított strict kódot írni. De voltak dolgok, amiket hiányoltam kezdteben, aztán megszoktam a hiányukat (pl.: target="_blank").
2. Az XHTML 2-höz nagy reményeket fűztem, különösen az <object type="image/jpeg" src="..."> tag-hez, ami az <img src="..."> helyett lett volna. Vagyis minden kép, hang, videó, flash stb <object> tag-be került volna. Dugába dőlt terv, kár érte.
3. A HTML5-tel szemben kezdetben elutasító voltam, mert hőn szeretett XHTML-emet gyilkolta le. Aztán megtetszett. Tetszett, hogy kevesebbet kell írni ugyanazért. Még jobban fog tetszeni, ha minden böngésző fogja rendesen támogatni minden elemét. Ebben érzem a hibát, hogy néhány viszkető tenyerű cég/fejlesztő által ráerőszakolt népszerűsége miatt felemás a támogatottsága. Pedig vannak benne jó dolgok. A HTML5 Form tipikusan ilyen. Régóta hiányzott már, és nagy szükség van natív form elemekre és nem JavaScripttel összerakott ilyen-olyan megoldásokra (pl.: slide, range, email, phone kliens oldali regepx validálással). Tetszene még a <video> elem is, de azzal sincs minden rendben. Ez az egész HTML5 jó lenne, ha kész lenne, vagyis ha minden böngésző egységesen támogatná. De tetszenek a <section> és <article> elemek is. Ha már egyszer információközlés a cél, ez így tényleg sokkal szemléletesebb egy sima <div>-nél.
4. A CSS3 nagyszerű újdonságokat hozott. De a CSS2.1 is tele van jó dolgokkal. Most nem mindenről tudom, hogy melyik-melyikben deklarálódott, ezért úgy mondom inkább, hogy a CSS nagyszerű. És nem a lekerekítésre gondolok meg a transition és a transform csodákra, mert ezek szerintem csak mind parasztvakításra jók. Max az n+1. dologként lett volna szabad megvalósulniuk.
Ellenben az információközlés hatékonyságát szem előtt tartva:
- a @font-face rendes támogatottsága már réges-régen megvalósulhatott volna, és akkor nem kellett volna Flash replace-ekkel görcsölni. Nem minden esetben jó a beépített szűk betűkészlet. Gondoljunk csak egy "egyszerű" intergál számításos egyenletre. Milyen jól jött volna az egyetemen, ha a netről csak egy sima copy-paste kellett volna a jegyzethez, és nem a jpg-kről kellett volna lemásolni az egészet. Vagy, ha valami irodalom rajongó szaki csinálna pl. egy "AdyHandScript.ttf"-et, milyen érdekes lenne úgy olvasni a verseit... Vagy akármi másra is jó.
- a CSS counter-ek is elég alapvető elemei kellettek volna legyenek az alap specifikációnak. Most már van, használható:
- a CSS multi-column-layout. Ezt viszont milliárdszor fontosabbnak és hasznosabbnak érzem, mint pl. a lekerekítést. Egyre változatosabbak a kijelzők, mind méretre, mind felbontásra. Egy 24"-os 16:9-es monitoron a legtöbb weboldal már élvezhetetlen, mert vagy egy kb 900px széles sávot látsz, és 1020 pixelen a nagy semmit, vagy teljes szélességben elterülő, olvashatatlanná váló szöveget. Mindezeken segítene a hasábos megjelenés. Nem hiába használják az újságok és a lexikonok ezt a megjelenést időtlen idők óta. Alapvető szükség lenne rá, eléggé megosztott a támogatottsága.
És ez csak pár dolog volt.
5. Ami a régi böngészőket illeti. Nem érv az, hogy sokaknak még XP van a gépén, amin csak IE8 van. Igen is, a fejlesztők kezében az eszköz, hogy rávezessék az embereket, hogy merjenek tovább lépni. XP-re van Chrome, Opera és Firefox is. Nem áll meg az élet. Kell készíteni step-by-step leírásokat, hogyan kell áttérni fájdalommentesen. Mindenki számára jobb:
- a felhasználó gazdagabb élményekhez juthat, nem beszélve arról, hogy akár gyorsabb is lesz a böngészés.
- a fejlesztőnek sokkal kevesebb idő összeállítani egy leírást, hogy hogyan kell felrakni egy új böngészőt, mint évekig toldozni-foltozni a kompatibilitás miatt.
Ok, erre szokott jönni, hogy dehát ahol nem lehet telepíteni. Ezek a cégek. Ahol főleg az intranet az úr, és nem nézik jó szemmel, sőt tiltják a külső netezést. Az intranetet meg rendszerint arra a böngészőre írták meg, ami a cégben van. Ha a cég böngészőt vált, intranetet is fog váltani, ami már fel lesz készítve a szabványosságra (remélhetőleg).
6. Hogy ki miatt nem fejlődik a web? Senki miatt. A web fejlődik. Ami tegnap csak javascripttel ment, ma már natívan.
rengetegen használnak még
Ezt úgy írod, mintha az Internet Explorer lenne az egyetlen böngésző, és nem is lehetne mást feltenni XP-re. Körülbelül két kattintás egy böngésző telepítése, ha meg olyan problémáim lennének, hogy egy projekthez valami html5 újítást akarok használni, amit nem visz msie8, akkor csuklóból kitennék egy olyan oldalt, hogy "elavult a böngésződ, válassz ezek közül másikat".
Ajánlom figyelmedbe ezt a
Ácsi
1. Ha céges szinten nem szabad netezni, mert intranet van és az IE6-ra lett megírva, ezért IE6 van mindenhol és ennek ellenére akar az alkalmazott netezni, akkor az egy balf...aszondják rá, hogy csúnya dolog, ne csinálja azt, amit nem szabad, hanem dolgozzon.
2. Ha céges szinten szabad netezni, és van intranet és az IE6-ra lett megírva és csak IE6 van a gépen, akkor a vezetés egy balf...aszondják rá, hogy nem ért hozzá, mert akkor IE6 legyen intranet és minden más letiltva benne, mert lyukas, mint a kölségvetés és legyen egy alternatíva, amivel tudnak netezni biztonságosan. Csakhát lusták, mert rámenne akár egy szombat-vasárnap is, hogy 1000 gépre központilag felrakják, meg házirendet állítsanak, meg a többi urban legend ugyebár. Kifogás-nyafogás.
3. Ha céges szinten szabad netezni, de nincs intranet, akkor meg balf...aszondják, hogy Jóskák ülnek a cégnél, mert mire várnak? Ha aggály van a Chrome-mal kapcsolatban, akkor van Firefox, ha az se jó, akkor Opera. Innentől kezdve minden csak kifogás-nyafogás megint.
+1 ha nem szabad netezni és nincs intranet se, akkor meg nem mindegy mi van a gépen? Lehet, hogy gép sincsen, vagy épp Zetornak hívják.
Ennyi.
A kettes ponttal kapcsolatban
Valószínűleg régi vasak, emiatt elképzelhető, hogy XP-nél régebbi operációs rendszer fut rajtuk. Az egyik blogon volt egy bejegyzés erről, de sajnos most nem érhető el, és az archívumban sem találom. Hidd el, sok helyen nem véletlenül nem cserélik le a szoftvert, és nem azért, mert annyira laikusok lennének.
Rendszergazda
Windows-on nulla
Ha szakemberek által összerakott hálózatod van, akkor önmagában a telepítés nem okozhat gondot.
Persze ha arra célzol, hogy mi munka előzi meg a cserét, az más téma. Mert az előkészítés az valóban rengeteg munkát jelent(het).
ui: az az "egyik" blog nem a NOPblog volt véletlenül?
(alias 0x90.freeblog.hu)
NOPblog
Tegnap még ment, ma reggel
update: megint működik.
Nyilván túloztam
És ha azt vesszük, hogy a különböző statisztikák szerint az IE9+Chrome+Safari+Firefox+Opera 80%-nál jár és a "régi" böngészők 20%-on, akkor meg merem kockáztatni, hogy 5-10% még mindig áttéríthető a régiről az újakra megfelelő tájékoztatással és leírásokkal.
Ha mégse, akkor az a 20% sajnos így járt:
1. a cég vagy belátja, hogy fejlődni kell és kész, vagy lemarad. (2-3%)
2. az alkalmazott majd nem munkaidőben fogja a céges gépről olvasni a netet, hanem otthon. (5-10%)
és máris 90% fölött járunk.
És aki ennek ellenére kimarad, azt sajnálom. Az én kedvemért se fognak többé gyártani 1974-es Ford Grand Torino-t, piros színben fehér sport csíkkal, szirénával, és még csak hivatalos supportot se kapok, ha mégis sikerül szereznem egyet. Vannak lelkes támogatók, akik egymást közt adnak-vesznek-cserélnek, de a '74-es Grand Torino a múlté. Mint ahogy az IE8 és elődei is... És ahogy majd az IE9 is elavult lesz egyszer.
Értem én a koncepciót, amit szeretnél elérni, de nem tartható. Ha a jelenlegi irány rossz, úgyis meg fog változni. Ha meg csak érezzük, hogy nem jó és puffogunk róla, de tulajdonképpen a tömegek által mégis támogatva lesz, akkor ez lesz és kész.
Félve merem megkérdezni: nézted az Olimpiát? És utána nézted a Paralimpiát? Durva és csúnya párhuzam, de szemléletes. Ha a 100m-es síkfutásra vagy kíváncsi, nem a mű végtagosokat fogod nézni.
Ha van rá igény, támogassuk a régi böngészőket. Hajrá! Legyen. De amíg én a magam számára megelégszek a 80%-kal, addig nem fogok időt fecsérelni rájuk. Ha a böngésző képes a nem értelmezhető HTML5 tageket <DIV>-ként reprezentálni és az ismeretlen CSS definíciókat figyelmen kívül hagyni, addig az információt meg fogja kapni. Tőlem legalábbis. (Nézd meg az oldalamat IE8-ban és IE9-ben.
Élmény vesztés van, információ vesztés nincs. És ez a lényeg. Ha valahol felróható felelősség, akkor az ebben van. Mindent úgy kell megcsinálni, hogy CSS és JS nélkül is olvasható legyen minden szöveg, látható legyen minden információ tartalmú kép, és működjön minden form.
Félreérted
Milyen fejlesztést igényel a
Semmilyet
Akkor milyen erőforrásokat
Az összeset
Kizárja? Vagy csak munkaórát
Szerintem abban a szálban sem válaszoltál a kérdésre. A böngészőket (megjelenítés) és a keresőket (szemantika) különböző csapatok fejlesztik, miért vonna el erőforrást utóbbitól az előbbi?
Azt hittem, hogy a
Tehát nem a böngészők a
Melyik volt előbb, a tyúk
Hogyan kellene a
A kérdésedre később fogok
[OFF] A tojás
Tojásrakó állatok már sokkal előbb léteztek, mint tollal rendelkező szárnyas lények, így kijelenthető, hogy az az állat, amiből a tyúk kifejlődött szintén tojásrakó volt. Ebből következik, hogy a tojásnak előbb kellett léteznie, mint a tyúknak.
Ha viszont a kérdés úgy hangzik, hogy tyúk, vagy tyúktojás? Nos akkor a válasz megfordul, mert az első tyúktojást már egy tyúknak kellett raknia, de amikor a mutációk révén kikelt a történelem legelső tyúkja, azt a tojást, amiből kikelt még egy "épp-nem-tyúk" rakta vagyis a tojás sem tekinthető tyúktojásnak. Bár valószínűleg kísértetiesen hasonlított rá, de szemantikailag nem helytálló.
[/OFF]
Kifogás
Nem ez a kifogás
De mi zárja ki, hogy egy másik böngészőt is felrakjanak a gépekre? Ahhoz nem kell windows update (jó esetben)... Rakjon fel Firefoxot IE view pluginnel, és akkor csak egy gombnyomás lesz a váltás, ha IE kell. Vannak viszonylag fájdalommentes megoldások.
Teljesen fájdalommentes nincs. A nem-átállás sem fájdalommentes, mert egy idő után elfogynak az oldalak, amiket még tud vinni a régi böngésző.
Mellékszál
</trollface>
Ps: meglepően tapasztalom a felhasználók böngészővel kapcsolatos felvilágosultságát, az ilyen ütemű piaci átrendeződéshez nem csak az otthoni felhasználóknak, hanem a céges usereknek is böngészőt kellett váltani.
jReject
Nocsak, vegre valaki itt is
Beszelunk itt webalkalmazasokrol meg szemantikus webrol meg sok egyeb jol hangzo kifejezesekrol, viszont egy alapveto problema nincs megoldva: a megjelenites es az adatok szetvalasztasa. Az, hogy HTML - dokumentum, JS - mukodes, CSS - megjelenites az bullshit. Aki ezt elhiszi az nem kodolt meg komolyabb oldalt vagy webalkalmazast. Mindaddig, ameddig egy helyen van egy oldal szerkezetenek es a dokumentum leirasa (sot: tobb kisebb reszdokumentum), addig felesleges tovabbmenni. CSS-sel nem irhato le minden. Teny, hogy egyszerusodik, de meg messze vagyunk attol.
Pl. akarunk egy ikonnal ellatott gombot letrehozni, amelyhez tartozik kisebb mennyisegu leiroszoveg is. Lehet trukkozni de a vege az lesz, hogy mindenfele elembol letrehozok egy valamekkora HTML kodot. Miert? Miert nem csak annyi van ott, hogy van egy gombom es minden egyeb design beli elem elkulonitve? Vagy nezzunk egy gmailt. Ott gyakorlatilag nem csinalunk mast, mint egy HTML dokumentumot modositgatunk orrba-szajba ahelyett, hogy szetrobbantanank komponensekre, mint ahogy mar tobb tiz eve teszik mas normalis programozasi nyelvekhez keszult GUI Toolkitek. Csak a HTML ilyen agyhalott koncepcio, hogy egybebarmol mindent.
Egyebkent lett volna erre is megoldas, XML+XSLT, csak ugye a modern "szabvanykoveto" bongeszok is alig-alig tamogattak jol. Probalt mar valaki DTD-t betolni XHTML-hez? (Arrol meg ne is beszeljunk, hogy az "irjunk le mindent XML-ben mania miatt az XSLT egy korulmenyesen hasznahatlo valami.)
Igaza van a cikk szerzojenek: jelenleg a csicsarol szol minden, magarol a lenyegrol meg semmi. Es ez mindaddig igy is fog mukodni, ameddig hatra nem lepunk ket lepest (legalabb annyira, hogy lassunk picit tul is a webes okorsegeken) es feltesszuk a kerdest, hogy jo-e az irany.
Megoldás?
Persze, el kéne különíteni az adatokat, de hogyan?
Szerintem amíg dinamikus oldalról beszélünk és még nem webalkalmazásról, addig jó a HTML, de felesleges az 5. De az (is), hogy hol van a határ a dinamikus oldal és a webapp. között, erősen szubjektív.
És az elkülönített adatokkal egyidőben felmerül a keresők problémája is: ezek hogyan fognak boldogulni? Sokkal "okosabbak" lesznek / lehetnek, vagy "butábbak"? Nem elhanyagolhatók, főként azért, mert kb. mi is "tőlük függünk".
Azért ez egy kicsit túlzás, még egy lefordított desktop app.-ben is van néhány(ezer) bájt a left, top, image, stb. tulajdonságokról. Sőt, sok esetben maga a kép is a bájtkód része. Természetesen - jó esetben - nem a (program) forráskódodat kell vele teleszemetelned. De ez pont olyan dolog, ami teljesen el is fér a CSS-ben, kb. semmi köze a HTML-hez.
Tanuljunk a meglévő technológiákból
Első lépésként külön kellene választani az adatot, és bevezetném az adatforrások fogalmát. Egy ilyen adatforrás lehetne pl. egy cikklista, ajánlólista, stb. Formátumban lehetne pl. JSON, XML, SOAP kérés, akármi, lényeg az, hogy objektumokat le lehessen írni vele és jól definiálható legyen, hogy milyen mezőik vannak az adott adatnak. Másrészt ezek a szerkezetek lehetnek akár globálisan előre meghatározottak, mint mondjuk egy osztálykönyvtár egy adott nyelvben.
Pl. Ezen oldalhoz tartozna egy cikk (cím, szerző, szöveg, stb.). Külön adatforrásokban megadható kommentek, blogmarkok, amik oldalra tartoznak, stb. Egy-egy objektumhoz (nem kötelező jelleggel) megadható megjelenítést leíró template.
Gyakorlatilag ez a template maradna az, amit mi HTML-ként ismerünk. Utána ebben lehetne megadni (akár CSS-sel, akár a CSS beolvasztásával) magát a szerkezetet, megjelenést, stb. Viszont ami nagy különbség lenne, hogy mondjuk egy táblázatnál mi csak egy objektum-halmot kapunk, a HTML-ben meg csak mondjuk a fejléc-sor-lábléc, stb. szerepelne minden egyéb az adatforráshoz lenne bindelve. Persze, maga a template behúzhat más adatforrásokat is (pl. cikkhez tartozó kommenteket a cikk komment adatforrásából.)
Ezen kívül bevezetném még a komponens fogalmát. Ezt gyk. úgy kellene elképzelni, hogy lehetne definiálni saját tageket, saját attributumokkal, amihez lehet önálló templatet készíteni. (Vagy meglévőt módosítani.) Tfh. egy webes Office 2010 ribbont akarunk összerakni, akkor csak definiáljuk azt, hogy van szalag (fejléc attributum), gomb (ikon, szöveg attributum, esemény), csoport (fejléc attributum). Az, hogy n+1 div, háttér, etc. kell ahhoz, hogy összeálljon a végleges kimenet, az már a templaten múlik.
--
Ezek amúgy nem új ötletek, részben XUL, részben XAML/WPF, részben XSLT, sőt, ez az adatforrásos cucc mintha szerepelt is volna itt valami ActiveX bővítményként, hogy ilyen van az IE-ben. Na meg részben MVC, MVVM patternek alkalmazása magára a weblapra. Vagy említhetném a mindenféle komponensalapú RAD eszközöket, pl. Delphi VCL, WinForms, Qt, WPF... Arról nem is beszélve, hogy egy része valójában nem más, mint amit különféle nyelveken/keretrendszerekben mindenféle cifra módon csinálunk, de valójában többnyire csak azért, hogy megerőszakoljuk a HTML-t.
Tény, hogy ehhez *nagyon* sok midnent meg kellene bolygatni és a böngészőgyártóknak, keresőgyártóknak, tartalomfejlesztőknek is alkalmazkodnia kellene. (Vagy jobban belegondolva, akár még request-response HTTP protokolt is hozzá lehetne csaplni.)
Viszont most így mindezt leírva én továbbmennék egyel a szerzőnél: a HTML (és a HTTP) miatt nem fejlődik a web.
Majdnem
Viszont ezzel a megoldással az a gond (sok előnye mellett), hogy az egyedi komponensek miatt megtöbbszörözheti a szükséges forgalmat, ha a kliensnél még nincs (pl. cache-ben) meg a komponens. Sok komponens - sok adat, plusz még a böngészőknek is egész másképp kell működni. Akkor már több értelme volna vmi lefordított (Java, .net) alkalmazást "on the fly" beküldeni RAM-ba, aztán használhatja. De ez sem jó, ill. sok mellékproblémát magára húz.
Mindegy, én ehhez "KisMiska vagyok", de köszönöm, hogy leírtad, így többen is gondolkodtunk rajta.
Nem lehet meguszni
Masik megkozelitesben viszont mivel pl. egy cikk eseten a keret az fix es csak a tartalom kulonbozik, szerintem osszessegeben pont, hogy csokkenne, mivel, ha megnyitunk egy uj cikket, csak a cikk tartalmat kell letolteni a keretet mar nem. Egyszer persze mindent le kell tolteni, de szerintem ezzel erveni olyan, mintha azt mondanank, hogy ne hasznaljunk CSS-t, mert azt is le kell tolteni.
Delphi VCL-t amolyan "elso" jellege miatt emlitettem. Fenykoraban szerintem kozismert, elterjedt es egyebkent jo eszkoz volt. Ma mar persze vannak nala jobb eszkozok is.
És a cache?
Az egyedi komponensednek pedig sokkal több letöltendő adata van, mint egy szabványosnak. Gondolj csak egy input mezőre: ha semmi hátteret-keretet-stb-t nem állítgatsz neki, akkor is megjelenik.
<input name="valami" type="text" />
Ha jól számolom, ez 35 + 1 (\n) bájt. Ha variálsz rajta pl. CSS-el, akkor lehet 100-150. Ha viszont egy "tökegyedi" vezérlőt akarsz küldeni eseménykezelőkkel, stb, akkor nem úszod meg 2k alatt.
De tényleg jó lenne saját komponensekkel játszani (Delphi VCL-ben is szerettem), csak (nekem) gőzőm sincs, hogy ezt hogy lehetne jól csinálni. (Az ActiveX is inkább csapda volt.)
A Microsoftnak tizennégy éve
Így van
Az XML + XSLT kombó minden szempontból jobb választás, mert a két fenti problémát helyből megoldja, de a kimenete lehet akár strukturálatlan HTML is. Az XHTML-t a magam részéről pont a DTD-k miatt rossz próbálkozásnak tartom (a problémafelvetés jó volt!), mert a felhasználóra hárít egy meglehetősen bonyolult feladatot, valamint a végeredménye egy adattárolás szempontjából szétszabdalt web (mert mindenki saját DTD-t gyárt).
Az adatok szétválasztása kimerül jelenleg abban, amikor egy weboldal AJAX-on keresztül JSON formában küldi az adatait, amivel a keresők mit sem tudnak kezdeni. Egy XML-hez képest a JSON amúgy is visszalépés, hisz az elemeknek csak gyermekei lehetnek, attribútumai nem, és nincs hozzá XSLT, azaz macerás dolog más formába önteni az adatokat.
Aki ezt elhiszi az nem kodolt
Szerintem inkabb csak az van, hogy bar szerintem mar megvannak az eszkozok ahhoz, hogy a kliens oldalon is lehessen multi-tier felepitest letrehozni, az atlag fejleszto nem all azon a szinten, hogy ezzel a lehetoseggel eljen, es megrendeloi oldalon is meg csak most kezd megjelenni az igeny a fenttarthato/karbantarthato alkalmazasokra.
innentol kezdve a tobbseg beleragad a szutyokba, es nem tesz plusz erofesziteseket azert hogy jobb megoldast adjon, mint a megrendelo altal elvart minimum.
igen, jo esetben egy a/button taget meg bele a szovegnek egy spant
ez egy jo kerdes, miert nem igy csinalod? pont ez lenne a lenyege az altalad hianyolt adat/megjelenes/mukodes szeparacionak.
pontosan itt mire gondolsz?
viszonylag kevesen vagyunk itt jelentosebb ralatassal a google mail webfeluletenek a mukodeseben, de egy gyors rapillantas utan ugy latom, hogy ajaxxal folyamatosan pollolja az ertesiteseket, plusz kulon prefetcheli a leveleket, plusz kulon keri le a tag adatokat, plusz kulon keri le a levelek elonezeti adatait, plusz kulon widget a reklamfeluletek kezelese, etc.
mindekozben az oldalon beluli navigacio nem igenyel aktiv internetkapcsolatot, amennyiben a kert eroforras mar prefetchelve lett, akkor azt siman megnyitja, es a halozati kapcsolag megszakadasat is egesz szepen kezelik (fent megjelenik az ertesites, es a visszaszamlalas a kovetkezo kapcsolodasi kiserletig).
az hogy a vegen mindebbol egy html kod keszul (amit idonkent modositanak a kivaltott esemenyek), az a web sajatossaga, nem pedig a gmail hibaja.
gondolom itt most az asztali alkalmazasokkal allitod szembe a html-t.
mint mar mondtam, a webre is lehet spagetti kodot irni (es ennek eleg nagy hagyomanya is van), de ugyanigy lehet spagetti asztali alkalmazast is irni.
(de a kedvencem, amikor a desktop .net koderek keszitenek asztali alkalmazast, ugy hogy fogalmuk sincs a web mukodeserol, es meg a fejlesztokornyezet is megprobalja elhitetni veluk, hogy ezt megismerni nincs is szuksegunk, mert o mindent megcsinal helyettuk.)
jo dolog az, nekem csak az a problemam vele, hogy nem eleg dinamikus az en izlesemnek.
de hirtelen nem latom, hogy ez hogy segitene az itt felsorolt probleman.
tehat pl. az altalad emlitett gmail-en hogyan segitene ha az outputot xml+xslt segitsegevel generalnad?
en szemely szerint nem latom akkorana a problemat, a web jobbara organikusan fejlodik, es az ajanlasok is a felmerulo igenyekre/problemakra valaszul szuletnek.
nem hiszek benne, hogy jobb lenne, hogy ha akademikusok az elefantcsont toronybol mondanak meg, hogy merre menjen a web, es mindenkinek ugy kellene csinalni.
azert kap a csicsa jelenleg, mert a megrendelot, atlag felhasznalot ez erdekli kozvetlenul.
mindket csoport magasrol tesz ra, hogy mennyire szemantikus vagy szep html-t generalsz, mindaddig amig szepen nez ki a bongeszoben (illetve a megrendelot meg erdekli a SEO, de neki ez csak annyit jelent, hogy elso akar lenni a google-ban a költöztetés szora).
akit ez erdekel az kb. a vakok/gyengen latok, es azok a fejlesztok, akik valamilyen okbol kifolyolag ertelmezni szeretnek a weben fellelheto informaciot.
ez a felhasznalas kozvetve hasznos lehet az atlag felhasznalonak/megrendelonek, de ezt magatol nem kepes felismerni ("Any sufficiently advanced technology is indistinguishable from magic.").
Tyrael
azert kap a csicsa jelenleg,
Egy vállalkozó sosem egyszerűen csak költöztet, hanem annak van helye, ideje, ára, sebessége, költöztethető mennyisége, határideje, megbízhatósága. Ezek mindegyike érdekli azokat, akik a szolgáltatást szeretnék igénybevenni, de jelenleg nem lehetséges, és a vállalkozó azt hiszi, hogy nem is lehet megoldani. Ezért nem kéri tőled, és inkább az animációktól reméli a megváltást. De ha te mint webfejlesztő sem foglalkozol a problémával, nem teszel fel kérdéseket és kéréseket szakmai fórumokon vagy a szabványok készítőinél, akkor sosem lépünk előre.
az atlag fejleszto nem all
Nos, erre azt tudom mondani, hogy hulljon a férgese. Nem kell minden PHPistukának az iparban dolgoznia, annyi sok szép szakma van még. Ha valaki szoftverfejlesztésre adja a fejét, akkor legyen már olyan kedves, hogy megtanulja normálisan azt, amit csinálni akar.
Csak egy példa volt, lehet cifrábbakat is kitalálni. Pl. komplett hozzászólás, komplett szerkesztőablak, stb.
Azért legyünk őszinték, a gmail igen-igen sok helyen megerőszakolja mind a HTML, mind a HTTP protokolt. Lehetne ezt sokkal-sokkal szebben, "tisztább-szárazabb" érzéssel is művelni.
Erről beszélek: ideje lenne ezeket felülvizsgálni. Azzal, hogy mondogatjuk, hogy "ez ilyen", azzal nem jutunk előrébb.
Valamennyire. Sokáig webeztem, de az idők folyamán nagyon kiábrándultam az egész webes fejlesztésből és egyre kevésbé akarok webbel foglalkozni, leginkább azért, mert látom, hogy egyes problémák mennyire nyőgvenyelőssen oldhatóak meg szemben pl. a desktop alkalmazásokkal. (És az ilyen ellenérvek, mint "központilag frissíthető, nem kell telepíteni, etc." pl. egy intranetes rendszernél kb. elenyésző hátrányt okoznak.) De most nem a másikra kell mutogatni, hanem a webről van szó: lenne mit tanulnia a meglévő desktop alkalmazásoktól.
Egyetértek veled: az XSLT eléggé túl van bonyolítva (és nincsenek is hozzá jó eszközök, de kezdetben semmihez nem lesz) és nem elég rugalmas. Ennél amúgy valamivel jobb megoldás a XAML a WPF-ben, bár a template rendszere ott is iszonyúan sok XML kód tud lenni a végére, ha valaki jobban beleássa magát, illetve van néhány nem triviális megoldása. De az irány mindenesetre jó.
Félreérted: nem egy meglévő HTML outputot akarok generálni. Templatezni akarok és a szerkezetet az adatoktól szétválasztani.
Hát... Főnökömtől a Facebookot meg a Pageranket hallom folyton, nem a HTML5-öt meg a CSS3-mat.
Akkor nyilvánvalóan mi vagyunk a hülyék, hogy ezt a spagettikupacot (kiváltképp, mint "alkalmazás" kontextusba emelve) elpusztítandó problémának találjuk. :)
Nos, erre azt tudom mondani,
Hm.
Ha figyelembeveszed, hogy mire valaszoltam itt (" Az, hogy HTML - dokumentum, JS - mukodes, CSS - megjelenites az bullshit. Aki ezt elhiszi az nem kodolt meg komolyabb oldalt vagy webalkalmazast. "), es nem cafolod azt a kijelentesemet, hogy mar most is megvannak az eszkozok, csak az atlag fejleszto nem kepes elni veluk, akkor kijelentheto, hogy te epp ilyen fejleszto vagy, mint akinek itt a palyavaltast tanacsolod?
lehet hogy felreertettelek valahol feluton, legyszives fuss neki megegyszer.
nyilvan lehetne, de, a konkret altalad felvetett pelda megvalosithato egyszeruen, ha pedig elkezdjuk odebb tolni a celt, akkor elofordulhat, hogy mire eljutunk odaig, ami tenyleg nem megvalosithato, ott mar nem is lenne elvaras, hogy az legyen.
Szoval ha szerinted erdemes ezen a vonalon meg vitaznunk, akkor szeretnek latni egy darab konkretumot, amit szerinted nem lehet szepen szetvalasztani html+css+js kombora.
Szerintem az eletszeru igenyek 95+%-a siman megoldhato, maximum azt tudom elkepzelni, hogy nem minden esetben eri meg igy szetszedni a felepitest.
mint irtam nem ismerem elegge a gmail felepiteset(mint szerintem sokan masok sem), ezert ebben a temaban csak akkor tudunk erdemben diskuralni, ha irsz valami konkretumot.
ok, akkor itt ertettelek felre.
tehat te gyakorlatilag kidobnad a http+html kombot, es valami ettol eltero transzport es adatkapcsolati/megjelenitesi protokollt javasolnal.
a http reszevel meg reszben egyet is tudnek (tudtam volna a HTTP pipelining hianyaban) erteni, de markup vonalon jelenleg nem latok olyan alternativat, ami megerne a cserevel jaro pluszkoltsegeket.
tehat igen.
fejleszto szempontbol lehet kenyelmesebb a desktop alkalmazas, hiszen talan picit jobban kontrolalhato a futtato kornyezet (hiszen ugyanott fut, mint ahol a te alkalmazasod, szemben a webbel, ami mindig egy kliens-szerver kornyezetben fut), kivetelt kepeznek persze a desktopon futo szerveralkalmazasok, de gondolom itt most nem ezekrol beszelunk.
nem vagyok meggyozve rola, hogy minden olyan vivmany, ami miatt a desktopfejlesztes kenyelmesebb atemelheto a webrol, pont az eltero felepites miatt.
ha megnezel egy flash player/fms kombot, lehet hogy kenyelmesebben olvad egybe a kliens es a szerver oldal, de meg mindig joval macerasabb, mint egy sima desktop alkalmazas.
es eleg elterjedt is, viszont azert annak is megvan az oka, hogy az MS miert nyit a html(5)+js fele is az alkalmazasfejlesztesben.
igen, kicsit feljebb mar rajottem.
igen, es fogadjunk hogy a project management kapcsan is csak a Scrumrol hallott.
mindig vannak hypeolt trendek, amiknek vagy van, vagy nincs koze a tenyleges arbevetelhez.
lehet hogy a HTML5-rol, meg a CSS3-rol nem beszel, tud, de amig a webre lekerekitett sarkokat, meg egyedi fontokat ker, addig (attetelesen) ezt a szekeret tolja.
hat, itt ~3 ember valoban e menten tette le a voksat, de ezzel szemben ott van az a nehany szazezer/millio ember, akinek a webes megjelenes elkeszitese ad munkat, es a jelenlegi technologia minden hibaja ellenere megel belole.
konkluzalva a dolgokat:
van egy csomo dolog, amit lehetne jobban csinalni, szerintem folyamatosan fejlodik a web, lehet hogy vannak olyan teruletek, amik nem kapnak eleg figyelmet (pl. szemantikus web), de ez reszben azert is van igy, mert nincs ra igeny.
ha majd lesz, akkor jobban fog menni.
ha ez valakinek nem tetszik, akkor leul, belerak nemi munkat, es segit jobba tenni az egeszet.
de mindezt nem ugy, hogy robbantsuk fel az egeszet, mert van egy homalyos elkepzelesem arrol, hogy hogyan lehetne jobban, es eroszakkal letolom a felhasznalok torkan, mert en tudom, hogy mi az objektiv jo/szep, es nem erdekel, hogy a jelenlegi felhasznaloi viselkedesek alapjan mire van igenyuk az embereknek.
ps: es amugy pont ezert ilyen nehez/lassu a sztenderdizalas folyamata.
Tyrael
Erős érv
esetleg valamit a
Tyrael
Egyetértek Saxussal, magával
Az adatokat tárolhatjuk HTML-be ágyazva, de ezzel gondok lehetnek. A HTML-lel az a baj, hogy alapvetően emberi fogyasztásra és adatok megjelenítésére tervezték, és emiatt a (strukturált) adatokat nehézkes kiszedni belőle. Egyrészt a hibatűrés miatt nem triviális feladat parsert írni hozzá (tudsz ajánlani PHP-ban írt HTML 5 parsert?), másrészt ha scriptből szeretnénk az oldalon megjelenített adatokkal kezdeni valamit, az sem egyszerű. Íme, egy példa:
Marketingmenedzserünk<br>
<span itemprop="name">Kovács Béla</span><br>
<div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
<span itemprop="streetAddress">Budapest</span>
<p itemprop="addressLocality">Akácfa utca 16,
<span itemprop="postalCode">1073</span>
<br>
<span itemprop="addressCountry">Magyarország</span>
</p>
</div>
</div>
<div itemscope itemtype="http://schema.org/Person" class="kiemelt">
Vezérigazgatónk<br>
<div itemprop="name"><span>Koplárovics Aladár</span></div>
<div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
<div itemprop="streetAddress">Budapest
<span itemprop="addressLocality">Akácfa utca 16,
<span itemprop="postalCode">1073, <span itemprop="addressCountry">Magyarország</span></span>
</span>
</div>
</div>
</div>
Két cím, az egyik kiemelt, más különbség nincs köztük, emiatt viszont más HTML kód kell hozzájuk, azaz jóval általánosabb és lassabb scriptből kinyerni belőlük az adatokat. Mert mi van, ha mondjuk nem csak statikus HTML-ként szeretnénk valamit megjeleníteni, hanem uram bocsá' egy Flash-ben szeretnénk kicsit animálni, vagy valami hasonlóval?
Mennyivel egyszerűbb ugyanez strukturált XML-ben, amiből utána olyan kimenetet generálhatunk egyszerűen, amilyet csak akarunk, akár HTML-t, JS-t, SVG-t, bármit.
<title>Marketingmenedzserünk</title>
<name>Kovács Béla</name>
<address>
<streetAddress>Budapest</streetAddress>
<addressLocality>Akácfa utca 16</addressLocality>
<postalCode>1073</postalCode>
<addressCountry>Magyarország</addressCountry>
</address>
</person>
<person important="true">
<title>Vezérigazgatónk</title>
<name>Koplárovics Aladár</name>
<address>
<streetAddress>Budapest</streetAddress>
<addressLocality>Akácfa utca 16</addressLocality>
<postalCode>1073</postalCode>
<addressCountry>Magyarország</addressCountry>
</address>
</person>
Mivel az XML szigorú, ha hiba van, a feldolgozó kiakad, azaz minőségi munkát kell kiadnod a kezedből.
A HTML-lel az a baj, hogy
errol tudnal valami linket?
en mindig ugy tudtam, hogy a legtobbet az SGML-bol orokolte eredetileg, ahol pedig a a generalized markup egyik fo feltetele:
"Markup should be rigorous so that the techniques available for processing rigorously-defined objects like programs and databases can be used for processing documents as well."
pl. a legelso draftban nem is nagyon volt emberi fogyasztast vagy megjelenitest tamogato element vagy attribute:
http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html
A kesobbi vegleges RFC-kbe mar bekerultek ezek, de tovabbra is a celok kozott szerepelt a szemantikussag:
Szerintem itt a kerettel nem volt baj, inkabb az implementacion csuszott el a dolog:
A html sikere es elterjedese (ezzel parhuzamosan pedig a sztenderdizalas elhuzodasa) miatt felhigult az elerheto tartalmak minosege, ami a bongeszofejlesztoket is arra kesztette, hogy lazabban/tagabban kezeljek a szabvanyt, es minel tobb oldalt/featuret lehessen az o bongeszoikkel megjeleniteni.
Erdekes gondolatkiserlet, hogy ha akkor szigorubb lett volna a piac (es ezert kevesebb, de szabvanyosabb weboldal/browser lett volna a piacon, es lassabban jottek volna az uj featureok) vajon az lett volna a webbol, ami, vagy megmaradt volna egy szuk reteg jatekszerekent(mint mondjuk most az xml+xslt, vagy pl. az opera, aki az egyik legsztenderdebb bongeszo volt mindig is).
a hibaturesrol lasd amit fent irtam,
html5 feldolgozasra meg nem volt szuksegem, gyorsan korulnezve a html5lib-t ajanlottak tobb helyen, de a php verzio nagyon regen (2009 ota) nem volt frissitve, ennek ellenere is jobban teljesitett, mint a tobbi libxml alapu parser.
Két cím, az egyik kiemelt, más különbség nincs köztük, emiatt viszont más HTML kód kell hozzájuk, azaz jóval általánosabb és lassabb scriptből kinyerni belőlük az adatokat. Mert mi van, ha mondjuk nem csak statikus HTML-ként szeretnénk valamit megjeleníteni, hanem uram bocsá' egy Flash-ben szeretnénk kicsit animálni, vagy valami hasonlóval?
A peldadban szandekosan szerepelnek azok a <br>-ek?
Ha igen, akkor ezert kizaras jar a szemantikus web klubban. :P
A markup kulonbozik a ket peldaban, pedig a vizualis kiemeleshez erre nem lenne szukseg, ha megfeleloen hasznalnad a jelenleg is elerheto eszkozoket.
A flashes animalast nem teljesen ertem, ha ilyen kell, akkor en <noflash> tag-be tennem a strukturalt schemat, a crawlerek nem igazan eszik meg a flasht.
lasd fent, lehetne ugyanolyan egyszeru a kimenet, ha nem szabotalnad szandekosan, nem erzem fair-nek az osszehasonlitast.
a szigorusag itt sem feltetlen a szabvanybol ered, es sajnos bizonyos embereket ez sem akadalyoz meg abban, hogy invalid xml-t generaljanak es ajanljanak ki, amit aztan a masik oldalon allva lehet hogy neked kell tudni feldolgozni.
nem vagyok benne hogy ez tudatos, es nem csak arrol van szo, hogy szeretnenek, de sokszor nem tudnak lepest tartani az elen jarokkal.
ne felejtsd el, hogy mire valaszoltam(tuzzel vassal elpusztitani), szerintem is fontos hogy fojamatosan jobba tegyuk a dolgokat, csak nem mindegy, hogy ezt hogyan tesszuk, es hogy mennyire tesszuk nehezze az atmenetet a resztvevoknek.
A TCP protokoll, az x86 architectura meg a neumann elvu szamitogep is itt van egy ideje, de amig nincs "jobb", addig pusztan a kor alapjan nem jelentheto ki valamirol hogy elavult.
De a 21 evvel ezelotti HTTP es HTML speci eg es fold a mai (es a hamarosan megjeleno) verziokkal kapcsolatban.
csak kilora:
http://www.ietf.org/rfc/rfc1945.txt - 60 oldal
http://www.ietf.org/rfc/rfc2616.txt - 176 oldal
es ebben ugye nincs benne se a https se a cookie rfc, etc.
a html-nel(es a kore kinovo okoszisztemaban) szerintem meg nagyobb a kulonbseg.
szerintem a gepi forditas, szovegertes es a mesterseg intelligencia jelenlegi allasa nagyobb gatja az altalad felvazolt keresokifejezes ertelmezesenek es az ehhez passzolo talalatok kivalasztasanak, mint az, hogy nem all rendelkezesre jelenleg az a strukturalt informacio, amibol ez megtalalhato lenne.
de kis lepesekben lehet javitani a dolgokon, a problema az, hogy a spammereken/blackhat SEO-sokon kivul kb. senki mas nem hasznalja ki a keresokben jelenleg elerheto kepessegeket.
ha azt hiszed, hogy a jelenlegi webes kereses vallalhatatlan, akkor ezek szerint nem neteztel az altavistas/altavizslas idokben.
errol itt meg nem lattam konkret javaslatot, de en is ilyen iranyban tudom elkepzelni a javulast.
Tyrael
A HTML-lel az a baj, hogy
Tim Berners-Lee: The next Web of open, linked data
Érdemes végignézni, a válasz egyébként 4:10 után van a kérdésedre.
html5 feldolgozasra meg nem
Most csak erre reagálnék, mert nem érek rá: kolléga most épp HTML oldal feldolgozásával játszadozik. Pár hete meg nekem kellett lebányászni adatokat weboldalról. Ha most elkezdenek terjedni a HTML5-ös okosságok, az első
Hanem abból ered a hiánya, hogy a böngészők minden hulladékot megpróbálnak megjeleníteni.
Szerintem te valami nagyon érdekes szemüvegen keresztül nézed a világot. HTML5+JS messze nem azért kell az MS-nek, mert "élenjáró technológia", (.NET mellett csempék reszelgetésére... hááááát....) hanem szimlpán meg akarták lovagolni a HTML5 hypet.
es nem cafolod azt a
Légyszíves mond meg, hogy a HTML5-ben hol van olyan eszköz, hogy tetszőleges adatforrás köré, amely mondjuk lehet TSV, JSON, XML, etc. fölé húzok valami template jellegű dolgot. Mondjuk egy táblázatot. És igen, most is meg lehet oldani azt, hogy mondjuk kliens oldalon JS-ből templatezek, ha mondjuk szedek még adatot, csak kérdés, hogy abból mit lát a Google és kérdés, hogy miért nekem kell kézzel csinálnom ezt?
Könnyű leragadni egy egyszerű gombnál és hupos stílusban eltrollkodni, miközben a bonyolultabb példákat már jól figyelmen kívül hagyod.
Ezt hadd ne kommentáljam azon kívül, hogy felcímkéztem egy trollkodás jelzővel. (Ez mióta divat itt a WL-en ilyen szinten?)
Nem hiszem el, hogy ennyire földhözragadt a gondolkodásos. Weben többnyire valamilyen adatot valamilyen módon megjelenítünk vagy azzal végzünk műveletet. Namost ez az adat és félig-meddig az oldal szerkezete és más egyéb, megjelenítésért foglalkozó kód jelenleg egy leírónyelvben van.
Senki nem beszélt itt desktop alkalmazások átemeléséről. Arról beszéltem, hogy a HTML kódot és magát a nyers adatokat külön kellene választani. Opcionális megfejelésnek mondtam egy kliens oldali templatezést. Esetleg bónusznak egy kétirányú üzenetváltás alapú protokolt. Nem tudom, hogy te ebben hol láttál bele desktop alkalmazásokat. (Esetleg ott, hogy ott már ez többé-kevésbé működik :)
Legyünk őszinték: jelenleg a fejlesztők jó része örül, ha valami összetaknyolt PHP-HTML gányolmányt össze tud tákolni, kb. ennek megfelelő igényszinttel. Vagy annyira, hogy azt se tudja megmondani, hogy ASP.NET-ben "csináltam már weblapot". (Utóbbi - sajnos - mai példa.) Ha ehhez akarsz mérni mindent, akkor teljesen felesleges bármi olyanról beszélni, hogy mi kellene még a webre.
Nem divat
Különben másoktól hallottam olyat róla, hogy nagy szaki, de az utóbbi időben csak fikázásokat látok tőle, és mindig embereket szid. Valamilyen kisebbségi érzése lehet mostanában, vagy válik, nem tudom, de nekem úgy tűnik, itt vezeti le a feszkót. Csak ezt elég rosszul teszi.
Prog.hu-n divat élből
Azért írjatok üzit, ha esetleg valami odáig fajulna, hogy moderálni kell, és nincs aki megtenné. Nem követem ezt a témát...
Tyrael, Saxus, Pepita,
kérlek mindnyájatokat, hogy szorítkozzatok a szakmai vitára, és viseltessetek több türelemmel a kollégák iránt, a vélt és valós sérelmek elkerülése érdekében. Ez utóbbiak pedig, ha szükségét érzitek, magánlevelezés tárgyát képezzék.
A jövőben a vitapartnerek személyére vonatkozó megjegyzéseiteket törölni fogom.
Rendben,
Amennyiben velem sem szórakozik senki, én is béketűrő voltam, vagyok és leszek.
desktop-web
És azt a keresési igényt sem Gábortól hallottam először, hogy "háromszobás, mittudoménmilyen lakást keresek akárhol", hanem látogatóktól, potencionális megrendelőktől. Más kérdés, hogy ennek megvalósíthatóságát jelenleg kétlem.
Hiába olvasom ezt a témát...
Szerintem, ha a Google ma kiadna egy közleményt, hogy azokat a lapokat pontosabban tudja majd értelmezni, amelyek ilyen meg olyan szabvány szerint építik fel, akkor egy héten belül weboldalak milliói használnák azt a szabvány.
Amennyiben valamely szabványügyi megmondóember, vagy böngészőgyártó mondaná meg a tutit, akkor valószínűleg a Google még közleményt sem adna ki, hogy ők bizony lesz.rják ezt.
Tényleg nem látom, hogy miért a HTML5 a hibás, hogy a keresők úgy működnek ahogy.
Ha nem tévedek, akkor a web-nek egy nagy rész nem csak termékek, szolgáltatások reklámozásáról szól, ahol az egyetlen(?) szempont, hogy a keresők minél pontosabban tudják, hogy pontosan mit is reklámoznak.
Munkaidőm 95%-ban ExtJS-sel foglalatoskodom, nálunk a body tag mindössze egy noscript elemből áll, benne, hogy ne vicceljünk már. Azon szerencsétlen cégek alkalmazottai, akik napi 8 órában ülnek ezen eszköz előtt igenis számít a csicsa, az hogy van lekerekítés, az hogy van átlátszóság, hogy hangot ad. Nálunk felmerülő kérdés az ügyfélhez, hogy canvas-t ismerő böngészőt fognak-e használni vagy sem, mert ha igen, akkor kapnak olyan ficsöröket, amelyeket ellenkező esetben nem. (nem vagyok mazohista, nem fogom végigkísérletezni a régi IE canvas utánzatait. Ha meg tudja a böngésző jeleníteni, akkor szuper, máskülönben így jártunk)
De tegyük fel, hogy mégiscsak valaki bevezetné az ingatlan_adatlap tag-et, benne a lakas_meret tag-gel és még további több ezer ingatlanhoz köthető paraméterrel. Pontosan mire is lenne jó ez? Ezt totál naivan kérdezem. Mert ezt még mindig nem látom. Azontúl, hogy könnyebb lenne lelopni más ingatlanportálokról az adatot, mi hasznunk származna ebből a fejlesztésből? A partner portálok nem a publikus weboldalról szipkázzák át az adatokat, ők meghatározott, előre egyeztetett formában kapják azokat. Viszont a nagyérdemű közönség a formázott emberi szem számára jól olvasható alakban fogja megkapni, nekik bőven elég, ha a lakásparaméterek div-ekben, illetve span-ekben vannak.
Én világ életemben a HTML-re, mint megjelenítő rétegre gondoltam, és kevésbé zavart a fentebb említett problémák. Ahogy számomra a weboldalaknál az a cél, hogy az előre megadott kulcsszavakra legyek elől, amely nem tartalmazza az adott ingatlan lakásméretét.
Hamarosan
Ha már a szemantikus webnél
Egy időben komolyan foglalkoztam egy új - számomra - legoptimálisabb notebook vásárlásával, a lehető legolcsóbban. Ugye ha előretekerünk az időben, és teljesülnek az álmaitok, beírom a google-be, hogy 'laptop, könnyű, erős, olcsó, (etc)'.
Ezt én megvalósítottam, PHP scriptekkel, lemirroroztam a nagyobb kínálattal rendelkező notebook forgalmazók webshopjait, feldolgoztam az adatokat, betettem egy excel táblába, sorbarendezés, szűrés, kiválasztás. Tárá.
Mondjuk amellett, hogy napjaim rámentek (de megérte, ezt ne hagyjuk ki), egy sor olyan problémába ütköztem, amit a szemantikus webbel, ha megdöglesz se tudsz elérni: az adatok pontossága.
Csak néhány példa:
INTEL Core i5 i5-2410M
vs.
Intel Core i5 2430 (2,3 GHz , 3 MB cache)
vs.
Core i5 2430M (2400)
vs.
Intel Core i5
vs.
Intel® Core™ i5-2430M (3M Cache, 2.40 - 3.00 GHz)
vs.
Intel/Core i5/2430M 2,4 GHz/max Turbo freq: 3GHz, 2C/4T, 3MB cache
Amit a szemantikus webtől elvárunk, hogy ezekre mondjon egy szabványt, amit minden használója követ, ezért az adatokat jobban megtalálnánk. Most akkor a szemantikus webnek le kellene fedni az egész világot, strukturáltan, naprakészen, továbbá elvárjuk, hogy ahogy ezek változnak, kövesse? Belegondoltatok abba, hogy ez milyen erőforrásokat igényel?
Ha csak abba gondolunk bele, hogy bejön egy új CPU típus az egyik gyártónál, lesz egy új paramétere, akkor azt át kell vezetni a szabványon (ha nincs szabvány, mindenki máshogy fogja megvalósítani), amíg azt el nem fogadják, a kereskedők nem tudják frissíteni az adatlapot, de a termék már 1 hónapja a piacon van és el kéne adni. Aztán a szabvány elfogadásával a keresőmotoroknak is hozzá kellene igazodnia, mire újraindexelik az új szabvánnyal ellátott webshopokat, még egy hónap.
Tipp: csekkoljátok az intel cpu összehasonlító oldalát (http://ark.intel.com/), az helyzet, hogy még a saját termékeiket sem tudják rendesen karbantartani, akkor ezt egy kis forgalmú notebook webshoptól hogyan várhatnánk el? (Figyelembe véve a magyar vásárló lojalitási jellemzőit...)
PS: már csak a fun kedvéért: a kereskedők mennyire örülnének annak, ha a google képes lenne a fenti produkcióra? :)
A processzorok összevetéséhez
deejayy problémája épp az,
Pl. a proci sebességét az egyik helyen "sebességnek", a másik helyen "órajelnek", a harmadikon nemes egyszerűséggel "gigaherznek" nevezik. És ez csak egy szűk kör, magyar területről, egyetlen fogalommal kapcsolatban.
Arról nem beszélve, amit már néhányan emlegettünk: az interneten működő szolgáltatásoknak nem az az érdekük, hogy adatbázist szolgáltassanak mások számára, hiszen ezzel a saját forgalmukat csökkentik.
Ennek a szemantikus web témának kb. akkor lenne igazán értelme, ha sikerülne megvalósítani az elméleti kommunizmust és megszűnne a pénz, a vagyon fogalma. Ugyanis amíg az információnak pénzben kifejezhető értéke van...
nincsenek szabványosítva a
1, Az adatok jelenleg is éppúgy kinyerhetők a weboldalakból, mint ha megvalósulna a szemantikus web, csak most macerásabb, mert minden oldalhoz külön parsert kell írni. Egy működő példa erre a liligo, amely repülőjegyekre keres ajánlatokat n darab website-on. Ha van egy használhatóan működő HTML parsered, oldalanként szerintem fél óra egy saját adatgyűjtőt (crawler) írni. A szemantikus web elkerülhetetlen, előbb-utóbb meg fog valósulni. Természetesen lesznek, akik rosszul járnak, de mindenkinek van ideje felkészülni, és új üzleti modellt gyártani, mert gyökeresen meg fog változni minden.
2, A felhasználók könnyebben találják meg az oldaladat, így pont növekedni fog a forgalmad.
amely repülőjegyekre keres
Ehhez nem kell website-ot parsolni, vannak rá kész API-k, amiket meg lehet hívni.
Lehet, hogy most így van,
SABRE
Ha a crawlerek tudnák, amit
Végeredményben igen. A
A web eredeti elképzelése, hogy (mások által szubjektíven létrehozott) linkeken keresztül jutsz el másik weboldalra, erősen lekorlátozza, hogy mit találhatsz meg, mert a figyelmed korlátos. A szemantikus weben kereshetsz közvetlenül adatokra, és azokat összehasonlíthatod azonnal.
Webshopoknál ezt még
De én főleg az információtartalomra gondolok. A crawlerek adatot gyűjtenek, te meg információt keresel a keresőjükkel. Ez egy hatalmas különbség. Pl egy cikk, blog, fórum stb. Ha eltekintünk az ilyen információk kategorizálásának nehézségeitől (ez is AI), még mindig nem tudja megmondani (AI) a kereső, hogy egy általad leírt nyelvben (AI) feltett kérdésre mennyire válasz (információ) egy általa ismert tartalom (adat). És ez az, amiért nem ennek a szekerét tolják. Senki nem szereti a sziszifuszi melókat. Főleg nem bevétel nélkül. Ennek az egésznek az előfeltételei is az egyetemi laborokban vannak, nemhogy felhasználásról beszélnénk.
Ha keresel valamit, sosem
A szemantikus web nem egyszerű dolog, mint ahogy a világunk sem az. Az biztos, hogy első lépésben nem lehet nagy összefüggésekre keresni, hanem csak a hasonló objektumok között, de már ez is óriási előrelépés lenne a mostani helyzethez képest. Ehhez nem kell más, mint az, hogy mindenki jelölje meg, hogy az általa leírt adatok mit jelentenek (például
<span itemprop="postalCode">1073</span>
).Így van
Miszerint az üzleti modellen jelentősen kéne változtatniuk pl. a webshopot üzemeltetőknek. Pont ott fentebb jutott eszembe, hogy dehogy kell, csak azt a butaságot kell elfelejteni, hogy attól lesz több vásárlója, hogy többen látogatják az oldalt. Neki bőven elég az is, ha csak a tényleges vásárlók látogatják, sőt, esetleg még jobb is.
Viszont új "tag-szabványnak", illetve "világszabványosításnak" nem sok értelme van, vagyis nemigazán kivitelezhető. Itt talán abba az irányba kéne menni, hogy pl. "cím, tulajdonságok, leírás". A tulajdonságokat pedig lehet egyedi / egyéni tag-ekkel tovább részletezni, a keresők dolga, hogy értelmezik-e ezeket a tag-eket, vagy csak a köztük lévő (szöveges) adatot. Persze ez csak egy nagyon durva példa, de talán szemlélteti gondolatmenetemet.
Ez semennyire nem válasz a
Természetesen kell egy
És ki tartja karban A
És ki tartja karban A
Szemantikus funkciókkal bővülhet a Google kereső
Igen, elnézést, nem írtam le,
Szerintem itt beszelunk el
Azokra a strukturakra meg nyilvan maximum ajanlasokat lehet tenni. Ettol fuggetlenul az objektumok jellemzoinek neve veges, de megint nem errol van szo.
A megkonnyiti a crawlingot kerdesre meg annyit tudok mondani, hogy onnan kezdve, hogy valaki valamit publikalt csokken a controllja felette. Ha valaki akarja, igy is ugy is viszi az adatot.
Masik oldal viszont: megkonnyiti azt, amikor tobb rendszert kell osszekapcsolni, nem kell minden egyes rendszerhez kulon-kulon adatforrast letrehozni.
Hozzáállás
A cikk röviden arról szól, hogy az interneten nem hatékony jelenleg a keresés, mert nagyon kevés információt osztunk meg, ráadásul azt sem úgy, hogy gépileg könnyen fel lehessen dolgozni. Azért ostorozok mindent és mindenkit, hogy foglalkozzunk ezzel a problémával, mert a weboldalak látogatói, akikből megrendelőink élnek, könnyebben találhassák meg azt, amit keresnek.
Két lehetőség van:
1, azt mondjátok, hogy amit leírok, az hülyeség, ennyi is elég kell legyen, a keresés jelenleg is hatékony; én ezt elfogadom, ha elég kompromisszumot kötünk, most is sok mindent meg lehet találni
2, azt mondjátok, hogy igen, igaz, hogy ha több metaadatot adunk meg, akkor lényegesen pontosabb találati listákat tudok kapni
Ha szerintetek a 2-es pontban van ráció, akkor viszont nem értem ezt a hozzáállást, mert mindenki azt bizonygatja nekem, hogy hogyan nem lehet megvalósítani a dolgokat. Dehát ez kit érdekel? A munkahelyén is egy új feladatnál mindenki így adja elő magát a felettesének?
A hétmérföldes út is az első lépéssel kezdődik, egy lépést pedig megtenni nem kerül túl nagy fáradságba. Természetesen lesznek problémák és vakvágányok a szemantikus web megvalósítása során (mert efelé megyünk megállíthatatlanul), de eddig az emberiség sokmindent megoldott már.
Tehát egy kis konstruktivizmustól gyorsabban fogunk haladni, de a miért és hogyan nem az nem visz előre. Igen, gondolkozni kell közben és nem kitaposott ösvényen menni. Viszont, ha arra gondolunk, hogy a hatékonyabb keresés miatt a látogatók könnyebben és gyorsabban találják meg ügyfeleink termékeit és szolgáltatásait, akkor azzal végeredményben mi nyerünk. És nemcsak mi, hanem az egész világ.
Ha nyilvánvalóan hülyeséget
Momentán olyasmiért folytatsz szélmalomharcot, ami a jelenlegi számítástechnikai eszközökkel (legalábbis a nagyközönség által ismertekkel) nem kivitelezhető, mert
a) a mostani szerkezet értelmezése emberi intelligenciát igényel és még azzal sem mindig sikerül (konkrét példa: vérnyomásmérőt keresek és a gyártó hazai képviselője nem tudja megmondani, hogy a nevén és az árán kívül miben tér el egymástól a két kiválasztott szerkezet)
b) amit te akarnál ráerőltetni a webre, az egyrészt ellenkezik a website-ok üzemeltetőinek érdekeivel (=publikáld az adatbázisodat, a hasznot majd "én"(= kereső) lefölözöm), másrészt olyan mértékű szabványosítást igényelne, amit fizikai képtelenség megoldani egy olyan világban, ahol még arra sem képesek a felelősök, hogy két böngésző egyformán jelenítse meg ugyanazt az oldalt...
Az, hogy az adatokat
offtopik
Tudnál mondani olyan keresőt, ami megbízhatóan működik és a találatként felhozott oldalakból legalább a tárolt változat tartalmazza a keresett kifejezés valamennyi szavát (ha úgy kerestem) ?
Én a google-t használgatom, de rendszeresek az olyan találatok, amikor még a tárolt változat sem tartalmazza a keresett szavakat.
Pl.: budapest omron elite szavakra keresve (speciális keresés, "ezen szavak mindegyikét...")
Az első két találatnak még a tárolt változatában sem szerepel a Budapest szó.
bing
Valóban, ilyen szempontból
(többek közt ezt kellene valahogy rendbetenni: a bing-en sok esetben a google valós találatainak csak a töredéke jelenik meg, cserébe a gúgli teleszemeteli a találati listáját olyasmikkel, amiknek semmi közük az általam keresett dologhoz)
És nem örülsz neki?!
eddig bírtam szó nélkül :D
ha meg is valósulna amit írsz, hatalmas számítási kapacitás kellene, hogy működjön.
de nem is ezzel van a fő gond. ha ezen túl is lépnénk akkor sem jutnánk sehova.
miért?
az általad említett leíró xml-ek is csak egy aspektusból írnák le az adott objektumot. pl egy autót (utasok száma, teljesítmény, üzemanyag). de mi van ha én formatervezési irányelv szeretnék rá keresni, vagy nem is autót keresnék, csak valamit ami nyíl alakú. ki az az elmebeteg, aki egy autós oldalon kitöltené a nyíl alak leíró információkat is?!
létrehozhatsz akármennyi objektumot, az csak egy vetülete lesz a dolgoknak. nem lesznek összefüggések, nem lesznek következtetések. mindent felrúgva előre mennél egy olyan irányba, aminek a végén van egy nagy kemény fal. olyan ez, mintha mindenkinek ugyanazt az adatbázis struktúrát kellene használni :)
jók ezek az objektumok, ha van egy konkrét feladat, amire megoldás kell. pl magyarország azt mondaná, hogy mostantól központilag tárolom az összes számlát, nyújtok egy ingyenes alap szolgáltatást, ahol tárolhatod, tárolnod kell a számláid + ez az api-ja, ezek az adatstruktúrák, azt fejlesztesz hozzá, amit akarsz, ha jobbat szeretnél.
de a web nem erről szól. megosztok némi információt. honnan tudjam azt, hogy amit én leírok az mást milyen formában érdekel?
értem amit mondasz, csak megpróbáltam választ találni rá, hogy miért utasítom el, miért idegen tőlem, miért éreznek így mások.
arról nem is beszélve
Nincs új a nap alatt
Egy pont nekem
Továbbra is fenntartom, hogy magával az alapelképzeléssel van a baj, főleg akkor ha pénzről, üzletről van szó. Ha én egy háztartási kisgépkereskedőnek azt mondom, meg oldottam, hogy a "porszívó, 10-20 ezer forint közt" keresésre megjelennek a találati listában (a többi bolt termékei között) az ő porszívói, akkor az a kisebbik dolog, hogy kitépi a szívemet, de még a munkát is másnak adja. Mert ez NEM érdeke a kereskedőnek. Max, esetleg talán annyi, hogy az "olcsó porszívó miskolc környékén". De ha ő bedobja az árukészletét a közösbe, akkor nem tud brandot építeni, nem lesz értelme jó szolgáltatás biztosítani, hiszen nem lesznek visszatérő vevői, nem tudja irányítani a vevőjét, hogy mégiscsak a 25E-s porszívót vegye meg, és/vagy vegyen mellé egy örmény csipkés pocaktakarót. Ha mégis elterjed, akkor létrehoznak egy soktízezres, kamu szortimentet: pl jelenleg nincs árukészleten, de addig is nézze meg többi termékünket). Innentől kezdve az egész szemantikus dolog bukik, egy drága játékszer lesz. Olyan ez, mint a kommunizmus: Az eszmék szépek, ez így, ebben a formában nem működik.
Persze, van olyan szituáció, ahol nagyon is! Pl wiki, múzeumok, nem profit-orientált információs oldalak, monopolhelyzetben levő, speciális adatokat szolgáltató oldalak (bkv, önkormányzati oldalak), nagyonpici, regionális szolgáltató (olcsó üvegezés Iszapszentmotoroson, de ez most is egész jól működik), talánesetleg aggregátor oldalak (itt már rezeg a léc)
Kettő Gábornak
2.:
- A vásárló soha többet nem klattyol az ő domain-jére;
- A keresők is tudni fogják, hogy erre a domain-re csak 5 s-ig mennek a látogatók, aztán jönnek vissza a találati listára...
Mondom, az elmélet szép.
1: És ezt úgy lehet elérni, hogy...? A kereskedőkön nem lesz nyomás, hogy ilyen irányba változtassák az üzletpolitikájukat.
2: Ez nem feltétlenül az inkorrekt ajánlatokról szól. A jó kereskedő el tudja adni a drágább cuccot úgy, hogy elégedett lesz a vásárló is. Vagy a hozzáadott/javasolt termékek intézménye sem alapjaiban rossz. De tény, hogy sokan nem így állnak hozzá a dologhoz.
Pont ez az infó veszik el a felhasználó felé, ha minden adat be van dobva a közösbe.
És erre a SEO mágusok majd találnak megoldást, amire majd a keresők találnak megoldást, amire majd a SEO-sok találnak megoldást... ismerős a helyzet?
Gyakorlat
SEO mágusok: én nem tudom, értelmetlen "csavarintásokba" én nem kezdek, pláne nem folytatok, nekem többet ér a szakmai-erkölcsi megítélésem. Persze, lesznek / lehetnek próbálkozók, de a szemantikus web ésszerű megvalósításával sokkal nehezebb lesz trükközni is. És mindig a próbálkozók számától és pillanatnyi sikereiktől függ, hogy a keresők milyen "büntetési" megoldást alkalmaznak. Szóval ennek a vonalnak is hasznára válik.
A gyakorlat... :)
Bár ez lenne a gyakorlat
Elég lenne, de nem teszik.
És ki csináltatja a honlapot? Ki mondja meg, hogy milyen legyen? Na? Na..?
Te nem, más meg igen. És aki igen, az sikeresebb (lesz).
Me má mé? Pont ugyan olyan nehéz lesz.
Sajnos tudomásul kell venni, hogy a web feletti kontroll már nem a fejlesztők kezében van, vagy legalábbis csak kis részben. És hiába találjuk ki, hogy hogyan lenne jobb, ha az emberek egy részének nem kell, egy más része meg kifejezetten ellenérdekelt, és ráadásul tőkeerős, akkor az nem fog megvalósulni.
Talán maguk a keresők tudnának ebben lépni, de erre jelenleg nincs jel.
Jól elvagyunk...
Pont ezt kérte Gábor úgy 120 körül, hogy a "minden így jó, ahogy van" jellegű neminformatív kommenteket hagyjuk el.
Mindegyik rendszerben van
A szemantikus web megvalósulásával a felhasználóknak annyi előnye lesz, hogy jóval gyorsabban találnak meg mindent (a fals hirdetéseket is, természetesen), és nem lesz sokkal drágább, mert minimális plusz munkát jelent egy adat mellé odaírni, hogy az milyen tulajdonság pontosan. A technológia fejlődésével a csalók kiszűrése is könnyebbé válik.
Pár imposztor miatt maradjunk a technológiai kőkorszakban?
Dehát...
Dejszen pont ezt állítottam, hogy ez nem lesz igaz, mint ahogy most sem igaz, és a múltban sem volt az.
Ez nem erről szól. Hanem arról, hogy hiába gondolsz valamit jobbnak, a társadalmi folyamatokkal szembemenni nagyon nehéz, gyakorlatilag lehetetlen. Ha nem találsz olyan előnyt, ami valódi előny (vagy legalábbis annak látszik) azoknak, akik valójában működtetik az egész online hóbelevancot (azok, akik pénzt raknak bele), akkor megette a fene az egészet. És ismét mondom, az nem előny, sőt hátrány a számukra, hogy a "negyedik kerületben hol kaphatok levehető ajtajú turmixgépet?" kérdésre a termékére mutató találatot az összes többivel együtt kiadja egy kereső. Olyannyira nem, hogy az online médiában már volt egy parasztlázadás azért, mert a google túl jól keres.
A robots.txt most is működik,
A probléma nyilvánvalóan nem
Ezt találtam, itt is több
Ne keverd a szezont a fazonnal
Sajnos továbbra sem látod a fától az erdőt
Na, látod, itt hibáztál. Nem a felhasználók, hanem a felhasználók pénze. A felhasználók pénzével pedig (többek közt) a kereskedők rendelkeznek, hiszen ők költik el informatikai beruházásokra. És persze, egy egy kereskedő mindent meg fog tenni, hogy a felhasználónak jó legyen de azért, és nem másért, hogy a felhasználó nála, és ne másnál költse a pénzt. Ha tehet valamit, amitől a felhasználónak jobb, _és_ neki ettől nagyobb bevétele lesz, akkor megteszi, akkor is, ha neki ez komoly beruházásba kerül. Ha nem lesz nagyobb bevétele, akkor esetleg a piac törvényei szerint elmozdul abba az irányba. De ha ettől neki személy szerint csökken a bevétele, akkor csak egy igen erős külső nyomásra fog változni. Mekkora nyomás kell? Látszik a zene- és filmkiadóknál: hatalmas nyomás van évtizedek óta rajtuk, hogy térjenek át a digitális terjesztésre, és mégis csak az utóbbi pár évben kezdett ez az üzletág felfutni. (és valahogy mégsem akarnak eltűnni a süllyesztőben) És ez a nyomás jelenleg nincs meg a szemantikus web számára.
Nem azt mondom, hogy nem lehet ezt a kényszert akár mesterségesen is megteremteni. De ez egy teljesen más probléma, nem technikai jellegű, hanem a marketing, meg a társadalomdinamika fennhatósága alá esik.
ki az az elmebeteg, aki egy
akkor máshonnan közelítem
miért kell az emberek számára készített tartalmat gépek számára értelmezhetővé tenni? miért kell 2x annyi adatot letöltenie minden egyes látogatónak, csak azért mert minden századik egy keresőrobot?
a HTML-nek nem ez a feladata.
tőlem legyen lehetőség az adatbázisom egységes struktúrában történő exportálására bárkinek, de akkor arra legyen egy külön szabvány ettől teljesen függetlenül.
kicsit off és túlzás, de én azt is badarságnak tartom, hogy ezrek harcolnak amellett, hogy így úgy akadálymentes legyen a weboldal, hogy a vakok is el tudják olvasni. fontos, hogy ők is hozzáférjenek, de akkor ez a párezer ember miért nem fektet abba energiát, hogy egy normális olvasóprogramot létrehozzanak?! mintha kötéllel akarnának tolni valamit :)
Akadálymentes weboldal nem
bocs.
első lépésként tegye mindenki
Továbbá egyetértek azzal, amit az akadálymentes weboldalakról írtál, persze ehhez normálisan elkészített HTML kell, ami mondjuk nem egy nagy wasistdas.
szerintem mindkét oldalnak
a személyes véleményem annyi, hogy én kimaradok abból, hogy az általad felvázolt irányba mozduljanak a dolgok. és ez nem puszta lustaság részemről :D
Köszönöm, hogy érdemben
Középút?
Egyre inkább hajlok arra a korábbi felvetésemre, hogy "cím, tulajdonságok, tartalom/leírás". (Nem biztos, hogy u.így neveztem el, de lényegében mindegy.)
A tulajdonságokon belül meg már "szabad a gazda", ha azt akarom, hogy a most induló webshopom terméktulajdonságai összehasonlíthatóak legyenek az XY shopéval, akkor u.úgy nevezem el a saját tulajdonságaimat. Persze, ez a keresőkben nem lesz egyszerű történet, de sokkal nagyobb szabadságot ad a fejlesztőknek és megrendelőiknek. U.úgy lehet külön adat és megjelenés, stb., csak nem előre lefixált kategóriákba (tag-ekbe) kell beleférni, hanem csak fővonalak vannak megadva. (Egy kicsit hasonlóan a keywords-description-höz.)
Szerk.: ja, és az egész (adat) XML-szerűen, vagy XML-ben.
Cochran Hölgyeim és Uraim,
Hölgyeim és Uraim, mondjuk úgy esküdtek. Séf úr védője azt próbálta elhitetni velünk, hogy kliense 20 éve írta a Büdös Banyát. Sőt, talán el is hitette. Még én is majdnem megsajnáltam őket! De hölgyek és urak, úgymond esküdtek! Csak egy dolgot említenék, ha megengedik. Hölgyek és urak, ez itt Chewbacca. Chewbacca egy wookie a Kashyyyk bolygóról. De Chewbacca az Endor bolygón él. Gondolják csak meg; ennek nincs értelme!
Gerald Broflovski
Bassza meg!
Séf bácsi
Mi az?
Gerald
Használja a Chewbacca-védelmet!
Cochran
Miért akar egy wookie, egy 220 centis wookie az Endoron, 50 centis ewokok között élni? Ennek nincs értelme! De ami még fontosabb: ennek az egésznek mi köze a most tárgyalás alatt lévő ügyhöz? Semmi. Hölgyek és urak, ennek semmi köze az ügyhöz. Ennek nincs értelme. Nézzenek rám! Ügyvédként védek egy hatalmas kiadócéget, és Chewbaccáról beszélek. Van ennek értelme? Hölgyek és urak, ennek semmi értelme. Az egésznek nincs értelme. Tehát emlékezniük kell, amikor majd vitázgatnak és döntögetnek az Emancipációs Kiáltványról: van értelme? Nincs. Hölgyek urak, úgymond esküdtszék! Ennek nincs értelme. Ha Chewbacca az Endoron él, ítéljenek bűnöst. A védelem végzett.
'forrás'
..elfogyott a söröm
Szerintem semmi köze nincs
Vegyünk példákat, csak hogy egy kicsit jobban érthető legyen:
- A mozilla létrehozta az xforms-ot és a xul-t. Mindkettő csodálatos technológia, az az egyetlen gond velük, hogy más böngészők nem támogatják.
- A microsoft létrehozta a silverlight-ot. Szintén csodálatos technológia, az az egy gond vele, hogy alapból nem került be az internet exploreren kívül más böngészőbe.
Gondolom még lenne jónéhány ilyen példa, de ennyire azért nem vagyok művelt...
Az ok, amiért a böngésző gyártók csírájában fojtják el egymás technológiáit a piaci részesedés. Ha a silverlight elterjedt volna, akkor megszűntek volna a böngészők közötti különbségek, és a microsoft, mint a silverlight gyártója győzött volna. Ha az xforms vagy a xul elterjed, akkor a mozillának behozhatatlan előnye lenne, mert ők implementálták először ezeket a technológiákat. Az egyedüli kiút ebből a patthelyzetből az olyan technológiák fejlesztése, amelyek már közösek a mostani böngészőkben: javascript, css, html, xml, xslt, xhtml. Az xml+xslt+xhtml azért nem rúg labdába, mert az xslt nem objektum orientált. Körülbelül olyan, vagy talán még rosszabb xslt-ben fejleszteni, mint php3-ban. Maradt a javascript+css+html, amikbe elég komoly erőforrásokat invesztálnak annak reményében, hogy nő a piaci részesedésük. Ezekkel kapcsolatban viszont a w3c-nek nincs akkora hatalmas mozgástere, mert a html+css finoman szólva nem egy minőségi munka, a böngésző gyártók meg rúgdossák őket jobbról balról, hogy mi kerüljön a szabványba. Szóval a html jövőjéről a döntéseket nem is a w3c hozza, hanem a böngésző gyártók, akik persze itt is ugyanúgy harcolnak egymással.
Talán van rá valamekkora remény, hogy néhány verzió váltás után valami használható dolog jön ki a html+css-ből. Azért igazán siralmas a helyzet, mert 5 perc alatt nagyságrendekkel jobbá lehetne tenni a kliens oldalt. Csak annyit kéne tenni hozzá, hogy kivenni minden böngészőből a kikapcsolható javascript funkciót. Kapásból lehetne pl jquery+backbone.js-el, vagy extjs-el MVC-t követve komplett klienseket írni, amik REST-el, SOAP-al, esetleg WebSocket-el vagy bármi egyéb módon kommunikálhatnának, és teljesülne bennük az MVC minta, szóval el lehetne választani bennük a tényleges információt a megjelenítéstől. Ehelyett az megy, hogy a css-ből akarnak egy külön nyelvet csinálni (változót már tettek is bele), mert azt mindegyik böngésző támogatja... Szerintem stíluslapokra semmi szükség nincs, amikor javascriptből be lehet állítani a style property-t, és ugyanúgy mergelni lehet bármelyik css osztályt egy-egy javascript objektum mergelésével. A css selectorokat is ugyanúgy el lehet felejteni, amikor van xpath, ami százszor többet tud. A html-en is lehetne egy csomót javítani pár alap dolog beszórásával, ahelyett, hogy float:left, meg hasonlókkal kéne gányolni, amikor az ember egy grid-et akar csinálni, a középre igazítást meg margin:auto-val kell, amikor egy center layout-nak kéne végeznie... Igazából szerintem magára a html-re sincs semmi szükség, elég lenne egy olyan javascriptben, mint a swing, vagy a javafx, ami a böngészőben felhasználható GUI komponenseket tartalmazná. A kereshetőségen a REST nagyon sokat javítana, mert tiszta adatot lehetne kérni a service-től pusztán az accept header változtatásával, és nem kéne a teljes kliens lerántani annak minden sallangjával együtt, ahogy az most megy... Én csak azt nem értem, hogy ez a javascriptre átállás miért nem történt eddig még meg, hiszen annyira nyilvánvaló...
A böngészők közti háború
Tehát akkor
Aztán adva van a HTML, amire a keresők cuppannak, a böngészők ilyen-olyan módon támogatják, viszont nem szemantikus.
A szemantikusság csak azért fontos, hogy a keresők (vagy egyéb parser-ek) tudják értelmezni, és ezáltal jobb keresési találatokat nyújtani? Vagyis a felhasználó számára, aki böngészőben nézi az oldalt bőven elég a HTML, ha keresni akarna jobb lenne, ha a kereső tudná értelmezni az XML+XSLT-t.
Ebből nekem az jön le, hogy 3 dolog kellene egyszerre:
1. XML+XSLT alapú oldalak
2. alkalmazások (böngészők), amik jól értelmezik és helyesen jelenítik meg
3. keresők, amik jól értelmezik, és jól dolgozzák fel ezeket.
Ha én a magam részéről prezentálom az 1. pontot, tettem-e az ügy érdekében? Ha elegen megteszik az 1. pontot, el fog-e indulni a 2. és a 3. pont?
Vagy elég, ha kezdetben a schema.org-os megoldást használom?
Esetleg, ha például egy
<link rel="semantic" href="content.xml" type="text/xml+xslt">
megoldással prezentálok egy másik outputot a HTML mellé?Vagy mi legyen az első lépés?
+1
Csere
Akkor már miért nem dobjuk ki a JavaScriptet is, és rakunk be helyette mondjuk C-t, abban úgyis csak egy
int main(int argc, char **argv)
függvény kell, és C-ben mindenki tud programozni. Azt szeretném tudni erre miért nem álltak át korábban. Legalább a C-hez nincs olyan sok köze egyik cégnek sem, mint a JavaScripthez.[/off]
hohoho! átlátok ám a szitán.. :D
amúgy igazad van, kedvesem most ismerkedik a HTML CSS párossal hobby szinten. és egész jól halad. Na ha most Javascriptben kellene bármit is művelnie, hát sírvafakadna az biztos. pont az a jó a html-ben, hogy egyszerű.
Hát js-ben is össze lehetne
Nem hiszem, hogy a
szerk:
Utánaolvastam a div a "division" rövidítése.
[off]
majd az updatehez érve, ohh... jobb volt, míg nem tudtam.
Ja, tényleg vicces. Én a
Egyébként azt sem értem, hogy minek külön head meg body rész, amikor van http header, amiben a meta adatok simán elmehetnek... :D Szerintem inkább ne boncolgassuk :D
offline media
Emlékszem régen kaptam olyan CD mellékleteket, amihez html volt a gui. A head és body tagek valós okát persze én se tudom pontosan.
Bár gondolom költői kérdés
Egyébként a nodejs elég szépen mutatja, hogy mekkora lehetőség van a kis VM + javascript felállásban. Ugyanezt meg lehetne csinálni bármelyik böngészőben.
Természetesen
Óvatosan!
Azért kell OO-nak lennie,
Persze lehetne bármelyik másik nyelv, ami VM-ben fut, js-nek mindössze annyi az előnye a többivel szemben, hogy már jó ideje benne van a böngészőkben.
Az utolsó mondatod nem tudom
Ha úgy vesszük, a
Bármilyen nyelvet lehet
LLVM
Persze, ezért beszéltem az
Közben utánaolvastam jobban a
Arra gondoltam, hogy egy olyan nyelvre van szükség, amivel dinamikusan lehet bővíteni egy adott alkalmazást, hogy ne kelljen minden erőforráshoz egyszerre lerántani a GUI-t, hanem erőforrásonként külön-külön meg lehessen oldani mindezt. Ez megoldható most is egyébként ajax-al, csak a html+css jelenléte és az xhr hiányosságai miatt sokkal körülményesebb. A html+css helyett ezt az ajax-os megoldást meg lehetne támogatni egy saját GUI létrehozó API-val és egy komolyabb kommunikációs felülettel: rest kliens, soap kliens, socket.io. Az, hogy ez milyen nyelven valósul meg nekem tökmindegy, csak legyen. :-)
Kérhetek konkrétumokat?
Azt azért elképzelem, hogy az ingatlanos honlapokat fejlesztő cég állásinterjúján megkérdezik, hogy mi a különbség a terasz és az erkély között, majd hibás válasz esetén elutasítják, hogy így mégis hogy gondolja, hogy valid HTML oldalt állítana elő. :)
Kérhetsz
Nem értem
A spagettikód is kiment már a