Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 16
  1. #1
    Senior Coder
    Join Date
    May 2006
    Posts
    1,673
    Thanks
    28
    Thanked 4 Times in 4 Posts

    Basic Table - cellpadding not working.

    Hi,

    I haven't used tables for a while now
    but this really is something which looks like it should be
    tabulated.

    Only the first row is shown but for some reason the
    cellpadding does not seem to be working.

    Code:
    <div class="asset_box" >
    <span class="assetHead">MyStuff</span>
    <div class="in_box" >
     						
    
    <table border=1 cellpadding=20>
     <tr>
       <th>Campain No.</th>
       <th> Category</th>
       <th>Campaign Title</th>
       </tr>
     <tr style="color: black;">
    <td>1</td>
    <td>The </td>
    <td>Number One</td>
    <td><a href="edit_camp.php?a=1">Edit</a></td>
    </tr></table>				
    </div> <!-- End div: in_box -->
    </div> <!-- End div: asset_box -->
    Any obvious reasons why this might be ?



    Thanks.

    ... Maybe I will use divs and spans after all




    .
    Last edited by jeddi; 01-22-2012 at 07:56 PM.
    If you want to attract and keep more clients, then offer great customer support.

    Support-Focus.com. automates the process and gives you a trust seal to place on your website.
    I recommend that you at least take the 30 day free trial.

  • #2
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,589
    Thanks
    0
    Thanked 644 Times in 634 Posts
    The cell padding (and the border) really out to be defined using CSS rather than in the HTML.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #3
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,300
    Thanks
    28
    Thanked 275 Times in 269 Posts
    Quote Originally Posted by jeddi View Post
    Any obvious reasons why this might be ?
    Perhaps the problem is a result of having one row with three columns and another row with four columns in the same table. Use a colspan attribute or even up the number of cells in each row.

    As felgall indicated, cell padding should be specified with CSS: th, td { padding: 20px; } or tr > * { padding: 20px; }. The cellpadding attribute is "deprecated" in HTML 4.01 and "obsolete" in HTML5.

    Likewise with the border attribute.
    For every complex problem, there is an answer that is clear, simple, and wrong.

  • #4
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,589
    Thanks
    0
    Thanked 644 Times in 634 Posts
    Quote Originally Posted by Arbitrator View Post
    The cellpadding attribute is "deprecated" in HTML 4.01 and "obsolete" in HTML5.
    It is only deprecated in HTML 4 if they actually delete it in HTML 5. If it is obsolete in HTML 5 then that means it isn't deprecated in HTML 4 but is merely obsolete.

    Deprecated means obsolete now and completely deleted from the next version. So it can't exist at all in HTML 5 if it is deprecated in HTML 4. That it still exists in HTML 5 implies that its status in HTML 4 has been downgraded from deprecated to obsolete.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #5
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,300
    Thanks
    28
    Thanked 275 Times in 269 Posts
    Quote Originally Posted by Arbitrator View Post
    The cellpadding attribute is "deprecated" in HTML 4.01 ...
    Apparently, my memory was a bit off. The cellpadding attribute was not formally or implicitly deprecated in HTML 4.01. The attribute is allowed even in HTML 4.01 Strict.

    Quote Originally Posted by felgall View Post
    It is only deprecated in HTML 4 if they actually delete it in HTML 5. If it is obsolete in HTML 5 then that means it isn't deprecated in HTML 4 but is merely obsolete.

    Deprecated means obsolete now and completely deleted from the next version. So it can't exist at all in HTML 5 if it is deprecated in HTML 4. That it still exists in HTML 5 implies that its status in HTML 4 has been downgraded from deprecated to obsolete.
    All of this information is either incorrect or nonsense.

    Elements and attributes in HTML 4.01 are explicitly listed as "deprecated" or "obsolete" or were implicitly deprecated by exclusion in HTML 4.01 Strict. Those statuses have no relationship to how they are defined in HTML5.

    HTML5 loosely uses the term "obsolete" for features that should not be used or should be avoided, and this use does not mirror the HTML 4.01 definition of the term.

    Further, a number of HTML 4.01's "deprecated" and implicitly deprecated features do, in fact, exist in HTML5, and some of them are now "conforming" features.
    Last edited by Arbitrator; 01-23-2012 at 10:18 AM. Reason: I added futher explanation.
    For every complex problem, there is an answer that is clear, simple, and wrong.

  • #6
    Regular Coder riptide's Avatar
    Join Date
    Jan 2007
    Posts
    143
    Thanks
    1
    Thanked 0 Times in 0 Posts
    sounds complicated do I even need to use HTML4?

  • #7
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,300
    Thanks
    28
    Thanked 275 Times in 269 Posts
    Quote Originally Posted by riptide View Post
    sounds complicated do I even need to use HTML4?
    It's a good idea to be familiar with HTML4, but I'd say that all new documents should be written with HTML5 in mind at this point.
    For every complex problem, there is an answer that is clear, simple, and wrong.

  • #8
    New Coder
    Join Date
    Dec 2007
    Posts
    43
    Thanks
    9
    Thanked 0 Times in 0 Posts
    its also good practice to use <tbody> after the <tr> once its not a <th>
    http://anothera.net | New Era Art Group

  • #9
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,589
    Thanks
    0
    Thanked 644 Times in 634 Posts
    Quote Originally Posted by Arbitrator View Post
    It's a good idea to be familiar with HTML4, but I'd say that all new documents should be written with HTML5 in mind at this point.
    HTML 5 is only adding tags and all of the HTML 4 ones (with very few exceptions) will still apply. There isn't anything currently proposed for HTML 5 that would affect the definition of tables.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #10
    Regular Coder riptide's Avatar
    Join Date
    Jan 2007
    Posts
    143
    Thanks
    1
    Thanked 0 Times in 0 Posts
    I did't know anything about it because I've been coding in xhtml the entire time.

  • #11
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,300
    Thanks
    28
    Thanked 275 Times in 269 Posts
    Quote Originally Posted by felgall View Post
    ... all of the HTML 4 ones (with very few exceptions) will still apply.
    Right. This is a good reason to use HTML5. You can stick with the HTML4 set of elements if you aren't ready to deal with compatibility issues and you don't have to deal with the arcane rules of HTML4; for example, you can avoid the verbose DOCTYPE declarations, SGML processing rules, and type attributes.

    Quote Originally Posted by felgall View Post
    There isn't anything currently proposed for HTML 5 that would affect the definition of tables.
    Sure there is; use of the cellpadding attribute is a spec violation: http://www.whatwg.org/specs/web-apps...le-cellpadding.
    For every complex problem, there is an answer that is clear, simple, and wrong.

  • #12
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,300
    Thanks
    28
    Thanked 275 Times in 269 Posts
    Quote Originally Posted by riptide View Post
    I did't know anything about it because I've been coding in xhtml the entire time.
    Most XHTML is de facto HTML5 too, so you should probably move to HTML5 also. (Or you could move to XHTML5, but make sure you use an *.xhtml, *.xht, or *.xml file extension.)
    For every complex problem, there is an answer that is clear, simple, and wrong.

  • #13
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,589
    Thanks
    0
    Thanked 644 Times in 634 Posts
    Quote Originally Posted by Arbitrator View Post
    Right. This is a good reason to use HTML5. You can stick with the HTML4 set of elements if you aren't ready to deal with compatibility issues and you don't have to deal with the arcane rules of HTML4; for example, you can avoid the verbose DOCTYPE declarations, SGML processing rules, and type attributes.
    You can use the SGML <!DOCTYPE HTML> doctype with any any version of HTML between HTML 2 and HTML 4.01. It is a perfectly valid short version where you want to identify that you have an SGML document that uses HTML where you don't have a need to specify the particular version of HTML used.

    Just to add to the confusion though HTML 5 which is not defined using the SGML standard and therefore can't have an SGML doctype defines <!DOCTYPE HTML> as an HTML tag.

    Therefore that doctype can be used with ANY version of HTML between 2 and 5.

    As for any rules with HTML 5 - since it is just an early draft there is nothing definite about what tags and attributes it will have once it becomes a standard but most likely all of those in HTML 4 and XHTML 1 will still be there with perhaps one or two being marked as obsolete. HTML 5 is also proposing to change the HTML 4 standard as well by downgrading all the deprecated tags from HTML 3.2 that 95% of web sites still use from deprecated to merely obsolete - since if they were to leave them as deprecated in HTML 4 then that means that they cannot be used in HTML 5 (since deprecated means obsolete in this version and gone completely in the next).

    All the so called 'arcane' rules of HTML 4 still apply in HTML 5. The only difference using HTML 5 rather than 4 makes is that you can experiment with the proposed new tags to help decide which of them are actually useful additions to HTML. Since the proposal currently contains some contradictory options they obviously can't all survive until when HTML 5 eventually becomes a standard and people start using the actual final standard (if it ever does - HTML 4 did become a standard in 1997 and 95%+ of web sites are still transitioning from HTML 3.2).

    For an example of contradictory options consider these two attributes that HTML 5 proposes you be allowed to add to form fields - required pattern="^$" where the first states that the field must contain something while the second states that it must be empty. Presumably since the 'required' attribute has been made obsolete by the 'pattern' attribute there is no reason for it to survive into the final standard - since specifying pattern=".*" means that the field is required but its content can be anything (which is as much as required by itself means but without the possibility of a contradictory pattern).

    Another example is the <iframe> tag. The HTML 4 replacement for that new HTML 5 tag which has never been a part of any prior standard is the <object> tag which is just as simple to code provided that you don't need to deal with IE6 or earlier (which is just about dead now). There are a couple of minor things that don't quite work with the object tag in IE7 and 8 (you can't adjust the border) but the tag works fine in IE9 and all other modern browsers and so a longer alternative code using <iframe> (currently a proprietary tag which the HTML 4 standard treats as an HTML 3.2 tag even though it wasn't a part of HTML at all) will cease to be necessary long before everyone is using a browser that supports HTML 5 (which none currently do - some do support some of the proposals but they can't support the entire standard because it doesn't exist yet). So when IE6 or IE8 finally dies <iframe> will be completely unnecessary as a shorter <object> tag can replace it.

    I'd be surprised if more than half of the current proposals for HTML 5 survive to become a part of the standard without undergoing significant modification. You also need to remember that IE5 started implementing CSS 2 when it was far closer to becoming a standard than HTML 5 currently is - the standard was subsequently changed so that IE5 no longer followed the standard leading to IE6+ needing to use the presence or absence of an SGML doctype as a switch to determine whether to follow the draft CSS 2 version implemented in IE5 or the final CSS 2 standard in rendering the page. If there hadn't been so many sites started using draft code subject to change which eventually did change then browsers would still not need to care about whether the SGML tag at the top identifying the content as HTML was present or not and HTML 5 which has decided to not follow the standards for defining markup languages would not need to add a doctype tag into HTML.

    For 99.999999999% of people it will be far more effective for them to concentrate on getting rid of all the HTML 3.2 tags in their code. That will make it far easier come 2025 or 2030 when HTML 5 does finally become a standard for them to update their pages to follow that new standard in only 5 or so years instead of the nearly 15 with no end in sight that most sites have taken to transition from HTML 3.2 to 4.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #14
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,589
    Thanks
    0
    Thanked 644 Times in 634 Posts
    Quote Originally Posted by Arbitrator View Post
    Right. This is a good reason to use HTML5. You can stick with the HTML4 set of elements if you aren't ready to deal with compatibility issues and you don't have to deal with the arcane rules of HTML4; for example, you can avoid the verbose DOCTYPE declarations, SGML processing rules, and type attributes.
    You can use the SGML <!DOCTYPE HTML> doctype with any any version of HTML between HTML 2 and HTML 4.01. It is a perfectly valid short version where you want to identify that you have an SGML document that uses HTML where you don't have a need to specify the particular version of HTML used.

    Just to add to the confusion though HTML 5 which is not defined using the SGML standard and therefore can't have an SGML doctype defines <!DOCTYPE HTML> as an HTML tag.

    Therefore that doctype can be used with ANY version of HTML between 2 and 5.

    As for any rules with HTML 5 - since it is just an early draft there is nothing definite about what tags and attributes it will have once it becomes a standard but most likely all of those in HTML 4 and XHTML 1 will still be there with perhaps one or two being marked as obsolete. HTML 5 is also proposing to change the HTML 4 standard as well by downgrading all the deprecated tags from HTML 3.2 that 95% of web sites still use from deprecated to merely obsolete - since if they were to leave them as deprecated in HTML 4 then that means that they cannot be used in HTML 5 (since deprecated means obsolete in this version and gone completely in the next).

    All the so called 'arcane' rules of HTML 4 still apply in HTML 5. The only difference using HTML 5 rather than 4 makes is that you can experiment with the proposed new tags to help decide which of them are actually useful additions to HTML. Since the proposal currently contains some contradictory options they obviously can't all survive until when HTML 5 eventually becomes a standard and people start using the actual final standard (if it ever does - HTML 4 did become a standard in 1997 and 95%+ of web sites are still transitioning from HTML 3.2).

    For an example of contradictory options consider these two attributes that HTML 5 proposes you be allowed to add to form fields - required pattern="^$" where the first states that the field must contain something while the second states that it must be empty. Presumably since the 'required' attribute has been made obsolete by the 'pattern' attribute there is no reason for it to survive into the final standard - since specifying pattern=".*" means that the field is required but its content can be anything (which is as much as required by itself means but without the possibility of a contradictory pattern).

    Another example is the <iframe> tag. The HTML 4 replacement for that new HTML 5 tag which has never been a part of any prior standard is the <object> tag which is just as simple to code provided that you don't need to deal with IE6 or earlier (which is just about dead now). There are a couple of minor things that don't quite work with the object tag in IE7 and 8 (you can't adjust the border) but the tag works fine in IE9 and all other modern browsers and so a longer alternative code using <iframe> (currently a proprietary tag which the HTML 4 standard treats as an HTML 3.2 tag even though it wasn't a part of HTML at all) will cease to be necessary long before everyone is using a browser that supports HTML 5 (which none currently do - some do support some of the proposals but they can't support the entire standard because it doesn't exist yet). So when IE6 or IE8 finally dies <iframe> will be completely unnecessary as a shorter <object> tag can replace it.

    I'd be surprised if more than half of the current proposals for HTML 5 survive to become a part of the standard without undergoing significant modification. You also need to remember that IE5 started implementing CSS 2 when it was far closer to becoming a standard than HTML 5 currently is - the standard was subsequently changed so that IE5 no longer followed the standard leading to IE6+ needing to use the presence or absence of an SGML doctype as a switch to determine whether to follow the draft CSS 2 version implemented in IE5 or the final CSS 2 standard in rendering the page. If there hadn't been so many sites started using draft code subject to change which eventually did change then browsers would still not need to care about whether the SGML tag at the top identifying the content as HTML was present or not and HTML 5 which has decided to not follow the standards for defining markup languages would not need to add a doctype tag into HTML.

    For 99.999999999% of people it will be far more effective for them to concentrate on getting rid of all the HTML 3.2 tags in their code. That will make it far easier come 2025 or 2030 when HTML 5 does finally become a standard for them to update their pages to follow that new standard in only 5 or so years instead of the nearly 15 with no end in sight that most sites have taken to transition from HTML 3.2 to 4.

    Quote Originally Posted by Arbitrator View Post
    Sure there is; use of the cellpadding attribute is a spec violation
    It isn't valid in HTML 4 either. It is deprecated which means that it is an HTML 3.2 attribute marked as obsolete in HTML 4 and to be removed in HTML 5. It just sounds like in this instance HTML 5 is actually following what the HTML 4 standard says it is supposed to do with that attribute. HTML 4 states that it should be gone from HTML 5 - that's what deprecated means.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #15
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,589
    Thanks
    0
    Thanked 644 Times in 634 Posts
    Quote Originally Posted by Arbitrator View Post
    Most XHTML is de facto HTML5 too
    No it isn't but then very few people are actually using XHTML yet because IE8 doesn't support it - XHTML pages served to IE8 get offered for download instead of being displayed in the browser.

    Of course the new standard is actually (X)HTML 5 since XHTML will become a practical alternative long before the new standard is finiished and so they need to be ready for both professionals using XHTML and hobbyists using HTML (although the latter will probably stick with the HTML 3.2 they currently use).
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •