ugrás a tartalomhoz

A modern böngészők miatt nem fejlődik a web

Hidvégi Gábor · 2012. Szep. 26. (Sze), 13.45

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, Cross­origin 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.

 
1

hazafele vennem kell egy nagy

Tyrael · 2012. Szep. 26. (Sze), 15.42
hazafele vennem kell egy nagy adag pattogatott kukoricat.

Tyrael
10

:)

Greg · 2012. Szep. 26. (Sze), 21.52
2

Az Adobe-t és társaikat se

Karvaly84 · 2012. Szep. 26. (Sze), 16.13
Az Adobe-t és társaikat se hagyjuk ki a dologból. Piacot kell fenntartani nekik is, és az üzleti érdek mindig előremenőbb marad mindennél, amíg a haszont pénzben mérik. Ez a web akkor lesz tökéletesen kiforrva, majd ha már nem lesz.
3

félreérted

tiku I tikaszvince · 2012. Szep. 26. (Sze), 16.58
Sokszor kifejtetted már ezzel kapcsolatban a véleményed, én meg már többször leírtam, hogy szerintem valamit nagyon félreértesz.

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…

„50-60 négyzetméter alapterületű, kétszobás ház Pest megyében, 12 és 16 millió forint közötti áron”
Hogy erre releváns találatot kapj milyen információk birtokában is kell lenned?
  • Most akkor mi a keresés tárgya?
  • Hol keresel?
  • Melyik plusz információt melyik adatra kell megfeleltenem?
  • 50 vagy 60? 50 még jó? 60 még jó? 60,0001 már ok?
  • négyzetméter, nm, m2
  • Mi van ha az adatforrásban nem forintban hanem euroban vannak az árak?


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.
5

A bonyolult keresésekre a

kdani3 · 2012. Szep. 26. (Sze), 18.11
A bonyolult keresésekre a legegyszerűbb megoldás, ha különböző adatbázisok tárolják a speciális adatokat. Például az ingatlankereső oldalak többségén a fent említett keresés pofonegyszerűen megoldható. Mivel rengeteg olyan oldal van, ami nagyrészt egy adatbázisban való keresésre épül(ingatlankereső oldalak, álláskereső oldalak, közösségi portálok, stb.). A keresők dolga mindössze annyi, hogy a fontosabb típusokra kialakítsanak egy saját szabályt, amihez az adatbázisok tudnak illeszkedni. A HTML5-ben ehhez kibővített lehetőségek vannak, de már az XHTML-ben is meg volt ennek a lehetősége. (Az ilyen weboldalakat továbbra is képesek megjeleníteni a régi böngészők)

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)
11

Most csak röviden válaszolok,

Hidvégi Gábor · 2012. Szep. 26. (Sze), 23.40
Most csak röviden válaszolok, holnap jönnek a többiek. A téma rendkívül összetett és bonyolult, a bejegyzés kétszer ilyen hosszú volt, de egy csomó mindent ki kellett szednem belőle, hogy elolvassa bárki is.
A HTML5 (+CSS3) alapvető célja a szemantikusság fokozása.
Szerintem itt van egy nagy félreértés. Az új tag-et csak a dokumentum struktúráját bővítik, de a dokumentumokban tárolt adatok jelentéséről nem hordoznak többletinformációt. Ne hívjuk ezért őket szemantikus elemeknek! Ezeknek egyébként csak és kizárólag akkor van súlyuk, ha folyószövegről van szó. Node a legtöbb cég nem folyószöveget árul, hanem megfogható terméket, például ingatlant, kolbászt vagy repülőjegyet, ott pedig 0 információértéke van, hogy <div>-ben vagy [code]<article>[code]-ben van az adat.

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.
Van fogalmam róla, de ez az ő dolguk, oldják meg ők. Lehet, hogy eleve nem szavakra kéne keresni? Az általad is említett microdata egy megoldás, de nézd már meg, hány valós életbeli tárgyat, objektumot készítettek el! Ezret max? Körbenézek, és csak az asztalomon a tízszeresét látom; ez nagyon gyenge teljesítmény eddig, és akkor az összefüggésekről még nem is beszéltünk.
Meg hányan használják a mikroadatokat? Elenyésző számban.
Mert a kereséseknek csak végtelenül elenyésző része ennyire bonyolult.
Azért egyszerűek a keresések, mert az embereket ránevelték, hogy a legprimitívebb kifejezéseket írhatják be. A kedvenc példám erre az iddqd blog egyik bejegyzése, amiben 2010 legjobb keresőkifejezéseit szedik össze. Így keresnek az emberek. Nem csak arra, hogy "online biztosításkötés" vagy "mátrix torrent", hanem "16 bites számítógépes játékoknál használatos angol kifejezések" vagy "commodore világ miért szűnt meg". És itt halnak meg a keresők.
12

iddqd

eddig bírtam szó nélkül · 2012. Szep. 26. (Sze), 23.58
Valaki itt valamit nagyon félreértett...
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.
18

Csak azt szerettem volna

Hidvégi Gábor · 2012. Szep. 27. (Cs), 07.21
Csak azt szerettem volna bemutatni, hogy nem mindenki főnevekre keres, hanem úgy indulsz neki mondjuk, hogy "na, akkor egy olyan repülőjegyre van szükségem, ami Madridig érvényes, retúr, olcsó és jövő június 7-én használható". Ebből most lesz "Madrid repülőjegy", és végignézel öt site-ot, mindegyiket persze másképp kell kezelni, mire találsz olyat, ami megfelelő a számodra.
25

Talán nézz utána a HTML5

kdani3 · 2012. Szep. 27. (Cs), 11.18
Talán nézz utána a HTML5 lehetőségeinek, és rájössz, hogy van lehetőség arra, hogy jelöld az adatok jelentését. A HTML5 legnagyobb vívmánya a jelentésjelölésre való áttérés. És a HTML5-ben lehetséges repülőjegy struktúrát létrehozni úgy, hogy a keresők képesek legyenek hasznosítani ezt a többlettartalmat. Mi több, a Google kereső már hasznosítja is ezt.
41

Pár mondatban tudnád vázolni

tgr · 2012. Szep. 29. (Szo), 15.51
Pár mondatban tudnád vázolni azt a technológiát a sitebuilder/weblapüzemeltető szemszögéből, ami lehetővé tenné, hogy a keresők intelligens válaszokat adjanak mondjuk a "commodore világ miért szűnt meg kérdésre"?
42

Íme; feltételezem, hogy ehhez

Hidvégi Gábor · 2012. Szep. 29. (Szo), 16.31
Íme; feltételezem, hogy ehhez nem kell csinálni semmit. Viszont a hardverigénye olyan nagy, hogy Moore törvénye alapján kb. száz év múlva fog tudni egy számítógép kiszolgálni egy keresést.
4

érdekes

yvan · 2012. Szep. 26. (Sze), 17.27
...de azért kicsit átgondolatlannak tűnik nekem ez az eszmefuttatás.

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.
19

Nem nehéz az első öt

Hidvégi Gábor · 2012. Szep. 27. (Cs), 07.30
Nem nehéz az első öt találatba bekerülni, ez csak a szűrési feltételek függvénye. Roppant egyszerű elméleti keresés: "webfejlesztők, akik Budapest 7. kerületében dolgoznak, ár szerint növekvő sorrendben".

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ő.
Á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
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. Arról ugye nincs információ, hogy hányan nem találják meg. A CSS3 nem tesz hozzá, hogy első legyél, de a metaadatok igen.
26

Hogy nem-e?

yvan · 2012. Szep. 27. (Cs), 11.41
"Nem nehéz az első öt találatba bekerülni, ez csak a szűrési feltételek függvénye."
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.
28

Persze túl kell lépni az egy

Hidvégi Gábor · 2012. Szep. 27. (Cs), 12.21
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.
Ha eltekintünk a nagy cégektől, mint pl. a Generali vagy Nivea, akik az egész országban szolgáltatnak, akkor a Miskolci Kútfúró Kft. miért akar kútfúrásban első lenni Baranyában? Az ügyfél valószínűleg azért várja el a két kulcsszavas optimalizálást, mert erre lett nevelve, meg tudja, hogy a keresők nem képesek többre. Tyúk vagy a tojás problémája. Máris jóval kisebb találati listában kell jó helyezést elérni. Tegyük fel, hogy cégünk nagyon rövid határidőkkel dolgozik, ezt meg lehet adni microdatával?

célirányosan csábítjuk a usereket akár más forrásból is
Az általában pénzbe kerül, a kereső viszont ingyenes, és manapság ez elég fontos szempont.

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.

szóval html oldalról én a problémát megoldottnak látom
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.
35

még a végén fizetni kell az ügyfélnek?

yvan · 2012. Szep. 28. (P), 16.31
"Az általában pénzbe kerül, a kereső viszont ingyenes, és manapság ez elég fontos szempont."
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.
36

"Az általában pénzbe kerül, a

Hidvégi Gábor · 2012. Szep. 28. (P), 21.59
"Az általában pénzbe kerül, a kereső viszont ingyenes, és manapság ez elég fontos szempont."
A szabványt patkoljuk át azért, mert az ügyfél filléreskedik. Logikus.
Ezt nem értem, én semmilyen szabvány átpatkolásáról nem beszéltem.

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.
Pont ezt írom a bejegyzés végén, hogy mi vagyunk a felelősek a kialakult helyzetért. Nézd meg bármelyik szakmai oldalt, akár a weblabort, ezer blogmarkból hány foglalkozik a szemantikus webbel?

az adatok kiértékelését végző 3.fél azt vesz belőle figyelembe, amit ő akar
A keresők elemi érdeke, hogy minél pontosabb találatokat adjanak, és ez még száz évig csak metaadatok segítségével lehetséges.
46

A keresők elemi érdeke, hogy

yvan · 2012. Szep. 29. (Szo), 19.48
A keresők elemi érdeke, hogy minél pontosabb találatokat adjanak, és ez még száz évig csak metaadatok segítségével lehetséges.

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.
6

Provokáció?

T.G · 2012. Szep. 26. (Sze), 18.36
Nem tudom eldönteni, hogy ez a cikk kifejezetten provokációnak készült, vagy a szerző a leírtakat komolyan is gondolja. Illetve nekem nem egyértelmű, hogy kire lő, a HTML5-re, a modern böngészőkre vagy azokra a fejlesztőkre, akik frissítik a böngészőiket?

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!
14

Nem tudom eldönteni, hogy ez

Hidvégi Gábor · 2012. Szep. 27. (Cs), 06.44
Nem tudom eldönteni, hogy ez a cikk kifejezetten provokációnak készült, vagy a szerző a leírtakat komolyan is gondolja.
Is-is. A cikk azért készült, hogy a kollegák lépjenek túl a szövegszerkesztő-keretrendszer-lekerekített sarkok szentháromságon, mert ezeken túl is vannak mindenkit súlyosan érintő témák. Ezeken is érdemes gondolkodni, meg érdemes beszélni, a változásokat érdemes kieszközölni, különben mások hozzák meg helyettünk a döntéseket, és az nem biztos, hogy nekünk is jó lesz.

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.
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?
Mert nem a szomszéd Juliska néni készítette azt a kódot, amiből nem lehet kitalálni, hogy mi micsoda. A schema.orgon nincs fenn pékség objektum. Miért nincs fenn? Nem kérték elegen. Miért nem kérték? Ki kérte volna? A fejlesztők. Hát ezért ők a hibásak.
7

