Related
I'm fairly new to HTML. With the rise of HTML5's popularity as a standard (at least, from what I've learned and experience the past couple of semesters), I am wondering if it is still considered good practice to use [DIV] instead of new container elements, such as [main], [nav], etc.
I feel far more comfortable using div's as opposed to the new container tags because of their default values and how much like putty they are when it comes to box modeling a page the way I want it.
My main question is this: If a potential employer or well-seasoned programmer were to look at my HTML5 code and saw div's instead of new container tags, would it be considered bad practice/sloppy coding? Or is using div's still entirely acceptable? Apologies if this is a silly question, but I ask because after this semester is over I'm going to start applying for jobs and want to make sure that my practices/standards are conducive to those that will offer me the highest chance of landing a good employment opportunity!
DIV tags do not convey meaning like you get with the html5 specific section tags. The functionality is the same as far as the block element. Using the new HTML5 tags help self document your code and not need comments to explain what each DIV does.
I would recommend to get into using the new tags in HTML5 instead of just divs. You should always want to write as semantically as possible. This helps you grow as a coder and move the web forward.
Default behavior is a poor reason to not use semantic markup. For one thing, almost every site should use a CSS reset mechanism. Bootstrap, et al, do this for you, and they generally apply border-box sizing for convenience.
Aside from polyfills for older browsers, fallback markup is an option. Wrap a classed div with an HTML5 element and apply CSS to both.
Semantic markup allows other types of content consumption beyond the standard web page, such as syndication feeds and print document generation. HTML5 elements provide much contextual information in those cases, as well as for visually-impaired users who employ screen readers and other assistive technology.
All that said, I doubt many employers will deduct for element choice. Overall page structure, markup cleanliness, appropriate internal documentation, etc. are probably more important.
DIV's are always acceptable, but for a better codding semantic and for the searching engines it's a better practice to use the HTML5 tags. Sooner or later you'll use them so better start practicing.
HTML5 tags are a better way to organize code and help searching engines for best results. It's also help for the CSS because surely you'll save classes and will target the tags.
HTML5 is the way...
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Inline styles vs styles in CSS
i guess i'm looking for some opinions on this. I am all for using css styles as classes in a separate .css file. But every once in a while, i run into a scenario where i need just some padding for a particular element or change the css class' width only in one particular situation. Is it okay to add inline styles in those scenarios? do people do this or always create classes for everything.
My theory would be if its not something reusable or does not contain more than 2 styles, why create a class for it. Am I wrong in thinking that?
Summary of Answers (since there are many)
It is better to avoid inline styles because
1) style sheets provides more maintainability.
2) better separation of html data and layout.
3) re-usability of styles.
4) probably provides better caching.
Overall, css style sheet is the best practice.
Anything is reusable if you think it through and set it up correctly. Even one-line, one element CSS attributes can be beneficial if reused. This takes advantage of the concept of caching, which will keep the css in memory after the initial load hit. No matter which way you slice it, inline styles add to your overhead every load without question.
Never mind the fact that inline mixed with a proper css document adds overhead to your own debug time, figuring out where the darned calls are coming from.
Two answers to this one:
1) It's considered good practice to keep your design (css) and your data (html) separate. By adding in-line styles, it makes it more difficult to revise the look of a site, it makes it more difficult for future programmers to modify your site, and is overall NOT the best way to go.
If everything is in a CSS file(s), then you can change the entire design of your site without having to mess with the data (HTML) of the site. This is ideal.
2) Yes, a lot of people still use inline styles very often when tweaking something small, regardless of "best practice".
You said: "if its not something reusable or does not contain more than 2 styles"
I would add another reason to use external stylesheets: maintainability. If you (or someone else) has to fix your code in the future, you will have a much easier time of it if all of your styling is in one place. You will not remember that you added that little bit of styling inline, and you may spend hours hunting for it.
It is a good standard to keep all styling separate to maintain clean, maintainable code.
That said, we can acknowledge that it is "ok" to use inline styles, as you asked in your question. However, best practice is often something more than "ok" and should serve as a guide as often as possible.
I feel like a good balance is all that you need. While its typically considered better practice to create classes as much as possible, there comes a point when its just easier to use an inline style. Like you said, if there's just that one element that needs that minimal extra padding, its not a crime to give it that. At least, in my opinion it isn't. But definitely be in the habit of making classes for just about everything, except minor exceptions.
Its not just about re-use, its about getting into the habit of doing things correctly. What if someone else needed to help you on the project, they would have to sift through your whole file to find every instance of an inline style somewhere...
People who know their CSS always create a specific style rule for everything.
Thats my opinion and I believe it to be shared among my colleagues.
A big point for me is: maintenance. When all of the CSS is in external stylesheets, it is going to be relatively straightforward to find the styles your looking for to edit them. If there are inline styles, it will be harder to find what you're looking for.
I'm usually skeptical about claims that a style never be reused. If it happened once, it is likely to happen again. Coding for reusability is always a good idea and usually results in cleaner, better written code in my experience.
Even in these situations, I will usually add a unique class somewhere up in the target element's ancestors - often on the body tag - that I can use to target the the "unique situation" and keep all the CSS in the external stylesheet.
That being said, I do occasionally use inline styles. When I do, it is almost exclusively in a situation where I know that I will be animating styles with JavaScript after the page has loaded. I only do inline styles for the properties that I am going to animate and the rest go in the external stylesheet.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am taking a peek at Dive Into HTML5. It seems nice and interesting, but I am puzzled.
In the 1990s, at the time when Netscape was the browser and HTML was HTML2 or HTML3, there were a lot of tags: address, cite, code... Most of them are unused as of today, probably even obsolete.
HTML5 introduces tags to express "semantic meaning" to the tag itself. This is all fun and games, but I see something very strange in this approach. Technically, the semantics can be very open ended. HTML5 has tags for article, time, navigation bars, footer. Why shouldn't it contain tags for post icon, author's place, name and surname, or whatever else you want to assign specific semantics to (I'm confident <rant> and <nsfw> would be very important tags): ? I thought XML was the strategy to assign semantics to stuff. Nothing forbids you to put an XML chunk under a XHTML div element, and assign a stylesheet to it so to style it properly, or to delegate to the proper viewer the handling of that namespace (for example, when handling RSS or SVG).
In conclusion, I don't understand the reason behind this extensions focused towards semantics, when it's clear that semantic is a very broad topic, which is guaranteed to require a potentially infinite amount of semantic tags. Since I am pretty sure there are clever people at W3C, I think I'm wrong, but I'd like to know why.
Why are tags for article, time, navigation bars, footer useful?
Because they facilitate parsing for text processing tools like Google.
It's nothing about semantics (at least in 'broad' meaning). Instead they just say: here is the body of page (most important text part) and there is the navigation bar full of links. With such an approach you can easily extract just what you need.
I too hate the way that W3C is going with their specs. There are many things that I don't like, and this "semantics" fad is one of them. (Others include taking forever to complete their specs and leaving too many important details for the browsers to implement as they choose)
Most of all I don't like it because it makes my work as a web developer more difficult. I often have to make a choice whether to make the webpage "semantically correct" or "visually/aesthetically pleasing". The latter wins of course, because that is what the users want, but as a result validations start failing and the whole thing gets quite non-semantic (tables for layout and other things).
Another issue at which I frown is that they have officialy declared that the "class" attribute is for semantics, but then they used it for visual presentation selectors in CSS.
Bottom line - DON'T MIX SEMANTICS AND VISUAL REPRESENTATION. If you use some mechanism for describing semantics (like tag names, attribute values, or what not else), then don't use it for funcional/visual purposes and vice versa.
If I would design HTML, I would simply add an attribute "semantic" which could (like the "class" attribute) be added to any tag. Then there would be a number of predefined values like all those headers/footers/articles/quotes/etc.
Tags would define functionality. Basically you could reduce HTML tags to just a handful, like "div", "table/tr/td", "a", "img", "form", "input" and "select". I probably missed a few but this is the bulk. Visual styling would be accomplished through CSS.
This way the three areas - semantics, visual representation, and functionality - would be completely independent and wouldn't clash in real life solutions.
Of course, I don't think W3C is interested in practical solutions...
There is already a lot of semantics in HTML markup in the forms of classes and IDs, of which there is a (near) infinite amount of possibilities of, And everyone has their own way of handling these semantics. One of the goals of HTML5 is to try to bring some structure to this. you will still be able to extend the semantics of tags with classes and ids. It will also most likely make things easier for search engines.
Look at it from the angle of trying to make statements either about the page, or about objects referenced from the page. If you see a <footer> tag, all you can say is "stuff in here is a footer" and pass it by. As such, adding custom tags is not as generic a solution as adding attributes and allowing people to use their own choice of URIs to specify predicates and optionally values - RDFa wins hands-down because you can express any triple-statement you like from RDF in a page, one way or another.
I just want to address one part of your question. You say:
In the nineties, at the time when
Netscape was the browser and html was
HTML2 or HTML3, there were a lot of
tags: address, cite, code... Most of
them are unused as of today, probably
even obsolete.
There are a great deal of tags to choose from in html, but the lack of usage does not imply that they are obsolete. In particular the header tags <h1>, etc, and <ul>, <ol> are used to join items into lists in a way I consider semantic. Many people may not use tags semantically, but the effort to create microformats is an ongoing continuation of the idea you consider an artifact of the 1990s. Efforts to make the semantic web be a winner keeps going, despite full-text search and link analysis (in the form of Google) being the winner as far as how to find and understand the web.
It would be great to see an updated version of Google's Web Stats which show "html as she is spoke." But you are right that many tags are underused.
Whether html5 will be successful is an open and interesting question, but the tags you describe as obsolete didn't go anywhere, they were there in HTML 4.01 and xhtml. HTML5 seems to be an effort to solidify what is useful in tags. In the end if html5 gets support in browsers and makes the job of web developers easier, it will succeed. xhtml2 failed because it roundly failed to gain adoption in browsers and did nothing to make the job of web page makers easier. The forces working on html5 seem keenly aware of the failure of xhtml2, and I think are avoiding having html5 suffer a similar fate.
"Why shouldn't it contain tags for post icon, author's place, name and surname, or whatever else you want to assign specific semantics to (I'm confident and would be very important tags): ?"
You use <dialog> to describe conversations or comments. Rant and NSFW are subjective terms therefore it makes sense not to use them.
From what I understand a bunch of experienced web developers did research and looked for what most websites have in common in html. They noticed that most websitse have id="header", id="footer", id="section" and id="nav" tags so they decided that we need HTML tags to replace those id's. So in other words, don't expect them to give you a HUGE amount of HTML vocabulary. Just keep it simple as possible as you can while addressing the MOST common needed HTML tags.
NAV tag is VERY important for providing accessibility as well. You want them to know where the navigation is rather than to force them to find whether links are for navigation or not.
I disagree with adding extra tags. If detailed vocabulary were actually import then there could be a different tag name for every word in the dictionary. Additional tags names are not helpful as they may communicate additional meaning to humans, but do nothing to facilitate machine parsing of the language. This is why I don't like the "semantic" tags for HTML5 as I believe this to be slippery slope to providing a vocabulary too complex while only providing a weak solution to a problem not fully addressed.
In my opinion markup language structure data as much as describe it in a tree diagram form. Through parsing of the structure and proper use of semantic conventions, such as RDFa, context can be leveraged to provide specific meaning to otherwise generic tag names. In such as case excessive vocabulary need not exist and structurally redundant tag names, such as footer and aside, could be eliminated. The final objective is to make content faster and more accurate to interpret by both humans and machines simultaneously while using as little code as possible to achieve that result. How that solution is lesser important, except to HTML5.
I thought XML was the strategy to assign semantics to stuff.
As far as I know, no it wasn’t. XML allows new languages to be defined which are all parsed in the same way, because they all use the XML syntax.
It doesn’t, of itself, provide any way to add meaning (“semantic” just means “meaningful”) to those languages. And until computers get artificial intelligence, they don’t actually understand meaning, so meaning is just what is agreed between human beings. HTML is the most commonly-used language with agreed meaning of its tags.
As HTML is so common, it’s helpful to add a few meaningful tags to it that are quite general in their application. The new HTML5 tags are aimed at that. The HTML5 spec’s authors could indeed carry on down this route, creating tags for every specific bit of meaning possible, but as they’re not robots, they probably won’t.
<section> is useful, and general enough to be meaningfully applicable in lots of documents. <author-last-name> isn’t. Distinguishing between the two is a judgment call, which is why humans, and not computers, write the spec.
For custom semantics that are too specific to be added to HTML as tags, HTML5 defines microdata.
I've been reading Andy Clark's book Transcending CSS (page 33).
...,it is now widely accepted that presentational names such as header, left, or red that describe an element's look or position are poor choices.
After reading these lines I asked myself: hey, aren't there elements in HTML5 spec such as header, footer?? Why is footer more semantic ? Andy in his book advocates to use site-info for the ID of the footer div and this makes more sense IMHO. Footer is a presentational name (describes the element's position).
In a word, AJAX. The new tags are meant to support what real-world developers are doing by replacing some of the <div class="sidebar-wrap"><div class="styling-hook"><div><ul class="nav"> type of divitis many websites suffer from. The only <div> left in the HTML5 is the styling hook.
The semantics that get promoted to tags from classes are those that developers have freely adopted en-masse as best practices, given an extended xhtml/css adoption period. Check out the WHATWG developer's edition of the spec's sections pagehere. The document itself is a pleasure, but I won't spoil it if you haven't seen it yet.
One of the less obvious reasons for some decisions made by the W3C is the importance of Webkit. If you look, you can see that they were better than some at taking the current work of the HTML5 Working Group and implementing ideas. They have historically been way out ahead in compliance (see here). The W3C placed a high priority on their (i.e. Android, iPhone, the Googlebot, Chrome, Safari, Dreamweaver, etc.,). Google, framework users, Wordpress/Moveable Type/Joomla! type users and others wanted self contained building blocks, so this is the style we get.
Facebook is modular. Responsive design's grids are modular. Wordpress is modular. Ajax works best with modular page structures. Widgets are modules. Plug-ins are modules. It would seem that we should be trying to figure out stuff like how to apply these tags to make it easier to hook the appropriate elements and activate them in our document/application/info-network hybrid Web 2.0.
In closing, HTML5 is meant to be written as xml (again, see the spec) in order to ensure that tools and machines making ajax requests for a portion of a document will get a well-formed useful response. How awesome in combination with things like media queries for devices like feed readers, braille printers, annotators, etc.,. I see a (near)future where anything with good semantic content is it's own newsfeed automagically! This only happens if developers adopt and write compliant documents.
Looking at the source code for Stack Overflow, I noticed they have used tables and inline CSS quite a bit, also something I found odd was use of inline table attribute formatting.
<table width="100%">
I'm just curious if there was any specific reason(s) to why they used tables to structure their template instead of the popular (or used to be popular) DIVs.
As well...the purpose of using CSS includes and using inline CSS on the same page (I know there is probably a great answer/solution(s) for this...I'm just curious to what they are)
I understand there is nothing wrong with using tables for tabular data...but in this case Stack Overflows tables are used for structure.
Tables vs. Divs is a pointless holy war.
There are specific issues with using tables in particular ways for layout that can cause problems. One of these is building an entire site layout in a single table in order to handle margins and placement -- because of the way tables are rendered this frequently means a website will not render progressively by the browser engine as the content downloads, and can only be rendered after the entire thing has been received. For a large page or slow modem user, they may be staring at a blank page for quite a while, which is a "Bad Thing". Never mind a lot of the inconsistencies in table rendering in the mozilla/ie5 generation of browsers that made consistent cross-browser table layouts somewhat painful, especially with images in the cells.
Supporters of the pure div path like to talk about content vs. presentation, because in theory HTML 4.01 is pure content, all of it meaningful. The divs provide meaningful organizational structure in an abstract sense, which is then given presentation exclusively by CSS. In these arguments, tables are valid only if being used to contain actual tabular data. Of course, this ignores the fact that for any sufficiently complex layout, there are almost always quite a few empty divs floating around simply to support the necessary hooks for presentation CSS, breaking the first level of this abstraction. Once this abstraction is broken, there's no law stating that, when your layout simply requires a presentation hook in the HTML that has no meaningful content, a div is somehow more appropriate than a table. If you are stuck with the choice of a meaningless div or a meaningless table in order to make your layout work, choose whichever is easier.
In the end, it's about being aware of the limitations in all methods and using the one that is most appropriate. There are many cases where using a table is simply easier than setting up a pointless (i.e. not-content-meaningful) array of divs, and the table rendering limitations don't apply. If the table is small and represents a minor chunk of the interior content, the rendering delay is not relevant.
Having not been involved in SO development, I only speak generally:
I've found that tables are often easier and more consistent across browsers than CSS-based layouts.
Also, emitting random CSS here and there often happens when trying to get things done. It can be refactored later, I suppose.
With respect to why they chose to set a table's width in HTML instead of CSS, I couldn't say.
I know that SO used a real, honest to goodness designer when they started. I don't know, though, if that designer gave them an image of what the site should look like or actual markup.
Please don't flame me for saying so. We're not all CSS ninjas.
SO was probably written by programmers, not web developers.
Tables are not evil, but certain uses of them (which used to be everywhere) are evil. Namely, using spacers, nested cells, etc, to control margin and padding.
Even though everyone now a days talk about layout with css and divs, the truth of the matter is css is awful when it comes to layout. You can only do so much. Look at some suggested solutions to get 2 or 3 column layouts using css, they all suck. Throwing a <table><tr><td id="left-column"><td id="right-column"></tr></table> is a lot easier.
css is just not suitable for non-trivial layout (and by that, I mean pure div/css)
The table solution I just threw above needs to use css to control width and padding and borders and background images, etc.
Give up and use tables
Because Internet Explorer does not support the display:table CSS property, which is what provides the grid-like layout model (equivalent to how html tables are rendered). The grid-model is the simplest and most flexible way to model many layouts.
So you have three choices, none of them attractive:
sacrifice support for Internet Explorer (all other modern browsers supports display:table property, which have been part of the CSS2 standard for more than a decade)
use cumbersome CSS workarounds which are costly and hard to maintain.
sacrifice semantic purity and use TABLE-elements.
SO chose the last option, probably because they think support for Internet Explorer users is more important than support for disabled users, and because they wanted something that was quick to develop and simple to maintain.
Jeff and his team were getting it done quick and dirty. This was a very quick development cycle, without the time to refactor out much of the clutter.
And face it - unless you are an expert, CSS is time consuming for table structures.
Inline styles and included css are just a sign they were trying to get it done, not worrying (at least for the first iteration) about the "right" way of doing it. The right way was whatever worked and got it done fast.
IE8 will be the last major browser to finally add support for the CSS display: table-* values, so the distinction will go away. Hopefully this will end the whining about how hard CSS is, and people can stop polluting markup with presentation.
I'm a reasonably smart person, not too far below average at least, but I find css layout totally unintuitive. Tables are extremely intuitive. I think one measure of a good technology is how often you have to refer to the manual while reading it. Tables blow CSS out of the water in this way compared to css. Again and again, when using css, I have to dig to figure out how to do something like this
Tables and layout
SO's layout is not based on tables.
At a quick glance, I'd say SO layout is 80% div-based and 20% table-based. Tables are used in the header and on the "badges" box. Table use is appropriate for badges IMHO (it's a list of items, after all), not so good for the header.
Anywhere else, divs are used.
Inline CSS
Again, many inline definitions are used (probably to quickly mockup site's structure), but SO correctly uses also css (to style the divs and to provide print formatting).
"css is too hard" and "tables are quicker and easier" excuses, coupled with some down right misgivings about what's wrong with the use of tables for structural markup.
The question is asking why SO chose to use tables, inline css, etc., to which I think the answer is probably nothing more than that either they aren't familiar with graceful degradation and semantics, or they didn't consider it important enough to devote the time and resources.
There's nothing wrong with not knowing css, but to dismiss semantic markup and the proper use of css just because you don't know it is just WRONG.
To champion that your site looks the same in every browser using tables, while not giving a seconds thought to those that don't use a visual browser smacks of selfishness - that's a strong word, and I apologize for the tone, as I don't intend to insult.
BTW - I take umbrage at the idea that the use of tables for structural markup is a 'holy war'. While some might think that Semantic markup is overly championed, it is not based upon blind faith.
CSS is great and can really simplify your markup, however, sometimes aligning content with tables is just easier and more reliable. Also for code generated dynamically some of the pain points for non-CSS based styling are less bad. Specifically, since you are dynamically, creating the markup you can re-factor the styling elements in the functional code.
As for the in-line styles, I often use these when I'm building a page and then try to re-factor them into an external sheet later. This makes it a little easier for my testing (no need to do a hard refresh) and changes are in one file instead of two.
My thougths would be they went with table because (apart from the argument table vs css)
They needed to get the functionality get out rolled quickly to have an opinion
After all this is just the public beta.
They were experimenting with ASP.NET MVC more and layout issues less
SO is all about programming questions and answers and at the end that what matters.
SO is all about recognizing the contributors by rewarding points and badges which it does quite decently (this may also be a controversial topic).
and so on....
I have no idea, but the only explanation I can come up with is that Jeff isn't as supportive of web standards as he'd like us to think and none of the team are that hot on CSS. Programmers often use cross-browser-ness, ease-of-use and numerous other supposed time benefits to excuse their lack of CSS skills. And I don't mean that as a criticism, they're probably really good at programming C#/Java/Ruby/SQL/whatever, they just can't seem to admit that they don't really know something as well us a bunch of polo-neck wearing, Mac Book wielding designers...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
It seems to be the general opinion that tables should not be used for layout in HTML.
Why?
I have never (or rarely to be honest) seen good arguments for this. The usual answers are:
It's good to separate content from layoutBut this is a fallacious argument; Cliche Thinking. I guess it's true that using the table element for layout has little to do with tabular data. So what? Does my boss care? Do my users care?Perhaps me or my fellow developers who have to maintain a web page care... Is a table less maintainable? I think using a table is easier than using divs and CSS.By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs.
Readability of the codeI think it's the other way around. Most people understand HTML, few understand CSS.
It's better for SEO not to use tablesWhy? Can anybody show some evidence that it is? Or a statement from Google that tables are discouraged from an SEO perspective?
Tables are slower.An extra tbody element has to be inserted. This is peanuts for modern web browsers. Show me some benchmarks where the use of a table significantly slows down a page.
A layout overhaul is easier without tables, see css Zen Garden.Most web sites that need an upgrade need new content (HTML) as well. Scenarios where a new version of a web site only needs a new CSS file are not very likely. Zen Garden is a nice web site, but a bit theoretical. Not to mention its misuse of CSS.
I am really interested in good arguments to use divs + CSS instead of tables.
I'm going to go through your arguments one after another and try to show the errors in them.
It's good to separate content from layout
But this is a fallacious argument; Cliché Thinking.
It's not fallacious at all because HTML was designed intentionally. Misuse of an element might not be completely out of question (after all, new idioms have developed in other languages, as well) but possible negative implications have to be counterbalanced. Additionally, even if there were no arguments against misusing the <table> element today, there might be tomorrow because of the way browser vendors apply special treatment to the element. After all, they know that “<table> elements are for tabular data only” and might use this fact to improve the rendering engine, in the process subtly changing how <table>s behave, and thus breaking cases where it was previously misused.
So what? Does my boss care? Do my users care?
Depends. Is your boss pointy-haired? Then he might not care. If she's competent, then she will care, because the users will.
Perhaps me or my fellow developers who have to maintain a web page care... Is a table less maintainable? I think using a table is easier than using divs and css.
The majority of professional web developers seem to oppose you[citation needed]. That tables are in fact less maintainable should be obvious. Using tables for layout means that changing the corporate layout will in fact mean changing every single page. This can be very expensive. On the other hand, judicious use of semantically meaningful HTML combined with CSS might confine such changes to the CSS and the pictures used.
By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs.
Deeply nested <div>s are an anti-pattern just as table layouts. Good web designers don't need many of them. On the other hand, even such deep-nested divs don't have many of the problems of table layouts. In fact, they can even contribute to a semantic structure by logically dividing the content in parts.
Readability of the code
I think it's the other way around. Most people understand html, little understand css. It's simpler.
“Most people” don't matter. Professionals matter. For professionals, table layouts create many more problems than HTML + CSS. This is like saying I shouldn't use GVim or Emacs because Notepad is simpler for most people. Or that I shouldn't use LaTeX because MS Word is simpler for most people.
It's better for SEO not to use tables
I don't know if this is true and wouldn't use this as an argument but it would be logical. Search engines search for relevant data. While tabular data could of course be relevant, it's rarely what users search for. Users search for terms used in the page title or similarly prominent positions. It would therefore be logical to exclude tabular content from filtering and thus cutting the processing time (and costs!) by a large factor.
Tables are slower.
An extra tbody element has to be inserted. This is peanuts for modern web browsers.
The extra element has got nothing to do with tables being slower. On the other hand, the layout algorithm for tables is much harder, the browser often has to wait for the whole table to load before it can begin to layout the content. Additionally, caching of the layout won't work (CSS can easily be cached). All this has been mentioned before.
Show me some benchmarks where the use of a table significantly slows down a page.
Unfortunately, I don't have any benchmark data. I would be interested in it myself because it's right that this argument lacks a certain scientific rigour.
Most web sites that need an upgrade need new content (html) as well. Scenarios where a new version of a web site only needs a new css file are not very likely.
Not at all. I've worked on several cases where changing the design was simplified by a separation of content and design. It's often still necessary to change some HTML code but the changes will always be much more confined. Additionally, design changes must on occasion be made dynamically. Consider template engines such as the one used by the WordPress blogging system. Table layouts would literally kill this system. I've worked on a similar case for a commercial software. Being able to change the design without changing the HTML code was one of the business requirements.
Another thing. Table layout makes automated parsing of websites (screen scraping) much harder. This might sound trivial because, after all, who does it? I was surprised myself. Screen scraping can help a lot if the service in question doesn't offer a WebService alternative to access its data. I'm working in bioinformatics where this is a sad reality. Modern web techniques and WebServices have not reached most developers and often, screen scraping is the only way to automate the process of getting data. No wonder that many biologists still perform such tasks manually. For thousands of data sets.
Here's my programmer's answer from a simliar thread
Semantics 101
First take a look at this code and think about what's wrong here...
class car {
int wheels = 4;
string engine;
}
car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;
The problem, of course, is that a bike is not a car. The car class is an inappropriate class for the bike instance. The code is error-free, but is semantically incorrect. It reflects poorly on the programmer.
Semantics 102
Now apply this to document markup. If your document needs to present tabular data, then the appropriate tag would be <table>. If you place navigation into a table however, then you're misusing the intended purpose of the <table> element. In the second case, you're not presenting tabular data -- you're (mis)using the <table> element to achieve a presentational goal.
Conclusion
Will visitors notice? No. Does your boss care? Maybe. Do we sometimes cut corners as programmers? Sure. But should we? No. Who benefits if you use semantic markup? You -- and your professional reputation. Now go and do the right thing.
Obvious answer: See CSS Zen Garden. If you tell me that you can easily do the same with a table-based layout (remember - the HTML isn't changing) then by all means use tables for layout.
Two other important things are accessibility and SEO.
Both care about in what order information is presented. You cannot easily present your navigation at the top of the page if your table-based layout puts it in the 3rd cell of the 2nd row of the 2nd nested table on the page.
So your answers are maintainability, accessibility and SEO.
Don't be lazy. Do things the right and proper way even if they are a bit harder to learn.
See this duplicate question.
One item you're forgetting there is accessibility. Table-based layouts don't translate as well if you need to use a screen reader, for example. And if you do work for the government, supporting accessible browsers like screen readers may be required.
I also think you underestimate the impact of some of the things you mentioned in the question. For example, if you are both the designer and the programmer, you may not have a full appreciation of how well it separates presentation from content. But once you get into a shop where they are two distinct roles the advantages start to become clearer.
If you know what you're doing and have good tools, CSS really does have significant advantages over tables for layout. And while each item by itself may not justify abandoning tables, taken together it's generally worth it.
Unfortunately, CSS Zen Garden can no longer be used as an example of good HTML/CSS design. Virtually all of their recent designs use graphics for section heading. These graphic files are specified in the CSS.
Hence, a website whose purpose is to show the advantage of keeping design out of content, now regularly commits the UNSPEAKABLE SIN of putting content into design. (If the section heading in the HTML file were to change, the section heading displayed would not).
Which only goes to show that even those advocate the strict DIV & CSS religion, can't follow their own rules. You may use that as a guideline in how closely you follow them.
This isn't the definitive argument, by any means, but with CSS you can take the same markup and change the layout depending on medium, which is a nice advantage. For a print page you can quietly suppress navigation without having to create a printer-friendly page, for example.
One table for layout wouldn't be that bad. But you can't get the layout you need with just one table most of the time. Pretty soon you have 2 or three nested tables. This becomes very cumbersome.
It IS a LOT harder to read. That's not up to opinion. There's just more nested tags with no identifying marks on them.
Separating content from presentation is a good thing because it allows you to focus on what you're doing. Mixing the two leads to bloated pages that are hard to read.
CSS for styles allows your browser to cache the files and subsequent requests are much faster. This is HUGE.
Tables lock you into a design. Sure, not everyone needs the flexibility of CSS Zen Garden, but I've never worked on a site where I didn't need to change the design a little bit here and there. It's much easier with CSS.
Tables are hard to style. You don't have very much flexibility with them (i.e. you still need to add HTML attributes to fully control a table's styles)
I haven't used tables for non-tabular data in probably 4 years. I haven't looked back.
I'd really like to suggest reading CSS Mastery by Andy Budd. It's fantastic.
Image at ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg
It's good to separate content from layout
But this is a fallacious argument; Cliche Thinking
It's a fallacious argument because HTML tables are layout! The content is the data in the table, the presentation is the table itself. This is why separating CSS from HTML can be very difficult at times. You're not separating content from presentation, you're separating presentation from presentation! A pile of nested divs is no different than a table - it's just a different set of tags.
The other problem with separating the HTML from the CSS is that they need intimate knowledge of one another - you really can't separate them fully. The tag layout in the HTML is tightly coupled with the CSS file no matter what you do.
I think tables vs divs comes down to the needs of your application.
In the application we develop at work, we needed a page layout where the pieces would dynamically size themselves to their content. I spent days trying to get this to work cross-browser with CSS and DIVs and it was a complete nightmare. We switched to tables and it all just worked.
However, we have a very closed audience for our product (we sell a piece of hardware with a web interface) and accessibility issues are not a concern for us. I don't know why screen readers can't deal with tables well, but I guess if that's the way it is then developers have to handle it.
CSS/DIV - it's just jobs for the design boys, isn't it. The hundreds of hours I've spent debugging DIV/CSS issues, searching the Internet to get some part of markup working with an obscure browser - it drives me mad. You make one little change and the whole layout goes horrendously wrong - where on eath is the logic in that. Spending hours moving something 3 pixels this way then something else 2 pixels the other to get them all to line up. This just seems plain wrong to me somehow. Just because you're a purist and something is "not the right thing to do" doesn't mean you should make use of it to the nth degree and under all circumstances, especially if it makes your life 1000 times easier.
So I've finally decided, purely on commercial grounds, although I keep use to minimum, if I anticipate 20 hours work to get a DIV placed correctly, I'll stick in a table. It's wrong, it upsets the purists, but in most cases it costs less time and is cheaper to manage. I can then concentrate on getting the application working as the customer wants, rather than pleasing the purists. They do pay the bills after all and my argument to a manager enforcing the use of CSS/DIV - I would merely point out the customers pay his salary as well!
The only reason all these CSS/DIV arguments occur is because of the shortcoming of CSS in the first place and because the browsers aren't compatible with each other and if they were, half the web designers in the world would be out of a job.
When you design a windows form you don't try moving controls around after you have laid them out so I kind of think it's strange to me why you would you want to do this with a web form. I simply can't understand this logic. Get the layout right to start with and what's the problem. I think it's because designers like to flirt with creativity, whilst application developers are more concerned with actually getting the application working, creating business objects, implementing business rules, working out how bits of customer data relates to each other, ensuring the thing meets the customers requirements - you know - like the real world stuff.
Don't get me wrong, both arguments are valid, but please don't critise developers for choosing an easier, more logical approach to designing forms. We often have more important things to worry about than the correct semantics of using a table over a div.
Case in point - based on this discussion I converted a few existing tds and trs to divs. 45 minutes messing about with it trying to get everything to line up next to each other and I gave up. TDs back in 10 seconds later - works - straight away - on all browsers, nothing more to do. Please try to make me understand - what possible justification do you have for wanting me to do it any other way!
Layout should be easy. The fact that there are articles written on how to achieve a dynamic three column layout with header and footer in CSS shows that it is a poor layout system. Of course you can get it to work, but there are literally hundreds of articles online about how to do it. There are pretty much no such articles for a similar layout with tables because it's patently obvious. No matter what you say against tables and in favor of CSS, this one fact undoes it all: a basic three column layout in CSS is often called "The Holy Grail".
If that doesn't make you say "WTF" then you really need to put down the kool-aid now.
I love CSS. It offers amazing styling options and some cool positioning tools, but as a layout engine it is deficient. There needs to be some type of dynamic grid positioning system. A straightforward way to align boxes on multiple axis without knowing their sizes first. I don't give a damn if you call it <table> or <gridlayout> or whatever, but this is a basic layout feature that is missing from CSS.
The larger problem is that by not admitting there are missing features, the CSS zealots have been holding CSS back from all it could be. I'd be perfectly happy to stop using tables if CSS provided decent multi-axis grid positioning like basically every other layout engine in the world. (You do realize this problem has already been solved many times in many languages by everyone except the W3C, right? And nobody else denied that such a feature was useful.)
Sigh. Enough venting. Go ahead and stick your head back in the sand.
According to 508 compliance (for screen readers for visually impared), tables should only be used to hold data and not for layout as it causes the screen readers to freak out. Or so I've been told.
If you assign names to each of the divs, you can skin them all together using CSS as well. They're just a bit more of a pain to get to sit the way you need them to.
Here's a section of html from a recent project:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>{DYNAMIC(TITLE)}</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
<div id="header">
<h1><!-- Page title --></h1>
<ol id="navigation">
<!-- Navigation items -->
</ol>
<div class="clearfix"></div>
</div>
<div id="sidebar">
<!-- Sidebar content -->
</div>
<!-- Page content -->
<p id="footer"><!-- Footer content --></p>
</body>
</html>
And here's that same code as a table based layout.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>{DYNAMIC(TITLE)}</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
<table cellspacing="0">
<tr>
<td><!-- Page Title --></td>
<td>
<table>
<tr>
<td>Navitem</td>
<td>Navitem</td>
</tr>
</table>
</td>
</tr>
</table>
<table>
<tr>
<td><!-- Page content --></td>
<td><!-- Sidebar content --></td>
</tr>
<tr>
<td colspan="2">Footer</td>
</tr>
</table>
</body>
</html>
The only cleanliness I see in that table based layout is the fact that I'm overzealous with my indentation. I'm sure that the content section would have a further two embedded tables.
Another thing to think about: filesizes. I've found that table-based layouts are twice the size of their CSS counterparts usually. On our hig-speed broadband that isn't a huge issue but it is on those with dial up modems.
I'd like to add that div-based layouts are easer to mantain, evolve, and refactor. Just some changes in the CSS to reorder elements and it is done. From my experience, redesign a layout that uses tables is a nightmare (more if there are nested tables).
Your code also has a meaning from a semantic point of view.
No arguments in DIVs favour from me.
I'd say : If the shoe fits, wear it.
It's worth noting that it's difficult if not impossible to find a good DIV+CSS method of rendering contents in two or three columns, that is consistent on all browsers, and still looks just the way I intended.
This tips the balance a bit towards tables in most of my layouts, and altough I feel guilty of using them (dunny why, people just say it's bad so I try to listen to them), in the end , the pragmatic view is it's just easier and faster for me to use TABLEs. I'm not being payed by the hour, so tables are cheaper for me.
CSS layouts are generally much better for accessibility, provided the content comes in a natural order and makes sense without a stylesheet. And it's not just screen readers that struggle with table-based layouts: they also make it much harder for mobile browsers to render a page properly.
Also, with a div-based layout you can very easily do cool things with a print stylesheet such as excluding headers, footers and navigation from printed pages - I think it would be impossible, or at least much more difficult, to do that with a table-based layout.
If you're doubting that separation of content from layout is easier with divs than with tables, take a look at the div-based HTML at CSS Zen Garden, see how changing the stylesheets can drastically change the layout, and think about whether you could achieve the same variety of layouts if the HTML was table based... If you're doing a table-based layout, you're unlikely to be using CSS to control all the spacing and padding in the cells (if you were, you'd almost certainly find it easier to use floating divs etc. in the first place). Without using CSS to control all that, and because of the fact that tables specify the left-to-right and top-to bottom order of things in the HTML, tables tend to mean that your layout becomes very much fixed in the HTML.
Realistically I think it's very hard to completely change the layout of a div-and-CSS-based design without changing the divs a bit. However, with a div-and-CSS-based layout it's much easier to tweak things like the spacing between various blocks, and their relative sizes.
The fact that this is a hotly debated question is a testament to the failure of the W3C to anticipate the diversity of layout designs which would be attempted. Using divs+css for semantically-friendly layout is a great concept, but the details of implementation are so flawed that they actually limit creative freedom.
I attempted to switch one of our company's sites from tables to divs, and it was such a headache that I totally scrapped the hours of work I had poured into it and went back to tables. Trying to wrestle with my divs in order to gain control of vertical alignment has cursed me with major psychological issues that I will never shake as long as this debate rages on.
The fact that people must frequently come up with complex and ugly workarounds to accomplish simple design goals (such as vertical alignment) strongly suggests that the rules are not nearly flexible enough. If the specs ARE sufficient, then why do high-profile sites (like SO) find it necessary to bend the rules using tables and other workarounds?
I guess it's true that using the table element for layout has little to do with tabular data. So what? Does my boss care? Do my users care?
Google and other automated systems do care, and they're just as important in many situations. Semantic code is easier for a non-intelligent system to parse and process.
Having had to work with a website that involved 6 layers of nested tables generated by some application, and having had it generate invalid HTML, it was in fact a 3 hour job to rectify it breaking for a minor change.
This is of course the edge case, but table based design is unmaintainable. If you use css, you separate the style out so when fixing the HTML you have less to worry about breaking.
Also, try this with JavaScript. Move a single table cell from one place to another place in another table. Rather complicated to perform where div/span would just work copy-paste-wise.
"Does my boss care"
If I were your boss. You would care. ;) If you value your life.
Layout flexibility
Imagine you're making a page with a large number of thumbnails.
DIVs:
If you put each thumbnail in a DIV, floated left, maybe 10 of them fit on a row. Make the window narrower, and BAM - it's 6 on a row, or 2, or however many fit.
TABLE:
You have to explicitly say how many cells are in a row. If the window is too narrow, the user has to scroll horizontally.
Maintainability
Same situation as above. Now you want to add three thumbnails to the third row.
DIVs:
Add them in. The layout will automatically adjust.
TABLE:
Paste the new cells into the third row. Oops! Now there are too many items there. Cut some from that row and put them on the fourth row. Now there are too many items there. Cut some from that row... (etc)
(Of course, if you're generating the rows and cells with server-side scripting, this probably won't be an issue.)
I think that boat has sailed. If you look at the direction the industry has taken you will notice that CSS and Open Standards are the winners of that discussion. Which in turn means for most html work, with the exception of forms, the designers will use divs instead of tables. I have a hard time with that because I am not a CSS guru but thats the way it is.
Also, don't forget, tables don't quite render well on mobile browsers. Sure, the iPhone has a kick-ass browser but everyone doesn't have an iPhone. Table rendering can be peanuts for modern browsers, but it's a bunch of watermelons for mobile browsers.
I have personally found that many people use too many <div> tags, but in moderation, it can be extremely clean and easy to read. You mention that folks have a harder time reading CSS than tables; in terms of 'code' that maybe true; but in terms of reading content (view > source) it is a heck of a lot easier to understand the structure with stylesheets than with tables.
Looks like you are just used to tables and that's it.
Putting layout in a table limits you for just that layout. With CSS you can move bits around, take a look at http://csszengarden.com/
And no, layout does not usally require a lot of nested divs.
With no tables for layout and proper semantics HTML is much cleaner, hence easier to read.
Why should someone who cannot understand CSS try to read it? And if someone considers himself to be webdeveloper then the good grasp of CSS is a must.
SEO benefits come from the ability to have most important content higher up the page and
having better content-to-markup ratio.
http://www.hotdesign.com/seybold/
508 Compliance - the ability for a screenreader to make sense of your markup.
Waiting for render - tables don't render in the browser until it gets to the end of the </table> element.
The whole idea around semantic markup is the separation of markup and presentation, which includes layout.
Div's aren't replacing tables, they have their own use in separating content into blocks of related content (, ). When you don't have the skills and are relying on tables, you'll often have to separate your content in to cells in order to get the desired layout, but you wont need to touch the markup to achieve presentation when using semantic markup. This is really important when the markup is being generated rather than static pages.
Developers need to stop providing markup that implies layout so that those of us who do have the skills to present content can get on with our jobs, and developers don't have to come back to their code to make changes when presentation needs change.
This isn't really about whether 'divs are better than tables for layout'. Someone who understands CSS can duplicate any design using 'layout tables' pretty straightforwardly. The real win is using HTML elements for what they are there for. The reason you would not use tables for non-tablular data is the same reason you don't store integers as character strings - technology works much more easily when you use it for the purpose for which it is desgined. If it was ever necessary to use tables for layout (because of browser shortcomings in the early 1990s) it certainly isn't now.
Tools that use table layouts can become extraordinarily heavy due to the amount of code required to create the layout. SAP's Netweaver Portal by default uses TABLE to layout their pages.
The production SAP portal at my current gig has a home page whose HTML weighs over 60K and goes seven tables deep, three times within the page. Add in the Javascript, the misuse of 16 iframes with similar table issues inside of them, overly heavy CSS etc, and the page weighs over 5MB.
Taking the time to lower the page weight so you can use your bandwidth to do engaging activities with users is worth the effort.
It's worth figuring out CSS and divs so the central content column loads and renders before the sidebar in a page layout. But if you are struggling to use floating divs to vertically align a logo with some sponsorship text, just use the table and move on with life. The Zen garden religion just doesn't give much bang for the buck.
The idea of separating content from presentation is to partition the application so different kinds of work affect different blocks of code. This is actually about change management. But coding standards can only examine the present state of code in a superficial manner.
The change log for an application that depends on coding standards to "separate content from presentation" will show a pattern of parallel changes across vertical silos. If a change to "content" is always accompanied by a change to "presentation", how successful is the partitioning?
If you really want to partition your code productively, use Subversion and review your change logs. Then use the simplest coding techniques -- divs, tables, JavaScript, includes, functions, objects, continuations, whatever -- to structure the application so that the changes fit in a simple and comfortable manner.
Because it's HELL to maintain a site that uses tables, and takes a LOT longer to code. If you're scared of floating divs, go take a course in them. They're not difficult to understand and they're approximately 100 times more efficient and a million times less a pain in the ass (unless you don't understand them -- but hey, welcome to the world of computers).
Anyone considering doing their layout with a table better not expect me to maintain it. It's the most ass-backwards way to render a website. Thank god we have a much better alternative now. I would NEVER go back.
It's scary that some folks might not be aware of the time and energy benefits from creating a site using modern tools.
Tables are not in general easier or more maintainable than CSS. However, there are a few specific layout-problems where tables are indeed the simplest and most flexible solution.
CSS is clearly preferable in cases where presentational markup and CSS support the same kind of design, no one in their right mind would argue that font-tags are better than specifying typography in CSS, since CSS gives you the same power than font-tags, but in a much cleaner way.
The issue with tables, however, is basically that the table-layout model in CSS is not supported in Microsoft Internet Explorer. Tables and CSS are therefore not equivalent in power. The missing part is the grid-like behavior of tables, where the edges of cells align both vertically and horizontally, while cells still expand to contain their content. This behavior is not easy to achieve in pure CSS without hardcoding some dimensions, which makes the design rigid and brittle (as long as we have to support Internet Explorer - in other browsers this is easliy achieved by using display:table-cell).
So it's not really a question of whether tables or CSS is preferable, but it is a question of recognizing the specific cases where use of tables may make the layout more flexible.
The most important reason for not using tables is accessibility. The Web Content Accessibility Guidelines http://www.w3.org/TR/WCAG10/ advice againt using tables for layout. If you are concerned about accessibility (and in some cases you may be legally obliged to), you should use CSS even if tables are simpler. Note that you can always create the same layout with CSS as with tables, it might just require more work.
I was surprised to see some issues were not already covered, so here are my 2 cents, in addition to all the very valid points made earlier:
.1. CSS & SEO:
a) CSS used to have a very significant impact on SEO by allowing to position the content in the page wherever you want. A few years ago, Search Engines were giving a significant emphasis to "on-page" factors. Something at the top of the page was deemed more relevant to the page than something located at the bottom. "Top of the page" for a spider meant "at the beginning of the code". Using CSS, you could organize your keyword-rich content at the beginning of the code, and still position it wherever you liked in the page. This is still somewhat relevant, but on page factors are less and less important for page ranking.
b) When the layout is moved over to CSS, the HTML page is lighter and therefore loads faster for a search engine spider. (spiders don't bother downloading external css files). Fast loading pages is an important ranking consideration for several search engines, including Google
c) SEO work often requires testing and changing things, which is much more convenient with a CSS based layout
.2. Generated content:
A table is considerably easier to generate programmically than the equivalent CSS layout.
foreach ($comment as $key=>$value)
{
echo "<tr><td>$key</td><td>$value</td></tr>";
}
Generating a table is simple and safe. It is self-contained and integrates well within any template. To do the same with CSS is considerably harder and may be of no benefit at all: hard to edit the CSS stylesheet on the flight, and adding the style inline is no different from using a table (content is not separated from layout).
Further, when a table is generated, the content (in variables) is already separated from the layout (in code), making it as easy to modify.
This is one reason why some very well designed websites (SO for instance) still use table layouts.
Of course, if the results need to be acted upon through JavaScript, divs are worth the trouble.
.3. Quick conversion testing
When figuring out what works for a specific audience, it is useful to be able to change the layout in various ways to figure out what gets the best results. A CSS based layout makes things considerably easier
.4. Different solutions for different problems
Layout tables are usually dissed because "everybody knows divs & CSS" are the way to go.
However the fact remains that tables are faster to create, easier to understand and are more robust than most CSS layouts. (Yes, CSS can be as robust, but a quick look through the net on different browsers and screen resolutions shows it's not often the case)
There are a lot of downsides to tables, including maintenance, lack of flexibility... but let's not throw the baby with the bath water. There are plenty of professional uses for a solution which is both quick and reliable.
Some time ago, I had to rewrite a clean and simple CSS layout using tables because a significant portion of the users would be using an older version of IE with really bad support for CSS
I, for one, am sick and tired of the knee-jerk reaction "Oh noes! Tables for layout!"
As for the "it wasn't intended for that purpose and therefore you shouldn't use it this way" crowd, isn't that hypocrisy? What do you think of all the CSS tricks you have to use to get the darn thing working in most browsers? Were they meant for that purpose?