Re: [whatwg] Forms: Submit only changed inputs

[dolphinling]

Ric Hardacre wrote:

...
only send input elements that have changed (i.e. are different to the 
"reset" state of the form). 


This has been proposed several times and is listed in the "For Future 
Versions" comments (view the source) at the bottom of the WF2 draft. In 
fact, it's listed twice, once as

 * only submit fields that have changed
and once as
 * A way to include in the submission a list of which form controls
   were changed from their default value.


In terms of the actual proposal you made, what's the point of those 
hidden fields you added? Why can't you just leave them out, so you have


  
  

  
  

  
  

...and when the user changes "jane doe" to "janet doe", you get

  001_name="janet doe"

...? Then all you need to do is update the 001_name.




--
dolphinling

Re: [whatwg] cross-frame cookies

[Alexey Feldgendler]

On Wed, 08 Feb 2006 17:29:46 +0600, Hallvord R M Steen  
<[EMAIL PROTECTED]> wrote:



there is some discussion surrounding cookies and security - see this bug:
http://bugzilla.opendarwin.org/show_bug.cgi?id=6797

We are wondering if it would be any use to block document.cookie
access across frames completely, or whether this would break too many
sites out there.. Any thoughts on this?


Just blocking access to cookies of another frame isn't enough. Consider  
the following example:


otherframe.document.body.addEventListener('unload', function() {
thisframe.variable = otherframe.document.cookie;
}, false);

When the unload event fires, otherframe will be accessing its own cookies,  
which is legal.



--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] <[EMAIL PROTECTED]>

[whatwg] Forms: Submit only changed inputs

[Ric Hardacre]

i mentioned this briefly in my introductory email and am interested in 
other people's views.


my thinking is this:


default behaviour, implied if "send" is missing


only send input elements that have changed (i.e. are different to the 
"reset" state of the form). this would exclude hidden elements, to 
enable the page autor to still track ownership of the form input data.


my reasoning is this:

i'm creating an HTML4 + CSS2 datagrid implimentation, the datagrid is 
quite large and i'm resorting to per-row editing to keep the overhead 
down (both in terms of client scripting and bandwidth). but if a user 
were to load the datagrid and change just on field the entire data set 
would be sent to the server. where one would either (a) validate all the 
data and overwrite the existing data or (b) cache the form info so that 
a quick comparison can be made before validation and db updating.


if, instead you could simply get a set of id's (placed in hidden fields) 
and corresponding data you could just validate and save the changed 
fields with a lot less work e.g.














if the user changes "jane doe" to "janet doe" i would recieve back

000_id=123
001_id=456
002_id=789
001_name="janet doe"

now i can see that only record 001 has any fields changed, validate 
accordingly, and hence update the "name" field for user "456".


a non-compliant legacy browser would not see the distinction and send 
all fields, which makes no difference to a good server script as it 
would in effect be performing the (a) option mentioned earlier, only 
that client's response time would be effected.


Ric Hardacre

[whatwg] cross-frame cookies

[Hallvord R M Steen]

Hi all,
there is some discussion surrounding cookies and security - see this bug:
http://bugzilla.opendarwin.org/show_bug.cgi?id=6797

We are wondering if it would be any use to block document.cookie 
access across frames completely, or whether this would break too many
sites out there.. Any thoughts on this?
--
Hallvord R. M. Steen