Forum Moderators: open
I've had it driven into me for so long now that 'tables are for displaying data', and not to be used to format your page any more, and the way forward is forever CSS.
I've tried my best to stick with CSS, but I've always found it a massive pain in the ass compared to simply using tables. The text is still readble on a page, the links still work, what's the big deal?
In short, I'm thinking of making life a lot easier by simply reverting to tables for formatting, with a little CSS to tweak it. Is this really such a crime?
I agree with all of the above. However, I would like to note - since the topic of server-side programming was brought up in the footnotes - that by using server-side includes to piece together pages (as I have described in a few other threads) a table layout can be made just as, if not more, maintainable than a CSS Div layout. I say more maintainable because as it currently stands CSS layouts are much harder to setup because of all the hacks involved - this will change with time of course. So - providing you have server-side programming - the only thing that CSS really has over tables is its correct semantics (which I never found to be a convincing argument by itself).
I'm speaking only from my personal experience as I don't know the type of environment you work in, but that quote above would make my job, and others around me, a living hell. I'm starting to think that all of your comments are derived from working on small micro-sites, where as in my case, sometimes we're 20 or 25 people working on the same project.
Skipping past what the conception department comes up with and what the Architects have planned out, all the programmers are given either a module or a section of a page to develop. They have absolutely no interest in how it will look in the end, simply that it works as per the specs.
The integrators are then supplied with straight no nonsense markup to work with. If it weren't for the standards/semantics, their job would be impossible to do. They have no control over what the scripts are rendering. If they were expected to make anything other than tabular data work inside a table, the back and forth between the integrators and programmers would drive everyone mad.
It's only logical to have the data/content/information be laid out properly (read: correctly) and use the intended CSS to do what it's meant to do.
No one will ever convince me that using tables for structure is either acceptable nor profitable.
I can only agree with that as long as you only work with table layouts. I have made up some CSS layouts (which, by the way, work even in IE6) that wouldn't be possible throught tables nor, fot that matter, any other markup construct.
There are certainly structures which can only be achieved with CSS. Personally - I am a fan of Hybrids. You get the structure of tables with the flexibility of CSS Divs. They offer you far more options in terms of layout VS just tables or just divs. And there maybe places where it is just plain extra work to use a table - and I'm not suggesting that they be used in those cases. But tables are flat out better at grid layouts - like if you need a horizontal row with multiple columns that all expand to the same height that have dynamically created content.
I can understand that. The only issue is that people stick with what doesn't work. It may also depend on each site's topics and audience, and most often there is quite a paradox here: users don't expect online shops to give them security instructions, but visitors to these kind of sites should take more measures to protect their security, since they are most likely transferring sensitive data to the site (payment details).
You seem quite sure about that, despite it doesn't match any real pattern: there hasn't been any browser version that lasted 10 years; but you are stating IE 6 will last at least 15 :o. Counting from the date when IE8 is finally released, I wouldn't expect more than one year for IE7 to extinguish, and maybe 2-3 years for IE6 to also die off. That still depends on how much should the usage % to drop to consider a browser to "die off": I know of some people who still run IE4, but I'm not targetting any of my web projects to support that.
Actually - if you see my last post - I said 5 to 10 years for IE6 ;) - and I believe that a reasonable estimate. This is centered around the fact that IE6 is the recommended (and default) browser for XP and 2000. I believe there are problems (if it even works) with IE7 on these computers. People aren't going to run out and buy new computers to support IE 8 - which will no doubt have the same compatibility issues as far as the OS is concerned - It's made for Vista. The reason its going to take 5 to 10 years for IE 6 to die off is because thats about how long its going to take for the vast majority of 2000's and XP's to be replaced by the general public. There are plenty of articles online talking about how the old 3 or 4 year replacement cycle for personal computers no longer (if it ever did) apply to us today. Rather - they estimate closer to 5 or 6 years before people start replacing their PCs. That leaves another 4 years for the remnant who just don't need or don't want to upgrade their computers. There will be a few after that who still have it, but 10 years is a reasonable estimate for how long it will take for it to - for the most part - die out. Personally - my PC with XP is only 3 years old so I won't be looking to replace it for another 5 to 7 years.
I like getting new computer stuff - but I hate replacing my old stuff ;).
With a good design and structuration, it doesn't take too much extra effort to achieve a very smooth degradation: for example, IE6 users would see the best IE6 could render, while IE8, Opera9.5x or Firefox3 users would see the same contents, with some layout and formatting improvements here and there. After that, informing the users about the fact they are seeing a "limited" version of the site is up to each one, and it depends on your needs, target audience, and so on. My point is not to require users to upgrade (maybe I should have stated this more clearly), but to reward those who do.
I see no need for degradation (unless your talking about REALLY old browsers). Quite frankly - there haven't been to many new features added over the HTML 4 lifespan, its mostly been about supporting the existing features. Most new features can be supported through alternative means (like the position:fixed). I haven't seen a design which can't be written to look just as nice in IE 6 as it does in IE 7 or FF 3. It might require some older, perhaps unsemantical, coding practices - but you can make it work.
You CAN do the degraded thing - but there are two problems with this:
1) If it isn't degraded to the point that its a hassel or till it looks ugly, people won't care.
2) If it is degraded to that point - people will leave for a site that does support IE.
Trying to force your average users to upgrade (even for unnecessary features which can be made to work without an upgrade) is a bad approach and should only be implemented if absolutely necessary. Build around them - not around the current standards which are for the future anyways. If its your own site - do what you want of course - but don't harm your client's clients ;).
I'm speaking only from my personal experience as I don't know the type of environment you work in, but that quote above would make my job, and others around me, a living hell. I'm starting to think that all of your comments are derived from working on small micro-sites, where as in my case, sometimes we're 20 or 25 people working on the same project.
You are correct that I've never worked on really large projects like that. I usually work alone or in smaller groups of 3 to 4 people. If I were doing a MASSIVE site - that would certaintly influence my design implementation.
My first E-Commerce site that I did - I did by myself. It had 700+ items - all of which I had to scan and upload to a database with relevant data from about 5 large catalogs. I had to do all of the PHP coding for a custom shopping cart and hook it all up to Paypal. It was a fun project - but it took forever 0.o, sure wish I had some help on that one. I'm sure this is small in comparison to the sites you work on though - if they require 20+ people.
It's only logical to have the data/content/information be laid out properly (read: correctly) and use the intended CSS to do what it's meant to do.No one will ever convince me that using tables for structure is either acceptable nor profitable.
The problem is that the CSS isn't supported for Grid Layouts. If you can design in such a way to get away without tables (which isn't to difficult most of the time) great. But to try to use CSS to do grid layouts ... its just not worth it. But - again - I'm speaking from working on projects which are probably quite a bit smaller than what your working with - which is definitely an important consideration.
When working on large projects - standards are a must (EDIT: though this doesn't necessarily mean W3C standards ;) ). I don't think that tables - so long as they are done properly - would be a problem in large projects. But its definitely easier if you don't have to worry about layout markup in such large projects.
Here's the conflict: it DOES work for users, it does NOT work (as well) for developers.
Actually - if you see my last post - I said 5 to 10 years for IE6 ;)
This is centered around the fact that IE6 is the recommended (and default) browser for XP and 2000.
I believe there are problems (if it even works) with IE7 on these computers.
People aren't going to run out and buy new computers to support IE 8
You CAN do the degraded thing - but there are two problems with this:
1) If it isn't degraded to the point that its a hassel or till it looks ugly, people won't care.2) If it is degraded to that point - people will leave for a site that does support IE.
If its your own site - do what you want of course - but don't harm your client's clients ;)
As a side comment, for big-team projects, I also think that separation of concerns is essential for good interaction between the parts developed by different "sub-teams" or individuals.
Regards,
Herenvardo
That said, as someone who knows a lot about DIVs and CSS, I find that it's impossible to do multi-column variable-length cross-browser-compatible layouts without tables. Firefox and IE treat floating DIVs differently, but are quiet consistent with tables. The CssZenGarden website is not relevant to real world sites with dynamic data, because the content of the Zen website never changes. You might find that a lof of designs would break if you doubled or halved the amount of text in some of the DIVs.
Two points:
1) Why does no-one ever ask what's wrong with laying out pages using unordered lists? That's possible too with a bit of persistence. Any argument for laying out pages using tables (apart from: "Because I already know how to do it and it seems to work in every user agent I've tried") also applies to laying out pages using unordered lists.
Come to think of it, why not just create huge sections of your page in Photoshop and display them all as images? That works in most browsers too!
2) Forr thoze hu doe nagri with yuzing standerds becoz uther methods werk just as well, wy do yu insist on tryin tu spell wurds according to defined spelling rools? Yu mite az well jus rite the way it sowns, no? Aft arool it werkz pritty much wen yu reed it bak, no? Wy bothar withaving tu lern how to spel stuff? Spelit how yu wont! (Shakspere did!)
Come to think of it, why not just create huge sections of your page in Photoshop and display them all as images? That works in most browsers too!
2) Forr thoze hu doe nagri with yuzing standerds becoz uther methods werk just as well, wy do yu insist on tryin tu spell wurds according to defined spelling rools? Yu mite az well jus rite the way it sowns, no? Aft arool it werkz pritty much wen yu reed it bak, no? Wy bothar withaving tu lern how to spel stuff? Spelit how yu wont! (Shakspere did!)
(I was thinking on leaving the post just as that, and give all of you some time to try to figure out where's the missing 1%. Nop, there is no rounding error ;))
Readability is a very good argument in favor of the semantic approaches and of the separation of concerns philosophy (which, while vastly overlapping, are still different concepts). But, let's put a counter-example / metaphor which illustrates the justification of tables for layout:
Let's suppose we need to write an essay or an article about something (I'll use essay from now on for this analogy); and there is a concept that is essential for the meaning or purpose of the essay.
The essay would actually represent a website; the concept represents the site's inherent layout (which in this case would be a grid/table layout), and the purpose of the site is to provide an interface for the user to browse the contents, which inherently relies on the layout).
It's quite obvious that we should use the right word and spelling for the concept, isn't it? But let's suppose, for this metaphor, that for some reason the correct word for that concept, as defined by the dictionary, is only understood by some of the intended audience; and most of them use a slang term for the concept. Also, most of the audience understands the slang term, even while some know it is not the correct wording.
Following with the metaphor, the right word and spelling would be the CSS table-related properties; the slang term would be the <table> and related tags; and the audience would represent the site's users and their browsers.
We face some different options:
Which option would you take might depend on the context of the essay. If rather than an essay what you are doing is some kind of advertising, then the slang term can work. If the essay is something about the importance of using correct words and spellings, then using the slang is unacceptable. There are infinity of grays in between.
Finishing with the metaphor, the advertising approach matches most commercial businesses, whose only purpose is to advertise some products and enable the users to buy them. The oposite extreme would be a website about the importance of semantic markup, standards compliance, or separation of concerns. Like with the essay metaphor, there are lots of sites in the "gray" area, which do not fall in any of the extreme categories.
Regards,
Herenvardo
The signature is not part of the metaphor :P
Well done.
I tend to think in academic terms, so, to me, all web pages are academic documents - consequently, any use of scrappy short-hand or slang (ie. table-based layouts) is just... clumsy.
Just letting users know about the improvements they would get if upgraded, and how to upgrade if they chose so, shouldn't hurt. Actually, it will show the users how much do you care about them (and, considering that websites are often the first point of contact between bussinesses and clients, that could even make the difference for a user picking that site instead of competitors "hey, does folks really care about me! Better than [Competitor X here] that just cares about my payment info being correct. :)").
My maxim is to always put the users first, and do what's best for them (not only in the web context, I'm also a software developer and I also apply the maxim on that field); but this means that when the user doesn't really know what's best for her/him, you need to explain it in a way s/he will understand. For my this is always the very first design principle; if it's not among your principles list, I will respect your position/philosophy, so feel free to ignore this whole paragraph.
I somewhat agree - but I still feel that the vast majority of users will either ignore it - or even be annoyed with the new banner and the degradation (if they have an older and newer comp to access your site with). The fewer banners advertising stuff, for good or not, the better - and the more sites I go to stay the same no matter what computer I'm using the better. I feel that 1) it's a waste of time (even if you gotta a couple converts its not going to speed up the time it takes for these browsers to die out) and 2) the extra work it creates is not worth it nor ideal. Going out of your way to make it degrade is wrong IMHO.
Furthermore, I just got a new development job - and my employer has a Windows '98! Not a good idea to make it degrade for them ;).
Ouch, I'm blind (honestly, maybe I should not keep posting at 3-4 a.m.). Yes, I just reviewed the thread and saw it.
Still, I don't expect IE 6 to last more than 2 or 3 more years (and this is regardless of IE8's release date). That's because this is the time in which I expect Win 2k to die off (see my thougths on Win XP later in this post).This fact is not much a fact. For 2k, the default is IE5.something, and IE6 is the highest you can install there. For XP, indeed, IE6 is the default (except XP SP3 which, AFAIK, raises the default to IE7). Recommended... by who? Microsoft always recommends they latests products (obvious, they have to sell them after all); so I'd like to know what's the source of such "recommendation".
I know the feeling - I'm posting at 6Am myself. I've had like 4 or 5 hrs sleep (normal for me unfortunately) and now I've gotta go on a 4+ hr car drive to help my parents move :/. Anyways, I was mistaken - its not that its recommended for XP - but for all Window OS's prior to XP. IE7 and 8 are for XP+Vista. Anyways, just because the technology is out there doesn't mean a thing - people don't upgrade. They don't like it, they don't want it. Hence you still will run a number of people who use 98 like my new employer. Again - I said it would only take 5 to 10 years for IE6 to go away, which really isn't a long time. 5 years for the majority of IE6 users to upgrade and 10 years for those remnant holding on to older computers (like they do for 98) to upgrade or become a super small demographic so that you don't have to code for them anymore (like people who use version 4 browsers today - no one cares that they use it, they're not programming for 'em).
Then there's IE7 - most people are not going to upgrade browsers. For the longest time - I thought I had IE6 on my laptop (mostly because I use FF to search the web). I knew quite well IE7 was out and I had no plans to upgrade. And I'm a developer! How much more so are non developers not going to care and see it as an unnecessary hassel? So long as it works - they aren't going to want to upgrade. I expect IE 7 to have at least as long as a life span as IE 6 has had.
That's exactly the point of degrading gracefully: I'll exemplify this with my current methodology (I know it takes a lot of extra effort, but the current sites I'm working on deserve it :P )...
0.o Way too much work and counter-productive in every way, IMO.
Indeed, the site's where I'm doing this are my own. When working for someone else, most often I have to work on already built sites, and I adapt myself to the existing methodology (if I found an HTML 3.2 site, however, I would strongly encourage the owner to create a new one from scratch, reusing content but not even a single tag of markup). The last time I had to build a new site (it was a remake from a 3.2 site, btw, but explicitly asked by the owner), IE6 was something new and I used tables for layout; simply because it'd be best for the users, which is what ultimately matters.
Exactly - having it work for the user is what ultimately matters. I also believe that users should get the same experience at any site and should not recieve a degraded form of a site unless it is impossible to make some feature work with an older browser. To purposefully make it degrade is... wrong. "Graceful" degradation is rarely graceful - especially for users who see your website with older vs newer browsers.
As a side comment, for big-team projects, I also think that separation of concerns is essential for good interaction between the parts developed by different "sub-teams" or individuals.
I agree completely. Making a website as modular as possible - especially for big-team projects - is essential to getting a website up and running. It's still important for smaller projects, but it will never get up and running if the groups are properly separated and using proper standards (again - this doesn't mean W3C standards, just standards for the company).
Ryan
Then there's IE7 - most people are not going to upgrade browsers.
That's exactly the point of degrading gracefully: I'll exemplify this with my current methodology (I know it takes a lot of extra effort, but the current sites I'm working on deserve it :P )...0.o Way too much work and counter-productive in every way, IMO.
That's content negotiation + graceful degradation at its finest and, for most "real-world" cases (...), it's undenniably a needless overkill
A more "real" example: have you seen some of those fancy CSS menus out there? They make interesting use of non-typical selectors to hide submenus and display them only when the corresponding item in the main menu is being hovered; but they don't work well in some browsers (for example, IE has had some issues with the handling of the :hover pseudo-class). There are some pages that add redundant javascript to ensure the menu behaves as it should (for example: the javascript handless it when the CSS is not recognized, and the CSS can be relied upon by most browsers when javascript is disabled); and they even add a bit of coding to check which browser is being used: if the browser can already handle the CSS, the javascript won't mess-up. Finally, any of those sites could (maybe some do, but I haven't seen any) use the <noscript> tag to provide alternative means of navigation when everything else fails. That's an example of graceful degradation: the page is designed in a way that it will use the best means available, but doesn't rely on only the best option and uses the "second best" when the first fails, and so on, until the last method (in this example, the noscript tag), which is supposed to be fail-safe.
Exactly - having it work for the user is what ultimately matters.
I also believe that users should get the same experience at any site and should not recieve a degraded form of a site unless it is impossible to make some feature work with an older browser.
So, going to the starting topic of the thread, I have to say: SirTalksalot, go ahead: there is no sin. Tables for layout are currently justified and, while they have been used by sinners in the past together with other malefic tools (such as the transparent-gif-spacer), they are not a sin by themselves (I'd rather say they are a forced indulgence).
I know, I know, in theory tables for layout are bad. But in theory the URSS was going to outlast every other nation in the globle; in theory mankind should already have eradicated itself from the Earth; and, 6 centuries ago, in theory, the world was flat and if you crossed the Atlantic you'd reach the edge of the world and fall to the Abbyss.
Don't miss-interpret me: theory is indeed interesting, and I really like theory; but theory is just theory, and not practice. Quoting a famous theoric scientist "As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality." This applies to any kind of theory and its respective application field.
I think I'm missing something, but I can't figure out what is it, so that's all for now :P
Regards,
Herenvardo
[edited by: Herenvardo at 10:13 pm (utc) on Aug. 23, 2008]
For bots and indexers to get to the content there is often node upon node to parse through, check the content, decide if it is layout of textual content and so on. It is labor intensive and since your content isn't really what the markup says it is you get a penalty (in theory)
Should stay out of this... I use both tables (existing pages from 1996) and css (all new pages since 2003) but as far as I can tell, bots have no problems ripping through a website, table or css. And I haven't heard of a smart bot, yet. I would be very intrigued in finding out more about smart bots because that's the one I want crawling my site. :)
With all the great expertise here, I often wish I could deduce some human identities, so's I could read some tomes I suspect some of you have written. For now, I'm happy browsing the threads.
I peruse tables versus divs, thinking of the Samurai. And I think of the divitis with which some webmasters replace their tables. Does it end up, being worthwhile? For a gross example, I think with "relative" horror [pun intended] of blogger templates.
As for me, I lack your great creativity, so I have "dumbed down" one small site, to all of (1) handle AOL, (2) disabled readers, and (3) still appear in a manner somewhat attractive to modern browsers (600 or so member group of older folks in continuing education).
I use the tables trick (does anyone else still use that?) to push content to the top over menus/etc and I am not about to stop now. It works - don't fix it.
I use css for all other styling possible.
If you took my css files out, my sites would like something out of the web, circa 1996. I have a sneaking suspicion that SEs like that. :-)
I use both tables (existing pages from 1996) and css (all new pages since 2003) but as far as I can tell, bots have no problems ripping through a website, table or css.
I look forward to the thread on HTML5 vs XHTML2
Regards,
Herenvardo
Can somebody guess the reason?
Employer demanded it? (only good one I can think of)
Can somebody guess the reason?
Employer demanded it? (only good one I can think of)
Regards
XML data can be binded to html tables
On the postitive side: the day you don't learn something new is a day you wasted; so thanks for helping me not to waste my day ;) :P
Regards,
Herenvardo
I'll give you a short example. Here's the XML:
<? xml version="1.0"><INVENTORY>
<BOOK>
<TITLE>My Favorite Book</TITLE>
<AUTHOR>Me, Myself, and I</AUTHOR>
<DESCRIPTION>Best book ever!</DESCRIPTION>
<PAGES>100</PAGES>
<PRICE>$50</PRICE>
</BOOK>
<BOOK>
<TITLE>My 2nd Favorite Book</TITLE>
<AUTHOR>That one guy</AUTHOR>
<DESCRIPTION>2nd Best book ever!</DESCRIPTION>
<PAGES>120</PAGES>
<PRICE>$45</PRICE>
</BOOK>
<BOOK>
<TITLE>My Most Hated Book</TITLE>
<AUTHOR>Some Loser</AUTHOR>
<DESCRIPTION>Tastes like salt</DESCRIPTION>
<PAGES>200</PAGES>
<PRICE>I'll slap you if you read this book</PRICE>
</BOOK>
</INVENTORY>
Now, in your HTML you need to load this xml document - similar to a CSS link tag. Here's the basic syntax:
<XML ID="theInventory" SRC="Inventory.xml"></XML>
Here's the table code used to display the xml data:
<table datasrc="#theInventory">
<!-- This row not required -->
<tr>
<th>Title</th>
<th>Author</th>
<th>Description</th>
<th>Pages</th>
<th>Price</th>
</tr>
<tr>
<td><span class="title" datafld="TITLE"></span></td>
<td><span class="author" datafld="AUTHOR"></span></td>
<td><span class="description" datafld="DESCRIPTION"></span></td>
<td><span class="pages" datafld="PAGES"></span></td>
<td><span class="price" datafld="PRICE"></span></td>
</tr>
</table>
This will work regardless of how many or how few items are in the XML document. Take that CSS Divs :D (although may work with CSS Divs.... not sure).
Anyways - look up 'XML DATABINDING TABLES' online and you'll find lots of info on it.
It's simple really. When you have tabular data, use tables.
How true. However, what would you consider the contents of this page - tabular data?
I am not adding to the discussion here other than to say I find it ironic that it is taking place on a page with a 4.01 transitional doctype, tables, and depreciated tags - <font size="2" face="arial" color="#ffffff">, etc.
And have you noticed the PR for the "recent posts" page.
Just food for thought.
Marshall
It is entirely possible to have multiple column layouts using CSS (source-ordered!) with variable heights, backgrounds, headers, footers etc, that work cross-browser.
It's also remarkably easy to implement complex grid layouts with divs and CSS, that are far more flexible and reusable than tables, *if you know what you're doing*.
It seems a lot of the CSS 'knockers' need to actually learn more about CSS before they slate what you can and cannot do with it.
I'm not saying that applies to everyone of course.
It is entirely possible to have multiple column layouts using CSS (source-ordered!) with variable heights, backgrounds, headers, footers etc, that work cross-browser.
It maybe possible - but can you program with only divs and css a grid layout with a single row and mulitple cells that receive dynamically built content that are all equal height without using overflow? I'd like to see it. And that's without using display:table and display:table-cell, which neither works cross-browser nor do I consider it semantically correct.
It's also remarkably easy to implement complex grid layouts with divs and CSS, that are far more flexible and reusable than tables, *if you know what you're doing*.
Depends upon what your doing.
Ryan
Anyways - look up 'XML DATABINDING TABLES' online and you'll find lots of info on it.
It's simple really. When you have tabular data, use tables.
When you have lists, use css ol/ul
It is entirely possible to have multiple column layouts using CSS (source-ordered!) with variable heights, backgrounds, headers, footers etc, that work cross-browser.
It's also remarkably easy to implement complex grid layouts with divs and CSS, that are far more flexible and reusable than tables, *if you know what you're doing*.
And that's without using display:table and display:table-cell, which works neither cross-browser nor do I consider it semantically correct.
As a side note, has somebody mentioned that XSLT works cross-browser1, 2 and allows rendering "whatever"? Of course, client-side XSLT has serious drawbacks 2 (specially in the field of SE indexing), and server-side XSLT would look to the client exactly as presentational HTML would, which fails for the entire purpose, except, maybe, maintainability.
1You'd have to serve the XML as either "text/xml" or, preferably, "application/xml", and with a <?xml-stylesheet ... ?> processing instruction attaching the XSLT sheet; but most modern browsers can handle that.
2 Of course, only XSLT 1.0 is widely supported, for XSLT 2 we'd have to wait a few more years.
3 AFAIK, if you use <output method="html"> the in the XSLT, the resulting html is then handled as in normal html rather than xml. So you would have draconic error handling for the source data and the stylesheet, but tag-soup indulgence for the resulting html (for example, you could have user-provided content marked as CDATA in the XML, and the final page will be rendered even if that content has something like "<b>asdf<i>qwerty</b>zxcv</i>"; but it will still crash if you messed up with your own XML or the XSLT (which means that you would immediately detect such issue if you test your files, which you should). So, you can get the best of draconic error handling (no chance to by-pass an error while testing) plus the sometimes needed indulgence of classic HTML (so no need to validate external content, just store it as CDATA).
Now that I think about it, server-side XML+XSLT, with <link rel="alternative" href="theXMLsource.xml"> seems quite interesting. Is there anybody who has tried this or something similar and can share some experiences?
Regards,
Herenvardo
It looks prety interesting. Although it takes more than my current 4-line CSS (note that I'm using only the CSS, there is no HTML code anywhere). Also, how does that work crossbroser? I had heard somethign about all this "data-islands" stuff, but AFAIK it was only supported on IE, and I have found no source stating otherwise (I guess I'll try that by hand on FF/Opera). As a side note, since I'm only using this (currently) to check my google sitemaps in a more human-readable form (I'm generating them dynamically, and need to check that the script pulls all of, and only, the relevant URLs, without throwing away my last bits of sanity), I can afford having it only working on FF, but it would be an issue if it only worked on IE. I'm not sure if this is straying too much off-topic, since it's still about tables and layouts :P.
I looked around on the subject and it appears to be an IE only attribute - though there are ways to simulate it with other browsers. I think they should make it a standard :D - but, like I said, I don't really use plain XML (or XHTML for that matter) so I'm not experienced enough in the area to debate it too much.
Can you tell me what does it mean for CSS to be "semantically correct"? Isn't CSS purely presentational in goal, scope, and semantics? I mean, the only semantics of "display: table" would be "display this rendered as a table/grid". As long as this is what you mean, that's 100% semantically correct in CSS. And if you don't mean that, I wonder why you'd be using such a declaration.
I made a thread on this topic in the CSS section. Basically - your putting a table (not a grid - a table) in your html. Your simply changing the location of where its declared a table/table-cell. Now - if your building an actual table with tabular data then its fine (though I don't see why you wouldn't just use a table then), but most people don't use it this way. Rather - they want the layout functionality of tables without being semantically incorrect. So they change where its declared a table and say its semantically correct ;).
I find it ironic and silly really.
Ryan
I'm a pragmatist. I need to spend time wisely or I'm not doing right for my clients. I tried CSS positioning for layouts, and it just isn't business-worthy in most situations right now. Maybe someday. I still, occasionally, use a spacer.gif, too. 1 minute's work instead of 1 hour's worth of tweaking, you know? That's especially true when working with legacy code that someone else created.
I applaud all the adventurers who are blazing the trail to perfect separation of style and content. Let me know when it gets paved, please.
Basically - your putting a table (not a grid - a table) in your html.
if your building an actual table with tabular data
However, if you find yourself (in an hipotetic future where display:table is suported) forcing <div>s in your code just to use this property, then I'll agree with you that something's wrong. However, on that future we'll already have either XHTML2 or HTML5, so we'll have the <section> element (currently both specs include it, and it's not likely to be removed from neither), and something like this (it'd probably need to be a bit more elaborate to be useful)
section { display: table-row; }
section section { display: table-cell }
seems fine to me. Your html has sections and subsections, and your CSS describes how to display them. Each language is being used for what it's for.
In summary:
HTML is for structure/semantics; and <table> is for tabular data.
CSS is for presentation/layout; and display:table is for tabular layouts.
I still, occasionally, use a spacer.gif, too. 1 minute's work instead of 1 hour's worth of tweaking, you know? That's especially true when working with legacy code that someone else created.
Regards,
Herenvardo
