So I'm starting to get fairly proficient at coding my site(s). But I'd like to take some meta-steps and begin to get down best practices and workflow kind of stuff. And I was wondering, I've heard that it is always important to finish html markup before adding css. Does this extend farther? I'd think that the order would be something like html>css>server-side>client-side. Is this right or is there some better way.
Thanks guys
I think that there is no hard and fast way to do this, it's an iterative process. Depending on the server side technology that you use, some of what you may wish to do might restrict your options from an html point of view.
In general, I fire together a simple form and wire up the server side code. It's usually relatively trivial to then make the form look as you wish.
There is no such thing as right order.
I would specifically recommend not trying to finish all of your markup before you start adding in CSS and/or Javascript.
The reason is pretty simple: CSS and JS both interact with your page based on the elements and selectors you define in your markup. So if you have a vision in your head for how you're going to lay out a page, you can imagine how the markup should be (and often you'll be pretty close), but you'll find that when you actually hook CSS or JS to it there are things that don't work exactly as you had expected them to.
At this point you often need to refine your markup to get the elements and selectors set up in such a way that the CSS or JS does behave how you'd like it to.
Dealing with this is much easier when your code is leaner. If you think you've already finished your markup 100% and then you slap your CSS on top and something looks funny, you may have to spend a lot longer hunting for the exact cause of the problem and rewriting big chunks of markup than you would have spent doing it incrementally.
So, I would recommend your workflow be more "big picture" -> "details."
Start with a basic wireframe of your site and just put enough CSS in there to see that all the major sections of your page are sized and positioned as you'd expect. Then begin to layer in content and presentation at the block level, then move in and polish out the details.
Core functionality should come before you worry too much about presentational elements, but big picture layout and interactivity (which is more than just markup) should come before detailed content.
Hope that makes sense. Of course, the most important thing is to find a workflow that helps you to be as efficient as possible, so try different approaches and find the pattern that's "just right" for the way you think.
I know that is a very embracing question, but I have just started with Ruby on Rails, and still have a long way with CSS and HTML.
There are lots of books about CSS and HTML patterns, but I would like to know what is really applied to actual webpages.
For example, what's the best way of doing a simple webpage with a lateral menu, a logo on the top, and some text below?
Ok, it seems stupid, but there's lot of ways of doing that, or not ?
So, how can I learn this patterns and what are the real patterns ?
Would appreciate suggestions of books, articles, etc.
you can find some good css templates here:
http://www.csszengarden.com/
Actually in html and css there are not patterns in the oo sense.
I find this tutorial very useful:
Design and Code your first website
The nettuts website has a lot af very good free tutorials.
A very good book to begin is:
Head First HTML with CSS and XHTML
It varies from developer to developer. So I'll just tell you what I'm doing!
I'm actually following a very common pattern - separate ANY layout from the contents!
Into the HTML goes...
Text
<div/> containers with IDs to be layouted
And in the CSS goes...
Layout for the ID'd and class'ed <div/> layout containers
Colors, Background images
Fonts
It allows to rapidly change the whole page design without even touching the HTML! And it decreases both your server's traffic and the load time on the client pages, because the CSS file can be cached, since it does not change as much as the HTML does!
The CSS Zengarden nate posted is a very nice example of this pattern. The same unmodified HTML with dozens of CSS files with totally different looks!
This pattern also allows the same unmodified HTML to be displayed with automatically selected CSS files on huge displays, on small netbooks and on mobile devices. Can't be any better if you ask me!
You might want to check out some CSS libraries.
I don't personally like using them because I have ways that I like to do things and sometimes they aren't flexible enough for what I want to do. But since you're just starting out they might help you get something that looks good up really fast without having to worry about float drop bugs or margin collapsing or any other CSS quirks that are easy to hit but hard to recognize if you haven't seen them before.
An example would be the Yahoo User Interface (YUI) Grids CSS that will help you set up many different kinds of grid layouts. To find more, I would search for "css framework" or "css library".
Another YUI resource I think would be really useful for you would be their design pattern library, which documents different ways to display common interface items and gives you resources to go implement them. This can help make your interface look familiar to users and can keep you from feeling like you have to redesign a drop-down box or something.
The rule of thumb should be to do all design in CSS and HTML is just HTML without calls to design. That way, like referenced above, you can change design rapidly.
A good reference for how this works is the Zengarden CSS site at: http://www.csszengarden.com/
This is a site I used often as I learned the ins and outs of CSS design.
I'm about to begin working on a web page with a complex table-based layout (coded years ago).
One of the things I'd like to do is convert the layout to a proper CSS layout with divs and spans.
Can you suggest a good approach for tackling problems like this? Should I use a CSS framework like Blueprint? Just get in there and hack on it until it looks right? I already make heavy use of Firebug and the IE Developer Toolbar.
There generally isn't a silver bullet in converting between table and CSS. Every site is different and has different requirements. The only real answer is: simply start the markup from scratch.
The best advice is to write the markup entirely first. Make sure the markup is accurate, semantic, and represents your data entirely. Do not write the stylesheet... yet. After the markup is done, create the CSS. This way you have semantic markup and CSS is purely controlling the presentation.
CSS frameworks often don't advocate this approach to semantic markup because they force you to add additional tags to comply with their approach. Consequently, CSS frameworks are sometimes more trouble than its worth.
Do the markup, then the CSS.
Before you start, ensure you are using a CSS reset. Eric Meyer and Yahoo YUI are both excellent. This will help to make all your browsers look the same.
Also, install the HTML validator too. This will ensure your HTML is looking good and ready for adding the CSS.
Then grab a copy of Firebug and install it in firefox. This is excellent for seeing which CSS rules are doing what. You can disable individual rules by clicking s cross by each rule.
Now, visit some web pages which validate correctly and see what rules they have used in their style sheets.
Web sites to try are www.alistapart.com, CSS Zen Garden, SimpleBits etc.
The converting process will be a painful headache! I suggest you to start a whole redesign.
I don't know is this can be of any help, I build CSS Framework called Emastic (supports fluid and fixed columns) and you can simulate tables if you want here is the example Emastic Table
I second the commenters who say you should re-design the whole thing from scratch. Clean up the HTML and then make the CSS.
I'd like to add a reason to do so. Usually table-based designs are at least a few years old and therefore look quite passe. Take advantage of this opportunity to improve the design. Either a slight refresh or a complete overhaul depending on your taste and needs.
Iterative way works as well. Start with small blocks, converting them to CSS. This should simplify your table structure, hopefully leaving only the "basic grid" in tables and all the rest in CSS.
From there, pick an existing, tested solution if it's a simple layout (for 1 to 3 columns, there are tons of tested solutions out there). If it's more complex, go with Blueprint.
I wouldn't use a framework. Learning a new framework is only useful if you use it over & over again. Each framework has its own bugs and weaknesses. Use
display: table-cell;
to make a column. These will line up like float: left;. See http://quirksmode.org/css/css2/display.html
In some cases, using regular expressions could speed up your process.
For instance, something like this:
<table.*>\R*.*<tr>\R*.*<td[^>]*?>(.*)</td>
would match the start of a table and provide the contents of the first cell in $1 for a replace:
<div class="container">\n\t<div class="row">\n\t\t<div class="span6">$1</div>
Of course you'd need to customize to match your particular use case. If you have a number of similar pages, you might try hand coding one first and then using something like this to make converting the others simpler.
Another approach would be to use something like this jQuery plugin: https://github.com/ryandoom/jquery-plugin-table-to-div
It is intended to modify following rendering, but could be used during development to take a given table and provide a simple DIV based form of it.
This question already has answers here:
Why not use tables for layout in HTML? [closed]
(66 answers)
Closed 5 years ago.
I have been pondering on this over the last couple of days. I'm currently writing a web application (actually adding a screen to an existing, extensive application). I know that using "tables" for layout is a big no-no. But in this app, all of the pages use tables for layout. I decided to do my new page using divs instead.
But I came across 2 hurdles.
A lot of the layout stuff that I need to do were already done on the other pages and if I use divs instead, I cant reuse any of that (CSS's and JS and that kinda stuff). That leads to more work and pushes out my completion date.
Some of the more complex parts of the layout are really difficult to do using divs and are really easy to do using tables. Maybe its just me being "old-school"y as I am not much of a web/html kinda guy (I get by).
So, why can't I use tables? I'm not trying to be argumentative, just want to see if there are any compelling arguments beyond the "Its the right thing to do" type stuff. I know it is the right thing to do. I'd like to know why?
Implementing your layout with divs, spans, etc, offers a ton more flexibility over tables. Consider floating, auto wrapping of block content vs. horizontal scrolling, specifying where an element should exist on a page, etc. Content is just plain easier to manipulate via CSS when not using tables.
When using tables you're pretty locked in to a strict structure.
Now that doesn't mean it's absolutely the wrong thing to do. From your information I'd likely stick with the theme of the application for consistency sake and implement using tables. Make the best choice for the situation vs. following "the rules" on what's popular right now.
Hope that helps!
Ian
Doing css layouts make it easier to change the layout of your page later on.
Tables also make your html harder to read and edit.
According to this page..
make your redesigns more efficient and less expensive
help you maintain visual consistency throughout your sites
get you better search engine results when you minimize your markup and use header tags properly. This reduces ratio of code to content.
make your sites more accessible to all viewers and user agents.
your pages load faster, file sizes will be smaller because table information isn't needed in every page.
and give you a competitive edge (that is, job security) as more of the world moves to using Web standards.
I'm going to post a contrarian view, just so you have some ammo. I realize this doesn't answer your question (why not use tables) but it does address the other responses you will see.
The future of CSS never gets here (note: from 2005)
Everyone else uses tables and there are valid arguments against every response others have listed.
You might find some middle ground by using "display:table" to turn DIVs into TABLEs. Of course, you can't do this because IE doesn't support it until v8.
I read a good point somewhere: when people are referring to side-by-side columns of equal height as the "holy grail", something must be wrong with the layout engine.
I mean, just look at the unmaintainable contortions some people go through to make it work: negative margins, pixel counts that must correspond throughout five different rules, etc.
So be practical.
That said, most of my designs use pure CSS. Nearly everything can be done in CSS just as easily as with tables (or even easier.) Start with the assumption that DIVs can do it, and maybe fall back on 1 table for a tricky multi-column layout. Even then, someone has probably found a solution for your layout so search first.
They are also bad for accessibility reasons i.e. screen readers don't read them correctly, but this is only if the data you are representing is not tabular data.
Saying that, due to deadlines etc. (the real world) I've resorted to using them for form layout because it's just so much easier.
Because the tag <table> implies it should contain tabular data.
Like Peter said, the universe won't implode if you do create table-based layout, but semantically, this should be avoided.
Semantics become increasingly important, since web pages are not always shown in a desktop browser anymore. Web standards are developing in a way that HTML describes the semantic structure of the document, not the markup; and as said: using <table> tags for tabular data is semantically correct.
Interesting related reads:
Should Tables be avoided in HTML at any cost?
http://en.wikipedia.org/wiki/Semantic_Web
First, you can usually convert a table layout to divs without too much trouble once you know the necessary CSS.
But more to the point, some of the reasons why tables are bad:
Not all your users are going to see the page using the browser's rendering engine. Some are going to use a screen reader, which may assume that when it encounters a table, it should actually read the contents out as tabular data. Essentially, you should think of it as a coincidence that tables have a certain layout "look" in a browser.
tables can't be rendered until the table and all its children have been parsed. A div can be rendered independently of its children, so you avoid the page contents jumping up and down on the page as the page is parsed, and get to show contents sooner.
There are good and valid reasons to prefer tables, but when you're used to tables, there's also a certain learning curve, so if you're pressed for time, this might not be the time to make that switch.
If you have the kind of constraints you mentioned, deadline looming, large existing code base, then use tables, the universe won't implode, but in the long term using css and welformed markup will allow you to create a nicer, cleaner, more maintainable website.
Tables are pretty ugly if you want to support text to speech readers (if you've got any kind of accessibility requirements, you pretty much have to use tables for tables and nothing else).
There is an SEO aspect of this as well. For SEO, it's better to have your content at the top of the page than at the bottom. (Sadly, studies suggest appears that putting a menu first is actually a good idea for accessibility, so the two imperatives clash.)
If you are having trouble with cross-browser support, I can suggest that you develop using Firefox. Its support for CSS development is much better than other browsers, and it's more standards-compliant (and hence more predictable). Later on, you can patch up for down-level browsers.
And, as Peter says, the universe won't implode. But using CSS for layout is cleaner in the long term. Redesigning something with the layout hard-coded can be a real pain. Check out the CSS Zen Garden for examples of what you can do. Of course, in the future, we'll have CSS table layouts, the best of both worlds.
Tables also affect the behaviour of search engines. Using CSS instead of tables is actually an SEO technique as well. The reason I heard for this is that search engines stop indexing after a certain level of tags, and layout using tables can become very deeply nested.
Using CSS for layout, rather than HTML tables provides a level of separation between your page content and the layout of that content.
With tables, your HTML markup has both your content and layout intermingled within the HTML code. This means is you ever want to have a different layout for the same content, you'll need to edit the intermingled code heavily.
By using a CSS stylesheet over your HTML markup you separate the code that provides the content (HTML) from the code that provides the layout (CSS). This makes it far easier to completely change the layout aspect of a web page without having to edit the content code.
The best example of this is the CSS Zen Garden website.
All that said, it's still far easier to do some layout techniques in tables rather than CSS, so there's definitely a "balancing act" there. (For example, even Google uses tables in it's page layouts!)
By using tables for layout you tie the content to the formatting, this is the main point that most of the disadvantages come from. It messes up the source, complicates site-wide formatting updates that could be easily done with CSS, etc. Using tables for layout also often means slicing images on weird places just to fit them in the cells, yuck.
you can use tables, but divs have more advantages.
but it's all in perspective.
Like you say, you are precious for time, so probably (on short notice) tables will be the choice to make. However, if you manage to make it div-wise, you will have a more maintable page, which you can use to refactor the other pages as well.
Jeffrey Zeldman wrote a great book on this topic: Designing With Web Standards. This book should be mandatory reading for every web designer.
Here are some reasons why tables for design are bad
Tables generate more markup -> More bandwidth usage
Tables makes it harder for search engines to index your pages -> Your site becomes less "searchable"
Tables makes it harder to change and tweak the visible appearance of your site -> More costly redesigns
...But most importantly: using tables for design adds presentation logic to your markup
That is bad because you want to separate your presentation from your content! HTML should only define WHAT your content is, not HOW it should look.
If you obtain this level of separation your site will...
...be more accessible by different kinds of browsers and other kinds of user agents.
...make redesigns much easier
The best you do not listen to the fanatics of CSS. These purists live in some imaginary world and will feed you the arguments of some abstract purity, semantics and the rest. You would not want to have this kind of people in your team. For now I've only seen yellow-mouth students to run around with "pure CSS design" ideas. They'll show you examples of very primitive CSS-designed sites, ignoring you whenever you ask them how you can accomplish some complex enterprise software design with it. Experienced developers already know this perfection is not possible.
What should you do? Follow the KISS principle. If CSS can help you implement your particular design idea, fine, the problem is solved. If you need to resort to some relatively uncomplex hack, it may be okay. But when it comes to some huge piece of code with dozens of rules to make a basic thing, which you easily and naturally achieve with tables, drop it.
It serves no purpose to create an incredibly complex and sophisticated tricky CSS design that noone else (and yourself after a couple of months) will be able to understand and support.
As for the "easy redesign", unless you only want to change colors and fonts, you will enevitably have to restructure your markup whether it is done with tables or without them. In the latter case, a high portion of your markup will serve no purpose except implement CSS trickery which will be useless for you new redesign idea.
Honestly, it's not your fault that the people responsible for further development of HTML/CSS don't do their job properly. You should not waste your and other people's time trying to find workarounds for something that should have been there ages ago.
HTML/CSS is a good example of how poorly some committee could do their job and brake the development of technology as compared to a single company with resources and commitment.
"The right thing to do" depends on your situation.
Yes, divs offer more flexibility, but at the end of the day, do you really need it? As far as the number of lines of code goes, I have found that a simple table is often quite a bit smaller that an equivalent div design.
It's faster to put together, and it works as reliably as possible in pretty much all browsers, which means you don't have to write a zillion hacks to make it work consistently AND it doesn't break down when a new display engine comes out.
Using tables for display is technically a hack, but it does the job, is easy to understand and maintain and is to a large degree future proof, so for a simple layout, considering that the rest of the website already uses tables for layout, I would keep using tables.
Besides, turning a Table into a "div" table which uses the new "display=table" attributes can easily be done with a few regexes (if you rack your brains, you can probably even do it with a single pass). If you know your regexes, you can replace a table with divs through an entire website in a matter of minutes, so the whole issue of flexibility is really not that big: when (if) you actually need to use divs and CSS positioning, just run a few regex, and you are set. And if you need more control than what you can handle from regex, you can spend a couple hours to write a quick & dirty parser that will convert your tables to div exactly as you want them.
Bottom line is that despite the stigma, for simple layouts, tables still do the job, they do it fast and are reliable, and if you don't have to contend with CSS purists, you can save yourself a lot of work.
CSS layouts make it easier to alter the layout through stylesheets (separation of data from display).
Also, browsers often can't render a table until the </table> tag has been parsed. This can be a problem if you are using a table with a large amount of content. CSS layouts can often be rendered as they go.
The Separation of Layout and Content is the domain of CSS and HTML - so far well understood. Now about separating...
I'm looking for hints and Best Practices to get started with the task of providing a "skin" or "theme" for a content management system.
Background:
We are starting to embrace a Portal Server/Content Management System and are starting to change the look and feel to match our needs.
Our designer has so far mainly worked with full control over HTML and CSS, tweaking either one in order to get pixelperfect layout. With adoption of the cms there's a lot precreated HTML (very semantic, almost no tables :) that needs to be skinned with CSS and Images. Though it is possible to change the HTML fragments, I'd prefer to do so only as a last resort.
As this provides the challenge of "how to get started" my question is about any tipps how to proceed or articles that can help managing or organizing this task - e.g. best practices in designing, how to slice this task or what tool to use.
It seems bad practice to just save a dynamically generated page to disk and make changes locally. This would be somewhat ok for the CSS files but changes to HTML elements must be retrofitted to the fragments that they are generated from. I'd like to keep this out of the designer's realm if possible. Also, the thought of Dreamweaver (or any similar tool) making implicit tweaks to the HTML structure is frightening for me.
For the curious: The mentioned CMS/Portalserver is Liferay, but the question is really language- and tool-agnostic.
Edit: FireBug (as Josh suggested) is awesome for trying on-the-fly changes to css. Is there more - either in the area of tools or in-process and self-organization?
If you're looking for practical examples of separating style and content, then I'd suggestion the CSS Zen Garden. Trawling through the HTML and CSS is inspirational and enlightening and should help with what you're trying to do.
My #1 tip would be be to make everything as semantic as possible and use lots of classes and ids to hook your styles onto.
Usually, Whenever I am in a situation Like this, I bring up the page in FireFox, inspect the different elements using FireBug and see exactly what css is applied to them. THen I'l just modify the existing css until I get what I like. You can even play around in firebug and modify the CSS without "saving" those changes.
Have look at CSS Tidy, we normally use this to clean up the CSS and reorganise for development and production. However, I personally prefer writing HTML/CSS by hand before using this. It is just a matter of individual preference I guess.