W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2004

[whatwg] Web Forms 2.0 Feedback

From: Jim Ley <jim.ley@gmail.com>
Date: Mon, 30 Aug 2004 11:45:22 +0100
Message-ID: <851c8d3104083003456994a657@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:36 UTC