It does look a more valid application of the HTML table tag than the screen shots above do. even so, I’m wondering whether other methods may be preferred.
The default for most block elements is for overflow to be visible. That means that if you had a box that was 500px wide and inside it you put a box that was 600px wide you would then see 100px of the box sticking outside of its parent. That means that its overflow was visible although it would not take part in the flow of the document.
If you then set that parent box to be overflow:hidden then the 100px bit that was sticking out would be gone. the element would be clipped inside the box.
If you then changed hidden to auto a scrollbar would appear on the bottom of the parent allowing you to scroll horizontally to see the full width of the child element.
The point I was making about visible overflow is that in some cases you may have tooltips or dropdown menus that need to be visible even when they stretch out of the parent container and if you used overflow:hidden as the float containing mechanism then you would cut off that type of content.
Tables are only to be used for proper tabular data and never for layout as we have more semantic ways of laying out pages these days. Html is all about semantics and structure and you use the right element for the task in hand.
e.g. heading tags for headings (in logical order of course), p tags for paragraphs or phrases of text, ul for unordered list, ol for ordered list, table for tabular data … and so on.
There is always a right tag to use for the job in hand.
Historically before css was around we abused tables so that we could make layouts but it was never semantic and never meant for that purpose (hence all the spacer gifs of old).
It took some time for everyone to come around to that way of thinking but virtually no one these days use tables for layout and if they do they are sorely misguided. Some current designers have never used table for this purpose and could not work out how to make layouts with them as they are in fact harder to mould than css.
If you want table behavior then you can use (ie8+) the css display:table and table-cell properties (applied to divs etc) which will allow some of the behavior of tables without implying any semantics on the content.
The only time you use tables is when you have tabular data and then the table element is the most semantic to use. It is very obvious when data is tabular (think spreadsheet) so you rarely have to give it a second thought when to use a table.
As far as laying out pages with css then I can assure you that it is a much shorter learning curve than trying to learn how to do it with a table from scratch. The problem is that when you come from a table background then everything looks like a table.
3 Likes
That is indeed my problem. I’ve been building tabled pages since the mid 90’s. My Geocities page was the bees knees, replete with blinks and really cool mailbox gifs. It seems I’m the guy yelling at divs to get off my lawn.
Back to the task at hand. As per instruction, I’ve swapped single for double quotes, I’ve fixed the deets container, set some padding and have added the social and tool buttons. I’ve updated the test page to reflect the new stuff:
The only errors on the page are being generated by the included ShareThis code being included for social buttons. I’ll probably need to write my own share functions to be in control of this.
I need to replace the tables around the social to tool buttons with divs to completely drop the tables from that page, but while I’m doing that, I wanted to know if you guys think that the structure of this page is sufficient for tablets to PC. It looks identical on MobileMe for tablets, but so far there’s been a lot that looked that way but was still horribly written.
A couple of weeks ago, you said that you wanted the menu fluid down to about 480px. We did that. This page, however can’t begin to narrow down to 480px. It’s closer to 800px wide with ads. I’m a bit puzzled about how you expect the end product to be framed? Without more planning and design work, you are not far from being a full desktop sized site.
I had tried to explain this above, but apparently didn’t do a good job of it.
The menu sits above every page on the site, and I hope to use it across all devices. For that reason, my hope is that the menu will scale completely.
The page I’m working on here can have a different template called for PCs, tablets and phones. As an example, my intention is to not have a rightSkyscraper for phones. If the width is too wide for a tablet, I’d get rid of it for that device as well.
I want to be able to maximize the desktop user’s experience, rather than strip it down to fit other devices.
I would love this particular design to work on a tablet in portrait as well and my limited testing makes it look like it is. Do you feel that it fails as a page intended to work with tablets? ( I know there are tons of devices with different specs), so this likely isn’t a yes/no question).
You probably did a fine job of explaining your intent and I didn’t remember it. At first glance, it sounded like the antitheses of responsive design, so I blanked it out. Sorry.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.