handle out of order closing tags
Brought to you by:
derrickoswald
Menu
▾
▴
Logged In: YES
user_id=962193
PS: There is a <tr> missing in the code. but including that
does not change the effect.
Logged In: YES
user_id=605407
The problem is the FORM tag is inside the table column
(which is inside the table row) instead of being right after
the TABLE tag. When the /TD after input1 is encountered,
the CompositeTagScanner logic tries to close all open
composite tags on the stack that were encountered since the
matching TD tag. This closes the FORM since it starts within
the table cell.
It appears to be broken HTML, since the specification says
FORMs can contain TABLEs but there's no indication that
TABLEs can contain FORMs (which are block level entities).
It's unclear what the 'right' answer is here since most
browsers support this mess. Perhaps the lost INPUT (input2)
and /FORM should go hunting for the parent form since they
are encountered outside of a valid FORM.
Logged In: YES
user_id=962193
Hi, Derrick.
Sorry for the late response. I was away on holidays -
freezing in the corse mountains ;-).
The point with forms is - i think - that HTML ist often
written intentionally with DISrespect of the HTML tree
structure where forms are involved.
Some layout arrangements can be obtained ONLY when
disrespecting the normal HTML Tag nesting. An example for
this is the paragraph - like vertical indentation when a
form is opened. One HAS to do "dirty tricks" to avoid it
reliably.
Also in another respect the form tag is special:
With nesting one form-block into another:
Whilst normally disallowed browsers seem to interpret nested
form tags like follows:
----------8<--------------
<form name=a>
<input name=b>
<form name=c>
<input name=d>
</form>
<input name=d>
</form>
-----------8<-------------
form a contains input elements b and d
I think the technology COMMONLY used in transitional html is
like this:
when crossing the <form> tag (and if "currentform"==NULL), a
form object is created and "currentform" is assigned to the
form object. [otherwise form seems to be rendered similar to
<p>]
All form ELEMENTS are bound to "currentform" if not NULL.
further FORM tags are ignored
the first /FORM tag unsets "currentform".
if unclosed, a form is logically unclosed at the end of the
document.
After all I don't think that the form tag sould be a normal
CompositeTag since it has its special rules on nesting with
itself and since it is commonly interpreted "overlapping"
blocks by other HTML-Tags. this applies to all HTML
interpreting programs that I know of.
Logged In: YES
user_id=1367545
It is correct to close the form before input 2. Examine the
code in Firefox DOM inspector to get an idea of what it's
doing with that code.
This is what Firefox rewrites the code as:
<TABLE>
<TBODY>
<TR>
<TD>
<FORM>
<INPUT name="input1"/>
</FORM>
</TD>
</TR>
<TR>
<TD>
<INPUT name="input2"/>
</TD>
</TR>
</TBODY>
</TABLE>
Logged In: YES
user_id=962193
the point is that also firefox will treat both forms
differently: Whereas in the DOM inspector output only one
value at a time will be submitted the original version wil
transmit BOTH values. basically the DOM inspector returns
the javascript perspective to the HTML document which is not
necessarily the same as the HTML interpreters view to the
document.
Logged In: YES
user_id=605407
Changing to RFE, since this is likely to involve a major
rewrite of the underlying parse mechanism...
was Bug #923146 tag nesting rule too strict for forms
Logged In: YES
user_id=605407
See also Bug #976448 Parent TableTag has incomplete HTML
for other test cases.
test case for RFE 923146
another test case for RFE 923146
Logged In: YES
user_id=605407
Originator: NO
See also bub #1583486 Parse failed! for another test case.
Logged In: YES
user_id=605407
Originator: NO
See also bug #1575385 Mismatched TD and TR tags for another test case.