homepage Welcome to WebmasterWorld Guest from 174.129.103.100
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderators: not2easy

CSS Forum

This 38 message thread spans 2 pages: 38 ( [1] 2 > >     
Separation of Style, Structure & Content
csuguy




msg:3721844
 9:57 am on Aug 13, 2008 (gmt 0)

One of the big advantages of CSS is that you can stick all of the styling info somewhere other than the content. This makes editing both the style & the content much easier. Let's face it - font tags were a pain to use and edit, and code was a mess. When we took out the font tags and the majority of other styling tags like <b> and <i>, the editing process was made much simpler in that regard.

However, in our rush to separate style from content, we ended up mixing up the structure of our pages with the style. Because of this, editing the structure of a page with even a moderately complex layout becomes a real challenge. And this isn't even because the code maybe that difficult, but simply because different areas of coding are being mixed together. Comments help some, but in large files they aren't overly helpful. And CSS files get real big real fast when you are relying on them for everything but content.

I believe that these 3 should be separated. CSS files should NOT contain anything but the most insignificant of structural data. If CSS is necessary for the structure, inline styles should be used! Whether using divs or tables, the structure of the page should be very easy to see just by looking at the html code within the body tag!

Of course, then the problem becomes the separation of content from structure! While not completely separate with the traditional CSS-Div methodology, it is true that - for the most part - the structure of a page and the content are kept fairly separated. However, there is an easy solution to this - Compilation Pages. By breaking the structure into 2 separate files and putting the content of pages into a 3rd file, you can dynamically piece together your pages using server-side programming. Easy Server-Side Programming at that! Then, when you want to make a site-wide structural change you simply change the code in the 2 structural files.

By breaking down the code into 1 css file (or more if needed) and the structure into 2 files (or more if some pages have a different structure) and putting the content of all your pages into separate files, you create a website which can instantly change its styles, structures, or content in the blink of an eye!

What do you think?

Ryan

 

Xapti




msg:3722227
 5:32 pm on Aug 13, 2008 (gmt 0)

when you refer to structure, you're talking about things like width, positioning, etc.?
I consider these to be style information nonetheless. Unless someone's using fixed or absolute positioning, the order/orientation and nesting of elements in a site (it's structure) is pretty straightforward looking at the HTML source code. I consider structure to be different from just position and size though; so while a nav bar may appear to the side of a page, it's order in the HTML is still what's most relevant in the overall structure.

Maybe I'm just not understanding what you mean by this term "structure".

g1smd




msg:3722336
 7:34 pm on Aug 13, 2008 (gmt 0)

I much prefer to mark up my content as headings, paragraphs, lists, tables and forms. The only other on-page HTML is for links and images, and for a small number of div containers.

All the styling goes into the external CSS file. That file is used by every page of the site. No way would style information ever go back into the HTML file... I want to be able to change the style of a thousand page site simply by editing one CSS file.

csuguy




msg:3722480
 10:14 pm on Aug 13, 2008 (gmt 0)

When I refer to the structure of a page/site, yes I am refering to its positioning in the page - and also how different things function when you put content in them. So things like position, overflow, visibility, top + left, margin+padding, etc.

Here's a simple example of a body that uses css divs (assume an imported css file):


<body>
<div id="content">...</div>
<div id="links">...</div>
<div id="header">...</div>
<div id="footer">...</div>
</body>

So, tell me, from looking at this, what can you really tell about what the page looks like or how its structured? You know the various sections and their content, but you don't know where these are positioned on the page nor do you know how they respond when content is increased/decreased. You don't know what is position relative vs absolute - or even what's just in the normal flow of the document. Heck, you don't even know if the components are visible! And of course the order that it appears in the html is no guarantee that that's the order it will appear on the site.

To figure that out you have to go through a large css file - which is large because it contains style AND structure information. Hopefully you only have to look for an id - but in even moderatly complex designs you have to worry about it being indirectly modified in mulitple spots throughout your document.

