On Mon, Apr 08, 2002 at 09:58:30AM -0400, Christopher H. Laco wrote: > While I agree on the concept, the reality is not as correct. > Please define "properly design your stylesheet"? > > My biggest beef with XSLT processors is they do to much thinking for me and > not enough DWIM-ing. > I want to be able to select, print, and arrange things [read: > elements/attributes], NO have it correct tag out for me [read: > adding/subtracting slashes and such].
Hmm, the XSLT processor act on an (most likely) in-memory tree representation of your document that has been built from your external (file) representation by the scanner/tokenizer/parser -- it doesn't "see" your XML 'code'. '<a></a>' vs. '<a/>' vs. '<a />' are alternative _external_ representations of the _same_ internal structure. > <br /> going into <xsl:output method="html"/> comes out as "<br>", at least > for me in libxslt and sablot, which is certainly not what I want it to do. which, in my understanding of the specs, is the only correct way. According to http://www.w3.org/TR/1999/REC-html401-19991224/html40.txt, section 9.3.2 (Controlling line breaks): | <!ELEMENT BR - O EMPTY -- forced line break --> | <!ATTLIST BR | %coreattrs; -- id, class, style, title -- | > | | Start tag: required, End tag: forbidden ^^^^^^^^^^^^^^^^^^ HTML 4 is an _SGML_ dialect, _not_ XML! If you ask for 'method="html"' that's what you get :-) > <xsl:output method="html"/> also completely munges <html > xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> into <html > lang="en" lang="en">. hmm, again, according to the specs. the only legal attributes to HTML are lang,dir and (deprecated) version. > Granted, these may be more specific to each xslt processor, but still, Do > What I Mean, not what you think I mean. > Even more to the point, XHTML fits well in neither method="html" or > method="xml" transformations. It doesn't fit 'html', but why not 'xml' methods. AFAIK xhtml is perfectly valid xml. I get the impression that you want/need to feed xhtml to non- xml aware browsers by faking something digestable to those broken implementions (the 'ol <br /> hack :-) Curse on the browser industry, not the XSLT implementors. You ask them to do the same mistake again (producing non-standard conforming output). > I'm sure there are ways around it ala encoding or hiding things from the > xslt processoer, but come on, that's silly IMHO. No, it's not. I'm glad i can rely on the standard conformance of my tools. If your really need the broken output (and as a service implementor i know that's hard to avoid), write an output encoder for LibXML/LibXSLT that deals with aforementioned issues. Ralf Mattes > > > > > -----Original Message----- > > From: Tod Harter [mailto:[EMAIL PROTECTED]] > > Sent: Monday, April 08, 2002 9:36 AM > > To: Melvyn Sopacua > > Cc: [EMAIL PROTECTED]; AxKit List > > Subject: Re: MSIE Render; Content-Type Questions > > > > > > Doesn't actually matter. There is no "official" xhtml output > > method either. > > XSLT 1.1 draft as of the latest one I read didn't include it. > > The reasoning > > being that if you properly design your stylesheet then the > > html method will > > work fine and should output legal xhtml. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
