RE: How to handle orphaned form elements
"Geoff Air" <[email protected]> Thu, 22 Dec 2005 14:11:36 +1100
| Newsgroups | gmane.comp.web.html-tidy.devel |
|---|---|
| Message-ID | <[email protected]> |
Following on from Jeff's November develop post, (and bug: 1371129), since
the insertion of the <form> tag is the current way tidy is coded, then I
suppose changing this current 'normal' behaviour would have to be called a
feature change ;=))
As you well know, essentially Tidy is an single pass 'editor', fixing as it
goes, although there are some final fixes done after the file is all in ...
as each begin tag is processed, the 'lexer' calls itself to process that tag
... (hence OT: the out-of-stack for 2000+ <font ...> tags = bug: 1371313)
... and when the end tag is found, it exits that 'level', and falls back to
the previous tag 'level' ... unwinding the stack ... this is of course for
elements that require an end tag ...
So, in this case it finds <body>, so enters level n+1, until </body> is
encountered ... here I am leaving out the <html> level, since it adds
nothing to this discussion, but is important ... then it find <div>, so
enters level n+2, then <form>, level n+3 ... of course it knows about <input
...> in-block, and stays at level n+3 ... this could be represented as
follows ... the '===' representing level(s) not shown - this is best viewed
using a FIXED font - this is representing the 'node' tree being built (on
doc->node)-
=== <body> -> <div> -> <form>
-> <input>
When it finds the </div>, it presently assumes a close of the <form>, ie an
</form>, and falls back a level, emitting a warning in the process ... Tidy
does not keep end tag nodes on the doc tree - they are released - it is the
level-fallback that denotes the end tag ...
=== <body> -> <div> -> <form ...>
-> <input ...>
-> <input ...>
-> </form> implied, by finding </div> = warning 1
-> </div> (the misplaced div)
Then it finds another <input ...>, and issues another warning, no block
open, and opens, generates, a <form ...> to allow this 'input' exist, or ...
=== <body> -> <div> -> <form ...>
-> <input ...>
-> <input ...>
-> </form> implied, by finding </div> = warning 1
-> </div> (the misplaced div)
-> <form> inserted, by finding the <input ...> = warning 2
-> <input ...>
Now it encounters the end form tag ...
=== <body> -> <div> -> <form ...>
-> <input ...>
-> <input ...>
-> </form> implied, by finding </div> = warning 1
-> </div> (the misplaced div)
-> <form> inserted, by finding the <input ...> = warning 2
-> <input ...>
-> </form>, and issues another warning 3, on a <form> (it
created) that has no 'action' attribute ...
This is all good, sound coding, for a single pass 'editor' ... nothing is
'wrong' here ...
Thus Tidy could have a 'feature', under a config switch, like 'KeepForm', or
even 'TidyMergeStrayFormElements' ... when this switch is ON, Tidy could
still issue the warning that is found a end div before end form, but it
could defer its level fall-back ... then is finds the <input ...>, and is
'happy' it deferred the level fall-back - then it finds the </form>, falls
back a level, and uses up the deferred </div>, to fall back to <body> ...
represented as -
=== <body> -> <div> -> <form ...>
-> <input ...>
-> <input ...>
-> </div> - DEFERRED warning 1
-> <input ...> (happiness!)
-> </form> (freed)
-> </div> - use the DEFERRED (freed)
Essentially this would reduce Tidy to only 1 warning, provided the config
'KeepForm' switch was on ... and, more importantly produce HTML code that
will cause the form to work as intended, in all browsers ;=))
Look forward to feedback on this under-config-switch-behaviour-change ...
that is, should I proceed with CAREFULLY coding this change? Sort of - don't
let misplaced end tags get you down ;=)) The idea, at this moment, would be
to have a Node deferred; addition to TidyDoc ... each end tag would check if
it could apply the deferred end tag ... or something like that ...
Regards,
Geoff.
PS: This is my first post to this board, so please excuse any faux pas ;=))
I am a member of other open source projects, but each has its own 'flavour'
...
Sample of the problem to be addressed:
<div>
<form method="GET" action="">
<input name="login" value="guest">
<input type="submit" value="click me">
</div>
<input type="hidden" name="password" value="secret">
</form>
_________________________________________________________________
realestate.com.au: the biggest address in property
http://ninemsn.realestate.com.au
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click