« 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 »
Autor Zpráva
Chamurappi
Profil
Reaguji na Jokera:
Takže má dvě možnosti: buď se s tím nějak vypořádá, nebo prostě nebude kompatibilní s XHTML.
Žádný dnešní prohlížeč není při „text/html“ kompatibilní s XHTML.

S text/html může a nemusí [být uzavřený], podle rozhodnutí prohlížeče.
Která specifikace říká, že se smí takhle rozhodovat? Smí také hlásit fatální chyby, není-li HTML kód správně sestavené XML?

Ještě před pár týdny jsi pod testem konzistence tvrdil:
Proto jsem taky dal odpověď "teoreticky" - přesně podle specifikace a "prakticky" - podle skutečné implementace té specifikace. To "teoreticky" je, co bych po přečtení specifikací od ideálního prohlížeče očekával
Nyní tu máš nástroj, který slouží ke kontrolování onoho ideálu a který se chová tak, jak bys od ideálního prohlížeče očekával. A najednou říkáš, že validuje špatně.

(Tuhle konstrukci není dovoleno posílat jako text/html, takže když to udělám, můžu čekat problémy)
V HTML 4 to dovoleno je.

Zase si hrajeme se slovíčky... Ano, je to "Striktně vyhovující XHTML dokument"
Snažíme se vysvětlit, že vyhovění a validita jsou dvě různá měřítka. Právě ses přesvědčil, že vyhovující dokument nemusí být validní, takže validátor označující vyhovující dokument za nevalidní může být v naprostém pořádku.

Mohl bys mi odpovědět ještě na dvě dodatečné otázky testu konzistence?
Jak myslíš, že by měl správný prohlížeč interpretovat při „text/html“ následující konstrukce?

[7] <?instrukce >něco<?instrukce?>
-- a) něco
-- b) nic
-- c) selhat

[8] <?instrukce ><!--<?instrukce?>něco<?instrukce >--><?instrukce?>
-- a) něco
-- b) nic
-- c) selhat
Joker
Profil
Žádný dnešní prohlížeč není při „text/html“ kompatibilní s XHTML.
Noo, takový příklad:
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1250" />
<title>Pokus</title>
<style>
.pokus{color:red;}
</style>
</head><body>ahoj</body></html>

Podle HTML: Prvek <html> obsahuje <head> a dva prvky <body>. Prvek <head> obsahuje <meta>, první prvek <body> obsahuje znaková data (">") a prvky <title> a <style>. Druhý prvek <body> obsahuje znaková data ("ahoj")

Podle XHTML: Prvek <html> obsahuje prvky <head> a <body>. Prvek <head> obsahuje prvky <meta>, <title> a <style>, prvek <body> obsahuje znaková data ("ahoj")

Mimochodem, názorná ukázka té mnou kritizované vlastnosti HTML, že dokument se ve skutečnosti může zpracovat úplně jinak, než jak to vypadá ze zdrojáku (tady je příčinou, že prohlížeč by ukončil <meta> už lomítkem a většítko měl brát jako znaková data, která nejsou dovolena v hlavičce, takže by si měl domyslet konec hlavičky a začátek těla, ve kterém ale zas není povoleno <body>, takže by si před dalším <body> měl domyslet konec předchozího <body>).

Podle DOM inspectoru v Opeře je zpracování uvedeného kódu Operou stejné, jako ta varianta "Podle XHTML". Takže v tomhle případě je s XHTML kompatibilnější než s HTML.

Která specifikace říká, že se smí takhle rozhodovat?
Právěže žádná- specifikace (XHTML) tu konstrukci zakazuje, ale nevyžaduje nějaké konkrétní chování prohlížeče. Takže cokoliv je správně :)

Snažíme se vysvětlit, že vyhovění a validita jsou dvě různá měřítka.
No ale jak může tamten dokument vyhovovat XHTML 1.0 Strict, když obsahuje značky, které XHTML 1.0 Strict nezná?

Ad test: Já už to zkrátím. Předpokládám, že cílem je dokázat, že je minimálně hodně obtížné doslovně dodržovat XHTML specifikaci a současně doslovně dodržovat HTML specifikaci. Fajn, to uznávám a ani jsem to nepopíral, ale pořád tvrdím, že není zas takový problém implementovat XHTML specifikaci a současně dodržovat HTML specifikaci tak, jak byla implementována. Podle mě by nejjednodušší řešení toho teoretického rozporu bylo to upravit v HTML specifikaci. Věci jako NET se stejně v prohlížečích nikdy nepoužívaly, takže by stačilo je formálně zrušit. Problémy s kompatibilitou nula, dopad na existující stránky nula.
Chamurappi
Profil
Reaguji na Jokera:
Poslední čtyři stránky mluvíme hlavně o validátoru. Tvůj postoj k chování prohlížečů je již dávno jasný. Oficiální validátor považuje HTML dokument s XHTML <!doctypem> za XML -- ptal jsem se, jestli je chybou stávajících prohlížečů, že nepostupují stejně jako W3C Validátor. Tys to úplně zakecal. Máš na to talent.

