ugrás a tartalomhoz

The ride to 5

Poetro · 2014. Okt. 29. (Sze), 14.10
A W3C ajánlottá tette a HTML5-öt több mint 6 év után
 ■
1

Késő...

Gixx · 2014. Okt. 30. (Cs), 11.31
Már a HTML8 a divat ;)
2

Visszalépés

Hidvégi Gábor · 2014. Okt. 30. (Cs), 13.01
A HTML5 jelentős visszalépés a web történetében, mert tovább konzerválja a jelenlegi állapotokat. Még mindig alapvetően statikus dokumentumokra épít, amiben keverednek az adatok a megjelenítéssel, a különböző frissítési idejű dokumentumrészek (menü, tartalom, hirdetések), azaz a szezon a fazonnal.

Érdekes elképzelés a HTML imports, de sajnos csak scripttel lehet használni, frame-szerűen összeállítani egy oldalt nem, így viszont nem vagyunk sokkal előrébb annál, mint amit eddig meg tudtunk csinálni egy akarmi.innerHTML segítségével (a különbség annyi, hogy az importált fájlban lévő scriptek lefutnak, tehát egy kicsit kényelmesebb lett a használat).

Már többször elhangzott a weblaboron is, hogy programozóként folyamatosan tanulnunk kell, viszont ezek után felteszem a kérdést, hogy mit sikerült tanulni, ha több mint húsz év alatt nem sikerült továbblépni ezen az egyszerű problémán?
3

több mint húsz év alatt nem

Poetro · 2014. Okt. 30. (Cs), 13.10
több mint húsz év alatt nem sikerült továbblépni ezen az egyszerű problémán?

Melyik is volt az az egyszerű probléma?
4

Második bekezdés, HTML

Hidvégi Gábor · 2014. Okt. 30. (Cs), 13.32
Második bekezdés, HTML imports (magyarul include).
5

Na kezdődik :).

bamegakapa · 2014. Okt. 30. (Cs), 13.53
Na kezdődik :).
6

Na, folytatódik ; )

Hidvégi Gábor · 2014. Okt. 30. (Cs), 14.13
Na, folytatódik ; )
7

jól elvagytok:)

Pepita · 2014. Okt. 31. (P), 09.40
Mintha ez lenne a legnagyobb probléma az életben.
Bocs ez off.
8

Ilyen alapon nem szabadna

bamegakapa · 2014. Okt. 31. (P), 10.25
Ilyen alapon nem szabadna semmivel foglalkozni az éhező gyerekeken, a háborúkon és a(z) {add your favorite "biggest problem in the world" here}-n kívül :).
9

A bőség zavara

Hidvégi Gábor · 2014. Okt. 31. (P), 13.11
Ahogy nő a szabvány, egyre több eszköz kerül a kezünkbe, amivel ugyanazt a feladatot lehet megoldani, jó példa erre a Poetro által írt következő mondat (kiemelés tőlem):
A document.getElementById-vel egy elemet választasz ki. Van még egy pár tucat módszer elemek kiválasztására: element.getElementsByTagName, element.querySelector, element.querySelectorAll, element.getElementsByClassName stb.

Ezeket az eszközöket a böngészők különbözően valósítják meg, amire jó példa Honda új reklámja. Egy nagyjából másfél éves böngészőben, az Opera 12-ben például használhatatlanok a videó gombjai, valamint nem jelenik meg az üzenet, amelyik arról tájékoztat, hogy az R gomb lenyomásával lehet váltani nézetet. Ezeket a funkciókat (onclick, onmouseover kezelése, div megjelenítése időzítve) már egy tizenöt éves böngésző is ismeri, a Google vagy a Honda fejlesztőinek mégsem sikerült megoldaniuk.

Egy gyakorlott webfejlesztőnek ez nem okoz gondot, mert folyamatosan képben van a változásokkal, de egy kezdőt megszédíthet a bőség zavara. Egy profi számára könnyű a választás, de ez nem jelenti azt, hogy egyszerű a helyzet. Ha tovább folytatódik az eszköztár növelése, várhatóan még rosszabb lesz a későbbiekben, és még több használhatatlan weboldallal és alkalmazással fogunk találkozni a jövőben.

