[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-layout
Subject:    Re: NG layout and 5.0 Navigator
From:       "Todd Fahrner" <fahrner () pobox ! com>
Date:       1998-07-31 19:50:38
[Download RAW message or body]

In article <35C0D3C9.220978ED@wired.com> , taylor <taylor@wired.com>  wrote:

>I think that it would be a disastrous error for Netscape to release 5.0
>without 100% of CSS working 100% correctly.

Me too.

Angus Davis wrote:

>Integrating a new layout engine into the old mozilla codebase is no easy 
>task. You're
>right to point out that NGLayout would need to be feature complete, bug free, and
>backwards compatible with content designed for Nav4.x.  

This last bit troubles me. It seems to me that full backwards compatibility
would commit you to extensive emulation of Nav 3/4's anomalous behaviors in
NGLayout. I hand author complicated layouts using tables and all the other
tricks, and it's basically a black art, witness the difficulties of
"wysiwyg" editors. There's a whole lot of undefined (or at least really,
really, really screwy) behavior going on in the current model, and this is
what authors have been authoring to for a few years now. This is especially
the case with CSS support, but table layout too (esp when relative measures
are involved). Don't get me started about inheritance and tables. I'm really
looking forward to a more coherent model, but then I hear you're not going
to integrate NGLayout until it is compatible with Navigator-optimized
content. Say what?!

I don't think it can be done. If by some truly awesome expenditure of
cleverness, sweat, and tears y'all succeed anyway, it will be impressive the
way freak shows are impressive. I'm not suggesting for one instant that you
release a browser that breaks much of the Navigator2/3/4-optimized content
out there. Please consider taking a modal approach: ship a browser with 2
independent rendering systems. Use the legacy system for legacy content. Use
NGLayout when rendering documents authored in either HTML 4.0 Strict or XML
(this will include HTML 5.0). Pay attention to the DOCTYPE. Encourage
authors to use HTML 4.0 Strict (or well-formed variant, for which you
provide a DTD) or XML, and outline a plan to phase out the legacy renderer.

Bloat? Can a 100% legacy-compatible NGLayout really be much more lean than
the legacy system and a "clean" NGLayout together? The maintenance issues
for a single hybrid engine must be pretty sticky, too. The biggest issue, I
think, is that a legacy-supporting NGLayout will not prompt any behavior
changes in authors and authoring-tool makers, and this, I submit, will be
the death of Navigator as a serious content platform. IMO, NGLayout needs to
show some tough love if it's to escape the quicksand of casual authors'
unreasonable expectations for error tolerance and kludge support.

    * * *

I'm a little perturbed by the amount of effort (apparently) going into
tweaking the table rendering code. For every 1000 Web pages that use tables,
I'll wager that no more than 5 use them solely for representing tabular
data. The rest use them for layout. A truly complete CSS1 implementation
could replace the tables in 995 of those documents, with much less total
code to download, parse, and generally plug up the Web with. In other words,
I think there's more bang for buck in supporting CSS to the point that it
can replace tables for their most common abuses than in improving table
support per se.

Complete, consistent, accurate support for the following (conspicuously
neglected) CSS1 properties <em>ACROSS ALL APPLICABLE MARKUP ELEMENTS</em> is
a minimum condition for retirement of tables-as-layout:

1. The display property (e.g., the ability to cause H1 elements to display
as list items, or list items to display inline, or table heads to display as
blocks, etc.)
2. The box model (margins, paddings, borders)
3. The float property (see http://www.w3.org/Style/css/Test/float ,
http://www.w3.org/Style/css/Test/movies )
4. The width property

"Absolute positioning" isn't in this list, because it's not the silver
bullet it's been billed as. It's not adequately flow-aware (flow happens),
and the back-asswards way inheritance works in positioning (from child to
parent!) is for social workers to deal with.

Disclaimer:
>From an engineering POV, I realize my suggestions here might be totally
goofy. I'm ready to believe that. As a Web author, though, I've got a lot
more ammo to support my position. If this is the wrong forum, please point
me to another and I'll take it there, with apologies.

[prev in list] [next in list] [prev in thread] [next in thread]