On Feb 24, 2012, at 12:18 AM, Michael Gratton wrote:
But in general, I recommend against this. Anything that can be
computed
should be computed on the server to obtain the canonical value,
otherwise
you open yourself up to attackers sending you inconsistent data.
While for applications
Bjartur Thorlacius svartma...@gmail.com schrieb am Fri, 24 Feb 2012
09:30:21 +:
In general, neither the
client nor the link he communicates over should not be trusted
unnecessarily.
Since I had difficulties parsing that, I'll try rephrasing without using
a triple negative: You wanted
[Resending to the list]
Le 22/02/12 09:48, Ian Hickson a écrit :
On Tue, 13 Sep 2011, Michael Gratton wrote:
This can be remedied by allowing the value of output elements to be
submitted. That is, include the output element in the submittable
form-associated element category.
I initially
On Tue, Feb 21, 2012 at 10:48 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 Sep 2011, Michael Gratton wrote:
HTML5 does not provide a means of submitting form content that is
otherwise rendered as normal text, i.e. not as a form control. The use
cases for this are the same as for the output
2012-02-22 19:30, Cameron Jones wrote:
Updatingoutput as form submittable element is included in a
proposal to enhance http request processing under a w3c issue
This sounds like a pointless attempt at enhancing a pointless element.
Instead of output, authors can use, and have been able to
On Wed, Feb 22, 2012 at 6:01 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
2012-02-22 19:30, Cameron Jones wrote:
Updatingoutput as form submittable element is included in a
proposal to enhance http request processing under a w3c issue
This sounds like a pointless attempt at enhancing a
2012-02-22 20:13, Cameron Jones wrote:
It [the output element]
does provide a greater degree of integration with the browser though.
Is this a requirement, or just assumed features of implementation? Which
of the assumed benefits could not be achieved by adding a new value for
the type
On Wed, Feb 22, 2012 at 6:26 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
2012-02-22 20:13, Cameron Jones wrote:
It [the output element]
does provide a greater degree of integration with the browser though.
Is this a requirement, or just assumed features of implementation? Which of
the
2012-02-22 20:38, Cameron Jones wrote:
I'm referring to the for attribute onoutput which ties its value
to the elements which went into the calculation. This would otherwise
have to be done using event attributes.
I don't see how that is supposed to simplify things. It's supposed to
On Tue, 13 Sep 2011, Michael Gratton wrote:
HTML5 does not provide a means of submitting form content that is
otherwise rendered as normal text, i.e. not as a form control. The use
cases for this are the same as for the output element, but when it is
also desirable for the result of a
Hi Mat,
Thanks for the response.
On 13/09/11 18:41, m...@matcarey.co.uk wrote:
Hi Mike, I've got some concerns with that:
HTML5 does not provide a means of submitting form content that is
otherwise rendered as normal text
I believe this is the job of CSS rather than HTML - I would say
Hi there,
HTML5 does not provide a means of submitting form content that is
otherwise rendered as normal text, i.e. not as a form control. The use
cases for this are the same as for the output element, but when it is
also desirable for the result of a calculation to be sent to the server
when
Hi Mike, I've got some concerns with that:
HTML5 does not provide a means of submitting form content that is
otherwise rendered as normal text
I believe this is the job of CSS rather than HTML - I would say that anything
due to be submitted to the server is semantically an input even if it's
13 matches
Mail list logo