Én is hozzátenném a magamét a flémekhez.

szaky · 2012. Szep. 26. (Sze), 18.55
Szerintem az ingatlanhirdetéses példa jól mutatja, hogy a megrendelők mit _nem_ akarnak. Kb egy-két évvel ezelőtt volt egy nagy felzúdulás a lapkiadóktól, hogy szerintük így is túl sok általuk előállított tartalmat kezel a google. Egy ingatlanhirdetéses oldalnak nem az az érdeke, hogy az általa menedzselt adatok összefüggései is kint legyenek a neten, mások által kezelve. Egy ingatlanhirdető oldal azt akarja, hogy az ingatlan, vagy eladó lakás szavakra keresve eljussanak hozzá, ahol majd _Ő_ szépen kezeli a saját logikája szerint a kereséseket, és ő kiajánlja a hirdetéseket és a kapcsolódó reklámot. Azon lehet keseregni, hogy ez felhasználói oldalról nézve mennyire negatív, de ha összehasonlítjuk azzal, hogy 20 éve hogyan kerestünk lakásokat, a fejlődés drámai.
15

A gondolatmenet jó, de a

Hidvégi Gábor · 2012. Szep. 27. (Cs), 06.51
A gondolatmenet jó, de a következtetés rossz. Az ingatlan hirdetőnek az a célja, hogy megtalálják és megvegyék az ingatlanját. Az ingatlanos site-oknak az a céljuk, hogy rajtuk keresztül találják meg a kérdéses dolgot, tehát ők veszthetnek azzal, ha a keresőben már eleve megjelenik minden adat.

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
8

Jó bejegyzés.

dropout · 2012. Szep. 26. (Sze), 19.44
Jó, mert egy kevésbé hangsúlyos, de fontos problémára irányítja a figyelmet. Lehetne jobb szemantikus webet csinálni és kell is. Ha jól értem pellengére állítod a fejlődés mentén a vizuális újdonságokat a szemantikus jelölés lehetőségének / használatának hiányával. Én ebbe a kontrasztba vinnék egy kis árnyalatot a megjegyzésemmel.

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.
16

Sorrend

Hidvégi Gábor · 2012. Szep. 27. (Cs), 06.56
A HTML5/CSS3 jó dolog, mert megkönnyíti valóban a munkánkat, a cikk egyik mondanivalója, hogy előbb legyen a web kereshető, utána ráérünk csicsázni.

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.
9

verseny

tiku I tikaszvince · 2012. Szep. 26. (Sze), 21.33
Beszélgettünk az irodában témáról és felmerült még az is, hogy a böngészők közötti versenyt a fejlődés gátjának kikiáltani… hmmm, hogy is fogalmazzam finoman…

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 mondjak
17

Beszélgettünk az irodában

Hidvégi Gábor · 2012. Szep. 27. (Cs), 07.13
Beszélgettünk az irodában témáról és felmerült még az is, hogy a böngészők közötti versenyt a fejlődés gátjának kikiáltani… hmmm, hogy is fogalmazzam finoman…
Nem kell finoman fogalmazni, ez oltári nagy baromság. De ki állított ilyet?
IE versenyzett a Netscape-el. [...] És mi is történt ezután kb 5-6 évig? Ja. Igen, emlékszem. Semmi.
A HTML pont ugyanarra az elvre épül bő húsz éve, azóta nem történt semmi, ez a baj. Nem tudunk és - úgy tűnik - nem is akarunk egy <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:

<nav>Típus: tégla építésű lakás</nav>
<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>

<ingatlan>
  <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>


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
Miben jobb? Látványosabb? Sokat érsz vele, ha nem találják meg.

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.
A Flash elterjedtsége pár éve 98%-os volt.
20

Most nem találom, ki írta, de

eddig bírtam szó nélkül · 2012. Szep. 27. (Cs), 08.03
Most nem találom, ki írta, de azt hiszem, igaza lehet: az oldalak üzemeltetői nem biztos, hogy örülnek, ha a felhasználó egy keresőből szedi elő a számára szükséges infókat ahelyett, hogy az oldalára látogatna.
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...
21

A keresőkben ott van most is

Hidvégi Gábor · 2012. Szep. 27. (Cs), 08.28
A keresőkben ott van most is minden információ (hisz a teljes HTML kódot eltárolják), tehát ez nem jó érv.
23

Épp ez az, hogy nincs benne

eddig bírtam szó nélkül · 2012. Szep. 27. (Cs), 08.50
Épp ez az, hogy nincs benne minden.
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 ;-) )
22

mi is a bejegyzés címe?

tiku I tikaszvince · 2012. Szep. 27. (Cs), 08.46
De ki állított ilyet?
Mi is a bejegyzés címe? A modern böngészők miatt nem fejlődik a web

Vesd össze az alábbi két kódot
Ezzel a példával, értem mit szeretnél bebizonyítani, de nem sikerül. Csak azt prezentálod vele, hogy nem ismered a HTML elemeket, nem érted mikor mire melyik elemet kellene használnod. Az ismeretek hiányából eredő frusztráltságod pedig az eszközön vezeted le. Ez kb ugyanaz az attitűd mint a "szar a linux mer' nem fut rajta natívan a Photshop".

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!
<dl itemscope itemtype="http://schema.org/Product">
  <dt>Típus</dt>
  <dd itemprop="name">tégla építésű lakás</dd>

  <dt>Bérleti díj</dt>
  <dd itemprop="offers" itemscope itemtype="http://schema.org/Offer">
    <span itemprop="price">50 000 Ft/hó</span>
  </dd>

  <dt>Alapterület</dt><dd>107 m²</dd>
  <dt>Ingatlan állapota</dt><dd>jó állapotú</dd>
  <dt>Szobák száma</dt><dd>2</dd>
</dl>
Az új elemek bevezetésével egy lépést tettünk a web eredeti funkciója, a tartalomközlés felé. Ha valaki most mindenütt <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.

Miben jobb?
Valóban nem fogalmaztam pontosan. A régi böngészők támogatásának elhagyásával felszabaduló erőforrásokat lehet fordítani új szolgáltatások fejlesztésére, a már meglévők használhatóbbá tételére, a meglevő kód optimalizálására, és lehet, egy kicsit látványosabbá is tenni. Miért rossz az, ha használom azokat a lehetőségeket, amik adottak? Miért baj, ha úgy használom ezeket a lehetőségeket, hogy azok a kliensek, akik számára nem elérhető pl a CSS3 lehetőségei, közben ugyanúgy tudják használni az oldalamat?
24

Kérlek, olvasd el az utolsó

Hidvégi Gábor · 2012. Szep. 27. (Cs), 09.08
Kérlek, olvasd el az utolsó előtti bekezdést is, ott fejtem ki, hogy mit is jelent a cím.

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.
27

tagek

yvan · 2012. Szep. 27. (Cs), 11.56
"A Flash elterjedtsége pár éve 98%-os volt."
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.)
29

Mobil platformon mekkora?Az

Hidvégi Gábor · 2012. Szep. 27. (Cs), 12.32
Mobil platformon mekkora?
Az Apple termékein nincs, valamint az Androidokon is egyre problémásabb beszerezni. Elindult egy trend (haljon meg a Flash), amit valószínűleg nem lehet már megállítani, de nem is ez volt a mondanivalóm lényege, hanem az, hogy a HTML 5 "újdonságait" már akkor meg lehetett oldani, amikor még 98% volt a Flash elterjedtsége. Innentől kezdve csak az időnket pazaroljuk, amíg az új technológia kiforr, és 98%-os elterjedtsége lesz.

El tudod képzelni, hogy hány új tag-et jelentene az élet minden területét lefedni
El, milliós nagyságrendű vagy nagyobb. És akkor mi van?
34

már androidon sem igazán

yvan · 2012. Szep. 28. (P), 16.31
a HTML 5 "újdonságait" már akkor meg lehetett oldani, amikor még 98% volt a Flash elterjedtsége

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.

El, milliós nagyságrendű vagy nagyobb. És akkor mi van?

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.
37

Persze neki lehet állni külön

Hidvégi Gábor · 2012. Szep. 28. (P), 22.04
Persze neki lehet állni külön tartalmat fejleszteni desktopra és mobilra
Bár a magam részéről kidobnám az egészet, de tisztában vagyok azzal, hogy ez nem fog megvalósulni. A bejegyzés arról szól, hogy rossz irányba indultunk, mert kritika nélkül elfogadtunk mindent.

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.
47

Az utolsó bekezdésedben

yvan · 2012. Szep. 29. (Szo), 19.57
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.

Ez esetben nem értem miért hoztál elő egy telejsen buta példát. :)
30

Szar a linux, mert...

Gixx · 2012. Szep. 27. (Cs), 12.47
...nem fut rajta natívan a GTA :)

De fejleszteni kiváló rajta :)
13

Van igazságod

Pepita · 2012. Szep. 27. (Cs), 01.41
Szemben az itt felszólalók többségével én azt mondom:
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".
31

A HTML5/CSS3 szerintem is egy

kdani3 · 2012. Szep. 27. (Cs), 12.52
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".


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...
32

Szerintem sem

Pepita · 2012. Szep. 28. (P), 01.17
Szerintem a webfejlesztés nem a csilli-villi megvalósításáról szól. A HTML5 meg végképp nem.
Nem azt mondtam, hogy erre használjátok / használom, hanem azt, hogy erre használható.

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.
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.
E kettő üti egymást. Az új böngészőnek is u.úgy megvan a maga nemkevés erőforrásigénye.
az Internet Explorer 5.0 elterjedtsége ma már igen csekély...
Én mondjuk IE8-ra gondoltam...
33

Itt a script:

kdani3 · 2012. Szep. 28. (P), 13.17
Itt a script: https://code.google.com/p/html5shiv/
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)
38

Kösz a linket

Pepita · 2012. Szep. 28. (P), 23.09
Ez beletelik némi időbe, míg tesztelem-átrágom, de így elsőre nem találtam az általad említett nem egész kB-os csodaszert a csomagban... Ha elengedhetetlen hozzá a jQuery 1.7.x, akkor azzal együtt mindjárt karcoljuk is a fél megát. Mindegy, ha már így "esküszöl rá", megnézem, nehogy túl szkeptikus legyek.
Az Internet Explorer 8-ban egyáltalán nincs gond a HTML5-el.
Azt leszámítva, hogy az új tag-ek nagyrészét nem ismeri, nincs is... U.ez igaz a CSS3-ra is. Amit pedig a továbbiakban taglalsz, miszerint milyen könnyű is kiváltani - azzal kb. u.azt mondod el, mint Gábor és én. Ha ilyen könnyen megvagyunk nélküle, akkor minek?
45

troll

