W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

[whatwg] including <output> in form submissions

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Wed, 22 Feb 2012 23:00:38 +0200
Message-ID: <4F455776.5090809@cs.tut.fi>
2012-02-22 20:38, Cameron Jones wrote:

> I'm referring to the "for" attribute on<output>  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 
designate dependencies, but you still need to do just the same coding as 
without it, won't you?

> Old browsers won't be "broken" by the
> <output>  element, they will function ina  degraded state though.

Certain old browsers won't recognize the <output> element at all.

>> If you wish to show results of calculation visibly _and_ pass them along
>> with the form data, you can use _both_ a normal element like<div>,<p>, or
>> <span>  _and_ an<input type=hidden>. The resulting duplication is
>> irrelevant; you have the result in a variable, or should have, and just put
>> it into two places.
>>
>> Yucca
>>
>
> This is imposing more and more on scripting

No, it's nothing in addition to what is currently done. And if you 
calculate something in scripting, you need to write it somehow into an 
element. Writing it twice, when needed, is very trivial.

> and is a far more removed
> from declarative markup which is easier to understand and less error
> prone.

I don't see how it would be less error prone. And I don't see anything 
declarative with output. It's declarative markup to say "this is a first 
level heading" (which we can say with h1) or "this is a person's name" 
(which we can't say in HTML), but it's not declarative to say "this is 
something written / to be written by a client-side script".

> I think the <output>  element is conceptually simple, especially
> for authors with little or no programming experience.

So why the discussions about including <output> in form submission?

> This also doesn't address the ability to style these elements in a
> separate and distinguishable way from <input>.

You don't need a new element (unsupported by old browsers) to do 
styling. You can use classes, or other attributes. And you don't need to 
use <input>. You can use <span> or whatever you like, and/or <input 
type=hidden>, which normally causes no rendering issues.

Yucca
Received on Wednesday, 22 February 2012 13:00:38 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:40 UTC