W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2006

[whatwg] Allow <form> as a child of <tbody>

From: Simon Pieters <zcorpan@hotmail.com>
Date: Tue, 31 Oct 2006 02:37:26 +0000
Message-ID: <BAY109-F407C2AA11BCF8E27CE68F7B4F90@phx.gbl>
Hi,

From: Ian Hickson <ian@hixie.ch>
> > 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/
Received on Monday, 30 October 2006 18:37:26 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:49 UTC