| This 38 message thread spans 2 pages: < < 38 ( 1  ) || |
|Separation of Style, Structure & Content|
| 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?
| 11:15 pm 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.
You're right - layout would have been the better word to use. Structure just came to mind first :D. I'll make sure to use that from now on.
However, I do believe that - unless its a super simple design w/ little css - creating a separate file for layout is worth the effort. True - for the initial design it is easier to stick it all into one location. Hence many people, when initially designing, make all of their css embeded and when it is completed they move it out into a separate file.
And the reason it is moved into a separate file is for maintainability and for easier to read code. However, often one aspect of maintainability is forgotten here - the person/people who may join you in/take over maintenance of the website. While it maybe easier for you to leave it all in one file, it is much easier for people coming along later to maintain the website if the design is already nicely divided into separate files.
| 11:35 pm on Aug 15, 2008 (gmt 0)|
|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? |
When talking about separating the layout from other styling info, I AM keeping the designer in mind. As I said in my previous post - its for the sake of those who come in behind you to maintain the website. Your code may make perfect sense to you, and you may know how you structure you code, but the bottom line is that it is plain easier for others to understand and maintain/change your code if it is nicely divided according to what it does. It also helps you if you haven't done anything with a website for - say - 6 months and need to make some changes.
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?
I have already dealt with this in detail. See the 5th post. Chances are - especially for a 1k+ page site - your host has at least 1 server-side programming language to use. If they don't - then stick the layout information in a separate file from the other styling info. This will greatly ease the maintenance process for yourself and for anyone who has to come along after you.
| 11:46 pm on Aug 15, 2008 (gmt 0)|
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.
I haven't tried that but I'll look into it.
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).
CSS files are difficult to navigate BECAUSE they are large. Comments help but the fact remains that comments only span a line or so - and can be difficult to locate in a large css file. Besides that - what if you want multiple layouts that employ the same styling? You could copy and paste everything into a new file I suppose - but it's simply easier if they exist in separate files. If not easier for you - then certaintly for those who come along after you.
| 12:06 am on Aug 16, 2008 (gmt 0)|
|Not really, I believe most of us caught on to the template/include concept a while back. ;) |
You'd be surprised :/
|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. |
I never liked the idea of using one of those templating services myself :/ - I don't like the proposition of being reliant on them. I suppose I could program it myself like npwsol was suggesting - which I wouldn't be against providing its not too much harder to implement than includes. If it is I might start using Filter Wrappers w/ Java. I'm not sure if there is a PHP equivelent though.
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. :)
I would only use them (or embedded) if I was using includes - and then I would only put my layout css as inline/embedded. All other styles would be external. Maybe it's just me - but I like the html file to show the layout.
|Structure - "The way in which parts are arranged or put together to form a whole;" |
That's exactly what I was thinking of when I said structure. I didn't realize that it was commonly used another way - this is like the first web design forum I've been on ever.
|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. ;) |
Sounds like a fun project! I'd love to see the site.
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.
The more separation of the parts, the more control you have. ;)
| 12:26 am on Aug 16, 2008 (gmt 0)|
|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. |
I used Frontpage for a short time, and messed around with DW a little too... I h8 using them or any other webpage creating interface! Hand-Coded is the only way to do it.
This is a bad approach to naming things - if your using css to control the layout. What if I want to make that side bar appear just under the masthead and have it expand 100% horizontally. It's not a sidebar anymore is it? For maintainability you typically don't want to use a location identifier with the id. Or are you going to go in an change the id for it in all of those thousands of pages?
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?
While you need to be aware of the kind of content your structure is going to be holding - so it doesn't break - content should be irrelevant when it comes to the layout and styling of a page.
Of course, your styles are usually created around what kind of information you're going to be displaying - so there is a dependency.
| 12:30 am on Aug 16, 2008 (gmt 0)|
What about <link rel="stylesheet" href="css.JSP?page=destination" type="text/css">, where in css.JSP you could control your styles Programmatically!?
Providing the link tag would work with a file not ending in '.css' - then ya you could do that. While JSP is frequently used with HTML, it is by no means restricted to HTML. You can make it output CSS pretty easily. And, of course, even if it didn't work with the link tag - you could use a css import statement or a server-side include.
| 3:38 am on Aug 16, 2008 (gmt 0)|
|You're right - layout would have been the better word to use. Structure just came to mind first :D. I'll make sure to use that from now on. |
How about using more standardised definitions already in existence:
Structure = document (page) structure. Provided by the publishing language. In this thread HTML, including HTML elements the user agent renders with some sort of presentational aspect eg <H1> big, bold, with spacing
Style = how content is presented or "displayed" to the user. (Makes most sense in the visual world.) Produced by the user agents interpretation and application of style rules or "css".
Content = what the user agent presents or "displays" to the user - images, text, etc
edit reason - spelling
| 8:00 am on Aug 16, 2008 (gmt 0)|
Because I am referring to a very specific form of styling
| This 38 message thread spans 2 pages: < < 38 ( 1  ) |