[XSLT] <xsl:output ... /> en afsluiten tags in XHTML

[drm]

Ik ben weer eens goed in xslt verder gegaan en voorheen transformeerde ik de uiteindelijke resulttree in xml altijd naar HTML 4. Nu wij natuurlijk allemaal keurig aan het overstappen zijn naar (well-formed) xhtml dacht ik daar ook eens een draai aan te geven.

Maar dan kom ik een probleem tegen waar volgens mij geen nette oplossing voor is:
Het afsluiten van tags die content mogen hebben moet nog steeds op de HTML wijze, anders snapt IE het niet meer. Denk bijvoorbeeld aan een script-tag in de volgende context:

code:

<xsl:transform 
   version="1.0" 
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>
   <xsl:output 
      method="xml" 
      doctype-etcetera="even weggeknipt"
   />
   <drm:snip />


   <script type="text/javascript">
      <xsl:attribute name="src">
          <xsl:value-of select="path" />hetscript.js
      </xsl:attribute>
   </script>


   <drm:snip />
</xsl:transform>

Daarbij moet je je dus voorstellen dat http/root even een probeerseltje is waarin de http(document-)root in staat. Gevolg is dan (natuurlijk) een keurig "empty" element:

HTML:

<script type="text/javascript" src="js/resizer.js"/>

Maar, om de browsers nog even tevreden te stellen zou dit eigenlijk:

HTML:

<script type="text/javascript" src="js/resizer.js"></script>

moet worden.

Wanneer je dit echter met een html-output method doet, krijg je wel een keurig (html-like) afgesloten <script> element, maar dan krijg je ook weer empty elements zoals <br /> die niet op de xml maar op de html wijze (<br>) worden weergegeven. Als je dat gaat doen kun je dus net zo goed bij html 4 blijven, ajbwib

Ik wil eigenlijk gewoon een lijst op kunnen geven van elementen die op de html-wijze afgesloten worden en een lijst van element die wel op de xml wijze afgesloten mogen worden... Ik vermoed dat dat vanuit xslt zonder work-around niet ondersteund wordt, maar misschien is er iemand die er een nette oplossing voor gevonden heeft?

Ik heb al geprobeerd bijvoorbeeld het script-element als cdata-element op te geven in <xsl:output />, maar dat heeft niet dat resultaat (logischerwijs ...)

Eveneens kun je die zaken natuurlijk gaan coderen (in de zin dat je met < en > gaat werken enzo), maar dan ga je natuurlijk een beetje voorbij aan de functie van xslt

_{Oh ja: het gaat natuurlijk niet zo zeer om het probleem van het 'src' attribuut, want hetzelfde probleem treedt op wanneer je bijvoorbeeld lege div of p elementen hebt}

[tomato]

Ja dit probleem ben ik ook al tegengekomen (nouja, eigenlijk was het eerst mbravenboer, maar ik merkte het op ).

Volgens mij kun je in sommige XSLT processors aangeven dat 'lege' elementen 'voluit' geschreven moeten worden, maar ik zou zo uit mijn hoofd niet kunnen zeggen hoe precies. En je zit dan natuurlijk nog steeds met bijv die <br /> tags.

Vervelend probleem, vervelende Internet Explorer bug (ja er zijn er nogal wat).

Volgens mij hebben we geen echte oplossing gevonden, maar gewoon een bogus regel in het script element gezet:

code:

<script src="hetscript.eenfijneextensie">var ie = -1</script>

Dat het ook bij andere elementen problemen geeft zoals div en p die je aangeeft wist ik niet. Misschien is het simpelweg bij mij nog nooit voorgekomen dat die elementen leeg bleven (of de gevolgen in IE ervan zijn me nooit in negatieve zin opgevallen).

[ Voor 4% gewijzigd door tomato op 25-05-2003 21:03 ]

[drm]

tomato:
Ja dit probleem ben ik ook al tegengekomen (nouja, eigenlijk was het eerst mbravenboer, maar ik merkte het op ).

Volgens mij kun je in sommige XSLT processors aangeven dat 'lege' elementen 'voluit' geschreven moeten worden, maar ik zou zo uit mijn hoofd niet kunnen zeggen hoe precies. En je zit dan natuurlijk nog steeds met bijv die
tags.

idd

Vervelend probleem, vervelende Internet Explorer bug (ja er zijn er nogal wat).

Volgens mij hebben we geen echte oplossing gevonden, maar gewoon een bogus regel in het script element gezet:

code:

[snip]

Zoiets zat ik ook al aan te denken, maar echt netjes is het niet ...

Dat het ook bij andere elementen problemen geeft zoals div en p die je aangeeft wist ik niet. Misschien is het simpelweg bij mij nog nooit voorgekomen dat die elementen leeg bleven (of de gevolgen in IE ervan zijn me nooit in negatieve zin opgevallen).

