Discussion on:
View:
Show:
What about the extra costs of implementing css in the first place? Training of people, browser incompatability etc? Should be interesting to see what happens then.
I agree with Ben and I would also add that the differences between CSS and tables in terms of ROI would be much less if include files had been used to separate content from presentation. In that case you would not have to make the same change to multiple pages of hardcoded tables - you'd be making one change to one (or two) files just like with CSS. I'm pretty sure CSS would still win in this situation - but by a much smaller margin.
We do a lot of includes on the CNET sites and I am not certain they would help out that much. The reason being that there's so many interactions--if the including page does or does not set widths that change how the include looks, that kind of thing.
You end up with having to tweak the component a lot so that it looks okay in all the places it gets included. Or you end up tweaking all the including pages because they've each done the include slightly differently, inside of a slightly different HTML element, etc.
You end up with having to tweak the component a lot so that it looks okay in all the places it gets included. Or you end up tweaking all the including pages because they've each done the include slightly differently, inside of a slightly different HTML element, etc.
Certain assumptions were made with this test and the premise is not entirely sound. I do agree that CSS can speed up development time and maintenance, but why build all those static pages to begin with? As one responder pointed out a single ASP template, or to use my preference, a single PHP template and all those static pages go away. Either way, there would only be one page to update to handle all the products. This whole concept begs for a database storing the product info.
Using the template/database concept will not only speed up maintenance, but the addition of a few simple scripts will also provide for product updates, additions and deletions without any changes to CSS or HTML.
Once ASP/PHP and a database is entered into the equation, CSS isn't a clear winner.
Using the template/database concept will not only speed up maintenance, but the addition of a few simple scripts will also provide for product updates, additions and deletions without any changes to CSS or HTML.
Once ASP/PHP and a database is entered into the equation, CSS isn't a clear winner.
Ben:
The main reason I didn't include training costs was because I didn't want to make a bunch of assumptions about the developer that would muddy the example, I wanted to focus more on the differences between CSS-basen layouts and HTML-based ones. So the article may lean a little more towards the theoretical than the practical.
However, you raise a good point. If the developer doesn't already know CSS, then there is a learning curve there. Fortunately, that would be a one-time cost (once they learn it, they don't have to learn it again). The HTML-only costs are incurred every time.
Thanks for the comments.
Shawn Morton
The main reason I didn't include training costs was because I didn't want to make a bunch of assumptions about the developer that would muddy the example, I wanted to focus more on the differences between CSS-basen layouts and HTML-based ones. So the article may lean a little more towards the theoretical than the practical.
However, you raise a good point. If the developer doesn't already know CSS, then there is a learning curve there. Fortunately, that would be a one-time cost (once they learn it, they don't have to learn it again). The HTML-only costs are incurred every time.
Thanks for the comments.
Shawn Morton
CSS is a wonderfull progress in terms of ROI, but one can use other tools to get by old technology. For example, using templates, in DreamWeaver, let you update all your pages at once!!! Also in combination with library objects you can change stuff around pretty fast.
But the problem remains the same. You have to train people--so we might as well train them on newer technology ..!!
But the problem remains the same. You have to train people--so we might as well train them on newer technology ..!!
I just wanted to know what browsers were supported by all this CSS? I thought it was a great article; I really like CSS. But my boss has a thing for supporting old browsers like Netscape 4.08.
The newer adaptations of CSS more than likely are not supported by NS 4.08. Personally, I would have a hard time fossilizing my code so that it worked on a browser that is approaching its 7th birthday. The market share of NS 4.08 is much to low for myself to focus on that demographic.
In a way, that also shoots yourself in the foot. If you develop your site using more modern (not necessarily the MOST modern) technologies, you've in essence increased the life span of the code compatibility, given that you've adhered to W3C standards.
In my opinion this especially holds true with the recent explosion in popularity of thin client apps. Just my .02.
In a way, that also shoots yourself in the foot. If you develop your site using more modern (not necessarily the MOST modern) technologies, you've in essence increased the life span of the code compatibility, given that you've adhered to W3C standards.
In my opinion this especially holds true with the recent explosion in popularity of thin client apps. Just my .02.
IE 5 is CSS level 1, IE 5.5, css 1 and partial css2, IE 6, css 1 and partial css 2. netscape 7, css 1 and most of css 2. Mozilla (1.2+), css 1 and almost all css 2. Opera 7, css 1 and most of css 2. I am now using mozilla firebird 0.7 as my main browser and im in love with it. all my css works perfectly. not to mention, its super fast and renders pages in half the time IE6 does. surfing on a dialup, I feel like ive got slow broadband, on broadband, theres not a big difference unless you hit a really complex layout. firebird is definitely the best browser available today and for the time to come.
-- j0sh
-- j0sh
I meant the application mentioned in the article. Not what browsers supposedly support what CSS standard.
Another item to consider in this mix is that CSS also gives you a lot more preciseness and flexibility to produce a better looking site than one done with pure HTML.
A practical issue not discussed here is: when is it cost effective to CONVERT the pure HTML site over to CSS and what are the best approaches / tools to do so?
A practical issue not discussed here is: when is it cost effective to CONVERT the pure HTML site over to CSS and what are the best approaches / tools to do so?
The product listing is a lot of static HTML pages of identical structure, only the content changes. Surely these would be generated on-the-fly using appropriate parameters rather than maintaining each individual page like this? Don't want to detract from the main thrust of you argument, as I think separating presentation using CSS is the right approach, but maintaining hundreds of separate static pages individually? Ouch!
cbin:
I agree that the static HTML site in this article is not an example of the "best" way to build a site.
However, I've gotten a ton of feedback from readers who say that the reason they don't adopt CSS is because they have a site of over 100 static HTML pages.
Thanks for the comments.
Shawn Morton
I agree that the static HTML site in this article is not an example of the "best" way to build a site.
However, I've gotten a ton of feedback from readers who say that the reason they don't adopt CSS is because they have a site of over 100 static HTML pages.
Thanks for the comments.
Shawn Morton
My thoughts exactly. I too think that CSS is certainly the more elegant approach. But in this example I kept thinking "we're talking about one ASP page here...". It's a tradeoff. If you're talking about styles/attributes that are or have the potential to be site-wide then CSS, otherwise, why add another layer of complexity to something that is fairly straightforward?
I've read your response that this example is based on user feedback, but realistically... If I contracted some work for $50/hour, I'd damn well expect a database-driven site.
I mean, only a few tables are needed to store this information. Then you can write a support app to let the company itself manage the content. When next year comes around will all-new products, you'll be pulling your hair out.
Coming back to this article, I thought the same thing as ezann, people will do this 95% of the time with a few asp pages. The return on investment is not that clear if you have the following common environment:
- database-driven site
- HTML re-use tools/processes in place such as includes or templates
- already using very simple CSS for colors and fonts
The arguments for full-blown CSS based on ROI haven't convinced me any. And I know the business manager at my company never saw any difference in ROI or other stated benefits of full-blown CSS versus using CSS simply for colors and fonts. Of course you shouldn't be hardcoding a color 50 places; that goes without saying. But it seems the examples I see in newsgroups and the one in this article use extremely skewed approaches to web development to prove its point rather than how the average site was constructed 3 or 4 years ago (I've never worked on a site older than this)
Having said that, I can appreciate the work that was put in this article (hope you didn't make all those HTML changes yourself)
I mean, only a few tables are needed to store this information. Then you can write a support app to let the company itself manage the content. When next year comes around will all-new products, you'll be pulling your hair out.
Coming back to this article, I thought the same thing as ezann, people will do this 95% of the time with a few asp pages. The return on investment is not that clear if you have the following common environment:
- database-driven site
- HTML re-use tools/processes in place such as includes or templates
- already using very simple CSS for colors and fonts
The arguments for full-blown CSS based on ROI haven't convinced me any. And I know the business manager at my company never saw any difference in ROI or other stated benefits of full-blown CSS versus using CSS simply for colors and fonts. Of course you shouldn't be hardcoding a color 50 places; that goes without saying. But it seems the examples I see in newsgroups and the one in this article use extremely skewed approaches to web development to prove its point rather than how the average site was constructed 3 or 4 years ago (I've never worked on a site older than this)
Having said that, I can appreciate the work that was put in this article (hope you didn't make all those HTML changes yourself)
I agree that it should be a database driven site ( a no brainer really) however I still belive CSS provides an advantage and speeds up coding.
Eg when formating forms you can specify the width and look by typing class=textshort (if you set this up previously) in html it would be longer and you would have to remember how wide you made the others etc and lets not forget the way css can change the look of the text boxes
I would seriously urge anyone to adopt database driven techniques and the use of CSS as it in my experience provides the best ROI for the client and provides the developer with more interesting work. I have found that clients keep comming back to get new features added rather than text/image changes which can be time consuming and costly. I personally prefer working on new features rather than boring text changes.
Eg when formating forms you can specify the width and look by typing class=textshort (if you set this up previously) in html it would be longer and you would have to remember how wide you made the others etc and lets not forget the way css can change the look of the text boxes
I would seriously urge anyone to adopt database driven techniques and the use of CSS as it in my experience provides the best ROI for the client and provides the developer with more interesting work. I have found that clients keep comming back to get new features added rather than text/image changes which can be time consuming and costly. I personally prefer working on new features rather than boring text changes.
I do use some CSS other than font or colors. I agree it is useful for form elements and buttons.
However, I tend to avoid classes like "textshort". Reason? When we design forms, we don't tend to re-use as much based on size of the textboxes. Also, I try not to include hints at the implementation of the CSS class in its name to keep some kind of encapsulation.
Usually, I wind up making a class named something like "FormInput". Then I create more specific classes like EmployeeFormInput which is specific to a particular form which I want all inputs to have similar attributes (such as the same width). That way, I can have a site-wide consistent look and feel for my forms (background, color, etc.) while having the ability to customize certain forms (for example, two forms might have different width requirements for their elements). And if I don't need that employee form anymore, I can safely remove the classes that begin with "EmployeeForm".
I do use CSS for much more than font and colors. The key is when to use CSS and if you do use CSS, where to put it. If I have a page with a specific layout, I try not to "pollute" my external CSS file with styles that are specific to one page. And instead of using inline styles, you might see me dipping into tables depending what browsers I support, how complex the layout, etc. I guess my point is that positioning styles for divs and the such is in my opinion the part of CSS which is less convincing when it comes to ROI.
However, I tend to avoid classes like "textshort". Reason? When we design forms, we don't tend to re-use as much based on size of the textboxes. Also, I try not to include hints at the implementation of the CSS class in its name to keep some kind of encapsulation.
Usually, I wind up making a class named something like "FormInput". Then I create more specific classes like EmployeeFormInput which is specific to a particular form which I want all inputs to have similar attributes (such as the same width). That way, I can have a site-wide consistent look and feel for my forms (background, color, etc.) while having the ability to customize certain forms (for example, two forms might have different width requirements for their elements). And if I don't need that employee form anymore, I can safely remove the classes that begin with "EmployeeForm".
I do use CSS for much more than font and colors. The key is when to use CSS and if you do use CSS, where to put it. If I have a page with a specific layout, I try not to "pollute" my external CSS file with styles that are specific to one page. And instead of using inline styles, you might see me dipping into tables depending what browsers I support, how complex the layout, etc. I guess my point is that positioning styles for divs and the such is in my opinion the part of CSS which is less convincing when it comes to ROI.
But I would like to see a little more fair comparison, maybe 3rd category, dynamically created pages. With all the technology that has been around for a while, I dont see that many static catalog sites, It would be interesting to see a comparison, CSS should still be a little faster in that comparison, but not that much.
Having one CSS file used in 100 static pages would allow you to change fonts etc very quickly in one place. Recently i had to do a site (around 30-40 pages) all in pure html with no js or css I can tell you it was painful.
Even with advanced find/replaces etc it took far longer than it would have using includes (PHP or ASP etc)and CSS. I am picking it would have taken under half the time and changes would have been much quicker too.
Think of it this way. One header page instead of 100. Change one file once and the change is done instead of changing 100 pages. I think the biggest ROI is moving from static self contained pages to dynamic content managed sites. It sometimes costs more up front but long term it far more cost effective to have a dynamic site over a static one. Adding a new product to the example shown in the article would have been horrible compared to adding it to a properly designed database driven site (this could have been done by the client in the time it would have taken to communicate the change request)
Even with advanced find/replaces etc it took far longer than it would have using includes (PHP or ASP etc)and CSS. I am picking it would have taken under half the time and changes would have been much quicker too.
Think of it this way. One header page instead of 100. Change one file once and the change is done instead of changing 100 pages. I think the biggest ROI is moving from static self contained pages to dynamic content managed sites. It sometimes costs more up front but long term it far more cost effective to have a dynamic site over a static one. Adding a new product to the example shown in the article would have been horrible compared to adding it to a properly designed database driven site (this could have been done by the client in the time it would have taken to communicate the change request)
All things being relative and situational, the test stands as a benchmark example as to the benefits of CSS. The article accomplished its goal.
Although the article reiterates the importance of reusing code, it confusing the presentation to the browser with the generation of the underlying code.
I agree that anyone maintaining a large site as a set of pure HTML pages is a masochist. As soon as one starts to look at using code to generate the HTML, this problem goes away. In some ways it is easier to generate pages based on a common table framework than to use CSS. To move panels around, one needs only to modify the appropriate table framework.
In general, the CSS approach represents a division of labor approach, the CSS expert takes care of the page layout, while the HTML expert takes care of section content. The programmed approach does not make a real distinction in the skills to do either. The decision will primarily be based on staff skills.
Yes, get away from writing raw HTML. In doing so, however, consider all the alternatives and select the one(s) best matching your company's capabilities.
I agree that anyone maintaining a large site as a set of pure HTML pages is a masochist. As soon as one starts to look at using code to generate the HTML, this problem goes away. In some ways it is easier to generate pages based on a common table framework than to use CSS. To move panels around, one needs only to modify the appropriate table framework.
In general, the CSS approach represents a division of labor approach, the CSS expert takes care of the page layout, while the HTML expert takes care of section content. The programmed approach does not make a real distinction in the skills to do either. The decision will primarily be based on staff skills.
Yes, get away from writing raw HTML. In doing so, however, consider all the alternatives and select the one(s) best matching your company's capabilities.
Very convincing article, well written and organized.
So I right clicked on the page only to find it?s full of tables.
Regards
Ron
So I right clicked on the page only to find it?s full of tables.
Regards
Ron
The site is run by builder.com, not shawn morton. Im sure if he had his way, it would be xhtml and css. and by the way, cnet.com just went to standards comliance, so i assume builder shouldnt be that far behind in getting its redo. you cant blame the author for writing something in support of css when his company uses html. thats not his fault.
-- j0sh
-- j0sh
CNET is a very large site and, after all the layoffs of the past couple years, we have a pretty lean technical staff. It's going to take us a while to roll out broader CSS support. You'll see it happen first on the big sites like News.com and, soon, Gamespot.com.
I don't know what the schedule is for a CSS re-design of Builder.com, but it is definitely not going to happen this year.
I don't know what the schedule is for a CSS re-design of Builder.com, but it is definitely not going to happen this year.
I think the article was well written even if builder doesn't publish it using CSS. If you have a site that uses ASP, PHP, etc., you will probably let the server render the HTML and still use CSS. I think that CSS is another tool on the utility belt and like all tools you use it when it is appropriate. If I were helping a small business that had a small simple static web site why not implement a stylesheet? It is easier to maintain and is supported by most Major Browsers like IE, Netscape, Opera, Konqueror (ehh not so well). Stylesheets aren't that hard to learn and there are software packages out there to make CSS.
I use EasyAsp (Free) which contains EasyStyle.
I use EasyAsp (Free) which contains EasyStyle.
CSS for font and colour is something that I've been using for as long as I've been able to. Layout is another matter...for better or for worse after having been an old school hard coder since the pre-dawn of the internet..i can slice up my tables real nice and with a dreamweaver type templating system have an ROI that is somewhat better than what your article showed. I'll also end up with sites that will show up on 100% of all browsers, which for me is the real kicker.
Great article though...you've made me think twice about my approach and gave my buddies more ammo to knock me on.
Great article though...you've made me think twice about my approach and gave my buddies more ammo to knock me on.
You are right in saying that using CSS for sizing tables etc can cause some issues on some browsers. Personally I choose to support IE and then just make sure the page functions for other browsers. There comes a time when we must move forward and forget about the old browsers. It isn't as if it costs to upgrade (unless you need to upgrade hardware). It is not difficult to ensure that sites still function in most other browsers. But to get full functionality for all browsers requires a lot of extra effort which is not usually productive. If your site meets W3C standards and doesn't work in some browsers then that is fine by me.
First, a disclaimer - I am -unequivocally - an advocate for standards. But this is just ridiculous.
The article states - "Conversely, the HTML changes took about five to seven minutes per page. Multiply that by 97 pages, and you can easily see the difference."
WHO IS GOING TO CREATE A NEW PAGE FOR EACH PRODUCT?!?! You don't run a proper e-commerce site by creating a brand new web page for each product. You run the product pages (and the category listings, and the whole thing) from a database. Change one product page and every page changes, because every page's content comes from the product database.
The article states - "Conversely, the HTML changes took about five to seven minutes per page. Multiply that by 97 pages, and you can easily see the difference."
WHO IS GOING TO CREATE A NEW PAGE FOR EACH PRODUCT?!?! You don't run a proper e-commerce site by creating a brand new web page for each product. You run the product pages (and the category listings, and the whole thing) from a database. Change one product page and every page changes, because every page's content comes from the product database.
The real life examples were good, but any serious e-commerce site is databse driven and you'll only be modifying a single layout template per screen modification, not 97 individual pages!!
I also am for standards and CSS, but I think this article compared 2 extremes which we all know will prove a dramatic difference between the 2 methods being evaluated.
Also, I don't think you can get any contractor to do ANY updates for as little as $5.60 The author didn't take into account any overhead costs of explaining layout requirements to a contractor. I highly doubt you can get any contractor to do any work for less than a half-hour's charge, even if it's only a 5 or 10 minute update. There's always overhead.
I would like to see this article re-done without such extreme sides taken and more realistic costs for development. Like I said, I'm all for standards but I bet things can be done using CSS for around 35% LESS than straight HTML and NOT the insane amount less than this article presented.
- Kurt
I also am for standards and CSS, but I think this article compared 2 extremes which we all know will prove a dramatic difference between the 2 methods being evaluated.
Also, I don't think you can get any contractor to do ANY updates for as little as $5.60 The author didn't take into account any overhead costs of explaining layout requirements to a contractor. I highly doubt you can get any contractor to do any work for less than a half-hour's charge, even if it's only a 5 or 10 minute update. There's always overhead.
I would like to see this article re-done without such extreme sides taken and more realistic costs for development. Like I said, I'm all for standards but I bet things can be done using CSS for around 35% LESS than straight HTML and NOT the insane amount less than this article presented.
- Kurt
The thing that I absolutely love about CSS is that it allows
for a much simpler page. You can cut your page size and
make it easier for browsers to work with your content.
Another advantage, that hasn't been touched on in the
discussion that I have read is that CSS is friendlier to Search
Engine Crawlers. They don't care a thing about the layout
of the page, they only want to see the content. A linked
style sheet takes formatting out of the equation so that the
crawler can look only at the information on the page.
By using backgrounds for the page and for individual
elements, you can also remove most of the graphics from
your page as well.
I have begun to change over all of my sites that were once
in tables for design over to CSS and you know what, it isn't
that hard and I have found I can achieve the same effects
and some that I couldn't do before.
Jeff Rader
http://lubtex.com/OS/
for a much simpler page. You can cut your page size and
make it easier for browsers to work with your content.
Another advantage, that hasn't been touched on in the
discussion that I have read is that CSS is friendlier to Search
Engine Crawlers. They don't care a thing about the layout
of the page, they only want to see the content. A linked
style sheet takes formatting out of the equation so that the
crawler can look only at the information on the page.
By using backgrounds for the page and for individual
elements, you can also remove most of the graphics from
your page as well.
I have begun to change over all of my sites that were once
in tables for design over to CSS and you know what, it isn't
that hard and I have found I can achieve the same effects
and some that I couldn't do before.
Jeff Rader
http://lubtex.com/OS/
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
