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é.
Suhlasim, spravny nazor.
Este by som dodal ze HTML ako take je hypertextovy jazyk primarne urceny na uladanie textovych dat s prelinkovanim tj. hypertext. To ze sa do toho narvalo x dalsich technologii a rozsiril sa aj o dalsie veci to je proste uz humus.
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).
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 !