Ebből következik, hogy a következő ésszerű lépés a redundancia csökkentése kell legyen, ha nem akarjuk, hogy ránk omoljon a kártyavár. Például ki lehetne dobni a fölösleges elemeket: abbr, address, article, aside, b, bdi, bdo, blockquote, center, cite, code, datalist, del, details, dfn, dialog, dd, dl, dt, em, figcaption, figure, footer, header, i, ins, kbd, keygen, main, mark, menuitem, meter, nav, ol, output, pre, progress, q, s, samp, section, small, strong, sub, summary, time, u, var. Ezek mind helyettesíthetőek különböző attribútumokkal (class, title, role stb.), és másra nem jók, csak a káoszt növelik a fejekben, mert vég nélküli vitákat lehet folytatni, hogy melyiket hol használjuk.

Ugyanígy a Poetro által felsorolt metódusokat is le lehet redukálni egyre, a document.evaluate nem csak azt tudja, amit a fentiek, hanem jóval többet.
10

Szemantikus web?

Endyl · 2014. Okt. 31. (P), 13.27
És akkor hogyan válik valóra az általad elképzelt megvalósítású szemantikus web, ha már ez a viszonylag kis számú, általános/struktúrális szemantikát leíró bőség megszédíti a kezdőket? Mi lenne velük, ha minden tartalmukat be kéne sorolni a milliófajta jelölő közé (mert ugye nem csak 1-2 fajta dolog létezik a világon), hogy pontosan lehessen rájuk keresni (nem csak szövegalapon, amit annyira haszontalannak tartasz)?
11

Más

Hidvégi Gábor · 2014. Okt. 31. (P), 13.45
Nem kéne keverni a kettőt. A HTML egy felületleíró nyelv, annak semmi közének nem kéne lennie (vagy a lehető legkevesebbnek) az adatokhoz.

Miért szükségszerű, hogy az adatokat is a sitebuildernek kell előállítania? Nem elég, ha a HTML-lel, a CSS-sel és a JS-sel foglalkozik? Ha bizonyos esetekben HTML segítségével jelenítjük meg az adatokat, akkor szerinted melyik a hatékonyabb, ha kis, vagy ha pedig nagy elemszámú leírónyelvet használunk?
12

Ezt pontosítanád?

T.G · 2014. Okt. 31. (P), 14.09
Mintha a modern böngészőket ekéző blogbejegyzésben nem pont ilyeneket írtál volna, ott az egyik hozzászólásodban még <ingatlan> tag is megjelent.

Akkor ígértél konkrét megvalósítást, amivel talán megérthetnénk, hogy miért írsz erről ennyit, de sajnos az is elmaradt: http://weblabor.hu/blog/20120926/modern-bongeszok#comment-92741
Ahogy alig egy hónapja más témában is kértem volna pozitív példákat, de azok is elmaradtak.
13

Szívesen

Hidvégi Gábor · 2014. Okt. 31. (P), 14.22
Az <ingatlan> egy adat, amit a kliensnek nyers formában kiküldhetünk XML-ben vagy akár JSON-ban is. Ettől pedig teljesen független, miképp jelenítjük meg, például böngészőben egy <div>-ben, mobiltelefonon egy alkalmazásban grafikonként, vagy a hűtőm érintőképernyőjén.
16

Tehát pont fordítva?

T.G · 2014. Okt. 31. (P), 14.59
Ezt most nem pontosan értem, tehát nemhogy ingatlan tag-et nem szeretnél, de (kis túlzással) a div-en kívül semmi mást sem? Szerintem mindenre használhatsz div-et, nincs előírva az, hogy a div-en kívül mást kellene használnod. Vagy most az zavar, hogy vannak az ajánlásban más tag-ek is, amiket fölöslegesnek tartasz?

Számomra a megközelítés az, hogy mi weboldalakat állítunk elő, van navigáció, van fejléc, van tartalom, vannak bekezdések és címek és felsorolások, vannak táblázatok, van lábléc, a láblécben feltüntethetünk elérhetőséget stb. Ezeket meg jelöljük, de ebből egyiket sem kötelező jelölni. Én role-t sosem használok, mert amit a tag-ek nem tudnak megmagyarázni, azokat nem magyarázom meg, és ennyi.

Ez kicsit Don Quijote szerű nekem, látom, hogy harcolsz a szélmalommal, de miért is?
18

Sosem írtam, hogy az

Hidvégi Gábor · 2014. Okt. 31. (P), 15.08
Sosem írtam, hogy az <ingatlan> tag-nek a HTML-ben lenne a helye.