Podle XHTML: Prvek <html> obsahuje prvky <head> a <body>.
Podle XML: Není to XHTML, neboť chybí deklarace jmenného prostoru.

Takže v tomhle případě je s XHTML kompatibilnější než s HTML.
Najdu ti jednoduše desítky protipříkladů, kdy se HTML prohlížeče chovají v naprostém souladu s HTML specifikací (a navzdory XHTML).

specifikace (XHTML) tu konstrukci zakazuje, ale nevyžaduje nějaké konkrétní chování prohlížeče. Takže cokoliv je správně :)
Takže správně je to, co říká specifikace, která nějaké konkrétní chování vyžaduje.

No ale jak může tamten dokument vyhovovat XHTML 1.0 Strict
Nemůže, XHTML 1.0 Strict není specifikace, ale jen DTD. Neopakuji se? Vyhovění a validita jsou dvě různá měřítka. Neopakuji se?
1) Při „text/html“ vyhovuje XHTML specifikaci a není validní XHTML 1.0 Strict kvůli vadné DTD a <menu>.
2) Při „application/xhtml+xml“ vyhovuje XHTML specifikaci a není validní XHTML 1.0 Strict kvůli <menu>.

Ad test: Já už to zkrátím.
Ne, já to zkrátím: odpověz, prosím, na ty dvě otázky.

Věci jako NET se stejně v prohlížečích nikdy nepoužívaly
Věci, na něž se ptám v otázkách [7] a [8], v prohlížečích krásně fungují a nikdo je nikdy nezakázal. Zapomeň na NET, nekompatibilit jsou mraky, podobnost těch jazyků je jen zdánlivá.

Problémy s kompatibilitou nula
Stejně jako u většiny nevalidních stránek. Má se kvůli tomu validátor chovat jinak než ideální parser?
Joker
Profil
ptal jsem se, jestli je chybou stávajících prohlížečů, že nepostupují stejně jako W3C Validátor
Není, prohlížeč nepotřebuje dělat nějaký výrok o validitě stránky, stačí, když jí správně zobrazí.

Není to XHTML, neboť chybí deklarace jmenného prostoru.
Nonono. XHTML specifikace říká u jmenného prostoru "měl by" (should) a ještě navíc jen z XML MIME.

Takže správně je to, co říká specifikace, která nějaké konkrétní chování vyžaduje.
Ano, i to patří pod "cokoliv" :-)

Nemůže, XHTML 1.0 Strict není specifikace, ale jen DTD.
No a XHTML specifikace je sada tří DTD... nějak mi uniká, o co se vlastně dohadujeme.

odpověz, prosím, na ty dvě otázky.
Budiž: 7 - a) a 8 - b) v souladu s oběma specifikacemi (pro jistotu připomínám náš oblíbený dodatek C: "(při posílání XHTML s text/html) Mějte na paměti, že procesní instrukce mohou být v některých prohlížečích vyrenderovány.")
Chamurappi
Profil
Reaguji na Jokera:
Není, prohlížeč nepotřebuje dělat nějaký výrok o validitě stránky
Hm. Zkusím tu svoji otázku zjednodušit, čti ji pomalu a soustřeď se, prosím:
Je chybou stávajících prohlížečů, že nepovažují HTML (tj. „text/html“) dokument s XHTML <!doctypem> za XML?

XHTML specifikace říká u jmenného prostoru "měl by" (should) a ještě navíc jen z XML MIME
Ne. To sis vymyslel, nic takového neříká.

Ano, i to patří pod "cokoliv" :-)
Ne, to patří místo „cokoliv“. Jedna specifikace říká „má to být tak“, druhá říká „nic neříkám“.

nějak mi uniká, o co se vlastně dohadujeme
Zjevně. Obvinil jsi validátor ze lži, označí-li vyhovující dokument za nevalidní. Vyvracím ti to.

7 - a) a 8 - b) v souladu s oběma specifikacemi
Ne, to je v souladu pouze s HTML specifikací. Pro XHTML platí pravý opak.
Joker
Profil
Je chybou stávajících prohlížečů, že nepovažují HTML (tj. „text/html“) dokument s XHTML <!doctypem> za XML?
Není, XHTML posílané s typem text/html musí dodržovat dodatek C právě proto, aby ho existující prohlížeče správně zpracovaly i když ho nezpracují jako XML.