It is much easier to edit the styles and structure of a website when they are kept separate! It's the same exact idea as keeping style separate from content - and it works!

csuguy




msg:3722513
 10:59 pm on Aug 13, 2008 (gmt 0)

@g1smd

I am not saying put your style information in the html page - simply the structure information. Now - if you have no way to do server-side programming, then its probably easier to just stick the info in a css file - separate from the style css file. If you keep the css for structure in a separate file from the style then you can create multiple structures for different pages, but keep the same styles. But I still dont like this method as it requires you to edit two files rather than one when changing the structure.

Now, if you have access to server-side programming then things become REAL easy. Right now, if you want to add a section to your webpages, you have to go into them one by one to add it in. True - when your done you can control them with your css file - but first some structuring has to be added to every single page! This could be a div, a set of divs, a table, w/e.

NOW, what if all of the structure was kept separate from you styles and content? What if a change to the structure document acted like it did with css - taking instant effect over the entire site! No more going through hundreds of webpages to add a little div - now you can just change 1 (or sometimes 2)!

Here's an example:

structure_top:

<html>
<head>
<!-- Include styles,scripts, title and Meta Info here-->
</head>

<body style="margin:0px">
<div id="container" style="position:relative;width:740px;height600px;margin:auto;">
<div id="header" style="position:absolute;top:0px;left:0px;width:100%;height:150px;">
<img src="banner.png" style="width:100%;height:100%;">
</div>

<div id="link_bar" style="position:absolute;top:150px;left:0px;width:100%;height:20px;background-image:url('link_background.png');">
<!-- links go here -->
</div>

<div id="sub_container" style="position:absolute;top:170px;left:0px;width:100%;height:430px;">
<div id="content">

And that's where the structure_top file would end. Then in a structure_bottom file you would finish it with:


</div>
<div id="footer">
<!-- footer info -->
</div>
</div> <!-- end of content_footer_container -->
</div> <!-- end of main container -->
</body>
</html>

Finally you put all of the content into separate files like: home.html, contact.html, about.html, etc.html. You'll still have spans and p's and other small things like that in the content files, but they will be completely separated from the structure! Now when I want to add something to all of these pages I simply edit the structure_top and or structure_bottom file accordingly. Not only that - but it is extremely easy to visualize a website built like this. If you need more than one structure to use throughout your website - you simply create a top and bottom file for each structure and use your server-side programming to piece it together!

Here's a simple example server-side page that would piece together pages for you:


<%
String page = request.getParameter('page');
if(page == null) page="home";
%>

<jsp:include page="structure/top.html">
<jsp:include page='<%= "pages/"+page+".html" %>'>
<jsp:include page="structure/bottom.html">

And your done! You could then acquire pages like so: www.domain.ext/?page=destination. For example if I wanted the contact page I would type in www.domain.ext/?page=contact - simple as that! Now editing my structure is a sinch - much easier than mixing it partially in with both the css file and the content files!

Ryan

csuguy




msg:3722517
 11:02 pm on Aug 13, 2008 (gmt 0)

I wish the code block thing would work better :/

alt131




msg:3722850
 11:42 am on Aug 14, 2008 (gmt 0)

What if a change to the structure document acted like it did with css - taking instant effect over the entire site! No more going through hundreds of webpages to add a little div - now you can just change 1 (or sometimes 2)!

Sever side languages are often employed to efficiently reuse elements common to multiple pages.

What I don't understand is your reasoning for proposing this as a css technique to separate structure, style and content as server-side assembly isn't css, and doesn't guarantee the three will be seperated anyway.

csuguy




msg:3723065
 4:45 pm on Aug 14, 2008 (gmt 0)

What I don't understand is your reasoning for proposing this as a css technique to separate structure, style and content as server-side assembly isn't css, and doesn't guarantee the three will be seperated anyway.

No, CSS isn't server-side assembly. But it is a valid technique which - when used in combination with CSS - makes maintance super easy! You should mix all available tools in web development so that the whole creation, implementation, and maintenance process is easy and effecient. I might have put this in a server-side section, but i didn't see one for the forum :/