Számomra a megközelítés az, hogy mi weboldalakat állítunk elő
Ez teljesen nyilvánvaló, és nem vagy egyedül, a többi pármillió sitebuilder is így gondolkodik. De ez nem feltétlenül jelenti azt, hogy ez az egyetlen és legjobb út. Ha viszont átgondolod, hogy milyen technológiai (hardverre célzok) fejlesztések voltak a közelmúltban (mobil eszközök), és mi várható (IoT), a HTML alapú web számomra idejétmúltnak tűnik (arról nem beszélve, hogy már a megalkotásakor elavult volt a statikus dokumentum elképzelés).
19

Mi az alternatíva?

T.G · 2014. Okt. 31. (P), 15.28
Nem látom, hogy miért gond, illetve miért elavult dolog, hogy a hűtőszekrény kijelzője is HTML oldalt jelenít meg. Igen, itt a fejléc és a lábléc teljesen más szerepet kap, de ez mit igazol? Természetesen sosem fogjuk ugyanazt a tartalmat küldeni egy publikus reklám weboldalra, mint egy hűtőszekrény kijelzőjére. Annyira azért nem gondoltam bele, de nem lepne meg, ha a HTML15-ban lenne majd pontos idő tag, mert ezt mind a hűtő, mind a mikró, meg más eszköz is használna, így miért ne legyen megjelölve. De szerinted ez probléma lenne?

Miért gondolunk a HTML-re, mint egy statikus dologra? Vagy most arra az esetre gondolunk, ha a vasaló kijelzőjébe esetleg olyan böngészőt tesznek, amely a HTML-t megjeleníti és a JavaScript-et nem futatja, akkor tényleg csak statikus tartalmat kapunk. Amikor DHTML-ről beszéltünk, akkor is úgy gondoltuk, hogy JavaScript-tel együtt értendő a dinamizmus.

Ha kidobjuk a HTML-t, akkor mit használunk majd helyette?
21

Nem látom, hogy miért gond,

Hidvégi Gábor · 2014. Okt. 31. (P), 15.39
Nem látom, hogy miért gond, illetve miért elavult dolog, hogy a hűtőszekrény kijelzője is HTML oldalt jelenít meg.
Pontosan azért, amiért virágzik az iOS és Android "app"-ok piaca, és nem HTML-ben készítik el ezeket a többgigahertzes és többmagos hardvereken.
22

Tehát?

T.G · 2014. Okt. 31. (P), 16.06
Melyiken nincsen WebView komponens?
Illetve mi az a közös megjelenítő, amely minden mobil platformon egységesen használható, ha nem a HTML?
14

Más?

Endyl · 2014. Okt. 31. (P), 14.30
Felőlem állíthatja elő más is az adatokat, de ő is ugyanúgy kezdő lesz, és neki is ugyanabból a millió fajta jelölőből kell majd felépítenie az adat struktúráját. A kérdés továbbra is áll, hogy ha egy minimális általános szemantikát nem tudnak az emberek megtanulni, egy sokkal szerteágazóbbat hogyan fognak?

Továbbá, ezután ezt a (millió lehetséges jelölőből álló) struktúrát ugyanúgy le kell képezni html-re (vagy egyéb prezentálható formára) a megjelenítéshez (lehetőleg legalább struktúrális szemantikát tartalmazva, hogy a kisegítő technológiákkal is lehessen navigálni - amit továbbra is jelölni kell; mindegy, hogy taggel vagy attribútummal, bár ha minden attribútum lenne, az közelebb lenne a spagettihez). Tehát a GUI építőnek továbbra is ismernie kell a millió jelölőt ahhoz, hogy le tudja képezni html-re vagy egyéb leírónyelvre. Mit is nyertünk ezzel?
15

Nem értem, miért kevered ezt

Hidvégi Gábor · 2014. Okt. 31. (P), 14.41
Nem értem, miért kevered ezt ide; ismétlem, az adatoknak semmi közük ahhoz, hogyan fognak megjelenni.
A kérdés továbbra is áll, hogy ha egy minimális általános szemantikát nem tudnak az emberek megtanulni, egy sokkal szerteágazóbbat hogyan fognak?
Ha az embereknek nem megy, majd megcsinálják a gépek.

Tehát a GUI építőnek továbbra is ismernie kell a millió jelölőt ahhoz, hogy le tudja képezni html-re vagy egyéb leírónyelvre.
Nem kell ismernie. Vegyünk egy általános sablonnyelvet, ami bemenetként például egy php tömböt kezel; a kimenet írásakor téged nem érdekel, hogy mi van a tömbben, csak annyi a lényeges számodra, hogy ha mondjuk a $tömb['kulcs'] értéke ez és ez, akkor ezt és ezt a HTML kódot kell kinyomtatni.
17

Ha az embereknek nem megy,

Endyl · 2014. Okt. 31. (P), 15.00
Ha az embereknek nem megy, majd megcsinálják a gépek.

Mintha ezt csinálnák napjaink keresői, de ennek a hatékonyságával nem vagy megelégedve. Mire emberi módon fel tudnak címkézni tetszőleges tartalmat gépek, addigra a szövegalapú keresés is ugyanolyan hatékony lesz, hiszen ugyanúgy szöveget kell értelmezni.

Plusz, ha a sitebuilderek nem tudják megjegyezni a tagek neveit, akkor lehet, hogy ott sem a tagek eltörlése, attribútummá alakítása a megoldás, hanem hogy gépek csinálják meg helyettük :)

ha mondjuk a $tömb['kulcs'] értéke ez és ez, akkor ezt és ezt a HTML kódot kell kinyomtatni.

Tehát akkor mégiscsak ismerni kell a kulcsot és az értékét értelmezni?
20

Szerveroldalon most is kell

Hidvégi Gábor · 2014. Okt. 31. (P), 15.33
Szerveroldalon most is kell valaki, aki a megfelelő adatstruktúrát előállítja, ő a backendes kollega. Az már részletkérdés, hogy jelen pillanatban (továbbra is PHP-ból kiindulva) egy PHP tömböt ad át neked, sitebuildernek, vagy pedig egy XML-t (vagy JSON-t). Jelenleg ennek az adatstruktúrának a felépítése ad-hoc, jellemzően az általatok tárolt belső adatbázist reprezentálja valamilyen szinten. A szemantikus web esetében ennek a kimenő adatstruktúrának van egy formátuma, ezt a backend programozó fogja lekezelni. Mivel ezt a problémát eddig is megoldották valahogy (mert hát, ugye az adatokat eddig is tárolni kellett, és át is kellett adni a frontendnek), ezután sem fong szerintem gondot okozni.

Tehát akkor mégiscsak ismerni kell a kulcsot és az értékét értelmezni?
Frontendesként most sem kell tudnod pontosan, hogy mi mit jelent. Most is van adatforrás, a szemantikus web esetében is van egy, ami hasonló a mostanihoz, tehát a munkád nem változik.
23

Azt kell, hogy mondjam jó

szabo.b.gabor · 2014. Nov. 2. (V), 16.58
Azt kell, hogy mondjam jó ötletnek tartom amit írsz. Nagyban megsegítené a b2b alkalmazások írását, ha volna egy egységes struktúra, amiben tárolandók az adatok.

Szerintem az okozza a legnagyobb zavart itt a weblaboron, hogy te a szemantikus mellé odaírod, hogy web. Igazából ez a történet nem a webről szól.

Ettől függetlenül szerintem nem biztos, hogy kivitelezhető a használt adatstruktúrák egységes, mindenkit kielégítő leírása, bővítése, és ennek használata. Persze meg kell próbálni.
24

Igen, én is gondolkodtam

Hidvégi Gábor · 2014. Nov. 3. (H), 10.01
Igen, én is gondolkodtam korábban arról, amit itt írsz, a web, a http az alapja, de nem (feltétlenül) HTML dokumentumokat küldözgetünk.

És az is igaz, hogy lehetetlen mindenkit kielégítő adatstruktúrákat létrehozni.
25

Mondjuk annyi kellene, hogy

szabo.b.gabor · 2014. Nov. 3. (H), 11.30
Mondjuk annyi kellene, hogy az azonos érdekkörbe tartozó gazdasági szereplők kidolgozzák a felhasznált adatok struktúráját, és kitalálni, hogy ez fenntartható legyen.
26

Ez is felmerült bennem, csak

Hidvégi Gábor · 2014. Nov. 3. (H), 12.18
Ez is felmerült bennem, csak attól félek, nem lenne belőle semmi, mert mindenki itt is a maga érdekeit nézné, és lassan születne meg minden döntés. Persze ez is egy út, de lehet, hogy egy központi "márpedig így lesz" módszer is működhet, mindkettő mellett vannak pro és kontra érvek.