zie hier het bewijs

[tomato]

drm schreef op 25 May 2003 @ 21:19:
Zoiets zat ik ook al aan te denken, maar echt netjes is het niet ...

Nee, zeker niet

zie hier het bewijs

Hmmm ik zie het, in Mozilla en Opera gaat het zelfs ook fout. Dan begin je je af te vragen of het zelfs wel geldige XHTML is, in die spec zitten wel meer rare dingen die je normaal in een XML applicatie niet zou verwachten... maar daarvoor zou ik even moeten gaan spitten... en het lost niets op aan je probleem.

Dan heb ik op dit moment geen mooie oplossing voor je en zit ik zelf eigenlijk met hetzelfde probleem, want ik gebruik ook veel de XML output method om XHTML te genereren... alleen ben ik er nog nooit tegenaan gelopen. Misschien weet iemand anders iets...

Ennuh... een hele dir speciaal voor mij? Stuur je me zo dan ff die FTP gegevens?

[crisp]

Als ik de DTD bekijk, dan maak ik daaruit op dat alleen de volgende elementen middels de /> afgesloten mogen/moeten worden, alle anderen hebben een losse afsluit tag nodig, zelfs als ze geen data bevatten:

<base />
<meta />
<link />
<hr />
<br />
<param />
<img />
<area />
<input />
<col />

Dit zijn trouwens allen tags waarvoor in HTML4 geldt dat een end-tag verboden is.
de laatste is trouwens grappig (check de source van de myreact pagina).
Bedenk dat xhtml != xml. Het is alleen een well-formed implementatie van html.

[ Voor 30% gewijzigd door crisp op 26-05-2003 00:05 ]

[drm]

tomato:
Hmmm ik zie het, in Mozilla en Opera gaat het zelfs ook fout. Dan begin je je af te vragen of het zelfs wel geldige XHTML is, in die spec zitten wel meer rare dingen die je normaal in een XML applicatie niet zou verwachten... maar daarvoor zou ik even moeten gaan spitten... en het lost niets op aan je probleem.

't Is dus (zie crisp) niet geldig, en die pagina valideert ook niet volgens xhtml 1.0 strict, maar het geeft wel duidelijk aan wat het probleem is

Dan heb ik op dit moment geen mooie oplossing voor je en zit ik zelf eigenlijk met hetzelfde probleem, want ik gebruik ook veel de XML output method om XHTML te genereren... alleen ben ik er nog nooit tegenaan gelopen. Misschien weet iemand anders iets...

Ik hoop het

Ennuh... een hele dir speciaal voor mij? Stuur je me zo dan ff die FTP gegevens?

offtopic:
als ik je upload max op de filesize van dat bestandje zet wil ik wel een homedir voor je maken

[nohtml]

crisp:
Dit zijn trouwens allen tags waarvoor in HTML4 geldt dat een end-tag verboden is.

Het is overigens wel frappant dat je dat noemt, want de validator van w3 (is niet heilig, maar goed...) gaat toch wel akkoord als je voor bijvoorbeeld een <img> een sluittag opgeeft in xhtml

Bedenk dat xhtml != xml. Het is alleen een well-formed implementatie van html.

Dat is een vreemde stelling well-formed is een term die je gebruikt als je het over een documentstructuur hebt die zou valideren volgens de xml standaarden. Xhtml is dan een implementatie (vorm) van HTML die well-formed is en daarmee (dus) een subset van xml (imho )

[drm]

*kick*

[mbravenboer]

Niet oplosbare problemen met technieken zou ik het liefst proberen te voorkomen door de technieken niet te gebruiken, maar in dit geval is dat nogal lastig omdat XHTML ontwijken betekent dat je HTML moet gebruiken.

Je zou kunnen proberen of je probleem opgelost wordt met de xhtml output method van XSLT 2.0.

Voor specificaties hiervan:
http://www.w3.org/TR/xslt-xquery-serialization/#xhtml-output

Saxon 7.5.1 is dan de implementatie om daarmee te experimenteren:
http://saxon.sourceforge.net/

[hobbit_be]

yow ik ben net mijn site met xml+xsl->xhtml aan het omzetten maar als die blijkbaar zoiets simpels niet aankan (ik gebruik xalan) vind ik dat wel grappig (nou niet echt). Kun je ipv output als html niet gewoon txt pakken , dan blijft de processor er toch met zijn poten af? (ik krijg iets van die 'slimme' dingen)

[mbravenboer]

Het ligt niet aan de html output method, maar aan het probleem dat de xml output method niet toegepast kan worden voor het outputten van xhtml 1.0 (althans, niet probleemloos).

De text output method zou verboden moeten worden.