[whatwg] About <input type="hidden">

Ian Hickson ian at hixie.ch
Tue Nov 11 17:11:19 PST 2008

(I've not replied to all the e-mails on this thread because they are 
mostly redundant with this one. Please let me know if you made a point 
regarding <input type=hidden> that you think needs changes to the spec 
that I missed.)

On Fri, 17 Oct 2008, Mike Wilson wrote:
> Anne van Kesteren wrote:
> >
> > For the table and lists cases, is there a good use case for 
> > complicating their content model
> This being a good or important use case is hard to say - I guess it is 
> one of these real-world annoyances that both webdevs and browsers have 
> learnt to cope with. As part of the HTML5 initiative is based on 
> real-world browser behaviour I was thinking this may be a candidate for 
> some spec adjustment in some form (maybe just defining graceful 
> migration).
> > or could you just as well put the input either before or after the 
> > table or list?
> For hand-coding I certainly could, I see no real reason to do what I 
> suggest here when you are in control of the complete markup.
> But it gets harder for the scenario I was mentioning in my initial mail: 
> [some incarnations of] server-side templating. Many templating systems 
> work with the whole page at once to specify what markup to generate for 
> specific data, but for more decoupled systems you may want to specify a 
> HTML snippet per object type or similar - and then apply recursive view 
> rendering on an object graph.

I agree, but it seems that having the hidden inputs be inside the next
<li> of a list, or the next <td>, or whatever is appropriate, isn't much 
to ask for.

> Andy Lyttle wrote:
> > This is something I wanted to do recently.  I was building HTML in a 
> > Perl script, adding table rows in a loop, and I wanted some rows to 
> > contain text field with user-editable value, while for other rows I 
> > wanted the value to be displayed but not editable
> Yes, this is sort of similar to my scenario above, and you were able to 
> workaround it being in control of the whole markup in one place (and not 
> completely decoupled as I describe above). I think this is one of those 
> things that webdevs keep hitting every now and then, and it is caused by 
> a kind of inter- mingling of document structure and POSTable state in 

For Perl, it's definitely possible (and relatively easy) to just store the 
hidden inputs until the next suitable place (e.g. the next cell).

> Assuming you are in control of the whole page's markup at once then I 
> agree. But when you are not and, it may be far from trivial. (I 
> mentioned an example of this in the link I included earlier.)

I don't really follow why it's so hard in that case, but maybe you should 
use a better templating language. :-)

> Ian wrote:
> > > - keeping the whole thing invalid but still define in HTML5 how 
> > >   the migration of ill-placed <input>:s should work
> > 
> > That is theoretically already defined.
> Interesting. Is it the foster-parenting of tables you are referring to, 
> or is there anything more specific for <input>:s?

Yes, foster parenting, and also the form element pointer, etc.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list