By now we all know the benefits of “web standards” - creating sites where content and presentation are separated by use of semantic XHTML and CSS. Early adopters of web standards have long extolled the many payoffs, which include:
- Greater accessibility for all, including users with disabilities, users on various platforms and browsers, and users accessing websites via handheld devices
- Greater flexibility in easily delivering variations of the same content, such as print or high contrast alternatives
- Smaller page sizes and faster downloading, which saves bandwidth and ultimately money
- Better search engine rankings because search robots can more quickly and easily crawl your pages and discern their content
- Increased ease of maintenance due to simplified code and style-sheet controlled presentation
- Increased ease of redesign in the future, since all presentation can be handled in the style sheet
But how realistic is this last point, really? Table-based layouts might be a nightmare of nested cells and font-tags, but CSS-based sites can be outlandishly overwhelming with their many, many nested divs and spans, their plethora of IDs and classes, and their multiple style sheets with their many hacks. Sites that I myself built just a year or two ago would be impossible to completely redesign without starting from scratch. So although it’s nice to think that all web-standards-based sites are Zen Garden like, the truth is that many, many of them are just as difficult as their table-based counterparts to redesign.
What Can Be Done?
So, what can we as developers do to make the hype real? Part of it comes naturally - as we develop our skills as CSS mavens we logically begin to create more organized, simplified, and versatile style sheets, we move away from creating unnecessary classes and IDs and begin to make better use of the cascade, and our XHTML becomes more simplified and more semantically structured.
But I think we can take it a step further. I suggest that we begin to code our XHTML first, independent of what we plan for the layout to be. Let’s code our XHTML as if we plan to have 10 different designers apply their own unique layouts to it. If we can do it that way, then we will be able to execute minor or even major design overhauls without touching a single page in the site. And what’s more, any other developer will be able to do the same. That would be a true realization of the hype.
Seeing the Light
I first began to see the possibilities of coding this way when I was charged with implementing the realign of Energy Muse, a site I had coded a year before. Energy Muse had redone their logo, and therefore wanted a site-wide facelift that would reflect their altered branding. This was the first time that I had been involved in the realign of one of my own sites since I had begun to master CSS. I was amazed to discover how easy it was - to my surprise and delight I found that I did not have to touch the html even a little bit! Uploading a few new images and an updated CSS sheet was all that was required to transform this:
Into this:
And then (in a later realign) into this:
Now, while this was exciting, it’s not quite as impressive as it could be, because the basic structural layout of the site was unchanged. It really was just a facelift, as opposed to an extreme makeover. But it was enough to inspire me to really try to do it right next time.
Recently I coded the Deluxe Digital Media website with the idea in mind that we would eventually have multiple layouts to choose from - our own mini Zen Garden. This was, I believe, the first time I’ve really done it right in terms of my markup. And it was this experience that was the impetus for this article.
So What Does Doing It Right Mean?
Besides trying to clear your mind of your intended layout, there are a few other things to keep in mind when writing the XHTML first.
Semantic Markup
Obviously, the most important thing to start with is making your markup semantic. Semantic markup is simply the use of the proper tags for content elements – heading tags for headings, paragraph tags for paragraphs, list item tags for list items, etc. In addition to the basics, you might be wise to also use tags like
and , in addition to , and the like. For a more in-depth look at semantic markup, including some tags you may have forgotten about, see Blue Anvil’s Guide to Semantic Markup.Flexible ID and Class Names
In an effort to keep everything about our markup layout-independent, try to give IDs and classes names that relate to their structure, rather then their appearance. So, instead of id=”left_column” try id=”main_content”, instead of class=”small” try class=”copyright”, etc.
Enough Hooks
As CSS mavens, there’s one thing we know we need to have in our markup, and that is enough “hooks” to attach our CSS to. Traditionally, we put these hooks in as we need them. In our new improved way of doing things we will have to put them in wherever we might need them.
For example, in the Deluxe Digital Media site we use live text for our navigation - no images, and nothing fancy. But instead of this:
I wrote it like this:
Now, I have the hooks I might need to do something more complicated with the navigation in the future. The surrounding div gives me an additional element to style and attach margin, padding, borders, or background images to. The spans surrounding the text will allow me to hide that text in the future if I wanted. The unique IDs for each link will allow me to assign different background images to those links. Together, the spans and IDs allow me to use image replacement techniques for my navigation elements. The possibilities become endless.
Additionally, I would be inclined to add a couple extra divs at the top and bottom of the body of the document to ensure maximum agility. Something like this:
Actual Content Behind Flash or Descriptive Images
You might notice that the Deluxe Digital Media site uses some Flash animation on the front page. This animation, similar to a large descriptive image, contains important information. This is information that cannot be read by screen readers, nor accessed by handheld devices, nor indexed by search engines. For these reasons, I have made this information readily available in semantic markup. The markup is hidden. But, since I have wrapped my Flash movie in a div with an ID of Flash, I could in the future decide to unhide the markup and hide the Flash instead. Now, in a case where there is only one instance of Flash on the home page it might make more sense to just go in and remove it - but if you had Flash on multiple pages and perhaps wanted to serve up a Flash-alternative site (or simply a printer-friendly site) with the switch of a style sheet then this method would really come in handy.
Wait a Minute: Is all this Semantic?
Now I know that one of our favorite pastimes as standards advocates is arguing over extraneous markup and glorifying the leanest, meanest code possible, however it seems to me that sometimes we can take this too far and actually do ourselves a disservice. Yes, it’s true that the markup I am advocating includes some additional divs and spans and such. But I ask you to consider what makes more sense - creating the cleanest, leanest, meanest markup possible that we can revel in and pat ourselves on the back for, but which some poor developer in the future will have to completely redo in order to accommodate a new design? Or letting go of the need for what we’ve come to think of as perfection in order to create a solid foundation that can withstand redesigns in the future. What is more important, to save a few kilobytes now, or hours and hours of time recoding down the road?
Imagine…
You are charged with implementing a design overhaul for a site you have never worked on before. You have the PSDs in hand as you go to look under the hood of this site. You prepare yourself for the nightmare of someone else’s convoluted code. However, to your astonishment, you find a site that is so well coded with semantic markup, flexible IDs and classes, plenty of hooks, and real content hidden behind any Flash or descriptive images that you do not have to work with the XHTML at all. No dreadful find and replace mishaps. No recoding all the pages from scratch. Just a Zen-Garden-esque experience. PSDs, a style sheet, and you.
Let’s live up to the hype.
Mani, your article is an elegant contribution to the process required to chip away and fix in the minds of clients the benefits of a “document first” approach. As developers we tend to write content first and hang our visuals on top. Clients however want to “see” something as part of a pitch, so the process is sometimes stubbornly visually led. Slowly though, as an industry, we’re finding that our clients are becoming increasingly aware of a “Standards led” approach, the value of good information and the benefits of the long game. Thanks for the insight and ideas - critical mass is right around the corner.
Nice writeup, Mani.
One point that I would add to you discussion is that of all the “benefits” you mentioned, only one has to do with improving the actual user experience.
And, while greater accessibility is possible through standards, how much is Amazon, Google, Yahoo, etc. losing out because of their lack of compliance?
You could make the argument that they’re losing money through bandwidth costs, flexibility in development, etc, but I would really hesitate to make those claims without knowing the individual cases of each company. They’re not fools, after all.
The real difference is that successful sites focus with laser-like precision on providing value for users. In more cases than not, web standards are still a “nice to have” rather than a real game-changer. The accessibility they do add doesn’t add a tremendous amount of value for most people. (it does add a lot for those with disabilities)
With structured data on the rise (RSS, microformats, etc) things will start to change and web standards will be adopted more. But only when the user experience is markedly better…
Mani, I thought your article was brilliant for its simplicity. Thanks for writing this.
[…] Web designer Mani Sheriar has written a brilliantly easy-to-understand piece on ThinkVitamin.com about making your Web pages flexible in their design. If you’re looking to understand the good practices of making your site stand up to the test of a stylesheet redesign, this is the article to start with. […]
Nice article!
There are one small mistake though. CSS1 doesn’t allow underscores in class/ID names. An errata for CSS2 (published in 2001) allowed underscores.
Underscores in class/ID names do work on all modern and old(ish) browsers, but it’s still wrong :-)
Netscape devedge: Underscores in class and ID names
Great article Mani! Congrats on first ThinkVitamin article.
“This is information that cannot be read by screen readers, nor accessed by handheld devices, nor indexed by search engines.”
That’s not ENTIRELY accurate. Though not all, many screen readers, handheld devices, and search engines can access Flash content and Flash provides ways to provide text descriptions within the file itself.
[…] I’m ridiculously thrilled to announce that my first Vitamin article, Real-world CSS Zen for your site has been published! It is about realizing the standards hype by making semantic layouts your first priority. […]
Terrific article, Mani. Clear, concise, with great examples…thanks!
[…] Here’s an excellent and very articulate article by Vitamin newcomer Mani Sheriar that gives us clear cut examples of coding standards–based html that allows easy site redesign, which is, after all, one of the reasons we code using web standards. Great job, Mani! […]
I would avoid the extraneous span and div tags (how is this better than a tabular layout?) unless the plans for the website include multiple themes or periodic refreshes.
In an ideal world, I like the concept, but in my experience when a client wants to redo/refresh their website, they also refresh and update content which tends to mean starting from scratch.
[…] Vitamin has a feature entitled Real World CSS Zen Garden for Your Site which focuses on a few extra steps to take when marking up semantic xhtml to ensure the most painless redesign in the future. […]
Great article. Re: being semantic, I think it’s fine. I don’t believe a webpage should be whittled to it’s barest semantic bones. I think the goal of semantic markup is to simply make the semantics easily visible/usable. The corollary of which is that the other stuff is easy to ignore. I think you’ve struck a nice balance that achieves both.
Bravo! As someone who designs document-first (at least i have done recently) I really appreciated this article. The perfectionist attitude of lean, mean code is good to a point, but some people seem to actually take the point of using css a bit to far, to the point that they actually make a redesign harder!
PSDs, a style sheet, and you, yep, that’s it.
Personally I don’t think “Increased ease of redesign in the future, since all presentation can be handled in the style sheet” is problematic I think it’s simply not true. Content is part of the presentation as are certain display artefacts through scripting and sometimes restyling or a redesign needs these structures to change. Style sheets mainly focus on style, that is in of itself not presentation.
The point is that when writing within web standards is becomes dramatically easier to make changes. And small changes in the front-end code can result in big changes in the presentation. In other words a big redesign often only requires minor changes in the web standard front-end code.
Any redesign requires a review of all aspects of the front-end and may require changes on all fronts. With this in mind why consider building for things that are unknown. Write for what you need, no more no less.
Pretty good article, thanks for sharing it.
I’ve been employing your approach in recent projects as well…nail down semantics and document structure in your XHTML, and then tackle the CSS.
I get nagging doubts from time to time though when I hear many proponents of web standards argue for more spare and minimalist use of structural tags in the HTML. Some people, for example, might accuse you of “divitis” for wrapping an extra DIV around the UL in your example.
But I think your article lays many of those doubts to rest and nicely illustrates the benefits of using HTML appropriately to apply structure and hooks.
Thanks for the outstanding article!
This is an excellent article. Well done Mani and congratulations on your first ThinkVitamin publication. This is a really valuable approach and I recommend anyone who is into web standards to take it on board. It neatly sums up how we’ve been thinking and working for a while, mainly on the back of a couple of major/minor re-designs/aligns where we’ve either benefited from having included some extra semantic tagging in the first place, or found ourselves wishing we had!
Some people have questioned whether, as redesigns often involve content changes too, this approach is really worth it. I disagree. From both a theoretical and practical perspective, the ability to separate changes to the content from changes to presentation is a good thing. In practical terms, one person can work on content or backend changes while someone else works on transforming the look and feel - even in a fairly small team this is great for efficiency. Even if it’s just one person involved, as Mani says this approach can mean you spend less time on tedious re-coding of your markup, and more time doing meaningful work actually changing the design.
In my experience sites which are built well in the first place, to a clear strategy, rarely need a really radical overhaul. But even when they do our experience has been that even fairly major changes - like the redesign examples Mani gives - can be done almost entirely in the CSS if the basic markup is good enough. With proper templating / SSIs in place any related content changes are then also pretty painless.
In practice of course we often find that the basic markup isn’t up to it - usually because its a few years old and frankly could do with an overhaul anyway. In this case we often want to take the opportunity of the redesign to clean up the markup. This is good too. But if so we’d always try to mend our ways and make the new markup more future-proof.
A couple of other points in reply to some specific comments:
Scott: a few extra divs and spans are vastly preferable to a table layout. A table layout shoehorns a site into at least a basic layout structure (header, + 3 columns, + footer for example). Divs and spans, as presentationally neutral markup, do no such thing. With the right markup of the kind Mani is suggesting, you can turn a 3 col layout into 1 or 2 without changing the HTML at all. See the CSS Zen Garden for proof.
Joshua Porter: While you’re spot on the user experience is the single most factor in a site’s success, this article isn’t saying “do this and your site will be fab”. I don’t think anyone would say that web standards, in and of themselves, are a magic bullet for providing a great user experience. I would argue that they are a valuable tool in implementing richer interfaces, faster downloads, and wider accessibility all of which can contribute to a better user experience, but that’s not what this article is about. Mani is suggesting a particular way of implementing a web standards design, which leads to more efficient site development. This mainly benefits the designer/developer and the client. The designer/developer spends less time on wasteful re-coding and so has more time for other things - like working on the user experience perhaps ;-). The client spends less money paying the developer for wasteful re-coding, meaning they have more to spend on other things - like user experience consultancy ?? ;-)
Finally web standards advocates never forget the power of “it’ll cost less in the long run” when convincing a client this is the way to go. Sadly this is still often a more powerful argument than “the user experience will be better”. Would that things were different…
[…] Vitamin Features » Real-world CSS Zen for your site Imagine… You are charged with implementing a design overhaul for a site you have never worked on before. You have the PSDs in hand as you go to look under the hood of this site. You prepare yourself for the nightmare of someone else’s convoluted code. However, to your astonishment, you find a site that is so well coded with semantic markup, flexible IDs and classes, plenty of hooks, and real content hidden behind any Flash or descriptive images that you do not have to work with the XHTML at all. No dreadful find and replace mishaps. No recoding all the pages from scratch. Just a Zen-Garden-esque experience. PSDs, a style sheet, and you. Tags […]
Cool article! Really like the look of the deluxe digital media site…
Only thing I personally would be cautious of is the hiding actual content (Wording) behind flash files etc.. Now the Search Engines (Well Googlebot anyway) have started to crawl external stylesheets - they might think you are trying to pull a fast one… I would guess its unlikely but just thought its better to be cautious.
All in all, a nice article - jus tone nit. Right after talking about semantic mark-up, you suggest adding ‘Top’ and ‘Bottom’ divs - you may want to update this to ‘header’ and ‘footer’. ;-)
Well done Mani. This is such a great article. Especially to a beginner like me.. Congrats.
This is an excellent article Mani. I’ve never redone a site that allowed me to leave the html in place, but with come practice, I think it could be a real time saver. I’ll definitely be using these techniques in my next site. Thanks for the write-up.
This article stared off great with a nice introduction into web standards and the reasoning behind them. But then the code examples horrified me.
Empty DIVs, unnecessary spans, this is not semantic mark up and is utterly meaningless. I appreciate the fact that it might be nice to include a few lines of code to make a re-work of a site easier, but surely any extra hooks that are required should be added at the time of the rebuild. This is just meaningless mark up.
“..what makes more sense - creating the cleanest, leanest, meanest markup possible…Or letting go of …perfection in order to create a solid foundation.” Jeez, you might as well go back to using tables as your article seems to be taking a huge step backwards in the future development of web sites.
I tend to peg this stuff as YAGNI (you aren’t gonna need it). You’re experience might be different, but I find it a waste of time trying to predict what I might need in the future. Just stick to the simplest thing that could possibly work, and if it needs to get more complicated, extend it later.
But this is made much more workable if you’re using a good templating system where you don’t repeat yourself at all. If you need to add a header div, you just add it to the template. If you need ids in the menu, you just change the menu include file (or DreamWeaver library or whatever).
If you stuck to that principle (don’t repeat yourself), you’d save yourself a lot of time guessing the future, and a lot of time making up for what you failed to guess.
Please forgive the extreme programming buzzwords. They just work too well for me to ignore them.
Vster, I think you are missing the boat here. Divs and spans do not add any semantic weight to the page, and while they may “clutter” the markup, they are invisible to the end user. Having them available as a way to ease the redesign process in the long run is a great way to develop a website, at least until future implementations of CSS take away the need for all that extraneous markup.
It’s a big step up from table layouts, and comparing the two is way way off. Apples and oranges, ripe apples and rotten oranges at that.
Thanks Mani for an interesting article, here’s hoping it’s the first of many! Although I’m not keen on the empty divs suggestion, I completely agree that a bit of forward thinking here and there can pay dividends in the long run.
Thought I’d throw one in: a little trick I like to use of late is putting a “first” and “last” class on list items. Y’know, just in case :)
Well, that certainly got me thinking. Thank you.
Since switching from table layout some years back, I’ve always favoured layout-neutral div names, and avoiding class|div-itis where it didn’t help relay document structure. That said, while I try to work within current standards, I’ve found that following said standards can seem like nailing jelly to a tree. Sites I built 10 years ago were rather conservatively coded according to the standards of the day, and even then somewhat of a nightmare to maintain, more so with passing years. My limited coding skills are based on what I wanted to achieve, first studying, then trying out various methods to accomplish this. A testament that good judgment comes from experience, much of which comes from bad judgment.
I recently had the pleasure(?) of designing a couple of sites which are generated by a content management (CMS), the bowels of which are hidden from the “client-designer / content provider”, and for which said designer / provider has tinkering access only to a generic and aged (2003) style-sheet and a few top-level templates. The style-sheet and top-level templates told which tags to expect and be able to tinker with, and allowed changing the nesting order of some divs. The content is generated by the CMS accessing a database, presumably using object-oriented code in an earlier version of php. (For their samples, see the above address, substitute sample for vidc, and for my first, substitute 2045 for vidc.)
Unable to add encompassing divs and especially spans, getting some kind of display working was the extent to which I felt able to develop a site within these constraints. Later on, some form of progressive enhancement using javascript referenced through the header template could expand possibilities, but that seems likely the only way to add the “future-proofing” we all want though find difficult to achieve. My own crystal ball was sent out to the cleaners years ago and never again seen.
While I’ve built numerous sites from scratch, over the years I’ve come to prefer using a CMS (exploring Drupal now) to automate as much as possible. Am I being naive / obtuse in questioning whether the majority of site developers are working with some sort of CMS, and that much of the extra “hook” coding suggested in the article would be placed, if not in theme(s) for the CMS, right in the most basic methods themselves? It would seem to be a labour-saving way to implement this approach, and prevent content providers from needing to be concerned with it.
Just a thought.
Good approach to CSS/XHTML development and it is a good article for the less experienced. XHTML first is the way to go. It is like sketching things out on pen/paper before diving into Photoshop/Illustrator. You need the blueprints before you build the house.
Also for those saying that CSS + redesigns don’t necessarily go hand in hand… well the basic page structure of nearly all of our client sites are identical — header, footer, sidebar, etc, etc. Build a generic framework then iron out the details. This helps our redesigns, and new site builds, go tons quicker!
Google can index Flash content so this is not entirely true but it is still not an advisable to deploy a whole site in Flash.
I really enjoyed the article. I’m a Front-End Architect for a web firm in Portland. We recently finished a “real world” Zen Garden approach with one of our clients. We took on structure planned out the “hooks” and developed 24 sites in 30 weeks. It was an astonishing feet that couldn’t of been done with a traditional table based layout. You can the project here http://www.popart.com/selectrucks/Default.aspx and a presentation here http://video.google.com/videoplay?docid=-6943155289327149422. Thanks again for the great article!
-ryan
Hi Mani,
I appreciate your article and I think it is a good idea to put the emphasis on a well-structured XHTML template.
I think it is good advice to drop the perfectly semantical solution in favour of a design that is practical for redesign in the future.
Re: superfluous tags
I’m with the purists on this one: i can’t justify having the extra markup in the page just in case i need to use it in the future.
My problem is where do you draw the line?
The first chapter of The Zen of CSS Design mentions things like:-
“there is no one-size-fits-all solution for building a page”
“less markup is better… reducing markup bloat should be a universal goal”
“a large goal of standards-based design is to eliminate unnecessary elements”
For CSS Zen Garden the goal was to have maximum flexibility, which is the justification for having as many hooks as possible; but for a ‘normal’ site i don’t really buy into the benefit - unless that site is expecting a lot of redesigns/skins.
However, i totally agree with semantic markup and the general principals. I always start with semantic structure and then apply the CSS layout on top.
Thanks for the article Mani.
the naming of classes and ids is something I always seem to struggle with. While I do try to keep a naming convention that relates to their structure and not their position, I for some reason find it difficult. I think its from some bad old habbits. really nice article.
“Now I know that one of our favorite pastimes as standards advocates is arguing over extraneous markup and glorifying the leanest, meanest code possible, however it seems to me that sometimes we can take this too far and actually do ourselves a disservice.”
I have found myself thinking along the same vein lately. I have gone to the point with sites where it’s as little HTML as possible and then returned only to add more markup later, whether it be for a facelift or a redesign.
Another really important part to this is to come up with a standard language of CSS one uses on all of their sites. There is nothing worse than going back to a site for a redesign (and I am completely guilty of this) and seeing that all of the content you need to change is in div id=”orangebar” or something similar. While it made sense when you were coding the original, it doesn’t make sense now.
Good article.
I saw a couple of references to CSS Zen-Garden in some of the replies in which the authors where stating that non-semantic, superfluous markup was wrong. I just wanted to point out that the CSS Zen-Garden site provided extra divs in the coding for just such reasons the author of this article stated.
I agree with the idea of using some extraneous markup as long as it is not becoming ridiculous. Later this extra markup can help a lot while realigning the page, though from the other side, such markup could be introduced on a later stage, when the realign has arrived.
As far as for the flexible names, i see it as a big requirement, to use the purpose, but not decoration as a basis for them - exactly the same principle is to apply in programming, no one sane would use a name “left_content” for a variable, but instead using “main_content”, or whatever it is meant to be.
[…] The Business Value of Web Standards Real-world CSS Zen for your site The Business Case for Web Accessibility Google’s “Webmaster Guidelines” Google’s “How can I create a Google-friendly site?” “Vägledningen 24-timmarswebben” […]
It’s amazing how many out there still don’t start with the content and semantic xhtml. I tell my clients: content is king, gimme all the text you have and any photos/graphics you will want.
Organize it.
Make some basic documents.
then make it pretty.
So much is just fluff, unless, and often even if the site is about video, animation, graphics or audio.
While things like Flash do have some hooks that can be used to make it searchable, it still isn’t by nature very searchable.
Even an illustrator file has xml built into it, but that doesn’t make it human readable markup.
Same with SVG (if it ever takes off for real…)
[…] There was an article written by Mani Sheriar over on ThinkVitamin earlier this year about real world css zen. I am going to take what I know and apply it to the zen garden methods described in Mani’s post. […]
[…] Real-world CSS Zen for your site Filed under: Web Dev @ 8:15 pm […]
[…] Mani Sheriar has written an interesting post on the Vitamin website about her experiences with XHTML and CSS web design. […]
[…] Inside Google Book Search wrote an interesting post today onHere’s a quick excerptIf we can do it that way, then we will be able to execute minor or even major design overhauls without touching a single page in the site. And what’s more, any other developer will be able to do the same. … […]
This is an great article, Mani!
CSS Zen-Garden makes me alway think that I still have very much to learn…
Very nice article! - Zen Garden is the first place to look for some cool ideas…
I think the goal of semantic markup is to simply make the semantics easily visible/usable
The CSS thing is growing and i think it has future. A semantic markup will be required in the future
Hi there , just found your pleasent web site, kind regards from germany
Thanks for the information - A great article, very useful website. I never before thought on the many different aspects of CSS.
Best regards from Germany
Hi there, I found great ideas on your Web site, thanks for that and keep on doing
A great contribution to the world of web standards summarizing up why certain people in today’s web design community still endeavour building up the most complicated web platforms and or design works with the least number of structural flaws (like xhtml errors) while they had considerable chances to catch up stil a similar “look” only by exerting the one-thirds to one-tenths of their original efforts. Those so-called ‘ the standards evangelists’ do know enjoy a favorable position in pain-lovers world. But at the end the yield is good and worthy of the effort spent: No Pain - then there is No Gain!
erreta
Those so-called ‘ the standards evangelists’ do know not enjoy a favorable position in pain-lovers world
excuese me for the mistakes which ain’t no unusual to make, but definetely a shame AND DISGRACE to the readers if left indifferently :)
Thank you very much for your really interesting internetsite - good navigation and easy to find all information with a few clicks.
best grretings - Chris
Hey man, excellent site you’ve got there, by the way. I dig it!
Thanks a lot, this was an amazing article, for me CSS i quite a pain in the a**
I like this site and the good navigation. all the informations are easy to find. thank you very much. Greetings chris
Great article, always loved the zen garden.
International Song & Lyrics Archive - http://www.songstime.com
allowed in your comments. Please be respectful and keep your comments on-topic. If we think you’re being offensive for no reason, we’ll delete your comment
and keep your comments
A great contribution to the world of web standards summarizing up why certain people in today’s web design community still endeavour building up the most complicated web platforms and or design works with the least number of structural flaws (like xhtml errors) while they had considerable chances to catch up stil a similar “look” only by exerting the one-thirds to one-tenths of their original efforts. Those so-called ‘ the standards evangelists’ do know enjoy a favorable position in pain-lovers world. But at the end the yield is good and worthy of the effort spent: No Pain - then there is No Gain! this is good idea
like this site and the good navigation. all the informations are easy to find. thank you very much. Greetings chriss
thanks a lot for this topic
yes but getting access key is very very hard
thank you ..
Alevi, Alevilik - http://www.kizilbasforum.com
Yarence Dergisi, Siyasi Dergi - http://www.yarence.org
Thanks.
Thanks! I wish you a wonderful Christmas and a New Year!
thankss good y-bye
after unregistering albumart3d.dll, all the other visualisations work in MCE?
thankss
thank you .
Very nice article! Thanks for this!
good article, thanx