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 12 years ago.
Is it just because some people think they are harder to read? I find it much easier to explain a layout to somebody by drawing a grid than by using floating divs. And if they are learning to code floating divs then they have to deal with the setting widths and using CSS clear.
(by the way, I don't use tables myself)
They violate semantics of what a table is. Tables should be used for tabular data. They also are quite heavy on markup. In addition, they lock your site into one structure to a specific grid.
Tables are for storing tabular data. Content is not tabular data.
It's mostly a matter of separation of concerns - your HTML should be marking up your content, not decide on what the UI will look like and be layed-out, which is the concern of CSS.
Tables should be reserved for tabular data.
Its mainly a hype. Tables are an acceptable way and often more logically way of separating a view into multiple sections. However CSS is more dynamic, if you go with tables you're often stuck with them especially since tables are often placed in between 'the data' while css is defined externally. Also changing a 'table-like' layout made in css is easier than changing a table made layout.
On the internet there are a couple of good resources about this question:
http://www.decloak.com/dev/csstables/css_tables_01.aspx
http://iamelgringo.blogspot.com/2009/02/tables-vs-css-css-trolls-begone.html
As you can see it's also often a semantics thing. Semantically a table is not ment for layouts, (however it sure is handy and these kind of distinctions are more for purists).
This is taken from another site, but still just as relevant:
Tables are usually more bytes of markup. (Longer to download, and more
bytes of traffic for the host.)
Tables usually prevent incremental rendering. (Takes longer
for the user to see anything on the
page.)
Tables may require you to chop single, logical images into multiple
ones. (This makes redesigns total
hell, and also increases page load
time [more http requests and more
total bytes].)
Tables break text copying on some browsers. (That's annoying to the
user.)
Tables prevent certain layouts from working within them (like
height:100% for child elements of
). (They limit what you can
actually do in terms of layout.)
Once you know CSS, table-based layouts usually take more time to
implement. (A little effort up-front
learning CSS pays off heavily in the
end.)
Tables are semantically incorrect markup for layout. (They
describe the presentation, not the
content.)
Tables make life hell for those using screen readers. (Not only do you
get the other benefits of CSS, you're
also helping out the
blind/partially-sighted. This is a
Good Thing.)
Tables lock you into the current design and make redesigns MUCH harder
than semantic HTML+CSS. (Have you seen
CSS Zen Garden?)
SAUCE: http://phrogz.net/css/WhyTablesAreBadForLayout.html
Not every browser displays them the same way... should only be for tabular data, not content
Related
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 10 years ago.
I'm working on a template, and I know using CSS is better than using HTML tables for positioning... But, is it acceptable to get the best of both worlds and use table-like styles on my divs? For example:
display: table;
This would not only help me solve the sticky footer problem, but I could avoid the pains associated with floats as well. Not sure if this would be considered an ugly hack or an eloquent solution. Thoughts?
I personally see nothing wrong with using display: table. I would not recommend widespread use of it, but sometimes it can be very useful for making something display the way you want without having to add a bunch of extra HTML or deal with an onerous set off CSS rules to get something to look the way you want it to.
If it works for the client browsers you are targeting in your development and can save you pain or complexity in other areas, than feel free to use it.
Ugly hack... You can deal with floats using the clearfix method and there are tons of sticky footer techniques ( like this one ) to use.
Also the display: table not supported in IE7 and below if that's a concern.
You should go forward and use the newer more semantic elements for your layout - header, section, footer etc. and resort to table-s when you want to present some tabular data only.
There is no reason to fear or loathe display: table. Yes, the value is table, but it is fair game and entirely valid CSS 2.1.
Tables are "bad" in markup, because they were abused and applied in a way that did not reflect their intended semantic purpose, which is to present tabular data. If you have tabular data, not using tables would be just as big a sin as using tables for layout.
Let's return to the topic though. Support for display: table is a bit flaky in IE < 8 and non-existent in Android < 2.1 and iOS < 3.2. If you need to support those, rather use float.
The simplest use of this property is to apply display: table to the parent element, display: table-row to the children and display: table-cell to the grand-children. If you deviate from this at any level, the results can get a bit weird. (I have personal experience with this.) Take a look at the W3C specification for the CSS table model if you get stuck.
Sources:
http://caniuse.com/css-table
http://www.w3.org/TR/CSS21/tables.html#table-display
It depends. While CSS divs are the best solution for anything in HTML (except when you need IE6 support...), and tables (in terms of markup) are becoming an ancient technology, on the one hand it is possible to come up with the most handicapped and stupid solution on CSS ever made, and on the other hand you can create an HTML masterpiece without a single div.
So if you think you're good enough in CSS, use it. If you're not sure, or you're a real tables master, tables should do the work.
I've personally never used display: table, but this link seems to be pretty well versed on the syntax.
http://www.onenaught.com/posts/201/use-css-displaytable-for-layout
I typically stick to floats and after reading this, might give display: table a chance. When I use floats, I have to follow it up with some sort of clear: both div. display: table seems to be a more efficient and acceptable solution to that problem.
As mentioned tables work great for tabular data. I also like to use tables at times when you are getting a lot of dynamic data back. For template development, I would stick with CSS.
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.
I'm updating a lot of code for a web app and tables are used everywhere to control layout.
I'm relatively new to HTML programming and am not sure what to make of the use of tables where CSS could seemingly be used. Is this just from a time now gone?
Bottomline, is the latest iteration of CSS and browser support acceptable enough to consider styling using tables antiquated?
In my opinion, the CSS is much easier to use.
It's a bit subjective, I know, but I think a consensus can be reached.
Use tables for tables. CSS for everything else.
The guy who first thought of using tables for layout wrote an article in 1997 stating, "The Web is Ruined and I Ruined It". There are countless similar articles, such as "Tables for Layout is Stupid" and the like. CSS has been around for that long and no developer worth his salt would not use it to layout his web pages. We're on the 3rd iteration of it and CSS itself is used to style tables by default in the browsers themselves.
At best, tables are a predefined, immovable grid of boxes you must fit your design into. Compare that to CSS which has limitless flexibility and reasoning for tables for layout flies out the window.
Do not use tables for layout. Use CSS. Nothing else to discuss.
This seems like a pretty subjective question, but basically the answer is that if the data lends itself to a table, put it in a table element. You can still style the tables with CSS, the HTML should describe the data whereas the CSS styles it.
If you have a table of data, don't make a "fake" table using divs/spans and make it look like a table. Put it in a table and style as appropriate.
If tables are being used for tricks like a 2-column layout, where there is no tabular data...yes that way of styling is obsolete and depreciated.
Keep in my though, I don't believe its a horrible "sin" to use tables for styling if it saves time, makes cross-browser compatibility easier, and looks fine. Remember, the only one (usually) reading your markup is the browser. If its going to take hours to rip out all the tables for the exact same end result, you might want to question if its worth the time/effort. On the other hand, when starting from scratch, you may as well learn the modern methods and create some maintainable markup.
Tables aren't going anywhere, it's in the HTML5 spec for a reason. You shouldn't use a table to style your website, but if you have some tabular data, then put it in a <table>. Just as you would put a paragraph into a <p>, a list of items into a <ul>, or a header into a <h1>.
People are so rash in their judgement of tables because they were used for evil for so long. I can use a bunch of <div> containers and a crap load of CSS to mimic an unordered-list, or just use semantic markup.
So, the lesson to be taken from this is, use tables for tabular data, and NEVER for styling. You should also never use things like valign="center" and cellpadding="0" on your table elements, this should be passed onto the responsibility of CSS to style.
P.S. look at Google's code, they're still using tables, and they're one of the main companies who are pushing HTML5.
It's easier (arguably), and has use for email clients. Legacy support is also better for IE 6 and below as well as other older browsers. Other than that, I have yet to see something tables can do that cannot be done with modern CSS. So the short answer is not any more.
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.
I apologise in advance if this question is asked too often, but I've been doing light web development lately and noticed this across many different (and somewhat prominent) webpages.
I see comments (of varying quality) being used in "more traditional" programming languages, but it's very, very uncommon for me to see them utilised in HTML or CSS. (I've seen it more in JavaScript, though.) I can usually figure out what's going on since HTML isn't very complicated, but why is this so?
Thanks!
Perhaps the commented version is kept locally, and minified/gzipped versions are the ones shown to the public. This makes loading times faster than those with the additional commentary.
I think because HTML (and CSS for the most part) is simple markup and rarely contains any complex logic in it (JavaScript maybe). So the markup itself is self-explanatory and requires no additional comments to explain/clarify what it is or what it does.
The pages you look at the internet are just the end products. Bandwidth costs money and noone wants to pay for sending noticies of the inner workings of their site to visitors most ofwhom never takes a look at the page source.
The backend which generates these pages (as most of the web pages are generated) can have comments of course. There are security concerns too, you don't want to give out unnecessary information about the inner workings of your site.
There are sepcialized tools too just to remove unnecessary content from pages (and css) to create smaller files.
I would speculate because HTML is a markup language, and all the content is quite transparent - so not necessary to comment compared with a procedural language where the logic can be complex, and a hint helps you to understand it.
I would also speculate it is because a large portion of the HTML is repetitive between pages and sites, so needs no explanation as it has been seen many times before.
You would not want to end up with this would you :)
<h1>My great site</h1>
<!-- heading level one - 'My great site' -->
Comments are best used to explain tricky bits of a file, and there's not a lot that's tricky about HTML or CSS.
WIth that said, if i'm doing something that works in some specific browser, i'll add a comment about why it's done the way it is. I'll often also use a comment to add notes about bug fixes (especially if there's a ticket for the bug and double-especially if there's a hundred other people working on the CSS as well). But often for HTML, it's almost no effort to turn the HTML comment into a comment in the server-side language, hiding it from the browser completely. So the code could be commented, without you ever knowing it.
I personally don't use them because during web development, comments tend to be personalized, especially ones you would put into HTML. Instead, I put them in PHP in HTML to make them invisible to the source reader.
As for CSS comments, the only time I have those is when I have over 5000 lines of CSS code and need to separate it into sections. Even then, I prefer to make several smaller files which are self-explanatory through file location and file name, rather than use extensive commenting.
I believe HTML and CSS to be simple and descriptive enough for anyone to derive their meaning very fast without help from comments.
CSS, especially, is incredibly self-describing. E.g.
margin: 0;
There’s not a lot to add to that. In CSS, I always try to add comments when the purpose of some code isn’t immediately obvious, e.g.
overflow: hidden; /* Contains descendant floats */
And in HTML, I try to make class names and id values self-describing, like good class, method and variable names in programming languages.
The most important reason for that is as you stated, there is no such a huge need for comments in HTML and CSS.
Secondly, commenting in HTML is very difficult compared to programming languages, putting a <!-- --> mark needs time, whereas // comes from inside.
Quite simply, HTML and CSS don't need as many comments. For the most part, the CSS and HTML you write does exactly what it says. While it is certainly possible to obfuscate HTML and CSS (especially CSS), it does not happen nearly as often as it does with programming languages. In programming, you need comments because the code is not always self-explanatory and you often do strange things for non-obvious reasons.
Commenting in HTML is only needed when you are doing strange things you neeed to explain. Otherwise, it is just as ridiculous as making comments for code that has an obvious behavior, like this:
var i = 3; //Declares a variable called i and assigns its value to 3.
Example of why you might need a comment in HTML:
<td> </td> <!--IE does not display borders on cells without content-->
I would assume that it is
because HTML is not a programming language and you usually do not have to explain why/how something works..
and also because people try to minimize the size of their pages..
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 10 years ago.
I have a beginner's question for web development. I am going to create a table in which I am having input fields which I will submit to the server.
What is the common practice for doing this? Should I use html-tables or should I build the tables using stylesheets for positioning and sizing cells, columns, etc.? If both are common practice, what are the pros and cons of using eithor of those?
If the content is tabular in nature, logically structured in rows and columns, then the appropriate tags - the tags that describe the structure of the content - are table tags.
You will have folks on both side and some will be nicer than others. Essentially, you use tables for tabular data and not to make a layout for your buttons, logos, etc..
On the other hand, I have some old asp Classic code where we used tables everywhere and it still works great.
If I did it today, I'd use "semantically correct" design where I could which means tables for table data (things displayed in row and column) and the css stuff for layouts.
I usually use divs for this purpose. The strict definition would be to use tables only to display semantic content.
You need to plan carefully first what you need in terms of layout, whether sections are going to be similar, whether there is a lot of sharing or not. And the amount of formatted container your foresee.
It naturally occurs to you that if you can centralise the design on some CSS commands, you will benefit from being able to change looks at once as they are all linked to a common source.
If you are going to have several pages, you will be thinking of having the CSS even on a different page and link to it from others.
Also, you need to know that divs and spans work in a different way than other HTML elements. You will not be able to obtain effects that you would have obtained with a table.
In other words, what you need to do is go to the w3 website and read everything about CSS. Expecting to get an answer in 3 lines about such a huge subject will not help you much.
Alvaro
My motto for html/css is:
"Use the right tag for the job". If its a table let it be a table :)
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 10 years ago.
I am looking for some stats on current browsers for how long it takes to render a table using plain HTML versus a hacked-up CSS puritan method that avoids using actual TABLE, TR, TD etc. tags.
I am not looking for what's proper, only for what's faster, particularly on Firefox 3, although I am also interested in the stats for other browsers. Of course TABLE tags are designed for tables. That's not the question.
If you really have tabular data, then use tables. The idea that you should never use tables for anything was a mistaken extension of the correct concept that you should use html tags only for their intended semantic purpose. That means use CSS for layout, but use tables for tabular data. It does not mean never use tables.
In general, I would say use <table> for tabular data. However, if the table is very long (say, over 100 rows) and the number of columns is low (~3), using divs to emulate rows would result in a much smaller markup footprint. This is especially relevant if you are using DOM searching javascript (as provided by the many JS libraries), as it would benefit to reduce the DOM tree size.
This is from experience, I had such a table and was looking for optimizations - moving to a div based display cut the HTML generated to a third and was a big improvement in DOM traversal performance.
Since some browsers wait until the entire table has been transferred to display it in order to make sure they have adjusted the column widths for content size, using divs will probably render faster if you're looking for an average across every browser.
That being said, if you need a table, use a table.
This question looks to be similar to this one:
Why not use tables for layout in HTML? so you might want to check some of the responses there as well.
In general, browsers will not render a table until the entire table has been calculated, which means that from a user perspective a large table is slower than the same content using CSS styling in place of tables. I was working with a web application at one point that was using tables to display a grid of status information, and it was extremely intensive to display and very slow. The same information displayed using CSS was faster and more importantly, started to display line by line as it was loaded, instead of waiting for the entire table, so it felt faster as an end user. I would suggest investigating using CSS to display the data using a sample dataset for testing. This is what I did to confirm that the tables were in fact much slower for the particular use case we had.
If you use CSS for layout and you adhere to best practice and keep your CSS in a separate file(s) then your CSS will typically only need to be downloaded once before it is cached, giving you the benefits of caching.
If you use tables for layout then your layout tables will be sent with the HTML for every page, increasing your bandwidth and download times.
To improve the rendering speed of tables though you could try setting the table-layout:fixed; to see if that helps..
Different browsers have wildly different javascript/css performance, so it's very hard to generalise here. For example, IE7 has a shockingly slow engine, and Chrome's is mind-bogglingly fast. Firefox is somewhere in between, depennding on if you're using 2 or 3.
I would not take rendering speed as the most important aspect here. HTML tables are made for tabular data. Putting that into a lot of DIVs or so would be totally wrong in my understanding.
Like most of the above answers, I too would say use Tables if you are displaying tabular data and DIVs if you want to control layout (using CSS3). Contrary to belief, tables are not slower in rendering than DIVs if you set a few properties like colgroup and keep layout as fixed. Check out the details of how to in the following link:
sites.google.com/site/spyderhoodcommunity/xhtml/makingtablesrenderfasterwhenlistingtabulardata
For tabular data, use a table. Tables come with all kinds of nice features, like <thead> and <tfoot> tags, legends, titles, captions, etc. Everything you need to make a table a table.
Also, if the CSS doesn't work/isn't loaded/doesn't matter, the table will still look and work the way it should.
Personally from what I have read, if you are actually presenting tabular data, a table is more appropriate for the task, I personally hae found that to be pretty true.
As for raw number of what is "faster", as mentioned by #skaffman it depends on the browsers...but to be "correct" it would make sense to use a table for tabular data.