- From: Cameron Jones <cmhjones@gmail.com>
- Date: Wed, 22 Feb 2012 18:38:09 +0000
On Wed, Feb 22, 2012 at 6:26 PM, Jukka K. Korpela <jkorpela at 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 assumed benefits could not be achieved by adding a new value for the > type attribute (<input type=output>), or a new parameter (<input output>), > or otherwise retaining the use of <input> (which would degrade well)? > 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. >> This results in a less scripting being required and allows for >> inline scripting to be more concise which aids readability and keeps >> things together. > > > This would need to be illustrated by real examples, and you would still have > the question why this could not be achieved using libraries, without making > pages break on old browsers. > See above for less scripting. Old browsers won't be "broken" by the <output> element, they will function ina degraded state though. It's just as applicable to "fix" them using libraries. >> It's also possible for it to be styled using a >> different interface instead of elements targeted at capturing >> information. The 'disabled' state doesn't provide this for <input> > > > 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 and is a far more removed from declarative markup which is easier to understand and less error prone. I think the <output> element is conceptually simple, especially for authors with little or no programming experience. This also doesn't address the ability to style these elements in a separate and distinguishable way from <input>. Cam
Received on Wednesday, 22 February 2012 10:38:09 UTC