Tom Palmer wrote:
>
> > But unlike Tidy, a browser does not need to correct the DOM, since a
> > decoration applies to how fonts are rendered it can produce the right
> > rendering while producing an OpenXML-equivalent DOM in memory.
> >
> Once scripting shows up, things get rough again, though.
>
> I have an open question on a related issue. Browsers handle forms
> that overlap subtrees. If you submit the form, the right parameters
> go out.
>
> With a DOM and the current spec for HTML, how do you do that?
I'm guessing you refer to:
<FORM>
<TABLE>
<TR>
<INPUT ...
....
</TABLE>
<INPUT ....
</FORM>
Both INPUT elements will be part of the FORM controls collections even
though they are not direct children. Calling form.getFormElements() will
return a collection of two HTMLInputElement.
> I haven't studied XHTML in depth, but I imagine the enforced XML
> rules would invalidate many forms in current web pages. I think
> there may be cases where certain layouts (without using CSS-P)
> require incorrectly placed FORM tags or _extreme_ ingenuity on
> the part of the page designer.
The tough case are when people do stupid things like starting a form
just before a table row and ending it outside the table. The browser can
deal with this correctly because the browser will treat the entire table
as the form. But another browser might narrow the form to just that
table. This is dependent on how the browser maps a form to a view,
regardless of what the DOM says.
This form of behavior is undefined in HTML, the fact that it might work
with NN 4.0 and IE 4.0 doesn't mean it will keep working with NN 5.0 or
a different browser.
Most other cases work equally well with a DOM and a browser.
>
> Are there any (standardized) mechanisms for dealing with this?
HTML 4.0 is well defined and if you don't deviate from what HTML 4.0
defines and rely on a particular browser to figure out what you ment,
your HTML 4.0 will be equivalent to a well formed XHTML 1.0 document.
arkin
>
> (Basically, I bring this up since I bet Apache's Java HTML engine
> could easily be the default for Java coding in a year or two, and
> being able to deal with some of these issues could be important.)
>
> - Tom