Ne. To sis vymyslel, nic takového neříká.
Opravuji se, není to přímo ve specifikaci, ale v téhle poznámce, která sice není normativní, ale přesto v ní samotné W3C říká, že namespace v dokumentu být nemusí.
A mimochodem se tam i jasně říká, že XHTML nedodržující dodatek C by se nemělo (SHOULD NOT) posílat jako text/html.

Obvinil jsi validátor ze lži, označí-li vyhovující dokument za nevalidní. Vyvracím ti to.
Hm, venku je tak krásně a my se tu budeme dohadovat, jestli jsem měl napsat "dokument vyhovující XHTML" anebo "dokument vyhovující XHTML specifikaci a současně vyhovující příslušné XHTML DTD". Není to už trochu na hlavu?

Ne, to je v souladu pouze s HTML specifikací. Pro XHTML platí pravý opak.
Viz to co jsem napsal:
pro jistotu připomínám náš oblíbený dodatek C: "(při posílání XHTML s text/html) Mějte na paměti, že procesní instrukce mohou být v některých prohlížečích vyrenderovány."
Tin
Profil
Není, XHTML posílané s typem text/html musí dodržovat dodatek C právě proto, aby ho existující prohlížeče správně zpracovaly i když ho nezpracují jako XML.
Ale pak to je HTML a ne XHTML.
K čemu nám je pak xhtml dobré? JEDINNÁ jeho výhoda(teoreticky) zmíněná na SEDMNÁCTI STRÁNKÁCH tohoto tématu je: Abychom ho mohli zpracovat XML-nástroji.
Html by tak šlo zpracovat úplně stejně. Mezi XH a H jsou dva rozdíly: X má na začátku zbytečné kecy (na vlastní zpracování nemají žádný vliv); H neuzavírá některé tagy (což by zase nebyl takový problém dodělat).
Pak by tu byla třetí pseudovýhoda -- "X" je módní.
Chamurappi
Profil
Reaguji na Jokera:
Není
V tom případě ani český validátor není chybný. Souhlas?

<mimo-téma>
Opravuji se, není to přímo ve specifikaci
Ve specifikaci je, že deklaraci jmenného prostoru obsahovat musí. Kdybych nedůvěřoval tvé bystrosti, odkázal bych tě znovu na těch pět podmínek.

v téhle poznámce, která sice není normativní, ale přesto v ní samotné W3C říká...
Poznámka nevyjadřuje stanovisko W3C (dle svých slov).

namespace v dokumentu být nemusí
Bez deklarace jmenného prostoru neexistuje spolehlivý způsob, jak XHTML elementy rozeznat.
</mimo-téma>

my se tu budeme dohadovat, jestli jsem měl napsat "dokument vyhovující XHTML" anebo "dokument vyhovující XHTML specifikaci a současně vyhovující příslušné XHTML DTD"
Jenže on proti té DTD validní není, takže validátor zcela oprávněně hlásí chyby. Oháníš se slovíčkařením, ale od počátku tu mixuješ dohromady dvě různé věci.

pro jistotu připomínám náš oblíbený dodatek C
Dodatek C říká, že některé prohlížeče procesní instrukce zobrazují (tj. ukáží celý kus kódu návštěvníkovi). Na popsanou situaci se nevztahuje -- žádný známý prohlížeč od roku 1997 nezobrazuje procesní instrukce. Všechny ale správně předpokládají, že instrukce končí samotným většítkem. Je to další z mnoha nekompatibilit mezi HTML a XML.

Jak má konec procesní instrukce určit validátor? Musí si jeden způsob vybrat. Podle čeho má vybírat?
Joker
Profil
Tin
No jelikož myšlenka XHTML byla vzít HTML a přeformulovat ho do XML, dá se tak nějak očekávat, že hlavní rozdíl mezi HTML a XHTML bude, že XHTML je XML :-)

Chamurappi
V tom případě ani český validátor není chybný. Souhlas?
:-) Postup validátoru střídavě hájíš tvrzeními "Sice se takhle žádný prohlížeč nechová, ale validátor se musí byrokraticky držet specifikace" a "Validátor to takhle dělá proto, že to tak dělají prohlížeče".

W3C validátor se "byrokraticky drží specifikace", pokusí se rozlišit HTML a XHTML a validovat každé proti "své" specifikaci. Pokud si není jistý, napíše varování: "MIME typ tohoto dokumentu se může použít pro SGML i XML dokument a nemohl jsem určit, o co přesně jde. Zkouším validovat podle SGML".
Validátor w3.cz kombinuje byrokratické dodržování specifikace a upřednostňování implementace v prohlížečích tak, aby nebylo možné vytvořit validní XHTML s typem text/html.

Tím dokonce vzniká kuriózní situace, kdy se validátor pouští do sporu se specifikací, jejíž dodržování má kontrolovat!

Jenže on proti té DTD validní není, takže validátor zcela oprávněně hlásí chyby.
Nojo, a kdyby se tam náhodou žádná nedala najít, napíše chybu "Váš dokument není validní, protože XHTML specifikace je špatně" (formulováno jako "Odkázaná definice typu dokumentu je pravděpodobně pokažená"... připomínám, že DTD je normativní součást specifikace).
Nastává další kuriózní situace, kdy mi validátor řekne, že můj dokument neodpovídá specifikaci, protože samotná specifikace neodpovídá sama sobě :-)
Chamurappi
Profil
Reaguji na Jokera:
"Sice se takhle žádný prohlížeč nechová, ale validátor se musí byrokraticky držet specifikace"
Prohlížeče mají k tomu chování dost blízko. Kdyby NET-zápis neexistoval, tak by validátor měl hlásit přebytečné lomítko v každé prázdné značce. Zkus si tam nacpat místo něj obrácené lomítko a uvidíš, jak dopadneš -- z hlediska prohlížečů stejně (chyby tolerují), ale validátor ti ukáže stejný počet chyb, jako kdyby NET neexistoval.

"Validátor to takhle dělá proto, že to tak dělají prohlížeče"
Validátor to takhle dělá proto, že by to tak měly dělat prohlížeče. A dělají. Ptám se tě: je to špatně? Ne, není to špatně. A český validátor je špatně? Jasně, ten špatně je, protože tu někdo má příliš rád XHTML, než aby uznal pravdu.

Tím dokonce vzniká kuriózní situace, kdy se validátor pouští do sporu se specifikací, jejíž dodržování má kontrolovat!
Nemá. Nikdy neměl. Má trpělivost je u konce, nastav mozek, stisknu spoušť. Validátor kontroluje pouze validitu.

napíše chybu "Váš dokument není validní, protože XHTML specifikace je špatně"
V DTD skutečně jsou chyby, elementům schází údaj o volitelnosti značek. Mohl bych ve výjezdu chyb všechny problémy vyjmenovávat.
Ano, v tomto ohledu není specifikace zrovna rozumně napsaná, jelikož nabádá k užívání nevalidního HTML kódu. Tu DTD šlo napsat tak, aby dávala smysl i u „text/html“ dokumentů.

Validátor w3.cz kombinuje byrokratické dodržování specifikace a upřednostňování implementace v prohlížečích
K čertu s byrokracií, u nosu máme mnohem realističtější příklady. Vraťme se k procesním instrukcím. Ptám se znovu:
Jak má konec procesní instrukce určit validátor? V závislosti na čem se má rozhodnout mezi „>“ a „?>“?
Joker
Profil
Má trpělivost je u konce, nastav mozek, stisknu spoušť.
Zdá se, že se shodneme na tom, že se neshodneme :-)

Můj postoj ve sporu XHTML vs. HTML je pořád takovýhle:
1. Při tvorbě stránek má XHTML v některých případech výhody, v jiných ne. Nenutím nikoho přepisovat už napsanou XHTML/HTML stránku do HTML/XHTML, pokud k domu nemám pádný důvod. Vím, že bych tím dotyčnému zbytečně přidělal práci.

2. XHTML lze odesílat i s typem text/html za účelem kompatibility se současnými prohlížeči. Specifikace to dovoluje a prohlížeče s tím nemají problém. Musím ale dodržovat určitá omezení (onen dodatek C). I když jsem si vědom, že jsou tam určité třecí plochy mezi doslovným zněním XHTML a HTML specifikací, nevidím to jako velký problém. Prostě se vycházelo z implementace HTML normy, která se ustálila trochu někde jinde, než doslovné znění normy. Nakonec, normy pro web jsou normy de facto, nikoliv de iure, a není snad jediná z nich, která by byla implementována doslovně.

3. Nevidím důvod, proč by validátor XHTML kódu měl označit XHTML kód plně odpovídající specifikaci (což zahrnuje i DTD) za nevalidní. Tím spíš je podivné, pokud za důvod nevalidity dokumentu označí samotnou specifikaci.
Kolem a kolem, možná by měl validátor v případě chybné DTD raději ukončit validaci. Proč validovat dokument podle něčeho, co je špatně?

