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

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

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Wed, 06 Apr 2005 00:07:38 +0200
Message-ID: <42530C2A.2090601@students.cs.uu.nl>
To: www-style@w3.org

Sounds like ::outside

http://www.w3.org/TR/2003/WD-css3-content-20030514/#wrapping


~Grauw

Emrah BASKAYA wrote:
> 
> 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
> 


-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!
Received on Tuesday, 5 April 2005 22:07:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:36 GMT