Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Variables and HTML
 On Fri, 11 Mar 2005 19:19:16 -0500, Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> wrote: We use d-o-e extensively for the use case Michael describes, namely we 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!! We also use it for two other less common cases. One is where because of some browser vagary we want to generate and output HTML that's not valid XHTML. We can't embed it in the XSL because it would cause the XSL file to be ill-formed. Neither can we use xsl:element to construct it. 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. 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. The last use case is where we do (or could) have a well formed output doc 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. The breakpoint is calculated and the ID of that node is placed in a variable in global scope. A table is built for the list to go in and the first column is started. When the breakpoint node is rendered, a named template is called which ends the first column and starts the second (with logic for continuation headings). I'd love to have a better solution for this, so let me know if you have any thoughts! That having been said, I concur that tag-writing may be a reasonable way to think about doing certain kinds of work that prove (very) difficult to approach otherwise, such as dealing with "overlap" or the various ways XML fakes overlap. But it's not really XSLT, even if you use an XSLT engine + serializer to implement it, and when I think about this it's always in the part of my brain behind the door marked "Heresy: Enter at Your Own Risk". 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. -------------->Nathan I'll let others comment on the implications of XSLT 2.0 for the three cases described. -- .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:. Nathan Young A: ncy1717 E: natyoung@xxxxxxxxx 
|
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
|
