[whatwg] input type=hidden outside phrasing content

[Mike Wilson]

Anne van Kesteren wrote:
> I'd suggest playing with validator.nu. Out the top of my head:

Ah, thanks for the link. I tried the different examples
and your hunch was correct for all of them (tables and lists
having problems).

> 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.
Along the way the system may want to insert hidden state 
that it wants posted back later, and the easiest way to
accomplish this is something like inserting a hidden input
just after the respective snippet's top element.
(If there are snippets designed for actually editing the data 
these will have been hand-coded to include inputs in valid
places so this is not an issue.)

So, for an example hierarchical object structure:
  obj1
    obj2
      obj3
we may have the following associated HTML snippets:
  obj1 -> TABLE...
  obj2 -> TR...
  obj3 -> TD...

If we want the system to insert hidden state along the way 
the naive solution would look like this:
  TABLE
    INPUT obj1 state
    TR
      INPUT obj2 state
      TD
        INPUT obj3 state
which is not valid.

We could make this smarter by moving TABLE's state before the
element instead of as first child, but the TR is harder to fix. 
We could have the system add an extra TD to hold the state for 
the "row object" but this is starting to affect the rest of
the page a bit much.


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.

 
Kristof Zelechovski wrote:
> So, where a paragraph is not allowed, neither is the INPUT 
> control; inserted where it does not belong, it migrates; the 
> document is invalid but it can be rescued.

I had a look at migration in a TABLE structure for a few 
different browsers (by inspecting the DOM) and the results are 
sort of interesting:

Firefox 3:
Hidden INPUTs are kept in their exact place where they were
specified but "visible" INPUTs in invalid locations are moved 
up and in front of their parent element(s) until they have a 
valid position.

Safari 2:
Visible INPUTs in invalid locations are moved up and in front
of their parent(s) and hidden INPUTs are moved up and behind
their parent(s).
Though, POST parameter order is preserved and not affected by 
the INPUT reorganization in the DOM.

Safari 3 and Chrome:
All INPUTs in invalid locations are moved up and in front of
their parent(s).

Opera 9.60:
All INPUTs in invalid locations are kept in the exact place
they were specified in and no migration is done. (And visible
fields are still displaying correctly.)

IE6 and IE7:
All INPUTs in invalid locations are (sort of) kept in place 
but are wrapped with an extra unnamed element, f ex:
  <TABLE>
    <>
      <INPUT>
    <TR>
    ...

Summing this up I think FF3 has an interesting behaviour as
they sort of already do what I am suggesting. Visible INPUTs
should be placed where their element is allowed to be 
rendered, but hidden INPUTs could really be placed anywhere.


Best regards
Mike Wilson