Re: Stylings only possible with Tables

Daniel Beardsmore wrote:


> 
>>  4. Allow designers to constrain the height/width of sets of blocks ...
> 
> 
> This was the subject I introduced here some months back and was not well 
> understood. The only solution I've seen (that someone showed me) was 
> still a horrible hack. Combined with what you wrote in 5, this would be 
> fantastic.

I remember the discussion. I don't have a complete, well thought out solution, 
but I am thinking about something like
      .blockset1   { width: max(); height: min(); }
This would require the CSS module to find the max, or min, or other constraint 
of a group of blocks. The blocks would be defined as belonging to a class (in 
the example, .blockset1). Other limitations, as in the table layout algorithms 
would need to be applied. If I read the specification correctly, the only 
information needed is the width of the parent block and the contents of the 
*children blocks.

> 
>>  5. Design new display-models to assist (simplify) layout of web pages.
>>  Currently, designers must place elements in a flow, a table, or stack 
>> (blocks)
>>  vertically. I would like to open discussion with ...
> 
> 
> Have you read up on the CSS3 Advanced Layout module?
> 
>  http://www.w3.org/TR/css3-layout/

I haven't looked at the Advanced Layout module much, yet. This will inspire me 
to read it. Thanks for the reminder.

> 
> They have some interesting ideas for page layout, although I still 
> prefer the ideas I devised before reading about that. Instead of trying 
> to design a whole layout with letters in a string, I'd simply divide up 
> the page like a frameset. I would also permit multiple elements to be 
> slotted into page frames in sequence.
> 
> For example, if the page were split vertically into two frames, 
> "sidebar" and "main", you could write:
> 
>  #menu { slot: "sidebar" }
>  #content { slot: "main" }
>  #seealso { slot: "sidebar" }
> 
>  <div id="menu"> <!-- menu goes here -->
>  <div id="content"> <!-- main content goes here -->
>  <div id="sidebar"> <!-- see-also links go here -->
> 
> Each new div assigned to a frame slot would come after the previous one 
> or obey slot-position: replace-all | top | bottom. Top/bottom would 
> allow, for example, the sidebar to contain first the main navigation 
> menu (#menu) then the see-also links (#seealso) but have the divs in a 
> separate order, e.g.
> 
>  #menu { slot: "sidebar"; slot-position: top }
>  #content { slot: "main" }
>  #seealso { slot: "sidebar" }
> 
>  <div id="content"> <!-- main content goes here -->
>  <div id="sidebar"> <!-- see-also links go here -->
>  <div id="menu"> <!-- menu given at end of page but appears above see-also
>                       -->
Could you send me a URL for a more complete description of your proposal? I'm 
having trouble understanding the example and would like to study the plusses and 
minuses of your suggestion, so I can compare it against my own thoughts and the 
Advanced Layout module.
> 
> This makes me curious, thus, how much layout you feel could be replaced 
> by the Advanced Layout mechanism or my framed slot layout, and how much 
> cannot. I would imagine that there are separate mechanisms needed.

At least in the future I can foresee, the current layout mechanisms (inline, 
vertical blocks, and tables) won't go away. But there are much more flexible and 
simpler to use ways to lay out a page. I would like designers to have more 
choices than just -- put the next element inline or put it below the current 
one, or make a table and have everything line up. Based on my list of 
suggestions, which started this discussion, allowing designers to have a grid 
which is not a table, or to stack blocks horizontally as well as vertically, or 
to size blocks similarly which are not in a table, or even to place a stack of 
blocks and allow the user to tab through them, would be wonderful options for 
the designers.
> 
> Tabbing is awkward because although the basic layout is easy (e.g. a 
> slot where you only see one assigned div at once) you still need a tab 
> bar, which, like list markers, are in effect generated elements that are 
> not present in the HTML and require interesting considerations as well 
> as the ability to be effectively decorated.

Tabbing is not the only option, only the most obvious one. Scroll bars could 
work in the Z direction, if properly labeled. For a small number of div's, 
having NEXT and PREV icons would work. Making the border clickable could 
simulate either tabs or scrolls or both. There must be smart people in this 
group who could imagine at least a dozen others.
> 
>>  I'm waiting for the screams -- "We've never done it that way before!" 
>> I have
>>  more thoughts about use cases, standards, and implementation, if any 
>> of the
>>  above interest anybody.
> 
> 
> I really, really hope this gets taken seriously. The Advanced Layout 
> Module has not been altered since December 2005 (a year and a half ago) 
> yet is full of unanswered questions and comments for the reader. It 
> seems to be abandoned, yet, I deeply believe that such "advanced" (i.e. 
> simple) layout is *THE* weakest area of CSS and the one in greatest need 
> of resolving. Battling with floats to force CSS to give us what are 
> conceptually very trivial 2D layout concepts (side columns, 
> horizontally-ordered lists, fluid grids etc) is a very desperate sign.
> 
> 
I agree. Whenever I find a question for which the answer seems impossible, I 
tell myself that I am asking the wrong question. When layouts require deeply 
nested tables and confusingly floating objects, we are asking how we can do some 
layout when we should be asking ourselves what better ways we should implement.

-- 
James Elmore
22162 Windward Way
Lake Forest, CA 92630
Home	(949) 830-9534
Email	James.Elmore@cox.net

Received on Saturday, 23 June 2007 18:11:26 UTC