[whatwg] input type=hidden outside phrasing content
mikewse at hotmail.com
Fri Oct 17 03:22:55 PDT 2008
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
> 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
> 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
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:
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:
INPUT obj1 state
INPUT obj2 state
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:
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
Visible INPUTs in invalid locations are moved up and in front
of their parent(s) and hidden INPUTs are moved up and behind
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
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:
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.
More information about the whatwg