Miért tartom károsnak a HTML5-öt és, hogy a böngészők elfogadnak érvénytelen HTML kódot is...

Tegnap esti task: adott egy özönvíz előtt készült oldal, még HTML4-es időkből, tablefull design, CSS mutatóban, ahogy kell. Miután API az nincs (ill. van, csak nem arra, amire nekem kellene), így maradt az, hogy parseolom az adatokat valahogy.

Na de a valahogy része már nem olyan egyszerű. XML és (nem retardáltak által írt) XHTML esetén ezzel nem lenne gond, megnyitom a kedvenc és/vagy feladatnak megfelelő XML olvasóval s TADA.WAV.

Miután nem igazán van a .NET-ben alapból se HTML se SGML parser mindenképp gányolás lett a vége, ami jelen esetben a System.Windows.Forms.WebBrowser használata. (Természetesen csak gányolással működik egyszerűen). Segítek: leánykori neve Internet Explorer, legalábbis abból a megjelenítésért felelős komponens. Miért nem kerestem rá SGML parsert? Mert messziről látszott, hogy az oldal semmiféle validátoron nem menne át, ellenben a böngészők megeszik

Mennyivel egyszerűbb lenne az élet, ha nem kezdene el mindenki pluszba XML szerű nyelveket készíteni (aki lemaradt volna: HTML5 töri az SGML kompatibilitást, mostantól saját parser kell neki) _ÉS_ hogy nem a böngészőmotorokat igazították volna a lustákhoz és/vagy retardáltakhoz, (akik képtelenek szabványos dokumentumokat kiadni a kezük közül) ahelyett, hogy szimplán dobtak volna egy parse errort.

Mindenkinek egyszerűbb lenne most az élet. Kivéve a nyomorékoknak, akiknek nehéz pár alapvető szabályt betartani. De őket nem tudom sajnálni.

( uid_4263 v | 2015. 04. 30., cs – 14:23 )

Miért parseolsz adatokat egy html weboldalból?

--
arch,debian,openelec,android

Pont az a baj hogy egy alapvetően prezentációra szánt dokumentumból próbálsz adatot kinyerni valamilyen arra szánt forrás helyett, amit megbízhatóan lehetne parse-olni. Bár az általad leírt dolgok is sokat rontanak rajta (értsd ha szabványos xhtml lenne, könnyebb dolgod lenne).

--
arch,debian,openelec,android

Jó, ez van, a problémát meg szeretném megoldani.

Én is jobban örülnék, ha a weben a megjelenítés és az adatok szét lennének választva (innen indult a szemantikus web is), más kérdés, hogy erre a CSS önmagában kevés. És igen, egyszerűbb lenne, ha szabványos XHTML lenne, de nem az, ez egy kb. 10 évvel ezelőtt összetákolt weboldal.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( uid_17720 | 2015. 04. 30., cs – 15:19 )

Találtál egy szar HTML4-es doksit, amit nem tudsz parse-olni. Eddig világos. De hogy jön ide a HTML5 és hogy ahhoz nincs parser? Most az segített volna? Ha X nyelvhez/frameworkhöz nincs Y-hoz parser, akkor Y dögöljön meg?

Szerintem úgy hogy bár lehetőség lett volna kijavítani egy régi tévedést és áttérni XML alapra, de specifikáció rendkívül okos megalkotói ehelyett inkább rontottak a helyzeten. És ez a mentalitás sok helyen visszaköszön a web történetében, emiatt nagy kalap trágya a webfejlesztés.

Én pedig az XHTML-t érzem tévútnak, meg az XML alapot. A HTML egyszerűen nem arra lett kitalálva, hogy parsoljuk. Nem adattároló formátum, hanem dokumentum-leíró nyelv.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

A HTML egyszerűen nem arra lett kitalálva, hogy parsoljuk.

Mondjuk akarok egy programot írni ami felhasználó által szolgáltatott HTML sablonok és adatforrás alapján generál reportokat. Szerinted ez nem egy teljesen valid business case?

Az XHTML ugyan miért lenne tévút?

A problémádra a template rendszerek jelenthetnek megoldást. Ez olyasmi dolog, hogy lehet parsolni HTML-t regexp-pel és az esetek egy részében eredményes is lesz, de nem arra való.