Anyways, while it is not CSS specifically, it is a method which solves what I see as a major problem with css - and that is the mixing of style and structure. They are different and separating them makes the editing process that much easier. Even if you don't have server-side programming at your disposal - they should be kept separate. And not only should they be kept separate but you should be able to know how a page is structured simply by looking at the html.

Also, there is a guarantee that they will be separate. It requires that you program it properly - but you can ensure that they will be kept separate by simply spending the time to set it up correctly initially.

alt131




msg:3723368
 10:41 pm on Aug 14, 2008 (gmt 0)

I might have put this in a server-side section, but i didn't see one for the forum :/

Make a selection from the front page: [webmasterworld.com ]

(Mods please modify if the link is not OK)

csuguy




msg:3723435
 12:08 am on Aug 15, 2008 (gmt 0)

What do you know, there are a couple server-side ones. Though the code I used is JSP and I don't see a JSP section. I do know PHP so I could post it there. However, I still feel that this is the section my post belongs in - as it is about the role of css in web development and how it should be implemented along side other technologies for easier maintenance.

Like I said - even if you dont have server side programming at your disposal you should do at least 2 things: separate your structure css from your style css AND program your html files so that the structure can easily be deciphered without looking at the css files. These two things allow for much easier maintenance of websites.

If you don't have server-side programming then using inline styles may not be a good idea for maintenance. And that's fine - it just means your going to have to use a bit more html (maybe even a table) to show the structure. You don't have to put every single detail, but it should be clear what goes where - and comments should be used to provide important structural details that can't be derived from the html - like if overflow is being used and what kind of positioning is used for the object.

You see then that while I highly recommend Server-side Programming to help with development, it is not about Server-Side Programming but about the role and implementation of css in regards to structure and style.

buckworks




msg:3723444
 12:21 am on Aug 15, 2008 (gmt 0)

id="container" style="position:relative;width:740px;height600px;margin:auto;"

When you already have this:

id="container"

it's pure code bloat to also have this:

style="position:relative;width:740px;height600px;margin:auto;"

Except in VERY rare cases, info like that should be in the external stylesheet, not presented inline.

csuguy




msg:3723448
 12:29 am on Aug 15, 2008 (gmt 0)

@buckworks

the purpose of the id is not so that the structural css can be restated in an external file. The purpose of the id is so that style css can be used in an external file - separate from the structure code.

And of course - I wrote it inline with the assumption that you were using Server-Side Programming to piece the files together. If you weren't using Server-Side Programming, no you wouldn't want inline styles - but you would want to separate the style css from the structure. And - IMHO - your HTML code (using comments if need be) should very clearly define the structure of your page. It's fine to use css to define the structure, but what can be done in HTML to show the structure should be used. I gave an example case in an above post that is pretty common for CSS-Div sites - the html file gives no indication of the structure of the page.

I believe mixing your structure with your style is just as bad as mixing your style with your content - ideally all should be separated.

g1smd




msg:3723472
 12:59 am on Aug 15, 2008 (gmt 0)

Use two separate CSS files then.

I think it silly to have inline styles on the page. If I need to alter the structure, then I want to be able to edit one CSS file to do that, not have to edit thousands of HTML pages.

buckworks




msg:3723473
 12:59 am on Aug 15, 2008 (gmt 0)

To me, things like position, margins, height, width etc. are all part of style.

Structure refers to the semantic structure of the document, which has its own logic regardless of where things happen to be positioned on the page.

csuguy




msg:3723478
 1:12 am on Aug 15, 2008 (gmt 0)

@g1smd

You still don't understand the Server-Side Programming that I have presented - it wouldn't require you to edit thousands of pages! Just one maybe two depending upon what you are changing. And that includes when you have to add something to the structure of the webpage - which you CANNOT do with CSS. If you wanted to add something to the structure of the webpage you would have to go and add it to all of those thousands of pages.

