When it comes to web-design, I am horrible at producing anything remotely good looking. Thankfully there are a lot of free sources for design templates. However, a problem with these designs is that they just cover a single page, and not many use cases. If you take a look at CSS Zen Gardens, they have 1 single HTML file, and can radically style it differently by just changing the CSS file.
Now I am wondering if there is a standard HTML layout (tags and ids), that covers alot of use cases, and can be generically themed with different CSS files like Zen Garden. What I am imagining is a set of rules off how you write your html, and what boxes, lists, menus and styles you are supposed to use. A set of standard test pages covering the various uses can be created, and a new CSS file while have to support all the different pages in a nice view.
Is there any projects that covers anything similar to what I am describing?
Check out the Grids framework from YUI. Particularly awesome is the Grid Builder. Also, they have a set of reset, base, and font CSS files that will give you a good baseline to build on.
I generally just try to follow the guidelines set by the HTML standard itself.
Headings go in "h" tags (so one H1 tag for the main heading, then one or more H2 tags under that etc).
Free text gets grouped in paragraphs in P tags.
Logically-grouped sections of information go in DIV tags.
Any kind of list (even menus that you eventually might want horizontally laid out) belong in list tags like UL, OL or DL.
Tables of information go in TABLE tags. DON'T use table tags for layout.
Be smart with your ID and CLASS attributes. Keep IDs unique and assign them to elements that you know represent something unique on the page, like a navigation menu or a page footer. Assign the same class to elements that are repeated but similar (which you might want to render with a similar visual style).
I always start with a very plain, vertical page - just run everything I want down the page in black and white. Then I start adding CSS to make sure the bits are formatted and laid out the way I want.
Take a look at the source of my home page for an example of what I'm talking about.
I've used Bluprint CSS, it's easy and useful as you'll see. It also has some ruby scripts that allow you to change the number of columns and the distance between them. By default it's 950px for a span-24 element.
BluePrintCSS was, from what I know, the first CSS framework.
As YUI CSS Framework, It's help you to handle layout.
That kind of framework will help you to build multiple CSS for your site.
BluePrintCSS is a quite mature project so I encourage you to check it out.
Related
Looking at the CSS Zen Garden, I can see how powerful and convenient it is to separate design and content. The possibilities seem nearly endless. One can change the style sheet and the appearance of the whole site can be drastically altered.
Let's say I'm putting together the HTML part of a website. How do I know where to put divs, where to nest them, etc?
For example, let's say I want to centre something on the screen: I would generally nest 3 divs together: one display:table, one display:table-cell, and one margin-left:auto;margin-right;auto which would have the content.
Let's say I'm just doing the HTML content, but am not thinking about the design at this stage. How would I know that I need to nest together 3 divs if I don't necessarily know I will centre it on the screen?
Or if I have one design now with HTML/CSS and I have my divs and spans all set out, what happens in 18 months if I decide to change the CSS for a completely new layout? Sometimes I will have extra divs and sometimes I won't have enough.
Presumably it would always be better to have more levels than not enough. That way, the worst thing that can happen is that you have a few superfluous divs which aren't styled and have no visible effect.
Is this generally a problem others have? I know CSS Zen Garden is a special case, but would you generally change the HTML code considerably when you change the corresponding CSS?
I've worked in web development for many years, and over here in Reality things are a bit different from Theory: There is no such thing as separation of content and presentation. You'll always end up sliding in additional divs.
You better follow the YAGNI principle. Don't worry about your CSS as you're writing your HTML. Come back later and do the neccessary adjustments.
As for Zen Garden, you'll find a comment in the source code:
This xhtml document is marked up to provide the designer with the maximum possible flexibility. There are more classes and extraneous tags than needed, and in a real world situation, it's more likely that it would be much leaner.
Theoretically, in order to change the style, you wouldn't have to touch the data (HTML). In practice, there are those problems you mentioned.
What I would do is a more-or-less sensible usage of divs (so for example, anything I think that I might want to move around, or any bunch of HTML that I would want to refer to together - would go in a div of its own). Otherwise, don't use too many divs, for reasons such as readability, maintainability, and size of HTML.
Then, whenever you want to change the style, make the minimal addition of divs so that you'll be able to do what you want.
This is a genuine problem with CSS and it was recognised by the authors of CSS3. The most recent published draft (2003) of the CSS Generated and Replaced Content module discusses a pseudo element called ::outside which would have solved the problem you describe. It would, when implemented, for
<div class="mycontent">Some text</div>
have allowed you to write:
div.mycontent { margin-left:auto;margin-right:auto; }
div.mycontent::outside { display:table-cell; }
div.mycontent::outside(2) { display:table; }
Unfortunately, the ::outside pseudo-element never made it into the CSS3 selectors spec, and the next draft (2011) of the CSS Generated and Replaced Content module will not mention the ::outside pseudo-element.
So we're stuck with putting wrapper divs everywhere just in case which as you note, does not allow proper separation of presentation and content, and remains a deeply unsatisfactory situation.
It all depends on how your website is driven. If you are using template files, the amount of updates will be minimal.
You do not want to overload your code with superfluous Divs because a) load time (althought it will be minimal difference in theory) and b) because it will create a lot of confusion when others edit your files.
From your example, it looks like you may be used to table style layouts. Using Divs to contain your layout will make flexibility very easy.
I am currently in a 5-7 large development team creating a really large website with lots of pages and features.
I feel like we are in such a situation where a developer can change the style sheet to suit his own needs, but is unaware of the 1000 places where it probably change it for something else. I cannot blame him either, since I know it's hard to check everything.
It's a total mess.
I know that using one single style sheet file saves bandwidth and prevents duplicated code and maintenance, but I cant help wondering - is using style sheets a good idea for big sites, or should it be more object/element oriented.
Let's say you forget about the crazy large CSS and you define the CSS on each element instead. So each time you render a GreenBuyButton, it has the "style='bla bla bla'" on it. And this is pretty much done for all elements.
This will increase the bandwidth, but it will not create duplicated code.
Could this be a good idea or how does really large teams work on a single website do with CSS to avoid it being a mess?
Why don't you create multiple CSS sheets depending on the area of the site?
blog.css
accounts.css
shopping.css
Then you could have a serverside script (say PHP) combine all CSS into 1 sheet which will get you the same result of 1 small file (could use a minimizer as well).
Check your overall site with a CSS checker to find duplicates (css defined) and manage it that way.
Otherwise communication is key between your team, who develops what, and so people don't duplicate CSS definitions. A master CSS keeper would be best suited to manage the CSS styles, besides your team should have an agreed upon style and not go rouge creating their own unique styles.
My recommendation would be to use the CSS rules on specifity to help you. For each CSS that is not global, put an activate selector on, for example
.user-list .p {
font-size: 11pt
}
.login-screen .p {
font-size: 12pt
}
This will make it easy to identify what rules are for which pages, and which rules are global. That way developers can stick to their own set of styles, and no mess up anyone else's.
Change how you write CSS.
Instead fo treating every area of the website like a specific piece of markup that needs styling, start defining broad classes.
Enforce some rules. Like, "All <ul> have a specific look for this project." If there are multiple ways you want to style an element, start using classes. This will keep your website looking uniform throughout. Uniformity reduces broken layout.
Create building block classes like a "framework" of sorts. This has helped me so often that I never start a project without doing this first. Take a look at the jquery-ui themeroller framework to give you the idea. Here's an example:
.icon { display:block;width:16px;height:16px;}
.icon-green { background:url(/green.png);}
.icon-blue { background:url(/blue.png);}
Then on the elements:
<span class="icon icon-green"></span>
<span class="icon icon-blue"></span>
Breaking your styles up into their building blocks like this and using multiple classes on the element will keep your team members from having to change styles to suit their needs. If a particular styling quirk is not available they can define a new set of classes.
UPDATE:
Here is an example of how I used this method: Movingcost.com. Huge website, multiple different sections and pages, and only 252 lines of uncompressed css. Actually, these days I break things down further than I did on the movingcost project. I probably would have gone through those elements at the bottom of the stylesheet and figured out how to combine some of those into classes.
Multiple CSS files and combine in code
While doing development I found out that doing it the following way seems to be reasonable and well suited to development teams:
Don't put any styling into HTML. Maintainability as well as lots of head scratching why certain things don't display as expected will be really bad.
Have one (or few of them) global CSS that defines styles for global parts. Usually defines everything in template/master. Can be bound to master page or to generic controls used on majority of pages.
Have per-page/per-control CSS files when they are actually needed. Most of the pages won't need them, but developers can write them
Have these files well structured in folders
use naming and formatting guidelines so everyone will be able to write/read code
Write server side code taht will combine multiple CSS files into a single one to save bandwith.
You can as well automate some other tasks like auto adding per-page CSS files if they're named the same as pages themselves.
Doing it this way will make it easier to develop, since single CSS files will be easier to handle due to less content and you will have less code merging conflicts, because users will be working on separate functionality most of the time.
But there's not feasible way of automating CSS unit tests that would make sure that changing an existing CSS setting won't break other parts of your site.
My favorite override trick is to assign the id attribute on the <body> of each page. It's an easy way to make page specific changes without breaking out a separate stylesheet file.
You could have the following html
<body id="home">
<h1>Home</h1>
</body>
<body id="about">
<h1>About</h1>
</body>
And use the following css overrides
h1 {color: black}
#about h1 {color: green}
The home page gets the default css while the about gets overridden.
Using style sheets on large sites is an excellent idea. However, it only really works when you apply your team standards to the style. It makes sense to have a singular template controller that links your style sheet(s). It also makes sense to appoint someone on the team as "keeper of the style" who all changes to the style sheet should go through before making substantive changes.
Once the style standards are agreed upon and defined, then all of the controls in the site should implement the styles defined. This allows developers to get out of the business of coding to style and simply coding to the standard. Inputs are inputs, paragraphs are paragraphs, and floating divs are a headache.
The key is standardization within the team and compliance by all of the developers. I currently lead a team site that has upwards of 30 style sheets to control everything for layout, fonts, data display, popups, menu and custom controls. We do not have any of these issues because the developers very rarely need to edit the style sheet directly because the standards are clearly designed and published.
The answer is in the name. The reason it's called cascading style sheets is because multiple can be combined and there are decent rules defined on which one takes preference.
First of all, doing all your styling inline is a ridiculous idea. Not only will it waste bandwidth like nothing else, it will also result in inconsistency. Think about it for a while: why would changing a line of css 'break' another page? That indicates your css selectors are poorly chosen.
Here are my suggestions:
use one css file for the basic site look. This css file is written by people doing mainly design, and as a result the site has a consistent look. It defines the basic colors, layout and such.
use another css file per 'section'. For instance, a 'shopping' section will use components that are nowhere else on the site. Use that to define section-specific stuff
put page-specific styling directly in the page (in the header). If this section becomes too big, you're doing something wrong
put exceptional styling directly on the components. If you're doing the same thing three times, abstract it out and use a class instead.
choose your classes wisely and use the semantics for naming. 'selectedSalesItem' is good 'greenBold' is bad
if a developer changes a stylerule and it breaks the rest of the site, why did he need to change it? Either it's an exceptional thing for what he's working on (and should be inlined) or it was basically broken on the rest of the site as well, and should be fixed anyway.
If your css files become too big to handle, you can split them up and merge them server-side, if you want.
You don't want to define CSS for each element because if you ever need to make a change that affects many elements one day, say the looks of all the buttons or headers, you will be doing a lot of Search/Replace. And how to check if you forgot to update one rule to keep your site consistent?
Stephen touched on a very strong point in CSS. You can assign multiple classes to an element.
You should define some basic rules that "ordinary" developers can't touch. They will provide the consistency through the site.
Then developers can assign an extra class to personalize any property. I wouldn't assign more than two classes though: a global and a personalized.
Considering you already have this huge stylesheet in your hands, I'm not sure how you will pick which one of the 7 developers will have to sit down through a month and organize it. That is probably going to be hard part.
First off, you need to extract your website's default element styling and page structure into a separate stylesheet. That way people understand changing those rules affects the entire site's appearance/structure, not just the page they're working on.
Once you do that, all you really need to do is document / comment all of your code. A person is a lot less likely to write duplicate code in a well-documented stylesheet, and that is a fact.
I've been developing for a while and often develop sites using menu tabs.
And I can't figure out why so many web developers like using lists < ul >< li > etc rather than just using plain old divs.
I can make menus in divs which are simple and work perfectly in every browser. With lists, I'm usually trying to hack it one way or another to get it work properly.
So my question is simple : why should I use lists to create my menus instead of divs ?
Simple: Semantic HTML. Navigation is essentially a list of links in your HTML, so your markup should reflect this.
It has several benefits, search engine spiders can intelligently figure out what is a list of stuff (ie. your nav) and google specifically does clever things with it.
Also, users with text only browsers or screen readers can instantly recognise navigational elements with ease.
Besides, it's good practice.
If you take your menu as an example, then menus by nature can be hierarchical, and an HTML list is specifically designed for marking-up a hierarchical list of items. It is the semantically correct mark-up for that type of item and will be easily understood by any type of user-agent whether CSS is enabled or not (think of screen readers, web robots etc.)
There absolutely no reason you should find it harder to style a nested list as a sequence of 'flat' divs. In fact, quite the contrary, since you CSS syntax is designed to easily differentiate nested items.
There is no hacking needed with lists, because just setting display: block and clearing a few other styles produces identical behaviour to divs, but the advantages are that search engines, text browsers like Lynx, and so on (all UAs not seeing your CSS) get an idea of what the elements are. It also helps mashups like stumble, feed agregators and generators, and all the other programmes that take data from pages and try to assemble it into something useful.
Basically, divs are redundant (check out http://camendesign.com/ if you don't believe me; no divs, classes, or spans, though using too much HTML5 for a production site).
Is it possible to convert HTML + CSS into HTML for a system that doesn't handle CSS, not even inline CSS?
What options do I have?
No. Much of what CSS does is not possible with HTML alone. Your best option is to design your site in such a way that when it loses CSS, it still renders in a nice and orderly fashion. Pay very close attention to things like Heading Tags, paragraph tags, lists, etc. Be sure to build semantically-correct sites, and they (in most cases) will degrade quite nicely.
The only thing you can do is add styles that were possible with old html3+ attributes and font tags. Quite a bit of stuff is possible, but none of it is going to be automatic. You can go through pretty much everything in css and try to find it's html3+ attribute equivalent.
Things like background font b i center width height are examples of old attributes (or tags in the case of font) that define style (and should generally be ignored these days). I don't envy the work ahead of you, but just make a happy medium between reasonable things and unreasonable styles. Tables also might come in handy for floats as well.
Sounds like an old mobile device?
If you can't use any CSS, I would imagine you would have to resort to possibly deprecated HTML tags/attributes, like font tags and attributes like bgcolor.
This would probably be rather difficult, because to my knowledge you can't achieve everything you can do with CSS, like positioning for example. You would have to switch your layout to use tables and set align, valign, etc.
use this first
http://www.mailchimp.com/labs/inlinecss.php
then replace css with deprecated html
http://www.highdots.com/css-editor/articles/css_equiv.html
Two words: Image Maps :) (I've actually seen sites that, in order to "render correctly on every browser" literally just make a big fancy image the background, and add links accordingly via an image map)
Often when I'm designing a site, I have a need for a specific style to apply to a specific element on a page and I'm absolutely certain it will only ever apply to that element on that page (such as an absolutely positioned button or something). I don't want to resort to inline styles, as I tend to agree with the philosophy that styles be kept separate from markup, so I find myself debating internally where to put the style definition.
I hate to define a specific class or ID in my base css file for a one-time use scenario, and I dread the idea of making page-specific .css files. For the current site I'm working on, I'm considering just putting the style definition at the top of the page in the head element. What would you do?
Look to see if there's a combination of classes which would give you the result that you want. You might also want to consider breaking up the CSS for that one element into a few classes that could be re-used on other elements. This would help minimize the CSS required for your site as a whole.
I would try to avoid page-specific CSS at the top the HTML files since that leaves your CSS fragmented in the event that you want to change the appearance of the site.
For CSS which is really, truely, never to be used on anything else, I would still resort to putting a #id rule in the site-wide CSS.
Since the CSS is linked in from a different file it allows the browsers to cache that file, which reduces your server bandwidth (very) slightly for future loads.
There are four basic cases:
style= attribute. This is the least maintainable but easiest to code. I personally consider use of style= to be a bug.
<style> element at the top of the page. This is slightly better than style= because it keeps the markup clean, however it wastes bandwidth and makes it harder to make sweeping CSS changes, because you can't look at the stylesheet(s) and know what rules exist.
page-specifc css: This lets you have the clean HTML and clean main CSS file. However, it means your client must download lots of little CSS files, which increases bandwidth and page loading latency. It is, however, very easy to maintain.
one big site-wide CSS: The main advantage of one big file is that it's only one thing to download. This is much more efficient in terms of bandwidth and latency.
If you have any server-side programming going on, you might be able to just dynamically combine multiple sheets from #3 to get the effect of #4.
I would recommend one big file, whether you actually maintain it as one file or generate the file through a build process or dynamically on the server. You can specify your selectors using page-specific IDs (always include one, just in case).
As for the answer that was accepted when I wrote this, I disagree with finding a "combination of classes that gives you the result you want". This sounds to me like the classes are identifying a visual style instead of a logical concept. Your classes should be something like "titlebox" and not "red". Then if you need to change the text colour on the user info page, you can say
#userInfoPage .titlebox h1 { color : red; }
Don't start applying classes all over the place because a class currently has a certain appearance that you want. You should put high-level concepts into your page, represented by HTML with classes, and then style those concepts, not the other way around.
I would set an id for a page like
<body id="specific-page"> or <html id="specific-page">
and make use of css override mechanism in the sitewide css file.
I think you should definitely expand the thought process to include some doubt for "page specific css". This should be a very very rare thing to have. I'd say go for the global style sheets anyway, but refactor your css / html in a way that pages don't have to have super-specific styling. And if in the end there's a few lines of page-specific markup in the global css, who cares. It's better to have it in a consistent place anyway.
Defining the style in the consuming page or inlineing your style are two sides of the same coin - in both cases you are using page bandwidth to get the style in there. I don't think one is necessarily better than the other.
I would advocate making an #Selector for it in your site-wide main stylesheet. The pollution is minimal and if you really have that many truly unique cases, you may want to rethink they way you mark-up your sites.
I would put them in a <style /> tag at the top of the page.
It's not worth it to load a page-specific CSS file for one or two specific rules. I would place it in tags in the head of the document. What I usually do is have my site-wide CSS file and then using comments, section it up based on the pages and apply specific rules there.
As you know style-sheet files are static files and cached at client. Also they can be compressed by web server. So putting them in an external file is my choice.
For that situation, I think putting the page-specific style information in the header is probably the best solution. Polluting your site-wide style sheet seems wrong, and I agree with your take on inline styles.
In that case I typically place it at the top of the page. I have a page definition framework in PHP that I use which carries local variables for each page, one of which is page-specific CSS styles.
Put it in the place you would look if you wanted to know where the style was defined.
For me, that's exactly the same place as I would place styles that were used 2 times, 5 times, or 170 times - I see no reason to exclude styles from the main stylesheet(s) based on number of uses.