<< Back Home
CSS Essays : We All Underestimate Style Sheet and Front-End Code
or "The Future of the Web Tomorrow Is About Respecting Style Designers and Building on Good Style Sheet Skills Today"
Back in the fall of 2000, I was finishing up a multimedia certificate and transitioning from artist to web designer. I quickly landed a job and became a member of a good-sized web design team. It was the last era of the Dot Com Years and we were full of projects and venture capital funded work. Designers were taking 3 hour lunches and playing UnReal on the company network between projects. Sales guys were riding scooters up and down the hall, and it was a happy, free and fun period in history. I will never forget it. (I will be writing a long article on my experiences later). Anyway, it didnt take long before the projects and the money started drying up and by that Christmas, we were all laid off, but a few straglers. I went back to school and started retraining.
To make a long story short, this little company somehow lost its last members, and I got a call form the CEO and was hired back. I was one of the lucky ones, you might say. During the long deathly quiet years of slow business and few projects and the recession, I somehow clung to my job and watched the last developer and manager let go. It was hard, but I kept our little web department (which was just myself) profitable and functioning and did all the jobs that others used to do, including company and client sites, some development, marketing, print, and client relations. During that time I did quite a few sites and some very large ones. But I remember that back on the summer of 2001, after my rehire, I began to look over the code in a site I was working on, and thinking about CSS and XHTML. This was way before the current movement had jelled. I remember going home at night and trying to create a simple rollover CSS button. After some frustration with Netscape 4 and IE5, I think I realized the difficulty in trying to do this for client projects in a cross-browser fashion, especially as the browsers had not yet matured and we were under very rigid budgets. I also remember playing around with XHTML in Netscape 6 and IE and seeing some serious flaws. So after some testing I abandoned the whole idea, waiting for the day when browser support would be more complete. It was frustrating and I was alone in the woods at that time. Again, back then, the reality of limited budgets and using a technology that was not fully supported weighed heavily on me, especially since I was then the person responsible for web projects that HAD to work or else (and work well, I might add). Being an expert at tables and spacers, I returned to my original concepts and the next few years built on the success of cross-browser table-based layouts. As we climbed back from the brink of DOT BOMB obscurity, and hired new people, I trained them on my reliable design concepts using HTML and we saw lots of success.
But I like to look back to that lonely quiet summer of 2001, before 911, before the success today, before the new guys came in, and before this new CSS movement we are all now experiencing and wonder....what could have been? What could have happened if I had spent a couple more frustrating weeks alone in those dark corporate offices or my den at home trying to get that XHTML working? I like to think I tried, but it wasnt good enough to start that movement....not back then with those browsers. I guess I also suffered from what most people suffer from today. I just didnt respect or understand the importance and power of style sheets and XHTML and what it all meant for me as a designer. Front-end code was just one facet of my responsibilities, so I did what I had to do to get the job done (at the expense of standards). Thats what we all do, I guess. Things are supposed to be changing though today, with the newer browsers, so I've finally made the move to XHTML and CSS. But is our work or respect for the technology really any better?
As hard as style sheet design and structure is when building websites, allot of people today are throwing themselves into it, and coming up with solutions. They are not very pretty ones, from the sites I've seen, but some very good attempts. There are a very small minority of sites where the style designer has reached a certain level of "enlightenment", in that the web designer has not only designed a pretty site, but the styles work in ALL THE BROWSERS, or at least seem to have been designed with sensitivity for browsers other than Internet Explorer 6 and Mozilla and Opera. Regardless, most of you guys are "hacking" things as best you can, coming up with sites that "kind of" work, yet fail on some areas, but seem to be happy with making them "good enough' for your clients.
Ok, so we are not all perfectionists, as programmers. That's ok, but lets all make a general observation about web designers using style sheets today: Seems like "everyone and their grandmother" can design web pages using style sheets these days, if you include all the good to really bad designs. This includes people that use website design software, like Dreamweaver to help them do styles and layout, or .NET Visual Studio, or Frontpage (really bad!), or Page Mill, etc. It also includes people who cut and paste other people's code, people in school learning HTML and styles (which is really almost completely deprecated now with XHTML), and allot of Windows programmers who assume they can do styles when they too are doing bad style layout, and designing the software we use to do styles incorrectly and in an "unstandardized" fashion (i.e. Visual Studio).
SO, if everyone who builds style sheets claims to be building decent sites, when we obviously have a very large majority using bad style tactics, layouts, and designs, which are not as standardized, cross-browser, and accessible, as they could be, not to mention usable, pretty, and based on "standards", then we really do have a messy internet, don't we? You agree? Is there anyone out there that gets frustrated when you go to a big corporate site and you cannot resize the fonts? Is there anyone using Internet Explorer 5 (average about 10% of users world-wide based on our server stats) who sees structural design problems in sites? Has anyone with a screen reader gotten frustrated by the fact that a websites with images has no alt tags, or no "skip to content" button, or navigation menus which are non-listed link sets?
My point is that we all (myself included at times) seem to take "front-end" design for granted and obviously styles sheets in the various browsers for granted, and despite what we think we have created using styles, most of us are designing really poor style sheets and real website messes. Why? The reason is because, like any facet of web design, we assume its easy stuff. Being a Windows PC user, that's doubly true! We also assume if it looks good in one or two browsers, we are done. Not so! Why? Because its about DESIGNING FOR ALL VIEWERS, and GOOD STYLE SHEET ARCHITECTURE, and using good WEB STANDARD PRACTICES, and about ACCESSIBILITY GUIDELINE IMPLEMENTATIONS. These ideas or concepts mean many things to many different types of people. But for the most part, they should mean coding sites that are as thoroughly tested in as many browsers possible, designed by trained and experienced style sheet designers, are as readable and usable as possible, and whose content is as accessible as possible, for the target audience. But also, it's about designing for the widest possible audience. My point being, that most of us are not taking style sheets and web design as seriously as we should, and when you really test and review most style code, it generally falls far short of what it could and should be. I know the coders I have worked with, often assume it's about "making something look pretty". But it's actually the opposite. It's about taking something that's supposed to look pretty already and organizing it better so that content is manageable, repurposed, markup is minimized, and structures are better organized for multiple device access. It's not about looks, as much as it's about good code that managed. It's about repurposing content for multiple devices. And it's about less server work by greatly reducing the number of raw kilobits shipped out from the server. Most developers and programmers I know miss this point entirely.
Web designers are also guilty of poor assumptions that hurt websites designs later, as they continue to implement poor style code and site architecture and structures. Designers will also claim "the client is always right even if they want sites that are unusable or break standard practices" - another bad mistake designers make. Yea, I've run my business and I do understand what it means to say the customer is always right (and so get paid). But what kind of designer would I be if I passively accepted what all my clients wanted without challenging and encouraging and educating them to better practices. You must agree, you cannot expect your clients to have the knowledge you have, so why would you let them destroy their sites? If I needed plumbing work done in my house would I want to deal with a plumber that did what i told him? Or would I respect a contractor more who shows me a better way - shows me a way his years of experience have taught him save lots of trouble later. Sorry, the "customer is not always right, folks"!
So, why do all of us continue to miss the boat on respecting and growing our style sheet skills and respecting those that have developed them correctly? Why do we all keep slapping up quick and dirty style sheet solutions in our projects, or using Visual Studio or Dreamweaver to build such poor and ugly style sheet systems, rather than seeing hand-coded and carefully developed style sheet structures as THE MOST IMPORTANT COMPONENT OF ANY WEB SITE, PERIOD?
Why? Because most coders assume what's working on Windows and in the nice "comfy" world of Microsoft and PCS's translates to the web and if Microsoft does it one way for their browser (using proprietary "junk code"), its probably ok for the rest of the world online. Nothing could be farther from the truth. Microsoft does not own the web. They may run your code correctly as long as you are inside your Windows environment (that 97% or you out there that are), but on the web, it's a diverse and increasingly diverse world with many players, OS's and devices. Internet Explorer for PC is also slipping in market share month to month to Mozilla and open-source agents. As well, as much as two thirds of servers world wide are not IIs or Windows based, but are UNIX-based and Linux systems. This translates to the following: If you are a Windows Programmer or developer, you have been very spoiled and can generally count on a very easy development cycle for Windows Programs, as most of the world is Windows, and most Windows OS's give you great tools to help you build for those systems.
But on the internet, it's the opposite. Most of what is used to view the web, run the web, and interact with the web is NOT about Windows or ASP COM objects or XML or built-in .NET OOP programming models. Client-side is also not about slapping some Javascript up to run a circus trick for your viewer because you didn't take the time to find an easier more useable XHTML and CSS solution. This comes down to the fact that server-side work and scripting does not translate to client-side usage or usability, and thanks to Internet Explorer and Microsoft, the web is still a very diverse audience you have figure out how best to code for by hand, using your skills, sensitivity, and brains! You may say, "Hey, not true. Internet Explorer for PC is still the dominant browsers, period, and why should I fret over all these other people!" True, for now.....but that's changing. And only applies to desktop browsers, not all the new mobile devices beginning to flood the market. Plus, IE is starting to lose the browser war again. So, just because something "looks pretty" in Internet Explorer does not mean you are designing good code. These days, it actually means the opposite. Why? Because Microsoft is one of the few companies today whose products do not follow Web Standards. Many developers and designers have experienced what was essentially a browser war in 1999, that resulted in browser manufacturers (primarily Internet Explorer and Netscape) fighting to get market share by separating themselves from each other by adding proprietary features, rather than making CSS and standards compliance as handed down by the W3C, a priority. Now that's changing, and Mozilla is ahead of the game. Will Microsoft catch up? Yes, I would bet the house that IE 7, when or in whatever form it takes, will do that. Will it also have those nasty little Microsoft proprietary attributes and components....yea, and I expect with Longhorn, it will be radically different. But here is the thing.....the web still goes on like a river, and will still have new devices, will still have Standardized browsers that cannot use Microsoft "extensions" to their browsers, and the mobile market will continue to deepen and enrich our coding standards by requiring more sensitivity and intelligent and educated use of style sheet and XHTML coding structures. Those programmers who buy into the Microsoft "schema" and architecture will certainly do well within Windows and Windows-based systems. But the browser world and World Wide Web ain't stopping for Microsoft. Its a mighty river that will keep flowing, and those that code that's open-source and inclusive of everyone will be the big winners!
How to Do Style Sheets Correctly
Now, on an educational note...
This article is also about how to design good architecture for your websites so that they will work well and help you design really large enterprise level projects in the future. It's my belief that the fundamental power and importance with Style Sheet work today, is that its taken for granted on many levels by management teams who attempt to undercut design teams. In fact, styles, especially when combined with other technologies, like xml, XLST, server-side scripting, and even traditional web design tools and website imagery, have the power to completely "run and control" future web projects entirely. Powerful concepts, folks! Don't take for granted XHTML, XML, CSS, and Web Standards. The future looks very powerful indeed for people who figure out how to take CSS seriously and design good CSS structures and systems for their websites. With some of the stuff we will see in the future, events and navigation and buttons, and even dynamic content will be pushed into style sheet features, such that server side work will become more focused on data manipulation, state, and xml returns. XSLT will and does work today to assist in bringing even more power to front-end code and preparing styled content for delivery. And your ability to design your own "schema" and xhtml tags and control them with style sheets will mean coders for web projects will be more and more valuable, especially those that respect and understand the importance and complexity of fully understanding Web Standards and good CSS system design.
The failure of many early adopters today to stress good style sheet design and architecture means many people are carrying the old torch for HTML and presentational markup, in that styles are all about presentation, and the venue of the designer, when in fact, styles are about website architecture, layout, content control, and delivery. What does all this mean? It means we all need to clean house and start thinking about all the facets of style architecture, xml, xhtml, and the server and how to best combine style systems so that we can deliver all the different web applications coming our way the next 50 years. Those of you using styles as a simple style sheet with some layout and font sizes are going the right path, but I say, is not truly thinking about how to architect good style systems for the future complexity coming our way. If you and I don't start thinking about web design in terms of information rather than warm and fuzzy look and feel, we will leave the future complexity up to people like Microsoft to build styles for us, and lose the power to design our own systems and designing for ALL BROWSERS AND ALL USERS AND ALL DEVICES. So what am I recommending in this article?
I am recommending that you first think about what it means to use style sheets, with no tables, in your layouts. Start by looking at a simple HTML page and then an XHTML web page with markup and free of presentation. Think hard about which websites and which parts of websites may need different kinds of layout structures or versions of structures. For example, If you were responsible for a truly monstrous website redesign like EBay, how would you approach that? Surely you wouldn't build a single style sheet with a bunch of layout and font styles, and say you are done! You would think about the project as a whole, and a series of style pages for the site itself each of which manage various parts. You would think about the
structural aspects of cascading style sheet systems. (When I say "structure" or "architecture", I'm not JUST talking about layout or markup structures. I'm also talking about how style sheets themselves are organized, and possibly metadata systems or databases to control style pages attached to various sections of sites. I'm talking about taking style solutions seriously, folks!). Then you might design some alternate layouts for times where you may want to switch layouts. You might have a series of styles for the basic tags, like paragraphs or basic links, and then an advanced sheet for classes that style versions of those tags (i.e. some page links may be red, others blue, others bold, etc.). What about menu or navigation systems. You might have 2 or 3 different menu sets tied to separate menu-based style sheet systems. Then we have things like footers, and headers. You might want a style system to manage headers, and then for managing advertising sections of the header. This would allow you to possibly use dynamic 'display: none' features added to advertisements to turn them on and off using styles rather than costly cookies or Javascripted solutions. Footers might seem simple, but you might have footers for the main site, one for secure areas of the site, another for co-branding the site, etc. etc. We haven't even touched on a series of print style sheets, where you hide some areas of the main site and express content areas in a more print friendly way using point units for fonts. If you have various versions of the layout, you will need various versions of those in print. Then there is mobile devices, where its important to have multiple XHTML-basic coded pages or XSLT or style sheets to manage those parts of sites viewable in micro-browsers and PDA's. What about web content management systems? I just finished a project where I migrated my content management system from HTNL to XHTML and CSS. Now I can completely manage the delivery and look-and-feel of each CMS for each site. It takes a very organized and robust structural approach to put all these pieces together.
And my whole point is to show you that as we begin to think about the architecture of websites, and as the web itself matures and widens its breadth and reach across all kinds of demographics of users and media, that styles will also need to widen, in "managing" the site. Again, it is not just look and feel and "making text look pretty", but really managing the site's content, its content architecture, and many kinds of functionality pieces, like print. If you take even the smallest site design you are building today, and plan or pretend that it will possibly become an EBay or enterprise level project someday, then you will be a part of the new
in website style design and architecture, and now thinking in larger terms about how to architect your personal style sheet systems for all kinds of future releases tied to that site and its management.
My Recommendation
First, here are some general recommendations I am giving you to follow in designing powerful web applications using XHTML and Cascading Style Sheets:
- Learn style sheets, XHTML, XML, and XSLT. I would say learn Javascript and the DOM second. It will take time but as you practice using styles and these technologies, you will gain much skill.
- Don't let other designers, programmers, managers, and clients try and devalue, minimize, distort or reduce the important of style sheet design, Web Standards, Accessibility design, testing, usability, and good and validated XHTML markup. Allot of developers continue to assume HTML = CSS = 'pretty sites' = 'not as important as the database and server-side code' in the project. Guess what...I'm a .NET and ASP hard core developer, too, and have built information management systems for sites, and I consider a good style sheet rule MUCH MORE IMPORTANT than a .NET server control or control loop or SQL Server query. Not that server-side development is important, but style sheets and good web design and usability are FAR MORE IMPORTANT to the success of a project. Designers should be paid well!
- Don't let Microsoft or Macromedia convince you that their software will take care of style and dynamic code for you! I've read allot of websites that constantly develop cool components to .NET or Dreamweaver that continue to make the erroneous claim that those tools make web design and development easier. As far as development, yea, you can't do much without Visual Studio as far as ASP.NET goes. But that's it! I use Notepad for everything else, and guess what, I'm designing styles and web layouts without all the "junk" and messy code that Visual Studio and Dreamweaver creates. This also goes for style tools, like TopStyle, which I love, but never use. Why? Because its a great "reference tool", but for meaningful design, TRUST YOUR OWN CODE ONLY! (If you remmeber anything about me online, take that one critical piece of wisdom!) Learn to hand-code and you will go far! Why? Because the browsers will NEVER USE STYLES AND MARKUP THE EXACT SAME WAY, so any software tool that tries to fix that for you, will only ever get it partially right. Plus, the code they build for you will only add in junk that you have no clue about, and when the site breaks in a browser, because you did not code it yourself, guess what, YOU WILL HAVE NO CLUE HOW TO FIX IT! And what's worse, programs like Visual Studio that claim to "help you fix code the right way" often will rewrite your code the WRONG WAY, unless you carefully read the software documentation and rebuild the preferences carefully in each one to fix that. Talk about a brain teaser! Can you imagine having to not only worry and review all the code these GUI's add into your carefully laid out markup up, but then trying to remember software versions, what they support, then trying to configure all your team's computer's with those settings and then your clients, if they work on a site? What a HUGE MESS the web software world is! Don't make all that hard on yourself....learn to use Notepad or any simple text editor and type in the raw text yourself. What do you gain? You don't pay for expensive software, you learn how to do styles, you design sites that work on ALL THE BROWSERS, you know how to fix something and where to look when or if it breaks, and most importantly, you code the RIGHT WAY. Sorry, but there is no software program that can consistently get all the Web Standards right then figure out how to "best" do that for each browser and agent out there. So, trust you hands and brains, not that of a manufacturer!
- Go to the w3c.org and read as much as you can. These guys are read by the software manufacturers and this org sets the standards you and I will all someday have to follow.
- Now for the most important advice: Build your own style sheet for a website and experiment. That's right, play around and learn. It's the only way. No book, software, or online web log can take you all the way with good coding practices. You have to play with the code in a sample web page or site and see what you get! That's it! Once you start doing those things, you will learn more and do better design than any other method
- Finally, separate your style sheets into functions or features they control and start building an architecture of style sheets that you can cut and paste as a template in all your projects. Build a menu sheet, a structural sheet, a print sheet, a mobile sheet, and an RSS news feed sheet. I will be articulating this in greater detail in future articles, as there are lots of details involved.
*Note: The purpose of this article is simply to articulate the core concepts so you dont get sidetracked into creating poor style structures and start respecting the style sheet as a powerful and increasingly critical web application element. So follow the list above as a central philosophy and you will go far, my friend. Ten and twenty years from now when the Internet is this gigantic even more diverse multi-verse entity infused with style structures and built on XML and CSS, you will thank me! All those stuck in the world of Microsoft browsers and software development tools, GUI's, antiquated HTML, undervalued CSS design teams, mismanaged web development organization, and proprietary code will have to retrain, big-time! You will have an edge in the world of web application design and development! :o)
Final Word on Style Systems
Ok, so now you are doing all the above and respecting and empowering all your projects with powerful XHTML markup and css, and following some good Web Standard practices. You are now saying, "Mitch, show me the beef! Tell me something I dont already know! Give me all the dirty little details already!"
Ok, in ending this article, here is a style organizational strategy I recommend, and it's what I am doing myself. Don't just design one or two style sheets for any website, stuck in the root folder of your site. Thats for sad little "simpleton" sites, as were done in 1999. Go one step futher and build a "styles" folder on your OS and server, and have a central repository for all the style sheets that will be used for that site. Use a system like this that you are familiar with, that's named intuitively, and that any other developer can understand quickly and use. Having all styles for each website project within a website subdirectory, or sub section of a site, will allow you to begin centralizing, yet consistently implementing the same structure on all your web projects on a physical file level which translates to a logical level later. If you inherit someone else's project, it can be a mess to sort out large style sheet layers. But, getting organized with more enterprise-level strategies, anyone that inherits yours project will appreciate you and your intuitive and highly organized and consistent site plans. After you have established a central repository for styles and managed code, or have built a folder for your style sheets, go ahead and do the same for other items in your site that are separate from the style sheets. This makes sure you don't mix non-styles items in with styles. Most people create an "images" folder, a "script" folder for Javascript, an "include" folder for templates and server-side includes that contain and hold the pieces of the website. I also build a "media" folder with subfolders for Flash, PowerPoint, Acrobat files, and video, so its all tracked and can be erased or moved from the server if needed. The 'images' folder will also have sub folders for classes of images, like user photos, or icons, etc. By coming up with a simple, consistent and intuitively named folder structures, as dumb and obvious as that sounds, means you are preparing not only your projects for faster better performance and maintenance, but fellow designers now have the ability to quickly dive into each others work and very efficiently locate and change managed code and files. That adds up to savings of thousands of hours or development time across dozens of managed code projects, and millions of cells of gray matter in our brains are saved the stress and strain of "relearning" code and site organizations when trying to make changes to sites, or in reorganizing sites. This follows one of the reasons for moving to XHTML, which is separation of one type of object or concept from another. This just makes things much easier and as projects explode in size, amounts to hours and hours and thousands of dollars in cost savings when groups of developers have to come in and update, edit or manage things in your projects. Just remember, organization is key, and that should appear in EVERY aspect of your code and project design, not just with high level stuff like data or code logic. It's really important in something as simple as file structures.
Let's go back to the styles folder. I just create "types" of style appropriate for older and newer browsers, which are also tied into functionality, like structural and navigational sheets, etc. I also put subfolders inside my 'styles' folder and this allows me to control site repurposing sheets like print, aural sheets, mobile sheets, and RSS, if needed. Again, by electing to create a logical and physical location for all the pieces of your site, you are preparing any single web application to be both "self-contained", easily drag and drop (as on most typical Microsoft operating systems and servers), and modular such that you can copy and paste the exact same folder of items quickly into other projects, instead of digging around on a server for all the pieces. The centralization factor also makes it easy to find and update styles in your project as well, and extend them and enrich them as needed using one central location. Building the "styles" folder with sub-folders for various types of style structures follows this general plan as well, and so gets you organized for building an simplifying truly enterprise-level web applications completely build and controlled by XHTML and CSS.
As a side note, I also use includes, and usercontrols (.NET) as well as markuporganization to futher control and organize things, and will be diving into XSLT to integrate all this using that new language later. More on that later...
Again, because this article is just about style structure philosophy and avoiding the devaluation of front-end styled web page development, so I'll save the dirty details of what I'm describing for a future article. Just stay firm in your desire to build good style structures, architectures, and with Web Standards and Accessibility needs in mind, and don't let the "old-school" HTML designers, programmers and clients side-track you from building powerful sites controlled by CSS, done the right way. Rush that process or underestimate it and you remain in the Dark Ages of web application development. In the future, I believe the important of good style and front-end coding will be huge, as the web diversifies and demands continual content repurposing for all kinds of agents and users. As the future arrives, your careful and prioritized use of front-end technologies like cascading style sheets will make you a valued asset in your company and for the millions of users who thank you for thinking about them.
- Mitchell Stokely, USA
