(In)kompatibilitási rémálommá válhat a HTML5 is

(In)kompatibilitási rémálommá válhat a HTML5 is
2012-07-23T08:44:11+02:00
2012-07-28T17:40:07+02:00
2022-10-24T21:50:32+02:00
  • Nem vállalatirányítási rendszert, de a C64 basic V2-höz képest elég összetett ügyviteli progit. Amúgy működött, de nem volt szépségdíjas a kód.

    Igen, egyébként lehet OOP-ben is jó nagy nyulat fogni ha nem ért hozzá az ember. De ez olyasmi, hogy kétkerekű biciklivel is el lehet esni. De egykerekűvel azért könnyebben.
    Mutasd a teljes hozzászólást!
  • Jó, csak azt ne mondd, hogy vállalat irányítási rendszert írtál commodore 64-re. Nyilván a megfelelő eszközre az adott nyelv tökéletesen megfelelt ahhoz a szinthez, amit képviselt. Egy Quake 1 szintű programhoz teljesen elég volt a C is, OOP már a nagyobb rendszerekhez viszont szükségessé válhat. Egyébként az olyan OOP elgondolások, mint a DI és egyebek épphogy el is bonyolíthatják a rendszert fölöslegesen a kelleténél jobban.
    Mutasd a teljes hozzászólást!
  • Az X programnyelvről Y programnyelvre fordított kódok ritkán szépségdíjasok. De ez nem attól van, mert Y annyira jó.

    Hidd el, az oop nem véletlenül folyik a csapból is - én anno még oop nélküli nyelveken kezdtem fejleszteni (8 bites gépek basicjei, Z80 assembly, Clipper87, Turbo Pascal és Turbo C, Cobol). Kb. akkora lépésváltás volt mint picit régebben, amikor bevezették a strukturált programozást.

    A típus nélküliség pedig akkor jó, ha az egész kódot 100%-ban le tudod fedni unit tesztekkel. Biztosan van olyan projekt ahol erre van keret (határidő, pénz) - én sajnos eddig még nem találkoztam ilyennel. Pedig nem ma kezdtem.
    Mutasd a teljes hozzászólást!
  • Más kódjaiba belepiszkálni típuskezeléssel együtt se szeretek, bár időről időre kénytelen vagyok. Láttam már Haxe-el készített JS-t. Nem sok mindent csinált a program de azt terjengősen és OOP módon. Persze nem vitatom, hogy hasznos dolog az OOP, de gyakran jól elvagyok nélküle is, de ha szükségét érzem, akkor használom. Mondjuk érdemes belenézni a Three.js kódjába, az például OOP-s js és elég szépen van megoldva, csak, hogy pozitív OOP példát is említsek.

    Amúgy meg sajnálom, hogy az egyszerű módszereket nem minden böngésző veszi át, illetve nem egyformán, lehet, akkor túl könnyű lenne az élet.
    Mutasd a teljes hozzászólást!
  • Ez addig lesz így, amíg nem kell mások által nem túl jól megírt kódba belepiszkálnod. Vagy a sajátodba mondjuk 5 év múlva .

    Hidd el, nem véletlenül akarja a gugli is lecserélni. Nagyon kellene normális OOP, a statikus típuskezelés sem ártana ha legalább alternatívaként létezne. Pár dolog egyébként tényleg jó benne, de vannak hátborzongató megoldások.
    Mutasd a teljes hozzászólást!
  • szutyok javascript
    nem akarok flamelni, de nekem pont a kedvencem a JS, kár lenne valami kötöttebb nyelvvel helyettesíteni.
    Mutasd a teljes hozzászólást!
  • alig várom, hogy elhangozzon az apple-től, meg a ms-től az alábbihoz hasonló:
    "A végleges HTML5 szabványból eltávolítottuk ezt meg ezt meg ezt, mert a felméréseink szerint a felhasználóknak nem ez kell, hanem inkább vegyék meg a Store-ban jó kis dollárokért, cserébe garantáljuk az élményt :)"
    Mutasd a teljes hozzászólást!
  • Nem olyan rossz ez a web szempontjából. Ez szvsz lényegében azt jelenti, hogy a w3c lényegében elveszíti a jelentőségét - ami nem is baj, ha megnézzük a jelenlegi webet. Az, ami eddig volt, a lehető legrosszabb megoldás volt a web szempontjából - hiába akart valaki valami értelmes dolgot csinálni, Pl. a gugli valami tisztességes programnyelvet a szutyok javascript helyett, a w3c-n biztosan nem ment át a dolog, mert a többi szereplő nem ebben érdekelt.

    Igazából egyébként a web akkor fejlődne, ha a böngészőpiac egyszereplős lenne - és ez az egy szereplő ebben lenne érdekelt. De míg a legtöbb szereplő (apple, ms, de részben a gugli is) pénze a desktopban van, és ők egy csapatba vannak zárva, addig ez kizárt.
    Mutasd a teljes hozzászólást!
  • Ó de jó
    Mutasd a teljes hozzászólást!
  • Csak, hogy teljes egyértelmű legyen a szakadás: a W3C szerdán négy új szerkesztőt jelölt ki a HTML5 karbantartására. Köztük 2 Microsoft- és egy Apple-alkalmazott, valamint egy független fejlesztő található meg. A WHATWG-ben ugye a Google embere (Ian Hickson) az elnök ill. ő volt megjelölve a HTML5 speckó szerkesztőjeként is.

    Innentől kezdve elég egyértelműnek tűnik, hogy a fejlesztések várhatóan két külön irányba fognak menni, a két meghatározó vállalatcsoport (Microsoft és esetleg Apple, valamint a Google és a Mozilla) érdekei mentén.
    Mutasd a teljes hozzászólást!
  • A 375 tagból tehát 5 gyárt piacképesnek mondható böngészőt, a maradék 370 tag pedig ...minden mást

    A web nem a böngészőgyártókból áll, és nem ők határozzák meg az igényeket, hanem "a minden más": a felhasználók és a fejlesztők (köztük a 370 darab egyéb tag), akik böngészik és akik alkalmazásokat készítenek rá. A böngészőkészítők dolga pedig mindössze utóbbiak igényeinek kiszolgálása (kellene hogy legyen). Amik között azonban egészen biztosan nem szerepel sem az, hogy hathetente frissíteni kelljen a szoftverüket, mindenáron, sem az, hogy két-három változatban kelljen megírni a weboldalaikat, csak azért, mert néhány agresszív kismalac nem tud megférni a többiekkel, és saját "szabványokat" akar kitalálni a már létezők mellé.

    "A" állítás: a W3C hátráltatja a HTML (és társi) szabványok böngészőkbe való implementálását

    Hogyan? A W3C ott áll a Google, a Mozilla és az Apple kóderei mögött, és hátratekeri a kezüket, hogy ne tudjanak kódolni? Vagy hogyan akadályozza meg "a HTML (és társi) szabványok böngészőkbe való implementálását"? És a külön specifikációk létrehozása hogyan fogja elősegíteni ezt?

    "B" állítás: a Google gonosz összeesküvést szőtt

    Semmiféle összeesküvésről nincs szó, csak a piac befolyásolásának és manipulálásának kísérletéről a saját érdekei szerint és a versenytársak érdekeivel szemben, a profitmaximalizálása érdekében. Ezt csinálja minden vállalkozás - a Google, az Apple és a Mozilla is. Ők magasról tesznek a web és a webezők érdekeire ha az szembemegy a saját profitérdekeikkel. Ezért is nem építenek az IE-éhez hasonlóan hatékony követésvédőt vagy reklámszűrőt a böngészőikbe. És ezért akarják mindenáron, idő előtt teleaggatni a böngészőiket kiteszteletlen dolgokkal is. A Google és a Mozilla azért, hogy versenyezni tudjanak a desktoppal és a natív alkalmazásokkal; az Apple-nek meg minden jó, ami csökkenti a web stabilitását és egységességét, mert annál több embert tud a zárt kertjén belül tartani. De egyikük sem azért akarja ezt, mert a webfejlesztők, a weboldalak vagy pláne a felhasználók tömegei igényelnék azt, hogy kedvenc weboldalaik egyik pillanatról a másikra megszűnjenek működni, vagy mert szeretnék mostantól weblapjaikat minden böngészőhöz külön-külön is megírni.

    Occam az "A"-ra szavazna. Én is. Ha Te a "B"-re, akkor az a Te véleményed.

    Se Occam, se én nem szavaznék egyikre sem, hiszen mindkettő állítás totális hülyeség.
    Mutasd a teljes hozzászólást!
  • Az "off-topik" arra vonatkozott (szerintem jól láthatóan oda írtam, az után a kijelentés után, amire értettem), hogy a HTML-hez nem igazán látom hozzátartozónak azt, hogy milyen védelmi mechanizmusokban ver rá az IE a többiekre. Ez - ha nem tetszik, akkor is - off-topik.

    Nem igazán akarok belebonyolódni egy soha véget nem érő vitába, mert feleslegesnek tartom. A véleményemet kifejteni írtam ide, nem pedig ennek szentelni életem hátralevő részét.

    A W3C-nek olyan, a web fejlődésében "hihetetlenül jelentős" szerepet játszó tagokat látok mint a Nemzeti (értsd: Amerikai) Rákkutató Intézet. Igen, látom, hogy ott van az AT&T, a Google, a Facebook és a MS is. De nem értem, mi jelentősége van a 375 tagnak, amikor ezek 95%-a gyakorlatilag akár a sarki fűszeres Bt-je is lehetne (ironizáltam!!), míg a böngésző- és webes piacot a maradék 5% képviseli, amelynek kb 95%-át a WHATWG csoport tagjai teszik ki (darabszámban). Ja igen, ott van még a CERN is - bár azt hiszem, ide passzolna az a közhely is, hogy "nem az apa, aki megcsinálta, hanem az, aki felnevelte" - dísznek.

    A 375 tagból tehát 5 gyárt piacképesnek mondható böngészőt, a maradék 370 tag pedig ...minden mást

    Occam borotvája?
    "A" állítás: a W3C hátráltatja a HTML (és társi) szabványok böngészőkbe való implementálását (talán mert túlméretezett[?]), ezért az ennek gördülékeny haladásában érdekelt csoport függetleníti magát tőle.
    "B" állítás: a Google gonosz összeesküvést szőtt - az őket lényegében eltartó - webezők és webfejlesztők ellen, ehhez betársult a "dróton ráncigált" Mozilla, a többiek csendben aszisztáltak mindehhez hiszen az Apple egyébként is ellenérdekelt a web fejlődésében (nyilván eleve kigáncsolni lépett be a csoportba!), valamilyen titokzatos szándék pedig nyilván az Operát is vezérli, ha már az előző háromtól függetlenként cinkosként síri csendben asszisztál a Google hazugságához (vagy annyira buta, hogy nem veszi észre a Google ármánykodását).

    Occam az "A"-ra szavazna. Én is. Ha Te a "B"-re, akkor az a Te véleményed.

    Szép jó éjt!
    Mutasd a teljes hozzászólást!
  • A csoport mögött érdekszövetség húzódik meg több másik többé-kevésbé jelentős piaci szereplővel, a döntés tehát nem húzható rá kizárólag erre a két résztvevőre.

    Na nézzük csak akkor:
    W3C: 375 regisztrált cég a tagja, és nem tudsz olyan közismert informatikai vállalkozást mondani, ami ne lenne köztük
    WHATWG: 4 cég a tagja (Google, Mozilla, Apple, Opera). Ezek közül ugye a Mozilla - évi 300 millióért - pontosan azt csinálja amit a Google mond neki, az Opera pedig gyakorlatilag jelentéktelen szereplő, az Apple-s fiúkról még sosem hallottam, hogy bármit is alkottak volna a WHATWG-n belül (ami nem is csoda, tekintve, hogy az Apple nem érdekelt a böngésző fejlesztésében zárt ekoszisztémája kiépítése óta - hiszen minél okosabb és minél többet tud a web, annál kevésbé van szükség az általa kínált natív alkalmazásokra, amik felett teljes kontrollt tud gyakorolni és gyakorol is). Viszont mindegy is, mert a csoport elnökét a Google adja.

    Ezek után
    1. azt állítani, hogy a WHATWG a piacot akár csak összehasonlítható mértékben is reprezentálná a W3C-vel
    2. tagadni, hogy ne a Google, és szócsöve valamint legjobb tanítványa, a Mozilla határozná meg, hogy mi történjen a csoporton belül
    elég furcsa kijelentésnek hat.

    Abból, hogy több helyen is megkerülhető tényezőnek de legalábbis hangsúlytalannak van feltűntetve. Hogy ne menjek messze, idézek a vonatkozó cikkből

    A cikk egyetlen egy hely - ráadásul kizárólag a WHATWG álláspontját írja le. Ez alapján azt mondani, hogy több - nem jelentéktelen - helyen lenne megkerülhető tényezőnek beállítva, megint csak elég furcsa kijelentésnek tűnik.

    a szabványosítás és valójában nem is lehet szabványról beszélni, akkor ez azt jelenti - logikusan - hogy a W3C szerepe alapvetően formális, ergo megkerülhető, mellőzhető.

    Nem az volt a kérdés, hogy technikai vagy jogi értelemben megkerülhető -e a W3C (mert persze, hogy az, mint ahogy a WHATWG is az), hanem az, hogy jó -e (és ha igen kinek) megkerülni őt.

    A W3C szükségességének megkérdőjelezése a web fejlődésében egyébként sem újkeletű dolog, évekre nyúló viták vannak erről. Nem fogok hivatkozáslistát gyűjteni, a jelenségről mindenbizonnyal Te is tudsz.

    Én olyasmiről tudok, hogy a lassúságát kritizálták. Arról, hogy értelmes ember és/vagy ne csak üzleti érdekből valaha is azt mondta volna, hogy egyáltalán ne lenne rá szükség, én nem tudok.

    Végig a WHATWG-ről van szó, tehát adódik a kérdés: ha a WHATWG-t nem akadályozza semmiben, akkor miért is beszélünk (beszél a cikk) a WHATWG döntéséről?

    Nem látom az ellentmondást amire a kérdésed rá akar mutatni. Lehet, hogy azért, mert nincs is?

    >>a munkacsoport mögött álló piaci szereplők az IE lemaradását és ebből következő lassú kiszorulását realizálhatták<<
    "Az IE annyira lemaradt a többi böngészőtől, hogy azok évek óta tőle másolnak dolgokat (hardveres gyorsítás, követésvédelem, kártevőszűrő, stb.)"
    Off-topik.

    Akkor minek írtad be ebbe a topikba? Vagy csak onnantól lesz off egy téma, hogy cáfolták a vele kapcsolatos kijelentéseidet?

    Az okfejtésemet ez sem cáfolja - ha így van, ha nincs - ti. tökmindegy, hogy le van-e maradva vagy sem, a WHATWG (mögött álló érdekcsoport) lépése és a "szabványozás" feltételezhető felgyorsulása a csoportból kimaradt MS-t fogja lépéskényszerbe hozni, nem azokat, akik a csoport mögött állnak. Ez egyszerű logika.

    Nem látom a logikát a dologban, tekintve, hogy még a böngészőpiacnak is csak a kisebbségét képviselik a WHATWG tagjai. Az egész webes ekoszisztémának meg még kisebb részét. Itt ha valaki, akkor csakis a felhasználók meg a fejlesztők hozhatják majd lépéskényszerbe a Microsoftot, azon keresztül, hogy elkezdik használni és elvárni a WHATWG által erőltetett technológiák minél előbbi beépítését az IE-be is. De a WHATWG mögötti cégek egészen biztosan teljességgel képtelenek lesznek bármiféle nyomás közvetlen kifejtésére a Microsoftra.

    Az ugyanakkor amiről én beszélek az, hogy teljesen függetlenül attól, hogy ezt fogják -e csinálni (és esetleg megint azt kezdik el szidni és okolni aki valójában NEM felelős az inkompatibilitási problémák kialakulásáért), vagy végre átlátnak majd a szitán (a Google-t és a Mozilla-t fogják lehülyézni, hogy miért siettették a dolgokat), a probléma még ott lesz, hogy ha elkezdenek beépíteni egy még nem eléggé kiforrott, kitesztelt technológiát a mainstream stabil böngészőkbe, majd utólag módosítják azt a felmerült problémák orvoslása végett, akkor pontosan ugyanaz a helyzet fog előállni, amitől úgy látszott, hogy végre kezdünk megmenekülni. Ti. hogy egyik weblap majd csak egyik böngészővel (böngészőváltozattal), a másik meg csak a másikkal fog működni. Vagy, hogy X-féle célkörnyezetre kell a weblapokt megírni.

    Betömködni? Pl. mit?
    Hm... Filter (CSS), XMLHttpRequest? Ezeket mindkettőt ActiveX segítségével fűzték az IE6-hoz - tudtommal. Az XHR-t legalábbis egészen biztosan.

    Rosszul tudod. Egyrészt mindkettőt tudták már az IE-k a 6-os verzió előtt is. Másrészt mindkettőt a Microsoft találta ki és az IE vezette be először - akkor, amikor (és ami után hosszú évekig) még egyetlen konkurens böngésző sem tudta ezeket. Tehát szó sem lehet arról, amit állítottál, hogy ezek bármiféle réseket vagy hiányosságokat képeztek volna, amiket ActiveX-en keresztül próbáltak volna betömködni, miután szélnek eresztették a böngészőt magját fejlesztő csapatot - mert, hogy amikor ezek készültek, akkor (és utána még évekig) még megvolt a böngészőt fejlesztő csapat; és mert ezek mind először az IE-ben bemutatott újdonságok voltak. Harmadrészt a CSS filterek nem ActiveX-, hanem DirectX-alapúak. Amely szavaknak ugyan mindegyike X-re végződik - de ezzel véget is ért minden hasonlóság közöttük.

    Ezt nem értem, pedig az Égiek a megmondhatói, nem mostanság kezdtem az ipart... akkor jól értem, hogy azt állítod, hogy az IE6 tulajdonképpen azért szabványtalan, mert a gonosz és/vagy butuska webfejlesztők összeesküdtek ellene, majd a W3C gondolt egyet és átvariálta a szabványokat, hogy aztán minden létező szabványteszten hosszú éveken keresztül alulteljesítsen?

    Nem. Azt állítom, hogy az IE6 szabványkövető - csak a webfejlesztők többsége (téged is beleértve) nem ért eléggé a webfejlesztéshez ahhoz, hogy tudja egyrészt ezt, másrészt azt, hogy hogyan lehet (ill. kell) szabványos oldalakat csinálni. Ha pedig nem "szabványosra" írsz meg egy oldalt (nem jelzed benne a "szabványnak" megfelelően vagy rosszul jelzed, hogy az melyik specifikáció szerint értelmezendő), akkor az IE nem az általad "szabványnak" tekintett specifikáció szerint fogja értelmezni és megjeleníteni azt, hanem - kompatibilitási okokból - a korábbi (általad "nem szabványosnak" tekintett, pedig "szabványt" ugyanannyira képező) specifikáció szerint. És ez fog a problémákhoz, a nem várt és eltérő működéshez vezetni.

    Ettől még az IE6 kiválóan ismeri és követi az úgymond "szabványokat" - csak a nem a "szabványnak" megfelelően készült weboldalakat (teljesen helyesen) nem a "szabvány" szerint fogja értelmezni. A valóban "szabványos" oldalakat viszont éppen úgy "szabványosan" jeleníti meg, mint az összes többi böngésző is. Amik azért jelenítik meg a nem "szabványos" weboldalakat másként, mint ő, mert kevesebbet tudnak nála, és ők csak az általad "szabványos"-nak titulált - valójában csak egy másik, a "nem szabványos"-sal egyenértékű és egy súlyú - specifikációt ismerik, így nem a "szabványnak" megfelelően megírt weboldalakat is a "szabvány" szerint tudják csak értelmezni.

    Egyébként azt, hogy az IE beelőzte a szabványt, speciel könyvben olvastam.

    Mindegy mit olvastál, mert az tény, hogy
    1. a HTML4-et 1999-ben, tehát két évvel az IE6 kiadása előtt már véglegesítették
    2. az IE6 teljes mértékben támogatta a HTML4-et (is), mármint értelemszerűen annak végleges változatát,
    így semmi alapja nincs annak, amit arról írtál, hogy
    1. ne várta volna be a MS a specifikáció véglegesítését
    2. hogy ebből eredtek volna a böngészők közötti inkompatibilitási problémák.

    Semmi problémát nem érzékelek a logikám konzekvens mivoltát illetően.

    Ez teljesen összhangban van az állításommal, amely szerint az érvrendszered nem logikus és nem konzisztens. Ha legalább ott lennél már, hogy érzékelnéd az ellentmondásokat, akkor elkezdhetnéd feloldani őket - de mivel még sem sem látod őket, erre esélyed sincs erre. Így még szép, hogy inkonzisztens és önmagának is ellentmondó marad.
    Mutasd a teljes hozzászólást!
  • Nem, természetesen nem olvastam végig az összes hozzászólást. Bele-bele olvastam, hogy nagyjából képben legyek, de perpillanat úgy gondolom, hogy ez az egyéb prioritásaim mellett elégséges is.

    Úgy látom, hogy következetesen kipécézted magadnak a Google-t és a Mozillát és ezzel alapvetően nem tudok egyetérteni. A csoport mögött érdekszövetség húzódik meg több másik többé-kevésbé jelentős piaci szereplővel, a döntés tehát nem húzható rá kizárólag erre a két résztvevőre.

    Ezt miből következtetted ki, hogy senki szerint nincs rá szükség?

    Abból, hogy több helyen is megkerülhető tényezőnek de legalábbis hangsúlytalannak van feltűntetve. Hogy ne menjek messze, idézek a vonatkozó cikkből: "amit aztán majd a W3C - ha akar - a maga tempójában követhet formális "szabványosítási" folyamatával" - tehát ha formális (az idézőjel használatát úgy interpretáltam, hogy a szabványosítás sem valódi, hanem legfeljebb kvázi-szabványosítás - hiszen ha valódi lenne, mi szükség az idézőjelre?) a szabványosítás és valójában nem is lehet szabványról beszélni, akkor ez azt jelenti - logikusan - hogy a W3C szerepe alapvetően formális, ergo megkerülhető, mellőzhető. A W3C szükségességének megkérdőjelezése a web fejlődésében egyébként sem újkeletű dolog, évekre nyúló viták vannak erről. Nem fogok hivatkozáslistát gyűjteni, a jelenségről mindenbizonnyal Te is tudsz.

    A W3C nem akadályozhatja semmilyen mértékben sem a csoport munkáját, mert hogy gyakorlatilag semmi közük nincs egymáshoz, pláne nem függenek egymástól

    Idézet újra a cikkből: "A szakítás elsősorban a [...] WHATWG-nek köszönhető, ami a jelek szerint nem bírta tovább cérnával, hogy a W3C úgymond lassú standardizálási procedúrájával gyakorlatilag megakasztja a web folyamatos és dinamikus, a változó igényekhez gyorsan igazodó módon történő továbbfejlesztését. Ezért a WHATWG úgy döntött, hogy a továbbiakban [...]" - Végig a WHATWG-ről van szó, tehát adódik a kérdés: ha a WHATWG-t nem akadályozza semmiben, akkor miért is beszélünk (beszél a cikk) a WHATWG döntéséről? Vagy akkor mind a cikk, mind magam is ugyanazt értjük a WHATWG alatt: nem a munkacsoportot magát, hanem a mögötte meghúzódó piaci érdekképviseleti szövetséget. Döntsük el, hogy melyik.

    Az IE annyira lemaradt a többi böngészőtől, hogy azok évek óta tőle másolnak dolgokat (hardveres gyorsítás, követésvédelem, kártevőszűrő, stb.)

    Off-topik.

    a CSS3 megfelelőségi tesztben a legújabb IE magasabb pontszámot ér el, mint a legújabb Chrome, Firefox és Opera

    Az okfejtésemet ez sem cáfolja - ha így van, ha nincs - ti. tökmindegy, hogy le van-e maradva vagy sem, a WHATWG (mögött álló érdekcsoport) lépése és a "szabványozás" feltételezhető felgyorsulása a csoportból kimaradt MS-t fogja lépéskényszerbe hozni, nem azokat, akik a csoport mögött állnak. Ez egyszerű logika.

    Betömködni? Pl. mit?

    Hm... Filter (CSS), XMLHttpRequest? Ezeket mindkettőt ActiveX segítségével fűzték az IE6-hoz - tudtommal. Az XHR-t legalábbis egészen biztosan.

    Nem pedig azért, mert az IE6 ne lett volna minimum annyira szabványkövető, mint a többi.

    Ezt nem értem, pedig az Égiek a megmondhatói, nem mostanság kezdtem az ipart... akkor jól értem, hogy azt állítod, hogy az IE6 tulajdonképpen azért szabványtalan, mert a gonosz és/vagy butuska webfejlesztők összeesküdtek ellene, majd a W3C gondolt egyet és átvariálta a szabványokat, hogy aztán minden létező szabványteszten hosszú éveken keresztül alulteljesítsen? Nane...

    Egyébként azt, hogy az IE beelőzte a szabványt, speciel könyvben olvastam. Adósod leszek egy címmel és egy kiadóval, de nem mai darab és sajnos jelenleg mintegy 280 km-re található a lakásomtól.

    ezért jól mutatja, hogy véleményed mennyire nem - legalább önmagában - logikus, konzisztens érvrendszeren alapszik.

    Semmi problémát nem érzékelek a logikám konzekvens mivoltát illetően. Ugyanis nem azt állítom, hogy az nem szülhet problémákat, hogy valamit "béta" állapotban fognak implementálni, hanem azt állítom - és ezt végig következetesen - hogy a böngészőgyártók többségét a WHATWG összefogja annyira, hogy ebből számottevő és tartósan abszurd helyzet (mint amilyen korábban volt egy hasonló érdekszövetség hiányában) nem fog keletkezni várhatóan.

    Ha már valamibe belekötnék az érvelésemben ezen a ponton, az a CSS3 gyártó-specifikus kiterjesztéseinél írtak lennének, hiszen ott érzékelhetőek már "elúszások" (ezzel hatékonyabban lehetne riogatni). Megjegyzendő azonban, hogy a CSS3-ban gyakorlatilag szabványosították azt, hogy hogyan lehet szabványtalannak lenni. Pontosan ezért probléma, de ilyen probléma a HTML specifikációjában nincs - és remélhetőleg nem is lesz, mint ahogy a vonatkozó szabványelemről is egyre több és egyre hangosabb vélekedés jelenik meg, miszerint igencsak problémás (itt emlékezetes az Opera és a Mozilla -webkit prefix implementációs kényszere).

    Összefoglalva tehát:
    - Nem kétrésztvevős volt a döntés, hanem legkevesebb négy;
    - WHATWG az előző, a mostani és minden további hsz.-omban = a mögötte álló érdekcsoporttal;
    - Az IE technológiailag tarthat előrébb, a kapcsolódó témában (vö.: HTML, CSS) nem túl tartós és nem túl jelentős előnyre tehetett csak szert;
    - Továbbra is úgy tartom, hogy amíg a WHATWG résztvevői képesek a saját "szabványuk" követésére, addig az elszabaduló és jelentős inkompatibilitás előrevetítése csak hisztéria, aminek semmi valós alapja sincs, mert a múltban ilyen átfogó piaci összefogás nem létezett.
    Mutasd a teljes hozzászólást!
  • Szerintem ha a csoport nem hullik szét, akkor nincs ok az aggodalomra alapvetően.

    Ezek szerint egy hozzászólást se olvastál el a topikból mielőtt beleírtál.

    Nekem innen egyelőre inkább tűnik úgy, hogy a webes piac megunta a W3C vakarodzását és mintegy szükségtelen elemnek nyilvánította

    A kettőnek semmi köze nincs egymáshoz. Mármint attól, hogy vakaródzik, nem lesz felesleges elem - legfeljebb csak gyorsításra szorulna (ha már valamire).

    A valós "probléma" - legalábbis a a Google és a Mozilla szemszögéből - vele ehelyett az, hogy nem teszi lehetővé számukra, hogy a folyamatos fejlődés és a szabványkövetés látszatát egyszerre tartsák fenn böngészőikben, ill. hogy kizárólag az ő üzleti érdekeinek alá rendelve kerüljenek a szabványok alakításra. Ezért szeretnék elrakni az útból és egy általuk irányított és uralt csoporthoz vonni a szabványosítás folyamatát - teljesen függetlenül attól, hogy annak piaci reprezentációja szinte jelentéktelen a W3C-hoz képest, aminek sokkal több cég és szervezet a tagja. Köztük többek között a Microsoft is, aminek a böngészőjét még mindig többen használják, mint a WHATWG-tagok böngészőit összesen, együtt.

    (egyébként tényleg: miért lenne rá szükség, ha egyébként senki szerint nincs rá szükség igazán?)

    Ezt miből következtetted ki, hogy senki szerint nincs rá szükség?

    Ha a W3C valóban hátráltatta a csoport munkáját

    Ezek szerint még annyira sem érted a WHATWG és a W3C szerepét, kapcsolatát, mind az előbb gondoltam. A W3C nem akadályozhatja semmilyen mértékben sem a csoport munkáját, mert hogy gyakorlatilag semmi közük nincs egymáshoz, pláne nem függenek egymástól.

    Stratégiailag is inkább azt feltételezem, hogy a felgyorsított szabványosodás eredményeként a munkacsoport mögött álló piaci szereplők az IE lemaradását és ebből következő lassú kiszorulását realizálhatták

    Az IE annyira lemaradt a többi böngészőtől, hogy azok évek óta tőle másolnak dolgokat (hardveres gyorsítás, követésvédelem, kártevőszűrő, stb.), vagy hogy pl. a CSS3 megfelelőségi tesztben a legújabb IE magasabb pontszámot ér el, mint a legújabb Chrome, Firefox és Opera.

    Ennek a folyamatnak - túl az IE6 idejében lévő és fent is vázolt piaci állapotokon - az is oka volt anno, hogy az akkori fejlesztőgárdát elbocsátották és csak bugfix-eket végeztek a böngészőn, meg amit lehet azt megpróbálták betömködni az ActiveX-en keresztül

    Betömködni? Pl. mit?

    de valójában évekig nem fejlesztették a böngészőt, ami egyébként azért lett szabványtalan, mert az MS nem várta be, amíg a W3C komótosan szabványosítani méltatta vala a HTML4-et, hanem a szabványelőzetes alapján állította össze a böngészőt

    Ez furcsa lett volna, hiszen az IE6 két évvel a HTML4 véglegesítése után jelent meg. Amit egyébként az IE6 gyakorlatilag tökéletesen követett is - csak sajnos a webfejlesztők béna többsége nem tudta, hogy hogyan kell szabványos dokumentumot készíteni. Ezért jelentek meg bizonyos - a szóban forgó működvelő amatőrök által nem a szabványnak megfelelően készített - oldalak, szerkezetek másként IE-ben és más böngészőkben. Nem pedig azért, mert az IE6 ne lett volna minimum annyira szabványkövető, mint a többi.

    Egyébként meg az előbb azt mondtad, hogy semmi baj nem lesz a WHATWG partizánságából, azaz abból, hogy annak tagjai már jóval véglegesítés és alapos tesztelés előtt beépítenék az új bővítéseket a szabványokhoz a böngészőkbe. Most meg azt mondod, hogy pont abból volt a baj, hogy az IE nem várta meg a véglegesítést, hanem egy korai változatot implementált. Ami bár nem igaz, de mivel tökéletesen ellentmondásban van az általad előbb írottakkal, ezért jól mutatja, hogy véleményed mennyire nem - legalább önmagában - logikus, konzisztens érvrendszeren alapszik.
    Mutasd a teljes hozzászólást!
  • Szerintem ahhoz, hogy bármit is érdemben ki lehessen fejteni ezzel a hírrel kapcsolatban, azt kéne tudni, pontosan mitől ilyen tetülassú a W3C szabványosítási procedúrája.

    Addig én ezt az egészet csak jajveszékelésnek gondolom. A korábbi inkompatibilitásokkal a fő gond az volt, hogy a böngészők gyártói mentek a maguk feje után. Most ezzel szemben (az MS kivételével) a WHATWG-ben ott van - tudtommal - az Apple, a Google, a Mozilla és az Opera is. A legtöbb jelenkori elszállás sem a HTML5-ben tapasztalható egyébként, hanem a CSS3 vendor-specific elemeinél, amit bevezetni egyreinkább általános véleménnyé válik, hogy őrületesen nagy hiba volt.

    Szerintem ha a csoport nem hullik szét, akkor nincs ok az aggodalomra alapvetően. Nekem innen egyelőre inkább tűnik úgy, hogy a webes piac megunta a W3C vakarodzását és mintegy szükségtelen elemnek nyilvánította (egyébként tényleg: miért lenne rá szükség, ha egyébként senki szerint nincs rá szükség igazán?). Semmi extrát nem látok ebben, a W3C bukta az egyébként is igencsak megtépázott presztizsét (szvsz az egyetlen dolog, amiben élen járnak, az az, hogy miként lehet valamit minél lassabban és agyamentebben szabványosítani).

    Ha a W3C valóban hátráltatta a csoport munkáját, akkor ennek a lépésnek az egyetlen várható következménye inkább az, hogy a csoport hatékonyabbá fog válni, mind eddig volt.

    Stratégiailag is inkább azt feltételezem, hogy a felgyorsított szabványosodás eredményeként a munkacsoport mögött álló piaci szereplők az IE lemaradását és ebből következő lassú kiszorulását realizálhatták, semmint különféle PR okokat.

    Arra sem számítok, hogy az IE elszabványtalanodik ennek következtében. Ennek a folyamatnak - túl az IE6 idejében lévő és fent is vázolt piaci állapotokon - az is oka volt anno, hogy az akkori fejlesztőgárdát elbocsátották és csak bugfix-eket végeztek a böngészőn, meg amit lehet azt megpróbálták betömködni az ActiveX-en keresztül, de valójában évekig nem fejlesztették a böngészőt, ami egyébként azért lett szabványtalan, mert az MS nem várta be, amíg a W3C komótosan szabványosítani méltatta vala a HTML4-et, hanem a szabványelőzetes alapján állította össze a böngészőt, amit röviddel a kiadás után nem is fejlesztett tovább.

    Teljesen más volt a piaci klíma annak idején és más most, nem értem, ki és milyen alapon von párhuzamot az akkor és a most között. Én a W3C tesze-toszaságán kívül egyetlen picit is komoly közös nevezőt sem találok a múlt és a jelen viszonyában.
    Mutasd a teljes hozzászólást!
  • A WHATWG azt akarja kikerülni, hogy először ki kelljen gyomlálni a bugokat és problémákat, és csak amikor már hosszú ideje nem találni problémát vele, akkor kerüljenek az éles böngészőkbe is beépítésre ill. széles körben használatra az új technológiák.


    Azt én is értem, hogy alfa/béta változatban levő dolgokat akarnak betenni éles böngészőbe, de hol mondják azt, hogy széles körben is akarják használtatni a weboldalakkal? Egy felelős webfejlesztő nyilván nem fog ész nélkül "éles" oldalban (értsd: olyan oldalban, aminek a hibája pénzveszteséget okoz) ki nem forrott technológiát használni. Ebben az is segíti, hogy vannak tanácsadó oldalak, ami alapján be lehet lőni, hogy mi érett már meg a használatra.

    Nem kell kivárniuk, de azt egyértelműen jelezniük kellene szerintem, hogy a dolog kísérleti és változhat.

    És mégis hogyan? Amikor egy weboldal elkezd egy úgymond csak kísérleti technológiát használni, akkor dobjon fel a júzernek egy figyelmeztetést, hogy ez még csak kísérletileg van benne?


    Nem a látogatót kell figyelmeztetni, mert ő amúgy se ért hozzá, hanem a webfejlesztőt, aki használni akarja. Mondjuk azzal, hogy nem implementáljuk a leendő szabványos nevével, hanem csak vendor prefixes változatban. A mitigációról pedig annyit, hogy, ahogy fentebb mondtam, az ilyesmire nem kell építeni semmi kritikus (=pénzt érő) dolgot. Aki játszani akar vele, az pedig hadd játsszon, annál több tesztelője van a dolognak.

    Adott esetben használjanak vendor prefixet is akár.

    Ehhez akkor miért kell a WHATWG? Ezt a gyártók maguk is meg tudják valósítani saját hatáskörben.


    De hát a WHATWG-t pont a gyártók hívták életre, a közös munka koordinációjára. Ez az a szervezet, ahol "saját hatáskörben" összehangolják az új fejlesztéseket.

    Bár az ötlet maga is agyrém egyébként, tekintve, hogy ezzel pontosan azt mondod, hogy jöjjenek csak vissza azok az idők, amikor 3-4-szer kellett megírni egy weboldalt - minden elterjedt böngészőre egyszer.


    Már miért kellene minden böngészőre külön megírni, ha közös irányba fejlesztenek mindent? Nem arról van szó, hogy egyszer meg kell írni mondjuk -ms-filter propertyvel, egyszer meg opacity propertyvel, hanem lényegében ugyanazt a propertyt használod különböző prefixekkel. A prefix célja csak az, hogy a jelenlegi (esetleg bugos, pontatlan) szemantikát elválassza a végleges szemantikától, amíg kérdéses a dolog stabilitása.

    Ezután azt elvárni, hogy majd a W3C fogja vinni az innovációt előre, és proaktívan kezd dolgokat szabványosítani, elég érdekesen hangzik.

    Ezt tőled olvasom először a topikban. Mármint hogy bárki is ezt várná el.


    Jó. Szóval akkor kihez is forduljon egy böngészőgyártó, aki szeretne valami újdonságot implementálni, de el szeretné kerülni, hogy a többiek teljesen inkompatibilis módon csinálják a hasonló fejlesztéseiket? A W3C-t most beszéltük meg, hogy nem akarják kivárni, mert náluk minden évekbe telik. Inkább egyeztetnek a WHATWG-n belül, és konszenzussal bővítik a közös specifikációjukat.

    Ráadásul azzal, hogy kvázi deklaráltan nem is akarják követhetővé tenni a változásokat (ami persze érhető is, ha ezekre ad hoc módon kerülhet sor, akár naponta is), lehetetlenné teszik még olyan alapvetően csúnya, de azért csak működő hackek bevetését is keletkeztetett problémák súlyának mérséklésére, mint pl. a DOCTYPE.


    A DOCTYPE-ot egyébként is régóta kivették már azzal, hogy a "<!DOCTYPE html>"-t ajánlják a HTML kód elejére rakni, amiben ugye semmilyen verziószám nincs megadva. Gondolom abban bíznak, hogy sikerül "eléggé" előre kompatibilisnak maradni ahhoz, hogy a régi oldalak is használhatóak maradjanak.

    Nyilván elvben meg tudnák tenni, hogy egyik napról a másikra átírják a specifikációt, és direkt elrontják az eddigi dolgok kompatibilitását, de felteszem, hogy nem ez a szándékuk. (Főleg, hogy ezzel magukat is szivatnák, hiszen őnekik kell implementálni az újat is.) Szóval nem a lehető legrosszabb esetet kellene egyből a falra festeni.

    Semmit sem ér egyes (úgymond stabil) részek vonatkozásában a visszafelé kompatibilitás megőrzése, ha közben más részek (ti. a fejlesztés alatt állók) vonatkozásában ez nem biztosított. Mert teljesen lényegtelen, hogy egy weboldal azért nem szűnik meg működni egyik napról a másikra, mert a <p> taget írták át <x>-re, vagy mert a <video>-t nevezték át <player>-re.


    De, ahogy eddig is mondtam, az a weboldal, ami fejlesztés alatt álló dolgokat használ, ezt annak a tudatában teszi (vagy legalább is így kéne tennie), hogy ezek még változhatnak. Úgymond vállalja azt a kockázatot, hogy ő az adott feature egyik bétatesztere, és ha úgy alakul, alkalmazkodnia kell a változásokhoz. És persze az a minimum, hogy van egy B terve az adott dolgot nem ismerő böngészők kedvéért.
    Mutasd a teljes hozzászólást!
  • Azt fogják csinálni a böngészők gyártói amit eddig, ráhagyják a probléma megoldását a kóderekre.
    Mutasd a teljes hozzászólást!
  • Hol írta Hickson az e-mailjében, hogy a bugfixeket ki akarják kerülni? Az nem tetszik nekik, hogy új feature nem kerülhet be a specifikációba, illetve pont hogy fontosabbnak tartják a bugok javítását, mint egy konkrét állapot rögzítését.

    Nem érted. A WHATWG azt akarja kikerülni, hogy először ki kelljen gyomlálni a bugokat és problémákat, és csak amikor már hosszú ideje nem találni problémát vele, akkor kerüljenek az éles böngészőkbe is beépítésre ill. széles körben használatra az új technológiák. Ha ezt nem így csinálják, hanem fordítva, akkor az azzal jár, hogy előbb-utóbb valami olyan módosításra lesz szükség, ami megtöri a kompatibilitást a korábbi, "bugos", nem elég pontos, önellentmondásos, ineffektív, stb. specifikációkkal ill. az azokon alapuló implementációkkal. Azaz, addig jól működő weboldalak hirtelen elkezdenek nem működni, ill. az egyes böngészőket ugyanazokat a dolgokat elkezdik másként értelmezni, megjeleníteni, stb.

    Nem kell kivárniuk, de azt egyértelműen jelezniük kellene szerintem, hogy a dolog kísérleti és változhat.

    És mégis hogyan? Amikor egy weboldal elkezd egy úgymond csak kísérleti technológiát használni, akkor dobjon fel a júzernek egy figyelmeztetést, hogy ez még csak kísérletileg van benne? És ez mennyiben fogja mitigálni a későbbi javításokból adódó kompatibilitási problémákat? Azt, hogy a tegnap még kiválóan működő weboldal egyszer csak megszűnik majd működni vagy másként jelenik meg és kerül értelmezésre holnaptól?

    Adott esetben használjanak vendor prefixet is akár.

    Ehhez akkor miért kell a WHATWG? Ezt a gyártók maguk is meg tudják valósítani saját hatáskörben. Bár az ötlet maga is agyrém egyébként, tekintve, hogy ezzel pontosan azt mondod, hogy jöjjenek csak vissza azok az idők, amikor 3-4-szer kellett megírni egy weboldalt - minden elterjedt böngészőre egyszer.

    A WHATWG pont azért jött létre annak idején, mert a W3C nem volt képes megfelelően szabványosítani az újdonságokat, illetve olyat próbált erőltetni, amire nem volt igény (XHTML 2.0).

    Ez idáig oké. Ugyanakkor ez nem szentesíti a WHATWG minden cselekedetét - pláne nem akkor, amikor ő maga is pontosan ugyanabba a hibába esik, mint anno a W3C. Hiszen teljesen nyilvánvaló, hogy a legtöbb HTML5 technológiára az átlagos webszájtnak az ég világon semmi szüksége nincs, és mindössze a Google-nek kellenek ahhoz, hogy a böngészőből minden, jelenleg még az asztali alkalmazások által uralt piacon is versenyezni tudjon.

    Ezután azt elvárni, hogy majd a W3C fogja vinni az innovációt előre, és proaktívan kezd dolgokat szabványosítani, elég érdekesen hangzik.

    Ezt tőled olvasom először a topikban. Mármint hogy bárki is ezt várná el.

    Ha jól értem, az alapelv az lenne, hogy stabil dolgoknál tartjuk a visszafelé kompatibilitást, kísérleti jellegű dolgoknál a bugfix a lényeg, és aki kritikus dologra használta, az magára vessen.

    De ha egy úgymond kísérleti technológia megjelenik a mainstream böngészők stabil változataiban, a weboldalak pedig elkezdik használni, onnantól kezdve már nem csak kísérleti technológia lesz, és minden módosítása webalkalmazások tömegeit fogja érinteni és többé-kevésbé használhatatlanná tenni. Ami végő soron ahhoz fog vezetni, hogy mind a fejlesztők, mind a felhasználók elkezdik a webet problémás technológiának tekintetni - ami nyilvánvalóan nem lehet a WHATWG célja.

    Hát nem tudom, mennyire lenne kitesztelve valami olyan, amit csak speciális böngésző builddel lehet kipróbálni.

    Ugyanannyira, mint bármelyik szoftver, amit csak a tesztelők kapnak meg. Gyakorlatilag minden program így készül - és a végén mégsem egy óriási bughalmaz az ami a felhasználókhoz kerül a szoftver stabil változatában. Pedig ott nem csak a tervezési, hanem implementációs hibákról is beszélünk (és 100 hibából általában 99 implementációs, nem tervezési hiba a szoftvereknél), ami viszont nyilván egy specifikáció esetében nem ill. csak minimális mértékben játszik.

    Így akármilyen blogra ki lehet rakni teszem azt "Töltsétek le a legújabb Chrome-ot és nézzétek meg a linkelt demót", és máris nyúzzák élesben az emberek, nem kell előtte mindenféle speciális verziót telepítgetni.

    Ez a lényege a kísérleti technológiáknak és a fejlesztő verzióknak. Hogy még véletlenül sem lehet azt gondolni róluk, hogy na akkor most erre a dologra lehet építeni - mert hogy speciális környezet kialakítása kell a használatukhoz. Ezzel szemben ha valamelyik technológia elérhetővé kezd válni a mainstream böngészők nagy részében, akkor - teljesen logikusan - elkezd építeni majd mindenki rá, ami vagy lehetetlenné teszi majd a hibák utólagos javítását, vagy a javítások révén az addig elkészült weboldalak működése fog veszélybe kerülni.

    Azt értsd meg, hogy itt nem implementációs bugokról beszélünk, azaz amikor valami nem úgy működik, ahogy a specifikációban van leírva, és a javítás kvázi a tényleges működés az elvárthoz (a specifikációhoz) igazítást jelenti. Hanem - mivel egy specifikációról beszélünk - tervezési hibák (ellentmondások, szűk keresztmetszetek, biztonsági rések, stb.) javításáról, hiányosságokról pótlásáról van szó, a specifikáció szintjén, ami önmagában indukálja, kiváltja az implementáció, azaz a tényleges működés változtatásának szükségességét (és így a 100%-os kompatibilitás potenciális megtörését), legalábbis akkor, ha az implementációkkal (böngészőkkel, weboldalakkal) követni akarja valaki folyamatosan a specifikáció változásait.

    De ugyanígy a CSS3 dolgai is elérhetők a rendes böngészőbuildekben, instabil dolgok esetén a megfelelő vendor prefixszel, és bárki nézegetheti. Ha megváltozik, hát így jártak, akik használták, elvégre instabil a dolog.

    Pont ezt igazolja és bizonyítja, hogy milyen következményekkel jár az, ha egy kiforratlan, nem véglegesített (ill. véglegesítéshez még közel sem álló) technológiát kezdenek el beépíteni és elérhetővé tenni a böngészőkben. A fejlesztők elkezdik használni.

    Pedig a probléma a CSS esetében eleve nem is lehet olyan vészes, hiszen a CSS gyakorlatilag semmilyen szemantikát nem hordoz magában, mindössze csak a megjelenítést befolyásolja. Ráadásul a CSS3 jellemzően csak olyan dolgokat ad hozzá a CSS korábbi változataihoz, amik csak dekorációs jellegűek, és nem támogatásuk vagy rossz értelmezésük a legritkább esetben tesz használhatatlanná egy oldalt. Pl. ha egy böngésző nem ismeri a border-radius-t, azaz nem tudja lekerekíteni a dobozokat, az a legritkább esetben okoz bármilyen problémát. Ezzel szemben ha pl. egy böngésző nem támogatja a <video> taget, vagy a <canvas>-t akkor teljesen értelmét vesztheti és használhatatlanná válhat az ezeket használó videólejátszó vagy grafikonrajzoló.

    Valóban, magát a verziószámot teszi értelmetlenné a változó szabvány. De pont ezért a WHATWG a saját verzióját már nem is HTML5-nek hívja, hanem a "HTML - A Living Standard" néven emlegeti.

    Magyarul még revizíószámmal sem látja el ill. nem követi ezt. Hát, ez tényleg marhára jó - mert így abszolút nem lehet követni, definiálni vagy számonkérni semmiféle megfelelőséget. Attól függetlenül is, hogy ami ma 100%-osan megfelelő, az holnapra teljesen inkompatibilissé is válhat, pusztán azért, mert átírják a szabványt.

    Mi köze ennek egyáltalán bármiféle szabványosításhoz? Annak az a lényege, hogy kőbe vésett fix dolog, amikhez mindenki igazodhat. Egy folyamatosan változó dologhoz viszont nem lehet igazodni, ill. értelmezhetetlen bármiféle megfelelőség hajszolása vagy kinyilvánítása, ami így csak pillanatnyi lehet.

    Ráadásul azzal, hogy kvázi deklaráltan nem is akarják követhetővé tenni a változásokat (ami persze érhető is, ha ezekre ad hoc módon kerülhet sor, akár naponta is), lehetetlenné teszik még olyan alapvetően csúnya, de azért csak működő hackek bevetését is keletkeztetett problémák súlyának mérséklésére, mint pl. a DOCTYPE. Ami ugye eleve csúnya, hogy ti. ennek értéke alapján ugyanazt a dolgot különbözőképpen értelmezzük - de ha már nem is lehet majd megmondani, hogy a specifikáció melyik változata szerint kellene értelmezni a weboldalt ill. a böngésző számára is lehetetlenné fog válni ez (ti. húszcsillió specifikáció-változatot implementáló értelmezőmotor párhuzamos biztosítása), akkor csakis az következhet be, amit írtam, hogy ti. egyes, korábban hibátlanul működő weboldalak egyszerűen csak elkezdenek majd nem működni. És mind a weboldalak fejlesztői, mind a böngésző fejlesztői, mind a felhasználók számára teljesen követhetetlenné válik majd, hogy akkor mi is passzol össze mivel - és pláne lehetetlenné válik majd az adott weboldalakhoz, webalkalmazásokhoz passzoló böngészők birtoklása, futtatása és használata előbbiek megnyitásához.

    Én továbbra is szeretném hinni, hogy a stabil részek visszafelé kompatibilitásának megtartása révén az idén "megfelelő" implementációd jövőre csak "részleges implementáció"-vá válik, nem lesz belőle "helytelen implementáció".

    Semmit sem ér egyes (úgymond stabil) részek vonatkozásában a visszafelé kompatibilitás megőrzése, ha közben más részek (ti. a fejlesztés alatt állók) vonatkozásában ez nem biztosított. Mert teljesen lényegtelen, hogy egy weboldal azért nem szűnik meg működni egyik napról a másikra, mert a <p> taget írták át <x>-re, vagy mert a <video>-t nevezték át <player>-re. Mindkét esetben ugyanúgy megszűnik úgy működni és megjelenni ahogy eddig tette - és még csak azt se mondhatod, hogy utóbbi, kvázi frissebb részekben végrehajtott változtatás kisebb mértékben rontja és lehetetleníti el a működését, mint a már sokkal régebbi, régóta stabilnak tekintett részekben.
    Mutasd a teljes hozzászólást!
  • Ezzel a W3C eljárás helyessége mellett és a WHATWG ellen érvelsz. Hiszen pontosan ez a folyamat az amit a W3C megvalósít, és amit a WHATWG ki akar kerülni.


    Hol írta Hickson az e-mailjében, hogy a bugfixeket ki akarják kerülni? Az nem tetszik nekik, hogy új feature nem kerülhet be a specifikációba, illetve pont hogy fontosabbnak tartják a bugok javítását, mint egy konkrét állapot rögzítését.

    Ha pedig azt javaslod, hogy a böngészőgyártóknak minden egyes bug, hiba esetén ki kellene várniuk az implementációjuk megvalósításával amíg a bugok kijavításra kerülnek, akkor azzal pedig azt mondod, hogy meg kell várniuk amíg a specifikáció végleges állapotba kerül.


    Nem kell kivárniuk, de azt egyértelműen jelezniük kellene szerintem, hogy a dolog kísérleti és változhat. (Adott esetben használjanak vendor prefixet is akár.) És nem kell megvárniuk a specifikáció összes bugjának a kijavítását, csak az adott feature nyitott kérdéseinek eldöntését.

    Van közös spec ami összehangolja őket. Ezt ill. ezeket a W3C adja ki.

    A WHATWG pont azért jött létre annak idején, mert a W3C nem volt képes megfelelően szabványosítani az újdonságokat, illetve olyat próbált erőltetni, amire nem volt igény (XHTML 2.0). Pont arról szól a dolog, hogy az implementálók a saját kezükbe vették a spec elkészítését, amit végül a W3C is kénytelen volt átvenni, amikor látta, hogy az XHTML nem jut sehová. Ezután azt elvárni, hogy majd a W3C fogja vinni az innovációt előre, és proaktívan kezd dolgokat szabványosítani, elég érdekesen hangzik.

    A WHATWG akciója csak arról gondoskodik, hogy még egy specifikáció (illetve még N darab a maga N revíziójával, a folyamatos fejlesztés miatt) amihez lehessen illeszkedni, ezáltal potenciálisan interoperábilitási problémákat okozva azokkal az implementációkkal, amik meg nem ugyanahhoz a specifikációhoz ill. revízióhoz igazodnak.


    Ha jól értem, az alapelv az lenne, hogy stabil dolgoknál tartjuk a visszafelé kompatibilitást, kísérleti jellegű dolgoknál a bugfix a lényeg, és aki kritikus dologra használta, az magára vessen.

    És ki mondta, hogy senki ne próbálja implementálni? Itt arról van szó, hogy a böngészők éles változatába ne kerüljön bele egy olyan specifikáció támogatása, ami még nincs véglegesítve. Hanem maradjon meg kísérleti technológiának a böngészők kísérleti változataiban, amiket így értelemszerűen kísérleti oldalakon használnak majd csak. Aztán legkésőbb ott kibukik majd ha van valami baj vele.


    Hát nem tudom, mennyire lenne kitesztelve valami olyan, amit csak speciális böngésző builddel lehet kipróbálni. Így akármilyen blogra ki lehet rakni teszem azt "Töltsétek le a legújabb Chrome-ot és nézzétek meg a linkelt demót", és máris nyúzzák élesben az emberek, nem kell előtte mindenféle speciális verziót telepítgetni. De ugyanígy a CSS3 dolgai is elérhetők a rendes böngészőbuildekben, instabil dolgok esetén a megfelelő vendor prefixszel, és bárki nézegetheti. Ha megváltozik, hát így jártak, akik használták, elvégre instabil a dolog.

    Utóbbi metodika követhetetlenné és megfoghatatlanná teszi a HTML5-megfelelőség fogalmát, azon keresztül, hogy ami tegnap megfelelő volt, az holnap már lehet nem lesz az, az akkora már módosított "szabvány" miatt.


    Valóban, magát a verziószámot teszi értelmetlenné a változó szabvány. De pont ezért a WHATWG a saját verzióját már nem is HTML5-nek hívja, hanem a "HTML - A Living Standard" néven emlegeti. Én továbbra is szeretném hinni, hogy a stabil részek visszafelé kompatibilitásának megtartása révén az idén "megfelelő" implementációd jövőre csak "részleges implementáció"-vá válik, nem lesz belőle "helytelen implementáció". Hogy melyikünknek lesz igaza, azt majd meglátjuk
    Mutasd a teljes hozzászólást!
  • Persze felmerül a kérdés, hogy ha nem volt egyértelmű valami, akkor miért csináltak hozzá "éles" (nem alfa, nem béta) implementációt ahelyett, hogy bug reportot küldtek volna a spec fejlesztőinek.

    Ezzel a W3C eljárás helyessége mellett és a WHATWG ellen érvelsz. Hiszen pontosan ez a folyamat az amit a W3C megvalósít, és amit a WHATWG ki akar kerülni. Ha pedig azt javaslod, hogy a böngészőgyártóknak minden egyes bug, hiba esetén ki kellene várniuk az implementációjuk megvalósításával amíg a bugok kijavításra kerülnek, akkor azzal pedig azt mondod, hogy meg kell várniuk amíg a specifikáció végleges állapotba kerül. Tehát megint csak azt mondod, hogy a W3C folyamata az ami követendő.

    A böngésző-implementációk valószínűleg tudnák követni. A weboldalak már sokkal kevésbé, mert a weboldalak nagy részét nem akarják hetente átírkálni ad-hoc változások miatt.

    Erről van szó. Ezért nem lehet azt csinálni, hogy utólag kitaláljuk, hogy mégse úgy legyen valami ahogy eddig volt, vagy ahogy eddig csinálták egyes böngészők, mert nem volt elég pontos és/vagy önmagában ellentmondó volt a specifikáció. Tehát megint csak azt mondod, hogy a szabványt először rögzíteni kell (nyilván megfelelően hosszú peer review és tesztelés után), és csak azt követően lehet elkezdeni implementálni az éles böngészőkben.

    Hát ha nincs egy közös spec, amit kövessenek, akkor ki/mi fogja összehangolni őket?

    Van közös spec ami összehangolja őket. Ezt ill. ezeket a W3C adja ki. A WHATWG akciója csak arról gondoskodik, hogy még egy specifikáció (illetve még N darab a maga N revíziójával, a folyamatos fejlesztés miatt) amihez lehessen illeszkedni, ezáltal potenciálisan interoperábilitási problémákat okozva azokkal az implementációkkal, amik meg nem ugyanahhoz a specifikációhoz ill. revízióhoz igazodnak.

    Az a baj, hogyha nem próbálja senki implementálni az új dolgokat, akkor nem fog kibukni, hogy ellentmondás vagy kétértelműség van a specifikációban.

    És ki mondta, hogy senki ne próbálja implementálni? Itt arról van szó, hogy a böngészők éles változatába ne kerüljön bele egy olyan specifikáció támogatása, ami még nincs véglegesítve. Hanem maradjon meg kísérleti technológiának a böngészők kísérleti változataiban, amiket így értelemszerűen kísérleti oldalakon használnak majd csak. Aztán legkésőbb ott kibukik majd ha van valami baj vele. És az éles böngészőkbe már csak akkor kerüljön a fícsör, amikor már minden lehetséges tesztelésen átesett, és véglegesnek tekinthető. Pont úgy, ahogy ez klasszikusan szoftverek esetében működik.

    Ha pedig még a fenti folyamat ellenére is marad hiba a HTML5-ben, akkor majd a HTML6-ban javítjuk azt - de nem a HTML5 rev2736735-ben. Utóbbi metodika követhetetlenné és megfoghatatlanná teszi a HTML5-megfelelőség fogalmát, azon keresztül, hogy ami tegnap megfelelő volt, az holnap már lehet nem lesz az, az akkora már módosított "szabvány" miatt.
    Mutasd a teljes hozzászólást!
  • Egyébként meg onnantól, hogy egyetlen korábban nem pontosan tisztázott részt tovább pontosítanak vagy egy ellentmondást feloldanak (amiket már egy azt esetleg implementáló böngésző saját hatáskörben valahogy megoldott ill. feloldott) már nem garantálható a 100%-os visszafelé kompatibilitás.


    Hát ha két implementáció másképp értelmez valamit, akkor utólag már nyilván vagy a "minden böngésző ugyanúgy működik" elvet sértjük meg, vagy a 100% visszafelé kompatibilitást. Persze felmerül a kérdés, hogy ha nem volt egyértelmű valami, akkor miért csináltak hozzá "éles" (nem alfa, nem béta) implementációt ahelyett, hogy bug reportot küldtek volna a spec fejlesztőinek.

    Nem az a kérdés, hogy tudják -e követni ha akarják (mert ha akarnák, akkor egy tök ad-hoc módon, felülről inkompatibilisen változó specifikációt is tudnának követni)


    A böngésző-implementációk valószínűleg tudnák követni. A weboldalak már sokkal kevésbé, mert a weboldalak nagy részét nem akarják hetente átírkálni ad-hoc változások miatt. Szóval a felülről kompatibilitás csak fontos dolog lenne.

    A válasz persze az, hogy így csak még szélesebb spektrumon fognak elhelyezkedni utóbbiak, illetve, hogy még nehezebb lesz megállapítani vagy egyáltalán csak számon tartani is, hogy melyik böngésző éppen mit és hogyan is támogat.


    Belátom, ebben igazad van. Már most is más-más részeket implementálnak a böngészők, nem ártana hagyni egy kis időt, hogy utolérjék egymást. A spec gyors bővítése itt tényleg csak rontja a helyzetet. Szerintem egy lassú tempójú, meggondolt bővítés azért még beleférne egy "élő szabványba", de a WHATWG valószínű nem ezt fogja akarni.

    Mindebbe ráadásul még nincs is beleszámolva, hogy esetleg a W3C a WHATWG által kidolgozottól eltérő módon rögzít majd bizonyos dolgokat a specifikációiban - mert ha ezt teszi, az még egyszer négyzetre vagy köbre emel majd minden fent felsorolt problémát.


    Teljesen egyetértek. Az ideális eset az lenne, ha a W3C a bugfixeket átvenné, az új feature-ök nélkül. A végére akár a W3C változat lehetne az "alapszint", a WHATWG-s pedig a "bleeding edge" változat. Hogy a valóságban mi lesz belőle, majd meglátjuk.

    Ki kényszeríti - saját magukon kívül - a böngészőgyártókat arra, hogy "ad-hoc implementáljanak, egymással garantáltan inkompatibilis módon" dolgokat?


    Hát ha nincs egy közös spec, amit kövessenek, akkor ki/mi fogja összehangolni őket? Valamilyen koordinációra szükség van, hogy az azonos (vagy legalább is hasonló) feature-öknek az API-ja azonos legyen. Ha jól értem, pont erre lenne jó a HTML élő szabvány, hogy egységes specifikációt adjon azoknak, akik valami újat szeretnének implementálni.

    a Google és a Mozilla) generálják ezt a problémát azzal, hogy ahelyett, hogy bevárnák az új specifikációk szabványosítását és közös elfogadását (ahogy pl. a MS és részben az Opera is teszi), saját szakállra elkezdik berakni őket a böngészőikbe.


    Az a baj, hogyha nem próbálja senki implementálni az új dolgokat, akkor nem fog kibukni, hogy ellentmondás vagy kétértelműség van a specifikációban. Az sajnos nem megy, hogy valaki megírja a tuti szabványt, és utána ráérünk majd implementálni. Az más kérdés, hogy sajnos nem mindenkiben tudatosul, hogy a draft/experimental dolgokra nem szabad komolyan építeni, mert még változhatnak.

    Na mindegy, én bízom a legjobbakban, de simán lehet, hogy nem lesz igazam.
    Mutasd a teljes hozzászólást!
  • Az Ian Hickson-féle e-mailben, amit a cikkbe is belinkeltél, arról van szó, hogy folyamatosan javítják a bugokat, illetve szükség szerint új feature-öket vezetnek be. Nincs szó arról, hogy a meglevő dolgokat visszafelé nem kompatibilis módon átirkálják, hibajavításon felül.

    Ez semmit nem változtat azon, hogy a folyamatos módosítás teljesen ellentétes a "szabvány" fogalmával és céljával, illetve, hogy egy folyamatosan változó specifikációhoz nem lehet illeszkedni.

    Egyébként meg onnantól, hogy egyetlen korábban nem pontosan tisztázott részt tovább pontosítanak vagy egy ellentmondást feloldanak (amiket már egy azt esetleg implementáló böngésző saját hatáskörben valahogy megoldott ill. feloldott) már nem garantálható a 100%-os visszafelé kompatibilitás. Pontosan ilyen súlyú inkompatibilitások voltak azok anno is, amik a problémát jelentették - nem pedig nyílt és durva szakítások a korábbi hagyományokkal.

    Szóval amíg a specifikáció "szelleme" megmarad, az implementációk tudják követni, még ha a betűje időnként változik is.

    Nem az a kérdés, hogy tudják -e követni ha akarják (mert ha akarnák, akkor egy tök ad-hoc módon, felülről inkompatibilisen változó specifikációt is tudnának követni), hanem az, hogy ennek a folyamatosan követésnek egyrészt van -e értelme (a periódikus, több évente történő frissítéshez képest), illetve, hogy ettől most akkor közelebb vagy távolabb kerülnek -e egymástól a böngészők. A válasz persze az, hogy így csak még szélesebb spektrumon fognak elhelyezkedni utóbbiak, illetve, hogy még nehezebb lesz megállapítani vagy egyáltalán csak számon tartani is, hogy melyik böngésző éppen mit és hogyan is támogat.

    Mindebbe ráadásul még nincs is beleszámolva, hogy esetleg a W3C a WHATWG által kidolgozottól eltérő módon rögzít majd bizonyos dolgokat a specifikációiban - mert ha ezt teszi, az még egyszer négyzetre vagy köbre emel majd minden fent felsorolt problémát.

    Új dolgok bevezetésére mindig van igény

    Új, szabványos, minden böngészőben azonos módon működő fejlesztések bevezetésére van igény. Ég és föld a kettő.

    egy statikus spec csak annyit érne el, hogy az újdonságokat mindenki ad-hoc módon implementálná, egymással garantáltan inkompatibilis módon.

    Miért? Ki kényszeríti - saját magukon kívül - a böngészőgyártókat arra, hogy "ad-hoc implementáljanak, egymással garantáltan inkompatibilis módon" dolgokat? A válasz persze az, hogy senki. Ők maguk (mármint elsődlegesen a Google és a Mozilla) generálják ezt a problémát azzal, hogy ahelyett, hogy bevárnák az új specifikációk szabványosítását és közös elfogadását (ahogy pl. a MS és részben az Opera is teszi), saját szakállra elkezdik berakni őket a böngészőikbe.

    Nem azért, mert tényleg igény lenne rá a fejlesztők vagy a felhasználók részéről, vagy mert ez így hosszútávon jó lenne a webnek - hanem csakis azért, mert ezzel tudnak (vagy gondolják, hogy tudnak) rövid távon marketing-tőkét kovácsolni maguknak. De ugye a Mozilla ill. a Firefox példája mutatja, hogy a dolog nagyon nem úgy működik a valóságban ahogy képzelik, illetve, hogy visszaüt, miután egyre több fejlesztő és felhasználó érzi a saját bőrén, hogy ennek így semmi értelme.

    Szóval szerintem nem az mindenki érdeke, hogy minden pontosan ugyanúgy menjen mindenhol (hiszen ezt elérhetnénk úgy is, hogy mindenki visszavált az IE6-ra), hanem hogy legyen egy közös részhalmaz, ami mindenhol ugyanúgy megy, és az idő előrehaladtával folyamatosan bővül.

    De az idő előrehaladtával a jelenlegi modellben nem az a halmaz fog bővülni, amit mindenki tud, hanem az, amiből összeválogathatja majd mindenki, hogy mit tud, minek a lefejlesztésére, követésére, stb. van ideje és pénze. Ez pedig pont azt jelenti, hogy az idő előrehaladtával arányaiban egyre kisebb lesz az rész az egészhez képest, amit mindenki ugyanúgy tud majd.
    Mutasd a teljes hozzászólást!
  • A folyamatosan változó specifikáció (amit még annyira se lehet szabványnak nevezni, mint amúgy, hiszen a szabvány lényege pontosan az, hogy fix és állandó)


    Az Ian Hickson-féle e-mailben, amit a cikkbe is belinkeltél, arról van szó, hogy folyamatosan javítják a bugokat, illetve szükség szerint új feature-öket vezetnek be. Nincs szó arról, hogy a meglevő dolgokat visszafelé nem kompatibilis módon átirkálják, hibajavításon felül. Szóval amíg a specifikáció "szelleme" megmarad, az implementációk tudják követni, még ha a betűje időnként változik is. Persze a régebbi böngészőkben nem lesznek meg az újabb feature-ök, de ez eddig is így volt.

    Nyilván ha megfelelő mértékű rosszindulatot feltételezünk a WHATWG lépései mögött, akkor lehet, hogy direkt packázni fognak a Microsofttal vagy egyéb "külsős" piaci szereplővel, de eddig tudtommal ennek nem adták jelét. (De nyugodtan javíts ki, ha tévedek, csak felületesen szoktam olvasni az idevágó híreket.)

    Ugyanakkor rajtuk kívül ez senki másnak nem érdeke - sem a fejlesztőknek, sem a felhasználóknak. Nekik az lenne a fontos, hogy minden az összes böngészőben ugyanúgy menjen - de ez a dolog nem ebbe az irányba mutat.


    Hát nyilván elméleti esély lenne rá, hogy akkor most mindenki abbahagyja az innovációt, szépen leimplementálja a W3C-s HTML5-öt ától cettig, örülünk, hogy minden ugyanúgy megy minden böngészőben, aztán elkezdik szabványosítani a HTML6-ot. Csak ugye a gyakorlatban ez nem így megy. Új dolgok bevezetésére mindig van igény, egy statikus spec csak annyit érne el, hogy az újdonságokat mindenki ad-hoc módon implementálná, egymással garantáltan inkompatibilis módon.

    Szóval szerintem nem az mindenki érdeke, hogy minden pontosan ugyanúgy menjen mindenhol (hiszen ezt elérhetnénk úgy is, hogy mindenki visszavált az IE6-ra), hanem hogy legyen egy közös részhalmaz, ami mindenhol ugyanúgy megy, és az idő előrehaladtával folyamatosan bővül. Mindeközben az "úttörők" (mind bögésző-fejlesztői, mind webfejlesztői oldalról) szépen kikalapálják a problémákat az új feature-ökből, amik végül stabillá válnak és bekerülnek a közös halmazba. Lehet, hogy idealista vagy naiv vagyok, de szerintem ilyen alapon működne a folyamatos fejlődés kőbe vésett szabványok nélkül is. Persze nyilván ehhez kell annyi közös jóindulat, hogy egyrészt mindenki akarja követni a közös "élő szabványt", másrészt a szabvány készítői ne kivételezzenek egyes implementációkkal mások rovására.
    Mutasd a teljes hozzászólást!
  • Egyet kell értenem Stinggel, a Microsoft fejlesztési modelljébe nem illik egy gyorsan változó szabvány. Nem valószínű, hogy ők a WHATWG mellé állnának...
    Mutasd a teljes hozzászólást!
  • Én személyesen annak is drukkolok, hogy az MS inkább a WHATWG verzió mellé álljon, mint a W3C verzió mellé, hiszen a többi "nagy" már ott van, és így fent lehetne tartani (illetve javítani lehetne) a böngészők közti kompatibilitást.

    Ez szerintem teljesen kizárt. A folyamatosan változó specifikáció (amit még annyira se lehet szabványnak nevezni, mint amúgy, hiszen a szabvány lényege pontosan az, hogy fix és állandó) fenntartásában egyedül a Google és a Mozilla érdekelt, mert ez biztosítja számukra az állandó jelenlétet a sajtóban és a felhasználók fejében, ill. annak látszatát, hogy úgymond a konkurencia előtt járnak. Ugyanakkor rajtuk kívül ez senki másnak nem érdeke - sem a fejlesztőknek, sem a felhasználóknak. Nekik az lenne a fontos, hogy minden az összes böngészőben ugyanúgy menjen - de ez a dolog nem ebbe az irányba mutat.

    A dolog a Google részéről - aki teljesen nyilvánvalóan az egész mögött áll - egy óriási stratégiai baklövés, és csak a natív alkalmazások - és végső soron a Microsoft - malmára hajtja vele a vizet. Bár az Apple is tapsikolhat, mert minden ami a webnek rossz az neki jó, mert azt jelenti, hogy eggyel kevesebb oka lesz a felhasználóinak megpróbálni átmászni a zárt kertje falán.
    Mutasd a teljes hozzászólást!
  • Túl optimista vagy, én ezek után azt várom, hogy az MS majd előáll szépen a saját verziójával...
    Mutasd a teljes hozzászólást!
  • Majd szépen továbbra is lehet táblázatokat böngészni, hogy melyik funkció milyen böngészők alatt, hogyan működik. Aztán gyakorlatilag úgyis kialakul egy olyan halmaz amit mindenki tud aki számít. A cégek meg szépen belövik, hogy melyik platformra is szeretnének fejleszteni, és ehhez képest alkalmaznak majd újdonságokat. A jQuery pont ebben is jó, hogy egységes felületet biztosít a program számára.
    A népszerű funkciókat, úgyis minden böngészőgyártó igyekszik majd implementálni. Sajnálom, hogy ilyen nehéz egységes rendszert kialakítani.
    Mutasd a teljes hozzászólást!
  • Pontosan. Viszont ha megspórol nekem több órányi guglizást, szentségelést, és - akár - több száz sornyi töltelék (értsd: nem business logic) kód írást, tesztelést, na akkor cupp cupp.
    Mutasd a teljes hozzászólást!
  • Újfent beigazolódik a régi bölcsesség miszerint fekáliából nem lehet várat építeni. A javascript alapú keretrendszerek alatt készített kódok jelenleg is úgy hullanak szét az újabb böngésző verziók megjelenésével mint a 40-éves lada a Dakar rally-n.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd