Parent pseudo-containers - a method for seperation of content from design

Summary:
Defining a pseudo-container parent in CSS, not actually
seen in the html markup, that will act as a parent to the desired
elements, thus enabling us to group semantically irrelevant elements for  
styling purposes.

Reason:
Many times, to design layouts, we depend on nested divs. The nesting is
not necessarily semantic, and is just to serve the layout. So this is
against seperating content from design, also limits the author for feature  
design changes.

Explanation:
What I suggest is defining a pseudo-container parent in CSS, not actually
seen in the html markup, that will act as a parent to the desired
elements. The childs would be selected either using id's[, classes, or
selectors?]. No child could have two parents on the same degree to remove
confusion, so the last occurence of the parent-child relation setting in
the CSS is used, and the similar CSS ovverride rules apply. the order of
id's in the CSS defines the order rendered by the browser regardless of
where the id's in the markup may be [but the order in
the element shows in the markup may be deemed important only for childs
defined with classes and selectors]

A very simple example that doesn't do any justice to this proposal is
here: lets say we'll have a 2 coloumn layout with header and footer divs
that centers in the document window. The required CSS would be:

#intro, #outro, #contentwrap {width: 700px; margin: 0 auto;}
#outro {clear: both;}
#navigation {width: 30%; float: left;}
#pagecontent {width: 65%; float: right;}

And the markup would be:
<div id="intro">...</div>
<div id="contentwrap">
	<div id="navigation">...</div>
	<div id="pagecontent">...</div>
</div>
<div id="outro">...</div>

This is a very very simplified example. But you see we used #contentwrap
solely for providing a centered 700px bed for our coloumns, tho the two
div's may not be semantically related. Instead, what if we could add a
Parent Pseudo-container for our coloumns and style it?

So our new CSS would be (where our pseudo-parent is called #virtualwrap):

#intro, #outro, #virtualwrap {width: 700px; margin: 0 auto; }
#outro {clear: both;}
#navigation {width: 30%; float: left;}
#pagecontent {width: 65%; float: right;}
##virtualwrap { #navigation, #pagecontent }
/* double # define it is a pseudo-container id.
     this tells the user agent the coloumnleft
     and coloumnright should be be wrapped with a
     psueudo-"div" which can be styled.         */


and the markup would be:

<div id="intro">...</div>
<div id="navigation">...</div>
<div id="pagecontent">...</div>
<div id="outro">...</div>

No markup for styling! We can later change this design really easily
without having to add-remove any markup. Just group any element with a
parent pseudo-wrapper and there you go.

The pseudo-container would start before the first occurence of any
defined child.  Browsers may choose close the pseudo-container immediately  
and keep adding children in the pseudo-container as it loads the page for  
a dynamic display, imagine this like the page updates when the agent is  
able to load the images. Browsers may not choose to do dynamic display  
with this feature, then anything that doesn't meet the child criteria is  
put on hold (in buffer) until the pseudo container is closed, and  
displayed afterwards.

If classes or selectors are defined, the agent will have to wait until
the end of the file transmisson if not using the dynamic display method.
So using classes or selectors may not be advised or may simply kept
out of the specification, I wait for your ideas on this also. There is
less problems with id's, as there should be only on instance of an id
in the markup, so the pseudo container can be closed immediately when
id's are fullfilled. That is also going to be a nice use of id's.
As I said, the browsers may update this realtime, or wait until it can  
close
the pseudo-container. The children are *moved* into the pseudo-container
"as if they are cut and pasted", so they don't occur elsewhere. Children
of the defined child are also moved along with their parent.

It could be that pseudo-containers could also be contained with parent  
pseudo-containers. This way the whole order of markup evaluated by the  
browsers could be modified with ease, and it is not a difficult task to  
implement for the user agents either. When the browser hits a child block  
with id, it creates a virtual parent. If the virtual-parent also has a  
virtual-parent, it is also created along with it. The pseudo parents are  
closed immediately after its children are fulfilled or the file has ended,  
if so, the parent is closed after the last child with one of the desired  
id's. Pseudo-parents are rendered immediately after they are closed just  
like a normal block level element for a non-dynamic approach. Basically,  
what the user agent would do is to re-arrange the divs (and whatnot) in  
its buffer guided by our CSS.

Also, authors who have done non-flexible designs using absolute positioned  
divs (hopefully with id's)  could convert their designs to liquid and  
flexible designs for future CSS browsers without touching the markup.

This feature does not break backwards compatibility either. The authors  
could choose to include the old markup while comfortably knowing s/he  
could change his/her design later or serve a different version of design  
to browsers with this capability.

*This feature could be a seperate module in itself*, of part of the  
syntax/parsing module. I'd prefer the latter.


Pros of this method:
*No markup needed for styling
*Radical design changes could be made anytime, even for very old pages  
cluttered with extra markup (provided we had given the containers some  
id's).
*The author may rearrange the display or the presentation order depending  
on the media.
*A site usign this method may give users a chance to choose between  
entirely different layouts depending on their preferences without fancy  
server-side footwork.
*The author may also stick with the older styling-with-markup method yet  
still use this new method in conjunction, or simply feel the comfort of  
knowing that he can use this feature to re-arrange the style years later  
without having to touch the markup, that he can redefine the parent-child  
relationships in an external CSS file while not breaking old CSS-browser  
support.


Cons of this method:
*When classes or selectors are defined (if the spec would let it of  
course, I believe id's are sufficient) the user-agent would have to  
download all the html file before displaying if it doesn't choose a  
dynamic display method.

I had seen one or two pseudo wrapper disscussions during my search but
none dealt with defining children which would be its killer use, I hope
I am not repeating anything.

--
Emrah BASKAYA
www.hesido.com

Received on Tuesday, 5 April 2005 22:03:17 UTC