- From: Jim Ley <jim.ley@gmail.com>
- Date: Mon, 30 Aug 2004 11:45:22 +0100
On Sun, 29 Aug 2004 19:20:40 -0700 (PDT), Csaba Gabor <csaba2000 at yahoo.com> wrote: > > image.click(2, 5); > > > > Is that right? If so, that seems relatively simple to add. > > Perfect: > arbitraryHTMLElement.click(xLocalObjectOffset, yLocalObjectOffset) > one issue: I would think that the elemtent's onClick should be run. > Does this conflict with any current behaviour? I don't think any element click attribute is appropriate, we already have DOM events for doing this, the simple method for image input elements perhaps there's some motivation in terms of convenience, but please not on all elements, there's no point just duplicating what's already out there. > I'd prefer to use your new data: construct) It's not new, and it's not the WHAT-WG's > However, > if I click a submit button what the form looks like when the submit was > pressed is not necessarily what it will look like when it gets submitted > (names might change, elements might get added). Why not just catch the onBeforeNavigate Event? Interogate the form details there, everything is available to you, I definately do not believe automating browsers is a reason for modifying a documents standard! > Hmmm, strikes me that your new data construct will actually provide me > what I want. Direct the output embedded within a mini page to an iframe > (so please make sure standards specify no security restrictions since > it's coming from parent), NO! cross protocol scripting is dangerous, it just not be just automatically achieved - Scripting of iframes with javascript: children is blocked in IE in many situations, and I see no reason to change this for data. Definately not as specified in a standard. > Or, to take an example that hits home, what about the variety > (and I'm talking about their HTML / DOM implementations) that > we find in recent UAs (IE, Opera, Mozilla)? Clearly not > good since there is a huge amount of effort (on the part of > programmers) that goes into compensating for the differences. No, that is not a bad thing, the alternative - a single UA will result in baked in bugs (we already have this from the two browsers that were dominant at the various time, so now we're alway going to be living with NN3/4 behaviour and IE5/6 behaviour) and it will stifle development. [snip form discussion] XForms basically addresses your need - it seperates the forms behaviour from its rendering. Jim.
Received on Monday, 30 August 2004 03:45:22 UTC