277821 - problems with xml/xsl transformation when form tag is nested in table

Status: NEW

(Core :: XSLT, defect)

Description

[RoadbugCz]

When a form tag is nested within a table, the the result of the client side
tranformation is that the whole form tag and it's content is skipped.
For example:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.1">

<table>
 <tr>
   <td>Title 1</td>
 </tr>
 <form>
  <tr> <td>Some content</td> </tr>
 </form>
</table>

Will render only Title 1.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This is probably because we don't do any fixup of the DOM which means that the
form tag actually ends up where created. I'd be interested to know if the same
problem occurs in xhtml.

Comment 2

[RoadbugCz]

Attachment: xml file used to describe this issue

Use together with it's Test.xsl to see the transformation fail.

Comment 3

[RoadbugCz]

Attachment: xsl file to describe this issue

If you comment out the form tag, the client side transformation will succeed.
Now it will skip the content of the form tag. Use with Test.xml

Comment 4

[RoadbugCz]

It works fine with xhtml (servers side tranformation with xalan produces the
correct result).
I don't really understand why would you need to fix up the DOM as the DOM is
correct. (May be I wasn't descriptive enough)
This approach is used pretty a lot in web developement (table rows have action
buttons submiting only the row. Please, have a look at the simple example I
attached. Thx

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The DOM is not 'correct' since HTML doesn't allow <form> to be a child of
<table>. See the HTML spec.

Yes, this is very commonly used, but I think the way we implement that in
mozilla is that we fix up the DOM so that it is more inline with what the spec
says. Though I'm not sure about that which is why I ask what happens in xhtml
where we never do any fixup.

Could you attach an xhtml testcase. Please make sure you use the correct
namespace and the correct mimetype (application/xhtml+xml)

Comment 6

[RoadbugCz]

Attachment: XHTML examle doesn't work either

You were right, the xhtml doesn't work too. Is there 'any' way how to work
around this? I know I could make it html compliant and put a form tag into each
row like <tr><td><form><table>...data supposed to be in one
row</table></form></td></tr>...
But than the aligning of columns/boders etc. is difficult. Thanks.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

There is probably no workaround other then creating proper html no (perhaps you
could wrap the entire table in a form). I agree this is too bad since having
forms for a single row can be genuinly usefull.

jst, bz: Does either of you have an oppinion on this. Are we simply not going to
support rowlevel forms in xhtml? Or are we going to refer to WebForms (which
will take care of it)?

It would be quite a big change to support this. Not only would we have to teach
layout to ignore the form-tag (which is impossible to express in CSS). We would
also have to modify the DOM code so that it is able to walk one extra step up
the tree when needed.


Of course we could let XSLT perform the same fixup that the HTML contentsink
does. That wouldn't take care of XHTML though.

Comment 8

[Boris Zbarsky [:bzbarsky]]

The fact that this does not work in XHTML is just a bug.  I'll attach a patch to
fix it.  Note that correct layout for XHTML, per the CSS spec, is to wrap the
form in an anonymous table cell and to create an anonymous table inside the
form, so the entire form will be in the first (and only) cell in that row. 
That's the rendering the patch will produce on the XHTML example here and on the
original XSLT testcase (which is fixed, since it produces XHTML, not XML).

This won't help with hand-constructed HTML (not XHTML) DOMs too much (of the
sort that xslt creates in HTML mode, as I recall).  So either XSLT should do
some fixups of its own, or we should try to make this code actually deal with
forms in a better way in general.  Or neither.  ;)

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

Comment 10

[Boris Zbarsky [:bzbarsky]]

Another possibility is to add the following rule to html.css:

table > form:empty, tr > form:empty, tbody > form:empty,
thead > form:empty, tfoot > form:empty { 
  display: none !important;
}

and remove the frame constructor hack altogether.  Then, since the HTML content
sink fixes things up such that those forms are empty, they won't get in the way
in normal webpages (which is the goal), but if there's something to show in the
form we'll show it...

Note that this will lead so slightly odd behavior in XHTML documents if someone
styles the form with a border or whatnot, but I think that this is well within
the purview of what a UA stylesheet should be doing.

David, thoughts?

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Unfortunatly I don't think most people will think this solution is enough since
then they might as well make each row a separate table.

Also, why should the rendering be any different in a HTML DOM (i.e. one created
through script or xslt)?

Comment 12

[Boris Zbarsky [:bzbarsky]]

People who really care can set their form to be display:table-row...  That
should mostly work in both Gecko and IE with that code.

The reason for the rendering weirdness is that we want the form in the DOM, but
we don't want it to have margins or take up space (usually it does).  So we need
to suppress the form _somehow_.  Got a good suggestion on how to do it only for
DOMs that came through the parser?  ;)

If the proposal in comment 10 is accepted, then the rendering will be the same
no matter how the DOM was created, of course, and the same between XHTML and
HTML, given an identical DOM.  But identical source will produce different DOMs,
as now.

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

display:table-row probably won't work since then you'll have two tablerows
nested, unless of course you don't have the <tr>, but then it won't work in IE
of course...

A problem with using the rules in comment 10 is that we don't dynamically update
:empty rules (bug 98997). So if you build a table through the DOM and insert the
elements as you go the row will be hidden. Of course, we'd be no worse off then
we are right now, and it would help xslt, although only marginally.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> display:table-row probably won't work since then you'll have two tablerows
> nested

"mostly" is key here...

> So if you build a table through the DOM and insert the elements as you go the
> row will be hidden. Of course, we'd be no worse off then we are right now

Exactly.  And better off when we fix the :empty thing...

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to comment #14)
> > display:table-row probably won't work since then you'll have two tablerows
> > nested
> 
> "mostly" is key here...

Will there be a difference at all between display:block and display:table-row?
Won't both cases make the <tr> be considered a separate table?

Comment 16

[Boris Zbarsky [:bzbarsky]]

Hmm...

Actually, you may be right -- either way the <tr> will end up in a separate
table, in the first cell of the resulting row... :(

Comment 17

[Boris Zbarsky [:bzbarsky]]

Note to self -- if we take the approach in comment 10, the "form" check in
ConstructFrameByDisplayType can go too.

Comment 18

[Johnny Stenback (:jst)]

Comment on attachment 170956 [details] [diff] [review]
Patch

Clearing review requests as there's more to do here, right?

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 170956 [details] [diff] [review]
Patch

Yeah, actually this patch already went in as part of some other table-related
frame constructor changes...