W3C home > Mailing lists > Public > www-style@w3.org > February 2000

Re: UI WD (compliant browser)

From: Chris Lilley <chris@w3.org>
Date: Mon, 21 Feb 2000 17:40:13 +0100
Message-ID: <38B16A6D.AE16460D@w3.org>
To: Tantek Çelik <tantek@cs.stanford.edu>
CC: "www-style@w3.org" <www-style@w3.org>


Tantek Çelik wrote:
> 
> Matthew Brealey wrote:
> > No. It means that the browsers are not compliant because the pages
> > wouldn't exist if the browsers didn't tolerate them.
> 
> Non-compliance by indirection?  I understand the blame you are laying at the
> feet of the browsers, but I'm not sure it is reasonable to call it
> non-compliance. (Exception: CSS-1 section 7.1)

I also understand the attribution of blame, and agree with it, but guilty
and non-compliant are not necessarily the same thing. Broken pages are non
compliant. Browsers which ignore normative parts of the spec are
non-compliant.

> > The fact is that by releasing incompliant browsers, Microsoft and Netscape
> > have created the problem. If Microsoft and Netscape had followed the
> > parsing rules in the first place, none of these problems would exist.
> 
> Memories are short.
> Especially internet memories it appears.

Yes, this is a new development from the meme of "Mosaic was the first
browser", now it seems the new meme is "Nav and IE are the first browsers".
Oh well.

> The long honored tradition of accepting liberally authored markup (what some
> so affectionately call "Tag Soup") dates back to at least Mosaic.  At the time
> (1994/1995?) I was distracted by other technological windmills, so someone
> else will have to fill in the history.

It predates Mosaic. Arena did have a visible icon on the taskbar when it
detected invalid HTML, but it did not use an SGML DTD to do so and got it
wrong frequently; a diagnostic that you can't trust is worse than useless.
The NeXT browser and www tolerated bad markup, though that was more to do
with the extreme simlicity of what passed for a parser than with the
elaborate error correction that was a 'feature' of later browsers.

> > Furthermore, by allowing invalid declarations or tokens (e.g., font-size:
> > "12px" or P.1), they encourage people to create invalid pages.
> 
> I think "encourage" is a bit strong.  "enable" perhaps.

Do not discourage, certainly. Provide no way of telling, is also true. The
browser makers seem slow to realise that read-only browsers are still
authoring tools. An "editing mode" switch that gave much stricter error
checking and error localisation would be a valuable feature (hint).

> Which came first?  Liberally written pages or liberally accepting user agents?

The latter, though if we refine "liberal" to mean "delibarately error
correcting" as opposed to "not checking for much" then the answer reverses
- the former.

> And once the liberally written pages proliferated, does anyone aiming to
> provide a browser which supports that content have any choice but to accept
> and attempt to do something with sloppy content?
> 
> There is not much that can be done about either the pages or the browsers out
> there.  There is quite a bit that can be done about the pages and browsers
> being written today.  I prefer to focus on the latter.

I agree, focussing on the authoring tools and browsers of today is
preferable. Also, focussing on new technologies with realistic conformance
criteria (XML) rather than totally unrealistic conformance criteria (The
HTML specs).
> 
> >> > , neither Netscape nor Microsoft will release a compliant browser.
> >>
> >> That statement makes the assumption that a browser cannot simultaneously
> >> be
> >> compliant and handle legacy uncompliant content.

A valid assumption. But I think you perhaps intended "serially" rather than
"simultaneously"?

> If the markup is invalid or not well-formed, the result is undefined*, and
> whatever the user agent produces cannot be said to be compliant or
> uncompliant.

> *At least in HTML. 

Only in HTML.

> On the other hand, XML (and thus XHTML), to its/their
> credit, does do a better job at defining how to treat non-well-formed
> documents.

I c ertainly agree for XML, and add CSS to that list as well. As for XHTML,
since it is served as text/html the chances of browsers exhibiting
conformant behaviour with non-well-formed content seem rather slight. I
would be really happy to be proved wrong on that one.

--
Chris
Received on Monday, 21 February 2000 11:40:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:04 GMT