No ja bych rekl, ze musi to byt levnejsi, protoze document.all.neco je kratsi, a tudiz to programator natuka rychleji a tim padem za mene penez. :-)
Jinak, je jasne, ze kdyz chci usertit kodovani, tak treba pouziji neco jako
function get(id)
{document.getElementById(id);}
a pak jen pouzivam get('neco'), coz je jeste kratsi nez document.all.neco. Nebo muzu zajit do extremu a udelat g('neco')
To neni pravda. Muzete rict, ze to treba nezajima vetsinu zakazniku. Ale jak velka ta vetsina bude bude zaviset na tom, v jakem oboru dany web podnika. Kazdopadne vzdy existuji lide, kteri sve penize pouziji nejen na prosty nakup, ale i na to aby tim, komu je daji ocenili i treba validnost webu.
Jo a standard se pise na oknci s d. Pismeno t z toho dela vlajku (standarta).
To me velmi zajima. Kolik je to "mnoho"? Dokazete to nejak vycislit.
Mimochodem, pokud se zakaznici zajimaji, zda jim ebanking pobezi v Mozille, nezajimaji se, zda je ten web v souladu se standardy, ale zajimaji se, zda jim pobezi v Mozille.
Tedy rikate, ze na celem svete neexistuje jediny zakaznik, ktereho zajima validita? Pokud totiz takovy zakaznik existuje je splneni jeho pozadavku vasim ziskem, ne? Na prvnim miste je spokojeny zakaznik, jak rikate.
Tvrdím tedy znovu, že pokud sice budu mít web validní, ale bez spokojeného zákazníka, tedy bez zisku, je mi takový web k ničemu.
Ano to je pravda. Ale fakt validnosti nijak neimplikuje zakaznika nespokojeneho, stejne jako nevalidita vebu neni zarukou komercniho uspechu.
Jistě, že se snažím získat co největší počet spokojených zákazníků, ale k tomu opravdu nepotřebuji míti úplně validní web (Nesmí být tedy úplně zmršený - nečitelný).
Pak asi kazdy chapeme jinak pojem co nejvetsi pocet. Koho odradi validni web? Ja si myslim, ze nikoho. Koho odradi nevalidni web? Ja si myslim ze nejakeho zakaznika.
Stačí se podívat na naše nejnavštěvovanější (předpokládám, že i vysoce výdělečné) e-obchody. Málokterý má plně validní web. Ale mají tisíce spokojených zákazníků, kteří často ani nevědí, jaký mají v PC Explorer.
Ale to prece nevypovida nic o tom, kolik zakazniku nemaji. To, ze nejvic lidi ma Windows, znamena, ze nikdo nema Linux?
ale na prvním místě zůstane (doufám) vždy spokojenost zákazníka = můj zisk.
Z jakych zdroju cerpate sve presvedceni, ze zadny zakaznik neodvozuje svou spokojenost od validity webu?
Automaticky samozřejmě nikoliv, ale ze všech možností je nejpravděpodobnější, že při použití této se web zobrazí korektně maximálnímu počtu prohlížečů.
A je dobré mít na paměti, že to platí zejména s ohledem na prohlížeče, které dosud neexistují. U těch to nemůžete řešit tak, že se podíváte, kdo má ve statistikách nad pět procent a pro něj to nějak upatláte. Nezbývá než se držet standardu a předpokládat, že autoři prohlížeče udělají totéž.
Lidi vubec nezajima kvalita. Protoze pokud ano, nenakupovali by na trzistich u vietnamcu.
Tot vase logika.
Anebo kdyz predelavas nejaky hotovy web do CSS. Samozrejme, udelas jej rovnou validni, nicmene, pri prevodu do sablony se k obrazkum automaticky priradi valign, border, vspace, bude chybet ukoncovaci lomitko, prvek
bude bez lomitka, budou chybet alty atd. A to vsecho musis dodatecne zjistit a opravit.
Viz dole poznamka o Euroskopu. Dodavatel dodal validni kod, pri prevodu se z toho stal nevalidni kod. A pokud by Euroskop chtel validni web, nekdo to nekdo dodatecne opravit (a tomu cloveku se samozrejme musi zaplatit).
Samozřejmě že mám-li nevalidní web a chci z něj udělat validní (nebo z tabulkového layoutu udělat CSS layout), je to práce navíc. Ale zrovna tak je práce navíc, pokud chci z validního webu udělat nevalidní (nebo z CSS layoutu tabulkový). To o ničem nevypovídá. Tady šlo o srovnání náročnosti vytvoření celého webu od nuly - v takové situaci žádné nevalidní přechodové stádium není potřeba.
Ve zmíněném případě Euroskopu by stačilo, aby ti, kdo dělali dodatečné úpravy, znali svou práci a své úpravy prováděli rovnou korektně. Nebylo by potřeba, aby ten web nejdříve zmršili a pak ho pracně opravovali.
Jedním možným řešením je apelovat na profesionální čest autorů, ale to se dnes bohužel moc nenosí - a nejen u tvůrců webů. Takže bych to viděl spíš na osvětu zaměřenou na zadavatele, aby se požadavky validity a přístupnosti staly v co největší míře součástí zadání. Výjimku tvoří státní správa, tam by takový požadavek měl být IMHO dán zákonem.
To je zrovna věc, o které by se dalo dlouze diskutovat. Existují argumenty, které mluví pro navigaci na konci, ale jsou i takové, které mluví spíš pro navigaci na začátku. Nedá se říci, že by jedna varianta byla univerzálně lepší než druhá.
Musíte rozlišit základ, tj. (X)HTML, a doplňkové technologie. Pokud prohlížeč nepodporuje doplňkovou technologii, je to na úkor komfortu, ale nesmí to být na úkor použitelnosti. Neumí-li CSS, nebude stránka vypadat tak hezky a nebude tak přehledná, ale pořád uvidím všechno. Neumí-li JavaScript, možná budou některé věci pomalejší (spletu-li data, upozorní mne na to server - stejně je musí zkontrolovat), něco nebude tak pohodlné, ale všechno bude fungovat. Neumí-li Flash, přijdu o některé zajímavé efekty, ale pořád vidím veškerý obsah a mám k dispozici všechny funkce. Tak vypadá dobře napsaný web.
Tak je JavaScript součástí normy (X)HTML, nebo ne ? Co mi je potom, když si ho uživatel vypne?
JavaScript není součástí normy (X)HTML. Součástí normy je způsob, jak client-side skripty do dokumentu vkládat. Ale nic se tam nepíše o tom, že by prohlížeč (X)HTML musel některé konkrétní skripty umět interpretovat. Ostatně, kdyby tomu tak bylo, k čemu by byl podle vás element noscript?
Můj zájem je, aby uživatel pokud možno odesílal na server jen validní data, zvlášť když browser tu validaci umožňuje. Validací šetřím jeho čas a koneckonců i bezpečnost (omezuji tím zbytečný POST dat na server).
Server ta data stejně zkontrolovat musí. Takže má-li klient zapnutý JavaScript, zkontroluje mu to client-side skript. Má-li ho vypnutý (nebo nemá-li ho vůbec), zkontroluje mu je server. Konkrétně to vypadá tak, že v dokumentu jsou všechny prvky formuláře enabled a disablují se teprve skriptem při načtení stránky. Tím je zajištěno, že formulář bude plně funkční i bez JavaScriptu.
Připomínáte mi zedníka, který ještě nemá hotové základy domu a chystá se instalovat na (neexistující) střechu televizní anténu. Pokud nechápete, na co narážím, pak třeba na to, že více než pět let po specifikaci CSS Level 2 nepodporuje poslední verze MSIE ani CSS Level 1. O svérázném výkladu některých prvků HTML ani nemluvě. Až zvládne MSIE trochu slušně aspoň základní věci (HTML, CSS), můžeme se bavit o standardizovaných nadstavbách (tj. ne věci jako VBScript nebo cokoli postaveného na ActiveX).
a to nemluvím o Macromeda Flash formátu (který dokazuje, že to jde i bez norem, když vývoj garantuje jedna firma)
Právě že to dokazuje, jak to nejde. Jakmile se stanete závislým na jedné firmě, je po přenositelnosti, po možnosti volby.
Právě kvůli Lynxu se i dnes vyplatí layoutovat tabulkami atd... Nejspíš jste ten soft v životě neviděl.
S lynxem pracuji docela běžně, mimo jiné v něm kontroluji každý svůj výtvor. Právě tabulkové layouty v něm dopadají naprosto strašidelně, protože při absenci té tabulky se k sobě dostanou věci, které vedle sebe nemají co dělat, a věci, které k sobě patří, jsou daleko od sebe. S dobře navrženým CSS layoutem tento problém nevznikne.
Že lynx nepodporuje XSL transformace, bych mu za zlé neměl. Je to totiž HTML prohlížeč. Po HTML prohlížeči těžko chtít, aby komfortně zobrazoval XML. Pokud něco takového chcete, není problém XML předem prohnat filtrem, který tu transformaci provede. Předpokládám, že v dohledné budoucnosti bude tato schopnost (volitelnou) součástí lynxu.
Na základě statistiky se domnívám, že pod Linuxem neběží ani jedno procento browserů - stačí takto?
Nemá smysl se dohadovat, zda je to jedno procento, pět procent nebo třeba jedno promile. Podstata je jinde: co z toho vyplývá? Že tito uživatelé nemají právo prohlížet si webové stránky?
Podpora HTML je u HTML prohlížeče naprosto zásadní věcí. Na druhém místě je to dnes, vzhledem ke snaze o oddělení prezentační a obsahové složky v novějších verzích HTML, podpora CSS. Cokoli dalšího je navíc. Pokud prohlížeč hrubě nezvládá tento základ, jsou hračičky okolo k ničemu. Stejně tak, jako neocením u auta přehrávač CD a dřevěnou palubní desku, pokud nebude dobře jezdit.
I tam je však nutné zvažovat kompromis mezi multiplatformitou a konformanci se všemi možnými standardy - nebo snad státní organizace nemusí peníze počítat?
Už to tu padlo několikrát, není to pravda. Přenositelný a standardy dodržující web je stejně náročný (často i méně) na vytvoření a výrazně méně náročný na údržbu. Dodržování standardů je navíc jedinou šancí, jak zajistit kompatibilitu s neznámými nebo budoucími prohlížeči.
Zvlášť když vidíte sám, že zmíněné "standardy" nejsou vzájemně kompatibilní.
Tohle mi nějak uniklo, co máte konkrétně na mysli?
Kdyby bylo jen na W3C - nebylo by DHTML, ani ten Flash.
S tím DHTML trochu nechápu, Flash je čistě proprietární doplňková technologie. Pokud je použit tak, aby byl web kompletní a plně funkční i bez něj, je věc každého, zda o něj stojí. Za sebe musím říct, že absence chrčících, pípajících, text překrývajících a procesor vytěžujících reklam by mi vyvážila těch pár stránek, kde je Flash skutečně použit k něčemu užitečnému. Je-li použit tak, že stránka je bez něj nekompletní nebo (částečně) nefunkční, je to jednoznačně chyba.
Co se tagu LINK týče, oba nejrozšířenější browsery (95%+ market share) Netscape i MSIE jej úspěšně ignorují už od verze HTML 3.2.
Nezkoušel jsem nové verze, ale vzhledem k tomu, že od verze 6 používá Netscape stejné renderovací jádro jako Mozilla, která element link implementuje, předpokládám, že nemáte pravdu. Mimochodem, co myslíte termínem market share? Myslel jsem, že to znamená podíl na trhu - jenže jaksi žádný trh nevidím.
tím spíš, že se většina provozovatelů snaží uživatele od fyzické struktury webu z nejrůznějších důvodů naopak odstínit
A proč si myslíte, že navigace pomocí elementu link by měla odrážet fyzickou strukturu webu? Samozřejmě že by měla odrážet logickou strukturu.
Nevím, zda o tom víte, ale Microsoft se také pokusil po svém rozšířit protokol TCP. V tomto případě mu to naštěstí neprošlo, protože mezi webovými servery nemá většinu, takže na to jeho uživatelé dopláceli. Dokážete si představit tu katastrofu, kdyby v oblasti síťových protokolů panoval stejná džungle jako u HTML. Kdyby si každý výrobce vylepšoval standardy po svém?
Opakuji to tady již po třetí: tag <br /> neodpovídá normě HTML 3.0+ - stejně jako DOCTYPE - není s ní kompatibilní zdola... XHTML je prostě ve vztahu k nepárovým značkám HTML nový jazyk, ne nadmnožina starého.
Ano, XHTML je nový jazyk. Musí být, protože je aplikací XML, což HTML není. Že HTML před 4.0 neobsahovalo informaci o verzi, je smůla, ale nějak se zavést musela. To byste také mohl tvrdit, že HTTP není žádný standard, protože hypotetický server striktně vyžadující HTTP/0.9 nebude rozumět HTTP/1.0 requestu. Navíc je syntaxe deklarace doctype záměrně zvolena tak, aby ji prohlížeč, který jí nerozumí, musel ignorovat.
Musíte si uvědomit, že HTML 3.0 (nebo spíš 3.2) vznikalo bez koncepce jako zoufalá snaha popsat ex post to podstatné z živelného vývoje, kdy si každý rozšiřoval a upravoval jazyk HTML po svém. Teprve HTML 4.0 je norma, kterou lze považovat za koncepční a základ, na kterém se dá stavět. Ohánění se HMTL 3.2 je dnes poněkud bezpředmětné a slouží spíše jako nejapná výmluva těch, komu se nechce dodržovat zásady, které přináší HTML 4.0. Ti ovšem většinou sami HTML 3.2 nedodržují, protože se bez jiných prvků HTML 4.0(1) nedokáží obejít.
To platí opravdu jen teoreticky - v praxi je stránku odladěnou pro robustní renderer MSIE mnohem obtížnější přinutit ke korektní funkci i pod Netscape a staršími verzemi Opery. V praxi se na úpravy pro minoritní prohlížeče vynakládají srovnatelné částky, jako na primární verze odladěné ve MSIE, protože jak MSIE, tak Opera interpretuje Mozillu jinak a zpravidla mnohem méně robustněji. Kdyby tomu tak ostatně nebylo, ani bychom se tu o tom koneckonců nebavili.
To opět vychází z mylného názoru, že je třeba web nejdříve napsat pouze pro MSIE a pak ho teprve začít upravovat tak, aby prošel i jinde. Ve skutečnosti lze postupovat i obráceně: napsat web přenositelně a v souladu se standardy. V Mozille (Netscape) a Opeře to v naprosté většině případů stačí, v Konqueroru (Safari) také (většinou jen pár kosmetických vad). Vyhnete-li prvkům, o kterých je známo, že je MSIE interpretuje špatně, znamená doladění pro MSIE 5.5+ relativně nevelkou práci navíc. Pokud chcete, aby to vypadalo bezvadně i v MSIE 5.0 (bez kosmetických vad), je to práce trochu víc, ale snazší údržba takového webu (zejména při změnách designu) vám to bohatě vynahradí. To není teorie, to je praxe (a nejen moje). Chce to jen netrvat na zastaralých postupech (zbastlím to metodou pokus-omyl pro svou verzi MSIE a ostatní, ať si ji seženou).
předpokládám, že nemáte pravdu... Předpokládám tedy, že to nevíte..?
Napsal jsem předpokládám, protože jsem to, striktně vzato, v Netscapu nezkoušel. Protože ale používá stejné renderovací jádro jako Mozilla, kde to funguje, mám velmi závažný důvod věřit.
existují celé weby psané ve Flashi, jsou velmi efektní, dynamické, při správném návrhu nejsou nijak náročné na technické vybavení prohlížeče a nemají problém s funkcionalitou na různých platformách.
za prvé: nejsou to weby, smyslem webu je univerzalita. Takové prezentace mohou být zajímavé, efektní, mohou mít skvělé funkce, ale nejsou to weby. To už můžete rovnou distribuovat hotové aplikace, není v tom podstatný rozdíl. Za druhé: jsou náročné - na systémové zdroje klienta. U výkonného PC to (obvykle - jsou výjimky) nepoznáte, se slabším hardwarem budete mít velké problémy. Za třetí: mají problém s funkcionalitou na různých platformách. Většinou stačí, abyste neměl právě tu verzi Flashe, kterou použil autor, a hned máte problém. O prohlížečích, které z dobrých důvodů Flash nemají vůbec, ani nemluvím. Opravdu si myslíte, že je rozumné cpát Flash do handheldů?
Tak ještě jednou, třeba už si to konečně přečtete: napíšete-li stránky v souladu se specifikacemi (X)HTML a CSS a vyhnete-li se těm prvkům, o kterých je notoricky známo, že nejsou (především v MSIE) podporovány, případně, že jsou (především v MSIE) interpretovány chybně, bude vám to fungovat. Nemusíte psát stránku pro konkrétní prohlížeč a pak dlouze zkoušet, zda funguje i v dalších. Právě k tomu slouží standardy, ne k buzerování autorů. Prostě tu stránku napíšete v určitém jazyce, ne pro určitý prohlížeč. Chápu, že pro spoustu lidí je to obrovský myšlenkový zlom a není jednoduché si zvyknout, že se to dá dělat i jinak než metodou pokus-omyl, ale je to tak.
už dnes se nedostanete zhruba na 40% placeného obsahu webu a přibližně stejné procento stránek vyžaduje nějaké rozšíření:
Tak to ani omylem. Kdybyste v obou případech napsal deset procent, asi bych se hádal, že to je méně. Takhle to nemůžu brát vůbec vážně. Ve druhém případě ovšem kladu důraz na slovo vyžaduje - kdybyste místo něj napsal využívá, asi byste měl pravdu, ale to není důležité. Právě rozdíl mezi využívá a vyžaduje je to, o čem tu celou dobu mluvím.
Vaše body A až D znějí rozumně a až na drobné výhrady s nimi v zásadě souhlasím. IMHO jste však zcela "ujel" s tvrzením, že "nemá však smysl vyvíjet pro ty, co web procházejí třeba v Lyxu, resp. takový vývoj není rentabilní - proděláváte už ve chvíli, kdy ho realizujete." Argumentů, které tento názor zpochybňují, je hned několik:
O rentabilitě "vývoje" stránek pro Lynx nemá smysl hovořit, protože uzpůsobení pro tento prohlížeč nestojí ani ň. Samozřejmě to platí za předpokladu, že web tvoří erudovaný kodér. Pokud ho tvoří neschopný amatér, proděláte z mnoha důvodů pravděpodobně mnohem víc, než kolik na jeho práci ušetříte.
Je bláhové se domnívat, že Lynx a jiné textové prohlížeče s minimální funkčností používají jen podivné existence, které si na Webu nikdy nic nekoupí. Osobně znám několik (asi 5) lidí, kteří tyto prohlížeče používají dost často a na Webu utrácejí nemalé částky. Jeden z nich je dokonce vysoce postavený diplomat.
Nejde-li web dobře procházet Lynxem, je pravděpodobně nepřístupný i pro roboty vyhledavačů. Pak ovšem přicházíte opravdu o hodně peněz, protože to u mnoha webů znamená prakticky nenahraditelnou ztrátu až 70% potenciální návšěvnosti.
Víc viz můj starší, avšak dosud platný článek Chudým vstup zakázán (Interval.cz, 10.1.2002).
Pokud ten web hodláte vytvořit na půl roku a pak zrušit, pak možná. Jinak rozhodně ne. Pokud ho hodláte jakkoli rozvíjet nebo použít za základ nové verze, se standardy jednoznačně ušetříte.
Zavádějící časové údaje už byly opraveny, pokusím se k těm standardům HTML ještě dodat pár poznámek. HTML 3.2 a starší byly spíše takovým pokusem o popsání společného základu, který vyšel z živelného a chaotického vývoje webu v polovině devadesátých let. Teprve HTML 4.0 je standardem v pravém slova smyslu. A je navrženo (s ohledem na oddělení vizuální informace do stylesheetu) natolik dobře, že ho dodnes prakticky nebylo třeba vylepšovat (verze 4.01 je, jak už číslování napovídá, jen drobnou revizí). Sice vzniklo XHTML 1.0, ale to je nutný důsledek nástupu XML. Vzhledem k rostoucímu množství aplikací pracujících s XML je rozumný požadavek na úpravu HTML do podoby, která vyhovuje striktním požadavkům XML - a XHTML 1.0 není v podstatě nic jiného než taková úprava HTML 4.01.
Takže rozhodně nesouhlasím s názorem, že pánové od zeleného stolu si co pár měsíců pro vlastní zábavu vydají novou verzi HTML a chudáci autoři stránek aby je s vyplazeným jazykem sledovali. Ve skutečnosti můžete mít své weby už více než pět let v HTML 4.0 a CSS Level 2 a nic vás nenutí k přechodu na nový standard. Přechod na XHTML má smysl pouze u nových projektů (z hlediska dlouhodobé perspektivy) nebo tam, kde potřebujete využívat nástroje založené na XML.
A ty smartmobily si daleko lépe poradí s korektně a přehledně napsaným HTML 4.01 + CSS Level 2 (kterýžto budou ignorovat) než s HTML 3.2 s chaotickou strukturou; udržení přehledné struktury webu v HTML 3.2 je sice možné také, ale vyžaduje to dost velkou sebekázeň a specifikace vám v tom spíš překáží (nemáte např. atributy class nebo id).
Sloupcový layout se také pomocí CSS řeší snadno a pohodlně. Navíc vám umožňuje triky, které jsou tabulkami prakticky nedosažitelné - např. pokud chcete pro text hlavního sloupce využít i prostor pod menu.
colspan docílil toho, aby anotace článků vyplnily i prostor pod pravým informačním sloupce. Samozřejmě bez toho, abyste musel po přidání každého nového článku zkontrolovat, kolik anotací se vejde vedle toho pravého sloupce.
proc vlastne tvorit design, kdyz ho muzete ukrast, co?
viz VELMI napadna podobnost vasich uzasnych stranek s http://www.guistuff.com ...
uz se tesim na vas dalsi clanek a preji hodne uspechu, snad se konecne dockate mercedesu a domecku s vezickami kousek za prahou.