A web pedig nem a mérnököké, kutatóké és tudományos szakembereké. Tudom, hogy nehéz elfogadni, de a weben pontosan annyira helye van a a W3C valid plecsnis honlapoknak, mint Mancika kézzel, esetleg Wordben írt bemutatkozásának. Erre pedig az XHTML nem alkalmas, mivel túl szigorú, nem hibatűrő.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Láttam a mondat második felét is, csak a zinternet veszélyes hely, nem felejt, és rövid úton hivatkozási alap lesz a hozzászólásod, hogy márpedig lehet, csak nem érdemes :)

Szerk.: lásd még, kismillió beszélgetés erről különböző fórumokon, ahol egy-egy ilyen után mindenki kötelességének érzi, hogy hozzászóljon, hogy melyik A regexp, amivel mégis lehet. E-mail cím kb. ugyanez [bár azt még lehet is], ahelyett, hogy a platform beépített validátorát, vagy valami kész lib-et használnának, mindenki meg akarja írni a saját e-mail regexpét, ami csak egy-két edge case-re nem működik...

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

A problémádra a template rendszerek jelenthetnek megoldást. Ez olyasmi dolog, hogy lehet parsolni HTML-t regexp-pel és az esetek egy részében eredményes is lesz, de nem arra való.

Mi az hogy nem arra való? Te magad írtad korábban: „Nem adattároló formátum, hanem dokumentum-leíró nyelv.” Tehát a HTML egy dokumentum-leíró nyelv, amely NEM alkalmas dokumentumok leírására. Szuper.

Rosszul kötötted össze a gondolati elemeket. A mondat ennyi volt, mintegy példaként:

„Ez olyasmi dolog, hogy lehet parsolni HTML-t regexp-pel és az esetek egy részében eredményes is lesz, de nem arra való.”

Szóval a regexp nem való HTML parsolására, még ha bizonyos esetekben helyes eredményt is ad.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

"A web pedig nem a mérnököké, kutatóké és tudományos szakembereké."

A mondatod ugy lenne helyes, hogy nem kizarolag az ovek. Vagy akkor most minden mernok, kutato es tudomanyos szakember kottesse ki otthonrol az internetet?

Egyebkent pedig nincs igazad. Ha a Mancika-felek tudasahoz szabnak a webes szabvanyokat, akkor meg mindig a binary-only MS Word Document formatum lenne az elfogadott es a CSS helyett valami LOGO-szeru kotetlen szintaxisu nyelv felelne a dokumentumok kinezetenek leirasaert. A dokumentumok ugyanugy strukturalt szovegek, mint egy nyuves XML, csak a strukturalas maskeppen nez ki benne. A szabvanyok feladata elsosorban az lenne, hogy valamilyen szinten atjarhatosagot biztositsanak a tobbfele strukturalasi rendszer kozott, ebbe pedig boven belefer egy XHTML szintu szabvany, ugyanis Mancika sosem fog akarni HTML forraskodot szerkeszteni semmilyen szabvany szerint, aki meg az ilyen jellegu dokumentumok forrasszintu eloallitasaval foglalkozik, az meg ra lenne szoritva, hogy megfeleljen bizonyos szeles korben elfogadott kozossegi szabalyoknak, melyek gyujtemenyet egyuttesen szabvanynak hivjak.

A Mancika altal hasznalt eszkozoknek pedig kutya kotelessege lenne a szabvanyoknak megfelelo kimenetet eloallitani, ha ezt megsem teszik, az nem Mancika, hanem a gyarto felelossege es szegyene.

--
Blog | @hron84
Üzemeltető macik

"Nem adattároló formátum, hanem dokumentum-leíró nyelv."

Dokumentumot is ugyanúgy parseolnia kell valaminek. Aztán meg a gyakorlat bebizonyította, hogy az, hogy mit mire szántak és miből kell adatot kibányászni az két külön dolog. (Kaptunk már munkahelyen árlistát PDF-ben, amit meg kellett volna etetni az ERP-nkkel...)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"A HTML egyszerűen nem arra lett kitalálva, hogy parsoljuk"
A böngésző mit csinál?

