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

[Ian Hickson]

(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 
> HTML/DOM.

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.   `._.-(,_..'--(,_..'`-.;.'