Názory k článku Ian Hickson o nové verzi HTML
-
Podle mě zpětná kompatibilita je hrob pokroku. V tomto s p. Hicksonem zásadně nesouhlasím. Jakou zpětnou kompatibilitu nabízejí MC a CD? Přehraju snad CD na kazeťáku? Ne, prostě jednoho dne se musely začít vyrábět CD (weby s novým jazykem) a k nim přehrávače (nové internetové prohlížeče).
V nové specifikaci by hlavně mělo být důsledné odmítání chybných zápisů. starat se o dešifrování zápisu < b >nějaká < i >naprostá </ b>blbost</ i> je nesmyslné. Takový zápis je chybný a prohlížeč by měl nahlásit chybu a vůbec se nepokoušet to nějak dešifrovat.
Jenže tohle není možné bez radikálního řezu a naprostého zavržení zpětné kompatibility. Dokud někdo neudělá tlustou čáru a nezačne se nanovo, pořád budeme tahat za sebou kouli na řetězu. Podívejte se na standardy pro video. FullHD 1080i. Kdo mohl takovou pí*ovinu pustit do světa? Prokládaný video na progresivních displayích. Ale nikdo neměl odvahu jít a říct ode dneška má video rozlišení 1920x1080 a 24 nebo 48 fps. Předělejte si laskavě televize, kamery vysílací aparaturu a přizpůsobte se. Jenže pánové nahoře řekli ne, zpětná kompatibilita se sice stejně muesla kvůli rozlišení prolomit, ale tak se aspoň zachovali nesmysly se snímkovou frekvencí - zrychlenej PAL 25p, prokládanej PAL 50i, telecined NTSC 60i. Prostě Ivánku kamaráde, to bys blil. Takže jakmile někde slyším, že chce někdo zachovávat zpětnou kompatibilitu, otevírá se mi kudla v kapse. -
Znáte nějaký způsob, jak přimět tvůrce webových prohlížečů "radikální řez" udělat, aniž by vyvíjeli podruhé skoro totéž (což je drahé a neefektivní, a tedy nereálné) a aniž by prohlížeče přišly o uživatele (to si nemohou si dovolit)? A znáte nějaký způsob, jak předělat fungující (byť z různých pohledů chybné) webové stránky na bezchyné bez vynaložení obrovských nákladů? Pokud ne, pohybujete se v čistě teoretické rovině.
Lidé okolo WHATWG se pohybují v rovině praktické, uvědomují si, co má u výrobců a autorů obsahu šanci a co ne. A v rámci těchto možností jednají. Spekulace typu "jak by co mělo správně být" jsou hezké, ale s webem nijak směrem k lepšímu nepohnou. WHATWG s ním (byť velmi zlehka) hýbe už teď. -
filato (neregistrovaný)Nejsem zástánce toho, aby se udělala tlustá čára.
Ovšem jedno snad elegantní řešení tady je. Zamrazit zoprazovací procesory všech prohlížečů, implementovat jednotý procesor některý výše uvedené vývojové organizace. Není pak problém dle tagu v hlavičce zjistit, jaký procesor se pro zobrazení použije. Samozřejmě, když tam žádná informace nebude, použije se dnešní "zamražený" procesor. Vznikne pak vícero zájmových skupin, které budou vyvíjet další a další značkovací jazyky... A třeba někdy nastane doba, kdy budemene nové parsery zančkovacích jazyku do prohlížečů implementovat jako dnes např. Flash plugin :)) Možná by to nebyla tak špatná budoucnost. :) -
uzivatel (neregistrovaný)"Lidé okolo WHATWG se pohybují v rovině praktické, uvědomují si, co má u výrobců a autorů obsahu šanci a co ne"
Suhlas. A to su presne zaujmove skupiny autorov prehliadacov. Robia si co je pre mich jednoduchsie a nie co bude jednoduchsie pre ludi dajme tomu za 4 roky. Su lenivy implementovat nieco nove a viac prevratnejsie.
A ty si snad myslis, ze CD bolo vyvijane pre nejaku "praktickost" ? Pokial nebolo vydane nikto o nom nevedel. Toto bol taky velky prevrat inzinierov najma teoretickeho odboru, ze prakticki hnidopichovia o nom nemali ani ponatia.
Sam som praktik, ale nepovazujem sa za hnidopicha. Ak by sa tieto dve skuspiny ohladom HTML 5 a XHTML 2 rozumne dohodli mohli by odstranit neduhy oboch jazykov a vymysliet nieco poriadnejsie. Lenze oni si povedali nie, preco by malo odvetvie zastupovane komercnymi spolocnostami sledujucimi zisk na svojej specifikacii pracovat s nezarobkovou organizaciou ? A aj presne naopak. Na oboch stranach je banda tupcov, vdaka ktorym sa WEB mozno rozcleni na dve zlozky.
A vyjadrovanie spoluautora navrhu HTML5 o tom ze treba zachovavat kompatibilitu humusne pisaneho kodu v krizeni tagov tak mi je az na vracanie. Parser pre HTML 4 je davno napisany, preco chcu s nim drzat kompatibilitu ? Nie je nahodou DTD rozhoduje v tom aky parser by sa mal pouzit ? Tak co im brani ich od seba oddelit ? Ospravedlnovat takych co si daju do hlavicky XHTML 1.1 a ich webova stranka ledva zvlada HTML 4 Transitional ? Chapem, ze kopec dobrych kopec dobrych informacii, ktore si velmi vazim pochadzaju z ruk ludi, ktori webstranky pisat nevedia, ale zase nemachruju tym, ze si daju do hlavicky nieco co nie je.
A teraz nezastavam ziadnu skupinu. XHTML by nemalo padat pod striktnost XML, ale urcit si vynimky, co este nie je povazovane za chybu. Toto bola najvacsia chyba W3C, ked nemyslela na tieto kroky.
Zial, vyvoj vsetkeho je v rukach zaujmovych skupin a nepresadi sa to co je naozaj lepsie. A ked oni povedia, ze to nase je lepsie, pretoze je rozsirenejsie je pre 90% ludi pravdou. -
vdaka ktorym sa WEB mozno rozcleni na dve zlozky.
K rozdeleni webu nedojde, bude tu nove (X)HTML5 od W3C. XHTML2 se na web nedostane (W3C ho neplanuje na webu prosazovat a nikdo ho tam implementovat nebude).
Nie je nahodou DTD rozhoduje v tom aky parser by sa malpouzit
Jen to ne. Uz ted mame snad v kazdem prohlizeci 2-3 renderovaci mody, a ty se v kazden prohlizeci chovaji trochu jinak, to mame 2 mody IE, 3 v Mozille; Operu a Safari detailne neznam, ale mely by mit take po dvou (pokud nekdo vite presne, dejte vedet), takze tu dnes mame na webu 9 renderovacich modu, kazdy z nich se chova trochu jinak a zadny v podstate neni vubec zdokumentovan.
Spolehnout se opet na DTD a udelat dalsi skok by znamenalo pridani dalsich renderovacich modo do kazdeho z prohlizecu, takze bychom tu mely 4 nove mody, celkem jiz 13. Nedovedu si predstavit, ze by neco takoveho mohlo vest ke zlepseni situaci na webu.
Snaha WHATWG je presne opacna - sjednoceni a specifikovani namisto mnozeni dalsich nespecifikovanych chovani a tim i problemu s nekompatibilitou mezi prohlizeci. I ve W3C dnes zacina prevazovat nazor smerujici k sjednoceni a heslo Don't Break the Web se dnes dalsi HTML specifikace z W3C neodvazi porusit.
-
karf (neregistrovaný)Rozlišoval bych parsování a renderovací mód, to jsou dvě odlišné věci. Současné režimy zobrazování v prohlížečích se týkají implementace CSS, nikoliv HTML parseru (pokud je mi známo). To, že se módy zobrazení přepínají pomocí DTD je pouze důsledek živelné evoluce prohlížečů v minulosti. Sami autoři "HTML5" počítají s dvěma parsery (HTML a XML), z obou se vytváří jednotný DOM. Různé parsery pro XHTML2 a HTML5 by nebyl asi větší problém, protože XML parser stejně všechny prohlížeče již obsahují. Problém je spíš v jiných částech prohlížečů - DOM, chování prohlížečů, skriptování atd.
-
Současné režimy zobrazování v prohlížečích se týkají implementace CSS, nikoliv HTML parseru
Vse je provazane, renderovaci mod se dnes netyka jen CSS, ale i samotneho HTML nebo JavaScriptu - minimalne v nekterych prohlizecich. Kuprikladu omezena podpora document.all v Mozille funguje pouze v quirk modu.
-
uzivatel (neregistrovaný)A kto za to moze ? DTD je uznavem trochu zlozite, ale bolo velmi nutne z principu tej spätnej kompatibility, aby sa od seba odlisuili urcite verzie HTML. Cize HTML 5 bude dalsi, ktory prileje olej do ohna.
Tym horsie klameme ako krasne rozpravame. Cize Myslienka dobra, ale urcite mi daju niektori ludia za pravdu, ze to co predvadza Ian Hickson su len krasne reci a umenie kydat na druheho. Jeho model ja docasnou zaplatou na 3-4 roky. A zase budeme potrebovat nieco nove. -
anonymníno a proc ne? :) takhle svet funguje
bere se to nejsnadnejsi aktualne prijatelne reseni
pokud skutecne se za 3-4 roky ukaze, ze jsme v koncich a nelze postupovat dale (coz ale nemusi byt pravda a za 3-4 roku mohou existovat zcela jine problemy a pozadavky o kterych ted nemame ani potuchy), tak treba prevezmeme XHTML2 :)) -
uzivatel (neregistrovaný)Takto svet nefunguje, takto ho riadia iba zaujmove skupiny. Rozumej peniaze. Ak by sa na ne tak neprihliadalo tak teraz uz su davno rozsirene ekologicke auta s minimalnym vypudovanim nebezneho vysledku spalovania. Netazili by sa nadmerne lesy, pretoze to je zaklad zivej flory, nezabijala by sa nadmerne zver, atd atd. Clovek by myslel rozumnejsie a viac v sulade s tym odkial pochadza.
Ale toto nikdy nenastane pokial bude clovek rozmyslat len pomocou penazi. A prave tymto jeho zmyslanim je pokrok taky maly. Uz pred 20timi rokmi a mozno aj skor sme mohli mat to co teraz. Ale co sa sledovalo ? Vlastny prospech. To je vsetko.
Cize treba rozmyslat aj vlastnym rozumom a nie tym co ti kto predhodi a ty to automaticky skonzumujes. Nie nedarmo sa tejto dobe a spolocnosti hovori konzumna. Rozum je pre nich na druhom mieste. -
anonymnía nebo taky nejsou vubec zadna masove dostupna auta, ze ? :))
natoz pak pocitace a site...
a nejen clovek :) XHTML2 by melo byt take vic v souladu s HTML, ze ktereho pochazi :))
pred 20 a vice lety? v pred rokem 87? a tim 'my' myslite koho? ten nas socialisticky tabor miru? nebo tam na kapitalistickem zapade? tam se preci nepremyslelo pouze penezi, ne?
pokud mate nejakou vlasni ideologii a predstavu ekonomickeho systemu, ktery je schopen se nenasilne udrzet a byt relativne stabilni, je alespon rozumne efektivni, a hlavne nezhrouti se pri aplikaci na velmi velkou skupinu, kde se lide navzajem vetsinou neznaji, sem s ni (tedy sem ne, tady je to OT radeji o tom napiste nejaky clanek nekam jinam a dejte odkaz) a muzeme se o tom bavit (ale pokud to neni ve stylu - lide by meli byt na sebe hodni a nezistne si navzajem pomahat)
no hlavne ze jenom pro ne a ne pro vas :) -
uzivatel (neregistrovaný)Nie. Rozmyslam z hladiska vacsieho ako si vy viete pripustit. Preco hned hovorite o komunizme ? O tom nebola rec. Bavme sa v normalnej urovni, ak na to nemate tak je zbytocne pokracovat.
Je velmi technologii vymyslenych, ktore by dokazali odbremenit zivotne prostredie a ktore vyzaduju minimalne naroky na spotrebu. Ale co by bolo z toho keby ich vydali ? Vyrobcovia elektriny a tazobne ropne spolocnosti by dokazali potopit.
Svet riadia peniaze a nie zdravy rozum. Spolocnost je prehnita a kazi vsetkeho coha sa dotkne. Bud som este dost mlady a nedotkla sa ma alebo mam dostatocny obranny mechanizmus, aby som jej nepodlahol.
Pred 20 rokmi to bolo brane ako obrazne. Ak vzdy reagujete posmesne tak tato diskusia nema pokracovanie. Uzivajte si zivota, sledujte svoje zaujmy, aby vam bolo dobre. Mne je dobre najma vtedy, ak to co mi je drahe bolo zdrave, a teraz nemyslim svoju osobu. -
anonymníRec byla o 'nas' a dobe prd dvaceti lety. To, pokud se nemylim, v pulce vyspeleho sveta (i u nas) panoval komunismus (resp. presneji socialismus).
Ale svet neni jen o technologiich, ale take o tom, jak jsou efektivni a pouzitelne v praxi. Pokud mam technologii, ktera je v necem lepsi, ale v jinych parametrech (vcetne treba nakladu) horsi, pak to neni jednoznacna volba (napr. pokud ostatni zustanou u te stare levnejsi a vyhody te nove mi nepokryji jeji naklady, tak neuspeju). Neco jineho pak je, jak udelat obecne tu novou technologii atraktivnejsi.
Ano ekonomicky je svet rizen (presneji organizovan, koordinovan) cenami (vetsinou v penezich). Organizovat ho 'zdravym rozumem' tj. centralnim planovanim bylo cilem prave v komunistickem bloku. Tento system selhal a to proto, ze nikdo nebyl schopen to vsechno uridit. Svet je mnohem slozitejsi nez se zda :)
Nemusite se bat, vzdy pomerne velka cast mladych lidi ma pocit, ze je spolecnost prohnila a zkazena a funguje cela nejak divne. A Podobne i tech starsich ("kam se ten svet riti? tohle za nas nebyvalo"). A to nejen poslednich 20 let, ale uz cele veky. -
uzivatel (neregistrovaný)Ako som spominal doba pred 20 rokmi bola len obrazne povedana, tak na to prosim neukazujte pokial nie je vasim zamerom mlzit.
Ekonomika bola vo svojej dobe mozno dobry napad, ale prerastla v nieco co uplne zdegenerovalo rozum. Toto bolo davno a aj bude.
Niektori sa nechaju a niektori sa nenechaju.
Osobne dufam, neurazte sa, ze to tak poviem, ale nechcem byt ako vy. Budem mozno navonok robit, ze suhlasim so spolocnostou, no vnutorne nezmenim svoju pravu tvar. Nechcem sa nechat zmenit majoritou, som individualna osobnost, viem mysliet sam za seba, viem nacuvat, no nikdy nebudem slepo nasledovat. -
anonymníAle proboha to je ten nejzakladnejsi omyl! Ekonomika neni neci NAPAD. Je to prirozeny proces. Ekonomiku nikdo nevymyslel a nepresvedcoval lidi aby na ni presli. Ekonomove nevymysleji, ale zkoumaji a modeluji realitu. Neni to jako operacni systemy nebo software. Ekonomicke teorie nejsou zdrojaky toho, jak to ma fungovat, ale modely a teorie, jak a proc to nejspise funguje zrovna takhle.
Neni to cele organizovane a spravovane nejakym adminem. Spravuje a udrzuje se to vicemene samo (coz je, uznavam, pro mnoho lidi, zejmena technickeho a programatorskeho-stvoritelskeho zamereni, tezko pochopitelne - ale je to i relevantni a castecne technologicky obor - komplexita a emergence - jak z cinnosti velkych skupin jedincu chovajicich se podle jednoduchych pravidel vznikaji velmi slozite systemy). -
Pepa (neregistrovaný)Nejsem si jistý, jestli ekonomové jenom zkoumají. Co třeba ty chytrý pánové v ČNB co čas od času zahýbou s úrokovými sazbami, které pak zahýbou s úroky úvěrů, hypoték atd. Vzhledem k tomu, že se na základě zkoumání(doufejme) provádějí opatření mající za snahu chod ekonomiky měnit bych to přirozeným procesem nenazýval. Přirozený proces to byl možná tak před příchodem ekonomů.
-
anonymníTo je ale hospodarska (resp. v tomto pripade monetarni) politika statu. Jsou to zasahy do ekonomiky za ucelem regulace jejiho vyvoje s tim, aby se nektere veliciny (kurz, uroky, rust hdp) udrzely tam, kde oni se domnivaji, ze maji byt. Neni to zmena fungovani systemu (algoritmu), ale zmena nekterych jeho (vstupnich) parametru s cilem prostrednictvim tohoto systemu zmenit nejake jine (vystupni) parametry.
A ano jejich fungovani a rozhodovani je zalozeno na nejakych (dosud nevyvracenych) modelech, ne na predem danych algoritmech.
Za prirozeny proces jsem oznacil _vznik_ tohoto systemu (jako opak k nazoru, ze se jedna o myslenku). -
JeCh (neregistrovaný)Ano, bylo by tu sice možná 13 renderovacích módů prohlížečů, ale 9 by se nechalo ležet ladem. Zůstaly by 4 (možná míň nebo víc) hlavních (Trident, Gecko, Opera, KHTML) a v ideálním případě by všechny fungovaly stejně. Zbyl by tedy nakonec pouze jeden mód. Není to lepší než současných 9?
Prostě současné stránky ať si fungují dál. Ale zároveň by bylo dobré umožnit používat nový jazyk, oproštěný od chyb starých verzí. Pokud by se podařilo vnést dostatečné množství důvodů, aby byl důvod přejít, mohlo by to přinést úspěch.
Například by se na www.mojestranka.cz mohlo objevit: "Pokud chcete prohlížet verzi s lepším interaktivním obsahem a rychlejší odezvou, použijte browser XYZ." Postupně by asi implementaci nových vlastností přijaly i ostatní browsery. Ale musí být důvod "PROČ". A já myslím, že by se jich několik dobrých našlo. -
anonymníAle nejpalcivejsi problem soucasnosti neni v tom, ze by soucasne HTML bylo nekompatibilni. Ve firefoxu i opere si dnes prohlednete temer vsechno.
Nejpalcivejsi problem je, ze v HTML citelne chybi nektere pozadovane vlastnosti, aby bylo mozne ho efektivne pouzivat jako rozhrani k pokrocilejsim aplikacim.
Realne alternativy jsou, zda se, pouze dve: bud XHTML2 nebo HTML5.
XHTML2 resi neco jineho, nez co je hlavnim problemem, a resi to tak, ze zahazuje vetsinu toho, co existuje a pomerne dobre funguje. A neresi to, co je tim hlavnim problemem.
HTML5 se snazi resit to, co je hlavnim problemem a to v kontextu toho, co v soucasnosti existuje a pouziva se.
XHTML2 je rozhodne elegantnejsi a krasnejsi a dokonalejsi, ... ale za vysokou cenu. -
uzivatel (neregistrovaný)Hmm, tak to mas teda velku vacok (kapsu) na saku. Mne sa tam teda CD urcite nezmensi.
Samozrejme spravna odpoved tu uz zaznela. Povodne malo mat CD iba 60minut. Ake technicke cislo ze ? :) Technologia uz bola vymyslena, len sa zvacsila velkost. Cize teoriu nenavrhovali praktici. -
Filip Jirsák (neregistrovaný)Ten způsob, jak udělat radikální řez, je velice jednoduchý. Pro nové XHTML se stanoví nový mime typ, který bude zpracováván jiným parserem, než který se používá na klasické HTML. Stávající parsery je tedy možné zachovat, a vedle nich je možné vyvinout jednoduché nové parsery. Ostatně např. Gecko už nyní má 2 parsery – jeden pro HTML a druhý pro XHTML.
-
Filip Jirsák (neregistrovaný)Proč by ho někdo psal? XML parserů už existuje… Spíš je otázka, kdo napíše parser pro HTML 5. Protože jeho součástí má být i popis chybových stavů a jak je řešit. A to teď každý prohlížeč dělá po svém. Takže HTML 5 si buď vybere, jak to dělá jeden OSS prohlížeč, podle něj se standard udělá, a ostatní se budou muset přizpůsobit (napsat nový parser podle vzoru) – což je dost nereálné. Nebo se vyzobe z každého prohlížeče něco, takže budou muset stejně všichni napsat nové parsery. Navíc z toho "od každého něco" vznikne stejně vnitřně rozporný zmetek, a výsledek bude ještě horší, než dnes.
-
Spíš je otázka, kdo napíše parser pro HTML 5
Prakticky hotovo http://code.google.com/p/html5/ -
hejhula (neregistrovaný)Omyl. Hlavní otázka je, proč by s váma Microsoft spolupracoval?
Ten si udělá co chce a na vaše parsery hodí z vysoka bobek. A xhtml.com upraví specifikaci HTML 5 podle toho, jak mu budou wokenní experimentátoři matlat HTML metodou pokus omyl v exploreru sedmičce...
A všechny ostatní prohlížeče se přispůsobí.
Pouze skutečné XHTML (takové to co je kompatibilní s XML) zůstane promyšlené a jednoznačné.
Rozšiřovat specifikaci HTML je jak plánovat východ slunce... -
Hlavní otázka je, proč by s váma Microsoft spolupracoval?
Nedokazu dobre odpovedet na otazku proc, kazdopadne uz s nama spolupracuje. -
Napsane na papire to skutecne muze zni realne. Ptal bych se proc lide, kteri o realnych implementacich neco skutecne vi, maji jiny nazor. Nasel jsem ted odkaz jen na vyjadreni Macieje Stachowiaka za tym webkit (Safari, Apple):
We declined to participate in the XHTML2 Working Group because we think XHTML2 is not an appropriate technology for the web.
Podobne nazory bychom nasli i kdyz ne vzdy takle jasne shrnute rekneme u vsech webovych prohlizeci, ktere maji ma internetu podil vesti nez 0.5%. Stoji minimalne za zamysleni, proc maji vsichni takovy nazor. -
jalinh (neregistrovaný)Přesně tak - autor webu by mohl na začátku svého webu uvést kouzelné<slovíčko> a jeho web by byl zpracováván přísným parserem, nebo by ho neuvedl a jeho web by mohl být tak jako dosud. Pokud by prvním způsobem získal přístup k různým možnostem, jak svůj web zatraktivnit, jistě by se stále více lidí učilo psát validní dokumenty a ostatní nevalidní by byly dále k přečtení. Souhlasím, že tohle by mohlo fungovat....
-
anonymníto je reakce na muj prispevek o minimalnich novych moznostech v XHTML2???
prave proto se nikomu (vyvojarum nastroju, prohlizecu ani autorum) nevyplati jit do XHTML2, protoze krome problemu s nekompatibilitou aktualne nic noveho nenabizi
nemusim mit 5 verzi prave proto, ze jsou dosud existujici normy kompatibilni :)
a kdyz uz by se neco takoveho delalo, tak to nebude podle norem, ale podle prohlizecu, ze? :)) -
uzivatel (neregistrovaný)Mimimalnych ?
Pre teba je moznost doplnit si hocijaku chybajucu vec pomocou modulu, nad ktorym dbie najma W3C malo novych moznosti ? Ty budes radsej vidiet kazde dva roky novu normu, ktora ani nemusi byt kompatibilna s predchadzajucou ? XHTML ti to aspon trochu plni, pretoze bolo pisane uplne odzaciatku a odstranovalo prave tieto neduhy.
No to ma podrz. Ako dlho tvoris webove stranky ak sa mozem spytat ? -
anonymníA to si mam pro ty svoje moduly psat i pluginy do prohlizecu a distribuovat je uzivatelum??
To pak bude nejenom problem s verzi specifikace HTML, ale i s verzi specifikace modulu a konkretni verzi toho ktereho modulu, ktery zrovna to neco neumi...
A pak zase nebude ten modul implementovany pod 64bit a nebo pod linuxem...
Kazde dva roky? A kdo a proc by tu normu vydaval? Kazde dosavadni HTML bylo zpetne kompatibilni a pridalo novou funkcionalitu, ktera byla pozadovana.
Jedina webova norma, ktera neni kompatibilni s tou predchozi je prave XHTML2. A nez cekat X let na XHTML3 -
uzivatel (neregistrovaný)Hovorim moduly spravovane organizaciou W3C, alebo hociktorou autoritativnou. Ked si macher tak si kludne pis pluginy sam :)
Na toto by mali vymysliet cerfitikaty, a honosit sa im moze iba ten, ktory splna vsetko potrebne. Myslim, ze vyrobci prehliadacov by sa roztrhali, aby sa nim mohlo honosit. Vsetko je vec penazi, robi sa to co ktorej skupine najviac vyhovuje. Vyrobcom prehliadacov vyhovuje toto.
Pretoze to co navrhuje HTML 5 je len docasna nahrada. A tato norma pred sebou tlaci stale vacsi a vacsi kamen, ktory v urcitej dobe nepotlaci a mozno pride na to, ze predsa ten novy model bol v danej dobe ovela vyhodnejsi a daval nam vacsiu moznost rozsirovania technologie. -
anonymníZatimco XHTML2 je jako navrhovano na vecne casy a nikdy jinak??
Co je tim velkym kamenem?
Jak XHTML2 aktualne rozsiruje technologii webu?
Jake jsou ty moduly, ktere jsou potreba a nejsou zahrnuty v HTML4? Jedine o cem vim, je xforms (o tom, jak je to pro tvurce dulezite svedci i to, ze je uveden jako posledni z modulu), ktere ale nejsou zdaleka vazany na pouziti v XHTML2 a protoze priznavam, ze jsem se v nich jeste poradne nehrabal, tak nevim, jestli splnuji vsechny hlavni pozadavky na webove aplikace. -
uzivatel (neregistrovaný)Nie. XHTML 2 je XHTML 1.1 na steroidoch, lahko povedane :)
Je to modularny jazyk.
HTML 5 ide cestou nemodularnosti. Ono si mozete povedat, ze 99% ludi to nevyuzije, co je dost mozne, ale z zaklade ponuka niektore podobne znacky ako HTML 5 a niektore mu chybaju z toho dovodu, ze je vyvijany velmi dlho a k vsetkym nedoslo. Urcite ma svoje chybne miesta, s ktorymi nesuhlasim ani ja. Ja chcem poriadny jazyk, ktory bude pouzitelny. Nechcem ani HTML 5 ani XHTML 2, Chcem nieco medzi tym. Ale ako zaklad by som bral prave ten XHTML, pretoze mi prijde z pohladu tvorcu s jasnejsimi pravidlami. Uznavam, ze pre zaciatocnika o to zlozitejsi. Preto by mohli aj na tejto stranke viac zapracovat.
HTML nie je vobec modularny jazyk. To znamena, ze nemoze pouzivat moduly z Ruby, MathML, XForms, XMLEvents, XFrames, XLink a urcite pribudnu dalsie.
Sam si priznavam, ze XHTML 2 je velmi neprehladny, ale zaroven neoznavam ani HTML 5 v plnej podobe. Cize som medzi oboma tabormi a snazim sa poukazovat na ich nedostatky.
Je dost pravdepodobne, ze HTML alebo XHTML budu posledne jazyky pri vyvoji webu a nastupi interaktivny prenos, kedy sa zo serveru bude posielat priamo vygenerovany program s dynamickymi oblastami aky je znamy z sci-fi filmov. (X)HTML je moc staticke na podobne veci. A nejaky AJAX to nezachrani. Davam tomu 20 rokov. -
anonymníNa steroidech? To spis na tripu :))
Ale nic mezi tim proste v soucasnosti neni. XHTML2 je (skoro?) hotova specifikace, kterou ale nikdo nechce implementovat. HTML5 je ten pokus o neco novejsiho, ale jineho nez XHTML2.
No kdyz uz jsme v te sci-fi, mozna by stalo za to, kdyz uz se zamyslime nad redefinici webu se nezastavit u HTML, ale vzit to pekne odpodlahy vcetne HTTP. Takove modularni http, stavove, s integrovanou pokrocilou auntentizaci, sifrovanim casti prenosu, ...
Upravene URL tak, aby odlisovalo staticke a dynamicke dokumenty a clovek se nemusel bat ve webove aplikaci kliknout na back nebo reload...
To uz by ale nebyl soucasny web, ale neco uplne jineho, prirozene nekompatibilniho a tam teprve by se projevila ta sila nove standardizovane technologie -
uzivatel (neregistrovaný)XHTML 2 nie je problem implementovat. Je to len chaba vyhovorka. Kezde sa znackami podoba prave HTML5. Tam su zaujmove kroky ako to je skoro pri kazdom vacsom rozhodnuti.
Pokial si dobre pamatam tak viem o dvoch skupinach, ktore pripravuju nove sietove a aplikacne prostriedny rededifnicie webu.
Jedna konkretne spomenuta je tu: http://dsl.sk/article.php?article=3712 -
anonymníTady nejde o to, ze by to byl technicky problem implementovat.
Tady jde o to, ze ta implementace by byla temer k nicemu. XHTML2 neresi aktualni problemy webu. U autoru neni duvod na nej prechazet.
Misto toho uhyba na vedlejsi kolej a resi technologicke detaily a to zbytecne slozitym zpusobem a nekompatibilne. -
anonymníRuby (ctu spravne, ze to je hlavne pro popis vyslovnosti vychodoasijskych jazyku a kratke anotace??) neni to, co by soucasnemu HTML chybelo.
MathML mozna chybi vedeckym pracovnikum (tem, kterym bylo puvodni HTML urceno). XForms se snazi HTML5 resit. XMLEvents prosim, jakasi nadstavba nad obecnymi DHTML udalostmi nutna prave kvuli modularizaci. U XFrames nechapu smysl, klasicke frames uz z webu ustupuji (pokud tam neni upraveno jak pri pristupu na libovolny frame ho otevrit v odpovidajici strukture, pak je to na nic).
Soucasti specifikace XHTML2 je zacleneni pouze ruby, XMLevents a Xforms. Xlink je v textu dokonce primo zavrzeny.
Vetsina tech X-standardu je navic uz pomerne dost stara - pochazi z let 2001-2004 tj. z doby posedlosti vsim, co bylo X. V praxi se ale nejak moc neujaly a kdyz, tak rozhodne ne na webu. Cele to X hnuti se tak nejak minulo s webem. Zatimco panove (a damy) ve W3C davali kolik let dohromady obousmerne linky, anotace atp. (tj. zejmena veci vhodne pro textove dokumenty) web se posunul nekam jinam. Objevila se v obrovske mire multimedia, video, blogy, sdileni obsahu. Stalo se z nej zasadni implementacni prostredi pro rozsahle podnikove i verejne aplikace.
A to vsechno na 'starych' technologiich za pomoci novych nikym nestandardizovanych obezlicek jako AJAX. -
fissie (neregistrovaný)Lidé okolo WHATWG se pohybují v rovině praktické, uvědomují si, co má u výrobců a autorů obsahu šanci a co ne.
Osobne taky tenhle pristup nechapu a asi pochopit nedokazu. WHATWG neustale argumentuje tim, jak je XHTML2 k nicemu, protoze se nechytla v praxi. Jak by asi mohla, kdyz prave titez lidi, co toto tvrdi, se ani nikdy nepokusili ji naimplementovat? Ale jiste, ze by se pouzivat zacla, ona k tomu jen proste nedostala prilezitost. Mezi autory webu se jiste najde spousta tech, kteri radeji pisou v cistem a prehlednem XML, nez aby krizili tagy v HTML 4 (takovych je sice taky dost, ale ti by o sve praseni nutne preci adoptovanim XHTML2 neprisli). Jasne, uplne vidim ty argumenty, ze si to mam naimplementovat sam, kdyz je to tak snadne... jasne ze neni. Ale kdyz uz si hosi z WHATWG mohou vymyslet spoustu novych uzasnych featur do HTML5, tak by jiste zvladli i implementaci XHTML2 a dle meho nazoru by to byl rozhodne lepe investovany cas. Bremeno zpetne kompatibility nelze tahat vecne.
Navic s XML je spjata spousta dalsich hezkych technologii, se kterymi se da pracovat. Co treba Xforms? Ne, my si musime vymyslet vlastni webforms, protoze hotovy standard nam nevyhovuje, a pritom by do XHTML2 tak krasne zapadl. K cemu komu muze byt formularove pole, ktere povoli vkladat jen URL nebo e-mail? Nechat kontrolu vstupu ciste na klientovi je spatny vtip, pritom presne k tomu to vede, pokud tedy bereme v uvahu, ze web pisou nejvice prave lidi, kteri si ani neumi ohlidat krizeni tagu. -
anonymníZrejme proto, ze se osobne pohybujete pouze v rovine technologicke nbo navrharske a jko nejlepsi reseni vetsinou vidite napsat neco uplne znova.
nejde o to, ze XHTML2 je knicemu _protoze_ se nechytla v praxi, ale prave naopak nechytla se v praxi protoze neni navrzena s ohledem na praxi, neprinasi temer nic noveho, krome zpetne nekompatibilni zmeny formatu :)
Problem jiste neni v tom, ze by nebyli schopni parser pro neco takoveho napsat, ale v tom, ze zadna relevantni skupina uzivatelu to nevyzaduje. Vyzaduje to pouze hrstka teoretiku, a XML puritanu :) Ono to podobne dopadlo uz s XHTML1, ale protoze tam to bylo zpetne kompatibilni, tak neslo o takovy problem.
Ale jeste vice je tech, kteri tagy v HTML4 nekrizi a staci jim to. v cistem a prehlednem XML muzete psat weby ve zpetne kompatibilnim XHTML1.
Naimplementujte si co chcete, ale asi neocekavate, ze nekdo bude delat web, ktery si prectete jenom vy a ti, kteri maji vas prohlizec.
Jeste jdnou zduraznuji, ze nejde o schopnost implementace XHTML2, ale o jeji prinosy. Bremeno zpetne kompatibility je mozne odhodit v tom pripade, ze nova technologie je o tolik lepsi a nabizi o tolik vice pozadovanych funkci, nez stara nez stara, ze se drtive vetsine subjektu vyplati na ni prejit.
Samozrejme ze jde hlavne o formulare (treba interaktivni tabulka) a na ty se melo W3C zamerit na misto cizelovani genialniho navrhu XHTML2. Co si z xforms vezmou do (x)html5 nevim, ale zrejme neco ano.
Pokud je pravda, ze "web pisou nejvic lidi, ktry si neumi ohlidat ani krizeni tagu", potom plati, ze XHTML2 by uzavrelo web pro vetsinu tvurcu, coz jiste neni zadouci. Ja osobne nechodim na weby kvuli jejich validite, ale kvuli jejich obsahu. -
Franta (neregistrovaný)A co nám brání u dokumentů, které chtějí využívat nové funkce a elementy, validitu a čistý kód; a staré HTML parsovat a zobrazovat postaru?
IMHO nic a výhoda je v tom, že jednou budeme moci zahodit to závaží starého zpraseného HTML (až časem vymizí takové stránky). Stejně jako dnes nemusí každý výrobce elektroniky montovat do svých přehrávačů mechaniku na kazety a dá tam jen CD mechaniku. -
Franta (neregistrovaný)To jsi řekl moc dobře.
Nikdo přece uživateli nebrání, aby používal věž, která k sobě má kazeťák i CD. Stejně tak může mít prohlížeč, který umí jak staré ničemné HTML, tak i nové (X)HTML. Při otevření stránky se rozpozná, jestli je to staré HTML, pak se předá starému parseru, který se pokusí nějak interpretovat i zprasený kód. A když je to nové (X)HTML, tak se použije nový parser, který je přísný, ale zase budou dostupné pokročilé moderní elementy a funkce.
To, že v prohlížečích zůstane podpora starých stránek, nebrání tomu, aby nový formát byl čistý.
Řeči o tom, že by se 78-90% webu stalo nedostupným je sprostý FUD! -
vorel (neregistrovaný)Podle mě je <b>nějaká <i>naprostá</b> blbost</i> totéž jako <b>nějaká <i>naprostá</i></b><i>blbost</i>, akorát méně značkami. Není to zase až tak nelogická konstrukce - průniky množin jsme se přece všichni učili už v první třídě, ne?
Podle současné specifikace je to tak ovšem špatně, proto neexistuje jednotný předpis, jak to má browser zobrazit... a proto by se to používat nemělo. Puntík. -
uzivatel (neregistrovaný)Nechapes tomu. Vsetky nesemanticke znacky definuje vzhlad by mali byt odstranene. Co ak ja nechcem tucny a ohnuty text, ale chcem k nim pridat dalsie efekty ? Samozrejme, ze to pojde, ale tieto tagy k tomu nie su urcene. BOLD a ITALIC, vyjadruju ti tieto slova nejaky iny vyznam ? Mne teda nie, preto by mali byt nahradzovane pomocou SPAN, ktory bol na to primarne urceny.
A STRONG a EMPHASIS su semanticke znacky, takze nechapem, preco ich sem tahas. Vidiet, ze asi si normu nestudoval. Priznam sa, ze ani ja nie, ale nieco sa na mna nalepilo. -
anonymníPozor na to. To je pohled ktery se diva na dokument pouze z hlediska jeho obsahu. Pokud je primarnim obsah dokumentu a dokument je dobre strukturovany (napriklad clanek, bakalarska prace), pak je to jiste chvalihodne.
Ale HTML uz davno neslouzi pouze k tomu. HTML je svym zpusobem castecne i graficka prace nikoliv pouze typograficka. A pokud chceme mit HTML i pro tyto dokumenty, je opravdu nutne nutit jejich autory k tomu, aby si umele vymysleli semanticky vyznam?
HTML neslouzi pouze k definici semantiky, protoze na webu se uz davno neobevuje pouze textovy obsah. HTML je spise multimedialni format. Pocitam do toho samozrejme i CSS. Cili HTML+CSS+dalsi (flash atp.) definuji spolecne (nikoliv zcela oddelene) obsah a vizualni podobu.
A na okraj uvaha - jaky semanticky vyznam ma SPAN a DIV? Zadny :)) Je to proste univerzalni (jeden defaultne blokovy a druhy defaultne inline - coz lze ale zmenit cili jeden je nadbytecny) tag. Existuji jenom proto, aby se pomoci class nebo id dalo vytvaret vlastni (jiz nikde nedefinovane a tedy neprilis semanticke) tagy. Existuji prave proto, aby se dalo prachsproste nesemanticky designovat :)) -
uzivatel (neregistrovaný)Hlupost. Praveze kedysi bol HTML aj ako graficky format, ked sa neho nabalovali zbytocne tagy. Sam som zacinal v dobe ked v plnej mieste fungoval tag FONT.
HTML ale nikdy nesluzil ako graficky format. Zacal sa tak neskor pouzivat, ale prave kvoli tomu vzniklo CSS, ktory to ma priamo v nazve, cize STYLE. Ma sa nim robit styl. HTML ma prave to slovicko MARKUP, cize znackovaci. Nic viac a nic menej.
Ak nechapes rozdiel bezi DIV a SPAN tak je to pre teba zle. DIV je blokovy tag, preto sa ma na to pouzivat. Uz vidim ako cez DIV a upravou cez CSS menis display farbu jedneho slova. Si masochista ? Ked sa v tom vyzivas tak v pohode. Nebudem ta obmedzovat. Ale tym, ze zmenis zobrazovanie DIVu na inline nezmenis jeho vyznam. Je to stale blokovy TAG preto sa ma aj tak vyuzivat.
Ale tie priklady co spominas vobec nemaju suvislost. Cize neuraz sa, ale trepes a snazis sa to nejako zamaskovat. -
anonymníPokud se k tomu zacal pouzivat a spolu s CSS se tak pouziva dodnes, tak slouzi jako 'graficky' format :) Pomoci CSS nic samotneho nenastylujete. Potrebujete k tomu HTML (nebo obecne XML).
Kdyz si znovu prectete pozorne to, co jsem napsal, uvidite, ze vim, ze div je na rozdil od span standardne blokovy, ale bock/inline je spise vlastnost graficka, nez semanticka, nemyslite? :))
Nevim co se vam zda, ze se snazim zamaskovat. Pouze upozornuji na to, ze web neni pouze medium pro textove dokumenty s jasnou semantikou ale take pro dokumenty spise na efekt a nebo na oboji :) A (pravda v ocich vetsiny XHTML semantiku nehorazne kacirskym az rouhacskym) dukazem budiz existence nesemantickych tagu DIV a SPAN i v tak semantickych jazycich, jako XHTML2 :)
Jestli vas ta kacirska myslenka (a rozhodne si nedelam narok na to, ze s ni prichazim sam, natoz jako prvni), ze span a div nejsou semanticke, tak mne proste ignorujte. -
uzivatel (neregistrovaný)"Pokud se k tomu zacal pouzivat a spolu s CSS se tak pouziva dodnes, tak slouzi jako 'graficky' format :) Pomoci CSS nic samotneho nenastylujete. Potrebujete k tomu HTML (nebo obecne XML). Nechapes to. HTML len znackuje co je co. Dizajn tomu dava CSS a HTML na to nebol projektovany. CSS ma 11 rokov. Bolo uz v dobe HTML 3. Len prave vyrobcovia prehliadacov zmrstovali vyznam HTML a zavadzali ho aj pre dizajn. Kdyz si znovu prectete pozorne to, co jsem napsal, uvidite, ze vim, ze div je na rozdil od span standardne blokovy, ale bock/inline je spise vlastnost graficka, nez semanticka, nemyslite? :)) Nemyslim. V HTML je DIV definovany ako block. To ze mu mozem zmenit jeho graficky vyznam, je dane tym, ze CSS mi to dovoluje na kazdy tag, ale nezmenim vyznam ako popisok. Stale to bude blok. To ako ma vyzerat mu zadefinujem v CSS. Vy snad vycitate z toho, ako ma velkost, aku ma sirku, ked sa definuje len oblast, ktora je blok ? Ja teda nie. Nevim co se vam zda, ze se snazim zamaskovat. Pouze upozornuji na to, ze web neni pouze medium pro textove dokumenty s jasnou semantikou ale take pro dokumenty spise na efekt a nebo na oboji :) A (pravda v ocich vetsiny XHTML semantiku nehorazne kacirskym az rouhacskym) dukazem budiz existence nesemantickych tagu DIV a SPAN i v tak semantickych jazycich, jako XHTML2 :) Nie som ziadny XHTML fanatik, len sa snazim lepsie pochopit tu normu. A zistujem, ze je vazne kvalitne napisana. Prznia ju taki co ju chcu pouzivat na nieco ine nez na co je primarne urcena. Jestli vas ta kacirska myslenka (a rozhodne si nedelam narok na to, ze s ni prichazim sam, natoz jako prvni), ze span a div nejsou semanticke, tak mne proste ignorujte. Aka kacirska myslienka ? Ja pouzvam jazyky na to na co su presne urcene. Takze mne je jedno ako ich pouzijete. Ja budem vyuzivat ich skutocny vyznam. A sam viem, ze SPAN a DIV su nesemanticke. Pretoze ohranicuju len nejaku oblast, ktorej nedavaju ziadny vyznam. To by ste uz mohli tiez pochopit.
-
anonymní
DIV ale nema vyznam popisek, nema ani jiny semanticky vyznam. DIV ma vyznam "kus textu" s vychozim formatovanim block. To neni semantika, ale spis definice vzhledu.
Delat menu pres DIV neni semanticke. Kazdy si menu nejen jinak ostyluje, ale i jinak nadedefinuje v ramci HTML a bez formatovani neni mozne urcit, ze tohle je zrovna menu. Semanticke by bylo zavest neco jako tag MENU. Mnoho lidi na svych webech potrebuje menu. HTML4 ale ani nejnovejsi XHTML2 jim to neumoznuje udelat semanticky.
Pokud uz uznavate, ze web neni pouze typograficka platforma pro sazeni textu, proc hned rusit jednoduche formatovaci tagy? Co treba jednoduche HTML editory v mail aplikacich? Proc tam slozite cpat styly, kdyz by stacilo font a b? Proc nutne odebirat moznost vizualniho formatovani a nahrazovat ji pseudosemantikou?
pouzvam jazyky na to na co su presne urcene
Opravdu? :) Jenomze technologie WWW se obecne jiz dost dlouho nepouzivaji na to, k cemu byly primarne urcene, ze :))
HTTP je bezstavovy protokol naprosto nebhodny pro webove aplikace :) vetsina URL jiz davno neslouzi k jednoznacne identifikaci konkretniho dokumentu HTML se pouziva pro psani rozhrani webovych aplikaci, tvorbu menu a dalsi silenosti, ke kterym tenhle format pro popis textovych strukturovanych dokumentu provazanych odkazy rozhodne nebyl urceny :)Jsem rad, za predposledni vetu. Zejmena proto, ze se mi mozna povedlo alespon primet nekoho k prehodnoceni nazoru, ze Vsetky nesemanticke znacky by mali byt odstranene, a ze semantika je za vsech okolnosti samospasitelna.
-
uzivatel (neregistrovaný)-- DIV ale nema vyznam popisek, nema ani jiny semanticky vyznam. DIV ma vyznam "kus textu" s vychozim formatovanim block. To neni semantika, ale spis definice vzhledu.
-- Delat menu pres DIV neni semanticke. Kazdy si menu nejen jinak ostyluje, ale i jinak nadedefinuje v ramci HTML a bez formatovani neni mozne urcit, ze tohle je zrovna menu. Semanticke by bylo zavest neco jako tag MENU. Mnoho lidi na svych webech potrebuje menu. HTML4 ale ani nejnovejsi XHTML2 jim to neumoznuje udelat semanticky.
Nechape rozdiel medzi sementickym a nesementickym ? Hovoril som, ze DIV a SPAN je nesementicky, pretoze nema ziadnu vahu. Nic, je to len obycajny tag definovay oblast ako blok alebo ako typ inline textu. Co je na tom nezrozumitelne ?
Ale ja nehovorim o WEBe ako samotnom. Bavili sme sa o HTML a CSS tak prosim neodbiehajte inam. HTML je stale len znackovaci jazyk, ktori hovori ze toto je zoznam, toto je tabulka, toto je hadpis. Nic viac a nic menej. Ma danu svoju strukturu kedy napriklad nadpis prveho stupna nemoze ist za nadpis tretieho stupna a podobne. To co vidis ako vystup by mala byt vzdy praca CSS ako jazyka popisujuceho dizajn. Nechapete rozdiel medzi tymito dvoma jazykmi ?
Ano. Nesemanicke znacky by mali byt odstranene, ale len tie, ktore su prekonane. A to je dizajnovanie farieb a typu pisma. Ak sa budu zachovavat tak sa budu stale vynarat ohlasy, ze preco nie je napriklad tag, ktory nakloni text na druhu stranu a podobne. Na to tu je CSS, ak sa s tym niekto nevie zmierit jeho problem. DIV a SPAN su bezvyznamove znacky a v norme ani v ziadnom prehliadaci sa im nepripisuje ziaden iny vyznam okrem toho, ze je jeden typu block a druhy inline. -
anonymníStejne tak se ale znackam B nepripisuje jiny vyznam, nez ze je to tucny text (ktery jde v CSS zmenit treba na kurzivu) :))
To je prave ten problem, XHTML si hraje na semantiku, ale misto aby semanticky popsalo pozadovane vlasnosti (treba menu, zahlavi, zapati, vstupni formulare), tak to oseka na par zakladnich veci jako div a span a prida hromadu pomerne komplikovanych a ne az tak potrebnych X technologii se spornou vyuzitelnosti.
Ale HTML ma slouzit prave webu jako takovemu :) Proto je potreba divat se na nej minimalne v kontextu celeho webu. XHTML2 je dnes spis necim jako pokusem o univerzalni hypertextovy obecny kancelarsky format poslepovany z ruznych X. na potreby soucasneho webu nereaguje.
Vyhazovat za kazdou cenu primitivni formatovaci tagy je zbytecne. Kdo je chce pouzit (treba v tom mailu) at je pouzije. Kdo chce nove vlastnosti, at pouzije CSS. Tak to uz funguje celkem dlouho a nikdo snad nepozaduje pridavat do HTML to, co umi CSS.
Takze by mely byt odstranene vsechny bezvyznamove univerzalne formatovaci znacky a nahrazeny jinymi bezvyznamovymi formatovacimi znackami, ktere ale nemaji definovany ten zakladni format? :) Mimochodem netusite, proc je i po cistce v XHTML2 stale takova nesemanticka a ciste formatovaci vec jako atribut style? :)) -
anonymníTo takove reseni se mi zda od W3C dost nezvykle. Ocekaval bych spis, ze ho v nasledujicich letech (odhadoval bych to tak 5-10) hodla nahradit samostatnym modulem postavenym na nejakem cool samostatnem X-jazyku. Bude mit urcite vlastni jmenny prostor, skvele tagy umoznujici definovat netusene (a nepozadovane) vlastnosti.
Jenom je skoda, ze se to asi nebude jmenovat XMenu, tohle jmeno uz jim nekdo vyfouknul, mimochodem, vite, ze XHTML2 je TradeMark? :) -
Lot (neregistrovaný)Cituji: "HTML ale nikdy nesluzil ako graficky format. Zacal sa tak neskor pouzivat..."
Nechápu jak je možné že se html používal (lépe řečeno používá) jako grafický formát a přitom tak neslouží :-).
Možná Ti bude zle i ze mě - ale jaký sémantický význam má SPAN? IMHO žádný. Jaký je tedy sémantický rozdíl mezi SPAN a FONT? IMHO žádný. Výhodou tagu SPAN je, že můžeme následující nésemantické informace vyčlenit na zvláštní místo. Ale stánka poslepovaná z desítek DIVů a SPANů je IMHO stejně nesémantická jako stránka využívající jiné, rovněž nesémantické (dnes nedoporučované) značky.
Tím nechci zpúochybňovat nesporné výhody používání CSS, pouze poukazuji na to, že CSS samo o sobě sémantičnost stánky nazajistí. -
uzivatel (neregistrovaný)Dalsi co nevie citat ? Ja VIEM ze SPAN a DIV NIE SU SEMANTICKE.
Koniec. dalej nereagujem.
Font je prekonana vec co sluzila iba na definiciu fontu. SPAN je univerzalny.
Ak tomu nerozumies tak dalej nepis prosimta.
Ale ja netvorim 10 divov. Ja vyuzivam maximalne ako sa daju vyuzit ostatne znacky a vyhybat sa divom.
Ale ty nechapes ze CSS nie je a nikdy nebolo semanticke. TO bolo vzdy a vzdy bude HTML. CSS definuje iba vzhlad, ktory k semanticke vobec nepatri.
Nemam uz naladu to furt vysvetlovat. Nastuduj si to. -
Lot (neregistrovaný)Dvakrát jsem si četl svůj předchozí příspěvek a uvažoval, co Tě přimělo k tak příkré reakci, domění že jsem hlupák nebo se přinejmenším v html naprosto neoriantuji a měl bych studovat. Stejně jako jsem Tě ani náznakem neobvyňoval, že nevíš, že SPAN není sémantický a že tvoříš stánky slepené z desítek DIVů.
Jelikož jsi mě zřejmě nepochopil, pokusím se svůj předchozí příspěvek vysvětlit.
1) Vyjádřil jsi přesvědčení, že html nikdy nesloužilo jako grafický formát. Poukázal jsem na to, že si protiřečíš, jelikož přiznáváš, že se tak záhy stalo. Tedy správné vyjádření by bylo html PŮVODNĚ nebylo určeno jako grafický formát. Od dob odkdy se masově rozšířilo dodnes tak slouží.
2) Nenavrhoval jsi odstaranit VŠECHNY nesémantické značky?
Domyslel jsem si (věřím že ne špatně), že to nemyslíš tak úplně striktně a div a span bys ponechal - jenže ouha, tím by se sémantičnost html nijak nezvýšila. Lamy by pro tučné písmo nepoužívaly ošklivé nesémantické U ale "nádherné" nesémantické SPAN (samozřejmě že vím o existenci sémantického STRONG).
3) Nepoukazoval jsem na to, že tvoříš staránky splácáním desítek divů, ale na to, že jsou mnohé stránky takto splácány.
Klasické stránky nesou jak sémantickou tak nesémantiskou informaci. Nevidím žádný důvod snažit se tu nesémantickou vyloučit. IMHO jde hlavně o to, aby stránky nestratily sémantickou hodnotu. Využití CSS může (!) sémantičnost zvýšit (jsou-li styly aplikonány na sémantické značky), ale samy o sobě to nedokáží zaručit. -
uzivatel (neregistrovaný)Mozno sme sa nerozumeli, takze budem reagovat tiez v podobnom volnom duchu.
1) Skus sa len tak zamysliet, kto prave donasal do HTML "bordel" ? Boli to prave vyrobcovia prehliadacov, ktori sa bili o to, ze vymysleli novy tag tak hura s nim do specifikacie. Ale HTML tak projektovany nebol. Bola to jeho chybna ulicka, preto vzniklo CSS.
2) Je pravda, ze tym vyjadrenim som to nemyslel uplne presne. Chcel to povedat tak, ze som za odstranenie vsetkych nepotrebnych textovych znaciek, ako je B a I. Ich uzitocnost je prekonana. Mohli by sa tvorit ohlasy o nove tagy na upravu textu. A to je predsa proti logike. Naco mi je 300 roznych tagov ked vsetko spravim cez CSS ? Keby to tak bolo tak CSS nikdy nemuselo vznikat. Som rad, ze to zatial ide cestou zjednodusovania. Rozdiel medzi B a STRONG je prave ten, ze STRONG ma urcitu vahu v texte. Proste je znacka, ze text ulozeny v tomto tagu je vyznamejsi. B je len obycajne zafarbenie textu. Preco by som ho zrusil som spomenul.
3) Ono splacanie vela DIVov nemeni nic na postupnosti sematickych znakov. Ak mas H1 a H2 ulozene kazdy do ineho DIVu ale maju spravnu postupnost tak na semantickosti sa nic nemeni. Prehliadac DIVu a SPANu neprideluje ziadnu vahu a berie ich cisto len ako definiciu pre blok a inline text.
S tym ze CSS moze zvysit semantickost kodu by som si nebol taky isty. Kod sa spracovava atomicky. Cize jednoducho povedane z hora dole. To, ze napriklad niektory blok alebo element prenesies pomocou CSS na ine miesto nic na sematickosti nemeni, nemeni pre stroje. Po vizualnej stranke to je nieco ine, ale ak hovorime cisto o znackach, ktore maju mat nejaku postupnost tak s tym CSS nic nezmenis. To je len graficky vystup. -
Lot (neregistrovaný)Nesémantické prvky bych hned neodsuzoval jako bordel. Přece jenom - jsme lidé a ne stroje a proto je pro nás a naši orientaci ve stránce obvykle podstatnější vizuální hodnota než sémantická - ačkoliv nesmíme zapomínat na to, že i stroje by měly být schopny stránku zpracovávat. Primární určení 90% webu je však pro lidi.
Značky B a I mají modernější alternativu v CSS. Jsou však situace, kdy považuji využít je nebo CSS jako prašť nebo uhoď. Klasický případ - potřebuji jedno slovo napsat kurzívou. Ať již toto slovo obalím v I nebo v SPAN, sémantickou hodnotu to má stejnou a já nevidím zřetelný důvod proč by jedno řešení mělo být o tolik lepší než druhé. Jediný důvod proč v tomto případě upřednostňuji SPAN je, kdybych chtěl někdy v budoucnosti stránky přeďělávat do XHTML (tedy důvod praktický, ne sémantický). Samozřejmě že se takovýto případ nevyskytuje často - mnohem častěji se formátuje některý sémantický prvek a CSS je skvělé tím, že mě nenutí motat sémantické a nesémantické prvky dohromady.
Před B má STRONG díky své sémantické hodnotě jistě přednost.
Dalo by se namítnout, že díky univerzálnímu SPAN jsou již jednoúčelové nesémantické značky nadbytečné. To je naprostá pravda. Jsou však tací, kteří upřednostní jednoúčelobou značku protože je kratší - a nenapadá mě argument, proč by to mělo být horším řešením než zmiňovaný SPAN. Sémanticky považuji obě řešení za (stejným způsobem) špatná, ale kvůli shora uvedenému důvodu nepovažuji sémantiku za alfu a omegu stránek.
Domnívám se, že DIVy snižují sémantičnost textu stejným způsobem jako jakékoliv jiné značky bez sémantické hodnoty. Například takovému FONT prohlížeč IMHO nepřipisuje o nic větší hodnotu než tagu SPAN - oboje slouží k vložení nesémantické informace. Za sémantický považuji text, který má nejen správnou postupnost nadpisů, ale v němž je sémantická informace spjata s nesémantickou způsobem, který činí využití značek bez sémantické hodnoty zbytečným. V ideálně sémantickém textu má každý prvek sémantickou hodnotu a jí odpovídající hodnotu vizuální.
Kvůli tomu jsem také přesvědčen, že správné využití CSS zvyšuje sémantičnost HTML, jelikož dokáže jednotlivým sémantickým značkám přidělit nesémantickou hodnotu, čímž mě ve většině případů zbavuje nutnosti použít nesémantických formátovacích značek.
Jsem-li však nucen k volbě mezi sémantickou a vizuální hodnotou upřednostňuji hodnotu vizuální, jelikož je pro návštěvníky mé stránky mnohonásobně důležitější. -
anonymníAle vzdyt vyrobci prohlizecu vytvorili cele HTML a taky ho vyvijeli :)
TBL kdyz udelal sve (pra)HTML tak ho udelal tak, aby to jeho prohlizec zvladl.
HTML 3.2 prevzalo vetsinu novinek z toho, co bylo v te dobe jiz implementovano v prohlizecich. HTML 4.0 taktez.
Mimochodem s vami vychvalovanymi CSS prisli take lide z okruhu vyrobcu prohlizecu :)
Co presne povazujete za bordel? Nesemanticke graficke tagy? Proc je to bordel? Jiz existuji relativne dobre moznosti to tak nedelat.
Je to stejne jako moznost oddelit vzhled a aplikacni logiku v programovacim jazyce. Muzete to udelat (nekdy pomoci nekterych sablonovacich knihoven) a pro velke projekty se to rozhodne vyplati. Ale kdyz to tak neudelate, uzivateli to je jedno a pro vas je to jenom narocnejsi na dalsi spravu. To ale nemusi vadit u malych projektu. U tech by naopak mohlo vadit to, ze pouziti takove flexibilni sablony je relativne narocnejsi nez primo to narvat treba do zdrojaku v PHP.
XHTML2 postupuje podobne (dle mne spatne) - na misto relativne jednoduche syntaxe pro zakladni veci a trochu slozitejsi pro ty pokrocile zavadi ruzne specialni a univerzalni jazyky, ktere jsou samy o sobe pomerne narocne, natoz jejich kombinace. XHTML2 je tak skoro tak prehledne jako XMLSchema (i kdyz tak spatne na tom zase zdaleka neni). A navic rusi ty jednoduche moznosti.
Web se rozsiril i proto, ze napsat webovou stranku bylo jednoduche. Nebyl to takovy vykon, jako neco naprogramovat. -
uzivatel (neregistrovaný)Ale ja viem, ze CSS vytvorili ludia z Opery. To mi pripominat nemusite. Lenze web sa zmenil. Z obsahovej stranky, ktora panovala v 90tych rokoch 20teho storocia sa vyprodukoval na tovaren plnu penez na ktorej sa da dobre zarobit. Ak ste si to este nevysmi tak ste bud trosku slepy alebo verite marketingovym kecom.
-
anonymní
Naco mi je 300 roznych tagov ked vsetko spravim cez CSS ?
Jedine na to, ze je 300 ruznych vyznamu toho textu. Pak to bude semanticky web. Pokud vam jde jenom o Naformatovani vystacite si s CSS a JEDNIM univerzalnim tagem (no mozna dvema - odkaz se snad neda udelat pres css i kdyz by slo pouzit udalost onclick :)) Naformatujete to bud pres id a class, ktere si uzpusobite a nebo pokud jste vetsi machr tak i pres vzajemnou polohu.
-
byF (neregistrovaný)Dobře, v případě druhé možnosti ušetříte 12 byte.
Avšak změna spočívá ve významu tagů.
BOLD a ITALICS jsou vizuální formátovací tagy. Zobrazují text tučně, respektive kurzívou. STRONG a EMPHASIS jsou logické strukturní tagy. Čirou náhodou (asi protože si vývojáři prohlížečů nevěděli rady, kam zakomponovat B a I v nové specifikaci) se zobrazují tučně, respektive kurzívou. Klidně to může být obráceně. STRONG znamená nápadný, výrazný a EMPHASIS důraz, zdůraznění. Toliko k jejich významu. -
prohlížeč není jediným nástrojem zpracovávajícím html a xml. jakkoliv html5 řeší problémy vývojářů prohlížečů, na problémy ostatních webových vývojářů zvysoka kašle. přitom zastoupení gui prohlížečů mezi klienty se setrvale snižuje a přijde možná i doba, kdy budou většinu traficu tvořit automatické roboty. web je prostě příliš rozsáhlý na to, aby se jím člověk proklikával sám.
zkuste si třeba napsat parser validního xhtml a validního html. který z nich bude jednodušší? přijetí těžko implementovatelné specifikace jen snižuje šance malých hráčů a vede k další monopolizaci (např. googlizaci) internetu.
za html je třeba udělat důraznou tečku právě proto, aby si uživatel mohl vybrat svou cestu. psát těžko zpracovatelný tag soup a nezabývat se chybami, nebo psát použitelnější dokumenty, avšak se striktními omezeními.
současná situace je způsobena tím, že budou prohlížeče neustále přebírají odpovědnost za funčnost z autora dokumentu na sebe. pokud tohle skončí, tak se autoři naučí psát validní dokumenty. a to nemusí být utopie. většina uživatelů webu dnes tvoří své dokumenty v prefabrikovaných nástrojích typu wisiwyg nebo rs. skutečné html nikdy nepíšou a nebudou. pokud chce někdo publikovat, prostě si někde zaregistruje blog, nebo si stáhne existující rs. slovo autor tedy lze omezit jen na autory těchto nástrojů. těch je podstatně méně a své práci (html/xml) by měli rozumět podstatně více než koncoví uživatelé. zpřísněním podmínek tedy bfu nijak podstatně utrpět nemusí.
shrnutí:
1) hlavním autorem není koncový uživatel, ale programátor blogu/rs/editoru.
2) hlavním klientem nejsou, nebo výhledově nebudou prohlížeče.
3) základním problémem webu není "jak zobrazit nevalidní dokumenty", ale "jak konečně donutit uživatele psát validní dokumenty". a to html5 neřeší. -
zkuste si třeba napsat parser validního xhtml a validního html.
Projekt http://code.google.com/p/html5/ je parserem validniho i nevalidniho HTML a pri letmem pohledu do zdrojaku mi nepripadl zas tolik nerealny, jak se obcas tvrdi. BTW. je to onen parser, ktery Hixie zminuje v rozhovoru ,a ktery u Googlu cas od casu "prechroustava" nejakou tu miliardu dokumentu. Napsat robota, ktery si poradi s dnesnim HTML webem nemuze byt zas tak slozite, navic u tohodle mate vhodnou licenci.
-
Zdenek (neregistrovaný)Resite jine veci, nez o kterych jsem psal. Nemate pravo urcovat vyvojarum prohlizecu jak a co maji programovat. A to nehlede na to jakkoliv jsou vase poznamky pravdive. Pokud mate pocit, ze vyvojari kaslou na ostatni, nemusite jejich prohlizece pouzivat.
zkuste si třeba napsat parser validního xhtml a validního html. který z nich bude jednodušší? Evidentne to neni problem a to dokonce ani pri nevalidnim html ;-)
"přijetí těžko implementovatelné specifikace jen snižuje šance malých hráčů a vede k další monopolizaci (např. googlizaci) internetu." -
Zdenek (neregistrovaný)Jsem to nejak ustrihl :-)
přijetí těžko implementovatelné specifikace jen snižuje šance malých hráčů a vede k další monopolizaci (např. googlizaci) internetu
To mluvite o te tezko implementovane teoreticke specifikaci XHTML2 nebo o realne funkcni implementaci HTML? ;-)
Monopolizace? Kdyz tu mame IE, Operu, Firefox a par dalsich html prohlizecu? -
byF (neregistrovaný)"Nemate pravo urcovat vyvojarum prohlizecu jak a co maji programovat."
Vy jste asi vtipálek. Co myslíte, od čeho tu jsou jakékoli standardy? To bychom mohli zrušit zákony a právní stát. Přece nikdo nemá právo určovat občanům, co mají a nemají dělat.
Kdyby nebylo žádných standardů, Internet by měl krapet jinou podobu, jestli vůbec. Spousta rozdrobených sítí neschopných vzájemné komunikace. -
anonymníPozor! Neplette si dobrovolnou standardizaci soutezicich reseni a narizovani nejakych formatu, pripadne patenty.
To je totez, jako kdyz nekteri prskaji, ze proc openxml, kdyz uz je odf (a ted nediskutuji o kvalitach ani jednoho z nich) a "standard ma byt jen jeden". Ne. Standard slouzi k tomu, aby ten, kdo ho CHCE implementovat a pouzivat, tak mohl relativne snadno udelat. -
anonymníPokud je sto standardu, mate moznost si vybrat ten, ktery se pro vase potreby hodi nejlepe. Delat ale sty standard, pokud jich existuje pro totez jiz 99 je zrejme zbytecne plytvani. Totez by mohlo platit zhruba podle oboru pro cisla nad 3-7.
Prikladu ruznych koexistujicich standardu je mnoho.
Napriklad ethernet zdaleka nebyl sveho casu jedinym standardem pro site (dokonce rozhodne nebyl ani prvnim). PAL neni jedinym standardem pro barevnou televizi... -
"Nemate pravo urcovat vyvojarum prohlizecu jak a co maji programovat."
však to také nedělám. dělají to oni sami tím, že deklarují podporu určitého standardu. podivuji se ale nad tím, že tyto standatdy vytvářejí především výrobci prohlížečů, ačkoliv nejsou jejich nejčastějšími uživateli. nejčastěji přijde do styku s html sám autor stránky nebo nějakého nástroje. vaše věta tedy platí i naopak. -
anonymníProminte, ale pred XHTML2 tu bylo XHTML vychazejici z HTML4 vychazejici z HTML3 (HTML4 hlavne to, co jiz tehdy prakticky existovalo - podpora css, DHTML), ktere vzniklo poskladanim a organizaci toho, co prakticky v te dobe existovalo a bylo implementovano v prohlizecich.
Na rozdil od teoretickeho HTML2, ktere si na oblacku vysnili tehdejsi teoretici, ale nikdo ho v te dome nechtel/nebyl schopen implementovat.
Cili za vyvojem HTML a tim, ze je dnes tim, cim je stoji zejmena vyrobci prohlizecu. -
anonymníkecam, vysnili si HTML 3.0 (vcetne treba tagu MATH) ale nakonec se prevzalo do HTML3.2 to, co aktualne existovalo a bylo implementovano v prohlizecich.
-
anonymnítohle ale rozhodne neni ten nejzasadnejsi problem specifikace html, ze? :)
to si ma ostetrit autor DF
maximalne mu v tom specifikace muze pomoci tak, ze mu umozni pouzit nejakou pokrocilou textareu, kde je mozne pouzivat pouze zlomek elementu a automaticky se kontroluje, jestli jsou pouzity spravne (a i tak to nejspis bude muset osetrit aplikacne aby mu tam nekdo neposilal blaboly primo POSTem) -
Poměrně rozsáhle jsem téma parserů řešili tady http://blog.converter.cz/index.php?p=1242&c=1 a v diskusi pod tímto článkem http://www.lupa.cz/clanky/soumrak-nad-modernim-x/ a jednoznačně je jednodušší napsat parser HTML!
Ano, HTML.
Je třeba si uvědomit, že i tohle http://www.dgx.cz/knowhow/xhtml/ je validní XHTML kód! -
BrainLess (neregistrovaný)Dovolim si nesouhlasit s Hixiem na tema korektne naspanych stranek. Ja nejsem zadnej tvurce webu, udelal jsem par stranek spise pro interni potrebu moji a mych kolegu ale presto jsem vzdy sel na W3C a zvalidoval stranky a chyby opravil, je to na par minut prace. Je to jenom o lenosti !!!!. S timhle pristupem by jsme za chvili mohli rict, 90% lidi nedodrzuje rychlost v obci tak proc to kontrolovat.
-
PaJaSoft (neregistrovaný)Tento clovek mozna "pracoval" u Opera, mozna ma hluboke znalosti (v nejakych oblastech a nepolemizuji o tom), ale jen co jsem docetl k tomu, ze v podstate nevadi neukoncene ci prekryvajici se znacky, tak uz dal cist nemusim...
Za trest bych dotycnemu dal za ukol implementovat alespon jeden renderer toho, co timto zpusobem z HTML udela a to tak, ze neni pripustny chybne renderovany ("pochopeny") kod v zadne z moznych variant, ktere si timto sam (dobrovolne) vytvoril. Bych ho chtel videt frajera... Za vsech okolnosti musi byt vysledek spravny a jeste si dovolim pozadovat aby byl spravny i z hlediska toho, co tvurce takoveho hnusu prave do kodu stranky v HTML zapsal!
Mozna bych pak zacal chapat potrebuje _jednoznacne_ interpretace zapisu... Kam tento volny pristup vedl zazivame do dnes na svych bedrech... o obrovskych zbytecnych investicnich, casovych a lidskych nakladech nemluve. -
anonymníAle on nic takoveho z HTML nedela. Takove proste soucasne HTML je. Viz vysledky toho jeho vyzkumu.
Zbrblani teoretiku, kteri pisou sve semanticke weby v plaintextu a ladi je v lynxu je proste neco uplne jineho, nez realne potreby uzivatelu HTML - tj. autoru prohlizecu a nastroju pro tvorbu webu, tech, co je pouzivaji, tech, co maji sve dokumenty v HTML.
Mimochodem, ale tento volny pristup vedl take k tomu, ze naucit se udelat web (pozdeji dokonce dynamicky) bylo s dostupnymi nastroji tak snadne, ze si ho mohl snadno vytvorit tak velky pocet lidi a instituci, ze se web stal velmi oblibenym.
Psat web je totiz neco jineho, mnohem snadnejsiho, nez programovat. Ze se to nekterym spise programatorsky zalozenym typum nelibi, je jina vec. (mozna trochu zarli, jednak maji radi veci dokonale, predvidatelne a naprosto pod svou kontrolou, a druhak tim, ze to je snadne a zpetne kompatibilni tak trochu prichazeji o potencialni zivnost :)) ) -
uzivatel (neregistrovaný)Ale autori stranok su komercna sfera a ty sleduje svoje zaujmy. Co ma zafrflany teoretik z toho, ze dava svoj volny cas na navrh genialneho projektu a ide mu za to len uznanie a plat na zivobytie ?
Cim si komercna sfera ulahci pracu tym dokaze viac zarobit a o nic viac tejto skupine ani nejde.
Uznavam, ze kopec rozsireni je peknych, ale netreba verit kazdemu ich slovu. Sleduju svoj zisk a nic ine. Pre nich je lepsie robit kazde 3 roky novu "normu", pretoze dokazu na nej zarobit. Urobit nieco raz a poriadne ? Smrt kazdej komercnej firmy. Chyby a nedokonalosti sa robia zamerne z toho dovodu, aby na nich mohli v buducnosti znova zbohantnut.
Preco ste ludia taki slepi a zeriete im vsetko ? -
uzivatel (neregistrovaný)Hmm, este som sa nestretol s tym, ze Apple, Mozilla, Opera a dalsie firmy vytvaruju prehliadace len pre svoje potesenie. Asi mate mozog vymyty marketingom, ale web ponuka obrovske financne moznosti. Co by mali z toho ak by bola poriadna norma, ktora by bola v kazdom prehliadaci rovnaka ? Mimalne prepad obrovskeho financneho toku. Cize asi tak.
Dobre technologie umieraju na ukor penezneho zarobku tych chybnych. -
anonymníNo nevim jestli desktopove webove prohlizece, ktere jsou jiz nejaky cas zadarmo zrovna generuji nejaky velky financni tok :))
Pokud jde vsem jen o zisk a toho dosahuji prodejem nekvalitnich reseni, jakto, ze se v tak svobodnem prostredi jako je software neobjevi nekdo kdo poskytne kvalitni reseni a pokud je lide chteji, musel by je zakonite prevalcovat. Jakto, ze se na tom zverstvu podili i "hodna" komunitni opensource mozilla?
Mozna mam mozek uplne vymyty marketingem (ze by kampan spread firefox?) a je to cele ve skutecnosti jedno velke spiknuti (a nebo jsou nekteri lide prilis paranoidni...) -
uzivatel (neregistrovaný)A ty si myslis, ze ked je nieco zadarmo tak to nevykazuje zisk ?
Pocet %, akym je zastupeny prehliadac su veci akym sa daju vytrieskat peniaze z komercnych spolocnosti na reklame a dalsich vecoch.
Ak si dobre pamatam, tak Opera je jedine pre desktop dostupna zdarma. Safari je jedine pre MacOS, cize reklama na OS. Mozilla vytvorila komercnu spolocnost.
A preco sa nespravi nejaky lepsi prehliadac ? Pretoze to zaberie minimalne 2 roky prace kym sa zabezpeci kompatibilita a aka taka podpora pre starsie stranky. Uz vidim ako to niekto robi zadarmo. Nic take neexistuje. Internet je neskutocny zdroj penez. Kto si ukroji skor z toho trhu, aj ked prvotne zdarma tak ziska v buducnosti moznost na tom neskutocne zarobit.
Vsetky tieto spomenute spolocnosti su clenmi W3C a maju v nich velke zastupenie a rozhodovacie pravo, prave z toho, ze su tvorcami prehliadacov. Ak by chceli tak by dokazali hociktoru "normu" upravit na pouzitelnejsiu uroven. Ale ak sa odpojili a vytvorili docasnu nahradu tak to niecim smrdi. -
anonymníProsim? Na reklame? A jakych dalsich vecech?
Ona se vam v prohlizeci zobrazuje reklama? :) Nebo pocitate, se prodavaji pozice v defaultnich bookmarkach? A ze to zaplati vyvoj browseru? :))
Opera mini je uz urcite taky zdarma. Za operu embedded plati ten, kdo chce to reseni zabudovat do sveho produktu, coz je prirozene.
Safari je reklama na OS? :)) No spis to bude tim, ze desktopovy OS pro ktery neexistuje browser je proste dnes nemozny. To je jako tvrdit, ze MSIE je reklama na Windows :))
No zadarmo to delaji treba tvurci open source projektu :) Jmenovite firefoxu, (e)linksu, lynxu, ...
:) takze oni se odpojili sami od sebe? :))
vazne nebudte paranoidni...cele HTML vzniklo zejmena pod taktovkou tvurcu prohlizecu (a je to logicke - pokud neco neni implementovano, neni to pouzitelne) -
uzivatel (neregistrovaný)Povedzte mi ake spolocnosti su v tejto skupine presadzujuce HTML5. Stale sa hovori o Mozille, Opere a Apple (Safari). Vydite tam nejake dalsie ? Cim to bude, ze prave tieto tri skupiny okrem MSIE maju najvacsie zastupenie na trhu ?
Ako som uz spomenul hore, internet je velka zlata bana, ktora je takmer nevycerpatelna. Vsetky tri spolocnosti patria do komercneho segmentu aj ked niektory z nich tvoria open-source.
Ano ja viem, ze HTML vzniklo najma pod taktovkou prehliadacov, ale internet sa zmenil. Bud to nevidite vy alebo ja zijem vo svete bez klamstva a mozem verit kazdemu co povie. -
anonymníNo vzdyt samozrejme. Apple, Mozilla, Opera a Microsoft (ktery tusim ohlasil, ze se take pripoji) maji na 'trhu' prohlizecu snad 99.9%. A pokud se bavime o webu (a o webu pro uzivatele jak prohlizejici, tak publikujici), tak jde tu preci PREDEVSIM o prohlizece a o to, co budou umet.
Kdo jiny by mel mluvit do toho, co maji prohlizece umet, nez ti, kteri je dlouha leta uspesne vytvareji? Ti, kteri znaji pozadavky svych zakazniku.
Mimochodem z druhe strany je tam Google, ktery to s webovymi aplikacemi jiste mysli vazne, a vyvijet neco jako google office pod stavajicimi nevyhovujicimi a zastaralymi technologiemi je proste extremne nakladne. Rekl bych, ze vsichni dost dlouho cekali, co z W3C vypadne. Nevypadlo nic (resp. nic co by prinaselo pozadovanou funkcionalitu).
Bojite se, ze tim chteji zabranit nekomu dalsimu ve vstupu na svuj trh? A on je na obzoru nekdo takovy? Nekdo, kdo dosud nevstoupil a chysta se tak udelat? Vstoupit na trh, kde je jeden dominantni hrac se 70-80% podílem a hlavne, kde produkt je zadarmo? A jak tomu nekomu (minimalne jiz asi clenovi W3C) zabrani? Specifikace HTML5 bude jiste verejna a bez patentu. Leda by uz mel ten nekdo implementovano XHTML2 (ale ne HTML4??) a ted by prisel o sve investice do teto implementace. Znate nekoho takoveho? Tezko muze mit ale asi implementovano neco, co jeste oficialne neexistuje a kdyz, tak musi takovy hypoteticky subjekt pocitat s tim, ze to je risk.
Ano internet se zmenil a W3C na tuto zmenu naprosto nereagovalo. -
anonymníVykazovat zisk neni spatne. Neni to dokonce ani nemoralni.
Intel i AMD, na jejichz procesorech bezi vas opensource vykazuji zisk. Ti, kteri vam vyrobili vsechny ty polovodice a i plech na CASE vykazuji zisk. Vas pekar vykazuje zisk. Proc by zisk nemohly vykazovat SW firmy?
Porad netusim, cim jina nez W3C (mimochodem W3C tvori take firmy, ktere vykazuji zisk) specifikace nekoho omezovala. -
uzivatel (neregistrovaný)Samozrejme ze nepracujem. Ale nemam "mocenske" zaujmy. Ale kedze robim projekty aj pre komercnu sferu tak sa snazim za honorar, ktory dostavam, vykonat co najlepsiu pracu s pouzitymi najlepsimi technologiami, co je vyhoda ja pre mna, pretoze sa zdokonalujem. Robim veci co najjednoduchsie na spracovanie s univarzalnym nadychom, aby sa za urcite obdobie dali tieto veci rozsirit/upravit lahkym sposobom.
-
anonymníAno opravdu nechapu, jaky je vas postoj. Zatim tu podle mne pouze pisete "objevna" tvrzeni o tom, ze komercni subjekty tvori zisk a lehce paranoidni naznaky o tom, ze neimplementace XHTML2 a vyvoj noveho standardu (X)HTML5 ma vest k nejakemu monopolu nebo oligopolu a zrejme nejak prudce zmenit situaci na trhu prohlizecu nebo dokonce operacnich systemu oproti soucasnemu stavu.
Cili mate pocit, ze pokus o alternativu k XHTML2, ktere je (nejen) z jejich pohledu objektivne nevyhovujici a neprinasi dlouho pozadovane vlastnosti (nebo snad ano?) je pouze velky komplot s cilem na ukor nekoho (koho?) nemravne vydelat vetsi mnozstvi penez? -
uzivatel (neregistrovaný)Ak ste citali aj dalsie moje komentare nemam chut a nepresadzujem implementaciu XHTML 2.0. Chcem sucet HTML 5 a XHTML 2, ale to asi nebude mozne, pretoze si z dvoch moznosti vyberam nieco co moze mat svetlejsiu buducnost.
A dalej nemusim uz komentovat. Pochopit ma nechcete a mozno ani neviete, tak je zbytocne o tom dalej hovorit. -
anonymnía jak by takovy idealni soucet (nebo spis prunik?) mel vypadat v nasledujicich oblastech?
- kompatibilita s HTML4
- XML syntaxe (uplna, zjednodusena xml-like, volna)
- modularita
- nova funkcionalita (formulare a UI webaplikaci, video, grafika, ...)
- oddeleni semantickych znacek pro text a jinych (polo)semantickych znacek pro design designu
- existujici imlplementace v browserech
pripadne co konkretne vam vadi na stavajicich verzich navrhu XHTML2 a co na HTML5 -
Keson (neregistrovaný)Chtěl bych položit otázku lidem, kteří trochu vidí do vývoje (majoritních) prohlížečů. Proč neudělat tu "tlustou čáru", tedy nevyžadovat striktní kód u nového (X)HTML?
Výhody jsou, myslím, zřejmé: snadnější psaní webů, které půjdou zobrazit všude, snadnější psaní aplikací, které HTML zpracovávají.
Jak psal p. Neubauer,- hlavním autorem není koncový uživatel, ale programátor blogu/rs/editoru.
- hlavním klientem nejsou, nebo výhledově nebudou prohlížeče.
- základním problémem webu není "jak zobrazit nevalidní dokumenty", ale "jak konečně donutit uživatele psát validní dokumenty".
- Je snad výrazně složitější napsat parser pro (X)HTML5, který v sobě nebude mít "tag soup" heuristiku, než rozšířit současný "heuristický" parser o nové vlastnosti?
- Nebo se výrobci majoritních browserů nedokáží dohodnout, aby žádný browser nekorektní X/HTML5 nezobrazoval?
- Nebo je tak složité mít přidat do prohlížeče k těm současným (aby fungoval dnešní webový guláš) další striknější mód?
- Nebo prostě jen nepovažují současný stav za tak špatný? (kód, co jakš-takš zvládne zobrazit současné web stránky, už pčeci existuje, tak o co jde, že?)
-
anonymníhlavnim autorem _muze_ byt i (zkusenejsi) koncovy uzivatel, pokud toto vypustime, dosteneme se s XHTML nekam, kam se dostalo XMLSchema, ktere je pro cloveka neco naprosto neprehledneho (oproti treba relax-ng)
i pro toho programatora nastroje pro tvorbu webu je snazsi, kdyz je specifikace co nejjednoduzsi a prakticka
Hlavnim klientem jsou desktopove prohlizece. Pokusy s alternativnimi nonHTML technologiemi pro snadnejsi zpracovani se prilis nuchytily (jako wap& wml) a na ruznych jinych zarizenich (PDA, mobily, herni konozle...) se s rustem jejich vykonu spise priklanime k implementaci nejake jednoduzsi verze desktopovych prohlizecu
Pokud je 70-90 % aktualnich dokumentu nevalidnich, pak otazkou pak jak zobrazit nevalidni dokumenty je jiste velkym problemem.
--------------
1) jestli je slozitejsi pridat vlasnosti do neceho, do ceho se poslednich X let pridavaly vlasnosti, nez napsat neco uplne noveho, do ceho se dalsich X let budou pridavat dalsi vlastnosti?
2) pokud nektery browser nebude zobrazovat nekorektni xhtml (ktere existuje a existovat nejsbis v nejake mire bude), pak ho bud uzivatele nebudou pouzivat (pokud je minoritni) nebo tvurci nebudou pouzivat xhtml (pokud je majoritni)
3) a pak jeste jeden a jeste jeden a pak nejaky dalsi, ktery bude opravovat to, ze nekdo posila jinou hlavicku, nez ma mit dle specifikace (jako application/xhtml+xml) a pak je vsechny udrzovat, ladit a vyvijet...
4) ano soucasny stav neni ani zdaleka tak spatny, jako byval v dobach MSIE4 a 5, MS tehdy silene dohanel sve zaspani na webu a odstavil ostatni prohlizecem zdarma a nalakal spouty lidi na vlastni implementaci DHTML. Potom zase usnul a ostatni se prizpusibili, dohnali ho a predehnali v novych a pozadovanych webovych technologiich.
Temer vsechny prohlizece dnes drtivou vetsinu webu zobrazi pomerne dobre, nyni je hlavnim problemem to, ze HTML neni delano pro aplikace a v soucasnosti se masivne nasazuje prave jako aplikacni rozhrani. Po dlouhem cekani na to, co vypadne v teto oblasti z W3C (vypadlo nekompatiblni XHTML2 s minimem novych vlastnosti, ale za to krystalicky cistym navrhem = zacit psat sve prohlizece a nastroje temer znovu aniz budou mit nove funkce) se do toho proste vlozili prakticky. -
Franta (neregistrovaný)"Pokud je 70-90 % aktualnich dokumentu nevalidnich, pak otazkou pak jak zobrazit nevalidni dokumenty je jiste velkym problemem.
"
Proč by to proboha měl být problém??? Pro staré HTML přece už existují staré parsery. Pro nové (X)HTML napíšeme nový parser, resp. obohatíme stávající XML/XHTML a zobrazovač o nové funkce. Staré ničemné HTML se postupem času přestane používat a po nějaké době bude možné z prohlížečů vyřadit starý parser. Stejně jako dnes už nemusíme kupovat kazeťáky, stačí nám CD přehrávače. -
a) Nepsalo by se to současně. HTML by se prostě zmrazilo, maximálně by se opravovaly chyby, a rozvíjel by se pouze nový parser/vykreslovač. A kdo by dělal nové stránky a chtěl nové funkce, tak by prostě použil modernější XHTML.
b) Cena konverze? Znáš HTML Tidy? (http://www.w3.org/People/Raggett/tidy/) Staré stránky jde převádět automatizovaně a zcela bezpracně. V principu to není složité, protože WWW prohlížeč musí HTML kód načíst a nějak interpretovat, aby ho mohl zobrazit, a z této interpretace se dá odvodit čistý XHTML kód. Další důležitá věc je, že největší význam mají aktuální informace. -
anonymnía) ano to by sice bylo idealni reseni (podobne jako se design prenesl na css - stale muzete psat element font, ale pokud chcete pokrocile formatovani prejdete na css) jenomze problem XHTML2 je v tom, ze ty nove funkce a tedy motivace pro prechod tam proste nejsou.
b) mozna to je snadne lokalne, ale kdo bude tohle delat u vsech webu vsech instituci a jednotlivcu? kdo jim bude psat ty automatizovane skripty pro prevod vseho pres htmltidy? co s temi miliony automaticky generovanych dokumentu (ktere nedejboze navic nemaji oddelene sablony) kdo bude prepisovat treba ty prasacke javascripty s document.write a pochybnym pristupem k elementum, ktere ale v soucasnosti funguji a v XHTML2 proste nemuzou. S tim si za htmltidy asi neporadi. Ne kazdy cisty (X)HTML dokument na vystupu je totiz cistym XHTML i dokumentem na vstupu.
Aktualni (nove) informace maji vetsi vyznam nez neaktualni (stare) pouze v pripade, ze se s casem neco zmenilo na jejich aktualnosti :) Kdy se narodila Queen Elizabeth II muze byt dulezite, ale asi nikdo nebude mit motivaci to psat znova - aktualne :) Stejne tak napriklad popisy algoritmu -
1. Samo o sobě to není až tak složité, ale málo věcí v prohlížečích funguje samostatně, vše je provázané. To je při implementaci předpokládám největší problém.
2. Nedokáží, není to pro ně výhodné. Viz teorie her a vězňovo dilema.
3. Ano, je. Zvyšuje to složitost kódu, náklady na jeho údžbu, atd. A proč by výrobce prohlížeče měl investovat do nového módu/parseru, když bude použitelný pro mizivé procento obsahu webu, zatímco konkurence bude místo toho vynakládat prostředky na funcke přímo užitečné pro uživatele a zvyšující podíl jejich prohlížeče?
4. Nejde o to, zda je stav špatný nebo dobrý, ale o to, že se těžko ve velkém změní. -
Ad 3) Pokud bude můj prohlížeč jako jediný schpný zobrazit novou internetovou stránku se skvělým obsahem a zároveň zobrazí i všechny ostatní, budou na něj uživatelé masově přecházet. Takže pro vývojáře prohlížeče nový parser smysl má. Musí ale přinést nějakou praktickou novinku pro uživatele stránek.
-
Přesně tak...
Celý (stále dokola omílaný) problém současného Webu podle mě vychází z absence podpory XHTML v MSIE...Dokud Microsoft nepřestane ignorovat jeho existenci, není podle mě valná šance na jakoukoli technologickou změnu...Protože kdokoli se v současnosti rozhodne držet krok s dobou a používat mnohem snadněji validovatelný a parsovatelný XMLkový formát, musí chtě nechtě poskytnout ještě text/html verzi pro těch 50% uživatelů, používajících IE (jasně, podpora XHTML v KHTML má také do dokonalosti daleko, ale KHTML jednak webem nehýbe, a jednak kdyby se XHTML masově začalo používat, dopsání podpory by na sebe nenechalo dlouho čekat)...
Jen si představte ten krásný okamžik, kdy IE konečně zavede XHTML a celý svět bude moci přestat se schizofrenií HTML/XHTML...HTML zůstane jen ve starých (a tím pádem odumírajících) webech a po několika letech bude moci být jeho podpora z prohlížečů zcela vyřazena...Možná utopie, ale to záleží na pánech v Redmondu... -
anonymníWeb a HTML se ale nepouziva kvuli validaci ale kvuli tomu, co na jeho zaklade zobrazuji prohlizece. XHTML2 skutecne vypada, ze jeho cilem je pokrocila validace (a to i nekolika ruznych modulu s ruznymi schematy v jednom dokumentu).
A parsovani XML se vsemi jeho zaludnostmi neni zase tak snadne, jak by se mohlo zdat.
Tech lidi s MSIE je porad jeste urcite vic nez 50% :)
A ted myslite tim XHTML kterou verzi? 1 nebo 2? -
Já ale netvrdím, že se HTML používá k validaci...Jde jen o to, že parsování XML je (i "se všemi jeho záludnostmi") poměrně jednoduchá práce - XML jasně stanovuje logickou strukturu a například libxml2 je pro někoho až překvapivě jednoduchá...Nejsou totiž potřeba žádné komplikované heuristiky pro odhadování "co chtěl tímhle básník říci"...Zkrátka např. překřížené elementy <=> chybný kód...Jakékoli XML prostě rozparsujete jednoduše rekurzivně stylem (pokud pro jednoduchost opomenu parsování DOCTYPE a podobně):
0) dokud nenarazím na "<", jedná se o text, kterým prostě plním aktuální element
1) detekuji "<" == začátek elementu
2) název elementu - pokud obsahuje ":", má určenou NS
3) dále dokud nenarazím na ">" nebo "/>": mezerou oddělené atributy, každý rozseknu na znaku "=" na název a hodnotu
4) pokud nebyla detekována sekvence "/>", následuje obsah elementu...na něj zavolám rekurzivně tuto parsovací funkci, konec obsahu poznám podle "</název_elementu>"
5) skok zpět na 0
-pokud cokoli nesedí, není kód well-formed XML a nebudeme se jím zabývat
Možná se tím někoho dotknu, ale podle mě jednoduchý XML parser napíše kdokoli, kdo má alespoň primitivní znalosti jakéhokoli programovacího jazyka...Narozdíl od toho HTML parser je monstrum (téměř) s umělou inteligencí, nebo minimálně tisíci podmínek pro "detekován ten a ten prohřešek proti specifikaci => uděláme to tak, jak to dělá konkurence, případně tak, jak zrovna programátora parseru napadlo"...
Uživatelů MSIE je víc než 50%, uznávám, že tady jsem lehce zjednodušoval...Podle statistik jednoho mnou spravovaného webu asi MSIE všech verzí používá cca 54% návštěvníků, dále následuje Firefox s 35% a Opera s 9%...
Tím XHTML myslím jak první, tak i druhou verzi...Implementace druhé verze je trochu běh na delší trať, ale XHTML 1.1 se dá implementovat snadno (na základech HTML 4.01) a přechod mezi verzemi XHTML nedá zdaleka tolik práce, jako přechod mezi verzemi HTML... -
anonymníHm ale takhle jednoduche to parsovani opravdu neni. Pokud by bylo, tak neni az takovy problem, ale XML je o dost slozitejsi, nez se na prvni pohled zda.
Doctype je ale v XML vemi dulezite (podle ceho jineho chcete validovat nez podle DTD, pripadne jak jinak poznat co to je vubec za dokument nez pomoci identifikatoru) a navic muze obsahovat vlastni entity!
Nejak jste pritom zapomnel prave na entity (interni, externi, parametricke) a to muze byt poradny humus (v entitach mohou byt take znacky).
Atributy mohou obsahovat take znaky mezera a = a mohou byt oddeleny stridave apostrofy i uvozovkami a obsahovat tytez znaky odescapovane. A oo teprve blok CDATA, ktery muze obsahovat temer cokoliv. A to nejsem zadny XML guru a spousta zaludnosti mne ani nenapadlo.
HTML prece take definuje, jak se ma pracovat s neuzavrenymi tagy, ktere smeji byt neuzavreny a ktere ne. Ty, ktere jsou neuzavrene spravne neni potreba nijak odhadovat a ty, ktere jsou uzavreny spatne nejsou well-formed HTML :) Ze nektere prohlizece nejak prectou i non-well-formed HTML prece neni chyba specifikace HTML :)
Vami spravovany web, odhaduji, bude nejak technologicky specializovany tj. ne obecny web, ktery navstevuje vetsinova populace cili ta cisla jsou v techto pripadech obecne u MSIE nizsi, ale to je jedno. -
V žádném případě jsem nechtěl nějak snižovat význam DOCTYPE deklarací a entit, ale tohle všechno jsou vlastnosti SGML, takže stejné pro HTML i XML...Parsování řetězců je zase velmi jednoduchá operace (zapamatuji si, jaká uvozovka byla na začátku a hledám druhou stejnou, přičemž escape sekvence přeskakuji)...CDATA se neparsují dokonce vůbec...(Dobře, máme ještě PCDATA, ale to není o moc víc práce)...
Každopádně na HTML je nutno vždy mít speciální parser, kdežto na XHTML stačí jeden univerzální XML...Speciální parser pro HTML je třeba např. kvůli tomu, že některé elementy mohou být jak jednodílné, tak i dvoudílné (např. element IMG)...V případě XML je věc jasná, ale u HTML z otevíracího tagu parser nemá šanci poznat, jestli následující data jsou obsah elementu IMG, nebo elementu rodičovského...
Zmiňovaný web navštěvují převážně studenti středních škol, o nichž nepředpokládám, že by byli nějak významně "osvícení"... -
anonymníTo neni az tak jednoduche. HTML je velmi omezena podmnozina SGML. V HTML, pokud se nemylim, nemate moznost definice vlastnich entit. XHTML je kompletni implementace XML (coz je o neco vetsi podmnozina SGML) a tam vlastni entity definovat muzete.
V XML mohou byt take neparove tagy, cili s ni mi musite v parseru pocitat. Konkretne IMG nesmi mit v HTML4 koncovy tag, podobne i jine. Nezamenujte pomerne jasnou specifkaci HTML s tim, v jak prasacke podobe se HTML mozna muze nekde taky vyskytovat a prohlizece ho i tak prectou.
Ale opet: problem neni v tom, ze by neexistoval vyhovujici parser HTML - pokud pouzivate libovolny prohlizec, mate HTML parser a to dokonce takovy, ktery toleruje velkou cast chyb. -
Omlouvám se za drobný přehmat, ohledně toho IMG máte pravdu, jako vhodný příklad elementu, který může být v HTML 4.01 párový i nepárový jsem měl zvolit spíše element P...V XML mohou být také nepárové tagy, ale jsou snadno rozpoznatelné podle syntaxe <tag/>...
V HTML skutečně nemáte možnost definovat vlastní entity, čili další plus pro XHTML... -
anonymní
No plus mozna pro uzivatele (i kdyz v dobe dynamicky generovaneho webu rozhodne nijak vyznamne plus). Zato ale poradne minus pro implementatora parseru.
S P neni v HTML problem. Staci k tomu dve veticky ve specifikaci:
The P element represents a paragraph. It cannot contain block-level elements (including P itself). We discourage authors from using empty P elements. User agents should ignore empty P elements.
Tedy P konci bud koncovym tagem, nebo pred pocatecnim tagem prvniho nasledujiciho blokoveho tagu (vcetne P). -
anonymníA i kdyby se XML parsovalo snadneji, co to meni na tom, ze XHTML2 neresi ty soucasne pozadovane funkce?
Neni problem v tom, ze by neexistovaly parsery HTML nebo ze by byly pomale a nespolehlive - kazdy prohlizec ho v sobe jiz samozrejme ma.
A musel by ho mit i nadale - drtiva vetsina webu neni (a v dohledne dobe nebude) v XML. Forma XML sama o sobe neni ani nahodou vyhoda, pokud nenabizi nic dalsiho. Pokud chci psat web v cistem XML, muzu pouzit XHTML1.
Nejde o to napsat primitivni XML parser, ale kdyz uz tak parser XML podle specifikace. A to zase tak primitivni neni. I proto se na cteni XML pouzivaji standardizovane (a ne zrovna primitivni) knihovny a nikdo se s tim nepise sam. -
Jedna věc je obsah specifikace, navrhované elementy a podobně, kdežto celková filozofie je věc druhá...XHTML2 je stejně jako XHTML1 pokus zavést konečně řád do současného (s odpuštěním) bordelu...To mi právě přijde nejhorší, že WHATWG si místo konstruktivní diskuze o tom, co by mělo být v novém (a perspektivním) XML-based webu, vytvoří vlastního "následovníka" starého chaotického systému; aneb "provizorium fungovalo doteď, proč by nemohlo fungovat dál, stačí přisypat pár funkcí"...
Forma XML je sama o sobě zásadní výhoda třeba kvůli XSLT transformacím...
Rozhodně jsem neměl v úmyslu navrhovat tady parser, jen jsem chtěl ukázat, jak důležité je mít jasně stanovená jednoduchá pravidla... -
anonymníJaky je ten soucasny chaoticky bordel v HTML4 a XHTML1? Co je v tech specifikacich spatneho? Nebo je spatne to, ze prohlizece vetsinou celkem dobre prectou i to, co presne neodpovida specifikaci?
Web neni perspektivni tim, jakou ma filosofii (zvlaste pokud ta neni sdilena jeho uzivateli - tj. tvurci webu, tvurci prohlizecu, tvurci nastroju...), ale tim, co poskytuje za funkcionalitu.
Pokud chcete pracovat s XML na webu, mate tu XHTML1. XSLT chcete pouzivat na zobrazovani nebo zpracovani webu? Pokud na zobrazeni, pak nepotrebujete XHTML - vystup XSLT nemusi byt XML. Vstup ano, ale ten nemusi byt 'vseobecne' XHTML2, ale libovolne XML, ktere se transformuje pomoci specifickeho XSLT stylu do ceho chcete. Neco jineho je, pokud chcete obsah webu pomoci XSLT prevadet na neco jineho. Popravde nedovedu si ted predstavit moc na co, ale prosim i tak vam ale staci XHTML1.
Ale opakuji - moje vyhrady vuci XHTML2 nejsou ani nahodou vuci XML syntaxi. XML syntaxi melo uz XHTML1. Vyhrady jsou proti tomu, ze to je nekompatibilni a ze to je zbytecne slozite aniz to prinasi novou (pozadovanou) funkcionalitu. Tvari se, jako by web slouzil porad pouze k publikovani dlouhych vedeckych textovych dokumentu. Web ale uz dela dost dlouho hlavne neco jineho. Objevuji se fora, diskuse, multimedia, rozhrani k pomerne komplikovanym aplikacim...
XHTML2 proste zaspalo dobu a neodpovida pozadavkum soucasneho webu. -
Narozdíl od toho HTML parser je monstrum
Kdyz jsem se dival na zdrojaky plneho HTML parseru http://code.google.com/p/html5/, tak jsem mel pocit ze to o slozitosti HTML parseru bude nejaka poradne rozlezla fama. Stahnete si to a presvedcte se sami. -
aha utekl mi odkaz, mate pravdu, spravne to je http://code.google.com/p/html5lib/. Co vam na tomhle parseru pripada slozite? (odmyslim profilovaci a podobne funkce, ktere jsou soucasti proto, ze se pouzivani pro testovani implementace).
-
Složité mi připadá to, že každý HTML parser musí obsahovat logiku dané specifikace HTML (aby dokázal rozhodnout, kdy má např. čekat u nějakého elementu obsah). Pokud nahlédnete do kódu, přesvědčíte se sám, že je dočista prošpikován názvy jednotlivých elementů a odkazy na HTML5 specifikaci. Naproti tomu XHTML (resp. XML) parser nemusí o tom, co vlastně parsuje, vědět vůbec nic; stačí mu základní pravidla XML.
-
Specificka prace s elementy tam jiste je, ale ani to zdaleka tak strasne, jak se v kritikach html parseru dozvidame. Pokud se na to divam metodou neco za neco, tak bych si stale vybral o neco slozitejsi parser, ktery dokaze zpracovat >90% soucasneho webu, nez nedokonaly xml parser (stale vynechavame validaci apod.), ktery si poradi s ... rekneme nekolika malo procenty?
Desiva vypraveni o slozitosti HTML parseru a obtiznosti kohokoliv zapojit se do trhu webovych prohlizeci mi pri pohledu na dvoutisiceradkovy kod zakladni tridy (vynechavam tokenizer a veci okolo, jeste bychom tak jednu tisisovku nasbirali) pripadaji jako zbytecny mytus. -
anonymníNerad bych se mylil, zas tak do toho nevidim, ale osobne bych povazoval parser za jednu z nejsnadnejsich casti takoveho zgruntu psaneho prohlizece.
Mnohem vetsi problem bych videl v implementaci (ne parsovani ale korektnim vykreslovani a zpracovani) takovych lahudek jako vsemozne CSS, DOM a JS lahudky.
Tedy textovy (nebo i podporujici pouze staticke primitivni formatovani na urovni HTML3) prohlizec (tj. hlavne parsovani (X)HTML) povazuji za ulohu minimalne radove jednoduzsi, nez plnohodnotny HTML4 (pripadne XHTML1 i 2) browser s podporou CSS2 prip. 3, standardniho JS...
Navic pokud by kdokoliv chtel v nejblizsich peti letech vstupovat na trh prohlizecu, odhaduji, ze by stejne musel implementovat krome XHTML2 i predchozi standardy aby se uchytil. -
Tou složitostí jsem neměl na mysli objem kódu, ale spíše provázanost parseru se specifikací a tím jeho komplikovanou správu...
XHTML od 1.1 přináší jednolitou platformu pro další vývoj...Verze 2 k tomu přidává něco nové funkčnosti (a pokud někomu pořád něco schází, měl by se tento problém řešit přidáváním modulů/elementů XHTML a ne smetením slibné platformy se stolu a návratem k prehistorii zvané HTML)...
Variantou by mohlo být XHTML5, ale...Sami autoři dávají najevo, jaký mají názor na každého, kdo používá XML větou (cituji z HTML5 specifikace) "Generally speaking, authors are discouraged from trying to use XML on the Web, because XML has much stricter syntax rules than the "HTML5" variant described above, and is relatively newer and therefore less mature."...Aneb "lepší kontrolu správnosti kódu přece nikdo nechce; všichni píšou radši prasečiny a tak to má být"... -
Ano, v rozhovoru se v té souvislosti píše "Někteří lidé budou XML s HTML5 používat, ať už uděláme cokoliv.", z čehož mi vstávají vlasy hrůzou...Možná se pletu, ale já z toho prostě cítím averzi k pokroku ve formě XML...Pokud se v nějaké specifikaci objevuje něco takovéhleho, tak třeba mě osobně to zcela odrazuje od jejího používání kvůli obavě, že v další verzi se může autor rozhodnout podporu XML zcela zrušit...
-
anonymníNo prominte, ale HTML5 je nasledovnikem HTML4 a je zpetne kompatibilni minimalne az k HTML3.2 a v principu i dale. Nedovedu si moc v praxi predstavit to zruseni podpory XML.
Nekompatibilni tu je XHTML2. To mi nahani mnohem vetsi obavy, pokud uvazim, ze pro XHTML3 se muze zase kdosi rozhodnout, ze filosofie XHTML2 neni az tak skvela a mohlo by byt super ji konecne vyresit a zgruntu predelat.
Averzi vuci XML a vsemu X vidim spise v tom, ze W3C cca od roku 2000 hlasala neco ve smyslu, ze XML spasi web a vrhla se snad na desitky X jazyku zalozenych na XML. V praxi se snad ujalo jenom RSS a to jeste pro neco trochu jineho nez bylo puvodne urceno a, pokud se nemylim, tak ne az tak uplne v rezii W3C.
Nedokazu si vzpomenout na zadnou jinou X technologii, ktera by se za 7 a vice let na webu ujala. (Myslim na beznem uzivatelskem webu, ale ani webservices nejsou az takovy hit i kdyz se v konercni sfere obcas pouzivaji.) -
anonymníNapsat nevalidujici xml parser nemusi byt az tak obtizne, ale validujici xml parser je hodne slozita zalezitost (uz kvuli parsovani DTD atd. - ostatne prectete si http://www.w3.org/TR/2006/REC-xml-20060816/).
-
anonymníPokud chcete korektne zpracovavat XML (tedy XHTML2), musite zpracovat i DTD (kvuli entitam). Pokud chcete zpracovavat XHTML univerzalnim XML parserem, pak ten by mel byt zrejme co nejlepsi a nejkompletnejsi. Mel by asi umet validovat ruzne casti (moduly) pouzite nebo vlozene do XHTML2 relativne nezavisle (tj. rozpoznat, ze HTML je OK, ale chyba ('logicka' tedy je to well-formed) je ve formulari v XForms, nebo v SVG, nebo v nejakem z tech mnoha X jazyku, ktere zrovna pouzivate).
Specialni HTML parser v browseru validaci nepotrebuje. Jak jste psal vyse, ma kompletni logiku toho jazyka integrovanu v sobe (pripadne ve svych modulech). To neni az tak na skodu, protoze stejne ji tam musi mit na nejake urovni kvuli spravne reprezentaci znacek. -
To, že by měl být parser co nejuniverzálnější, je svatá pravda. V tom tkví právě hlavní výhoda XHTML - XML parser nemusí vědět vůbec nic o tom, co parsuje, stačí mu znalost základní syntaxe "nadjazyka" (XML)...Pokud má jít o validující parser, potřebuje ještě přístup ke schématům (nebo RELAX NG, pokud je někdo preferuje), ale tím to končí...Výhody jsou snad zřejmé - snadná správa a rozšiřitelnost + prohlížeči stačí jeden parser na všechno...Právě ve vkládání XForms, SVG, XUL nebo MathML (pokud by bylo XMLizováno) vidím hlavní přínos XHTML...Přináší modularitu a rozšiřitelnost a jako bonus i snadněji zpracovatelné dokumenty...
Naproti tomu HTML (a zvláště navrhované HTML5, v jehož specifikaci je dokonce výslovně zmíněno, že vyžaduje speciální parsování) se nedá zpracovávat jinak, než jednoúčelovým parserem...To s sebou přináší ztrátu modularity tím, že se do specifikace "natvrdo" začleňuje např. formulářová funkčnost; a problematickou rozšiřitelnost - na všechno "nové" potřebujete upravit specifikaci, zavést speciální element a upravit všechny existující parsery...Zkrátka a dobře, základní pravidla softwarového návrhu dostávají značně na frak, když je celá specifikace natvrdo zakódována v parseru... -
anonymníHTML hlavne bylo a je uspesne proto, ze bylo vzdy zpetne kompatibilni, proto, ze bylo vyvijeno vicemene soucasne s jeho implementaci v hlavnich prohlizecich (resp. dokonce trochu pomaleji - ano nejdriv byl bordel a spousta novinek, pak standardizace nekterych a pak se dohanelo to, kdo co nemel).
To take souvisi s tim, proc je podporovano vsude. -
Vzpomnel jsem si na clanek Petra Cimpricha o jmennych prostorech Úskalí XML (2). Rekl bych, ze jejich spravna aplikace xml parsovani jeste zkomplikuje.
-
anonymníNe nepovazuji. Jasna pravidla existuji (specifikace HTML4 a XHTML1).
Nektere prohlizece jsou benevolentnejsi a toleruji (ne nuti k) prekroceni techto pravidel.
Obsah webu se na klientske strane nezpracovava pomoci XSLT ale renderovacim modulem prohlizece. XSLT muzete pouzit na libovolne XML (tedy nejen na XHTML2, ale i na XHTML1 a jakekoliv jine).
XHTML2 dopadne jako dopadlo HTML3.0 - specifikace, ktera byla mc ambiciozni a nikdo ji nechtel implementovat. Rozdil je ale v tom, ze HTML3.0 obsahovalo na svou dobu az moc funkci (vcetne treba tech pro zapis matematickych vzorcu), ale XHTML2 obsahuje na svou dobu naproste minimum funkci.
Tahle diskuse je treba v XHTML1, ale nevim, jestli je snadno zpracovatelna pres XSLT - je tvorena zmeti DIVu a SPANu. Pro zobrazeni to je jedno (a bylo by uplne stejne, pokud by byla v HTML4). Pro zpracovani temer take - pokud budu chtit zpracovat obecne diskusi, nepovede se mi to. Budu muset pro kazdy web napsat vlastni XSLT styl. To nejsou jasna pravidla. To neni semanticke. -
Trained.Monkey (neregistrovaný)Predstavte si jednoduchy aplikacni protokol. Hoodne 'programatoru' + 'vyvojaru' by bylo bez prace a nedej boze by se vrhli na Javu.
Takze hodne stesti s HTML5, pokud mozno preju i HTML 6 a 7. Nez se to hovno rozlezi a web objevi zakladni programovaci veci, budou ostatni technologie zase o par generaci dal.
Jo, delam klienty v Jave :-) -
anonymníNerad bych se mylil, ale nebylo by v takovem vami popisovanem pripade mozne ty vyvojare propusit a s mensim poctem udelat vic prace?
Nevydelalo by se vic tech prachu? Mene zamestnancu=mensi naklady. Rychlejsi a snadnejsi vyvoj=mensi naklady a kvalitnejsi prace.
A stoji zakaznika vic php koder/HTML designer nebo ten, "kdo dela klienty v Jave"? :)) -
Ondřej Tůma (neregistrovaný)je sice hezke prirovnavat vyvoj webu k vyvoji v hudebnim prumyslu, ale jaksi autor tohoto prirovnani zapomina, ze takove gramofonove desky se ne jen stale pouzivaji ale i stale vyrabeji. A to predevsim kuli jejich kvalite, ano uz to neni zalezitost masoveho trhu, ale profesionalni uziti ale je to tak.
Bez ohledu na to, jaky je HTML paskvil, a jaky prasata ho pouzivaji ke sve prezentaci, porad bude XML tou gramofonovou deskou, ktera je proste diky sve kvalite k profesionalnimu uziti nezbytna. -
anonymníTed nevim jestli jsem spravne pochopil ten prispevek, to HTML a XML mne nejak zmatlo.
Bavime se tu o masovem webu, nebo nejakych internich freameworcich pro velmi uzce specializovane intranety? (a i tam bych pochyboval, ze pobezi na XHTML a ne na necem specificky vlastnim)
Ted se hleda nova masova technologie resp. jeji nova verze.
Gramodesky jsou starsi nez ostatni nosice - cili stara technologie a okrajove se pouzivaji prez sve nevyhody (linearita, krehkost, velikost, kapacita, rozmery, citlivost zarizeni...)
XHTML ma byt nova masova technologie, ktera tu starou nahradi, cili gramodeskou by tu v tomto pripade bylo HTML. Ale XHTML se neprosazuje protoze resi neco uplne jineho, nez co tvurce trapi. -
Ondřej Tůma (neregistrovaný)Uznavam ze to bylo spatne napsane. Grafonove desky se profesionalne pouzivaji pres sve nevyhody pro jednu zasadni vyhodu, to co na ni totiz nahrajete je daleko daleko jemnejsi zaznam zvuku, nez ktery v soucasnosti je clovek schopny digitalizovat. Ano je to pro opravdu mlsne usi, ale tady mam pocit ze lidske ucho je snad daleko citlivejsi nez lidske oko. Tedy digitalizace je opravdu slyset.
Co se xhtml tyce, tak je to paradoxne obracene. S xhtml lze delat daleko vice kras, prave proto ze jde vlastne jen o xml. (nebylo tu nahodou xml driv nez html ?) A v tomto smeru vidim html jako brzdu, kterou se snazi nekteri jeji zastanci jeste vice protlacit nez je.
A to je prave to co na tom prirovnani kritizuji, prirovnavat html ci xhtml ke gramofonovym deskam je zcestne.
PS: mimochodem, to okrajove pouzivani tak okrajove neni !! -
anonymníRozhodne nebylo driv. HTML (1993) je jednoucelova zjednodusena podmnozina jeste starsiho SGML, ktere je ale tak univerzalni, ze se snad neda kompletne prakticky implementovat :) (no mozna da, ale pak by i ty prvni prohlizece musely vypadat opravdu jinak).
XML je novodoby (tusim od 1997) pokus o univerzalni metajazyk, ktery by ale mel mnohem striktnejsi syntaxi a bylo by snadne ho zpracovat (jestli se to uplne povedlo nevim, vsechny ty entity, externi dokumenty, jmenne prostory, ... z toho nekdy delaji celkem chaos).
XHTML1 je potom prechod od syntaxe HTML ke (zpetne kompatibilni) syntaxi XML pro web.
XHTML2 je vlastne totez, jenze z nejakeho duvodu misto aby se na zaklady XHTML1 postavily nove vlastnosti, tak se to cele rozebralo, rozpitvalo, prekopalo, zeslozitilo a udelalo zpetne nekompatibilni. Slouzit to ma ale porad tomu stejnemu ucelu.
Tady ale prece nejde o obecne XML. XML a jeho ruzne aplikace se vyuzivaji na mnoha mistech a to i v praxi. Tady jde o webove XML = XHTML. Ze s nim jde delat vic kras je sice pekne, ale pokud to jsou krasy, ktere vyuzije minimum uzivatelu, a nejsou to krasy, ktere by vyuzilo hodne uzivatelu, je to v celku na nic.
A pokud je to navic zpetne nekompatibilni pak uz je prinos nejen maly, ale dokonce zaporny.
ČLÁNKY DO MAILU