"Én pedig az XHTML-t érzem tévútnak, meg az XML alapot. [...] Nem adattároló formátum"
De, pontosabban nem adat tárolásra, hanem korlátozott mennyiségű adat _továbbítására_ lett kitalálva, és pont ez történik.

--
arch,debian,openelec,android

( Elbandi v | 2015. 04. 30., cs – 16:26 )

huh, html parse-val nekem is megnyult a bajom :(

amugy ez sem eszi meg?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( SzBlackY | 2015. 04. 30., cs – 17:48 )

Egy url-t vagy példakódot tudsz írni? A libxml (-< PHP DOM extension) ugyan még HTML módban is okádja a warningokat egy-egy rosszul kódolt fájlra, de egészen használható DOM-okat tud csinálni - és van hozzá C# bind.

Időnként állami oldalak Ajax-os szemeteit szoktam vele PHP scriptekből behúzni [véletlenül sem well-formed HTML darabokat (semmi doctype, head/body, csak egymás mögé hányva néhány script tag meg táblázat)], warningolni warningol, de utána van egy használható DOM fa.

----
btw: pont ma futottam bele egy másik rendszerbe, ami szépen XML-t ad ki, ott viszont pont a ló túloldala, feleslegesen túlstrukturált, tele olyan adattal, ami a HTML kimenetben nem jelenik meg, mert nincs értelme [továbbmegyek: akár jogszabályt is sérthet a megjelenése...]. Szóval soha nem az eszközt hibáztasd, hanem a használóját.

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

Az oldal itt most lényegtelen és a parser lib is (mert végső soron sikerült beparseolni). Meg igazából az oldalt abból a szempontból nem szidom, hogy miért nem egy REST API-t ad (egyébként van, de sajnos csak az eladói funkciókra, ami nekem nem jó), mert tényleg a kőkorszakban készült, azóta sokat változott a web. (Még sima ASP, center, div egy szál se, helyette van egy halom table meg spacer.gif. Mond valakinek valamit? :) Sőt, persze, még az én anyámat, merthogy nem elég nekem az, amit az oldal nyújt. Csupán ennek kapcsán jutottak eszembe a dolgok.

Ami a lényeg, az a hozzáállás: anno a böngészőgyártók azt mondták, hogy persze, írjad, ahogy akarod, majd mi megjelenítjük valahogy. Természetesen úgy is írták sokan az oldalakat, ahogy. A böngészőgyártók meg tolták bele a böngészőkbe a hackek tömkelegét, hogy azok az oldalak megjelenjenek. (Kíváncsi lennék, hogy mekkora rémálom lehet ezeket a hackeket karban tartani.) Emiatt gyakorlatilag kétféle parser létezett: egy szabvány szerinti és egy a "való életbeli HTML"-re.

XHTML-el végre elindult valami, hogy egy szabvány alá tereljék a webet. Sajnos a böngészőgyártók ott sem az egyszerű utat választották (fogják a randomxml libet és onnantól az van és kész), hanem a meglévő HTML parserüket kezdték el toldozni-foltozni és pofozni, hogy úgy-ahogy megegye az XHTML-t is. Ennek következménye volt az pl. hogy ha egy XHMTL-es fájlban egy DTD-t behúzunk pluszba, akkor a Firefox azt kihányja az oldal tetejére. (Nem tudom, hogy ez most is fennáll-e még). De hozhatnám példának a Facebook RSS-ét, ami simán tartalmazott escapeletlen dolgokat.

HTML5-tel az a bajom, hogy ahelyett, hogy ezt a folyamatot egyszerűsítené, még rátesz azzal egy lapáttal, hogy törte az SGML kompatibilitást is. XML-ként meg sosem lehetett feldolgozni, mert a HTML 4 folyatása. És nem azzal van a baj, hogy egy új formátumot vezet be, hanem azzal, hogy mindezt teszi úgy, hogy az új formátum igazából nem hoz előnyöket sem az SGML/HTML4-hez sem az XML-hez képest. (Jó, icipicit kevesebb karakter, de ez mit számít, mikor a HTML kód jelentős része generált vagy valami WYSIWYG szerkesztőben készül (pl. webes CMS szerkesztője)).

Mindegy. Magam részéről úgy vélem, hogy azért vannak a szabványok, hogy megkönnyítsék az ember munkáját. Ha valaki nem tartja be a szabványokat vagy egy új értelmetlen szabványt vezet be és miatta kivételt kell tenni, akkor az hátráltat. Ugyanaz, mint a textfile/binary file: teljesen mindegy, egyik sem kevésbé hordozható mint a másik (ugye ez szokott lenni az egyik bullshit érv a textfile mellett). Valójában egy formátum attól lesz hordozható, hogy annak struktúrája jól definiált és mindenki ugyanúgy értelmezi. Na, most a weben ennek ellenkezője történik.

És, hogy miért akarok feldolgozni egy HTML-es oldalt, API nélkül? Mert csak. Mert megtehetem. És mert arra van a számítógép, hogy dolgozzon helyettem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Lehet, hogy félreértettél, tisztában vagyok azzal, hogy mekkora takony a HTML, verziótól függetlenül :) És én is ismerem a kényszert, hogy API nélkül használjunk HTML oldalt.

Az okaival (és abban hogy végső soron ez kinek a felelőssége) nem értünk egyet:
1) én elsősorban pont a WYSIWYG szemeteket okolom. Jön a paraszt, kopipásztázza a szemetét a wordból (mert egy dőlttel szedés csak abban oldható meg, ugyebár), és a remek WYSIWYG szerkesztő okádja az MS markupot. Ami nem kevés zaj. A legegyszerűbb példa: egy teljesen új doksiba írd be, hogy Hello World, és bármi formázás nélkül mentsd el HTML-be - több kiló markup-ot és stíluslapot fogsz kapni.
2) a következő lépés innen, hogy valaki előokádta a trágya markup-ot az, hogy azt meg kell jeleníteni. A böngészők itt tényleg mondhatnák, hogy "na ezt nem", csak azzal a net nagyon nagy részét elvágná (lásd a Facebook RSS-t... azért ha valakinek, nekik már illene erre is figyelniük). Ha ezt egyedül bármelyik böngésző meglépné, annyit érne el, hogy azonnal elvesztené az összes felhasználóját. És ezzel a kör bezárult, addig nincs szabvány-követés, amíg nincs szabványkövetés.

[mielőtt megint MS-ellenes linux-bérenc troll lennék: azért emeltem ki a Word-öt, mert annak van akkora piaci részesedése, hogy időnként sajnos találkozom az abból generált HTML-el. Biztos van még sok más, hasonlóan rossz HTML kimenetet előállító alkalmazás is természetesen]

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

"egy teljesen új doksiba írd be, hogy Hello World, és bármi formázás nélkül mentsd el HTML-be - több kiló markup-ot és stíluslapot fogsz kapni."

Javascriptes WYSIWYG szerkesztőkre gondoltam, nem a Wordre és hasonlókra. Egyébként ilyen szempontból lényegtelen, ameddig ezt szabványosan teszi.

"Ha ezt egyedül bármelyik böngésző meglépné, annyit érne el, hogy azonnal elvesztené az összes "

Igen, ezért mondom, hogy ez egy alapvetően elbaszott döntés volt már a legelején. Csak az a gond, hogy nem úgy látszik, mintha legalább megpróbálnák javítani.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az a kisebbik gond, hogy mentéskor ilyen trágya kódot ad ki magából a word, a nagyobbik, hogy sima copy-pastnél is. Azt pedig használják a userek.

A legelején nem nagyon voltak szabványok, amiket követni lehetett volna, plusz ugye maga a browser war hozott be egy csomó nem szabványos dolgot (régi szép idők, amikor két internet volt, a netscape-net és az explorer-net, és a két tábor utálta egymást :) ) Most meg már nem tudnák megoldani, a fentiek miatt (aki elsőként lép, az elveszti a piacát)

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

( kmARC v | 2015. 04. 30., cs – 18:43 )

jquery nem játszik? Mármint ha jól értem egyszer kell ezt a konverziót megcsinálni. Én valószínűleg bngésző konzolában írnám a jquery hányást egy adott oldalra, ha működik, akkor meg nodejs-ben az összes html-re mehet a szkript. Már csináltam ilyen, pár óra alatt megvolt a teljes cucc.