Furthermore, by having your html and structural css side by side - it is very easy to visualize (and thus edit and maintain) your site. If it's mixed in with styling info (like font, text-size, text-alignment, etc.) then it can become a real pain to isolate those parts which are purely structural.

And - like I've said - if you don't have access to server-side programming then dont use inline styles. There are still two other issues - separation of structure from style AND coding your html files so that they clearly show how a page is structured.

csuguy




msg:3723483
 1:17 am on Aug 15, 2008 (gmt 0)

@buckworks

Well, I'm not sure what you mean by 'Semantic Structure' - but surely you recognize that the structure of a document is a very specialized area of styling. From my experience, mixing this code together is a mistake as it all becomes very hard to separate and isolate. You CAN still work with it like that - but just like separating styles from content, separating the structure from styles is that much more efficient when it comes to maintaining and changing a site.

buckworks




msg:3723494
 2:22 am on Aug 15, 2008 (gmt 0)

I'm not sure what you mean by 'Semantic Structure'

That's been clear for quite a while.

csuguy




msg:3723501
 2:41 am on Aug 15, 2008 (gmt 0)

I know what semantics is - I'm just not seeing a connection to semantics and to what your saying. Not that I care much about semantics in the first place though - I care about what is applicable and efficient in the real world. I follow standards up to the point that they start to conflict with other details of web design - like maintainability. Maintainability - to me - is far more important than standards. They should go hand in hand - but they don't.

alt131




msg:3723573
 5:58 am on Aug 15, 2008 (gmt 0)

buckworks
To me, things like position, margins, height, width etc. are all part of style.

... you, me, and the w3.

And a lot of css people generally accepted as guru/experts - but that line didn't play nice in rhyme ;)

Marcia




msg:3723583
 6:47 am on Aug 15, 2008 (gmt 0)

One of the big advantages of CSS is that you can stick all of the styling info somewhere other than the content.

Taking the topic a bit further, how about browser-side vs. server-side?

With PHP, coding is usually imbedded within the HTML of pages. How about imbedding PHP code vs. having the PHP code separate, apart from the pages themselves?

That would keep the page structure/HTML and styling/CSS, which are the front end, separated from the code, which technically speaking, is back end processing.

vincevincevince




msg:3723746
 11:23 am on Aug 15, 2008 (gmt 0)

Structure is part of the content; however it is very very rare that structure needs more than the very basic HTML tags (A, H1, H2, EM, DT, DD, etc.). If you are talking arrangement, size etc. then that's not structure, that's style.

Receptional Andy




msg:3723756
 11:41 am on Aug 15, 2008 (gmt 0)

csuguy - I believe what you are referring to as 'structure' most other people would call 'layout'. As applied to HTML, structure usually refers to the use of semantically meaningful elements like headings, paragraphs, lists and the like. Part of the goal of CSS is to leave HTML structure to HTML, and confine the bulk of control of visual appearance (i.e. including layout) to CSS.

You could always use a separate style and structure CSS file, but personally I would find that adding an extra layer of complication, rather than ease of use, except for the most complicated of CSS-based designs.

It's the same reason that an ID of "footer" is much better than an ID of "bottom" - you are likely to want to change the layout without changing the underlying HTML structure.

Marcia




msg:3723772
 12:21 pm on Aug 15, 2008 (gmt 0)

Here's a simple example of a body that uses css divs (assume an imported css file):

<body>
<div id="content">...</div>
<div id="links">...</div>
<div id="header">...</div>
<div id="footer">...</div>
</body>


And does the "links" id tell whether those links are on the right side or the left side of the page (or the middle) visually in a browser?

So, tell me, from looking at this, what can you really tell about what the page looks like or how its structured? You know the various sections and their content, but you don't know where these are positioned on the page nor do you know how they respond when content is increased/decreased.

Does that really matter, looking at the HTML source code? The designer may know and care, but does the visitor care, or is the visitor just looking at the appearance in his/her browser?

You don't know what is position relative vs absolute - or even what's just in the normal flow of the document. Heck, you don't even know if the components are visible!

Why does that matter, from a presentation viewpoint?

And of course the order that it appears in the html is no guarantee that that's the order it will appear on the site.

So what? Isn't that the whole idea behind keeping them separate?
Bottom line:

If, for example, the links are in a sidebar across a 1K page site and they're on the left and hard coded into the HTML on pages, what if you want to change them from being on the left side to being on the right side? Are you going to go in and change the layout of the page on 1K pages, individually?

pageoneresults




msg:3723778
 12:51 pm on Aug 15, 2008 (gmt 0)

Right now, if you want to add a section to your webpages, you have to go into them one by one to add it in.

Not really, I believe most of us caught on to the template/include concept a while back. ;)

True - when your done you can control them with your css file - but first some structuring has to be added to every single page! This could be a div, a set of divs, a table, w/e.

Just to a few pages, the templates. After that, there is no more fiddling with structure. Its a one time proposition usually. And those templates can be constructed using any number of technologies.

And not only should they be kept separate but you should be able to know how a page is structured simply by looking at the html.

Heh! If we had a set standard for naming conventions and structure, the above would apply. But, we don't. Most people who understand HTML can view the source and get a pretty good feel for what is what. Although in some instances, it is an absolute mess. The bots think so too.

Like I said - even if you dont have server side programming at your disposal you should do at least 2 things: separate your structure css from your style css AND program your html files so that the structure can easily be deciphered without looking at the css files.

Ya. I prefer plain and simple html elements with no further tampering. I don't want to use inline styles either, that would be my last option. I would first look at external, then embedded, and then inline, in that order. That's me though. :)

Structure refers to the semantic structure of the document, which has its own logic regardless of where things happen to be positioned on the page.

That's how I've always perceived it.

Structure - "The way in which parts are arranged or put together to form a whole;"

Compilation Pages. By breaking the structure into 2 separate files and putting the content of pages into a 3rd file, you can dynamically piece together your pages using server-side programming. Easy Server-Side Programming at that! Then, when you want to make a site-wide structural change you simply change the code in the 2 structural files.

I wish there were only two structural files! I'm looking at a new store platform and there are 100s of structural files based on the dynamics of the compilation pages. Those XML libraries are pretty hefty. ;)

It is much easier to edit the styles and structure of a website when they are kept separate! It's the same exact idea as keeping style separate from content - and it works!

Agree! Agree! And, we all have "our" ways of doing things whether they are correct or not. Most of us try to stay in tune with the standards. Sometimes we do things that may not jive 100% with those standards and it all comes down to education and how to best utilize the tools you have available to you.

Separation of Style, Structure & Content

The more separation of the parts, the more control you have. ;)

npwsol




msg:3723797
 1:15 pm on Aug 15, 2008 (gmt 0)

As Andy says, semantic structure is where you use tags as they're intended to be used. I.E., H1 is your header, P is your text content, using a list to create a list (of, say, links). It can also be argued that it implies representing the flow of content in your source as it appears in your document. Basically, it's describing your document to the interpreter(browser) in a way where it doesn't have to read the content to know its purpose.

