W3C home > Mailing lists > Public > www-style@w3.org > July 2005

New layout language.

From: Orion Adrian <orion.adrian@gmail.com>
Date: Mon, 4 Jul 2005 23:57:25 -0400
Message-ID: <abd6c8010507042057e8c0ef1@mail.gmail.com>
To: www-style@w3.org
If you haven't already please read the primer.

The following is a description of a simple layout language designed to 
replace the layout portion of CSS at all levels.

Rather than create a syntax, I'm just going to describe the structures, 
properties and values. Please excuse any non-standard elements in the 
structure of this proposal, it's my first. All names are subject to changes.

The system is very simple in its design. The layout system simply uses two 
(2) images of a static layout to produce a linear function for the upper 
left and lower right coordinates of each region. This has several benefits.

Each region also has a role value that describes what kind of content goes 
into each region.

So a region's coordinate properties break down into the following:

A left, top, width and height. Each of these properties takes a percentage 
value and a length value. Right and bottom could be used instead of width 
and height to the same effect, but aren't here.

Percentages are defined the same way they are in CSS. lengths are defined as 
follows: Widths and heights and specified in em units. Actual adjustments 
will be done at render time into pixels or inches/centemeters.

The constant portion of each part represents the minimum layout (i.e. the 
appearance of the layout with the smallest viewport before it starts to hide 
elements). The percentage part controls the layout as the viewport resizes.

Calculating what the top and left values of a region should be is fairly 
simple. Simply look at the element above or to the left of the element in 
question, take its top, left, width and height values and add them 
appropriately taking into account padding between regions.

Region A (a region 1em down and 2em to the right of the viewport. The region 
does not move or change size during a viewport resize; it will always be 
20em wide and 5em tall):

left: 0% + 2
top: 0% + 1
width: 0% + 20
height: 0% + 5

Region B (a region that gains everything fromcontent body to the immediate 
right of Region A):

left: 0% + 24 (calculate the right coordinate of Region A and add 2 padding)
top: 0% + 1
width: 100% + 100 (this will be 100em wide and widen 1em for every 1em the 
viewport widens)
height: 100% + 20 (this will be 20em tall and lengthen 1em for every 1em the 
viewport lengthens)

Region C (another navigation pane with similar dimensions)

left: 100% + 126
top: 0% + 1
width: 0% + 20
height: 0% + 5

It also becomes easy to check to see if the layout grows incorrectly. The 
percentage part of any right coordinate (left + width) should be less than 
100%. Similarly the percentage part of any bottom coordinate (top + height) 
should be less than 100%.

Regions can optionally be embedded using the parent's left, right coordinate 
as reference instead of the viewport. There is no constraint on the size of 
a embedded region. Overflow is scrolled.

Each region is then given a role. When navigating to content, it searches 
the <link> structures in an HTML document and populates the various regions 
with the appropriate content (e.g. table of contents, index, favorites, RSS 

This concludes the basics of what I'm proposing. Further add-ons will come 
shortly as well as a rewrite after I get feedback.

Additional constructs are coming to cover the edge cases and additional 
needed functionality.

Orion Adrian

p.s. I appologize for how badly it's written, but I'd like to get it out 
before too long. This is a very rough draft and I appreciate constructive 
comments that aid in refining it. I am not looking for reasons it won't work 
and shouldn't be done. I think that ground has been covered. And yes I know 
it's not a formal proposal. We'll get to that.

Orion Adrian
Received on Tuesday, 5 July 2005 03:57:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:19 UTC