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.
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. 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?
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. Layout flexibility Imagine you're making a page with a large number of thumbnails. Make the window narrower, and BAM - it's 6 on a row, or 2, or however many fit. 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. Now there are too many items there. Cut some from that row and put them on the fourth row.
Cut some from that row 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. Looks like you are just used to tables and that's it.
Putting layout in a table limits you for just that layout. 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.
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 s 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.
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. If you're scared of floating divs, go take a course in them.
They're not difficult to understand and they're approximately 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.
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. 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:. 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.
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. Fast loading pages is an important ranking consideration for several search engines, including Google. 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. 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. 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 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. 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? Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams?
Collectives on Stack Overflow. Learn more. Why not use tables for layout in HTML? Asked 13 years, 1 month ago. Active 3 years ago. Viewed k times. Agreed, tables are fine when presenting tabular data. They should be avoided when using it purely for layout. Then again, sometimes, you have to take the easy road now and improve it later. Just view source and you'll see what I mean.
There is a duplicate Q and A at stackoverflow. The answer is simple: it depends. If tables are used to solve a specific problem that current CSS versions can't, they are well used. If you start getting tables inside tables, inside millions of tables then you're doing it wrong.
If it's the ocasional table just to layout some 2 columns or something like that, I don't disallow it on my team: it's faster and easier to do it. Camilo SO still lives in the 20th century. Jeff apparently does not know how to use the ul tag. Have a look at all of the lists on this site badges, related questions, recent tags. They're all either single columns or long paragraphs separated with br.
Two parts of a document that happen to be laid out alongside each other can legitimately be contained in DIV elements, but they're certainly NOT tabular data. It doesn't matter what one specific styling happens to be; the content is either tabular or not. Active Oldest Votes. I'm going to go through your arguments one after another and try to show the errors in them. 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.
It's so easy to resolve with master pages or user controls in. Sorry but this is really "pie int he sky" wishful thinking. Users care? Noone cares except a small number of misguided revisionists.
HTML including tables is far older than the relatively new notion of "semantics vs layout". Oh and source please for "the majority of professional web developers oppose you". Typo above: semantics were implied from the beginning. Even more: the very first proposal of HTML repeatedly warns against abusing tags to influence the layout, and cautions to use logical over physical markup.
Get a screen reader and have it read a page with a table layout. Sergio: please do not edit out relevant information. Show 7 more comments. Here's my programmer's answer from a simliar thread Semantics First take a look at this code and think about what's wrong here Semantics Now apply this to document markup.
Conclusion Will visitors notice? Sorry, that doesn't hold water. You don't use car for mybike because you would define a "bike" class instead. Nice analogy, and great conclusion. Doesn't anyone take pride in their own work any more? I think this is quite an arrogant post which doesn't explain anything but just repeats the same claims again without answering the question.
It is therefore no wonder that the creators of HTML provided a means by which to structure and present tabular data on the web. The point of a table is that it is rigid. Information is easily interpreted by making visual associations between row and column headers.
Look at the table below for example and find a Jovian gas giant with 62 moons. You can find the answer by associating the relevant row and column headers. When implemented correctly, HTML tables are handled well by accessibility tools such as screen readers, so a successful HTML table should enhance the experience of sighted and visually impaired users alike.
You can also have a look at the live example on GitHub! One thing you'll notice is that the table does look a bit more readable there — this is because the table you see above on this page has minimal styling, whereas the GitHub version has more significant CSS applied. Be under no illusion; for tables to be effective on the web, you need to provide some styling information with CSS , as well as good solid structure with HTML.
In this module we are focusing on the HTML part; to find out about the CSS part you should visit our Styling tables article after you've finished here. We won't focus on CSS in this module, but we have provided a minimal CSS stylesheet for you to use that will make your tables more readable than the default you get without any styling. You can find the stylesheet here , and you can also find an HTML template that applies the stylesheet — these together will give you a good starting point for experimenting with HTML tables.
HTML tables should be used for tabular data — this is what they are designed for. Unfortunately, a lot of people used to use HTML tables to lay out web pages, e. This was commonly used because CSS support across browsers used to be terrible; table layouts are much less common nowadays, but you might still see them in some corners of the web.
In short, using tables for layout rather than CSS layout techniques is a bad idea. The main reasons are as follows:. We've talked table theory enough, so, let's dive into a practical example and build up a simple table. As you will see, the cells are not placed underneath each other, rather they are automatically aligned with each other on the same row. Every cell we add makes the row grow longer.
Let's investigate this now. Note: You can also find this on GitHub as simple-table. Now let's turn our attention to table headers — special cells that go at the start of a row or column and define the type of data that row or column contains as an example, see the "Person" and "Age" cells in the first example shown in this article.
To illustrate why they are useful, have a look at the following table example. First the source code:. The problem here is that, while you can kind of make out what's going on, it is not as easy to cross reference data as it could be. If the column and row headings stood out in some way, it would be much better. You may find it hard to believe, but for a straightforward data table, you probably do not need any ARIA. Screen readers in particular have been dealing with tables for far longer than the existence of ARIA.
Sometimes a table is just a grid of data and sometimes a table is a control widget that users modify or modify its data, such as a spreadsheet. ARIA has a few roles that define and describe data grids. The definitions that follow come from ARIA 1. Please note that those roles are primarily intended to be used for interactive grids, such as a spreadsheet.
In these controls each cell may be editable and can be navigated using a series of keyboard shortcuts. Since developers were applying grid roles to what should be regular tabular data, ARIA 1. See related grid. The table role is intended for tabular containers which are not interactive. If the tabular container maintains a selection state, provides its own two-dimensional navigation, or allows the user to rearrange or otherwise manipulate its contents or the display thereof, authors SHOULD use grid or treegrid instead.
Putting all the ARIA roles into practice and understanding which to use can be tricky. You also need to implement all the keyboard support above and more. There is a placeholder in the ARIA Authoring Practices document for tables, though it points back to the grid pattern and the following decision flow for choosing between a table and a grid:.
To restate: a grid is a single tab stop on the page which then manages focus within , while a table is not. Here are a couple methods you can use. To reiterate, I am just talking about width responsiveness. I have another post coming that goes into more detail.
Yep, you can just let a table scroll off the screen within a bounded container. The catch is that you need to make the scrolling area keyboard accessible, but we already know a solution for that. I made a sample table in a scrolling container.
I have embedded it below or you can go directly to it at CodePen. I show how this keyboard-friendly technique can be used in individual cells as well in an old post. For some tables you can just use CSS to re-arrange the entire thing. Between CSS flex and CSS grid, we have more options than ever to make responsive tables that can adapt to nearly any screen regardless of your data. I will go into more detail on that in my next post. Instead it relies on the lowly CSS display: block.
0コメント