Názory k článku Akta X: HTML 5 jako alternativa ke XHTML
-
papouch (neregistrovaný)aby se nemusel parsovat vystup urceny puvodne pro prohlizec byl vymyslen WebService (http://en.wikipedia.org/wiki/Web_service) a par dalsich podobnych mechanismu
IDOS, to jsou ty jizdni rady? Nebylo by jednodusi se rovnou domluvit s autory? -
Franta (neregistrovaný)LOL, ty asi píšeš WS v assembleru, ne? :-)
Zkus to někdy v javě pomocí průvodce z Netbeansů nebo Eclipse, případně v C# ve Visual Studiu -- a zjistíš, že je to pro programátora nejsnadnější cesta jak volat vzdálené metody. A to jak z pohledu serveru, tak i klienta ;-)
Ale neznamená to, že bych byl jednoznačným zastáncem WS -- z výkonnostních hledisek to není optimální, data se obalují velkými kusy textu... ale to je cena za snadný a rychlý vývoj a schopnost integrace mezi různými jazyky a platformami. -
Franta (neregistrovaný)Dot net není moje hlavní doména, takže to nemůžu až tak posoudit. Ale když jsem si to zkoušel, tak mě zaujalo hlavně to, jak snadno se dají přegenerovat třídy na straně klienta, když se změní WSDL. Neprůhledné to jistě je, ale dovedu si představit uplatnění u věcí, které člověk potřebuje rychle naklikat. Nicméně celý dot net mi přijde jako spíš taková hračka než nástroj pro seriórní práci.
-
shaga (neregistrovaný)No, moje poznámka byla míněna jako takové drobné rýpnutí, ale když už je tu ta odpoveď... :)
Průvodce v Eclipse (Web Tools) jsem použil pro několik web service, které jsou nyní v produkčním nasazení a do teď si za to nadávám, rvu vlasy a chodím bezmála kanály. Jednak je to celé postavené na Axisu, což není zrovna nejkvalitnější kus kódu na světě (narazil jsem minimálně na tři dost nepříjemné bugy - Axis posílal nějkteré elementy v jiných namespacech než v jakých měl, jeden element mi dokonce přejmenoval...) a co je důležitější, nad vygenerovaným WSDL, při postupu code-wsdl, nemám plnou kontrolu, takže jakákoliv změna do interface je sázka do loterie, zda bude rozšíření interface skutečně rozšířením konzervativním, například. Z tvého "nejsnadnější cesta jak volat vzdálené metody" soudím, že WS-* stack používáš přesně tímto způsobem - jako formu RPC.
Tedy code-wsdl a wizardi vedou k neudržovatelnosti výsledného kódu.
Opačný postup, z XML schematu či hotového WSDL ke kódu, je mnohem příčetnější, z dlouhodobého hlediska. Problém je v tom, že XSD je mimořádně nabubřelý a složitý standard, interoperability issues beztak existují (ne nadarmo vznikla skupina WS-I dospecifikovávající ty kusy SOAPu a WSDL, které jsou nejasné a neinteroperabilní) a tak se člověk začne ztrácet v pojmech jako WS-I, wrapped, document/literal, rpc/encoded, sporech, zda SOAPAction používat či ne apod. Zkrátka nic, co by jednomu, který nemá čas pročítat tuny specifikací napsaných specification freaks z velkých korporací, nějak ulehčilo život.
WS-* je bastl. Nedospecifikovaný (wsdl je pouze W3 note!), na toolech (wizardy, IDE, drahé aplikační servery) závislý, mezi platformami nekompatibilní. Zaslouží si osud corby. -
Franta (neregistrovaný)Hlavní přínos WS vidím právě v rychlosti a snadnosti implementace a ta se projeví právě při přístupu: kód --> WSDL. Obrácený přístup je IMHO tak pracný, že se vyplatí použít jinou technologii.
Co myslíš tím "mezi platformami nekompatibilní"? Vždyť je jedno, v čem implementuješ klienta a v čem server. -
shaga (neregistrovaný)Nikoliv, postup kód - wsdl vede k tomu, že nemáš plnou kontrolu nad interfacem jako takovým - interfacem jsou XML zprávy, ne (kupříkladu) Javovský interface.
Problémy s platrofmami a jazyky existuje - právě proto existují specifikace jako je WS-I. Zkus konzumovat v Javě perlovské serializované objekty...
O tom, proč je code-wsdl přístup špatný se píše například tady: http://www.hpl.hp.com/techreports/2005/HPL-2005-83.pdf
Stack, který je si toho plně vědom a umožňuje dobře dělat schema first development je kupříkladu Spring WS: http://www.springframework.org/spring-ws
Říkám to nerad, kód-wsdl je pohodlná cesta, ale po zkušenostech, dost bolestivých, nikdy více. -
Franta (neregistrovaný)"Nikoliv, postup kód - wsdl vede k tomu, že nemáš plnou kontrolu nad interfacem jako takovým" Nechápu, kterou část mého příspěvku neguješ tím "nikoli"
Kód-->WSDL je rychlý a bezpracný a jako takový se na pár věcí hodí, nemá smysl ho zavrhovat, uplatnění pro něj existuje. Daní za tu rychlost je, že nemáš plnou kontrolu nad WSDL, ale to je tak vždycky: něco za něco. Pokud tenhle přístup přinese uspokojivé řešení, tak přece nevadí, že nemáš plnou kontrolu nad WSDL.
Pokud bych si měl psát WSDL ručně, tak se raději poohlédnu po jiné technologii než WS.
Btw: když začneme psaním WSDL, tak zase nemáme kontrolu nad těmi vygenerovanými javovskými (případně C) třídami. Pak je ještě možnost psát ručně úplně všechno, ale tím se člověk připravuje o hlavní výhodu WS a nemá to už vůbec smysl je používat. -
shaga (neregistrovaný)Neguju tím celý nápad generování wsdl z kódu, zhruba :)
Nemusíš psát ručně WSDL celé. Nejdůležitější je část se schematem, to napsat ručně můžeš a zbytek WSDL nechat generovat (při zachování plné kontroly nad tím, co bude jeho obsahem) například z JSR181 anotací v třídě implementující onu službu. Tato třída pak bude používat třeba JAXB2 generované nebo Castor třídy.
To, že nemáš konktrolu nad těmi třídami není taková katastrofa - vrstva služby je jistě tenká a pracuje nad nějakými business objekty, které jsou na ní nezávislé. Jde o to, že při generování Javovských tříd neřešíš problém toho, že bys mohl rozbít konktrakt s druhou stranou, maximálně rozbiješ svou tenkou vrstvu WS, kterou opravíš během chvíle.
Zažil jsem peklo toho, kdy jsem musel do nějakého poměrně důležitého interface dodávat další pole a metody a pak generovat WSDL. Jeden konzumující systém ty změny vyžadoval, druhý jej mohl implementovat až někdy za půl roku... Opravdu nepříjemné. Kdybych měl plnou kontrolu nad schematem, mohl bych mnohem snadněji interface rozšířit a mít jistotu, že jsem nerozbil konktrakt s druhou stranou.
A o to jde, o konktrakt interfacujících systémů. Všechno ostatní je podružné. -
Franta (neregistrovaný)Pokud změna spočívala v přidání metody, pak by se mělo vygenerovat totožné WSDL, které by mělo navíc pouze novou metodu. Tím se kontrakt nerozbije a pokud ano, tak je to chyba generátoru WSDL a měla by se nahlásit (btw: co to bylo za prostředí?)
Pokud jde o přidání parametru do existující metody, pak je to v podstatě změna "protokolu" a změna na straně klienta je tak jako tak nevyhnutelná. -
shaga (neregistrovaný)Axis, mimochodem, pokud jen trochu lze, držet se od tohoto co nejdál.
Přidání parametru nemusí nutně znamenat změnu na straně klienta. Je-li parametr nepovinný (minOccurs nastavený na 0), pak jej neposílající klient vůbec nemusí znát, zatímco jiný klient jej může zvesela posílat.
Ještě ke všemu jsou požadavky takové, že je formát správ prostě daný externím systémem - zrovna teď jsem to řešil - a pak vyjít od schematu prostě musíš. -
Tak trochumi to přijde jako jestli má být (X)html použitelné i když mi vyjde jen tak z ruky (tak jak původně fungovalo, s možností překlepu), nebo být validním XML se všemi jeho výhodami. A protože furt bude dost prasat a "dobrý" prohlížeč zobrazí všechno, tak podle mě není co řešit. (Ale ne že bych byl proti tučným rudým nápisům na dolní liště prohlížeče, pokud se dokument hlásí k XML/XHTML a přitom to není pravda). Ale popravndě s nějakým rozšiřováním HTML nesouhlasím, teď mi přijde tak akorát ... :) -
anonymníProblem je, ze to neni jenom otazka, jestli to umi parsovat prohlizec nebo ne. Takhle to zrejme vidi jenom frontpage-isti:) a sdruzeni protlacujici HTML5. Ale ono tech parseru muze byt o hodne vic, napr. jednoduchy XSLT pro nevidome, ktery oreze barevny sracicky a vyplivne pouze textovy obsah se specialnimi znackami pro SPEECH SW, nebo proste nejakej skriptik, kterej dokaze ve strance odlisit nadpis od obsahu textu. A kdyz to bude XML format, tak se bude moct psat parser jednoduse (treba XSLT).
Kdyz to nebude validni XML, tak jsi v riti a muzes psat vlastni parser, nebo zkopirovat kod z Mozilly.
Docela se divim, ze zrovna Google (kterej by mohl ve strance lehce najit spravne urcity typ textu) a Mozilla (ktera snad take pouziva XML transformace) chteji protlacovat ne-XML format. -
Ondra (neregistrovaný)
Hacek je, ze ono to stejne skoro nikdy validni XML nebude, protoze prohlizece jsou benevolentni vuci syntaxi (a vzdycky budou, jinak by zrejme byly k nicemu) a zadny oficialni standard neni vynutitelny. Vetsina HTML bastliru a "webdesigneru" nema ani tuseni, ze existuje neco jako validator, potrebuji, aby to nejak vypadalo v MSIE. Takze v riti budes tak jako tak, pokud budes chtit parsovat obecny webovy dokument, vstupni format ti nikdo nezaruci. Ta chyba, ze HTML bylo puvodne vytvoreno jako velmi volny format a prohlizece s tim musi pocitat (a autori stranek na to tudiz mohou hresit), se uz stala, a vratit se to neda. Takze hezky zpatky obema nohama na zem :)
Ale jinak sam s HTML 5 a vubec s pokracovanim HTML vetve nesouhlasim, XHTML mi prijde jako lepsi cesta. A i kdyby to tak nebylo, XHTML uz tady nejakou dobu je a pouziva se, a vytvaret konkurencni standard je podle me zbytecne.
-
Zero (neregistrovaný)Mne osobne sa paci XHTML 1.0 Strict! a nechapem preco sa zase vracat nie o krok ale o cely kilometer dozadu... ved kto nechce pisat v xhtml nech pise v html 4.01 a nie hned pre par exotov vymyslat html 5. Ved ked za tych niekolko rokov co je xhtml na svete sa vecsina webloperov nedokopala k pouzivaniu xhtml, tak pochybujem aby sa dokopala pouzivat html5. Ak by to bolo z dielne MS tak by som to chapal... ale ze to prichadza z dielne tych co dodrziavaju standardy...
-
Peca (neregistrovaný)Když UA zjistí MIME typ text/html, rozebírá dokument jako nějaké HTML a v definici HTML žádný element třeba <meta něco> nebo <br /> ve specifikaci HTML není a dokument je tudíž í, přísně vzato nevalidní. Druhá věc je, že snad všechny UA si s tím nějak poradí zobrazí to "korektně".
Validátor na rozdíl od UA porovnává shodu dokumentu s DTD a nezkoumá s jakým typem je dokument posílán. -
Lopan (neregistrovaný)Tak zrovna Strict je v praxi nepouzitelny (pokud delate designove weby). Oproti Transitional bylo odstraneno nekolik vlastnosti za ktere nejsou nahrady (pripadne existuji papirove, ale nejsou implementovane). Jen je po me nechtejte jmenovat, problematice prechodu na Strict jsem se venoval pred 2 lety a uz si jen pamatuju zaver :)
-
Peca (neregistrovaný)Dovolím si nesouhlasit. Ve Strict jdou dělat weby s designem (CSS), nicméně je pravdou, že v Trans jsou značky, které W3C nepochopitelně zavrhlo, např. MENU. A menu patří do MENU. Transitional umožňuje lepší sémantičnost.
Na druhé straně nemusím v Trans prezentační značky (CENTER, FONT a další) používat, když nechci. -
Zero (neregistrovaný)Tak s tym nesuhlasim... ja robim v stricte a pomocou css sa da web urobit celkom pekne a hlavne prehladne... nieco ako <center> som pouzival ked som sa ucil html vo frontpage... odkedy to robim rucne, tak vsetko formatovanie a ostatne deprecated veci len cez css a to mi aj najviac vyhovuje... len ma to jednu nevyhodu a to je zobrazovanie pod Expolderom...
-
Lopan (neregistrovaný)Samozrejme nemam na mysli veci jako center...
Ale vzpomel jsem si na dva hlavni duvody
1. atribut target u odkazu. Otevreni do noveho okna ma sve misto na webu.
2. nutnost obalovat formularove prvky blokovymi elementy, prijde me to zbytecne.
Duvod 1 byl rozhodujici. Reseni pomoci JS jsou nevhodna z duvodu pristupnosti. -
razor (neregistrovaný)No já bych použíl argument: accessibility. Nicméně tuším, že to velkou část web developerů nechává chladnou.
-
W3C v uplynulých letech trochu zapomnělo na reálné potřeby tvůrců webu. Usmyslelo si, že to nejúspěšnější na Webu, HTML, zařízne, zmrazí a zkusí nadefinovat něco podobného znovu jako XHTML 2. Hmm. Všechny možné X-kové specifikace od W3C existují nějakou dobu, ale na web se jim příliš nechce. Tedy autoři webů o něj nějak nestojí. Ani dodavatelé prohlížečů nemají příliš zájem vrážet desítky miliónů dolarů do podpory na Webu nepoužívaných specifikací.
WHAT WG vznikla jako odpověď na nevyslyšené přání tvůrců webů. W3C nakonec pochopila, že jí zvolená cesta nemusí být ta pravá pro všechny.
http://glazman.org/weblog/dotclear/index.php?2006/10/29/2197-tim-berners-lee-thank-you
http://www.w3.org/2006/11/HTML-WG-charter.html -
Zrovna jsem Ti chtěl odkaz na tenhle článek dát do diskuse na Lupu :) W3 určitě není neomylné, ale třeba ta věc s uzavíracím lomítkem -- tak, jak je popisovaná v článku -- je docela ujetá, ne? Dokážu si představit, že autoři prohlížečů se bez koncového lomítka obejdou, ale z pohledu nějaké "obecné" použitelnosti stránek mi XHTML přijde jako... třeba ne tak výrazný, ale přeci jen krok vpřed. Bránit se XML, když ho můžou mít prakticky zadarmo, je fakt divný. -
Jirka Kosek (neregistrovaný)Je potřeba oddělit sémantiku a syntaxi značkovacího jazyka.
WHATWG chce do HTML přidat několik nových elementů a atributů, které usnadní zejména psaní aplikací. To je v zásadě dobrá věc, i když to třeba částečně koliduje s XForms.
Dokument používající nové elementy/atributy pak půjde serializovat dvěma odlišnými způsoby -- buď jako HTML5 nebo XML dokument. Záměrně píši HTML5 dokument, protože narozdíl od předchozích verzí jazyka HTML není HTML5 formálně postaveno nad SGML, ale specifikace HTML5 definuje kompletní gramatiku jazyka v souladu s tím, jak se chovají prohlížeče, protože ty nikdy nepoužívaly skutečný parser SGML. Sice trochu záměr autorů chápu, ale já osobně bych se spíše snažil upravit stávající SGML deklaraci pro HTML tak, aby se to přibližilo k chování prohlížečů. -
On hlavni prinos WHATWG je prave ve specifikacich a la Web Forms. Osobne bych byl rad, aby uz byl implementovan. (X)HTML5 je IMHO vedlejsi produkt, ktery by mel celou vec ustnadnit a nakonec bude stejne dotlacen do XML compatible stavu 8-)
-
> specifikace HTML5 definuje kompletní gramatiku jazyka v souladu s tím,
> jak se chovají prohlížeče, protože ty nikdy nepoužívaly skutečný parser SGML.
To mi právě připadne tak ujetý, ale je možné, že tomu jen nerozumím. Jako programátorovi mi vyhovuje, že jsou mé webové stránky uložené v XML (jistě nejsem jediný). Myslel jsem, že by to mělo být jednodušší i pro autory prohlížečů, kteří by se časem mohli od starších parserů všech možných hrůz, co jsou na webu k vidění, přesunout k XML. Proč tedy HTML5 definuje novou gramatiku? (Vážně mě to zajímá.) -
Jirka Kosek (neregistrovaný)
Proč tedy HTML5 definuje novou gramatiku? (Vážně mě to zajímá.)
No na to se zeptejte chlapců z WHATWG. Osobně si myslím, že SGML na ně působí jako rudý hadr, a tak s ním nechtějí mít nic společného. Ona se ta nová syntaxe od HTML v podstatě neliší, liší se ošetření mezních situacích, kdy HTML5 je blízké tomu, jak se chovají současné prohlížeče (ty by se však měly chovat jinak, kdyby četli HTML v souladu s pravidly SGML a SGML deklarace pro HTML).
-
Mně nějaké lomítko přijde jako podružná maličkost, jako bych měl odmítnout arabského plnokrevníka v rozpuku sil pro pihu na břiše. Reálně na koncové lomítko parsery webové polívky HTML značek v prohlížečích kašlou, protože je autoři webů nepíší či zapomínají. Pokud je pro vás tato maličkost ve specifikaci zásadní, napište Hixiemu, je dostatečně inteligentní, přístupný a zkušený na to, aby skutečnými argumenty podložené názory či náměty vhodně začlenil.
Např. IInfo má většinu svých stránek v XHTML 1.0 a převážně validních. Občas kolegům ujede nějaká drobná bota, třeba neuzavřou INPUT či IMG, a chyba se dostane až na ostrý server. Mají se vám stránky přestat zobrazovat, protože XML není well-formed? Je nezobrazení v něčím zájmu? Prohlížeče? Čtenáře? Poskytovatele obsahu? Nikdo mne nenapadá... Well-formed je důležité pro výměnu dat, ale není kriticky důležité pro webové stránky.
Pod nálepkou W3C se vymyslelo spousty zajímavých věcí a také pár slepých uliček. Jsou i specifikace, které jsou na pomezí mezi užitečností a zbytečností: pokud by XForms byly prvními formuláři v prostředí webu, byly by jistě pro výrobce prohlížečů zajímavé. Ale zde jsou mohutně používané formuláře z HTML, které stačí drobně vylepšit. W3C nedá výrobcům prohlížečů žádné peníze na implementaci XForms a zároveň nikdo tak zásadně po XForms ve webových prohlížečích netouží (jinak by si vývoj zaplatil či vynutil jejich používáním). -
Pepa (neregistrovaný)co je načtení a zobrazení stránky jiného než výměna dat? imho by se to zobrazit nemělo a nikdo kdo by se na tu stránku jednou podíval by jí na ostrý server nepustil, protože by nic neviděl. Proč z autorů sw mají jen tvůrci webových stránek problém dodržovat nějakou základní syntaxi?
-
Ano, jde o jistou výměnu dat, nepovedlo se mi rozlišit text v XML s vyznačenými částmi a v XML zapsanou databázi.
Syntaxe HTML není žádným zpracujícím softwarem vynucována, v důsledku čehož není dodržována a proto její 100% dodržení nemůže být v reálném světě nezbytné. Jak fatální důsledek chybějící specifikace chybových stavů v HTML.
Je zřejmé, že dědictví miliard nevalidních stránek a jejich uživateli předpokládané "bezchybné" zobrazení je bariérou pro vstup na trh webových prohlížečů, ale bohužel taková je realita.
Nebo snad, Pepo, víš o výrobci webového prohlížeče, který by se chtěl pohřbít tím, že nebude umět zobrazit například 90 % Webu? Microsoft se svým lpěním na zachování zpětné kompatibility? Nebo by se snad Mozilla Corporation rozhodla popřít cíle své nadační matky a z Firefoxu udělat obskurní hračku pro dogmatiky webových standardů? Nebo snad Opera, KDE a Apple mají se svými prohlížeči tak zásadní podíl, aby změnili chování autorů webových stránek? A nebo čekáte, že Web změní Google, když by řekl, že nevalidní stránky vyřadí od května ze svého indexu?
Pokud se pohybujeme v rovině teorie, pak s tebou souhlasím, bylo by to krásné. Bohužel, reálný svět je uprostřed komplikované situace, která není moc řešitelná (téměř deadlock). Rozšíření XForms a XHTML 2 na Webu dokazuje, že řešení navržená W3C zatím v prostředí Webu neuspěla. -
Pepa (neregistrovaný)Samozřejmě vím jaký je reálný svět. Bohužel se výrobci prohlížečů v počátcích rozhodli, že budou myslet za tvůrce stránek a není prakticky vůbec vyžadována platnost vstupu. A bohužel na to vyžadování platnosti rezignovali při každém mezníku, kdy bylo možné ho zavést. Při zobrazení stránky s uvedeným doctype se přece nemusí řešit kompatibilita s nějakým podivným html nebo předchozí verzí. Chápu že je mraky stránek s podivným kódem vzniklých v dobách živelného vývoje, které stávající prohlížeče musí zobrazit. Ale proč proboha tenhle přístup začaly uplatňovat i pro nové stránky, které se hlásí k nějakým novým přesně definovaným standardům?
-
Po tvůrcích webových stránek chcete striktní vyhovění standardu/specifikaci, na sebe samotného už tak přísný nejste. Kdybych byl netolerantní, mohl bych Váš příspěvek označit za nevalidní (tj. neodpovídající pravidlům českého jazyka – velké písmeno na začátku věty, diakritika, interpunkce, prohozené pořadí slov) a odmítat jej číst. Vidíte ten problém? Ač jsem schopen naprosto jasně pochopit, co jste napsal, měl bych podle Vašeho doporučení pro prohlížeče popřít vlastní porozumění sdělovaného pro formální důvody. Pro život mezi lidmi trochu nepraktické.
Tolerance prohlížečů k prasáckému zápisu HTML pravděpodobně umožnila masivní rozšíření webu i revoluci Internetu, dnes jsme ale za tutéž toleranci biti. Historii zatím změnit neumíme, můžeme měnit jen budoucnost.
Máte nějaký konkrétní nápad, co mohou udělat tvůrci webových prohlížečů v této situaci pro lepší budoucnost? -
Ondrej 'SanTiago' Zajicek (neregistrovaný)Mezi pocitacovymi standardy (napr. od IETF) a jazykovymi pravidly je jeden podstatny rozdil - zatimco vyvoj standardu je mozne pripominkovat, tak jazykova pravidla vznikaji kodifikaci bezne praxe. Tedy neexistuje jina moznost, jak zmenit jazyk, nez pouzivat ho v modifikovane podobe a doufat, ze se modifikace natolik rozsiri, aby byla kodifikovana.
-
I W3C je soustavně doporučováno, aby standardy nenavrhovala na zelené louce, ale na základě běžné praxe. Některé z webových doporučení W3C tuším vznikají tak, že navržené doporučení se stane skutečným doporučením v okamžiku existence minimálně dvou nezávislých vyhovujících implementací. Co není v reálu implementováno, je z doporučení vyškrtnuto.
Problematika u webových doporučení je opět složitější, než se na první pohled zdá: má být inovátorem na webu pracovní skupina W3C nebo jím mají být tvůrci webových prohlížečů? Pokud bude hybatelem pracovní skupina, může se stát, že jí navržená vlastnost nepůjde elegantně implementovat (např. CSS pro sloupce) nebo bude nedomyšlená (nemožnost určení zalomení ve sloupcích CSS 3). Bude-li inovace na bedrech jednotlivých výrobců prohlížečů, může se stát, že vymyslí cosi tématicky podobného, ale každý na to půjde jinak (styly Microsoftu vs zahozené styly Netscape).
Verze HTML po úvodním návrhu TBL včetně HTML 4.01 a její obdoby XHTML 1.0 byly kodifikací praxe (např. tabulky byly dříve v prohlížeči než byť jen v draftu doporučení) a proto si myslím, že jistá podobnost s naším jazykem tu je. Sám bych se bál tvrdit, že není možné připomínkovat jazyková pravidla při jejich tvorbě/kodifikaci – předpokládám, že jen nejsme relevantní cílovou skupinou stejně jako běžní uživatelé Seznamu nepřipomínkují další verzi HTML. -
Franta (neregistrovaný)"existence minimálně dvou nezávislých vyhovujících implementací"
A ty implementace vzniknou na základě čeho? Jestli mají být navzájem kompatibilní, tak to musí být na základě téže analýzy, zadání. A kdo to zadání udělá? MS? Mozilla? Opera? Nebo se snad tito mají dohodnout? Od toho je tu přece w3, jako někdo nezávislý, kdo může dělat takové návrhy, které mají šanci na úspěch. -
W3C není nikdo nezávislý. W3C je jen "sdružení" organizací a jednotlivců, kteří mají o danou problematiku zájem a mají peníze na zaplacení členského příspěvku. Jednotlivé pracovní skupiny se formují ze zástupců těchto organizací a případných přizvaných expertů v dané oblasti.
Např. na CSS 2.1 se podílí:
* Bert Bos – zaměstnanec W3C
* Tantek Çelik – bývalý šéf vývoje MSIE pro Mac
* Ian Hickson – dříve Mozilla, později Opera, nyní tuším ještě Google
* Håkon Wium Lie – CTO Opery
Dvě implementace mohou vzniknout i tak, že někdo vyzkouší naimplementovat prototyp své představy, vyřeší problémy návrhu i problémy objevené použitím, sepíše návrh specifikace, podle ní to začne psát "konkurence", specifikace se dále upravuje, připomínkují ji i lidé zvenku (autoři webů, softwaru pro editaci, tvůrci jiných specifikací...), na základě toho všeho se mění i ta původní implementace.
Stalo se také, že na základě nedostatečně přesné specifikace vznikly různé implementace s rozdílnou funkčností, tak se chlapci nějak dohodli a v další verzi prohlásili jednu z implementací za správnou.
Jinak autoři specifikací nejsou obvykle mezi sebou na nože – mají k sobě vzájemný respekt, často jsou to přátelé či bývalí kolegové. Přeci jen často všichni řeší podobnou problematiku a to, že jejich organizace jsou konkurenty, se netýká až tak těch technických věcí. -
Franta (neregistrovaný)jenže on je rozdíl mezi komunikací lidí a mezi komunikací dvou programů ;-) Navíc příliš tolerance škodí tak jako tak.
Stránka se píše jednou, ale prohlíží tisíckrát, milionkrát. Takže je lepší ji napsat jednou pořádně, dát si s tím tu práci. Než ji milionkrát parsovat a opravovat v ní chyby. Nemyslíš?
"Tolerance prohlížečů k prasáckému zápisu HTML pravděpodobně umožnila masivní rozšíření webu"
Jedna trochu filosofická otázka: myslíš, že by to byla velká tragédie, kdyby web nebyl zahlcen stránkami typu "Moje první stránka" na které je odstavec nějakého pokusného textu a jméno autora? IMHO by to byl naopak přínos. -
Pokud člověk i program dokáží poznat smysl chybné zprávy, proč by jej měl program či člověk odmítat? Zvláště, pokud tvůrcem chybné zprávy může být v obou případech člověk?
A myslíš, že má první stránka v HTML byla něco zásadního? I programátoři se učí od legendárního Hello world! a já v těchto prvních oťukáváních publikace na webu nevidím nic špatného, spíše naopak. -
Protože úsilí nutné k napsaní takového programu by se dalo využít podstatně lépe ke zlepšování služeb které ten program nabízí. Kolik asi času a zdrojů při údržbě a vývoji prohlížeče tvoří právě údržba a vývoj renderování nekorektních stránek?
Na druhou stranu zavedeným výrobcům prohlížečů situace asi vyhovuje, protože nastavuje vysoký práh pro kohokoli jiného kdo by chtěl dosáhnout podobného výsledku a "správně" ukazovat nekorektní data. -
Ano, kdyby neexistovaly miliardy chybných stránek, mělo by smysl se na ty nevalidní vykašlat. Bohužel, je to hra na kdyby.
Jen u Gecka stála podpora starých stránek odhadem desítky miliónů dolarů z kapsy AOL. Nemyslím, že by kdokoliv chtěl utrácet takové sumy, aby zabránil vstupu na trh desktopových prohlížečů, kde jsou programy v podstatě zadarmo.
Názory konkrétních vývojářů např. od Gecka jsou jasné – podpora starých ošklivostí znepřehledňuje kód a zvětšuje datovou velikost jádra, nejraději by ji vyhodili. Nejde to. Uživatelé by prohlížeče bez této podpory nemohli reálně používat. -
Franta (neregistrovaný)Příznivé je alespoň to, že se situace pomalu lepší. Odevzdat nevalidní komerční web si dnes dovolí už málokdo. Cestu vidím v tom, že budeme dělat osvětu a sami vytvářet validní stránky. Časem se k tomu ideálu dopracujeme :-) Vedle toho je nějaké příliš volné HTML5 cestou zpátky!
-
No jo, ale to že existují milióny chybných stránek přece neznamená, že by se měl udělat nový měkký, strojem obtížněji zpracovatelný standard - to jako aby to těm chybným stránkám nebylo líto? Já si nemyslím že by měly být najednou odmítány, ale že by budoucí stránky (stránky dle budoucích standardů) měly být psány tak, aby nepřidělávaly browserům práci.
Kromě toho, čím dál tím víc se "plnohodnotný" web (nikoli jen xhtml-mp nebo wml) tlačí i do malých zařízení jako mobily - a tam zase po letech záleží na velkosti programu i jeho paměťové a výpočetní náročnosti. -
Myslím, že je to celé nedorozumění, kdy si fanoušci X-světa včetně autora vytrhli z kontextu specifikace jednu rozpustilou větu a mohou se z toho zbláznit. Opravdu si přečtěte relevantní části specifikace, popř. FAQ; já z nich mám jiný pocit.
http://www.whatwg.org/specs/web-apps/current-work/#html-vs
This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language.
...
There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification.
The first such concrete syntax is "HTML5". This is the format recommended for most authors. It is compatible with all legacy Web browsers. If a document is transmitted with the MIME type text/html, then it will be processed as an "HTML5" document by Web browsers.
The second concrete syntax uses XML, and is known as "XHTML5". When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is processed by an XML processor by Web browsers, and treated as an "XHTML5" document. 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.
The "DOM5 HTML", "HTML5", and "XHTML5" representations cannot all represent the same content. For example, namespaces cannot be represented using "HTML5", but they are supported in "DOM5 HTML" and "XHTML5". Similarly, documents that use the noscript feature can be represented using "HTML5", but cannot be represented with "XHTML5" and "DOM5 HTML". Comments that contain the string "-->" can be represented in "DOM5 HTML" but not in "HTML5" and "XHTML5". And so forth.
a pak také http://blog.whatwg.org/faq/ -
Franta (neregistrovaný)1) Docela zásadní problém vidím v tom, že nikde nebude jasně definované, jak moc špatně napsaný kód by měly prohlížeče tolerovat a opravit a jaké chyby už tolerovat nemusí. V důsledku pak nikdo nebude vědět, co je správně a co špatně napsaný kód, protože v jedné verzi prohlížeče se zobrazí OK a v jiné už ne. Prostě příliš volná pravidla nemohou fungovat.
2) Každý tak začínal, já taky, ale nemusí to člověk hned cpát na web. A hlavně, kdyby validace nutila tvůrce do psaní správného kódu už od začátku, měli by to v mnohém snazší -- naučit se od začátku XHTML je imho snazší, než když se má bývalý prasácký kodér html přeučit na něco nového. -
Ad 1) ano, to je problém HTML, které nedefinovalo pravidla pro nakládání s chybami a tak si je tvůrci určili sami. Jak svévolí, tak opisováním. Berte to jako fakt, nejde s tím nic moc dělat (alespoň mi tu nikdo nechce říct žádný realistický nápad, jak to dnes změnit).
Ad 2) Ano, ano. Hry na kdyby jsou ale zbytečné, opravdu tu minulost nikdo nedokáže změnit. -
Franta (neregistrovaný)"Občas kolegům ujede nějaká drobná bota, třeba neuzavřou INPUT či IMG, a chyba se dostane až na ostrý server. Mají se vám stránky přestat zobrazovat, protože XML není well-formed?"
Jenže vtip je také v tom, že nevalidní html výstup tě často upozorní na chybu programátora/softwaru na straně serveru. Kdežto když budeš defaultně vytvářet invaludní výstup, takové chyby si ani nevšimneš. Validace výstupu je velký dar -- dostaneš tak zadarmo nástroj pro automatické testování. -
ray (neregistrovaný)Mne se HTML5 take z rady duvodu docela libi. Od puvodni *IDEOLOGIE* XML se cele X* zvrhlo v peknej bordel, casto kolidujicich si standardu. Slozite molochy, ktere jsou nekdy neuveritelne slozite na *korektni* implementace. Protichudne vlastnosti, zavedene k supokojeni ruznych potreb velkych firem, etc... Nekdy mam pocit (specilane u W3C), ze zde plati rceni klasika "proc to delat jednoduse kdyz to jde slozite". Jak uz tady padlo, implementovat tisic a jeden X* standard jen proto, abych docilil neceho, ceho muzu dosahnout pridanim par elementu mi prijde jako zvrhlost... Web dokumenty validni nebyli, nejsou a nebudou. A ikdyby si to prohlizece vynucovali, nic by se nezmenilo. Kromne toho, vetsina lidi nechce cekat az se stanka nacte. Jenze dokud se nenacte kocovej /element tak stranka validni proste neni. Ortodoxni zastanci validity by tedy meli cekat, nez se jim vsechno nacte a na nejake zobrazovani 'mezivysledku' zapomenout. Proto a desatero dalsich duvodu dokumenty validni nebudou... Mozna by neskodilo cely X* svet radne prosekat a odplevelit. Treba by pak podobne snahy jako HTML5 nemeli podhoudbi pro svuj vznik.
R. -
Franta (neregistrovaný)Á, další lenoch co nechce uzavírat tagy a radši píše jako prase. Taky jsem začínal s Frontpage, ale je potřeba se od toho odpíchnout a začít psát validní kód ;-)
Co se týče zobrazování až po načtení celého dokumentu, nevím jak jsou na tom současné prohlížeče, ale žádného zpomalení jsem si u XHTML stránek nevšiml. -
rikard0 (neregistrovaný)V dnesnej dobe rychloho internetu a zlozitych aplikacii je ta uspora bajtikov zbytocna.
Navyse, pre tovrcov sw zobrazujuceho tvoje nevalidne stranky je ovela viac problematickejsie napisat kod tohto progrmu, aby zobrazil webe tak ako to jeho tvorca zamyslal, nez pre weby validne podla xhtml. To sa v konecnom hladisku prejavy ako mnozstvo zabranych bajtov na disku a bugle prehliadace.
Osobne som za xhtml 1.0 strict a podlo toho aj vyvyjam svoje weby. Otestovat si ich validnost nezaberie vela casu a ked su validne viem, ze mam za sebou kus dobrej prace. Rozsirenie stavajuceho xhtml o prostriedky pre zjednodusenie webovych aplikacii je dobra myslienka, no zatial som sa nestretol s nicim takym nestretol. -
uzivatel (neregistrovaný)A co akoze ?
Pisal si niekedy SW, nemyslim HTML. Ak nie tak ti poviem, ze zistovat, kedy je tag ukonceny ked tam tu znacku nedas je niekedy znacne problematicke a ubera ti vykon pri zobrazovani stranok, pretoze musi overovat ci nasledujuci tag je vnorenym tagom toho predchadzajuceho alebo sa jedna o uplne novy tag.
A kto tu hovori o norme HTML 4 ? Ved ked das DTD hlavicku ze sa jedna o HTML 4 tak ti pri validacii nevypise chybu s uzavretymi tagmi, pretoze ich nevyzaduje.
Takze sa nerozkrikuj :) -
pa3k (neregistrovaný)FUD. Uzatvorenie uvozdovkou apostrofom ALEBO navyše prázdnym znakom je fááákt obrovský problém pre parser ;-) Rovnako ukončovanie tagov li koncovou značkou nadradeného elementu (ul). Fakt drsná a zložitá vec :-D Sú to presne definované pravidlá a žiadny parser s tým výkonový ani žiadny iný problém mať nemôže.
-
Franta (neregistrovaný)Tohle mělo vyjít až prvního dubna, ne? :-)
Můžete mi někdo vysvětlit tohle: "za kterou stojí hlavně lidé spojení s výrobci prohlížečů "? Vždyť prohlížečům se mnohem lépe parsuje validní XML než nějaké sračky, které kódují malé děti.
Rozhodně se nebráním inovacím*, ale prosil bych XML.
*) i když je otázka do jaké míry to vůbec jde, protože dalším hodně tvrdým omezením je bezestavový protokol HTTP, díky němuž jsou webové "aplikace" aplikacemi pouze v uvozovkách, ve skutečnosti je to jen bastl a kompromis využívající dosluhující technologii. -
Franta (neregistrovaný)Zkus si změřit, jak dlouho trvá stažení HTML kódu* např. s touto diskusí. Nepočítej čas na renderování, jen čas stažení - zkus to třeba pomocí wgetu. Dokázal jsi postřebnout průběh stahování? Nebo jsi viděl až tohle:
100%[====================================>] 16,968 16.18M/s ETA 00:00
;-)
Takže já si myslím, že STOJÍ ZA TO počkat tu těžko postřehnutelnou dobu, než se stránka stáhne.
*) bez obrázků samozřejmě -
pa3k (neregistrovaný)Prečo potom XHTML stránky videteľne preblikávajú pri zobrazovaní? Chvíľku prázdno a zrazu hop, celá stránka. U html ten problém nemám. Zato veľmi často na aDLS lajne vnímam pri čítaní stredného stĺpca (obsahu) ktorý už je dávno zobrazený, ako sa doťahuje zvyšok do stĺpcov. Viď czc.cz v špičke - pri vyššom vyťažení.
-
"The lack of incremental loading and display [of XML documents] is simply a bug (or a missing feature)."
-- http://www.mozilla.org/docs/web-developer/faq.html
"Incremental rendering [of XML documents] is possible."
-- http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-August/001788.html
"XML Content Sink should be incremental [FIXED]"
-- https://bugzilla.mozilla.org/show_bug.cgi?id=18333 -
Aha, rozumím. No připadne mi (a asi se shodneme), že mezi parsováním slušně napsaného HTML a XHTML zase takový rozdíl není. Pak mi připadne dětinský psát do specifikací něco o značkovacích bozích -- kdyby tam to lomítko bylo, nikomu by to hlavu neutrhlo a s výsledným souborem by v pohodě dokázala pracovat většina standardních XML nástrojů. Webové prohlížeče na lomítko možná kašlou, ale webové prohlížeče nejsou jediný nástroj, který s HTML pracuje.
-
Jirka Kosek (neregistrovaný)Průběžné zobrazování XML vůbec nesouvisí s jeho parsováním, a proto ho ani nemůže dělat složitější. Většina nízkoúrovňových XML API, které se používají i v prohlížečích, čtou postupně XML dokument a pro jednotlivé počáteční a koncové značky, textová data apod. vyvolávají události, které aplikace zpracovávající XML musí obsloužit. Tenhle kód je hotový v desítkách různých knihoven pro čtení XML. Jediné co vývojář prohlížeče musí udělat, je obsluhovat tyto události, budovat z nich DOM a ten vykreslovat.
-
xxar3s (neregistrovaný)Písanie lomítiek na konci prázdnych elementov je byrokratický nezmysel. Formát XHTML sa skoro nepoužíva - 99% stránok sú odosielané s MIME typom text/html a teda sú to HTML stránky s XHTML doctypom. W3C je sekta(niečo ako Taliban) ktorá vymýšla nezmyslené formáty a snaží sa presvedčiť tupé masy veriacich že ich potrebujú. Budúcnosť patrí HTML5.
-
rikard0 (neregistrovaný)w3c sa uz neda povazovat za sektu, pretoze pocet jeho stupencov je vacsi ako su minimalne poziadavky na nabozenstvo.
Skor by som ako sektarov videl vyvojarov HTML5
BTW: skus si napisat parser na html4 ci html5, tak aby si zohladnil vsetky moznosti, ktore mozu tvorcu webu napadnut a zaroven sa dany web zobrazil tako ako to bolo zamyslane. Mas? Tak skus to iste s xhtml. Co ti ide lahsie?
Svet nema striktne pravidla (ani ich mat nemoze), preto je tu taky brodel.
Tak preco si robit bordel aj na webe?
XHtml strict rulez ;) -
Peca (neregistrovaný)>XHtml strict rulez ;)
Ano, to je přesně to, proč nemám rád X na začátku HTML. Také jsem byl takový a je bolestné pochopit, že zpětně nekompatibilní XHTML 2 má jenom mizivou šanci na větší než velmi malé rozšíření. Na druhé straně HTML 4.01 i XHTML 1.0 má naprosto stejnou množinu značek a liší se jenom prkotinami typu /. Takže si každý používejmě co uznáme za vhodné. -
Dlouhán (neregistrovaný)Na odkazované stránce najdeš kód a můžeš začít psát parser:
http://www.webylon.info/K.17 -
Franta (neregistrovaný)Tobě a autorovi té stránky asi ušlo, že XML parsery jsou už hotové. Je v tom spousta práce, to uznávám, ale smysl to má, protože se používají na spoustu věcí -- ty parsery se jednou napsaly a milionkrát se použijí.
Navíc tahle stránka (http://www.webylon.info/K.17) má jednu podstatnou chybu -- říká, jak je složité parsovat XML, ale o tom jak je složité parsovat zprasené HTML mlčí.
Úkolem prohlížeče je, vzít už parsovaný DOM a na základě něj kreslit na obrazovku písmenka, obdélníky, obrázky... -
Mikuláš Patočka (neregistrovaný)Problém s psaním HTML parseru není ta specifikace. Problém je --- někdo zapomene uzavírací tag, kdy ho zavřít? Když někdo zapomene v tagu uzavírací ">", kde ten tag ukončit? Když někdo zapomene úvozovky v atributu, kde se rozhodnout, že atribut končí? --- a tyto chyby se na webu vyskytují dost a když na ně nebudeš reagovat přesně stejně, jako majoritní Mozilla+IE, tak máš problém. A ve standartech se nedozvíš vůbec nic, leda, že je to neplatný kód.
-
emilk (neregistrovaný)zbyva jen zachyceni na mnozine skeletalnich symbolu :))
tyhle problemy ale mame i s xhtml.
odhaduju tak 99pxt webu posila s hlavickou text/html.
xhtml posilane tak, aby si vynutilo xml parser
zase treba uz jen pri vlozeni html reklamniho kodu treti strany
ukaze uzivateli jen chybovou hlasku.
tak proc po takovyhle zkusenosti porad trvat na xhtml?
po tolika letech psani nevalidniho html(xhtml), ktery v podstate nic nezlepsilo. -
Mikuláš Patočka (neregistrovaný)--- představte si C kompilátor, který když nalezne neplatný kód, tak si domyslí, co by to mohlo být, nenapíše chybu, a něco vygeneruje. To by z toho byl bordel, pak na nějaké standarty je možno úplně kašlat. A s HTML to takhle je. Ideální by bylo, kdyby browser po nalezení chyby napsal chybu a nic nezobrazil --- ale takový browser by nikdo nepoužíval --- takže se nějakého zlepšení nedočkáme.
-
Mikuláš Patočka (neregistrovaný)Pak každý stejně použije ten tolerantní mód a jseš tam, kde jsi byl. Dnes máš taky na webu validátory (x)html a málokterý vývojář WWW je používá. Pokazil to Mossaic a Netscape v prvních verzích, že ignorovaly chyby, teď už se s tím opravdu nedá dělat nic.
Co by se možná dalo dělat, by bylo specifikovat, že pokud stránka chce používat nějakou novou technologii (CSS3, AJAX ...), MUSÍ mít v hlavičce <!DOCTYPE blablabla> a dále specifikovat, že pokud je v hlavičce <!DOCTYPE blablabla>, tak browser NESMÍ zobrazit stránku s chybami a MUSÍ zobrazit chybovou hlášku --- pokud by tohle do browserů implementovali, tak by to možná nakopalo aspoň část webmasterů psát správné HTML, nic jiného je k tomu nedonutí. -
Mikuláš Patočka (neregistrovaný)Před pár lety jsem ve školním labu viděl následující jev --- přišli dva studenti a z rozhovoru mezi nimi bylo patrné, že se zapsali někde na brigádu na psaní WWW stránek --- zobrazili si tedy nějakou stránku, její zdrojový kód a hádali, co který tag dělá. Pak delší dobu koukali na tabulku a nakonec jeden prohlásil "Aha, TR odděluje řádky tabulky a TD sloupce" --- tak "pochopili" html a vrhli se na javascript. Jeden prohlásil, že javascript nezná, ale v tom formuláři pro tu firmu zaškrtl, že javascript umí. Tak koukali na javascript, připomínalo jim to céčko, tak se v tom trochu vyznali, a začali bádat, co dělá document.write. Po nějaké době jeden prohlásil "aha, to zapíše do toho dokumentu" a druhý "a document.read to zase přečte?".
Vždycky si toto představím jako průměrného vývojáře WWW píšícího prasácké stránky. Že existuje nějaký standard, kde by se dalo dočíst, co ty tagy a funkce javascriptu dělají, to zmíněné dva vůbec nenapadlo, pochybuju, že by věděli o nějakém validátoru. Standardizační komise může produkovat v podstatě cokoli, ale web to před takovýmito individui neochární :-/ -
roman (neregistrovaný)nevidim problem v tom, kdyz prumerne inteligentni clovek prijde na to, jak co funguje a jak to pouzit. problem vidim v modleni se k w3c a k oznacovani vseho, co jejich validatorem neproslo za prasackost. co jsem vypozoroval, tak w3c dogmatici jsou bud puntickari frustrovani tim, ze je okoli kasle, nebo nedostatecne inteligentni programatri, kteri si aspon chlacholi pocit dulezitosti, ze se nabifluji nejake "pravidla standartni webtvorby". pocitace a web maji byt pro lidi .... je 1 miliarda citatelu stranek, 1 milion vytvarecu stranek a 1000 tvurcu prohlizecu. Kto je tu pro koho? Tak to zalozte novy neprasacky standar, ktery bude stranku vykreslovat po pixelech, nebo neco jako postscript(vubec to neznam), at se to co nejlip implementuje..a usetri se strojovy cas pocitace... Ten fyzik, co HTML vymyslel si zrejme nezelal, aby se z HTML stalo neco, co bude dobre v prvni rade pro prohaneni validatorem a az pak pro cteni. Mne jako navstevnika webu VUBEC nezajima nejaka trapna ikonka w3c s linkem "checkni muj referrer", ale obsah.
-
jx0 (neregistrovaný)Dovolim si zminit zajimavost, kterou jsem slysel od starsich. V dobach, kdy si kazdy musel svuj zdrojovy kod vyderovat na stitky, cekat, az bude pripusten k pocitaci a bude mu prideleno urcite mnozstvi casu postacujici tak na jedno spusteni kompilace, existoval udajne kompilator (nebo parser?), ktery dokazal spoustu standardnich preklepu rozpoznat a opravit. Udajne se docela trefoval a usetrilo se tim opakovane spousteni kompilace. O jaky slo jazyk, kompilator a pocitac, to nevim. :))
-
anonymníSnad neco takoveho tak nejak silou (implementaci v browserech) prosadi.
Vzdyt cele HTML se vyvijelo zivelne/trzne vylepsovani z jednoho browseru prebirali dalsi browsery. Slavna W3C vydala tusim HTML 3.0, ktere ale bylo v tehdejsich podminkach dost obtizne implementovatelne a tak se na nej radeji zapomnelo a jako HTML 3.2 se vzalo to, co vice mene umely tehdejsi browsery.
Ctyrkove verze browseru uz to s vylepsenimi trochu prehnaly (hlavne MSIE se kterym se MS velmi snazil narychlo zachranit to, kde silne zaspal) a spolu s masivnim rozvojem webu (a "webdesigneru") zpusobily pomerne silny chaos. Takze se ti znalejsi upnuli ke standardum (a k W3C) protoze opravdu bylo potreba udelat trochu poradek.
Jenomze casem se ukazalo, ze W3C je zrejme porad stejny slon vznasejici se v oblacich (jako v dobach HTML 3.0) s tendenci velmi pomalu produkovat slozita reseni, ktera ale malokdo implementuje a malokdo pouziva.
Narazky na srovnavani HTML s programovacimy jazyky jako C jsou trochu mimo. Stejne tak jako se bourlive vyviji Internet a jeho pouziti, tak se vyviji pouziti WWW (potazmo tedy i HTML). Z pouziti pro puvodne staticky text provazany odkazy se obarvovanim a pridavanim vsemoznych elementu zmenilo nejprve na staticky (ovsem se spoustou velmi dynamickych GIFu) barevny katalog firem ci jednotlivcu posleze pribyla i vsemozna hejblatka a javascriptova udelatka.
Pozdeji se z WWW stala ta nejzasadnejsi sluzba internetu, ktera poskytuje pristup nejen takrka ke vsem ostatnim (uzivatelskym) sluzbam (od emailu po vzdalenou spravu). Web se ale stal take aplikacni platformou! V oblasti pristupu k informacnim systemum mozna tou nejzasadnejsi. Spousta podnikovych aplikaci ma webovy frontend. A pro aplikace se proste to zakladni HTML nehodi. Formulare, zaskrtavatka a tlacitka to vsechno pokazde reloadovane po odeslani je pro univerzalni ovladani aplikaci zatracene malo. I proto se rozvinuly AJAXove technologie.
Udelat obstojne kompatibilni interaktivni webove rozhrani pro aplikaci (v (X)HTML) je proste narocne, drahe (netvrdim, ze to nejde).
Rozsireni o 'formularove' UI je logicky krok. A at to radeji udelaji ti, kteri to budou implementovat (tvurci browseru + google) nez jimi financne podporovani snilci ve W3C.
Mimochodem google se angazuje jiste proto, ze se tim urcite chysta provest dalsi fazi utoku ve forme online poskytovanych aplikaci (m.j. office) - a je to zrejme on jediny kdo muze v soucasnosti konkurovat v IT Microsoftu v oblasti reseni pro mensi subjekty). -
vx (neregistrovaný)je padesát různých standartů **html** a jůzr stejně udělá to, že nápíše stránku ve wordu a dá uložit jako html... vůbec se nezajímá co to je za humus, stačí že to v IE zobrazí...
proč nepoužívat stránky čistě v pdf? případně celé flashové/javové stránky...
v dnešním světě kompjůtrů(kdy se na všecko sere a minimalizuje se jen do starých mobilů...
tak stránky v prolinkovaném pdf mi připadají jako slušné řešení...
//a o krok dal se zaseknem na tomtéž...několika verzích pdf:)))) -
Mě ne:
Až budete hodinu rolovat jednu A4 stránku po obrazovce mobilu, tak pochopíte proč PDF není vhodný formát pro web.
Flash a java? Tím ovšem omezíte celý web na platformy, kde tyto technologie fungují, odstřihnete se od vyhledávačů. Nehledě na to, že přijdete o jakoukoliv integraci s prohlížečem (historie, kontextové menu, záložky, zpět...) -
vx (neregistrovaný)jak říká můj tatínek, je uplně divné, že se někdo byl schopný dohodnout na SI a že to vetsina sveta opravdu používá...
no když to takhle říkáte, tak stímhle souhlasím, ja sem to myslel jen jako ad absurdum...
bohužel spousta stránek je čistě flašová... ve ff se to řeší snadno, když se neinstaluje flashový modul:)
a pdfka na webu mi taky připadají uplně odporné, tak mam nastavené, aby se automaticky ukládaly... protože nevidím žádný rozumný důvod, proč by měl prohlížeč prohlížet pdfka když to stejně dělá akrobat...
prostě to schizma verzí je fekál... když chcu dělat stránky, co si mám vybrat za standart? // 90% lidí co "delají stránky" beztak o tom, že na to existují standarty, nemá ani ponětí a používá FrontPage, ne-li Word...
řekl bych že nic převratného ale radši něco, co de prohlížet v prohlížeči, který používá většina lidí:(((
určitě nestojím o to, že IAček 6 nechápal aplication/xml+xhtml a pokoušel se s tim zachazet jako s aplication/octetstream... tudíž ukládal xhtml stránky s validním mime-typem... to si při vývoji stranky nemužu dovolit => budu srat na mime coz je velka chyba nebo pouziju html4 ktere tak jako castecne podporuje ten frontpejdž, ikdyž tam nepíšte ty doctypeovské hlavičky... -
Kolibáč (neregistrovaný)Už mě nebaví ty bitky mezi HTML a XHTML. Jsem příznivcem HTML 4.01 a XML. HTML 5 považuji za zbytečnost, v tomto případě podpořím XHTML.
Včera nám ale nešel proud a tak jsem potmě přemýšel. Vymyslel jsem jazyk kombinující XML, Python, PHP a preprocesor C. Ještě naprogramovat parser a browser a může začít nová éra Internetu... :-) -
Při nezaujatém pohledu je třeba konstatovat, že všechny ty HTTP, HTML, XML jsou vlastně naprosto nesmyslně použitou technologií.
Potřebujeme:
- Kotextovou komunikaci
- Změny částí stránky
- Oznámení změn serveru do prohlížeče
- Grafický design a pokročilé formátování textu
- Snadné parsování
Znásilňujeme k tomu staré protokoly, které jsou ve své původní definici:
- Bezkontextové
- Přenášející dokumenty v celku
- Kde server může pouze odpovídat klientovi
- Stavěné pro text s obtékáním obrázků a tabulkami
- S volnou syntaxi
Musíme používat berličky, jako jsou:
- Složité servlety, cookies, metody pro dodatečně přenášená data
- Rámce, pojmenováváné objekty speciálních vlastností, JavaScript ve spoluprácí se servlety (např. AJAX)
- Pravidelné kontroly stavu serveru napsané JavaScriptu
- Magii s tabulkami a detekcí prohlížečů.
Jediný problém, který byl zčísti vyřešen, je problém s komplikovaným parsováním - XHTML se podobá HTML, a lze jej snadněji parsovat. Dokud však existují stránky ve starém HTML, stejně jej nelze ignorovat.
Většina vědy a magie ve webdesignu je vlastně pouze obcházením problémů špatně zvolené technologie.
Který z těchto problémů řeší HTML 5? Pokud je neřeší, připadnou mi hádky o lomítko ve značce zcela nesmyslné. -
>Který z těchto problémů řeší HTML 5?
Ja vidim jako vyznamne Web Forms 2.0 http://www.whatwg.org/specs/web-forms/current-work/
Ty pro me resi dnesni omezeni formularu a celkem peknou cestou. HTML 5 IMHO vznika jako vedlejsi produkt a mozna trochu i z politickych duvodu. Proc by zde mohla byt na miste politika mozna nastini http://ln.hixie.ch/?start=1172653243&count=1 -
Ondrej 'SanTiago' Zajicek (neregistrovaný)> Potřebujeme:
...
No nevim, kdo ma byt implicitni 'my' a k cemu takove veci potrebuje. Nicmene vetsina tech veci me prijde, jako ze nijak nesouvisi s html strankami a jejich zakladnim smyslem - poskytovat informace v hypertextove podobe.
> Většina vědy a magie ve webdesignu je vlastně pouze obcházením problémů špatně zvolené technologie.
Mozna by bylo dobre, kdyby do prohlizecu nekdo implementoval X server (treba neco jako Xnest), takze ti, co chteji psat klient-server aplikace, by je mohli psat v nejakem beznem toolkitu a nemuseli by k tomu znasilnovat html. -
Na hypertext je html/http stále stejně dobrý. Pravda, zapomněl jsem ještě na další problém v původním návrhu, kvůli kterému se později vymýšlelo keep-alive - iniciace přenosu pro každý soubor zvlášť.
X server je také špatná technologie, pro její datovou nenažranost, zejména při přenosu obrázků. Tyto problémy se snaží řešit NX (narrow bandwidth X), ale to je také obcházením problémů, které by nemusely při jiném návrhu vzniknout. Ale by jistě v rámci X šla použít extenze, která by dekomprimovala obrázky až na straně "klienta" (X serveru), vykreslování kvalitních písem by se vrátilo zpátky do X (zde je menší problém - písma nepřítomná na straně klienta by se musely nějak přenášet). Další zúžení pásma by šlo dosáhnout vypínáním přenosu stavu vstupních zařízení, které zrovna nikdo nesleduje. Problém vidím také ve zvýšených HW nárocích na "server", který by tak byl vlastně X klientem.
Další možností implementace je na úrovni vhodného X toolkitu a jazyku postaveném nad ním. Tam by byly veškeré potřebné operace přímo k dispozici (tlačítka, formuláře, obrázky, dynamické operace, vnoření do okna, zpětná vazba). -
1 (neregistrovaný)Neni potreba zadny jiny jazyk, ale to co potreba je -> dodrzovat standardy a kaslat na software, ktery je nedodrzuje.
Ja usery M$IE banuju a zadny problem uz davno pri tvorbe webu _nemam_, vy ano? Pokud jste pomyslne pokyvali hlavou, dejte svemu problemu prave jmeno, problem s Micro$oftem a nikoliv problem s (X)HTML ! -
jaja (neregistrovaný)aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa akta x jsou aaaaaaaaaaaaaaaaaaujjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu super..................................................................................................................................................................................cus
-
- BUSINESS ANALYST (AUTOMOTIVE ONLINE SALES & DATA SCIENCE)
- Vývojář HW - elektronik, embedded - medical nebo šicí stroje
- Software Engineer - Back-End Developer (Java)
- PHP developer
- Systémový informatik
- Front-end developer/koder
-
- Budujte úspěšnou kariéru v jakémkoli věku!
- Úvod do řízení kvality
- Psaní e-mailů snadněji a rychleji
- Agilní (r)evoluce: Jak ustát agilní transformaci
- Myšlenkové mapy pro byznys i osobní život
- Kritické myšlení 6 - Mediální gramotnost a fact-checking
-
- PROJECT MANAGER & PRODUCT OWNER FOR APPS & DIGITAL WORKFLOWS
- Vývojář HW - elektronik, embedded - medical nebo šicí stroje
- PHP developer
- Web Frontend Developer
- Software Engineer .NET
- PHP/JS Developer(ka) pro Atmoskop.cz - projekt do konce roku
-
- Firemní telefonování v němčině
- Budujte úspěšnou kariéru v jakémkoli věku!
- Tipy a triky pro Excel
- Psaní e-mailů snadněji a rychleji
- Agilní (r)evoluce: Jak ustát agilní transformaci
- Myšlenkové mapy pro byznys i osobní život
