Mennyire fontos az érvényes HTML kód?
Cece már blogmarkolta a forrást, de pár gondolatot hozzátennék a cikkhez. Jeff Atwood HTML Validation: Does It Matter? posztjában azt boncolgatja, vajon az érvényes HTML kód valóban annyira fontos-e, amekkora jelentősséget a webfejlesztők tulajdonítanak neki. Írásában találomra tizenhat népszerű honlapot is megvizsgált, amelyek közül három nem tartalmazott kódhibát. Az a három site valóban jobb minőségű volna a többinél, csak mert valid a HTML forrása?
Pro és kontra lehet érveket felhozni a témához, annyi azonban biztos, hogy érdemes egyszer átgondolni, valóban ér-e annyival többet a valid kód (és hozzá színben passzoló plecsni), amennyi erőfeszítést ennek érdekében teszünk. A W3C HTML validátora (a többi hasonszőrű eszközzel egyetemben) egy mezei gép, amely a belétáplált szabályok alapján mond egy kétpólusú ítéletet: átmentünk vagy megbuktunk. Érdekessége, hogy önmagában egyik sem jelent semmit sem, valid HTML kód is lehet „táblázatos” vagy akár
A napokban foglalkoztam mélyebben a Dojo Toolkit JavaScript keretrendszerrel, ahol a Jeff cikkében felvetett témát kénytelen-kelletlen nekem is át kellett jobban gondolnom. T.i. a Dojo azt a filozófiát követi, hogy egy képet a HTML forrásban úgy jelölhetünk Lightbox komponensek, ha a
Persze, kérdezhetnénk, miért jó a Dojónak, hogy használatához nem szabványos markup elemeket kell használni, de másik oldalról megközelítve, vajon mennyivel jobb, mennyivel diszkrétebb az a gyakorlat, amikor speciális CSS osztályneveket parse-olunk onload esetén a megfelelő elemek begyűjtesére ahelyett, hogy a markupban jelőlnék meg egyből azt, amit szeretnénk (és ezzel a szemántikából sem vesztünk semmit). A néhány
A HTML kód érvényessége fontos, én (is) így gondolom. A validátor robotizált eszköz annak felderítésére, vannak-e esetleg elgépeléseink vagy súlyosabb kódhibáink, amelyek a későbbiekben sok fejfájást okozhatnak, ha egyszer csak azon kapjuk magunkat, hogy egy felsőbb réteg (megjelenés, viselkedés) nem úgy jutott érvényre, ahogy azt mi szeretnénk. Hogy ne menjünk messzire, valid HTML kód a feltétele a mikroformátumoknak is, tehát vannak olyan területek, ahol az érvényesség kiemelten fontos. A kérdés tehát újfent az, hogy érdemes-e (vagy ha igen, mikor) olyan nagy hangsúlyt az érvényességre fektetni, aminek eredményeképpen más érdemi fejlesztésektől vehetjük el az időt. Végezetül egy kérdés: közületek hányan nézték már meg, hogy a Weblabor főoldalán van-e HTML kódhiba?
■ Pro és kontra lehet érveket felhozni a témához, annyi azonban biztos, hogy érdemes egyszer átgondolni, valóban ér-e annyival többet a valid kód (és hozzá színben passzoló plecsni), amennyi erőfeszítést ennek érdekében teszünk. A W3C HTML validátora (a többi hasonszőrű eszközzel egyetemben) egy mezei gép, amely a belétáplált szabályok alapján mond egy kétpólusú ítéletet: átmentünk vagy megbuktunk. Érdekessége, hogy önmagában egyik sem jelent semmit sem, valid HTML kód is lehet „táblázatos” vagy akár
<font>
taggel és inline JavaScript teli – arra pedig általában nem szoktunk korszerű módszerként tekinteni.A napokban foglalkoztam mélyebben a Dojo Toolkit JavaScript keretrendszerrel, ahol a Jeff cikkében felvetett témát kénytelen-kelletlen nekem is át kellett jobban gondolnom. T.i. a Dojo azt a filozófiát követi, hogy egy képet a HTML forrásban úgy jelölhetünk Lightbox komponensek, ha a
dojoType="dojox.image.Lightbox"
attribútumot megadjuk a szülő linknek. A dojoType
pedig nem érvényés attribútum, a validátor lelkesen mutogat is rá. Mellesleg pedig nem kéne. Az ajánlás szerint egy kliensnek az általa nem ismert HTML paramétert illik figyelmen kívül hagyni, ha máshogy nem.If a user agent encounters an attribute it does not recognize, it should ignore the entire attribute specification (i.e., the attribute and its value). (HTML 4.01 Specification, B.1 Notes on invalid documents)
Persze, kérdezhetnénk, miért jó a Dojónak, hogy használatához nem szabványos markup elemeket kell használni, de másik oldalról megközelítve, vajon mennyivel jobb, mennyivel diszkrétebb az a gyakorlat, amikor speciális CSS osztályneveket parse-olunk onload esetén a megfelelő elemek begyűjtesére ahelyett, hogy a markupban jelőlnék meg egyből azt, amit szeretnénk (és ezzel a szemántikából sem vesztünk semmit). A néhány
dojoType
miatt invalid kód tényleg invalid? Vagy mondhatjuk azt, hogy nem annyira invalid? A validátor mindenesetre beállítja a piros favikont.A HTML kód érvényessége fontos, én (is) így gondolom. A validátor robotizált eszköz annak felderítésére, vannak-e esetleg elgépeléseink vagy súlyosabb kódhibáink, amelyek a későbbiekben sok fejfájást okozhatnak, ha egyszer csak azon kapjuk magunkat, hogy egy felsőbb réteg (megjelenés, viselkedés) nem úgy jutott érvényre, ahogy azt mi szeretnénk. Hogy ne menjünk messzire, valid HTML kód a feltétele a mikroformátumoknak is, tehát vannak olyan területek, ahol az érvényesség kiemelten fontos. A kérdés tehát újfent az, hogy érdemes-e (vagy ha igen, mikor) olyan nagy hangsúlyt az érvényességre fektetni, aminek eredményeképpen más érdemi fejlesztésektől vehetjük el az időt. Végezetül egy kérdés: közületek hányan nézték már meg, hogy a Weblabor főoldalán van-e HTML kódhiba?
Érdekes gondolatok...
Mellette:
-Ki honnan jött. Mint ahogy az angol cikk is leírja, az (X)HTML kód érvényesítése mazochistáknak, vagy (és :-)) programozóknak való. Én például anno Delphi -ből nyergeltem át a webes dolgokra, és megnyugtat a tudat, hogy amit csinálok, követ egy bizonyos szabályt-szabványt.
-Kereső robotok. Nem néztem utána a témának konkrétan, de mintha úgy rémlene, hogy valid markup-ban könnyebben elboldogulnak, és így oldalunk előbbre kerül. Ez egyébként a hozzászólásokban is tükröződik.
-Remény. Egyszer hátha eljutunk oda, hogy egy szabványosított kód minden böngészőn egyazon módon fog viselkedni.
Ellene:
-Eszköztár. Lehet olyan megoldás, ami valid eszközökkel nem elérhető. Egy profi hozzáértő, aki igen jól ismeri az adott lehetőségeket, dönthet olyan nem valid megoldás mellett, ami az adott feladat megoldásához (szerinte) jobban illik.
-Lustaság. (Jó, hívjátok produktívabb munkavégzésnek :-)) Nyilván gyorsabban haladok ha nem kell folyton a hibáimat javítgatnom.
Jómagam ha lehet a "validáljunk" táborba sorolom magam. Nem tudom belátni, hogy az adott szabványos eszközökkel miért ne lehetne ugyanolyan jó design-t készíteni. Nem azt mondom hogy ugyanolyat, hanem hogy ugyanolyan jót. Hasonlóan egy ceruzarajz is lehet szebb mint egy olajfestmény (nekem) persze mindig lesznek (mások) akiknek az olajfestmény tetszik jobban. Nyilván van egy elfogadott átlag, amire azt mondjuk, hogy hmm, ez szép kis alkotás, de nem a használt technika fogja meghatározni, hogy miért tetszik, hanem valami, a felhasználó-barátságon, graceful degradation-on, gyorsaságon, RIA -normákon túl, ami miatt összeáll az egész, validitástól vagy invaliditástól függetlenül.
Tehát ennek fényében szerintem legyen valid. :-)
Észrevételek
Szerintem a plecsninek annyiban van értelme, hogy felhívja az user (fejlesztő) figyelmét a web szabványok fontosságára, én ezt tartom jónak benne; mivel teljesen opcionális a felvétele az oldaladra, még csak amolyan jutalomnak sem kell felfogni, inkább másoknak szól, mint neked, inkább amolyan felhívás, semmint hivalkodás. Persze ezzel is "vissza lehet élni" :)
Úgy tűnik, hogy még sokáig nem fog lezárulni a web szabványok körüli vita: kell-e, jó-e, érdemes-e. Mert szerintem ez a kérdés, nem a plecsni :)
Én (is) úgy látom, ezeknek a szabványoknak a követése nem öncélú; mind a fejlesztők, mind a böngészőgyártók részéről erőteljes támogatást lehet tapasztalni ebben az irányban, sőt, afféle verseny is kialakult már: ki teljesít jobban, az Opera vagy az IE8 stb. Ugyanakkor az is igaz, hogy a visszafelé kompatibilitás és robusztusság a böngészők esetében alapkövetelmény, nem engedhetik meg, hogy mondjuk leálljon egy oldal renderelése, mert valaki nem zár le egy taget stb. Ezzel is vissza lehet élni.
Ámde nem értem, hogyan van az, hogy amíg egy compiler vagy interpreter nem ordít rá az emberre, addig minden további nélkül mellőzik a szabályokat; ezek attól még szabályok, amiket be kell tartani.
A validátor abban segít szerintem is, hogy a fejlesztő által esetleg elnézett dolgokat megmutassa (ehhez egyébként nem kell a webre csatlakozni, van egy csomó offline validátor, ami konzolba vagy más kimenetre tud reportolni). De nem csak ezt, hiszen például rengeteg jó helpet ad a hiba kijavítására, hivatkozásokat nyújt a továbblépéshez. Géphez képest szerintem jópofa :)
Ezzel az a gond, hogy a dojotype attribútum valid, csak éppen nem úgy, ahogy használják :) Úgy értem, ehhez moduláris xhtml kell, ahol saját tageket, attribútumokat definiálhatsz - ehhez persze az kell, hogy a fejlesztők erre hajlandók legyenek :) Mezei webfejlesztő nem ír DTD-t (én sem), de a dojo logikája egyelőre csak ebben az irányban képzelhető el.
Zárójelben: ilyen értelemben az xhtml elnevezés félrevezető, mert kiterjeszteni a htmlt nem nagyon van módod, hacsak nem a modulok irányában :)
A moduláris kiterjesztés azért is jó (lenne), mert az oldalon futó szkriptek számára elméletileg a DOM ad interfészt, tehát az új attribútumokkal ez pont jól megvalósítható lenne; a CSS classok meg tök másra valók, legalábbis a web szabványok szerint...
Összegezve, szerintem van itt egy döntési helyzet, mégpedig az, hogy követem-e a web szabványokat, vagy sem.
Na még csak egy dolgot :)
Nekem eddig az összehordott html/css/js szemét takarítása, foltozása mindig több időmbe került, extra munkát adott, mint a valid kód megírása. Minden valószínűség szerint hiányzik a skill szintű kódírás ezen a téren (magamt sem kivéve innen), nagyon nagy szerepe lenne itt az oktatásnak...
szabvány=szabályok (következetes) betartása
A példát nem feltétlen a programozás világából hozom, talán mert nem értek annyira hozzá, de szvsz ez is példázza, hogy mennyire fontos(nak kellene lenni) az élet bármely területén:
Senki nem állíthatja, hogy egy régebbi Jaguar (autó márka) azért sz@r mert mondjuk a gyertyát nem balra tekerve kell kivennünk ha cserélni akarjuk. Viszont minden autószerelő megörült neki mikor (miután a Ford átvette) a Jaguarok is követték a "szabványt", így rutinból elháríthatták a hibákat, illetve nem azon kellet kalóriát égetni, hogy most jobb/bal menetes-e, vagy éppen konvertálja a collt milliméterbe a szerszámok végett. Milyen nagyszerű érzés, hogy ránézünk egy hatos anyára és tudjuk, ehhez egy 10-es kulcs kell és nem kell "felpróbálni" három méretű villáskulcsot.
Bocs a kitérőért, de a szabványosság az egyik legfontosabb dolog, még ha alapkövetelmény is ebben az amúgy "határtalan" világban. Senki nem garantálhatja, hogy egy elkészített kódhoz csak és kizárólag a megalkotója nyúlhat hozzá, mondjuk pár év múlva. Az internet és egyik táptalaja a web pedig feltétlen kell, hogy ragaszkodjon valamilyen szabály rendszerhez. Laikusként gondolom, hogy ezért fejlesztették tovább a HTML-t 1995-ben és gyanítom nem lesz megállás. Ennek a multikulturális közösségnek ez, mármint a szabványok betartása garantálhatja, hogy "egy nyelvet" beszélve fejlesztenek és fejlődnek egyszerre. Szerintem ha kellő energiát fektetnénk abba, hogy bebizonyítsuk egy-egy invalid kód miért is rossz - valószínű lenne egy-két érv -, akkor ugyanezt fordítva, mármint a valid kód hibáit keresve nem jutnánk egyről a kettőre.
Összegezve véleményem, nem lehet kérdés a fontosság. A poszt indító cikk inkább filozófikus miértek keresése, hogy a jó az miért is jó?
Abban is biztos vagyok, hogy idővel meg fogják oldani, hogy egy Dojo Toolkit is szabványos legyen ha fenn akar maradni hosszútávon. Ettől még lehet remek eszköz (mintahogyan egy 82-es Jaguar is remekmű) és lehet pont ezzel szolgálja a fejlődést, hogy kihívásokat támaszt, ha nem is tudatosan.
És igen lelkes amatőrként eleinte mindig klikkeltem a sárga 3szögre, hogy pont itt?! De miután mindig meggyőződtem róla, hogy a figyelmeztetések (és nem hibák) olyan apróságok miatt vannak, amik csak abból adódnak mert éppen nem volt rá több idő (a szabadidőből) így ezeket el fogadtam és természetesnek veszem.
Még annyit, hogy szvsz ehhez nem kell akkora erőfeszítés. Ha nekem is megy könnyedén, akkor egy profi (akinek ez a kenyere) ezt észre sem veszi. Persze ha így tanulta meg annak idején. Erre szokás mondani: "A rest meg a hülye mindig kétszer fárad"
A Dojo szabványos
szerintem egyértelműen szabálytalan
Kicsit sok a szóismétlés de most nem tudtam jobban kifejteni.
ezt így nem értem sajnos
Egyetértek
ne már
lustaság
Igen
Igen, az általad idézetteket már olvastam, amikor a Dojot néztem és szerintem alá is támasztottad vele azt, amit mondtam. Több kód? Megnőtt a méret? Hány bájttal? Összetettebb? Be kell másolni a DTD-t? Összezavarodtak a fejlesztők? Ha ennyire nem értenek hozzá, akkor mit akarnak ők Dojozni? De nem baj, mert úgyse akarnak az emberek validálni! Hát ez mi, ha nem az egyszerűbb út követése?
önbizalom az van
Plusz még ajánom neked, hogy olvasd el mondjuk a DOM leírását a W3C-nél, majd állj neki implementálni egy böngészőt ez alapján, és akkor rá fogsz jönni, hogy a szabvány mennyi nyitott kérdést is tud hagyni.
Bocs
Az én olvasatomban a fejlesztők alatt ez esetben a felhasználókat kell érteni. De ha nem, akkor bizony régen rossz, ha a saját DTD (tehát az, hogy lehet validálni az önkényes HTML attribútumaikat) összezavarja ennek a fullos JS frameworknek a főműsoridős fejlesztőit. De én remélem, hogy jól értelmeztem azt a „developers”-t.
Én a saját munkám a legjobb tudásom szerint végzem, remélem nem kell senkitől bocsánatot kérjek ezért, se azért, mert elvárnám mástól is, hogy erre törekedjék.
Ezért nem.
Sok a betű, kevés a szalonna
Maradjunk a betűknél
Csupán kiegészítések
A W3C álláspontja eléggé egyértelmű, az első kommentemben ezt emeltem ki, vagyis hogy ilyen esetekben használjunk moduláris xhtmlt.
Szerintem egyébként ez nem triviális, ha nem nagy cég vagy, hanem kis/közepes számos ügyféllel, akiknek szerteágazó igényeik vannak.
Vannak aztán olyan esetek is, amikor egyszerűen nincs mit tenni, kénytelen vagy beletörődni abba, hogy a termék nem lesz valid: így pl. különböző weboldalak mixelése (white labelek, affiliate oldalak), amikor extrém mennyiségű kompromisszumot kell kötni minden téren.
Miért nem?
IE
IE?
Kár a flame
* mindegy mennyit.
Nincs ellene vagy mellette
A kérdés, hogy a szabályok jók-e?
Egyértelmű, hogy egyes szabályok nem jók, és ebből ered a konfliktus. Azért nem jók egyes szabályok, mert a szabályalkotók is emberek és hibáznak. Ezeket a hibákat ki kell javítani.
...és miért szigorítanak feleslegesen egyes szabályokon, amik régebben elfogadottak voltak?
- A böngészőmotoroknak segítenek vele, nem a fejlesztőknek (hibás elgondolás)
- Úgy gondolják, hogy jobban tudják, hogy mi jó a felhasználóknak, mint a fejlesztők (hibás elgondolás) (pl. target blank, alt attrib)
- Rá akarják erőltetni a fejlesztőkre olyan paradigmákat, amiket jobb lenne, ha a fejesztők maguk döntenék el, hogy érdemes-e az adott helyzetben alkalmazni (pl. stílusdefiniálás)
Jó a validálás, de nem kéne engedni hogy rossz irányba menjen: a validálás a fejlesztőkért legyen és ne másért és ne fordítva.
Nem kérdés tárgya
Azt a kaotikus borzalmat, amiben ma dolgozni vagyunk kénytelenek, csak magunknak, a lustaságnak és gyávaságnak köszönhetjük, egyaránt a böngészőgyártóknak és webfejlesztőknek. A szabványok célja a kiszámíthatóság és éppen ez az, ami a webről a fentiek miatt hiányzik, ennek tudatában pedig egyenesen vérnyomásemelő a tudat, hogy máig mennyien vannak, akik nemhogy pusztán nem követik a gondolatot, de mi több, meg is kérdőjelezik, vagy éppenséggel ellene agitálnak!
Furcsának tartom a cikk által állítottat, miszerint túl sokat foglalkoznánk ma az érvényességgel: ha így lenne, akkor a bemutatott felmérés nem ilyen eredményt hozott volna; foglalkozni az érvényességgel nem abból áll, hogy minden kódolási alkalomkor eszembe jut, és megmagyarázom magamnak, hogy most épp miért nem foglalkozom vele.
Részemről az első dolog, amit egy oldalon megnézek, az az, valid-e a forrása, mert ebből egyből kapok egy képet a fejlesztőjéről. Igen, lehet, hogy ettől még pl. táblázatokkal van felépítve, de a szemantika sokkal bonyolultabb és összetettebb kérdés, mint ez; a validitás az elvárható minimum, melynek megfelelni oly kevés erőfeszítést igényel, hogy már lustaságnak sem nevezhetem, ha valaki nem teszi: ez már hanyagság.
Ha valaki nem ismerné, Firefox kiterjesztés is létezik a dologhoz, nem kell folyton hívogatni a validátort: elég minden változtatáskor ránézni az állapotsorra, és ha valamit elírtunk (mert az érvényes kód gyakorlatilag semmilyen korlátot nem jelent fejlesztéskor, és idővel készség szintűvé válik írása), akkor rögtön javíthatjuk.
szellemiség
Szerintem a lényeg az, hogy tisztában legyél azzal, hogy az adott szabvány mit képvisel, mi a szellemisége, ismerd annyira, hogy tudd fromálni is akár, ha egy magasabb jó miatt ez tűnik célszerűnek. A szabány legyen érted, ne te a szabványért. Szvsz vakon követni szabályokat sokkal veszélyesebb.
Azt is be kéne látni, hogy az hogy az oldal valid, az önmagában kb. semmit sem ér (erre vonatkozik szvsz a túllihegés), egy tök valid oldal is lehet tök rosszul felépített, míg a szemantika jegyében jól felépített oldal egy plusz attributummal sokkal értékesebb lesz.
Programozásban mindig adódnak olyan helyzetek, hogy egy általában kerülendő megoldással többet nyer az ember annál, mintha csak követné bután a Szabályt.
...ha a szabvány és mi is fejlődünk az a jó :)
A szabvány szerintem elsősorban garancia és egy közös nyelv, ne higgyük, hogy ez állandó és kőbe vésett, de legyünk tisztelettel iránta - talán ezt nevezik szakmai alázatnak. :)
Lépésenként
Természetesen mindig gondolkodni kell új megoldásokon, de a szabvány az azért szabvány, hogy betűre betartsuk. Ha rossz, akkor kell csinálni egy újat és implementálni kell – valahogy ez a része már nem megy annyira…
is-is
A plusz attribútum nem szabványos és a szabvány szerint figyelmen kívül hagyandó. Ha egy XML fájl nem felel meg a saját DTD-jének, akkor az nem szabványos. Ezen nem változtat, hogy a szabvány előírja-e, hogy a hiba hogy legyen lekezelve (nyilván a jövőbeli változatokkal való kompatibilitást biztosítandó).
Fogd a vallásra, akkor nem mernek bántani
tgr alant megelőzött: az ismeretlen attribútum nem szabványos, e hibatípus megfelelő kezelése pedig az attribútum figyelmen kívül hagyása. Részletekben az ördög.
Ignoratio elenchi. Mi köze a kettőnek egymáshoz? Attól, hogy betartok minden törvényt, még lehetek rossz ember. Tehát akkor szerinted ne is tartsuk be a törvényeket? A validitás az elvárható minimum.
No offense, de a http://blog.felho.hu főoldalán a lehagyott type attribútum és a 12 lezáratlan p elem milyen szellemiséget képvisel? :) Vagy csak nem foglalkoztál vele, mert így is megeszik a böngészők?
No offense???
Végülis mire volt jó ez a mondat akkor? Inkább írtad meg volna hogy az idézett "Szerintem a lényeg az..." bekezdéssel kapcsolatban mi a véleményed...
Szerintem is a szabványra törekedés az egyik legfontosabb (és minimum) dolog, de 2 dolog mindenképp fontosabb:
1: akik a szabványt alkotják mindenképp a megfelelő céllal tegyék, figyeljenek oda, hogy kikért dolgoznak (nem a userekért és nem a böngészőkért, hanem a fejlesztőkért/fejlesztésért)
2: akik észerevesznek egyes hibákat (stb) a szabályrendendszerben és tehetnek érte, éljenek az eszözeikkel. Le a kalappal a dojosok előtt, hogy felvállaták, hogy nem teljesen szabványosak! Észrevették, hogy a szabály nem jó, sőt észrevették hogy a szabály rendelkezik a "nem szabványos" elemeikkel kapcsolatban így biztosak lehetnek benne, hogy hogyan viselkednek majd a szabványkövető böngészők a megvalósításukkal kapcsolatban.
Ugyeugye? ;-)
Az
"hatásos"
Erről volt szó
kettőnek nincs köze egymáshoz
Plusz amin igazából felhúztam a szemöldököm, az a lustaság/hozzá nem értés kitételed. Kb. semmilyen alapod nincs arra, hogy ilyen szavakat használhass (szerintem!). Dojo akárhogyis nézzük egy elég profi cucc nagyon sok szempontból, Alex Russel már kb. 10 éve is egy egész pofás OS jellegű cuccot fejlesztett JS-ben, Dojo-t is ő állította pályára, Comted/Bayeux is elég erősen kötődik a nevéhez, te mit tettél le ezekhez képest?
Emberi
Mégis mindkét esetben le lett vonva a következtetés: felesleges validnak lenni.
Szeretsz tekintély alapon vitatkozni, de jobb érvekkel, mint személyekkel. Lehet, hogy én azt az időt, amit mások arra fordítanak, hogy nagy dolgokat tegyenek le az asztalra, ilyen valótlan hülyeségekkel töltöm. Lehet, hogy én azt a munkát végzem, aminek csak a hiánya szokott feltűnni.
Egyébként a W3C is tapasztalatlan suhancok gyülekezete, ha ellene vannak az önkényes attribútumoknak?
Annyira emberi… Igen, a magyar utak is így készülnek, a nagy kép a lényeg, nem a kontextusból kiragadott részletek: nem az számít, hogy sokáig tartson, az számít, hogy meglegyen. A nagy képet tartod szem előtt akkor is, mikor kocsiba ülsz tömegközlekedés helyett: a lényeg, hogy ott légy, hogy mi lesz ötven év múlva, az lényegtelen. A Wordpress sablonod készítője is a nagy képet tarthatta szem előtt, mikor nem foglalkozott ilyen kicsinyes dolgokkal, mint pár
p
tag lezárása és valid HTML írása: a nagy kép azt kívánta, hogy meglegyen a sablon, még ha így több száz, több ezer invalid oldallal is gyarapodott a web.Igaz nagyjából semmiféle erőfeszítést nem igényelne adott fejlesztőtől az, ami hosszabb távon egy kiszámítható platformmal, kevésbé idegörlő fejlesztéssel, kisebb és gyorsabb böngészőkkel egy jobb világot eredményezne.
a szabvány fontos
A végkövetkeztetés részemről az, amit már írtam: tudni kell a szabványt a helyén kezelni, és ha adott esetben ez a célravezető, akkor lehet feszegetni a határait.
kontextus
Update: ha már szellemiség, épp most futottam bele a szerveren ebbe: http://felho.hu/regi/zionweb/intranet.html, ezt kb. akkor csináltam, amikor 4./5. osztályba jártál, és kipróbáltam, fut minden, ma a gépemen lévő böngészővel (ezzel együtt nem így csinálnám ma már ;)).
Nihil
Miért, ilyen alapon hol lényeges?
De a te blogod. Ha rossz az eszköz, akkor vagy javítom, vagy másikat választok.
Ez mondjuk inkább a böngészőfejlesztők „érdeme”, de vajon nem futna, ha valid lenne?
Előbb volt a tyúk!
Valaki felhozta példának a delphi-t. Igen, jó példa, gondoljunk csak bele, milyen jó lenne, ha két változónak is adhatnánk értéket egy soron belül (kb.: a := b := 0), megkönnyítené a programozó életét, de nem szabályos, ezért nem működik. Meg kell oldani másképpen, ennyi. Hozzáteszem, régen használtam delphi-t, előfordulhat, hogy változtattak a szabványon, és már remekül működik ez a fícsör is.
A sajnálatos az, hogy a webfejlesztőknek van választásuk a szabvány követése és figyelmen kívül hagyása között. (Ez a vita sem lenne akkor, ha a szabálytalan kódok helyett blank page jelenne meg az összes böngészőben...)
Dojo, HTML 5
Próbálta már valaki?
Pár éve, amikor kijött az XHTML 1.1 én megtettem, mert nem tetszett, hogy kivették a target attribútumot az <a ...>-ból. (Mondjuk ma már értem és elfogadom az indokot, hogy a látogató döntsön, hogy egy linket hova akar megnyitni)
Mindenesetre elkezdtem kutakodni és megtaláltam, hogyan tudnám visszavarázsolni. Minden szép és jó volt, de az örömömet egy idő után felváltotta a felismerés, hogy lehet, hogy a validátor azt mondja rá, hogy übervalid, de biztos megfogalmazódik majd előbb utóbb egyesekben, hogy ugyan mi a bánat az a PUBLIC "-//GIXX//DTD XHTML11-with Target//EN" ??
Merthogy a GIXX az nem W3C, így tulajdonképpen minden valid, amiről én azt mondom. Tehát az oldal így GIXX DTD valid lesz és nem W3C DTD valid. Akkor viszont a "W3C validated!" ikont se rakhatom ki (akkoriban ezt fontosnak tartottam).
Szóval szép és jó lenne, ha a moduloknak lenne valami W3C által validált gyűjtőhelye, és onnan be lehetne építeni őket. Nem tudom, van-e most (már) ilyen?
Mit lehet tenni?
ez jó kérdés
Az, hogy ajánlás valóban nem olyan eget rengető erejű és ráadásul csak a mellébeszélésre ad lehetőséget. Lásd box modell, ami megint csak nézőpont kérdése, hogy kinek van igaza. Vagy ott a másik kedvencem a haslayout.
Egy hozzáértő esetleg tudja, mi a konkrét akadálya, vagy pontosan ki tehetne azért, hogy ez olyasmi erejű legyen mint pl. egy ISO?
Mi a különbség?
A 'legjobb' megoldás?
De hogy az eredeti témánál maradjunk, nemrég néztem meg egy Yahoo előadást, amiben a következőket mondták:
Igen
Az idő előrehaladtával pedig lehetne egyre drasztikusabb megoldásokhoz folyamodni.
Formai megjegyzés
A többi site hatására nem lesz sem jobb, sem rosszabb az a három, gondolom ezt szándékoztad írni:
"Az a három site valóban jobb minőségű volna a többinél, csak mert valid a HTML forrása?"
Javítottam