[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Variables and HTML
Hi Nathan,
At 06:26 PM 3/14/2005, you wrote: [d-o-e for inline pseudo-markup] To do otherwise I would either need to build the whole system myself or hold a sufficiently large bludgeon over a bunch of technical and authoring groups, neither of which is possible I'm afraid. But I do champion the benefits whenever I get a soapbox!! Yes, the reasons it's not always possible to Tidy all HTML at the point of entry are generally social and political ones ... therefore not the sort of thing you can deal with in XSLT, or not in XSLT alone, anyway. d-o-e to create badly-formed HTML] Before css we used to get rid of the extra whitespace caused by the end form tag by sandwiching it between table rows. Most of these hacks have fallen by the wayside as long as you don't have to support older browsers, but some persist. Understood. Whether you need to support Netscape 3.0's HTML+ is another of those non-technical questions. Customizing the serializer isn't a possibility for our case... I might need some more convincing before I agreed it was really an appropriate solution even in the abstract. It is, however, the solution that is most in keeping with the overall design of the architecture. If this isn't the best or most "appropriate" solution, it's usually due to more of those non-technical issues. It's tough to customize a serializer for your XSLT processor, if it's in Java and your team isn't. (And not infrequently XSLT is developed by teams of one.) I have a template that splits a three tiered listing (headers subheaders and list items) into two columns. The break point is chosen as follows (first condition met is used): - if there are first level headers at the midpoint or within 7 items after the midpoint, break at the first one - if there are 1st level headers within 3 items before the midpoint use the last of those. - repeat the above two for second level headers. - if nothing else, break right on the midpoint. Offhand it sounds like a nasty positional grouping problem; these are doable in XSLT 1.0, but they're not always pretty. (Sometimes they have a kind of peculiar baroque beauty, but this one just sounds nasty.) The tag-writing solution is either simple and elegant, or corrupt and lamentable: you decide which. Also, no one else is in a good position to determine whether the dependency on the serializer to effect this is a high price, in your case. (But I was just reminded today that people have sometimes used d-o-e because they don't know about attribute value templates ... they do <xsl:text disable-output-escaping="yes"><p class="</xsl:text> <xsl:value-of select="local-name()"/> <xsl:text>"></xsl:text> because they don't know about the curly-brace magic in <p class="{local-name()}"/>. As you can see, this is most unfortunate.) I admit that the idea that XSL has identical requirement for output as it does for input is a new though very elegant and compelling idea for me. It does seem to fly in the face of a lot of marketing material crowing that XSL isn't just for XML output, it can do csv, acrobat, etc. The marketing material isn't wrong; it's just simplifying the matter. It's not XSLT that generates all these formats; it's XSLT + one back end or another. (Even in your citation you say "XSL", and as we know XSL is both more, and less, than XSLT.) Cheers, Wendell
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|