Treeview producing invalid XHTML in ASP 2.0

[Debbie Croft]

I have a client who mandates XHTML compliance in the applications they
commission. Problem is that I've just found that the Treeview control
doesn't produce valid XHTML - even with the appropriate "xhtmlConforman ce"
settings.

The problem lies in the post back code. As you can see below, the <script>
tag is missing a 'type="text/javascript"' attribute - which is required in
XHTML.

<script>
<!--
function TreeView_Popula teNodeDoCallBac k(context,param ) {
WebForm_DoCallb ack(context.dat a.treeViewID,pa ram,TreeView_Pr ocess
NodeData,contex t,TreeView_Proc essNodeData,fal se);
}
// -->
</script>

The Microsoft documentation says the Treeview is supposed to produce valid
XHTML - so it's broken. Anyone managed to create a work around? If there's
nothing easy I can do, would it be possible to intercept the HTML output by
the Treeview (or even the page) and insert the attribute using a string
replace, or something.

Failing a solution for Treeview, is there a good (and easy) third-party
alternative to Treeview that is known to produce valid XHTML?

What a pain. The reason I moved to ASP.NET 2.0 was because they said they'd
fixed this stuff. Grrr...

[Teemu Keiski]

Hi,

this has been reported:
https://connect.microsoft.com/Visual...edbackID=94108

Unfortunately they've decided not to fix it immediately. So most likely will
get fixed in vNext

--
Teemu Keiski
ASP.NET MVP, AspInsider
Finland, EU
http://blogs.aspadvice.com/joteke
"Debbie Croft" <de**********@n ospamforme.comw rote in message
news:12******** *****@corp.supe rnews.com...

>I have a client who mandates XHTML compliance in the applications they
commission. Problem is that I've just found that the Treeview control
doesn't produce valid XHTML - even with the appropriate "xhtmlConforman ce"
settings.

The problem lies in the post back code. As you can see below, the <script>
tag is missing a 'type="text/javascript"' attribute - which is required in
XHTML.

<script>
<!--
function TreeView_Popula teNodeDoCallBac k(context,param ) {
WebForm_DoCallb ack(context.dat a.treeViewID,pa ram,TreeView_Pr ocess
NodeData,contex t,TreeView_Proc essNodeData,fal se);
}
// -->
</script>

The Microsoft documentation says the Treeview is supposed to produce valid
XHTML - so it's broken. Anyone managed to create a work around? If there's
nothing easy I can do, would it be possible to intercept the HTML output
by the Treeview (or even the page) and insert the attribute using a string
replace, or something.

Failing a solution for Treeview, is there a good (and easy) third-party
alternative to Treeview that is known to produce valid XHTML?

What a pain. The reason I moved to ASP.NET 2.0 was because they said
they'd fixed this stuff. Grrr...

[Debbie Croft]

FYI. Installing Mircosoft's CSS Friendly Control Adaptors solves this
problem.

"Debbie Croft" <de**********@n ospamforme.comw rote in message
news:12******** *****@corp.supe rnews.com...

>I have a client who mandates XHTML compliance in the applications they
commission. Problem is that I've just found that the Treeview control
doesn't produce valid XHTML - even with the appropriate "xhtmlConforman ce"
settings.

The problem lies in the post back code. As you can see below, the <script>
tag is missing a 'type="text/javascript"' attribute - which is required in
XHTML.

<script>
<!--
function TreeView_Popula teNodeDoCallBac k(context,param ) {
WebForm_DoCallb ack(context.dat a.treeViewID,pa ram,TreeView_Pr ocess
NodeData,contex t,TreeView_Proc essNodeData,fal se);
}
// -->
</script>

The Microsoft documentation says the Treeview is supposed to produce valid
XHTML - so it's broken. Anyone managed to create a work around? If there's
nothing easy I can do, would it be possible to intercept the HTML output
by the Treeview (or even the page) and insert the attribute using a string
replace, or something.

Failing a solution for Treeview, is there a good (and easy) third-party
alternative to Treeview that is known to produce valid XHTML?

What a pain. The reason I moved to ASP.NET 2.0 was because they said
they'd fixed this stuff. Grrr...