W3C home > Mailing lists > Public > html-tidy@w3.org > July to September 1999

RE: Recovering from extra framesets

From: Randy Waki <rwaki@sun10.whizbanglabs.com>
Date: Fri, 17 Sep 1999 12:03:50 -0600
To: "HTML Tidy Mailing List" <html-tidy@w3.org>
Message-ID: <000401bf0136$feef4a60$ce9946a6@whizbanglabs.com>
Jany Quintard wrote:
>
> On Thu, 16 Sep 1999, Randy Waki wrote:
>
> > IE and Netscape seem to ignore extra framesets while 26-Jul-99
> Tidy treats
> > them as errors.
> >
> > I hope it's not rash to assume that in cases like this, we want Tidy to
> > approximate what most users are likely to experience in their browsers.
>
> Well, I am not sure I understand, but if Tidy is to be clean, it doesn't
> have to follow what browsers say, but what the dtd says ?

I think the issue is how to transform the non-conforming into the
conforming.

When Tidy encounters something non-conforming, it must decide if there a
reasonable way to transform the non-conforming construct into something
conforming.  If a reasonable transformation is available, Tidy issues a
warning and applies the transformation (it "tidies").  If reasonable
transformation is not available, Tidy issues an error and does not produce
an output document.

My comment about the browsers was concerning how to choose a "reasonable
transformation."  Occasionally the HTML spec recommends what to do with a
non-conforming construct, but usually we're on our own.  My
hopefully-not-rash assumption is that when the two major browsers treat
something non-conforming in the same way (in other words, they have chosen
the same non-conforming-to-conforming transformation), it is desirable for
Tidy to use that same transformation.

In the case of extra framesets, both browsers have chosen to discard the
extra framesets, so maybe Tidy should do the same.  Tidy will complain about
it and output the transformed, conforming document.  (Currently, Tidy
complains but does not output a document.)

Randy
Received on Friday, 17 September 1999 14:04:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 April 2012 06:13:42 GMT