List Info

Thread: Re: DOM FAQ
Re: DOM FAQ
country flaguser name
United States		 2007-02-09 20:48:37 

  


  

    

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		
  

  
  
   
     
    






 [1]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )