Hi,
From: Ian Hickson <[EMAIL PROTECTED]>
> FWIW, apparently I'm not the only one who thinks that having <form> as
> child of <tbody> is intuitive.
Sure, it would be great. I've nothing against the idea in principle. I
just don't see how to execute it.
For backwards compatibility reasons we can't change what DOM we get from
misplaced <form> elements.
Why not?
Nor can we use what IE does, since IE doesn't
actually generate a true DOM tree.
Ok.
Even if we could, it would mean also
changing the CSS table model -- which ordinarily I would say is fine, but
in this case the table model is one of the most complicated parts of CSS
and changing it would be a huge amount of work.
Oh. I didn't consider that. I see the issue. The only solution I can come up
with right now is to make FORM in TABLE actually be a table-row-group
element (instead of TBODY), so UAs have:
@namespace xh url(http://www.w3.org/1999/xhtml);
xh|table > xh|form { display: table-row-group; }
...in their UA style sheet. And that <form> in tables are parsed pretty much
as <tbody> is...
E.g., this markup:
<table><tr><td>foo</tr><form><tr><td>bar<!-- parse error here, missing
</form> --><tbody><tr><td>baz</table>
...would get this DOM:
table
tbody
tr
td
#text: foo
form
tr
td
#text: bar
#comment: parse error here, missing </form>
tbody
tr
td
#text: baz
Could that work?
As it is, we have a feature that address this use case and several others
(the form="" attribute). As much as I'd love to be able to introduce
random elements into the table DOM, it really seems that doing so would be
far more pain that it is worth.
> If the main use-case for form="" is to allow forms for each TR then
> allowing the above practise would make form="" redudant for that
> use-case. Obviously form="" has other use-cases, but if implementors
> don't want it yet it can perhaps wait to WF3... I don't have strong
> opinions about form="", I only know that <form><tr> "works" in all
> browsers while form="" only works in HTML5 browsers.
It only "works" in terms of the resulting form behaviour. If you actually
constructed the same page using DOM calls, it wouldn't work (you'd either
get the wrong rendering or the wrong form associations, depending which
DOM you tried to create). What's currently happening is a giant hack, not
something that IMHO we should condone.
Indeed.
Again, I'd love to do this. I just don't see _how_ to do it within the
constraints of a sane DOM, without a huge amount of work both in updating
specs (like CSS) and implementations that use those specs.
I don't think CSS should change for this. With the above new proposal it
doesn't need to, as far as I can tell.
Regards,
Simon Pieters
_________________________________________________________________
Chatta säkrare i Messenger http://www.msn.se/security/pcsafety/messenger/