comment on CSS3 Box Model [Re: How is it possible to devise such a feeble system?]

On Wednesday 24 October 2001 23:59, L. David Baron wrote:
|   On Wed, 24 Oct 2001, Jesse McCarthy wrote:
|   > Here's my question: How is it possible to devise a system -- a second
|   > generation system no less -- for laying out and specifying the
|   > presentational aspects of HTML documents that is so feeble that it can
|   > not even be used accomplish the most elementary goal of horizontally
|   > and vertically centering a DIV containing some text within another
|   > DIV?
|   The basic problem here is that the CSS box model was designed based on
|   well-known concepts of document layout.  It is a very well-designed box
|   model for documents.  However, it was not designed for user-interface
|   layout.  The box model uses top-down (in the tree structure) width
|   computation and bottom-up height computation and has almost no concept
|   of bottom-up width computation or top-down height computation, which are

Re: "...based on well-known concepts of document layout."
It's pretty much correct when you think of dot-matrix printers, *good old* 
70's and early 80's.
But in 1985 Hewlett-Packard introduced first consumer-oriented laser printing 
device - LaserJet. (based on laser printing technology, which in fact was 
developed in Xerox in 1970's, and first laser printer, while not consumer 
model, was launched by Xerox IIRC in 1978)
Besides, Adobe introduced PostScript Language somewhere in early 80's too.
AFAIK both HP PCL, which now has official version 6 (PLC6), and Adobe 
PostScript Lev.3 (ver.3)  allow you to layout page in *any* direction, and 
place elements in a way you want.

So, let's recognize the fact: LineText layout in CSS is designed around 
30-years old approach, which is IMO terrible.
BoxModel (and Visual Rendering for Boxes, incl. vertical 
alignment/positioning) is designed around 10-15 years old approach, which is 
much better.
Anyway, fix for this is not so difficult - CSS3 module: the box model
is rather good, in my opinion.

Some comments on it, though:
The box model builds on the inline text model (see the CSS3 Text module 
[CSS3-text]), that describes how text is laid out on a line, including 
treatment of superscripts and bidirectional ("bidi") text. 

The flow can be horizontal (typical for most languages), but in level 3 of 
CSS, flows can also be vertical (typical for the Uighur script and often used 
for ideographic scripts). 
I can't completely agree that "Box Model" should depend on "Inline Text Model"
let suppose that I wnat just to do some very simple layout
(it uses some text, but note that you can leave text handling to "browser 
default/unspecified" in this case, or to very simplified "LineText Core"  
And this example:
illustrates layout with no any text. I just preserved W3C validation icons.
Note that I used float here, but it's not really necessary (I just used one 
of my examples, to reduce Time To market time ;-) 
- - - -
concerning CSS3 Box Model: 'display' property
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
4. The 'display', 'display-model' and 'display-role' properties
Name:  display 

inline | block | inline-block | list-item | run-in | compact | marker | table 
| inline-table | table-row-group | table-header-group | table-footer-group | 
table-row | table-column-group | table-column | table-cell | table-caption | 
ruby | ruby-base | ruby-text | ruby-base-group | ruby-text-group | none | 
inherit | initial 

Initial:  inline 
Applies to:  all elements 
Inherited:  no 
Percentages:  N/A 
Media:  visual ('none' applies to all) 
Computed value  see individual properties 
I think more resonable list of values is:
inline | block | inline-block | run-in | compact | marker |  none | 
inherit | initial 

Doesn't it sound much better?
I think 6 major 'display' property values are much better to understand, and 
in fact *can be learned* even by beginners.
In fact, beginners can start just from 'inline' and 'block', and than expand 
to the rest.
Frankly speaking, I still don't have opinion on 'run-in' | 'compact' | 
'marker' properties.
at a first glance, they look like reasonable and interesting. But as Mozilla 
and MS IE6/win do not support those properties, it's rather difficult to make 
suggestion how they can be used in real life.
But indeed, I guess that 9 values are MUCH, *MUCH* better than 25 in CSS3 

|   critical for much user interface layout.  A small reference to the first
|   of those concepts has been added as a proposed change to CSS2 [1], but
|   it have not yet been clearly defined and it is only used in very limited
|   ways.
|   A large percentage of the pages on the web are not documents in the
|   conventional sense -- they are user interface, or sometimes user
|   interface wrapping documents.  CSS is a insufficient for describing user

Hmm... Do you think that Adobe Acrobat's PDF is not a document?
AFAIK it is shortcut for Portable Document Format.
And it can include hyperlinks, etc.
|   interface -- even more so than tables are, so tables are still common on
|   the web and probably will stay that way as long as CSS doesn't have a
|   better box model for describing user interface.  CSS is being used more
|   on the web, but its box model is not replacing tables in many places --
|   it's often being used within tables.

AFAIK *tables* are not very common in PDF/PostScript.
They use 'dictionaries', which are in fact some kind of hash-tables and 
usefull way of storing/extracting data.
I guess it can be rather efficiently emulated with XMLm and than styled.
So, I think that we should leave Tables to XML, drop them from CSS3, and 
focus on adding/implementing *correct* and *simple* Box Model.
With 'inline', 'block' and 'inline-block' in place, you can layout typical 
table quite easily.
|   The XUL box model [2] is an example of a simple constraint-based layout
|   system with more bottom-up reflow based on preferred size, minimium
|   size, and maximum size, and boxes lay out their children either
|   horizontally or vertically.  It takes a number of ideas from systems
|   such as InterViews [3].  It is *much* easier to describe the
|   presentation of a user interface using the XUL box model than it is
|   using tables or using floats (which are even more of a hack than tables
|   for describing user interface).  This box model was sufficient for
|   describing the user interface of Mozilla.  It's not perfect -- there are
|   some features that it probably should have, but doesn't, but it's much
|   better for describing user interface than HTML (or CSS) tables or
|   floats.

Thanks a lot of pointers, I was looking for some time for white-papre on 
Mozilla's UI design, I guess you gave links to info I needed.
|   In the future, I'd like to see CSS incorporate display types and
|   properties to allow both types of box model.  (I'd like to work on it if
|   I can find the time to do so.)  I believe they can be mixed -- there are
|   some difficulties computing the minimum or preferred width of a box that
|   contains floats, but those problems are no worse than those that already
|   occur within tables (whose layout is based on the minimum and preferred
|   widths of its children) and satisfactory compromise solutions exist that
|   avoid causing ugly overflow.
|   -David
|   (speaking only for myself)
|   [1]
| [2] and and
| particularly
|   [3]

P.S. for convinience, I attach both examples - they are quite short.

Vadim Plessky  (English)
33 Window Decorations and 6 Widget Styles for KDE
KDE mini-Themes

Received on Thursday, 25 October 2001 05:23:32 UTC