digg

Facebook Connect Join Digg About

Tableless forms

roscripts.com — Learn by example how to create a tableless css form

Who dugg this? Made popular Mar 5, 2007

Digg DudeWhat is Digg?

Digg is a place for people to discover and share content from anywhere on the web. Digg surfaces the best stuff as submitted and voted on by the community. Take the Tour to learn more.

94 Comments

show profanity settings
expand all
  • themoose, on 10/12/2007, -16/+70This is stupid.

    Tables are meant for tabular data, including forms. Not for whole webpages. CSS is meant for webpages. It's OK to use tables in CSS designs, as long as you're not basing the whole structure of everything on tables. This article is a prime example of why - CSS is meant to cut down code for starters, and these examples use 5x the amount of code that tables use. You can still style tables to your liking too, just like that guy did but with a hellava lot less code.
  • ryanmerket, on 10/12/2007, -6/+31[soapbox]

    Bob,

    No offense, but you have no idea what you are talking about. Tables are for tabular data, not layout. I would be willing to bet that any handicap person using a screen reader would leave your site in less than 10 seconds. How would your clients like that? Or if I went to your site in my Blackberry - I would probably grow tired 'thumb scrolling' to where the content is.

    The point is to seperate your CONTENT from the DESIGN. You can't do that with table based layouts. You content is very much part ofyour design (tables define layout) when you use tables. When you codein semantic XHTML and use CSS to manipulate your XHTML to take on the design. See www.csszengarden.com and study it - that content never changes - just the CSS file. That is the future.

    [/soapbox]
  • ldkronos, on 10/12/2007, -1/+21@themoose

    I dugg you up, because I agree with you that there is still a place for tables right now, because there are some things tables do best (setting up div's to behave like a table is pretty much impractical).

    However, the point of CSS isn't to reduce code. That just happens to be a common (and welcome) side effect. The primary purpose is to decouple content from presentation. Embedding details of the presentation into the content has 2 problems. First, it's messy. Second, sometimes it forces illogical constraints onto the content (think about putting a grid of column major ordered data into an HTML table, which is row major ordered)
  • inactive, on 10/12/2007, -10/+27"I develop websites"

    Not if you can't do it table-less.
  • stevenstclair, on 10/12/2007, -4/+18http://duggmirror.com/programming/Tableless_forms/

    dugg down for putting a working mirror? Ok.
  • DNABeast, on 10/12/2007, -1/+15@TheMoose

    True, but semantically forms aren't tabular data. They are lists of inputs that each have labels attached to them.
  • drmangrum, on 10/12/2007, -10/+22For simple forms, I fully agree. There is NOTHING wrong with using tables. You know exactly how they will render, and they aren't that hard to maintain. How much are you going to change a form anyway?

    Now using tables for a the full page layout is a different story.

    Tables may be old, but they work everywhere. Just because CSS is the latest and greatest thing out there doesn't mean it's always the best tool for the job.
  • pauldbentley, on 10/12/2007, -0/+11There is lots of discussion on how to markup tableless forms on the Internet; I think this example is a little over "div"ed as it were.

    I much prefer to mark my forms up using dl/dt/dd as it correctly represents defining data and terms which is basically what you are doing by filling in a form.
  • ngmcs8203, on 10/12/2007, -1/+10There's a learning curve that a lot of people seem to understate. If you are unwilling to learn by trial and error, spend a few months fiddling and figuring out why certain things break here, work there, then fine. Don't learn CSS for layout and stick with your tables. It's perfectly acceptable. But, honestly, nobody who says "I've learned CSS, and I'm going to stick to tables because it's easier" is full of *****. Once you've grasped CSS and have learned what to avoid, using it becomes second nature.

    Saying that it is too new, or pointless, or only fanatics use it and preach it is just naff. I could say that I opened a beginners guide to AJAX and say that it is pointless and too new also, but then I would just be restricting myself from what may be the base of the industry that I am working in for the future.

    The Web is a constantly changing infrastructure that is built up, knocked down, and built back up. So, that saying, use CSS if you want, but don't bash it because it confuses and frustrates you. We (CSS fanatics) would have stopped preaching its glories years ago if it wasn't all that great.
  • inactive, on 10/12/2007, -3/+11Because IE is forced upon that whole market, that is the only reason. Its not like its the superior browser.

    Those of us who are skilled can make it work in all browsers with no hacks.
  • armbar, on 10/12/2007, -0/+8Bob gets an F.
  • dacameron, on 10/12/2007, -4/+12Bob makes a good point: clients - rightly or wrongly - are more interested in their websites rendering "the same on every browser" than how accessible they are. I personally don't agree with that, but I'm not the one paying for it.

    As for Ryanmerket's comment "any handicap person using a screen reader would leave your site in less than 10 seconds. How would your clients like that". Well, to be honest, usually they will not give a rat's arse. People with "accessibility challenges" make up a very very very small part of the viewing audience, so demographically speaking: they're insignificant. It's "better" (as in "usage of money") to cater better to the people who AREN'T challenged by a UI. The only entities that seem to "care" about this are govt ones that are legally obligated to. The altruist side of me says "I don't agree with that", but the pragmatic side of me is not so sure.

    Either way, the original article was not posting anything that hasn't been floating around for 2-3 years, so whilst it's good advice, it's hardly newsworthy.

    --
    Adam
  • maino82, on 10/12/2007, -11/+18i agree. this anti-table movement baffles me. they still have their uses (such as *gasp* tabular data!) and don't need to be replaced by css in every situation.
  • sunimoto, on 10/12/2007, -13/+19What's so bad about tables that people go through so much to avoid them? I often use combination of divs, tables and sometimes fieldset/legend. It works out great. I really don't see what's the big deal is about.
  • sunimoto, on 10/12/2007, -0/+6I'm not saying that IE is superior in any way. However, its popularity is a non disputable fact and you have to live with that. This means not designing sites that don't work in IE. Saying that IE doesn't support a standard W3C-described property is not an excuse. Good designer will be able to create a great site that will look and act the same in all browsers. Having a separate style sheet for printer output is a good idea as well.
  • armbar, on 10/12/2007, -0/+6"I wish some of the CSS fanatics would just move over to XML and XSLT and leave the rest of us alone."

    I wish interior designers would just move over to architecture and construction and leave the rest of alone. That's about how much sense your sentence makes...they're different tools entirely.

    Tell me, did you just hear that XSLT has the word "Style" in it, and think that it was an alternative to CSS?
  • AmnestyGenocide, on 10/12/2007, -7/+13http://www.getvanilla.com/ - table-less forum
  • gers4302, on 10/12/2007, -0/+6I may be damned to hell for this, but here's my $0.02 on this.

    For the examples given on the site, this approach works well. You can get a nice, clean look and break out of the "table problem".

    But, for very large forms, this breaks down quickly. If you have a long label/input, you break the layout. Then if you compensate for this length, forms that have a lot of small labels/inputs look silly. For massive sites that require a lot of forms, you end up creating forms with custom label/input lengths, which tends to become a maintainable nightmare.

    If you are developing simple apps that will be viewable by a mass audience, then tabless is great for form data. If you require massive amounts of forms, you may want to reconsider, because you may spend a majority of time tweaking the 'width' attributes.

    Also, in big applications, the line between a table and a form is blurred. If you need quick access to data and the ability to edit it, you end up with your data in table form with it shown in inputs/selects. When you are doing a lot of work, you don't want to click an 'edit' button to change data.
  • samssf, on 10/12/2007, -1/+6@themoose:

    "This is stupid."

    While I agree that the method demonstrated in the article could be more efficient, I disagree that tables are meant for forms. Like stated above, semantically forms are not tabular data. There are actually methods that (for me) work better than the one used in article, and do have benefits over using tables, such as more control over positioning, etc. You can style form elements such as the "Label" tag to achieve a very nice effect, and has minimal bloating.
  • armbar, on 10/12/2007, -0/+4The problem with using tables in certain instances is that you lose device independence and some accessibility (not generally with just one table though).

    If someone tells you to flat out NEVER use tables, they're stupid. They have their times, but they're obviously only supposed to be used for tabular data. Sorry if you've had some ass-clown misrepresent the point.
  • Smuikas, on 10/12/2007, -1/+5Major problem with tables as forms:

    Screen-readers get confused.

    Unable to use fieldsets to their greatest advantage, typically.

    Tab-order can get wacky, unless you use tab-indexes (which themselves can get extremely wacky).

    Now, for css-based:

    For printing (who would want to print out a form, though? Gives your users an option to mail in something instead of filling out the form) you can define a special stylesheet that can style the form elements, and make the whole thing look like a real printed form (not a form you printed off some website).

    You can (as the example in the linked article has) align your labels and make them associate better visually with the elements they're attached to. Only a couple browsers out there can do this with tables (display:div, for example).

    It's also better for auto-generated form content (example; even though it's a heinous business model, a lot of people are in the direct marketing industry. A lot of these sites have hundreds of forms that must (mostly) be kept up and put together (besides shared information, like regular contact information) by hand. It's much easier to keep up clean and table-less pages than table-gucked up things). Less markup, less mess.

    That brings me round about to the whole less markup, less mess thing. Google partially ranks your page now based on the markup-to-content ratio. A big part of SEO nowadays is about cleaning up the code.

    Just about every reason there is for CSS-based layouts over table-based layouts is there for table-based forms versus css-based forms. Browser support of CSS is good enough these days that you can get away with it. Forms are not tabular data, they are a series of (as mentioned before) controls and labels. You don't see people building option dialog windows with excel, do you?
  • Mullinsmcd, on 10/12/2007, -0/+4Care to give us an example? I'm an amateur myself and designing without using tables is a new concept to me.
  • 3mpire, on 10/12/2007, -2/+6you know I use CSS for most things but when it comes to making the customer happy i'll use bad practices from time to time because they're just not going to appreciate a lecture on standards and don't give two ***** about it. The parent is speaking from practicality, and when people say "you don't develop web sites if you use tables" is full of *****, because there is more to developing a web site than the markup. People talk about separating content from presentation, but that goes FAR beyond the freakin' markup in the page. I've worked in places where CSS nazis actually SABOTAGED efforts to move from static code to dynamic code via an enterprise CMS because they didn't like the idea that code would be generated dynamically. So spare me the CSS gospel as if that's all you need to know to "develop" a web site. CSS's time is definitely coming. And when it's efficient to code exactly to standard (read: full browser support), wasting time on getting perfect CSS to the detriment of being effective or leveraging the power of server-side programming is just as stupid as resolutely refusing to learn CSS.
  • armbar, on 10/12/2007, -0/+4Labels are correct, but the br element is for line breaks, not for formatting. Separate your styling from your markup and you can present it to different types of devices without changing the markup, just the stylesheet.

    With that said, the guy has a lot of superfluous code.
  • Coolwave, on 10/12/2007, -0/+3Nice results, but WAAAY too much markup and repeated styles.

    CSS + meaningful markup ftw! I'm all for ending the overuse of tables in exchange for some good CSS, but I really think you could do a lot better than this. You should be emphasizing how much you can do with CSS to style your forms with very little markup.

    Too many people learn CSS by hacking examples like this for their own use without actually understanding what's going on. I guess that's how I started with CSS... :) It's easy to hate CSS when there's so much unnecessary code, and if you want to learn to love XHTML and CSS, I highly recommend sitting down with a good book on the subject. Here's a couple:
    - CSS Mastery by Andy Budd
    - Bulletproof Web Design by Dan Cederholm

    Now I just need a blog so I can redo these examples and make these books Amazon referral links!
  • Kinsbane, on 10/12/2007, -0/+3This has some nice examples of styling forms using CSS (also, with no DL's/DT's/DD's or UL's/OL's/LI's)
    http://www.themaninblue.com/experiment/InForm/index.htm
  • Saiing, on 10/12/2007, -2/+5I agree with some of the above dugg up comments. For a number of reasons:

    Yes, form data isn't the same as tabular data, but there are occasions when you want a form to replicate the tabular layout that it will actually be displayed as (a WYSIWYG input system if you like). At times like this is makes perfect sense to use a table.

    Also, let's face it, one of the reasons that people still heavily rely on tables, is that as present CSS just isn't ready to replace them. When a technology comes along that is supposed to supercede what went before,　it has to be good enough to actually improve on the status quo. CSS isn't there yet, partly because of the differences in browser support and partly just because of the way it's designed, meaning that doing something very simple can sometimes be very complicated.

    With tables, you pretty much know what you're going to get, because they're simple and straightforward to implement. With CSS, you often don't know for sure how things are going to turn out in browser X until you actually preview it. I'm sure that some smart ass will probably claim that I'm just too dumb to understand CSS, but I defy anyone to claim that that they always accurately predict what their code is going to produce every time.
  • aaroncampbell, on 10/12/2007, -0/+3http://www.assemblesoft.com/examples/form/
  • inactive, on 10/12/2007, -1/+4"The problem with CSS is that it doesn't have proper browser support"

    You've got to be kidding me. IE handles most of the 2.1 spec minus a few things which aren't terribly important anyway. All you need to think about is the way it handles margins slightly different than other browsers.
  • bpapa, on 10/12/2007, -1/+4This is a pretty crappy way to do "tableless forms." Instead of a table tag soup, it's div soup. It tastes just as *****.

    I'm a back end developer doing more and more front end type of stuff lately. On my site, when I realized that the only way to have the labels line up with the fields in the way that the guy is doing here was to go crazy with extra meaningless markup, I simplified the layout I had in mind. Nobody really gives a crap about how the stuff lines up on the page except the fancy pants designer. As long as the form is sensibly laid out the user will be just as happy to login in. You don't have to go crazy with extra markup to give a form a sensible layout.
  • pheen, on 10/12/2007, -0/+3I like and use the fieldset + css, it works well and degrades gracefully. I found it funny that the site that posted this tutorial uses a table on their contact form.
  • mikev, on 10/12/2007, -0/+3It's nice to see people trying to keep tables strictly for tabular data...but honestly...look at that code. That's *a lot* of unnecessary markup. Division-o-rama :X
  • inactive, on 10/12/2007, -2/+5I tried doing this for forms once and found that it took far too long to not do a form in a table. Plus, if you have a really long form, it takes a really long time in this manner. I also tried the UL method on alistapart and found that to be just stupid.

    Otherwise everything else can be done without a table.
  • aristoworks, on 10/12/2007, -0/+3Here's a script from AlistApart.com that shows a very simple yet effective Form Layout technique. It's about 1/2-way down.

    http://alistapart.com/articles/practicalcss
  • greyfade, on 10/12/2007, -2/+4one of the bigger problems with using tables in layout-specific contexts is with context-based screen readers or other non-visual clients. tables represent an ordered listing of two-dimensional data. input fields and their labels are not two-dimensional data.

    that being said, the "anti-tables movement" does tend to take it a little /too/ far. but they have a point: tables have no logical place in layout. visually, yes, they can be useful. but as pure data, they have no logical place (and, in fact, complicate matters immensely).
  • greyfade, on 10/12/2007, -0/+2... and use the holly hack for everything else.

    seriously, cross-browser design is a pain in the ass. IE is the only one that doesn't conform to the standard in a reasonable, consistent, and sane manner. hell, if they did the box model the way everyone else did it, at least then, they'd be more internally consistent.
  • Joyrex, on 10/12/2007, -0/+2I use form-related tags and CSS for my tableless forms - fieldset, legend, label, optiongroup, etc. Knowing how those tags work and what CSS you can apply to them can go a long way to making tableless forms that work in IE6, and all the other browsers.
  • dvsbastard, on 10/12/2007, -0/+2Although I am a huge advocate of CSS, I see usage as this as nothing but over engineered CSS for the sake of CSS - because of semantic purposes (i.e. it isn't actually tabular data)... But if the solution results in bloated, complicated code, and increased development time, with no actual benefits then what is the point?!

    What happened to a bit of common sense amongst developers?
  • inactive, on 10/12/2007, -1/+3What do you mean isn't there yet? You mean IE isn't and hasn't ever been there.
  • dandyhighwayman, on 10/12/2007, -0/+2What the...abba...bu...hmmm?
  • jalenack, on 10/12/2007, -0/+2Wow I can't read this text. Someone needs to discover line-height and font-size.
  • timwright12, on 10/12/2007, -0/+2buried for having bulky and unnecessary css/html. i started using all the form elements for styles (fieldset, legend, label, input, etc.). you'd be surprised what you can do it you take the time to manipulate the HTML (STOP USING LINEBREAKS!), it creates a real & accessible slim tableless form.
  • ineedajob, on 10/12/2007, -0/+2A form is a LIST of inputs.

    "ul" is an unordered list.

    Why complicate things?
  • manilodisan, on 10/12/2007, -0/+1While you're commenting that "it's sad that a tutorial on creating forms with CSS needs to exist in 2007" there are hundreds of people learning html. While you may be a good programmer you can't look back to where you came from and say that it's sad that in 2007 someone is learning HTML. It's sad that you think this way. You just can't say that. People voted what they liked and that's what digg is. A community.
  • morninglorii, on 10/12/2007, -0/+1Absolutely. He obviously knows his CSS properties... someone should teach him line-height at the very least.
  • alamko1999, on 10/12/2007, -0/+1[div] Testing [/div]
    hahaha
  • skeftomilos, on 10/12/2007, -0/+1Tables are not for layout, agreed.
    But what about floats? Is floating meant to hold the weight of page layout? I don't think so. Floating was invented for wrapping text around images and similar small things, not for layout. The reason of its heavy use for layout is just that it works. Not always, not perfectly but it works. Like use of tables does. Only that tables are working perfectly, everywhere, everytime.

    At the time being I have very small pressure from boss and clients to go tableless. I always have constant pressure to deliver fast. Having to choose between floats and tables, I'll take the later.
  • chump, on 10/12/2007, -0/+1background-image: url(../images/16m.png);
    background-repeat: no-repeat;
    background-position:left;
    background-color:#FFFFFF;

    or...

    background: #fff url(../images/16m.png) no-repeat left;
  • LouCypher, on 10/12/2007, -0/+1http://www.quirksmode.org/css/forms.html
  • samssf, on 10/12/2007, -0/+1@davidwg:

    Huh? You're saying CSS isn't that great, and then you mention that it's sad that people are learning CSS in 2007? What the ***** really is your point?

    First, just like most technologies, CSS actually is great if you know it well and use it right. It helps seperate structure from presentation, which is a great idea in my opinion. Find another solution that does it as well as CSS.

    Second, are you unaware that even though you may be 55 years old, there are people graduating from schools every day which may wish to learn new techniques? His solution might not be _the_ best, but it's a decent solution nevertheless. Do you have a website which demonstrates scripting or design techniques?
  • Fetching more discussions...
    Show 51 - 94 of 94 discussions

  • Add a Comment

    Login or register to comment!
    Or, sign-in super fast with your Facebook account ...


© Digg Inc. 2009 — Content created and posted by Digg users is dedicated to the public domain | Terms of Use Updated | Privacy Policy
DIGG, DIGG IT, DUGG, DIGG THIS, Digg graphics, logos, designs, page headers, button icons, scripts, and other service names are the trademarks of Digg Inc.