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

It can do what ::outside does but I didn't intend to suggest it to do what  
::outside does. You can re-group elements and rearrange order of elements  
with an ultra simple syntax. It can do what move-to does but it does  
heavens lot more.


On Wed, 06 Apr 2005 00:07:38 +0200, Laurens Holst  
<lholst@students.cs.uu.nl> wrote:

>
> 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
>>
>
>



-- 
Emrah BASKAYA
www.hesido.com

Received on Tuesday, 5 April 2005 22:30:28 UTC