Re: [xsl] Variables and HTML

Subject: Re: [xsl] Variables and HTML
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 14 Mar 2005 18:58:37 -0500
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
   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

I'd love to have a better solution for this, so let me know if you have
any thoughts!

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">&lt;p class="</xsl:text>
<xsl:value-of select="local-name()"/>

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.)


====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================

Current Thread