Mindez persze csak akkor, ha egyszeri konverzió, és persze értesz a jqueryhez. (Sokat tud segíteni egy subselector és $.text() )

Teljesen mindegy, hogy JQuery vagy sima DOM fa operáció, lényeg az, hogy kell egy DOM fa, amiből ki lehet nyerni az adatokat. És nem csak egyszer kell, sőt, gyakorlatilag az oldalt, mint egy API használom. Ahhoz, hogy használni tudjam, ahhoz ráadásul további lépések is kellenek (pl. be kell jelentkezni).

Cikkekre keresek rá, hogy azok hol mennyiért, milyen mennyiségben elérhetőek (ez lehet 100-as mennyiségben is), hogy milyen cikkek kellenek, adatbázisból jön és a listát is egy adatbázisba akarom aggregálni, majd ott kezelni.

De mondom, nem az a gond, hogy megoldhatatlan (mert megoldottam), hanem az, hogy felesleges (és gány) köröket kell tenni olyan dolgok miatt, amivel sosem lett volna probléma, ha a böngészőgyártók nem engedik meg a trehányságot.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem mindegy. A leírtak lapján neked a rendered oldalból könnyebb lenne értelmezni az adatot, mint DOM turkálással.

Amit én ajánlok, hogy épp ezért, ne a DOM-ot turkáld, hanem szűkíts (pl. táblázat egy sorára subquery), aztán .text(), aztán mondjuk regexp.

Tehát még egyszer, értem mi akülönbség, és NEM egyszerű DOM manipulációról van szó.

Szerkezet az meglehetősen fix, a tr.InnerText kevésbé, a regexppel meg úgy vagyok, hogy ha nem muszáj/nincs jobb, akkor inkább ne. Egyébként egy kissé egyszerűbb helyzet lenne, ha modernebb oldal lenne, mert ott azért általában legalább classnevek alapján lehetne egyszerűen szűrni.

Plusz, ez így össze van integrálva szépen a meglévő programmal.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A System.Windows.Forms.WebBrowser is "headless" ebben a formában, ahogy használom, hiszen sehova nincs kirakva. (Meg egyébként is, maga a program WPF, nem WinForms, tehát legfeljebb egy ElementHost-ba tudnám rakni.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mondjuk egy issue van vele, STAThread kell neki, lévén, hogy COM ojjekt, de egyelőre ez legyen a legnagyobb gond.

Ha nagyon útban lesz (és/vagy rengeteg időm lesz), majd megnézem ezt: https://www.nuget.org/packages/HtmlAgilityPack. Egyelőre marad a workaround.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( carlcolt | 2015. 05. 01., p – 12:51 )

Kb pont az esetek feleben ertek veled egyet Saxus.

Es ez most pont az amikor igen.

Hatalmas +1

( NevemTeve | 2015. 05. 02., szo – 07:49 )

(off: nem is merem megkérdezni, hogy a kérdéses website-ok gazdái tudnak-e erről a nemes adatletöltő tevékenységedről.)

Miutan az oldal gazdáinak a celja az, hogy minel tobbet vasaroljak azokon a boltokon, amelyeknek platformot biztosítanak, szerintem who cares.

Ugyanezeket az oldallekereseket egyebkent is megcsinalnam egyesével kézzel, most arrol van azo, hogy a sajat munkám automatizalom.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szerintem a kérdés nem helyénvaló. Aki a publikus internetre tartalmat tesz fel, az számoljon mindenfajta forgalomra, beleértve a humán kattogtatástól egészen a programozott, automatizált adatletöltésig. Amíg egy single hostról és nem 150-ről szívjuk le, szerintem nem vitatható.

--
arch,debian,openelec,android

Na, megneztem a TOS-t, egyetlen kapcsolodonak tűnő resz az ez:

"You acknowledge and agree not to distribute, disclose, upload, or transfer to any third party any content or data you receive from or which is displayed on the Site, which includes but is not limited to the inventory data files in the form of XML, CVS, or Tab-Delimited format, except when this is required for the operation of your store."

Szóval csak annyi, hogy nem adhatom at az adatokat masnak.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™"