1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

div vs table

Discussion in 'HTML & Website Design' started by bilalpakistani, Jun 17, 2012.

  1. TusharRelan

    TusharRelan Peon

    Messages:
    2
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #41
    Well, the biggest reason to use div is for prolong readability issue. When you are going to make too many rows and columns for a page layout, it will be hard to read by other website designers and developers or even you after months or years. All those <tr> and <td> tags without "names" are hard to manage. While with div tags you can specify each div into class or id or names. If you are working in a company, its wise to use the ongoing current nomenclature. Designers use div tags for this purpose because it is used worldwide.
    SEMrush
    Now, there is a way and there is a right way. You can use two hands on the wheel of the car, but the right way is to put a hand on the gear. Same is with the div and table tags. Tables for page layour is depricated.
     
    TusharRelan, Jun 26, 2012 IP
    SEMrush
  2. Rukbat

    Rukbat Well-Known Member

    Messages:
    2,908
    Likes Received:
    37
    Best Answers:
    51
    Trophy Points:
    125
    #42
    He and I disagree. He's creating a problem, then putting a band-aid on it. "Then, if someone can receive the HTML version, they will, and if they can’t, you have plain text as a backup." Or they're professionals, and trash anything with HTML tags, so they don't get it. If you want to see professional, look at emails sent by professional programming groups. At the very least, you let your users opt in for (and not opt out of) HTML emails.

    Professionals usually set our own filters, and we're more likely than not to consider tags to be spam.

    But do it your way, no one but 10 million email filters is stopping you.
     
    Rukbat, Jun 26, 2012 IP
  3. bilalpakistani

    bilalpakistani Member

    Messages:
    75
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    36
    #43
    okay! guys..

    Now, i will use, Div TAGS ..
    but, can you explain, Position: absolute, and Relative with some examples..
    i can't understand this,,,
     
    bilalpakistani, Jun 26, 2012 IP
  4. Rukbat

    Rukbat Well-Known Member

    Messages:
    2,908
    Likes Received:
    37
    Best Answers:
    51
    Trophy Points:
    125
    #44
    Position:absolute is the position relative to the upper-left corner of the document. Position:relative is position relative to where the object would be if there were no positioning stated.

    Position:absolute;
    top: -20px;

    would put the top of the object 20 pixels above the top (of the screen, usually).

    Position:relative;
    top: -20px;

    would put the top of the object 20 pixels above where it would be if the statement weren't there.

    You can move an object in any or all of the 4 directions. (Of course, using top and bottom, or left and right, would only yield the last one, since it can't be, say, both 20 pixels higher and 30 pixels lower at the same time.)
     
    Rukbat, Jun 26, 2012 IP
  5. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,858
    Likes Received:
    1,610
    Best Answers:
    230
    Trophy Points:
    515
    #45
    I'd point out that RPO (relative positioning) moves where it's DRAWN, but not where it is in 'flow' -- which is to say elements around it will treat it as if it's in the same position it would be without the position:relative;

    You can see that in this example:

    
    <div id="testBox"><div></div></div>
    
    Code (markup):
    
    #testBox {
      zoom:1; /* make relative child behave in legacy IE */
      margin:2em;
      background:#00F;
    }
    
    #testBox div {
      position:relative;
      top:-1em;
      left:-1em;
      width:15em;
      height:15em;
    }
    
    Code (markup):
    The inner div gets moved, but the box around it still picks up it's width and height as if it was in it's original position. If you use absolute positioning, the element is 'removed' from flow, so that outer DIV would act as if the one inside it didn't exist.

    I like to think of it as there being two 'boxes' the browsers track, the 'flow' box, which determines how other elements interact with it on the page, and the 'render' box, which is what's drawn. Things like negative margins shrink the flow box without changing the render... which is how most of your really good columnar float layouts work.

    Which is why APO (absolute positioning) should be reserved for a handful of special cases like image replacement methods, and why relative positioning should mostly be used for depth sorting or other content overlap methods... which is why REAL layouts are built using floats.

    Despite some nuts out there trying to make disastrously broken (at least for LF/120dpi users) inline-block layouts.

    As to the topic at hand, I'm not seeing much REAL explanation of how/what/why of DIV vs. Tables... so here we go.

    There's a concept of the past few years called 'semantic markup' -- which plays to the original point of HTML, saying what things ARE. What things look like was originally supposed to entirely be up to the discretion of the user agent with the ideal being able to have content marked up so that regardless of the end users device capabilities the content itself (the TEXT) could be delivered in a useful manner. Didn't matter if it was a 1978 Teletype terminal, a 21x22 VIC=20, a 300 dpi HP laser printer, 640x480 16 color VGA or a 1120x832 monochrome NeXT workstation -- a properly done HTML document would be meaningful and useful on all of them.

    We got away from that during the "Browser Wars" when IE and Netscape started adding their own proprietary HTML values that eventually got adopted into what became known as HTML 3.2... We got away from clean HTML saying what things are and into being more concerned about what it looked like on Windows and Mac PC screens; completely shtupping anyone who has anything that varies from the magical combination of resolution and font size settings as the 'designer'. (don't get me STARTED about "designers" -- and yes, I'm making quotes in the air with my fingers)

    CSS was supposed to fix that, which is how HTML 4 was formulated -- but HTML 4 was such a radical departure from HTML 3 (if you can call dumbing it back down to HTML 2 "radical") they ended up making two versions -- Strict and Transitional. Strict is the REAL HTML meant for making semantic markup. Transitional was meant to let people who had poorly coded HTML 3 websites to slap the new doctype on it to use the handful of new tags (like OBJECT) alongside the tags and attributes that have zero business being on any site written after 1998. (like CENTER, FONT, ALIGN, BORDER, TARGET, IFRAME...)

    Naturally though, people just kept pissing out HTML 3.2, slapping tranny on it, and then wondering why their decade out of date methodologies are broken, slow and inaccessible. Dumping idiotic libraries and frameworks like blueprint, YUI, mootools and jquery on top ending up being the equivalent of dumping a can of shellac on a pile.

    Hence HTML 5 -- which seems to exist NOT for building websites in any form of better, cleaner or minimalist way, but instead to placate the people who are still crapping out HTML 3.2 and don't even realize it. Certainly isn't meant for anyone who actually embraced semantic markup...

    Which back on topic, that's the REAL reason for using DIV. If you have semantic markup -- numbered headings and horizontal rules to mark the start/end of sections, logical heading orders (which is to say H2's are the start of subsections of the H1, h3's are starts of subsections of a h2, etc, etc), paragraphs around paragraphs, lists around lists, labels, fieldsets, captions all where appropriate -- you should have a logical document structure already in place that looks fine and works fine CSS off, and is useful to users of things like screen readers. Such markup should be written using content (or a reasonable facsimile) before the mere notion of making a layout comes along -- and then the layout should be made with?

    CSS! You may add a few div as hooks to apply style, but you should NOT be saying WHAT that style is in the markup. That's the beauty of DIV and SPAN, they do NOT apply any semantic meaning to elements that should already have it. (hence my problem with HTML 5's new allegedly semantic elements -- they're applying meanings you should already have!!!). Same goes for your classes and ID's... Say what things ARE or WHY they are getting a style, NOT what that style is.

    Just part of why if I had my way, the STYLE tag would be made obsolete, and the role of the STYLE attribute be much more tightly defined since in all but the rarest of cases the former has no business in the HTML at all, and the latter should only be used when conveying extra information visually; like the font-size on a tag cloud or width/height on a percent bar. <span class="blue"> being just as ****tarded as <font color="blue">

    ... and that's where TABLE comes into it; if you use tables to make columns, you're saying the stuff inside that TD is table data; you're applying meaning that is probably inappropriate. Of course, if people bothered learning to use tables properly (yeah right) with elements like CAPTION, TH, THEAD, TBODY, etc (yeah, right) they'd probably understand their role better. (But when most developers can't even be bothered to use heading tags properly, yeah, right!)

    The separation of presentation from content becomes more important moving forward with CSS 3's improvements to the media selectors... visual concepts or starting from a single visual layout is grade A farm fresh manure in the face of so called "dynamic" layout. Just because something is a column at one resolution or on one device does NOT mean it's going to be a column on all of them. Using a table, you're stuck HOPING the user agent can strip away columns or adjust properly -- calling something a 'leftColumn' makes no sense when you may have certain resolutions change the column counts or even positions. We can now switch on the fly with ease between one, two, three, or endless numbers of columns, shifting an entire layout around to best fit and make use of the users display. TABLE based layouts just can't do that in anything remotely resembling a useful manner -- and using DIV means you aren't changing the meaning or underlying document structure since DIV has no semantic meaning.

    Again, the difference between a hook to apply presentation, and saying what that presentation is. The latter having NO place in your HTML.
     
    deathshadow, Jun 26, 2012 IP
    sarkar1990 likes this.
  6. Rukbat

    Rukbat Well-Known Member

    Messages:
    2,908
    Likes Received:
    37
    Best Answers:
    51
    Trophy Points:
    125
    #46
    Deathshadow, you should make that post a website of its own, or at least a major article on your blog if you have one. (Or offer it to some of the web development sites.) I've copied it and printed it, and it's in my notebook - that is, my book of important notes. It's one very important note. I thank you for it. (Not that I didn't know it, but you put it better than I could have, and all in one place.)
     
    Rukbat, Jun 27, 2012 IP
  7. makdesigns

    makdesigns Peon

    Messages:
    24
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #47
    I would recommend division..
     
    makdesigns, Jun 29, 2012 IP
  8. sarkar1990

    sarkar1990 Member

    Messages:
    37
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    43
    #48
    Using Tables for Designs is a thing of the Last Century. :p
    DIVs give you more customization power. You can use it to make a fluid design, a responsive design and what not. actually with the coming of HTML5, DIVs are being replaced by their semantic cousins like ARTICLE, ASIDE, NAV, HEADER, HGROUP, SECTION, FOOTER
     
    sarkar1990, Jul 1, 2012 IP
  9. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,858
    Likes Received:
    1,610
    Best Answers:
    230
    Trophy Points:
    515
    #49
    Assuming you consider those replacements, to not be redundant, or to even be semantic... Honestly, they are not replacements, if you use the existing HTML 4 tags properly they are redundant/pointless, and they're semantics serve zero real world purpose! It's why I keep saying I suspect the reason they've slapped the new CSS and new javascript stuff under HTML 5's banner -- because without them the Emperor has no clothes.

    SECTION for example sounds all rosy on the surface -- break the page 'semantically' into sections -- but isn't that numbered heading and horizontal rule's job? A numbered heading is the start of a subsection of the higher ordered heading preceeding it... H1 is the start of the main page section under which everything else is a subsection... H2's are subsections of that H1, so on and so forth. HR is the start of a subsection that doesn't have/warrant a numbered heading -- like the footer.

    As such NAV's purpose of 'skipping to the start of the main section' is pointless if you use the existing heading tags properly and have a UA that takes the time to give you heading/hr navigation. FOOTER is pointless as that would just be the section after the last HR on a page... HEADER is pointless because we already HAVE heading tags. HGROUP is idiotic BS since there is no legitimate reason to use headings that way unless you failed to grasp the entire POINT of heading tags -- using them to start a new subsection...

    Which is why every time I see someone do something idiotic like:
    <h1>Site Tite</h1>
    <h2>Tagline</h2>

    I feel the overwhelming need to pimp slap somebody. (that should typically be a small tag inside the H1 since that's all one heading! Semantically SMALL is for de-emphasis). HGROUP just justifies the practices of people who fail to grasp the point of the existing tags.

    ASIDE seems to be being abused for presentation instead of semantics -- people are using it for sidebars becuase it's placed 'off to one side' -- off to one side is NOT semantics. The only definition you'll find for ASIDE that makes the least bit of sense from a semantic point of view is a literary aside -- like in a play where the character breaks the fourth wall. That is such a rare occurrence on a website that one questions the point of having such a tag.

    They all amount to wrapping alleged semantics around elements that should already HAVE semantic meanings... It's pointless code bloat.

    In many ways I suspect that some of the elements, NAV for example, have been added JUST to justify the half-assed practice of slapping extra div around things for no reason... like UL menus when there's usually little that couldn't be applied to that tag... Just as George Carlin said 'not every ejaculation deserves a name', I say not every tag needs a DIV around it or a class/ID on it. Most of HTML 5's new tags, in particular the ones you mentioned, are nothing more than pointless idiotic bloat.

    The beauty of DIV is that it adds no semantic meaning and is just there to group things for the application of presentation; There are MORE than enough tags to provide semantic meaning already, and eventually you have to let the TEXT do the talking for you. If we follow HTML 5's idiocy to it's logical conclusion we'll soon be wrapping extra tags around every word for no good reason apart from satiating sleazeball data scrapers desires and the nubes who go "ooh, shiny".

    Even the new functionality is rubbish -- AUDIO and VIDEO being redundant to OBJECT. There is ZERO legitimate excuse those could not have simply been an extension to OBJECT with the scripting applied to same... That was the POINT of OBJECT; to reduce the number of tags (since eventually it was to supplant even IMG) and to make it so that data formats were NOT dictated by the browser makers. Of course, with the W3C being basically run by the browser makers, that particular back-pedal isn't too hard to figure out -- it's a way for them to dictate to us what video formats we're going to use instead of letting the market choose... as such we're back to square one of only having support for browser makers favorite pet codecs instead of being able to add them as desired. Don't plan on seeing jpeg2k support any time soon...

    Of course, that stems greatly from people missing that most of the tags and attributes deprecated in 4 Strict were removed for being redundant or bad accessibility, NOT for being presentational... so naturally they're undoing all of the progress of the past decade or more with this steaming pile of manure.

    To be brutally frank, not counting the actually useful stuff like CSS3 and the new scripting, and talking about JUST the markup, I cannot fathom how anyone is DUMB ENOUGH to see merit in HTML 5... and what I outlined above is just the tip of the iceberg before we talk whatWG's idiotic 'lets get rid of versioning', making forms even more uselessly complex when most people can't be bothered to use what we already have properly,

    ... and it's not like you can't use CSS3 or the new scripting on the current RECOMMENDATION Strict doctypes.

    HTML 5 - setting coding practices back to the pinnacle of browser wars stupidity. Hardly a shock with the resurgence of popups, autoplaying music, forcing the opening of new windows, endless scripting bloat, browser sniffing and 'best viewed in' banners. (or worse, warnings about your browser version). It all seems carefully crafted to satiate the desires of the sleazeballs or just plain inept who until recently vomited up HTML 3.2 and slapped a tranny doctype on it, calling themselves up to date. Now they just slap HTML 5's lip service on it -- net improvement zero. It sure as shine-ola was NOT crafted for anyone who embraced semantic markup or separation of presentation from content... which again is why I cannot fathom how anyone experienced in web development is DUMB ENOUGH to even want to try and use it.

    Though I do know a number of developers writing HTML 4.01 Strict or XHTML 1.0 Strict, validating as such, then slapping HTML 5's lip-service doctype on it just to make the clients who demand HTML 5 happy, since 99.99% of them are too stupid to actually know what HTML 5 is; they just read about it in Forbes. Which again, taking technical advice from Forbes is like taking financial advice from Popular Electronics.

    ... the only real reason it even seems to exist is to sell new versions of books, get buns into seats at lectures, and allow scumball developers to sell ignorant suits on a new sick market-speak buzzword much akin to "web 2.0". It most certainly seems to have nothing to do with writing better more accessible websites!
     
    deathshadow, Jul 1, 2012 IP
  10. Alien44

    Alien44 Member

    Messages:
    42
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    41
    #50
    Divs over tables for many reasons including SEO, faster load time, less coding, easier use of CSS.
     
    Alien44, Jul 1, 2012 IP
  11. expertwebworld

    expertwebworld Peon

    Messages:
    4
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #51
    For SEO google preferred DIV base website.Div also make your website professional.It is good to work with DIV rather than table..........
     
    expertwebworld, Jul 5, 2012 IP
  12. aaronroofing

    aaronroofing Peon

    Messages:
    78
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #52
    Basicly!!! Tables are old style.. they died with HTML3 code when CSS2 came out with divs and content aware areas.
     
    aaronroofing, Jul 6, 2012 IP
  13. IISouLII

    IISouLII Peon

    Messages:
    2
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #53
    Agree... div its easier to use than table. for me i rather chose span or div...

    @deathshadow = "The only thing you can learn from Dreamweaver is how not to build a website...." why is that so?
     
    IISouLII, Jul 8, 2012 IP
  14. payukim

    payukim Peon

    Messages:
    20
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #54
    I think div can make the code more neatly to use is to arrange your content. Using table to arrange content can make the code messy if you have many sub divisions of content, and when you revise something in the table like deleting cell, resizing, it may damage other cells in some way cos cells in table is connecting each other like a web.
    So, let's use table only when you want your content in the table form, otherwise use div.
     
    payukim, Jul 8, 2012 IP
  15. netcommlabs

    netcommlabs Peon

    Messages:
    21
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #55
    Div tag is very good for speed up page downloads,reduce markup code of a web page.
     
    netcommlabs, Jul 11, 2012 IP
  16. andiklive

    andiklive Member

    Messages:
    276
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    26
    #56
    make easyly coding maybe, div good reasons.
     
    andiklive, Jul 11, 2012 IP
  17. flashblue

    flashblue Active Member

    Messages:
    29
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    61
    #57
    I suggest you to use for HTML5-CSS3 technologies. Otherwise, your website code can't pass the validation. Then, your site can't be read by search engines properly.
     
    flashblue, Jul 18, 2012 IP
  18. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,858
    Likes Received:
    1,610
    Best Answers:
    230
    Trophy Points:
    515
    #58
    Uhm... no... If anything, the looser rules make HTML 5 validation meaningless compared to HTML 4 Strict / XHTML 1.0 Strict... Pretty much letting you sleaze out the code any old way - hence all those fancy rule clarifications on how invalid or just plain poorly formed code should be handled. Just part of how the idiotic BS known as HTML 5 exists not for people who bother to understand the point of markup, but instead to placate the sleazy lazy scumballs and ignorant twits who until a year or two ago were vomiting up HTML 3.2 and slapping a tranny doctype on it. Now they can just use the 5 lip service on their rubbish code.

    Uhm... kind-of... no, not really... An improperly/unclosed tag could result in the rest of the page being ignored by the engines, but in that case it may also not render in some browsers. Just because your code is invalid does NOT mean it will be slapped down; if that were true 90% of the Internet wouldn't work.
     
    deathshadow, Jul 18, 2012 IP
  19. semwinner

    semwinner Peon

    Messages:
    57
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    0
    #59
    In simple words, div structure is clear than table, and Google like dive more than table. Since, table need to wait for a full loading, but div do not need.
     
    semwinner, Jul 18, 2012 IP
  20. HowardBeck

    HowardBeck Peon

    Messages:
    11
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #60
    HTML is found nice tag name is div,it's not taking so many time for loading.Table and iframe both are not using in now days.Dive tag use css class.
     
    HowardBeck, Jul 18, 2012 IP