Podle mého názoru mám pro každý z těch tří bodů dostatek argumentů i po přečtení těch 18 stránek tady. Přitom ani na jednom z nich se neshodneme.
Chamurappi
Profil
Reaguji na Jokera:
Jak má validátor určit konec procesní instrukce? V závislosti na čem se má rozhodnout mezi „>“ a „?>“?
Pajuc
Profil *
Chtěl bych reagovat na Tinův názor, že jediná výhoda XHTML spočívá v tom, že jde zpracovat XML nástroji.
To, co mě na XHTML hned na počátku zaujalo byla jeho jednoduchost oproti HTML. Vzpomínám si na své začátky a jak jsem přemýšlel, který atribut se píše s uvozovkami a který ne, nebo na trable s ukončovacím tagem (patří tam </LI> nebo nepatří?). Nevzrušuje mě dokonce ani to sexy X, logičtější by mi připadalo, kdyby se nepostuloval s velkou slávou jakoby nový jazyk, ale jen se změnila pravidla u toho starého.
XHTML se IMHO prosadí. Jeho síla pramení z jeho jednoduchosti. Odpůrci XHTML nejprve jeho popularitu vysvětlovali módou, když "móda" trvá již bezmála deset let, vymysleli teorii mýtů.
Složitost webových technologií neustále narůstá, XML nabízí jednoduchost a unifikaci. Učit se několik samostatně se vyvíjejících značkovacích jazyků je do budoucna neudržitelné a lidé intuitivně (aniž by vědomě hledali objektivní důvody) sahají XHTML, kvůli shodným prvkům s ostatními XML jazyky.
quinux
Profil
Pajuc
Rozdíl ve složitosti HTML a XHTML bych viděl prakticky nulový. Tvé "problémy" s pochopením pramenily spíše z toho, že to byly začátky a někdy jsme začínali všichni ;o) V HTML můžeš taky uzavřít všechny značky (tedy krom br apod.) a nemusíš nad tím nijak přemýšlet.
Na druhou stranu, přílišná volnost HTML, kdy se nemusí uzavřít všechny značky je podle mě špatná.
Joker
Profil
Chamurappi
Jak má validátor určit konec procesní instrukce?
Většítkem, které je obsaženo i v řetězci "?>". Kromě dokumentů sestavených úmyslně pro vyvolání problému s tím nebude mít problém nikdo. A i kdyby, pravdu bude mít validátor, samotná XHTML specifikace v části C.1. říká, že s tím mohou být problémy.

Na druhou stranu, přílišná volnost HTML, kdy se nemusí uzavřít všechny značky je podle mě špatná.
Hlavně to strašně komplikuje nějaké automatizované operace s tím kódem.
Například: Vybrání textu uvnitř odstavce z validního XHTML kódu lze realizovat nějak takhle:
preg_match('#<p.*?>(.*?)</p>#', $xhtml, $matches);
echo($matches[1]);
(dalo by se to ještě zdokonalit, ale na normální dokumenty to bude fungovat i takhle)

Chtěl bych vidět sebevraha, co by dělal něco podobného pro HTML: odstavec může být ukončen svou koncovou značkou, nebo počáteční značkou asi 30 jiných prvků, nebo ukončením nadřazeného prvku... možných nadřazených prvků je 20 a samozřejmě taky nemusí mít povinnou koncovou značku. Mňamka.
Chamurappi
Profil
Reaguji na Jokera:
Většítkem, které je obsaženo i v řetězci "?>".
I v dokumentech s <!doctypem> HTML 4?

dalo by se to ještě zdokonalit, ale na normální dokumenty to bude fungovat i takhle
Na normální HTML dokumenty také, neboť ukončovací značku odstavce vynechává málokdo. I v kódu českého validátoru jsou všechny nepovinné koncové značky rozepsané.
Joker
Profil
I v dokumentech s <!doctypem> HTML 4?
No jasně, právě v HTML 4 by bylo ?> špatně, ne? Každopádně na tom až tak nezáleží, kromě skriptů na straně serveru (které na klienta ani nedorazí) a XML deklarace jsem zatím neviděl žádné reálné použití procesních instrukcí na webové stránce. A kdyby někdo nějaké vyrobil, tak C.1.

Na normální HTML dokumenty také, neboť ukončovací značku odstavce vynechává málokdo.
:o)))
Tj.: "S nepovinnými koncovými značkami není žádný problém, stačí, když je nikdo nebude používat" :-D
Pajuc
Profil *
quinux
Rozdíl ve složitosti HTML a XHTML bych viděl prakticky nulový.
Rozdíl ve složitosti HTML a XHTML bych viděl teoreticky nulový. Prakticky mě to ale mátlo, zvlášť když jsem studoval cizí kód. Pravda, potom jsem si zvykl. Ale pocit, že HTML je chaotický, zůstal.

Každopádně moje problémy jsou irelevantní, zbytečné se jimi zabývat. Podstatou je, že používat paralelně XML a HTML, považuji za kontraproduktivní. HTML nemá oproti XHTML žádné výraznější výhody (kromě té, že stará garda je na HTML syntaxi navyklá). Benevolenci HTML IMHO obecně nelze za výhodu považovat, krom toho nic nebrání prohlížečům, aby nenabídli možnost zpracovat XHTML dokument svým pseudoHTML parserem.
quinux
Profil
Pajuc
Prakticky mě to ale mátlo
A mate tě to dodnes? Nad tím se zamysli, jestli si nebyl zmatený z toho, že jsi tomu tehdy nerozumněl tak jako dnes.

zvlášť když jsem studoval cizí kód
Když zpracovávám cizí kód tak jsem zmatený dodnes. Na vině není technologie, ale kodér ;o)
Tin
Profil
Pajuc
V xhtml MUSÍM vědět, která značka je nepárová, abych ji uzavřel />. V html potřebuju vědět totéž.
Pokud v html uzavřu všechny párové prvky, JE TO V POŘÁDKU. Pokud v html dám všechny atributy do uvozovek, JE TO V POŘÁDKU. V čem je problém?

sahají XHTML, kvůli shodným prvkům s ostatními XML jazyky.
A html s xhtml nemají stejné prvky???

A když jsme u toho, začátečníci budou umět html. A to až do té doby, než Yuhů napíše jakpsátXweb.cz (myslím, že to nikdy neudělá)

zvlášť když jsem studoval cizí kód ty píšeš kódy pro to, aby se v nich hrabal kdokoliv cizí? Jasně, když s někým spolupracuji. Ale pak se dohodneme, nebo mu to vysvětlím.
A tyhle problémy X nikdy nevyřeší: někdo odsazuje mnoha mezerami, někdo vynechává kvantum řádků mezi úseky, jiný píše úhledný monolit...
Pajuc
Profil *
Tin
V čem je problém?
Teoreticky v ničem. Psal jsem jen o tom, že kdysi jsem se u HTML zabýval problémy, které bych u XHTML nikdy neřešil.

A html s xhtml nemají stejné prvky???
Mají. Znovu však zopakuji mou doměnku: lidé intuitivně (aniž by vědomě hledali objektivní důvody) sahají k XHTML, kvůli shodným prvkům s ostatními XML jazyky.

...do té doby, než Yuhů napíše jakpsátXweb.cz ...
... je potřeba začátečníky, ale uvědom si prosím, že (X)HTML není jen český píseček, směrovat na seriál Martina Snížka.

Netvrdil jsem, že píši kódy, aby se v nich hrabal někdo cizí! To JÁ jsem se hrabal v cizích kódech, abych se z nich učil. A fígle, které jsem vyhrabal, jsem přejímal s původní syntaxí. Když jsem to pak viděl jinde napsané jinak, řešil jsem začátečnické dilema - co je správně?
quinux
Profil
Pajuc
že kdysi jsem se u HTML zabýval problémy, které bych u XHTML nikdy neřešil
Ale řešil, už jsem to psal, to není v jazyku, ale ve zkušenostech. Kdybys začínal dnes tak bys problémy řešil ať už bys začal s HTML nebo XHTML.

lidé intuitivně (aniž by vědomě hledali objektivní důvody) sahají k XHTML, kvůli shodným prvkům s ostatními XML jazyky
Pokud těmi lidmi myslíš začátečníky, tak ti v drtivé většině nemají ani páru co to XML je a k čemu by jim to bylo.
Pajuc
Profil *
quinux
S tvými stanovisky souhlasím, jen mám pocit, že se mi snažíš podstrčit něco, co jsem nenapsal. Já vyčítám HTML určitý druh problémů, spočívajících v syntaxi na 100 způsobů, což jsem podrobněji popsal v první reakci na Tina, nevyčítám mu problémy obecně.

Na XHTML přešla významná část zkušených webdesignérů a nechystají se vracet, proč mi podsouváš zrovna začátečníky. Protože si myslíš, že odborníci vždy hledají objektivní důvody? Mi to připadá tak, že čím zainteresovanější odborník, tím větší fanatik. Anebo mě tím chceš jenom shodit?
Tin
Profil
Pajuc (a i všichni ostatní)
Proč bych měl (a nedejbože intuitivně) sahat po něčem, o čem se jako první informaci dozvím, že každá chyba se trestá smrtí a za druhé, že to je podobné html, které je ale mnohem méně přísné? Jsem snad sebevrah?
quinux
Profil
Pajuc
S tvými stanovisky souhlasím, jen mám pocit, že se mi snažíš podstrčit něco, co jsem nenapsal. Já vyčítám HTML určitý druh problémů, spočívajících v syntaxi na 100 způsobů, což jsem podrobněji popsal v první reakci na Tina, nevyčítám mu problémy obecně.
Ano, ale na druhou stranu, nikde se nepíše, že ty tagy uzavírat nesmíš, takže většinu tagů můžeš uzavřít i v HTML a tím pádem ti v podstatě těch způsobů ubyde :)


Na XHTML přešla významná část zkušených webdesignérů a nechystají se vracet, proč mi podsouváš zrovna začátečníky
Protože jsi mluvil o svých začátcích. CHtěl jsem tím říct, že kdybys začínal dnes a rovnou s XHTML tak bys měl nejspíše ty samé problémy jako tehdy s HTML.


Anebo mě tím chceš jenom shodit?
To bych si nikdy nedovolil ;o)
Pajuc
Profil *
Tin
...chyba se trestá smrtí a za druhé, že to je podobné html, které je ale mnohem méně přísné?
Aha, v tom tedy tvá averze vůči XHTML. Já jsem zas pro větší přísnost, pravidla se mají dodržovat.
AlešD
Profil
Pajuc: Já jsem zas pro větší přísnost, pravidla se mají dodržovat.

Pokud vím, tak tady nikdo nehájí nedodržování pravidel. Celé téma je o tom, jaké výhody má XHTML oproti HTML. Je-li výhodou to, že pokud se, z nějakých důvodů, nestáhne celá XHTML stránka a skončí to celé chybou, tak prosím. Ale v HTML se mě zobrazí aspoň něco a mám na vybranou to stáhnout znovu, pokud dojdu k názoru, že se jedná o technickou chybu přenosu. V XHTML při spatření hlášení o chybě na řádku xy, odejdu a už se nevrátím.

Ad averze vůči XHTML. Nemám vůči XHTML vůbec averzi, prostě ho nechápu proč ho používat. Důvody:
- v HTML můžu psát tagy malými písmeny (a píšu je tak), v XHTML musím - to je výhoda?
- v HTML můžu dávat atributy do uvozovek (a dávám), v XHTML musím - to je výhoda?
- v HTML můžu některé tagy (P, LI, TR ...) zakončit ukončovací značkou (činím většinou tak), v XHTML musím - to je výhoda?
- v HTML nekřížím tagy, neboť je to sémantická blbost, v XHTML nesmím - to je výhoda?
- HTML kód vyjde vždy menší než XHTML - čí je to výhoda?
- HTML obsahuje naprosto stejnou množinu značek jako XHTML 1.0
- HTML musím posílat s text/html, XHTML můžu posílat s text/html, ale nemusí to vždy (podle nenormativního dodatku C) fungovat - to je výhoda?
- v XHTML musím (s výjimkou kódování UTF-8) psát jako první XML procesní instrukci s definicí kódování, která nikde k ničemu není (kromě kýženého shození IE do quirku), do tagu HTML pak jakési xmlns="http://www.w3.org/1999/xhtml" xml:lang="cs" lang="cs" o které málokdo ví na co to tam je. Navíc ono samotné DOCTYPE většina používá stylem copy-paste buď u JPW, nebo u Pixyho, aniž by věděli co tím vlastně chtějí říct. hlavně, že je to moderní XHTML 1.0 Strict.
- XHTML jde (možná) snadněji parsovat, nicméně pokud parsovaný dokument tvořím sám, byl bych za ******, kdybych ho vytvořil tak, že bych s ním posléze nedokázal pracovat.

A XHTML 1.1 - musí se posílat s applications/xml-xhtml odkud plyne nelze (kvůli IE) použít jinak, než k odstřižení uživatelů IE od stránek.

P.S.: už se sem pokusím nepsat :-)
P.P.S.: starší weby, které jsem v době okouzlení velkým X udělal, pochopitelně do HTML předělávat nebudu.
P.P.P.S.: v dalších vláknech tady se mě zdá, že se začínají objevovat poměrně agresivní zastánci HTML, pevně doufám, že takový nejsem.
Joker
Profil
každá chyba se trestá smrtí
Zrovna dnes jsem četl článek: Browser wars over, say Microsoft, Mozilla, Opera and Google
Mimochodem jsem přemýšlel, že bych o tom založil téma v sekci o prohlížečích, ale pořád nevím, jestli ano nebo ne :) Ale byla by to skvělá zpráva, kdyby války prohlížečů opravdu skončily. To by kdyžtak patřilo jinam, tady chci zmínit něco jiného. Přeložím začátek:
Války prohlížečů skončily a nyní se Microsoft, Mozilla a další vývojáři prohlížečů chtějí soustředit na prosazení prohlížeče jako platformy pro vývoj aplikací. Na tom se na včerejším setkání na O'Reilly Web 2.0 Expo shodli zástupci vývojářů Internet Exploreru, Firefoxu, Opery a Google Readeru.

Místo snahy překonat ostatní přidáváním nových vlastností chtějí vývojáři těchto prohlížečů pokročit v jejich použití jako platformy pro novou generaci Internetových aplikací a odstraňování překážek, které brání v této změně strategie


Podle mého názoru mezi ty hlavní překážky patří hlavně nekompatibilita těch prohlížečů, tj. to, že nějaká konstrukce funguje z těch čtyř uvedených prohlížečů v jednom až třech.
Pokud to opravdu myslí takhle, je asi jediná cesta: standardizace, sjednocení chování jednotlivých prohlížečů. Zároveň celé prostředí musí být stabilnější:
"If you're going to have [a Web] application crash … you are in trouble because that can be exploited as a security hole."
Takže sjednocování a utahování pravidel. A do tohohle modelu zapadá spíš ta přísnost XHTML, než volnost HTML.


A ještě jedna věc, kterou jsem chtěl zmínit, aby se debata posunula zas o trochu dál:
W3C se teď podle mě chytá podobného přístupu, jako jsem tu napsal já: že se nemělo udělat jenom "kompatibilní XHTML", ale zároveň ty teoretické sporné body vyřešit novou verzí HTML.
Nedávno byla založena pracovní skupina pro verzi XHTML 2.0 a zároveň pracovní skupina pro novou verzi HTML. Ač někteří ;-) to budou vidět jako vpodstatě pohřeb XHTML, jak já jsem četl ty informace, je to spíš snaha dostat se ke XML "z druhé strany"; XML zpětně kompatibilní s HTML podle mě narazilo na bludný kruh, o kterém je i tohle téma: "Jaké jsou výhody přechodu na XML?" Na nějaké větší výhody je potřeba, aby většina lidí přešla a většina lidí přejde, až to bude mít nějaké větší výhody.
No a teď se podle mě W3C snaží udělat to, co mělo udělat už v HTML 4.01, současně s vydáním XHTML: mít nejen XML zpětně kompatibilní s HTML, ale zároveň novou verzi HTML, dopředně kompatibilní s XML. Což se nakonec píše i ve vizi nových verzí HTML a XHTML: http://www.w3.org/2007/03/vision.html
Pokud nový formát rodiny HTML bude široce používán a bude moci být spolehlivě konvertován do XML, pokud už v té formě nebude přímo sestaven (přitom spolehlivě znamená nejen stejné formátování, ale i struktura a sémantika), bude moci být vytvářen a zpracován postupy založenými na XML. (…) Jelikož mobilní klienti si nemohou dovolit luxus dvou parserů a XML parser bude stejně vyžadován, očekává se, že obsah určený pro anebo nevylučující mobilní zařízení bude vytvářen jako XML
(…)
Tento směr nesnižuje úlohu XML jako hlavního značkovacího jazyka na webu i jinde.


No, tak schválně, co z toho vyleze :)


AlešD
Ale v HTML se mě zobrazí aspoň něco a mám na vybranou to stáhnout znovu
Pokud vývojáři z Microsoftu, Mozilly, Opery a Googlu vidí budoucnost webu v komplexních webových aplikacích, je přístup "zpracovat alespoň něco" katastrofální chyba.
Umíte si třeba představit, že by aplikace měla přejmenovat soubor, což by se skládalo ze zkopírování a vymazání, a operace kopírování by se nějak pokazila, tak by aplikace udělala alespoň to vymazání?
Pajuc
Profil *
Pokud vím, tak tady nikdo nehájí nedodržování pravidel.
Tin sice nedodržování pravidel nehájil, nicméně si stěžoval, že chyby se přísně trestají.

P.S.: už se sem pokusím nepsat :-)
To je chyba :-) Ještě jsi nevyjmenoval všechny rozdíly mezi HTML a XHTML, pouze jsi jeden navíc přidal. V HTML se AFAIK tagy rovněž nesmí křížit => to jen dokládá mé začátečnické zkušenosti, je problém si uvědomit, kde benevolence HTML končí. Jinak úplně souhlasím s Quinixem - to není v jazyku, ale ve zkušenostech. Kdybys začínal dnes tak bys problémy řešil ať už bys začal s HTML nebo XHTML. A je IMHO lepší začít s XHTML - výhodou je, jak znova a znova opakuji, přehlednější syntaxe, navíc prakticky shodná s obecnou XML syntaxí - ještě bych vyhodil ten Doctype a bylo by to super ;)
AlešD
Profil
Joker:

Malý dodatek před úplným umlknutím.

Aby mě bylo dobře rozumněno, v částečném zobrazení v prohlížeči jsem myslel pouze a jenom částečné zobrazení v prohlížeči (UA - user agent). Pokud se jedná o procesy mající charakter transakce server - klient, je samozřejmě nutné chybové stavy ošetřit a pokud něco nevyjde ROLLBACK. Ale to je přece něco jiného.
« 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 »

Vaše odpověď


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: