xhtml ved xsl transformationer, olebole kig ind

Okay, jeg vil ikke garantere dette virkelig får dit dokument til at køre igennem xml-parseren istedet for html-parseren (måske fungerer det også anderledes i mozilla?!?)

Der er nemlig et xsl-element som hedder output (http://www.w3.org/TR/xslt#output), som bestemmer hvordan dokumentet skal parses. Her kan metoden være xml,html,text samt en fjerde, som jeg ikke lige selv har sat mig rigtig ind i. Desuden har den også en attribut som hedder media-type, som man skal sætte til application/xml+xhtml.

Nu kommer så noget, hvor jeg bliver lidt i tvivl om hvad der foregår. For umiddelbart skulle man tro man skulle skrive:
<xsl:output method="xml" media-type="application/xml+xhtml" />
for at xhtml-dokumentet skulle parses rigtigt, men du kan jo prøve selv... jeg fik bare smidt en masse tekst i hovedet.

Der hvor resultatet giver mere mening er når man skriver:
<xsl:output method="html" media-type="application/xml+xhtml" />
Så bliver content-typen rigtig og outputtet vises som når man laver almindelige html-dokumenter. At man så skal skrive method="html" undrer mig lidt, for bliver det så parset som rigtig xhtml (altså gennem xml-parseren)? Jeg har umiddelbart ikke sat mig mere ind i det, men måske Ole kommer et smut forbi ;-)

<ole>

Der er ikke en MIME, der hedder 'application/xml+xhml'. Den hedder 'application/xhtml+xml'. Derfor er der ikke noget at sige til, det ikke virker, eller at man får et ubrugeligt output  ;o)

Derudover kan man godt få Moz' XML-parser til at gennemløbe elementerne ved load - men det bliver det ikke XHTML af. Det er stadig et HTML-dokument - med hele HTML-DOM'en intakt  :)

Det er der ikke noget hjernebrud - endsige noget nyt - i (bortset lige fra den 'fancy' MIME-type)  ;o)

/mvh
</bole>

Læg mærke til, at det dokument, der linkes til, sendes med MIME-type 'application/xml' og ikke 'taxt/html'. Det bevirker, at Moz' XML-parser netop behandler elementerne, når de loades - og derefter behandles dokumentet som et rent HTML-dokument.
Intet nyt under solen  :)

- men det ville da være positivt og formålstjenligt, hvis folk brugte energien på at sætte sig ind i, hvad W3C skriver om emnet ... i stedet for at bruge den på at vedligeholde skyttegrave og lede efter, om ikke olebole mon skulle have misforstået noget et eller andet sted.

Jeg er formodentlig ikke den eneste, der fornemmer et lille: "Ha! ... gotcha!" i spørgsmålet - men dsværre må jeg skuffe.

Jeg har nøje studeret XHTML siden foråret 2001, hvor jeg af jobmæssige årsager var tvunget til at sætte mig ekstremt grundigt ind i standarden. I den forbindelse skulle jeg stå for fontend'en på en stor koncern-applikation, hvor markup'en af specielle årsager skulle være 'hysterisk' X(HT)ML-kompatibel. Dermed hører jeg til de ret få, der overhovedet har været i situationer hvor XML-fejl i en markup-kode resulterer i en væltet applikation.

You won't get me ... jeg ved, hvad jeg taler om  :)

skovenborg:

Men netop xsl output bør fjernes i dette tilfælde, da source koden ellers også ville blive transformeret i tilfælde af libxml transformation, ved at undlade <xsl:output> kan man jo netop opnå begge dele.

Olebole:

Behøver du absolut se alting som et angreb mod dig som person ?
Jeg søgter nærmere en diskussion om hvorfor denne problemstilling var sådan, og det fik jeg :)

Der er dog stadigvæk problemer med sablotron transformation til HTML 4.01, da man ikke kan få indents , og output koden bliver noget makværk.
Client-side transformation (browser) er endnu heller ikke optimalt nok til at arbejde med.

At Mozilla loader det som xml, og først efter load behandler som HTML , faldt mig enig ikke ind, men lyder da meget logisk.

Men tak for kommentarene... og hvis i stadig går op i det point-system fis ? så sig da til.

Jeg ser absolut ikke alting som et angreb ... tvætimod. Hvor har du dog det fra?  :)

Der er masser af problemer i de forskellige browseres renderings maskiner. F.eks. kan det jo undre, at nogen somhelst browser - der ikke parser en side som XHTML - behandler <br /> som <br>.
Det viser, at XHTML ikke engang parses som HTML4.01 (når den korrekte MIME ikke bruges), men som tilfældig HTML tag-soup. SGML - og dermed HTML4 - foreskriver nemlig, at <br /> skal tolkes som <br>&gt;
Således bør:

Darvs<br />du

- renderes som:

Darvs
>du

Efter sigende er det problemer med bl.a. konsistensen i MSXML og MSHTML, at MS har besluttet at vente med XHTML-understøttelse og derfor ikke implementere dette i IE7 - mens andre leverandører ikke synes at have problemer med den slags.

Mozilla har endda besluttet sig for at fortsætte kursen med ikke standardiseret mudderkode. Gud hjælpe mig, om ikke der ser ud somom, de er ved at implementere den ikke standardiserede 'HTML-' DOM-property 'innerHTML' i deres - dermed proprietære - XHTML-DOM.

XHTML-DOM burde jo netop være ren XML_DOM. Hvad i alverden 'innerHTML' har at gøre dér, er en gåde. Det ligner den type leflen for dårlige kodere, vi kunne have håbet på, ville forsvinde ved overgangen til XHTML ... men ak! Summen af dumhed er konstant!  :o|

For ikke at tale om FF's øvrige DOM-håndtering. Prøv at kikke på dette eksempel:
    http://www.eksperten.dk/spm/661956#rid5902154

- bare én enkelt browser, der virker som forventet, ville være skønt ... men det ønske er nok illusorisk  :)

hehe... Browsere = dybt suk...

Jeg kunne enig også nøjes med bedre CSS implementation i IE7, så er jeg tilfreds.
Og når de danske padde webhoteller engang opgradere til php5, er det jo også mega let at skifte til html 4.01 istedet for xhtml, med mine nuværende systemer :)

Mht. innerHTML, var løsningen netop ikke at bruge xpath og DOM istedet ?
Hvis de ikke gør det, virker det for mig som et vildt rod.

php5 har derudover fået implementeret DOM meget pænt synes jeg ;)

Moz implementerer 'innerHTML' sideløbende med XHTML-DOM'ens properties og metoder - men det gør det ikke til mindre rod. Alene navnet viser, de to ting intet har med hinanden at gøre.

Jeg har ikke intensivt arbejdet med DOM i PHP5, men det ser okay ud. Når jeg f.eks. laver AJAX-applikationer, foretrækker jeg langt at bruge JSON fremfor XML. Det er hurtigere på serveren og i browseren - og de overførte data fylder mindre.

Samtidig er det et 'rent' datasprog, som ikke er 'fedtet ind i element-tænkning', hentet fra markup-sprog - men som læner sig kraftigt op ad C-syntaks. Det betyder naturligvis også, at man ikke kan bruge stylesheets sammen med JSON ... men det er jo netop også et eksempel på de ulogiske element/data sammenblandinger, der kendetegner XML  ;o)

I de situationer, hvor data skal være tilgængelige for andre klienter, der insisterer på XML, laver jeg specielle feeds til dem. Der skal væsentlige forbedringer til, før jeg overgår til XML, når det gælder at transportere data mellem server og browser.

JSON rocks ... simple as that!  :)