Re: [WF2] HTMLFormElement.accept vs. function accept(){}

Sorry, I meant this:

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cform%20action%3D%22foo%22%20onsubmit%3D'alert(this.getAttribute(%22action%22))%3B%20return%20false%3B'%3E%3Cinput%20type%3Dtext%20name%3Daction%3E%3Cinput%20type%3Dsubmit%3E

On Wed, Feb 20, 2008 at 4:02 PM, Jon Barnett <jonbarnett@gmail.com> wrote:
>
> On Wed, Feb 20, 2008 at 12:36 PM, Simon Pieters <simonp@opera.com> wrote:
>  >
>  >
>  >  On Wed, 20 Feb 2008 19:06:33 +0100, liorean <liorean@gmail.com> wrote:
>  >
>  >  >
>  >  > On 20/02/2008, Simon Pieters <simonp@opera.com> wrote:
>  >  >> There are some ways to fix this problem.
>  >  >>
>  >  >>    1) Make the .accept DOM attribute not override functions in scope.
>  >  >>    2) Remove support for .accept DOM attribute but keep the content
>  >  >> attribute.
>  >  >>    3) Remove support for both .accept and <form accept>.
>  >  >
>  >  > 4) Give it a different name in the DOM bindings, such as
>  >  > formelm.htmlAccept.
>  >  >
>  >  > This is style with other bindings used to avoid script engine
>  >  > problems, such as legendelm.htmlFor or elm.className. Granted, both
>  >  > those are because of ECMAScript reserved keywords and not live content
>  >  > script usage collisions, but I still think it's a viable option.
>  >
>  >  Yeah... if <form accept> was a killer feature. But it's not. It's pretty
>  >  useless. DOM2 HTML forgot about it's existence altogether. AFAIK, no
>  >  browser does anything with it at all. Supporting it is causing Web compat
>  >  problems. I'd say it's ripe for removal.
>  >
>  >  --
>  >  Simon Pieters
>  >  Opera Software
>  >
>  >
>
>  As an author is easy enough to fix by changing the accept() function
>  call to window.accept() since globally defined functions end up as
>  methods of the window object.
>
>  As an author, that type of hell is not new.  A form field named "name"
>  or even "action" is hell to deal with, especially in IE where
>  form.getAttribute() actually returns the input element instead of the
>  attribute value.  Try this in IE6:
>  http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cform%20action%3D%22foo%22%20onsubmit%3D'alert(this.getAttribute(%22action%22))%3B%20return%20false%3B'%3E%3Cinput%20type%3Dsubmit%3E%3Cscript%3E%20document.forms%5B0%5D.firstChild.click()%20%3C%2Fscript%3E
>
>  It's a problem that's unavoidable with any new properties/methods on
>  HTMLFormElement.  Since it's easy to work around and common to work
>  around, is it worth fixing?
>
>  --
>  Jon Barnett
>



-- 
Jon Barnett

Received on Wednesday, 20 February 2008 22:04:09 UTC