I believe with HTML5 there will be significant improvements to the "semantics" of a given document. (someone correct me if I'm wrong)

Using inline styles is a bad idea. Using server-side include files is a good idea, but not how you're thinking, it appears. If you have a consistent header and footer, throw those in a file and include them in each page.

Or here's one for you: instead of just using include files, make a server side application that manipulates the DOM of a template file to insert content. If you're looking to have two or three files to maintain, that's a fairly effective method.

CSS files are not difficult to navigate, interpret, or maintain whatsoever if you put a few moments into making sure that related information is kept close together. Inline styles, however, are extremely difficult to maintain and defeat the entire purpose of CSS. Inline styles are meant for limited exceptions to rules (hence they override everything).

You've got your head in the right place; code maintainability is paramount, especially on large sites. However, that comes hand-in-hand with good, semantic markup and well-organized CSS.

Marcia




msg:3723799
 1:17 pm on Aug 15, 2008 (gmt 0)

How about looking at this, including naming conventions, from the point of view of context regardless of the aesthetics or location in the visible page or source HTML code.

If you've ever had to do maintenance on a site that has the CSS willy-nilly all over the stylesheet (like Dreamweaver puts it when you modify a style element), you can then know that context is king.

<div id=masthead"> is the top, visually. What else can it mean? It could include the logo, the shopping cart info (view cart/check out), byline and top navigation.

<div id="pagefooter"> is obviously something at the bottom of the page. Where else is a foot? It can include copyright, date of last update, sitewide navigation links, etc. And it can be different and differently named for homepage and information pages, section main pages or section detail pages - styled differently accordingly.

<div id="sidebar"> is on the side. What else could it mean? It can be the "side" section with navigation and whatever else, either on the right or left; take your choice and change it easily, without changing hard coded HTML on dozens, hundreds, thousands or millions of pages.

Where ever it is in the code, properly annotated and coded in the CSS, anyone can go in and make modifications. It matters not one lick whether the pages are sequential as related to the sequences in the stylesheet (which can have multiple types of organization), or using CSS-P, or where they are visually to the visitor.

It's all about context and maintainability.

Added:

As an addendum, does anyone want to comment on the maintainability of content? Content can be hard coded onto web pages or be accessed via a database. Just to nit-pick about terminology, does that have anything to do with style or structure (I think not), or does anyone think otherwise?

[edited by: Marcia at 1:29 pm (utc) on Aug. 15, 2008]

npwsol




msg:3723860
 3:23 pm on Aug 15, 2008 (gmt 0)

Marcia - As to your addendum, it really comes down to what the content is. For instance, I'd say if you're calling links content, then you can definitely style and structure links. But body copy? That's just crazy.

I'm sure we've all run into the instance where the content breaks the structure, but I gather that's not what you're referring to.

Content could theoretically be used stylistically, but in the general sense it's irrelevent whether it's database fed or static content; the content itself typically has no play on the style or structure of a site.

blend27




msg:3723903
 4:23 pm on Aug 15, 2008 (gmt 0)

csuguy,

What about <link rel="stylesheet" href="css.JSP?page=destination" type="text/css">, where in css.JSP you could control your styles Programmatically!?

blend27

MattAU




msg:3724149
 10:23 pm on Aug 15, 2008 (gmt 0)

In the past few of weeks I've just started breaking my CSS code into two different files - layout and styles. It's going well so far, but I'm starting to think about splitting it out again into three files.

Layout - The layout of the page, position of content blocks, menus positioning etc.
Styling - Text size, font, boldness, borders, small positioning adjustments to make things like 'right'
Colouring - Colours and other styling that will have no impact on the layout.

To me this seems like a complex, yet logical way of doing it. I guess it depends a fair bit on the size and type of sites you're making, but I tend to make many small sites and don't have any flagship sites, so this seems like the easiest way to make future styling changes simple.

csuguy




msg:3724169
 10:59 pm on Aug 15, 2008 (gmt 0)

Taking the topic a bit further, how about browser-side vs. server-side?

With PHP, coding is usually imbedded within the HTML of pages. How about imbedding PHP code vs. having the PHP code separate, apart from the pages themselves?

That would keep the page structure/HTML and styling/CSS, which are the front end, separated from the code, which technically speaking, is back end processing.

Personally, I already separate my PHP & HTML as much as possible - providing it isn't a simple 1 liner. The only exception - for me - is forms. PHP/JSP allows you to check the form and move on to the next page or - if there are errors - display the errors, fill in the fields which were filled in, and put any extra characters/formating that is necessary.

If you take a look at my earlier Server-Side Programming Example - kept all layout information, server-side code, and style information separate. The less connected all of the different aspects of web design are to each other - the better.

This 38 message thread spans 2 pages: 38 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved