Re: [xsl] Understanding why <tag></tag> is the way it is (was Re: [xsl] IE Client side transformation issue)

["Andrew Welch" <andrew.j.welch@xxxxxxxxx>]

On 8/3/07, G. Ken Holman <gkholman@xxxxxxxxxxxxxxxxxxxx> wrote:
> The XSLT workaround I tell my students is to place another construct
> in the field, and in the production job I ended up using an empty
> comment, which produces the following when the input is empty:
>
>    <b><!----></b>
>
> ... or the following when the input is non-empty:
>
>    <b><!---->abc</b>

Hmm, I've taken the viewpoint that you shouldn't output <b/> if the
input is empty.  I really don't like the comment hack to get around
the problem... but I've been stung by it so many times that the
comment hack is appealing enough to do.

> >A while back I used to ask frequently why we couldn't have a switch to
> >tell the serializer to output <b/> as <b></b> and the general response
> >was "why?"...
>
> I don't think standards writing should be geared around
> malfunctioning tools.  A lot of that is attempting to be done these days.

Yes - I think I asked for a processor extension rather than a spec
change, but Mike said "no" :)    (...but also provided the XHTML
output method)


> >So in summary, the answer is to parse HTML with an SGML parser, and
> >XML with an XML parser and be aware which one the browser is using to
> >parse what you've given it.
> >
> >(It think it was DC that enlightened me here)
>
> But in the production job where I experienced this the output was
> going to 10,000 desktops with unknown browsers.
>
> Having to code around the browser bug was bad enough ... influencing
> the writing of standard specifications around browser bugs is going too far.

It didn't push you far enough to do it on the server then...?

Seriously though, for "10,000 desktops with unknown browsers" I
would've made the call very early on to do it serverside, regardless
of the "browser bug".

Surely the comment hack didn't go down well...

-- 
http://andrewjwelch.com