W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1997

AW: coping with overlapping elements in the DOM

From: (wrong string) öter <martin.schloeter@mb-interactive.de>
Date: Wed, 6 Aug 1997 09:54:31 +0200
To: <www-dom@w3.org>, "Lauren Wood" <lauren@sqwest.bc.ca>
Message-Id: <07550775800247@mb-interactive.de>
-----Ursprüngliche Nachricht-----
Von: Lauren Wood <lauren@sqwest.bc.ca>
An: www-dom@w3.org <www-dom@w3.org>
Datum: Mittwoch, 6. August 1997 00:45
Betreff: coping with overlapping elements in the DOM

>One of the big problems in trying to come up with a reasonable
>specification for the DOM is trying to figure out how much we
>should do to cope with broken HTML documents. Obviously
>seriously broken documents will cause so many problems
>that we just don't want to get into, but there are some
>classes of common mistakes that we can maybe allow.
>One of these classes of mistakes is overlapping elements,
>of the form
>Since we don't really want to encourage people to write broken
>documents, there is also the problem of whether we should do
>anything for overlapping elements at all. The choices are:
>1) don't do anything for overlapping elements
>2) do something and deprecate it immediately, so it will be in level
>one but not level two
>3) put it in without deprecating.
>The DOM WG would like feedback on this issue. Which option do
>you think the best?
I would like to suggest an approach usally used in software development
environments (most professional class libraries are using such an approach).
In normal "runtime mode" the browser should do it's best to show the end
user a "normal" looking HTML documents. The HTML-engine should fix as much
inconsistencies as possible.
BUT: The developers/producers of Web-Browser/HTML-engines should be
encouraged (comitted?) to implement a kind of "debug mode" in their
HTML-Engines. Running in this "debug mode" all failures in the HTML page
shall be explicit and obvious marked/shown as an error.
With such an two mode approach the HTML authors are getting excellent
chances to fix their bugs and to write solid code. The enduser nearly
allways gets a "nice picture", regardless in what state the actual page is.

More details on this two mode concept is found in "Writing Solid Code",
Steve Maguire, Microsoft Press.

MB-Interactive Online & Multimedia GmbH
Martin Schlöter
Received on Wednesday, 6 August 1997 03:55:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:03 UTC