[:D] Well done on using CSS instead of a 'skinning engine'. I could never undersatand why dotNetNuke used a skinning engine when layout and style can so easily be done in a css. I converted IBS/Portal Starter from tables to div's years ago and have never looked
back.
I could never undersatand why dotNetNuke used a skinning engine when layout and style can so easily be done in a css.
The benefit of a skinning engine is that it allows the skin to fine-tune the HTML elements. For example, a skin can "wrap" an element in an extra <div>. If you're skilled with CSS, you will know that it is sometimes imperative to tweak the HTML with extra
<div> and <span> type elements, to give CSS the hooks it needs.
The ideal solution would perhaps be a combination of a skin and CSS. The skin is used
only to inject the needed HTML elements, leaving all styling to the CSS file.
If you look at a website such as CSS Zen Garden, you will see that they use more hooks than just id and class selectors. The HTML has extra div and span elements so that you can fine-tune the CSS with selectors
such as:
body#css-zen-garden div#linkList div div ul
This fine tuning is necessary if you want a "deep" unordered list to be styled differently from an unordered list that is directly within the linkList div.
Such fine tuning is not always necessary, in which case keeping all styling in the CSS file is definitely the way to go. But more complex styling may require some additional HTML elements, so a skinning technique (like that used by DNN) helps.
Now DNN produces some of the ugliest sites on the internet, so it is easy to dismiss its skinning technique. Most DNN developers make poor use of CSS too. But as a
system, a combination of a skin for HTML and a CSS file for styling is definitely very flexible.
csszengarden's base HTML template consists of Divs with id's. Class attributes can be added to any HTML element for style. (the 2 'hooks') Both DotNetNuke and Rainbow are based on IBS. The original concept was to show case MS best practices. The framewrork
is 3 tier: Data -> Business -> Presentation (UI) layer.
I can't see how you could justify putting sytle/layout logic anywhere but in the Presentation Layer.
I'm not sure it would go down too well if I told a client that you needed to recompile their busy eCommerce site just to change the layout. (I am assuming the skinning engine is a code module.. correct me if' I'm wrong)
I can't see how you could justify putting sytle/layout logic anywhere but in the Presentation Layer.
I don't actually use DNN, but I feel sure that its skinning technique exists in the presentation layer. Or are you arguing that the styling of a webpage should be
completely separate from the generated HTML?
If so, the only HTML elements that have a reason for an ID attribute are form elements. Nothing else on the page requires an ID attribute, much less a class attribute. Many of these additional ID and class attributes exist purely for the use of the CSS stylesheet.
Hence, there is no complete separation of content (HTML) from presentation (CSS). The former is already being tweaked (by adding ID and class attributes) to suit the presentation.
So, if we accept that we must tweak the HTML by adding an ID value here and there, it is not inconsistent to instead add an extra element here and there. Both approaches (adding IDs and adding elements) are adjusting the HTML for the sole purpose of giving
the CSS its "hooks".
I am assuming the skinning engine is a code module.. correct me if' I'm wrong
Again, I don't use DNN. But the use of its skin technique, where it replaces tokens with HTML, must indeed be done by code (and not left to be done by the client, as with CSS).
I don't think we're actually disagreeing. In the vast majority of websites, all styling should indeed be done by CSS. However, in a small number of cases, a tweaking of HTML may be necessary.
I think DNN gets it altogether wrong ... it does most of the styling with a skin, leaving only a small amount to CSS. It should be reversed: all styling done by CSS, except for the rare occasion where a tweak to the HTML is required.
Alister, I am arguing that style should be completely separate from the generated HTML.
That is the purpose of CSS. Seprating style from content. You mentioned css zen garden which illustrates this concept well. ie Static HTML template but thousands of sites gerated from that single page using css without touching the HTML.
There is absolutely no need for a 'Skiining Engine'. Putting this logic in code is bad pracitse.
Anything that can be done with a 'Skining Engine'can be done in css and does not require a recompile.
IBS and it's derivities uses a simple 3 column layout. ie Left Nav, Content., Right Nav.
So just 3 Divs, why have a skinning engine?
I just don't see any need for it and consider it as a poor design .
This is my last post on this subject.. Unless someone can produce a case where a skining engine can do something that I can't do with a simple css page.
I jsut wanted to give some detail on this message, maybe strike up some extra discussion and some potential influence in things as well.
Currently there is Zen in Rainbow, which aims at bringing the layout and design to css. This is good, and what you still have are certain templating options and features that go a long way when combined.
For example you still have a template you can conrol for the html in the modules, module control buttons, menu's etc...
Also, part of the issue is the html in the modules, there is an effort currently to clean this up and bring out the use of a cleaner div system, with more control to the css as far as the modules themesleves. so that each module would have its own css file
and more control over images and such
You can preview this at www.rainbowbeta.com in some of the pages that use blogs, or the forms edit and view pages. You can also easily become a valuable member of the team if you want to assist in this, you said you already did something similar in IBS, you
can read up on lots of the plans or ideas in http://groups.yahoo.com/group/RainbowRecruits/ . Alot of effort is being geared to improving and pushing the zen engine and ideas.
Jonathan Minond
http://www.Jonavi.com
http://www.jonavi.com/Default.aspx?pageID=21
http://RainbowBeta.com
http://community.rainbowportal.net/blogs/jonathans_rainbow_blog/default.aspx
http://dotnetslackers.com/community/blogs/jminond/default.aspx
I think that you misunderstand the "skinning engine" in DotNetNuke (DNN):
1. DNN "skins" are zipped packages consisting of HTML, CSS, and any required images.
2. HTML is required because because a DNN skin applies to the ENTIRE page, not just the three panel content area. A DNN skin can have ANY number of panels for individual page header and footer items, individual navigation items, and content. A skin package
typically has skins for one content panel pages and either two or three content panel pages.
3. There is code in the DNN application that applies skins to pages, which I guess could be called an engine, but there is NO code in a skin package. Nothing needs to be recompiled when a new skin is applied.
There is debate among DNN "skinners" about the feasibility of pure CSS skins, but, personally, I don't see how you can achieve the same functionality without HTML. You need something to create the the variable number of divs, right?
Mmmmm... can't comment in depth on DNN, but I can clarify, for the sake of the general readership, what the skinning facilities are in Rainbow.
Rainbow has two alternative "skinning" methods available. These are 1) Classic and 2) Zen.
Classic is the original skinning system for Rainbow, based on Layouts and Themes. The layout determines the overall HTML structure of the page and the Theme determines the CSS applied to the page as well as the HTML structure of a module container. This
system is relatively easy to understand and implement, but suffers from an HTML--heavy approach (i.e. the use of tables for layout control, etc.)
Zen is a new system, written by myself, which provides a radical alternative to Classic. It is still based on Rainbow's notion of Layout and Theme (for backward compatibilty), but now the Layout specifies
only the overall page structure (e.g. whether a menu is in the header area or the left column). There is
no formatting per se in the Layout. The Theme supplies the CSS and completely determines the appearance of the final page. Zen uses "pure CSS" techniques, i.e. all layout control is done with <div> elements and CSS positioning. Zen's
own Navigation control produces a straight-forward <ul> structure, which is styled entirely by the CSS (although Zen can make use of the alternative DHTML/Javascript Rainbow menu systems).
Rainbow Zen was inspired by CSS Zen Garden (hence the name). Like CSS Zen Garden, if you disable CSS when viewing a Zen page, you see an orderly, readable "plain HTML" page, i.e. headings, paragraphs, bulleted lists (navigation), etc. Indeed, this is the
view that would be seen by any search engine spider, as well as text-based browsers (including, importantly) screen reader applications.
Is Rainbow Classic a "skinning engine"? Is Rainbow Zen a "skinning engine"? Yes, I'd say they both are: the term is a loose one. Neither requires any recompilation to switch themes. Neither contains any code (although Classic Layouts can get a bit "code-y").
The difference is that Classic relies on "old-fashioned" HTML: nested tables and (long-since depracated) tags like
font, size and so on. Zen uses div elements and CSS in a 100% modern, "standards compliant" way.
Is Zen easier than Classic? Probably not - most people think they "know" CSS because they can write
p.Normal{color: red} and <p class="Normal">...</p>. Controlling the entire layout and appearance of a page with CSS requires "advanced" CSS skills and is anything but easy the first time you try it. But without a doubt Zen/CSS is more powerful
overall than any table-based HTML layout system, is standards-compliant, is more easily 508-compliant, is inherently search engine friendly, etc.
Is Rainbow Zen a "better" skinning system than DNN's? You bet!
spawned
Member
165 Points
33 Posts
CSS the way to go.
Apr 30, 2005 06:51 AM|LINK
SomeNewKid
All-Star
45894 Points
8027 Posts
Re: CSS the way to go.
Apr 30, 2005 08:04 AM|LINK
The benefit of a skinning engine is that it allows the skin to fine-tune the HTML elements. For example, a skin can "wrap" an element in an extra <div>. If you're skilled with CSS, you will know that it is sometimes imperative to tweak the HTML with extra <div> and <span> type elements, to give CSS the hooks it needs.
The ideal solution would perhaps be a combination of a skin and CSS. The skin is used only to inject the needed HTML elements, leaving all styling to the CSS file.
spawned
Member
165 Points
33 Posts
Re: CSS the way to go.
Apr 30, 2005 09:51 AM|LINK
The only hooks required are the id or class contructors. I replaced the Table layout with divs so I can control layout and style 100% via CSS.
SomeNewKid
All-Star
45894 Points
8027 Posts
Re: CSS the way to go.
Apr 30, 2005 11:01 AM|LINK
If you look at a website such as CSS Zen Garden, you will see that they use more hooks than just id and class selectors. The HTML has extra div and span elements so that you can fine-tune the CSS with selectors such as:
body#css-zen-garden div#linkList div div ul
This fine tuning is necessary if you want a "deep" unordered list to be styled differently from an unordered list that is directly within the linkList div.
Such fine tuning is not always necessary, in which case keeping all styling in the CSS file is definitely the way to go. But more complex styling may require some additional HTML elements, so a skinning technique (like that used by DNN) helps.
Now DNN produces some of the ugliest sites on the internet, so it is easy to dismiss its skinning technique. Most DNN developers make poor use of CSS too. But as a system, a combination of a skin for HTML and a CSS file for styling is definitely very flexible.
spawned
Member
165 Points
33 Posts
Re: CSS the way to go.
Apr 30, 2005 11:40 AM|LINK
csszengarden's base HTML template consists of Divs with id's. Class attributes can be added to any HTML element for style. (the 2 'hooks') Both DotNetNuke and Rainbow are based on IBS. The original concept was to show case MS best practices. The framewrork is 3 tier: Data -> Business -> Presentation (UI) layer.
I can't see how you could justify putting sytle/layout logic anywhere but in the Presentation Layer.
I'm not sure it would go down too well if I told a client that you needed to recompile their busy eCommerce site just to change the layout. (I am assuming the skinning engine is a code module.. correct me if' I'm wrong)
Cheers,
Shaun.
SomeNewKid
All-Star
45894 Points
8027 Posts
Re: CSS the way to go.
Apr 30, 2005 12:36 PM|LINK
I don't actually use DNN, but I feel sure that its skinning technique exists in the presentation layer. Or are you arguing that the styling of a webpage should be completely separate from the generated HTML?
If so, the only HTML elements that have a reason for an ID attribute are form elements. Nothing else on the page requires an ID attribute, much less a class attribute. Many of these additional ID and class attributes exist purely for the use of the CSS stylesheet. Hence, there is no complete separation of content (HTML) from presentation (CSS). The former is already being tweaked (by adding ID and class attributes) to suit the presentation.
So, if we accept that we must tweak the HTML by adding an ID value here and there, it is not inconsistent to instead add an extra element here and there. Both approaches (adding IDs and adding elements) are adjusting the HTML for the sole purpose of giving the CSS its "hooks".
You can read about this more in the following article:
Separation: The Web Designer’s Dilemma
Again, I don't use DNN. But the use of its skin technique, where it replaces tokens with HTML, must indeed be done by code (and not left to be done by the client, as with CSS).
I don't think we're actually disagreeing. In the vast majority of websites, all styling should indeed be done by CSS. However, in a small number of cases, a tweaking of HTML may be necessary.
I think DNN gets it altogether wrong ... it does most of the styling with a skin, leaving only a small amount to CSS. It should be reversed: all styling done by CSS, except for the rare occasion where a tweak to the HTML is required.
spawned
Member
165 Points
33 Posts
Re: CSS the way to go.
Apr 30, 2005 01:19 PM|LINK
Alister, I am arguing that style should be completely separate from the generated HTML.
That is the purpose of CSS. Seprating style from content. You mentioned css zen garden which illustrates this concept well. ie Static HTML template but thousands of sites gerated from that single page using css without touching the HTML.
There is absolutely no need for a 'Skiining Engine'. Putting this logic in code is bad pracitse.
Anything that can be done with a 'Skining Engine'can be done in css and does not require a recompile.
IBS and it's derivities uses a simple 3 column layout. ie Left Nav, Content., Right Nav.
So just 3 Divs, why have a skinning engine?
I just don't see any need for it and consider it as a poor design .
This is my last post on this subject.. Unless someone can produce a case where a skining engine can do something that I can't do with a simple css page.
Cheers,
Shaun.
jminond
Contributor
2898 Points
608 Posts
Re: CSS the way to go.
Apr 30, 2005 02:21 PM|LINK
Currently there is Zen in Rainbow, which aims at bringing the layout and design to css. This is good, and what you still have are certain templating options and features that go a long way when combined.
For example you still have a template you can conrol for the html in the modules, module control buttons, menu's etc...
Also, part of the issue is the html in the modules, there is an effort currently to clean this up and bring out the use of a cleaner div system, with more control to the css as far as the modules themesleves. so that each module would have its own css file and more control over images and such
You can preview this at www.rainbowbeta.com in some of the pages that use blogs, or the forms edit and view pages. You can also easily become a valuable member of the team if you want to assist in this, you said you already did something similar in IBS, you can read up on lots of the plans or ideas in http://groups.yahoo.com/group/RainbowRecruits/ . Alot of effort is being geared to improving and pushing the zen engine and ideas.
http://www.Jonavi.com
http://www.jonavi.com/Default.aspx?pageID=21
http://RainbowBeta.com
http://community.rainbowportal.net/blogs/jonathans_rainbow_blog/default.aspx
http://dotnetslackers.com/community/blogs/jminond/default.aspx
mickjones
Member
220 Points
44 Posts
Re: CSS the way to go.
May 06, 2005 04:24 PM|LINK
I think that you misunderstand the "skinning engine" in DotNetNuke (DNN):
1. DNN "skins" are zipped packages consisting of HTML, CSS, and any required images.
2. HTML is required because because a DNN skin applies to the ENTIRE page, not just the three panel content area. A DNN skin can have ANY number of panels for individual page header and footer items, individual navigation items, and content. A skin package typically has skins for one content panel pages and either two or three content panel pages.
3. There is code in the DNN application that applies skins to pages, which I guess could be called an engine, but there is NO code in a skin package. Nothing needs to be recompiled when a new skin is applied.
There is debate among DNN "skinners" about the feasibility of pure CSS skins, but, personally, I don't see how you can achieve the same functionality without HTML. You need something to create the the variable number of divs, right?
jes1111
Member
45 Points
9 Posts
Re: CSS the way to go.
May 19, 2005 01:43 PM|LINK
Mmmmm... can't comment in depth on DNN, but I can clarify, for the sake of the general readership, what the skinning facilities are in Rainbow.
Rainbow has two alternative "skinning" methods available. These are 1) Classic and 2) Zen.
Classic is the original skinning system for Rainbow, based on Layouts and Themes. The layout determines the overall HTML structure of the page and the Theme determines the CSS applied to the page as well as the HTML structure of a module container. This system is relatively easy to understand and implement, but suffers from an HTML--heavy approach (i.e. the use of tables for layout control, etc.)
Zen is a new system, written by myself, which provides a radical alternative to Classic. It is still based on Rainbow's notion of Layout and Theme (for backward compatibilty), but now the Layout specifies only the overall page structure (e.g. whether a menu is in the header area or the left column). There is no formatting per se in the Layout. The Theme supplies the CSS and completely determines the appearance of the final page. Zen uses "pure CSS" techniques, i.e. all layout control is done with <div> elements and CSS positioning. Zen's own Navigation control produces a straight-forward <ul> structure, which is styled entirely by the CSS (although Zen can make use of the alternative DHTML/Javascript Rainbow menu systems).
Rainbow Zen was inspired by CSS Zen Garden (hence the name). Like CSS Zen Garden, if you disable CSS when viewing a Zen page, you see an orderly, readable "plain HTML" page, i.e. headings, paragraphs, bulleted lists (navigation), etc. Indeed, this is the view that would be seen by any search engine spider, as well as text-based browsers (including, importantly) screen reader applications.
Is Rainbow Classic a "skinning engine"? Is Rainbow Zen a "skinning engine"? Yes, I'd say they both are: the term is a loose one. Neither requires any recompilation to switch themes. Neither contains any code (although Classic Layouts can get a bit "code-y"). The difference is that Classic relies on "old-fashioned" HTML: nested tables and (long-since depracated) tags like font, size and so on. Zen uses div elements and CSS in a 100% modern, "standards compliant" way.
Is Zen easier than Classic? Probably not - most people think they "know" CSS because they can write p.Normal{color: red} and <p class="Normal">...</p>. Controlling the entire layout and appearance of a page with CSS requires "advanced" CSS skills and is anything but easy the first time you try it. But without a doubt Zen/CSS is more powerful overall than any table-based HTML layout system, is standards-compliant, is more easily 508-compliant, is inherently search engine friendly, etc.
Is Rainbow Zen a "better" skinning system than DNN's? You bet!