Tyrael · 2012. Szep. 29. (Szo), 17.42
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


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.


3 kilobájt alatt van.


de így elsőre nem találtam az általad említett nem egész kB-os csodaszert a csomagban


hogy lett a néhány kilobyte-ból nem egész kB-os?

a elengedhetetlen hozzá a jQuery 1.7.x, akkor azzal együtt mindjárt karcoljuk is a fél megát.

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.

É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".


vs.

Amit pedig a továbbiakban taglalsz, miszerint milyen könnyű is kiváltani - azzal kb. u.azt mondod el, mint Gábor és én.


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:
hogy pár csili-vilit könnyebb megvalósítani benne

innentől kezdve megfordítanám a kérdésedet:
Ha ilyen könnyen megvagyunk nélküle, akkor minek?

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
53

Mi ez?

Pepita · 2012. Szep. 30. (V), 00.47
Ne haragudj, de te most kötöszködsz velem? Nem egészen értem - főként a cím - miértjét. Helyenként vagy egy (elég hagynemondjam, milyen) stílusod.
hogy lett a néhány kilobyte-ból nem egész kB-os?
Úgy, hogy elgépeltem. Először 2-3 kB-ot írtam, majd láttam, hogy kiírta pontosan a 3-at, viszont elb... a szerkesztésnél. Bocs. De ha megnézem pl. ezt a kommentedet, kb. 3x annyi gépelési stb. hiba van benne...
hol láttad ez, mint dependenciát?
Hát, talán ha az egész mondatomat idézted - és megértetted - volna, akkor elhinném, hogy nem csak kötöszködni akarsz. Íme:
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.
a te állításod az volt, hogy a kiváltás bonyolult, és nagy terheket ró a gépre.
És a többi. Megint csak kiragadtál egy-egy mondatomat, amibe bele akarsz/tudsz kötni, véletlenül sem úgy érted, ahogy mondtam.
Ö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.
62

a szemelyeskedest szerintem

Tyrael · 2012. Szep. 30. (V), 02.21
a szemelyeskedest szerintem ne itt folytassuk, a tobbire reagalva:

Hát, talán ha az egész mondatomat idézted - és megértetted - volna, akkor elhinném, hogy nem csak kötöszködni akarsz. Íme:

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.

Ö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.

ebben ezek szerint elter a velemenyunk.

Ráadásul "szét is szakadt", nem valószínű, hogy valaha is tényleges szabvány lesz belőle.

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.

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?

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.

Nem először van olyan érzésem, hogy kipécézel és belém kötsz.

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
69

Hagyjuk

Pepita · 2012. Szep. 30. (V), 23.19
Inkább hagyjuk, el ment a kedvem az egésztől. Pedig érdekelt a szkript, de már nem...

É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.
76

sajnalom, ha ezt

Tyrael · 2012. Okt. 1. (H), 11.03
sajnalom, ha ezt kotozkodosnek elted meg, ujra elolvastam a hozzaszolasomat, a targy kivetelevel az egesz hozzaszolas a korabbi hozzaszolasokbol es az en targyilagos, nem szemelyeskedo valaszaimbol allt.
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
77

script méretek

tiku I tikaszvince · 2012. Okt. 1. (H), 11.19
Hogy tudjuk, mi mekkora
Libproduction size
HTML5Shiv
2,376 kb

Modernizr 2.6.2
15,154 kb

jQuery 1.8.2
32,98kb


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
39

Tiltakozás!

T.G · 2012. Szep. 29. (Szo), 08.10
Annyi ostobaságot olvastam itt, hogy tiltakozásom jeleként, egy hétig nem iszom a Weblabor-os bögrémből. Se kávét, se teát, de még vizet sem!
40

Érdeklődés

Hidvégi Gábor · 2012. Szep. 29. (Szo), 08.24
Kapucsínót sem?
54

Az is valami?

Pepita · 2012. Szep. 30. (V), 00.51
Inkább ne igyál más edényből sem... :)
68

Csak civilizáltan, ha

Joó Ádám · 2012. Szep. 30. (V), 18.13
Csak civilizáltan, ha kérhetem.
73

Félreérted

Pepita · 2012. Szep. 30. (V), 23.45
Elnézést kérek, viccnek szántam.
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é...)
43

Végigolvasva a cikket és a

BlaZe · 2012. Szep. 29. (Szo), 16.41
Végigolvasva a cikket és a hozzászólások nagy részét, én még mindig nem teljesen értem, hogy itt most miről is van szó. A böngészőkről, a html (meta) tagekről, a keresési találatokról... ?

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.
44

Röviden

Hidvégi Gábor · 2012. Szep. 29. (Szo), 17.11
1999-ben elindultunk a szemantikus web felé, de a lassú fejlesztés és az elégtelen eszközök miatt pár böngészőgyártó a saját kezébe vette a kezdeményezést, és olyanokon kezdtek el dolgozni, ami látványos, mert azzal tudják eladni a termékeiket. A szakma persze ráharapott, és inkább ezzel foglalkozik mindenki, mint a szemantikus webbel. Az írás arról szól, hogy a HTML5+CSS3 sok újdonsága megoldható a régi eszközökkel is, emiatt ez a jelenlegi irány időpocsékolás.

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.
48

Hogy megoldható valahogy

BlaZe · 2012. Szep. 29. (Szo), 20.01
Hogy megoldható valahogy minden régi eszközökkel (flasht itt most felejtsük el gyorsan), az nem jelenti azt, hogy nincs értelme a core rendszer részévé tenni. Ez az informatikában nagyon sok helyen megfigyelhető, és elég üdvözítő dolog.

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 :)
51

Másrészt meg értem, hogy a

Hidvégi Gábor · 2012. Szep. 29. (Szo), 21.33
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?
Kinek mi a fontos, ugye. A böngészőgyártó abban érdekelt, hogy az ő szoftverét használják, ezért igyekszik azt kényelmessé tenni, valamint arra törekszik, hogy minél több featúrát tudjon. A szemantikus web viszont a keresők ügye, a browser, ami egy egyszerű grafikus kliensprogram, nem tud mit kezdeni a metaadatokkal.
52

Akkor asszem most húztad át

BlaZe · 2012. Szep. 29. (Szo), 23.34
Akkor asszem most húztad át az egész bejegyzésedet egy vastag piros vonallal :)
55

Indokold

Pepita · 2012. Szep. 30. (V), 00.57
Ezt itt megindokolhatnád, különben csak ellenségeskedésnek tűnik.
57

Olvasd el HG hozzászólását

BlaZe · 2012. Szep. 30. (V), 01.06
Olvasd el HG hozzászólását újra. Leírta, hogy a szemantikus webnek semmi köze a böngészőkhöz. Tehát akár a torrentet is okolhatná a kialakult helyzetért, mert a programozók letöltenek a taggyártás helyett :)
70

És?

Pepita · 2012. Szep. 30. (V), 23.33
Szerintem ezzel egyáltalán nem mondott ellen a blogbejegyzésének.
Bocs, ha erősen fogalmaztam legutóbb, de nekem kötözködésnek (v. kötöszködésnek?) tűnt.
64

Nem az

Hidvégi Gábor · 2012. Szep. 30. (V), 08.08
Blaze rendes gyerek, ismerem : ) Ettől függetlenül a kijelentésével nem értek egyet, mert minden jel arra mutat, hogy mégiscsak kizárja egymást a két dolog.
71

Kizárja?

Pepita · 2012. Szep. 30. (V), 23.34
Vagy csak munkaórát / energiát vesz el tőle?
74

Igaz

Hidvégi Gábor · 2012. Okt. 1. (H), 07.52
Rosszul fogalmaztam.
49

Jó lenne, ha mindenki

yvan · 2012. Szep. 29. (Szo), 20.09
Jó lenne, ha mindenki rendszerben próbálna meg gondolkozni, és nem kritika nélkül fogadná el azt, amit elé raknak.

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.
50

Azért az sem ártana, ha

Hidvégi Gábor · 2012. Szep. 29. (Szo), 21.10
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.
Két feladat van, az első az objektumok adatbázisának elkészítése, a második pedig az összefüggéseké. Az elsőt viszonylag könnyű megcsinálni, és azonnal lehet benne keresni, és a mostanihoz képest drasztikusan nőne a keresések hatékonysága.

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.
A W3C tüttyög rajta : )

Az eredeti felvetéssel az a gondom, hogy a megjelnítés teljesen független a szemantikus leíró adattól
Így van, viszont az átállás a szemantikus webre nagyon nagy munka, ugyanis, ha bevezetik rendesen (nem csak ~500 objektum érhető el a schema.org-on, hanem százezerszer ennyi), akkor mindenki hátrányba kerül, akinek csak puszta HTML-ben van meg az oldala, tehát át kell írni minden oldalt.

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.
56

Pont ez a baj

Pepita · 2012. Szep. 30. (V), 01.05
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.
Ezért rossz ez az egész elgondolás. Mondjuk nem abszolút 0, de majdnem. Így viszont a keresőt használ(hat)ó látogatónak nem sok "köze van" ahhoz, hogy milyen tartalmakat fog megtalálni, ill. azok a tartalmak mennyire fogják kielégíteni az igényeit. Nagy baj az is, hogy ebben a dologban egyes rétegek üzleti érdekei teljesen szemben állnak a látogatók morális és egyéb érdekeivel. Na, ezt a szekeret én igyekszem nem tolni.
59

A böngésző mit kezdene a

BlaZe · 2012. Szep. 30. (V), 01.15
A böngésző mit kezdene a leíró adatokkal? A kereső meg most is feldolgozza a tartalmat. Hogy máshogy kéne?
60

A böngésző semmit

Pepita · 2012. Szep. 30. (V), 01.24
A böngésző semmit. Viszont ha 0 kapcsolat van a meta és a tartalom közt, akkor a meta alapján jó eséllyel ad téves találatokat a kereső. Épp azért nem absz. 0 a kapcsolat, mert vmilyen szinten feldolgozza.

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.
61

A jelenlegi helyzet az, amit

BlaZe · 2012. Szep. 30. (V), 01.36
A jelenlegi helyzet az, amit írsz. A kereső a tartalommal foglalkozik, a felhasználó meg kipótolja az IQ-t: értelmes keresési kulcsszavakat ír be, hogy találatot kapjon :)

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.
63

Túlzás

Pepita · 2012. Szep. 30. (V), 02.25
Azért - szerintem - nagyon is van köze mindennek és mindenhez. Ha nem lennék fejlesztő, akkor is arra tippelnék, hogy Newton bácsinak igaza lehetett a hatás-ellenhatás dologgal... Nem lehet kiragadni a böngészőfejlesztést, mert ezt látja a Júzer, te olyan HTML-t akarsz csinálni, ami tetszik ebben-abban a böngészőben neki, kereső szintúgy "el akarja adni magát" u.ebben a böngészőben. És akkor a ráfordított munkaerőről nem is beszéltem, amit hasznosabban is lehetne felhasználni. De mindegy, nem akarlak feltétlenül meggyőzni, már az is sokat jelent, ha gondolkodunk rajta.
65

Köszönöm, hogy érdemben

Hidvégi Gábor · 2012. Szep. 30. (V), 08.56
Köszönöm, hogy érdemben foglalkoztál a témával. A következtetést abból vontam le, hogy:
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.
58

Kemény...

Pepita · 2012. Szep. 30. (V), 01.08
Szó ami szó, elég parázs vitát kiváltottál... De nekem tetszik.
Csak azt sajnálom, hogy itt is igaz a mondás:
Szólj igazat! - beverik a fejedet.
66

bevert fej

dyuri · 2012. Szep. 30. (V), 12.28
Általában az a baj, hogy ilyen erősen szubjektív témáknál mindenki igazat mond, kezében baseballütővel.
67

Lásd még Tas vezér vs. Ond...

eddig bírtam szó nélkül · 2012. Szep. 30. (V), 13.19
Lásd még Tas vezér vs. Ond... :-)
72

Tévedés! :)

Pepita · 2012. Szep. 30. (V), 23.42
dyuri: Nincs baseballütőm - viszont igazam van. :) Ha túl sokan "emberkednek velem", akkor szerzek ütőt is. :)
HZ: Szerintem Tass. És - ha jól tudom - nem valószínű, hogy volt baseballütőjük... :)
75

Ennél hitelesebb forrást nem

eddig bírtam szó nélkül · 2012. Okt. 1. (H), 09.44
Ennél hitelesebb forrást nem tudok :-)
És Tas vezérnek volt egy (funkcióját tekintve) baseball ütőre hasonlító buzogánya! ;-)
78

Hozzá akarok szólni

Gixx · 2012. Okt. 1. (H), 15.30
Nem volt türelmem minden hozzászólást elolvasni, túl hosszú, de én is szeretnék hozzájárulni a véleményemmel a dologhoz.

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ó:

body > article > section#chapter1{ counter-reset: level_1;   }
body > article > section#chapter2{ counter-reset: level_1 1; }
body > article > section#chapter3{ counter-reset: level_1 2; }
body > article > section h1:before{
	counter-increment: level_1;
	content: "Chapter " counter(level_1) ": ";
}
hasznos dolog, dokumentáció publikáláskor. Vagy, akármi másra, lásd nálam.

- 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.
79

rengetegen használnak még

inf3rno · 2012. Okt. 2. (K), 10.10
rengetegen használnak még Windows XP-t, amire legfeljebb 8-as Internet Explorert lehet feltelepíteni


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".
80

Ajánlom figyelmedbe ezt a

Hidvégi Gábor · 2012. Okt. 2. (K), 10.45
Ajánlom figyelmedbe ezt a nemrég megjelent blogmarkot. Saját cégnél én sem engedném meg, hogy az átlag, számítástechnikához nem értő dolgozó bármit feltelepítsen engedély nélkül, akár egy böngészőt.
Google's Web browser Chrome thrilled with an extremely fast site rendering, a sleek design and innovative features. But it also gets critic from data protection specialists , for reasons such as creating a unique user ID or the submission of entries to Google to generate suggestions. SRWare Iron is a real alternative. The browser is based on the Chromium-source and offers the same features as Chrome - but without the critical points that the privacy concern.
SRWare Iron: The Browser of the future
81

Ácsi

Gixx · 2012. Okt. 2. (K), 12.50
Ha a cégnél tiltva van, hogy bárki bármit felrakjon, az tökéletesen rendben van, így kell eljárni. DE:

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.
83

A kettes ponttal kapcsolatban

Hidvégi Gábor · 2012. Okt. 2. (K), 13.24
A kettes ponttal kapcsolatban kérdezném, hogy hány év rendszergazdai tapasztalattal rendelkezel, ha szerinted ezer gépre ennyire egyszerű felrakni egy új szoftvert?

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.
84

Rendszergazda

Poetro · 2012. Okt. 2. (K), 13.35
Ha valaki jó Windows-os rendszergazda, akkor vannak neki eszközei, hogy akármit felrakjon a gépekre teljesen automatikusan. Ha mondjuk Linux-os a rendszer akkor pedig csak le kell töltenie egy ilyen eszközt.
85

Windows-on nulla

eddig bírtam szó nélkül · 2012. Okt. 2. (K), 13.52
Windows-on nulla tapasztalatom van, csak "kliensként" láttam működni a dolgot, de...
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)
86

NOPblog

Hidvégi Gábor · 2012. Okt. 2. (K), 14.15
De
94

Tegnap még ment, ma reggel

eddig bírtam szó nélkül · 2012. Okt. 3. (Sze), 09.23
Tegnap még ment, ma reggel meg koppantam egy nagyot... :-(

update: megint működik.
87

Nyilván túloztam

Gixx · 2012. Okt. 2. (K), 14.43
De így vagy úgy, fel lehet rakni az új böngészőket is.

É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.
88

Félreérted

Hidvégi Gábor · 2012. Okt. 2. (K), 15.28
Az írásnak az a mondanivalója, hogy a szemantikával kellett volna az utóbbi tizenhárom évben foglalkozni, és nem a vizuális fejlesztéssel (ráadásul az újdonságok túlnyomó többségét a régi böngészőkön is meg lehet valósítani meglévő eszközökkel), mert összehasonlíthatatlanul többet nyerünk vele. Tizenhárom elpazarolt év... ez több, mint az eddigi életem harmada; nem is gondolok bele, mert elsírom magam.
90

Milyen fejlesztést igényel a

Joó Ádám · 2012. Okt. 2. (K), 21.26
Milyen fejlesztést igényel a szemantikus web a böngészőktől?
91

Semmilyet

Hidvégi Gábor · 2012. Okt. 2. (K), 21.35
Egy Lynx is megteszi : )
92

Akkor milyen erőforrásokat

Joó Ádám · 2012. Okt. 2. (K), 22.08
Akkor milyen erőforrásokat von el a megjelenítés fejlesztése a keresés fejlesztésétől?
93

Az összeset

Hidvégi Gábor · 2012. Okt. 3. (Sze), 06.40
BlaZe ugyanezt kérdezte a 43-as hozzászólásában kezdődő szálban, a 74-ig bezárólag, ha nem gond, nem válaszolom meg mégegyszer, 71-ben van az igazság (ha a felhasználói oldalt nézed).
97

Kizárja? Vagy csak munkaórát

Joó Ádám · 2012. Okt. 3. (Sze), 14.45
Kizárja? Vagy csak munkaórát / energiát vesz el tőle?


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?
98

Azt hittem, hogy a

Hidvégi Gábor · 2012. Okt. 3. (Sze), 15.05
Azt hittem, hogy a kliensoldali fejlesztőkre gondolsz. A fentiek tekintetében egyik sem befolyásolja a másikat különösebben.
99

Tehát nem a böngészők a

Joó Ádám · 2012. Okt. 3. (Sze), 16.25
Tehát nem a böngészők a bűnösök. De a webfejlesztők sem, hisz miért használnának (talán teljesen még készen sem álló) szemantikus technológiát, ha a keresők nem foglalkoznak vele?
100

Melyik volt előbb, a tyúk

Hidvégi Gábor · 2012. Okt. 3. (Sze), 17.16
Melyik volt előbb, a tyúk vagy a tojás? A HTML 5 sincs kész, mégis a böngészők sorra építik be a különböző funkciókat, ki előbb, ki később. És ha az X kereső nem ismeri a szemantikus tag-eket, akkor mi van? Majd jön egy másik, aki meg igen. A fejlesztők felelőssége a prioritások felismerése, és a változások kieszközlése, hisz elvileg a súlyuk megvan hozzá, nem tollpihék.
101

Hogyan kellene a

Joó Ádám · 2012. Okt. 3. (Sze), 17.42
Hogyan kellene a fejlesztőknek kieszközölni a változásokat?
118

A kérdésedre később fogok

Hidvégi Gábor · 2012. Okt. 9. (K), 21.57
A kérdésedre később fogok visszatérni.
102

[OFF] A tojás

Gixx · 2012. Okt. 4. (Cs), 07.33
Feltéve, hogy hiszünk az evolúcióban.

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]
95

Kifogás

Hidvégi Gábor · 2012. Okt. 3. (Sze), 09.56
Miért nem váltunk IE6-ról? - volt blogmark is.
96

Nem ez a kifogás

Gixx · 2012. Okt. 3. (Sze), 11.36
Írtam is, hogy ha IE6-tól függő dolgai vannak, akkor legyen, maradjon IE6, de korlátozzák csak arra, amire csak az jó.

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ő.
89

Mellékszál

deejayy · 2012. Okt. 2. (K), 18.21
Mellékszál: a króm, az opera és a foxi is telepíthető rendszergazdai jog nélkü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.
82

jReject

Gixx · 2012. Okt. 2. (K), 12.56
103

Nocsak, vegre valaki itt is

saxus · 2012. Okt. 6. (Szo), 18.20
Nocsak, vegre valaki itt is ki merte mondani, hogy a HTML5 egy bullshit?

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.
104

Megoldás?

Pepita · 2012. Okt. 7. (V), 00.00
Legnagyobb részt egyetértek veled is, ahogy Gáborral is, de mi a megoldás? (Persze nem a kidolgozott szabványt várom tőletek / tőlünk, csak ötletet, irányvonalat.)
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".

Miert nem csak annyi van ott, hogy van egy gombom...

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.
106

Tanuljunk a meglévő technológiákból

saxus · 2012. Okt. 8. (H), 00.07
Nagyon egyszerű: cipőt a cipőboltbó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.
107

Majdnem

Pepita · 2012. Okt. 8. (H), 03.03
Hasonló irányban én is gondolkodtam, de mindig visszajutottam a "jóöreg" Delphis-Windowsos TCP/IP kliens-szerver történethez. Érdekes, hogy komponensek kapcsán te is a Delphi VCL-t (is) említed.

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.
108

Nem lehet meguszni

saxus · 2012. Okt. 8. (H), 09.02
Ezt az ervet nem tudom elfogadni. Most is le kell kuldeni a JS klienskonyvtarakat, CSS-t, nagy weblap/webalkalmazas eseten ez nem is kis kodmennyiseg. Kulonbseg az, hogy csak egyszer kell mig HTML-nel mindig ujra es ujra, amikor egy weblapot megjelenitunk. Kepek mellett amugy is elenyeszo mennyiseg.

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.
147

És a cache?

Pepita · 2012. Okt. 10. (Sze), 19.01
Kulonbseg az, hogy csak egyszer kell mig HTML-nel mindig ujra es ujra
Persze, csak amíg a (valamennyire) szabványos HTML-CSS-JS-t küldöd többször, addig az egyforma elemek cache-elve lesznek. (Ugye okos ember használ cache-t, a buta meg meghagyja alapértelmezetten..)

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.
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.
Igen, csak nem mindegy, hogy mikor. Elsőre gáz (mármint most érkezett az oldalra), márpedig ha hagyományos cache-re építesz, akkor pont az első oldaltöltés lesz hatalmas. És emiatt nem várja meg a másodikat... Ezért kanyarodtam (én) mindig vissza - gondolatban - a régi kliens-szerver dologra, mert ez volt az a pont, hogy "OK, a vezérlők-komponensek / kliens progi nagyrésze legyen a Júzernél".

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.)
153

A Microsoftnak tizennégy éve

Hidvégi Gábor · 2012. Okt. 10. (Sze), 21.18
A Microsoftnak tizennégy éve volt egy Delphi VCL-szerű, komponensalapú fejlesztést segítő webes eszköze, de a népnek nem kellett. Most várni kell egy újabb évtizedet, mire valaki ismét feltalálja a kereket.
105

Így van

Hidvégi Gábor · 2012. Okt. 7. (V), 09.37
Jól látod a dolgokat. A HTML megjelenítésre jól használható, de adatok tárolására korlátozottan alkalmas, mert nem feltétlenül strukturált, és hibatűrő, azaz nem triviális feladat hozzá parsert írni.

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.
109

Aki ezt elhiszi az nem kodolt

Tyrael · 2012. Okt. 8. (H), 10.43
Aki ezt elhiszi az nem kodolt meg komolyabb oldalt vagy webalkalmazast.

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.

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.

igen, jo esetben egy a/button taget meg bele a szovegnek egy spant

Miert? Miert nem csak annyi van ott, hogy van egy gombom es minden egyeb design beli elem elkulonitve?

ez egy jo kerdes, miert nem igy csinalod? pont ez lenne a lenyege az altalad hianyolt adat/megjelenes/mukodes szeparacionak.

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.

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.

Csak a HTML ilyen agyhalott koncepcio, hogy egybebarmol mindent.

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.)

Egyebkent lett volna erre is megoldas, XML+XSLT

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?

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.

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
110

azert kap a csicsa jelenleg,

Hidvégi Gábor · 2012. Okt. 8. (H), 11.16
azert kap a csicsa jelenleg, mert a megrendelot, atlag felhasznalot ez erdekli kozvetlenul
a webet, mint mindent az egész életben, ugyanúgy az éppen aktuális divatok irányítják. Egy átlagos fejlesztőnek nincs ideje és energiája objektíven értelmezni és elemezni, amit az épp aktuális blogokon, szakmai csatornákon olvas, ezért fenntartások nélkül elfogadja azt, amit elég sokszor lát. A megrendelőnek közvetlenül nem az az érdeke, hogy látványos legyen az oldala, hanem, hogy megfelelő eladást generáljon. Mivel a jelenlegi eszközök nem teszik lehetővé, hogy pontosan azokhoz jusson el a terméke, akinek szánja, kénytelen egy-két szóra optimalizálni az oldalát, mert ha ennél többet ír be valaki a keresőbe, teljesen random találatokat fog kapni.

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.
111

az atlag fejleszto nem all

saxus · 2012. Okt. 8. (H), 16.58
az atlag fejleszto nem all azon a szinten


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.

button


Csak egy példa volt, lehet cifrábbakat is kitalálni. Pl. komplett hozzászólás, komplett szerkesztőablak, stb.

pontosan itt mire gondolsz?


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.

az a web sajatossaga


Erről beszélek: ideje lenne ezeket felülvizsgálni. Azzal, hogy mondogatjuk, hogy "ez ilyen", azzal nem jutunk előrébb.

gondolom itt most az asztali alkalmazasokkal allitod szembe a html-t.


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.

XML+XSLT


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ó.

tehat pl. az altalad emlitett gmail-en hogyan segitene ha az outputot xml+xslt segitsegevel generalnad?


Félreérted: nem egy meglévő HTML outputot akarok generálni. Templatezni akarok és a szerkezetet az adatoktól szétválasztani.

azert kap a csicsa jelenleg, mert a megrendelot, atlag felhasznalot ez erdekli kozvetlenul.


Hát... Főnökömtől a Facebookot meg a Pageranket hallom folyton, nem a HTML5-öt meg a CSS3-mat.

en szemely szerint nem latom akkorana a problemat, a web jobbara organikusan fejlodik, es az ajanlasok is a felmerulo igenyekre/problemakra valaszul szuletnek.


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. :)
112

Nos, erre azt tudom mondani,

Tyrael · 2012. Okt. 9. (K), 13.23
Nos, erre azt tudom mondani, hogy hulljon a férgese.

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.

Csak egy példa volt, lehet cifrábbakat is kitalálni. Pl. komplett hozzászólás, komplett szerkesztőablak, stb.

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.

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.

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.

Erről beszélek: ideje lenne ezeket felülvizsgálni. Azzal, hogy mondogatjuk, hogy "ez ilyen", azzal nem jutunk előrébb.

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.

Valamennyire. ... De most nem a másikra kell mutogatni, hanem a webről van szó: lenne mit tanulnia a meglévő desktop alkalmazásoktól.

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.

De az irány mindenesetre jó.

es eleg elterjedt is, viszont azert annak is megvan az oka, hogy az MS miert nyit a html(5)+js fele is az alkalmazasfejlesztesben.

Félreérted: nem egy meglévő HTML outputot akarok generálni. Templatezni akarok és a szerkezetet az adatoktól szétválasztani.

igen, kicsit feljebb mar rajottem.

Hát... Főnökömtől a Facebookot meg a Pageranket hallom folyton, nem a HTML5-öt meg a CSS3-mat.

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.

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. :)

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
113

Erős érv

Hidvégi Gábor · 2012. Okt. 9. (K), 15.16
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
Egymilliárd légy nem tévedhet : ) Azért nálunk komolyabb emberek is foglalkoznak a szemantikus webbel és/vagy az adatok szétválasztásával.
114

esetleg valamit a

Tyrael · 2012. Okt. 9. (K), 15.33
esetleg valamit a temahoz?

Tyrael
115

Egyetértek Saxussal, magával

Hidvégi Gábor · 2012. Okt. 9. (K), 18.27
Egyetértek Saxussal, magával a HTTP protokollal is vannak gondok, de úgy gondolom, hogy maradjunk a realitás talaján, és a problémát oldjuk meg meglévő technológiákkal.

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:
<div itemscope itemtype="http://schema.org/Person">
  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.
<person>
  <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.

viszont azert annak is megvan az oka, hogy az MS miert nyit a html(5)+js fele is az alkalmazasfejlesztesben
A Microsoft sokszor követőpolitikát alkalmaz, azaz megvárja, amíg kijön valami új, és elkészíti a saját verzióját. Pusztán HTML5 + JS kombinációval nagyon korlátozott alkalmazásokat készíthetsz, ha el szeretnéd érni az operációs rendszer nyújtotta funkciókat, mondjuk a kamerát, akkor MS specifikus objektumokon keresztül teheted ezt meg. Meglovagolják az aktuális divathullámot, és magukhoz próbálják kötni a felhasználókat, őket nem érdekli az internet és a keresés jövője.

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
A középkorban az emberek azt hitték, hogy a Föld lapos, és egész jól eléldegéltek így. Ezzel a gondolatmenettel élhetnénk mi is ugyanúgy.

szerintem folyamatosan fejlodik a web
Az alapok (HTML, HTTP) nem változtak az utóbbi 21 évben. Ne zavarjon az meg, hogy látványosabb lett minden, meg nőtt a sebesség, a web nem változott egy dekát sem.

vannak olyan teruletek, amik nem kapnak eleg figyelmet (pl. szemantikus web), de ez reszben azert is van igy, mert nincs ra igeny
Mindenkinek van igénye rá, hogy ha keres valamit a neten, akkor megtalálja. Szemantikus web nélkül a keresés hatékonysága fordítottan arányos a megadott kulcsszavak számával. Az emberek nem pusztán arra keresnének, hogy "csöcs", hanem arra, hogy "kerek csöcs, ami egy magas, sportos, barnított bőrű, szőke nőre van ragasztva".

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
Meglévő technológiákkal, visszafele kompatibilisen megvalósítható a szemantikus web.
117

A HTML-lel az a baj, hogy

Tyrael · 2012. Okt. 9. (K), 20.43
A HTML-lel az a baj, hogy alapvetően emberi fogyasztásra és adatok megjelenítésére tervezték

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:
HTML has been developed with the vision that all manner of devices should be able to use information on the Web: PCs with graphics displays of varying resolution and color depths, cellular telephones, hand held devices, devices for speech for output and input, computers with high or low bandwidth, and so on.


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).

Egyrészt a hibatűrés miatt nem triviális feladat parsert írni hozzá (tudsz ajánlani PHP-ban írt HTML 5 parsert?)

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.

másrészt ha scriptből szeretnénk az oldalon megjelenített adatokkal kezdeni valamit, az sem egyszerű. Íme, egy példa: ...
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.

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.


lasd fent, lehetne ugyanolyan egyszeru a kimenet, ha nem szabotalnad szandekosan, nem erzem fair-nek az osszehasonlitast.

Mivel az XML szigorú, ha hiba van, a feldolgozó kiakad, azaz minőségi munkát kell kiadnod a kezedből.

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.

A Microsoft sokszor követőpolitikát alkalmaz, azaz megvárja, amíg kijön valami új, és elkészíti a saját verzióját.

nem vagyok benne hogy ez tudatos, es nem csak arrol van szo, hogy szeretnenek, de sokszor nem tudnak lepest tartani az elen jarokkal.

A középkorban az emberek azt hitték, hogy a Föld lapos, és egész jól eléldegéltek így. Ezzel a gondolatmenettel élhetnénk mi is ugyanúgy.

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.

Az alapok (HTML, HTTP) nem változtak az utóbbi 21 évben. Ne zavarjon az meg, hogy látványosabb lett minden, meg nőtt a sebesség, a web nem változott egy dekát sem.

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.

Mindenkinek van igénye rá, hogy ha keres valamit a neten, akkor megtalálja. Szemantikus web nélkül a keresés hatékonysága fordítottan arányos a megadott kulcsszavak számával. Az emberek nem pusztán arra keresnének, hogy "csöcs", hanem arra, hogy "kerek csöcs, ami egy magas, sportos, barnított bőrű, szőke nőre van ragasztva".

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.

Meglévő technológiákkal, visszafele kompatibilisen megvalósítható a szemantikus web.

errol itt meg nem lattam konkret javaslatot, de en is ilyen iranyban tudom elkepzelni a javulast.

Tyrael
119

A HTML-lel az a baj, hogy

Hidvégi Gábor · 2012. Okt. 9. (K), 22.15
A HTML-lel az a baj, hogy alapvetően emberi fogyasztásra és adatok megjelenítésére tervezték - errol tudnal valami linket?

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 volt szuksegem, gyorsan korulnezve a html5lib-t ajanlottak tobb helyen
Én is ezt találtam meg, egy erősen alfa állapotú szoftver, ráadásul azóta változhatott a szintaktika is. XML feldolgozásra meg már bő egy évtizede vannak kiforrott eszközeink.

A markup kulonbozik a ket peldaban, pedig a vizualis kiemeleshez erre nem lenne szukseg, ha megfeleloen hasznalnad a jelenleg is elerheto eszkozoket
Direkt. Akár egy HTML-en belül is két ugyanolyan típusú adat megjelenítéséhez teljesen már markup tartozhat.

A flashes animalast nem teljesen ertem
Most, mivel az adatok "bele vannak égetve" a HTML-be, egyféleképp tudjuk őket megjeleníteni. Ha az adatok szeparáltan lennének, akkor nagyon egyszerűen megoldható lenne, hogy ugyanabból az adatforrásból táplákozzon két megjelenítő, az egyik HTML, a másik egy Flash objektum.

De a 21 evvel ezelotti HTTP es HTML speci eg es fold a mai (es a hamarosan megjeleno) verziokkal kapcsolatban
Az alapok ugyanazok. HTTP-ben GET, POST, HTML-ben pedig <p>-k és <body>-k, és az adatok ugyanúgy egyben vannak a megjelenítést leíró kóddal. A többi csak díszítés.

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
A szemantikus web első lépcsőjéhez nem kell semmilyen mesterséges intelligencia, ez a legszebb.

ha azt hiszed, hogy a jelenlegi webes kereses vallalhatatlan, akkor ezek szerint nem neteztel az altavistas/altavizslas idokben
A keresés vállalhatatlan, mivel ugyanazokra az alapokra építkezik, csak amiatt lett elhanyagolható mértékben jobb, mert nagyobb adatbázisra alapul.
120

html5 feldolgozasra meg nem

saxus · 2012. Okt. 9. (K), 22.32
html5 feldolgozasra meg nem volt szuksegem


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ő
<br>
-nél meg leszek lőve.

a szigorusag itt sem feltetlen a szabvanybol ered


Hanem abból ered a hiánya, hogy a böngészők minden hulladékot megpróbálnak megjeleníteni.

nem vagyok benne hogy ez tudatos, es nem csak arrol van szo, hogy szeretnenek, de sokszor nem tudnak lepest tartani az elen jarokkal.


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.
116

es nem cafolod azt a

saxus · 2012. Okt. 9. (K), 20.34
es nem cafolod azt a kijelentesemet, hogy mar most is megvannak az eszkozok


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.

akkor kijelentheto, hogy te epp ilyen fejleszto vagy, mint akinek itt a palyavaltast tanacsolod?


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?)

mint irtam nem ismerem elegge a gmail felepiteset


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.

nem vagyok meggyozve rola, hogy minden olyan vivmany, ami miatt a desktopfejlesztes kenyelmesebb atemelheto a webrol, pont az eltero felepites miatt.


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 :)

hogy a jelenlegi felhasznaloi viselkedesek alapjan mire van igenyuk az embereknek.


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.
149

Nem divat

Pepita · 2012. Okt. 10. (Sze), 19.51
(Ez mióta divat itt a WL-en ilyen szinten?)
Ez egyáltalán nem divat, csak ez az emberke ilyen. Engem már többször "megtalált", eléggé kezdem is unni. Most te voltál soron. :)
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.
152

Prog.hu-n divat élből

inf3rno · 2012. Okt. 10. (Sze), 20.31
Prog.hu-n újabban divat élből lehülyézni az embert, ő is oda szokott írogatni, lehet, hogy hatással volt rá az ottani környezet. Egyébként én nem erről az oldaláról ismertem eddig...

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...
157

Tyrael, Saxus, Pepita,

Joó Ádám · 2012. Okt. 11. (Cs), 12.26
Tyrael, Saxus, Pepita, Inf3rno,

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.
165

Rendben,

Pepita · 2012. Okt. 11. (Cs), 20.55
én tudomásul vettem.
Amennyiben velem sem szórakozik senki, én is béketűrő voltam, vagyok és leszek.
148

desktop-web

Pepita · 2012. Okt. 10. (Sze), 19.24
de a kedvencem, amikor a desktop .net koderek keszitenek asztali alkalmazast, ugy hogy fogalmuk sincs a web mukodeserol...
Miért, kellene, hogy legyen fogalma? Vagy én nem tudom, mi az, hogy asztali alkalmazás?

azert kap a csicsa jelenleg, mert a megrendelot, atlag felhasznalot ez erdekli kozvetlenul.
A felhasználót már nem a csicsa érdekli, hanem a használhatóság - amennyire én tudom. Egyre többen váltanak asztali gépről is mobil-design-ra, ha ez nem egy mobilalkalmazás használatát / megvételét jelenti, csak design-egyszerűsítést.

É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.
121

Hiába olvasom ezt a témát...

T.G · 2012. Okt. 10. (Sze), 07.41
Hiába olvasom ezt a témát és az okfejtéseket még azt sem értem, hogy a lelkes HTML5 ellenes brigádnak mi a pontos baja.

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.
123

Hamarosan

Hidvégi Gábor · 2012. Okt. 10. (Sze), 08.42
A következő írásomban felelek a kérdésedre, hogy milyen előnyökkel járna a szemantikus web.
122

Ha már a szemantikus webnél

deejayy · 2012. Okt. 10. (Sze), 08.15
Ha már a szemantikus webnél tartunk, hadd hozzak egy példát én is.

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? :)
124

A processzorok összevetéséhez

Hidvégi Gábor · 2012. Okt. 10. (Sze), 08.53
A processzorok összevetéséhez ugye egy hardveres weboldal tesztjeit kell most megnézned. De, ha az adott oldal a grafikonjait nem csak képként szúrja csak be (egy példa), hanem mondjuk egy általános (XML) táblázatban is, akkor már készíthetsz egy alkalmazást, amivel összegyűjtöd az adatokat, amivel az összes CPU sebességét össze tudod hasonlítani.
125

deejayy problémája épp az,

eddig bírtam szó nélkül · 2012. Okt. 10. (Sze), 09.18
deejayy problémája épp az, amit én is emlegettem neked pár hónapja: nincsenek szabványosítva a világ objektumainak paramétereire használt elnevezések, anélkül meg max. valami mesterséges intelligencia képes felismerni, hogy mi micsoda egy-egy adathalmazban.

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...
126

nincsenek szabványosítva a

Hidvégi Gábor · 2012. Okt. 10. (Sze), 09.47
nincsenek szabványosítva a világ objektumainak paramétereire használt elnevezések
Akkor szabványosítani kell.

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
Ti ezt ismételgetitek, én pedig azt, hogy

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.
128

amely repülőjegyekre keres

Poetro · 2012. Okt. 10. (Sze), 09.54
amely repülőjegyekre keres ajánlatokat n darab website-on

Ehhez nem kell website-ot parsolni, vannak rá kész API-k, amiket meg lehet hívni.
131

Lehet, hogy most így van,

Hidvégi Gábor · 2012. Okt. 10. (Sze), 09.56
Lehet, hogy most így van, jópár éve még hívtak oda dolgozni, a feladat pont ilyen parserek írása lett volna.
132

SABRE

Poetro · 2012. Okt. 10. (Sze), 09.59
A SABRE nevű rendszert az 1950-es években fejlesztették ki, és azóta is jó pár egyéb GSD rendszert fejlesztettek hasonló céllal. Ezek már pár évtizede működnek.
130

Ha a crawlerek tudnák, amit

BlaZe · 2012. Okt. 10. (Sze), 09.56
Ha a crawlerek tudnák, amit mondasz, mi szükség lenne a webre? Elég lenne egy adatbázis hálózat, meg egy kereső, és mindent a keresőben néznél meg. Ez nem a weboldal forgalom növekedéshez vezet...
134

Végeredményben igen. A

Hidvégi Gábor · 2012. Okt. 10. (Sze), 10.04
Végeredményben igen. A keresések nagyon hatékonyak lennének, de miért látogatnának el az emberek az oldaladra? Például azért, mert ha mondjuk X terméket meg szeretnének venni, akkor fel kell vegyék veled a kapcsolatot. Továbbá, ahogy a keresőben most is csak két sornyi információ jelenik meg minden találatról, egy szemantikus keresőből is el kéne navigálnod a céloldalra, hogy mindent elolvashass.

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.
137

Webshopoknál ezt még

BlaZe · 2012. Okt. 10. (Sze), 10.25
Webshopoknál ezt még valamennyire elfogadom, bár ha már minden szabványos, a megrendelést lefedhetné egy API is. És az is egy érdekes kérdés, hogy ha mindenki mindent ugyanolyan áron árul, akkor kit hoz ki a kereső és miért? Ha meg valaki nem a legolcsóbb, senki nem vásárolna nála.

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.
138

Ha keresel valamit, sosem

Hidvégi Gábor · 2012. Okt. 10. (Sze), 10.33
Ha keresel valamit, sosem egyvalami érdekel csak, erre korábban írtam a csöcsös példát. Lehet valami a legolcsóbb, ha az ország másik felében van az üzlet, és a postaköltség miatt többe kerül, mintha elmennél a szomszéd városba magad. De az is lehet, hogy nem tudsz kártyával fizetni és így tovább, ezerféleképp lehet szűkíteni az adatok alapján a találati listát.

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>).
150

Így van

Pepita · 2012. Okt. 10. (Sze), 20.08
Itt a lényeg, de egy korábbi gondolatoddal vitatkoznék.
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.
127

Ez semennyire nem válasz a

BlaZe · 2012. Okt. 10. (Sze), 09.51
Ez semennyire nem válasz a felvetésére. Az XML-től még nem lesz 1 cikk mindenhol ugyanúgy leírva a világ összes weboldalán. Attól még ugyanúgy kellhet oldalanként saját parsert írnod, hogy lásd ki kicsoda. Illetve nem válasz az új paraméter kérdésére sem. Amiről te beszélsz, az szerintem egy eléggé utópisztikus dolog. A tudomány a jelenlegi állása (AI) alapján egyszerűen nem képes rá.
129

Természetesen kell egy

Hidvégi Gábor · 2012. Okt. 10. (Sze), 09.55
Természetesen kell egy központi adatbázis, ahol meg tudom nézni, hogy az egyes objektumoknak milyen tulajdonságai vannak. A HTML-ben is mindenki <p>-t használ egy paragrafus megjelenítéséhez.
133

És ki tartja karban A

BlaZe · 2012. Okt. 10. (Sze), 10.01
És ki tartja karban A központi adatbázist? A világon mindent leírni XML-lel? Azontúl, hogy ez az adatbázis végtelen méretű lenne, végtelen mennyiségű ember is kéne a karbantartásához. Ezért utópisztikus ez az egész. És ezt te is nagyon jól tudod :)
136

És ki tartja karban A

Hidvégi Gábor · 2012. Okt. 10. (Sze), 10.19
És ki tartja karban A központi adatbázist?
Például egy nonprofit társulat.

A világon mindent leírni XML-lel?
Most HTML-ben van leírva minden, ami nagyjából ugyanaz.
Szemantikus funkciókkal bővülhet a Google kereső
keresőmotor jelentősen jobban tud majd keresési kifejezéseket kezelni, köszönhetően annak az adatbázisnak, ami több száz millió “entitást” ismer, többek közt embereket, helyeket, tárgyakat
Tehát már létezik ilyen, csak ezzel ugye az a baj, hogy egy zárt adatbázis.
135

Igen, elnézést, nem írtam le,

deejayy · 2012. Okt. 10. (Sze), 10.15
Igen, elnézést, nem írtam le, hogy mire példa a felsorolt CPU lista. Tegyük fel, hogy ezek ugyanazon processzortípus leírásai, csak ahány weboldalon megvan, annyiféleképpen írták le. Az összehasonlítás már egy másik szint, egyelőre a feldolgozásig sem jutnánk el ilyen adatokkal.
139

Szerintem itt beszelunk el

saxus · 2012. Okt. 10. (Sze), 10.51
Szerintem itt beszelunk el egymas mellett: en nem a HTML-be akarok mindenfele objektumhoz valamilyen azt leiro strukturat, hanem pont az adott objektum leirasat kiemelni onnan.

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.
140

Hozzáállás

Hidvégi Gábor · 2012. Okt. 10. (Sze), 11.02
Tisztelt kollegák!

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.
141

Ha nyilvánvalóan hülyeséget

eddig bírtam szó nélkül · 2012. Okt. 10. (Sze), 11.24
Ha nyilvánvalóan hülyeséget kér a vezető, akkor valahogy tudtára kell adni.
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...
142

Az, hogy az adatokat

Hidvégi Gábor · 2012. Okt. 10. (Sze), 11.38
Az, hogy az adatokat könnyebben el lehet érni egy weboldalon, nem jelenti azt, hogy el is lophatom őket. Egyrészt ez két pillanat alatt kiderül, másrészt a keresők most is így működnek, lementenek mindent, de megjelenítik a forrást.
143

offtopik

eddig bírtam szó nélkül · 2012. Okt. 10. (Sze), 12.07
"A keresők most így..."
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ó.
144

bing

Hidvégi Gábor · 2012. Okt. 10. (Sze), 12.20
bing - nálam olyanokat ad vissza.
145

Valóban, ilyen szempontból

eddig bírtam szó nélkül · 2012. Okt. 10. (Sze), 12.26
Valóban, ilyen szempontból tényleg használhatóbbnak látszik.
(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)
151

És nem örülsz neki?!

Pepita · 2012. Okt. 10. (Sze), 20.19
<OFF>
a gúgli teleszemeteli a találati listáját olyasmikkel, amiknek semmi közük az általam keresett dologhoz
Tudhatnád már, T. Kolléga, hogy Gugli sokkal jobban tudja nálad, hogy mit szeretnél keresni... :)
146

eddig bírtam szó nélkül :D

szabo.b.gabor · 2012. Okt. 10. (Sze), 15.55
No értem én, hogy szemantikus web, értem én hogy xml-ben leírok valamit.

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.
154

arról nem is beszélve

szaky · 2012. Okt. 11. (Cs), 11.14
hogy körülbelül a harmadik percben jelenne meg az az oldal, ahol csak a poén kedvéért felvettek 3.2*10^8 darab kamu objektumot, csak hogy kiadja a kereső bármilyen keresésre.
155

Nincs új a nap alatt

Hidvégi Gábor · 2012. Okt. 11. (Cs), 11.18
160

Egy pont nekem

szaky · 2012. Okt. 11. (Cs), 13.18
Igen, ez is azt igazolja, hogy ha megvalósul a szemantikus web, nem sok változást hoz az életünkbe, ugyanúgy tele lesz szeméttel a találati lista.

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)
166

Kettő Gábornak

Pepita · 2012. Okt. 11. (Cs), 21.04
1.:
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
Na, ez is egy olyan dolog, amit Gábor úgy fogalmazott meg, hogy az üzletpolitikán is változtatni kell. Magyarul: nem átb...i kell a vevőt, hanem korrekt ajánlatot(kat) tenni.

2.:
Ha mégis elterjed, akkor létrehoznak egy soktízezres, kamu szortimentet: pl jelenleg nincs árukészleten...
És be is fürdi rögtön a kamut, mert:
- 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...
172

Mondom, az elmélet szép.

szaky · 2012. Okt. 12. (P), 08.18
nem átb...i kell a vevőt, hanem korrekt ajánlatot(kat) tenni.

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.

A vásárló soha többet nem klattyol az ő domain-jére;

Pont ez az infó veszik el a felhasználó felé, ha minden adat be van dobva a közösbe.

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

É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?
190

Gyakorlat

Pepita · 2012. Okt. 14. (V), 15.10
A kereskedőkön nem lesz nyomás, hogy ilyen irányba változtassák az üzletpolitikájukat.
Az önmagában nem elég, hogy a keresők is és a vásárlók is hátrébb sorolják?..

A jó kereskedő el tudja adni a drágább cuccot úgy, hogy elégedett lesz a vásárló is.
Ha kicsit megpróbálod a kereskedő, vagy inkább a vásárló szemével nézni a dolgot, rögtön rájössz: nem az ártól függ az áru minősége, viszont a vásárló elégedettsége elsősorban a minőségtől, és csak másodsorban az ártól függ - legtöbbször. Ilyenformán a mai reklámok / webshopok tulnyomó többsége egy kész átverés show, mivel arra helyezik a hangsúlyt, hogy ez szinte ingyen van, meg miket kapsz még ingyen, stb. A jó kereskedő az, aki emberszámba veszi a vásárlót (is). Én azt látom, hogy vannak cégek, amik erre mennek, lehet ebből komoly előnyt is kovácsolni.

Pont ez az infó veszik el a felhasználó felé, ha minden adat be van dobva a közösbe.
Kit érdekel? Csak a kereskedőt...

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.
191

A gyakorlat... :)

T.G · 2012. Okt. 14. (V), 15.17
Na, ez tényleg szép lenne... keressünk rá a legolcsóbb termékre:

<olcsó>
    <olcsó>
        <olcsó>
            <olcsó>
                ...
            </olcsó>
        </olcsó>
    </olcsó>
</olcsó>
:)
192

Bár ez lenne a gyakorlat

szaky · 2012. Okt. 15. (H), 10.56
Az önmagában nem elég, hogy a keresők is és a vásárlók is hátrébb sorolják?

Elég lenne, de nem teszik.

Kit érdekel? Csak a kereskedőt...

És ki csináltatja a honlapot? Ki mondja meg, hogy milyen legyen? Na? Na..?

SEO mágusok: én nem tudom, értelmetlen "csavarintásokba" én nem kezdek (...)

Te nem, más meg igen. És aki igen, az sikeresebb (lesz).

Persze, lesznek / lehetnek próbálkozók, de a szemantikus web ésszerű megvalósításával sokkal nehezebb lesz trükközni is.

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.
199

Jól elvagyunk...

Pepita · 2012. Okt. 16. (K), 04.51
Elég lenne, de nem teszik.
Mert (még) nem szemantikus a web.
És ki csináltatja a honlapot? ...
Nem vetted észre, hogy itt a nyomás / kényszerítő momentum, amit fentebb hiányoltál.
Te nem, más meg igen. És aki igen, az sikeresebb (lesz).
Én úgy gondolom, hogy előbb-utóbb sikertelenebb lesz, mert be fog fuccsolni jónéhány próbálkozása. És én optimista vagyok, nem naiv.
Sajnos tudomásul kell venni, hogy a web feletti kontroll már nem a fejlesztők kezében van, ...
Hát akkor te is a "ne csináljunk semmit, minek?" tábort gyarapítod, nem akarsz, és emiatt nem is tudsz fejlődni. Ha szemantikus oldalakat kezdünk csinálni, akkor ennek előnyeit nagyon is ki fogják használni a keresők, amíg viszont mi nem lépünk, addig ők sem fognak (nagyot).
Pont ezt kérte Gábor úgy 120 körül, hogy a "minden így jó, ahogy van" jellegű neminformatív kommenteket hagyjuk el.
193

Mindegyik rendszerben van

Hidvégi Gábor · 2012. Okt. 15. (H), 12.54
Mindegyik rendszerben van lehetőség a csalásra, az offline hirdetőújságban is adhat meg hamis adatot a kereskedő, most is a weboldalán, és a szemantikus weben is, végeredményben úgyis rosszul jár, mert el fognak tőle pártolni.

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?
194

Dehát...

szaky · 2012. Okt. 15. (H), 13.15
végeredményben úgyis rosszul jár, mert el fognak tőle pártolni.

Dejszen pont ezt állítottam, hogy ez nem lesz igaz, mint ahogy most sem igaz, és a múltban sem volt az.

Pár imposztor miatt maradjunk a technológiai kőkorszakban?

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.
195

A robots.txt most is működik,

Hidvégi Gábor · 2012. Okt. 15. (H), 13.25
A robots.txt most is működik, hasonló módon lehessen a tartalomban megjelölni, hogy mit indexelhet a kereső és mit nem.
196

A probléma nyilvánvalóan nem

szaky · 2012. Okt. 15. (H), 15.50
A probléma nyilvánvalóan nem ez volt: keress rá a 'google megadóztatása' és 'Ruport Murdoch' szavakra.
197

Ezt találtam, itt is több

Hidvégi Gábor · 2012. Okt. 15. (H), 16.40
Ezt találtam, itt is több megoldást hoznak a problémára. Ráadásul ez egy speciális eset, mint írja, "az olvasók egy részének kíváncsiságát pusztán a cím és a bevezető mondatok elolvasása is kielégíti", míg egy vásárláshoz ez kevés. Mindig van, akinek az érdekeit sérti egy új irányzat, de ideje is van, hogy felkészüljön rá.
198

Ne keverd a szezont a fazonnal

Hidvégi Gábor · 2012. Okt. 15. (H), 16.53
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)
Az internetet a felhasználók éltetik, ők vásárolnak, ők keresnek tartalmat, tehát az ő kegyeikért kell elsősorban harcolni. Ha a szolgáltatók (keresők, tartalomgyárosok) nem tudják kiszolgálni őket, akkor ez van, eltűnnek a süllyesztőben. A befektetők azért tesznek pénzt ezekbe a vállalkozásokba, mert azt remélik, a felhasználók majd eleget fizetnek vissza.
200

Sajnos továbbra sem látod a fától az erdőt

szaky · 2012. Okt. 16. (K), 08.14
Az internetet a felhasználók éltetik

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.
156

ki az az elmebeteg, aki egy

Hidvégi Gábor · 2012. Okt. 11. (Cs), 11.22
ki az az elmebeteg, aki egy autós oldalon kitöltené a nyíl alak leíró információkat is
Aki számára fontos.

létrehozhatsz akármennyi objektumot, az csak egy vetülete lesz a dolgoknak. nem lesznek összefüggések, nem lesznek következtetések
Ez az első lépés, az összefüggések megadása a következő, és az nyilvánvalóan bonyolultabb. A mikroadatok, sémák mind az első lépés megtételére tett kísérletek, tehát az úton már elindultunk.

olyan ez, mintha mindenkinek ugyanazt az adatbázis struktúrát kellene használni
Még mindig jobb, mint a mostani állapot, amikor semmilyen módon nem segítjük a gépi feldolgozást.
158

akkor máshonnan közelítem

szabo.b.gabor · 2012. Okt. 11. (Cs), 12.43
akkor máshonnan közelítem meg, első lépésként tegye mindenki publikusan (olvasásra) elérhetővé az adatbázisát. mert a végeredmény valami ilyesmi volna.

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 :)
159

Akadálymentes weboldal nem

eddig bírtam szó nélkül · 2012. Okt. 11. (Cs), 13.13
Akadálymentes weboldal nem vakoknak, hanem gyengén látóknak készül! Erősen romlik a szemem, emiatt kénytelen voltam félretenni a programozgatást is (remélem, csak addig, míg eljutok az optikushoz új szemüveget készíttetni).

A fentiek szellemében a személyeskedést töröltem. – Joó Ádám
161

bocs.

szabo.b.gabor · 2012. Okt. 11. (Cs), 13.28
bocs.
162

első lépésként tegye mindenki

Hidvégi Gábor · 2012. Okt. 11. (Cs), 13.55
első lépésként tegye mindenki publikusan (olvasásra) elérhetővé az adatbázisát
Most is publikus minden, csak gépek által nem értelmezhető. Hogy miért fontos ez? Mert a világon két dolog korlátozott: a földterület és az emberi figyelem terjedelme. Ha most elkezdesz valamit keresni, kapsz egymilliom találatot, és neked kell végignyálaznod a weboldalak sorát, hogy megtaláld kívánságod tárgyát. Mivel nap mint nap tízmilliós nagyságrendben kerül fel a netre új tartalom, ebből következik, hogy relatíve egyre kevesebb mindent fogsz megtalálni, mert nincs időd mindent átnézni. Emiatt kell gépileg megtámogatni az adatok indexelését (és nem az őket tartalmazó dokumentumokét).

miért kell 2x annyi adatot letöltenie minden egyes látogatónak
Ha szétválasztjuk az adatokat és a megjelenésüket, végeredményben jóval kevesebb lesz a forgalom, mert ha legközelebb látogatsz meg egy weboldalt, csak az adatokat kell újraküldeni, a dizájnt nagy valószínűséggel nem.

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
A microdata részben erről szól.

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.
163

szerintem mindkét oldalnak

szabo.b.gabor · 2012. Okt. 11. (Cs), 14.44
szerintem mindkét oldalnak igaza van (vagy inkább ugyanannyira van igaza). nem tudom se egyik se másik oldalról azt mondani, hogy hülyeség.

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
164

Köszönöm, hogy érdemben

Hidvégi Gábor · 2012. Okt. 11. (Cs), 14.55
Köszönöm, hogy érdemben foglalkoztál a témával, és leírtad, hogy mit gondolsz, mert így másik nézőpontot is megismerhettem.
167

Középút?

Pepita · 2012. Okt. 11. (Cs), 21.17
Srácok, "arany középút" nincs ezen a téren?
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.
168

Cochran Hölgyeim és Uraim,

szabo.b.gabor · 2012. Okt. 11. (Cs), 22.16
Cochran
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
169

Szerintem semmi köze nincs

inf3rno · 2012. Okt. 12. (P), 02.03
Szerintem semmi köze nincs ahhoz a modern böngészőknek, hogy nem fejlődik sehova a web. A web igenis fejlődik, csak ezeket a fejlődéseket elfojtja a böngésző háború.

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ó...
170

A böngészők közti háború

Hidvégi Gábor · 2012. Okt. 12. (P), 08.07
A böngészők közti háború valóban sok nagyon jó fejlesztést ölt meg, de ebben a felhasználók "a (behelyettesítendő cégnév)től én nem fogadok el semmit" hozzáállása is ludas.

Az xml+xslt+xhtml azért nem rúg labdába, mert az xslt nem objektum orientált
Miért kéne objektum orientáltnak lennie? A css sem az, mégis minden feladatot el lehet vele végezni, az XSLT pedig dettó ugyanaz a technológia. Van élet az MVC, OO, SCRUM, TDD stb. buzzword-ökön túl is.

Csak annyit kéne tenni hozzá, hogy kivenni minden böngészőből a kikapcsolható javascript funkciót
Egyrészt az összes böngészőhibát scripten keresztül használják ki, másrészt a Firefox ötödik legnépszerűbb kiegészítője a NoScript. A weboldalak 99%-ánál tökéletesen fölösleges, anélküliés kéne működniük, csak a maradék 1% olyan alkalmazás, ahol meg szükséges.

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
A böngészőháború, a felhasználók fogalmatlansága és zéró lobbiereje, meg hogy a szabványírók elefántcsonttoronyban és gyakorlati tapasztalat nélkül dolgoznak vezettek ide.
173

Tehát akkor

Gixx · 2012. Okt. 12. (P), 08.29
Tehát akkor adva vannak a böngészők, amik ilyen-olyan módon támogatnák az XML+XSLT megoldást, amilyen a Starcraft2 weboldala volt anno. Erre mondhatjuk azt, hogy szemantikus, igaz? A baj vele csak annyi, hogy a keresők nem foglalkoznak vele (ha jól tudom), magyarul SEO rémálom.

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?
171

+1

szabo.b.gabor · 2012. Okt. 12. (P), 08.13
azt kell mondjam, hogy tetszik az ötleted.
174

Csere

Poetro · 2012. Okt. 12. (P), 08.49
[off]
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]
175

hohoho! átlátok ám a szitán.. :D

szabo.b.gabor · 2012. Okt. 12. (P), 10.01
Tudjuk ám, hogy nagy JS guru vagy Poetro! és tudod, hogy pont ilyen irányba mennek a dolgok. megijedtél a konkurenciától ugye? :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ű.
177

Hát js-ben is össze lehetne

inf3rno · 2012. Okt. 12. (P), 11.55
Hát js-ben is össze lehetne szórni pillanatok alatt egy oldalt a css-es workaroundok meg hasonló szépségek nélkül.

Nem hiszem, hogy a
viewPort.append(new Panel({content: "valami szöveg"}))
annyival bonyolultabb lenne, mint a
<body><div>valami szöveg</div></body>
Annyi különbség van a kettő között, hogy a fenti kicsit emberközelibb, mert pl a div-ről én 15 év html ismerettel sem mondom meg, hogy mit akar jelenteni maga a szó, a panel-ről meg minimális angol ismerettel megmondja bárki, hogy az micsoda.

szerk:
Utánaolvastam a div a "division" rövidítése.
178

[off]

T.G · 2012. Okt. 12. (P), 12.13
Hehe. Olvasom a kommentedet... tényleg, mi a franc az a div? :)
majd az updatehez érve, ohh... jobb volt, míg nem tudtam.
179

Ja, tényleg vicces. Én a

inf3rno · 2012. Okt. 12. (P), 12.18
Ja, tényleg vicces. Én a p-ről nem tudtam jó darabig, hogy paragraph. :D
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
183

offline media

Arnold Layne · 2012. Okt. 12. (P), 13.55
minek külön head meg body rész, amikor van http header

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.
176

Bár gondolom költői kérdés

inf3rno · 2012. Okt. 12. (P), 11.50
Bár gondolom költői kérdés volt, de js-hez van egy rakat VM, objektum orientált, sokkal előnyösebb, mint C, és már lassan 2 évtizedes tapasztalat van vele.

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.
180

Természetesen

Poetro · 2012. Okt. 12. (P), 13.15
Természetesen a kérdés költői volt. Mondjuk azt nem teljesen értem, miért kell OO-nak lennie a nyelvnek, valamint a C-vel több mint 4 évtizedes tapasztalat van. Ha meg olyan nyelv kell, ami VM-ben fut, akkor ott az ActionScript, Ada, Fortran, Haskell, Java, Python, Ruby stb.
181

Óvatosan!

Hidvégi Gábor · 2012. Okt. 12. (P), 13.20
Vigyázz, mert inf3rno előtt örökre elásod magad!
182

Azért kell OO-nak lennie,

inf3rno · 2012. Okt. 12. (P), 13.34
Azért kell OO-nak lennie, mert az magasabb absztrakciós szint. Értsd: közelebb áll az emberi logikához, mint a gépihez.

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.
184

Az utolsó mondatod nem tudom

Joó Ádám · 2012. Okt. 13. (Szo), 00.25
Az utolsó mondatod nem tudom hogyan kellene értelmezni.
185

Ha úgy vesszük, a

inf3rno · 2012. Okt. 13. (Szo), 08.13
Ha úgy vesszük, a böngészőkben futó javascript is egy VM-ben van. (Igazából haverom aggatta rá ezt a kifejezést, nem tudom mennyire helytálló, én csak js engine-nek szoktam nevezni, meg egy rá épülő API-nak.)
186

Bármilyen nyelvet lehet

Joó Ádám · 2012. Okt. 13. (Szo), 12.46
Bármilyen nyelvet lehet futtatni virtuális gépen, besorolni őket a jellemző implementációjuk alapján szokás. Ez utóbbit figyelembe véve a felsoroltak közül egyedül a Java és az ActionScript fut virtuális gépen, a JavaScript, a Ruby és Python interpreteres, a Fortran, a Haskell és az Ada pedig fordított.
187

LLVM

Poetro · 2012. Okt. 13. (Szo), 13.10
Azért a többinek is van több implementációja, van ami JVM alatt fut, van ami más LLVM alatt.
189

Persze, ezért beszéltem az

Joó Ádám · 2012. Okt. 13. (Szo), 21.52
Persze, ezért beszéltem az eredeti vagy a legelterjedtebb implementációról, ami alapján be szokás sorolni egy-egy nyelvet.
188

Közben utánaolvastam jobban a

inf3rno · 2012. Okt. 13. (Szo), 13.22
Közben utánaolvastam jobban a VM definíciójának, mert belezavarodtam egy kicsit. Rossz volt a szóhasználatom, nem VM-re gondoltam, az is lehet, de ugyanúgy jó egy fordított nyelv is. Ilyen téren kicsit hiányosak az ismereteim, megpróbálom leírni az én szavaimmal.

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. :-)
201

Kérhetek konkrétumokat?

T.G · 2012. Okt. 16. (K), 08.24
A kétszázadik hozzászólás után szerintem érdekes lenne látni, hogy amit szeretnétek az tényleg, hogy nézne ki a gyakorlatban. Jó lenne látni egy DTD-t, amire azt mondanátok, hogy erre van szükség a boldogabb jövő érdekében. :) Mondjuk autó kereskedés honlapját vegyük példaként. De lehet bármi más is, csak legyen konkrét példa.
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ő. :)
202

Kérhetsz

Hidvégi Gábor · 2012. Okt. 16. (K), 09.14
Természetesen van ilyen elven működő oldalam (hisz konstruktivizmus nélkül nincs értelme kritizálni semmit), de még kicsit várni kell, míg bemutatom, előtte még filozofálgatunk. Nem állítom, hogy ez a végleges megoldás, sok hasznos visszajelzés érkezett, azaz még sokat fog alakulni.
203

Nem értem

izé · 2012. Nov. 5. (H), 13.34
Végigolvastam mind a 202 hsz.-t, de még mindig nem értem, hogy miért nem jó megoldás a HTML5 microdata használata. Most komolyan, lehet, hogy én vagyok az értetlen...
204

A spagettikód is kiment már a

Hidvégi Gábor · 2012. Nov. 5. (H), 19.28
A spagettikód is kiment már a divatból.