Re: DOM FAQ

While trying to create an html image button that actually clicks, I tried 
embedding the image element in side of a button element.  In straight HTML 
this worked very well, however, when I converted the page to an aspx page 
I started getting PageValidation Exception errors, the solution to which 
was either turn off page validation (not one that I was particularly happy 
with), remove the embedded html elements from between the button elements 
(thus limiting the button to simple text messages - something that was 
counter to the WC3 stated intent of the button element), or switching to 
the input image button and input button elements.  While the input button 
worked well enough and did actually show the button "pushing" when 
clicked, the input image button didn't.  Unfortunately adding the "push" 
action to the input image button requires complex event scripting, which 
only becomes more complex when there are interactions and side-effects 
when the button is used in conjunction with other elements to form 
multi-element components.

It would be nice if the standard for the button element was to return the 
id or name instead of the embedded text or html.  Lacking the id or name, 
then the element should work as it does now.  This would prevent the 
PageValidation Exception and make the button element more attractive to 
developers who are looking for the flexibility of being able to embed 
complex content.

This next suggestion probably should go to Microsoft, but perhaps there 
are some "nuggets" for you in here too:  In addition to Application and 
Page level Validation protection against injection attacks, it would be 
nice if there was a way to control the which elements are protected at the 
element level.  Additionally, the implementation of a element attribute 
switch that controlled which  whether the element posted data back to the 
server when the page was submitted.  This way buttons and other controls 
on the client side that provide functionality to the client page via 
scripting, but that don't need to send any information back to the 
"server' could be configured to "work" silently.  One possible option 
would be to use a "runat=client" attribute switch to indicate that the 
element only needs to work in the client side and not communicate back to 
the server.  The effect of this would be buttons and controls that don't 
"clog-up" the post back and simpler code for developers that don't need to 
defeat injection attacks traveling back to the server.

Thank you,
Howard Brown