SitePoint Sponsor

User Tag List

Results 1 to 7 of 7
  1. #1
    SitePoint Enthusiast
    Join Date
    Sep 2009
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    How does HR work out its width?

    I'm working in a world where I am lucky[?] enough to be able to assume standards compliant browsers and am therefore using CSS table styles.

    I have two pretty much identical repeating "table" layouts (actually generated by a .NET repeater). In between each table occurrence I have a simple "HR" to get a separator line.

    The appearance (same in IE8 and FireFox) of the separator in the first set of tables is as I expect/want - the HR sizes itself to the width of the CSS table.

    The appearance (again same in IE8 and FireFox) of the separator in the second set of tables is narrower - the HR sizes itself to the width of the first cell within the CSS table.

    I am obviously missing something simple. I've had a good look through the CSS view in the IE8 developer tools and can't see any difference.

    If anyone has seen this before I'd appreciate a pointer. Also, as a start point, can someone explain where the HR tag picks up its sizing from?

    Thanks, Nick.

  2. #2
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,367
    Mentioned
    180 Post(s)
    Tagged
    6 Thread(s)
    Hi,

    I can't quite visualise what you have. Any chance you could paste a rough demo of the problem as it sounds quite interesting

    The default width of the hr element is 100%, i.e., the rule extends across the entire canvas.

    If the element is inside a table cell that has no or little width (or no content) then it will only stretch as wide as that cell or as wide as the first cell in that column.

    I might be able to clarify more if I could see the example

  3. #3
    SitePoint Enthusiast
    Join Date
    Sep 2009
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Paul,

    Thanks for offering to have a look! I think the easiest way to show you is to give you some access to the actual site. So, have a look here.

    You'll be confronted with a logon screen - use "temp" and "abc123#" (and, yes, I do need to sort out the layout on that logon screen). You'll have access to very little, but you will be able to select Manage Restaurant from the menu.

    You'll see three "tabs" on the Restaurant Management screen. Contact Details has an HR which is doing what I need. Address Details shows the behaviour that I don't want. I've tried ripping out various chunks of the markup in Address Details to try and find the issue, but it's being very stubborn.

    As I said it's probably very simple and obvious -- I just can't see it!

    Thanks!!

    Nick

  4. #4
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,367
    Mentioned
    180 Post(s)
    Tagged
    6 Thread(s)
    Hi,

    As far as I can see the problem is that you are not being true to the table.

    This is the structure you are using.

    Code:
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Untitled Document</title>
    <style>
    .dt {
        display:table
    }
    .dtr {
        display:table-row
    }
    .dtc {
        display:table-cell;
        padding:20px;
        background:red;
        border-right:1px solid #000
    }
    </style>
    </head>
    <body>
    <div class="dt" style="width:100&#37;">
        <div class="dtr">
            <div class="dtc"> cell content </div>
            <div class="dtc">cell content </div>
        </div>
        <!-- end tr -->
        <hr />
    </div>
    </body>
    </html>
    Run the above code and it exhibits the problem you mention.

    It would be the same as saying.

    Code:
    <table cellspacing="0" cellpadding="0">
        <tr>
            <td>&nbsp;</td>
            <td>&nbsp;</td>
        </tr>
        <hr />
    </table>
    You can't have a hr in that position. All content must be within a table cell. The hr is basically being treated as the first cell in an anonymous row.

    For your routine to work correctly you would need to follow the same format that you would in a table to get a horizontal rule. Either close the table or apply a border to the bottom of the last cells.

    The reason that the border stretches 100% on some elements is because you have actually omitted the table cell structure altogether and effectively have one 100% wide cell. You go straight from a table row into content.

    Code:
    <div class="DPformRow">
      <label for="ctl00_MainContent_fvRestaurantDetail_repContacts_ctl01_txtTitle" id="ctl00_MainContent_fvRestaurantDetail_repContacts_ctl01_lblName">Name</label>
       <input name=
    The rules for the css table model say that the first cell of each row belongs to the first column which means that where you have just the "hr" in that odd position the browsers will automatically construct the missing elements such as a table-row and assume that the cell is the same width as the first cell in the previous rows.

    I should also point out that your data looks tabular and for that reason the table element would actually be the most semantic element to use. The CSS display:table property is meant for producing only the visual effect of a table structure. It is not meant as a replacement for tables that hold tabular data.

    Quote Originally Posted by w3c
    Table layout can be used to represent tabular relationships between data. Authors specify these relationships in the document language and can specify their presentation using CSS 2.1.
    In a visual medium, CSS tables can also be used to achieve specific layouts. In this case, authors should not use table-related elements in the document language, but should apply the CSS to the relevant structural elements to achieve the desired layout.

    Hope that makes some sense

  5. #5
    SitePoint Enthusiast
    Join Date
    Sep 2009
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Paul,

    Thank you!!

    Quote Originally Posted by Paul O'B View Post
    Hope that makes some sense
    Not only does it make some sense, it makes perfect sense. Many, many thanks for the time that you have obviously spent on this.

    Quote Originally Posted by Paul O'B View Post
    The reason that the border stretches 100% on some elements is because you have actually omitted the table cell structure altogether and effectively have one 100% wide cell. You go straight from a table row into content.
    This points to the fact that I was "lucky" that the first tab worked the way I wanted/expected and that no amount of tweaking the second example was going to make it fall into line.

    Spelt out the way you have, it is very clear. I think I was struggling with the ASP.NET end of things where the HR was sitting neatly in an ItemSeparator element and therefore it was not at all obvious (although it is with hindsight of course) that it was in the middle of a "table".

    Quote Originally Posted by Paul O'B View Post
    I should also point out that your data looks tabular and for that reason the table element would actually be the most semantic element to use. The CSS display:table property is meant for producing only the visual effect of a table structure. It is not meant as a replacement for tables that hold tabular data.
    Indeed - it would be good to understand the "consensus of current thinking" here. I guess I have developed an aversion to using "proper" tables for anything except truly tabular data. Maybe I have gone too far? It would be interesting to have some views on where a sensible "breakpoint" should be, based on how "tabular" the data needs to be before using "old fashioned" tables becomes "acceptable".

    Thanks again, Paul for the excellent pointers!

    Nick

  6. #6
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,367
    Mentioned
    180 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by NickLocke View Post
    Paul,

    Indeed - it would be good to understand the "consensus of current thinking" here. I guess I have developed an aversion to using "proper" tables for anything except truly tabular data. Maybe I have gone too far? It would be interesting to have some views on where a sensible "breakpoint" should be, based on how "tabular" the data needs to be before using "old fashioned" tables becomes "acceptable".

    Thanks again, Paul for the excellent pointers!
    Nick
    The way I look at it is when you have a definite relationship between items in a grid structure (either horizontally or vertically).

    However, I may have to retract my previous statement and looking closely at your data it seems to be "all" form oriented and generally form data is not considered to be tabular data so perhaps you were actually correct in using the display table properties instead.

    I usually use floats for form alignment but it can get awkward if they are complex and if the form data can be arrange in neat rows and columns the display:table should be fine. The problem with display:table is when you want rowspan or colspan effects which aren't natively implemented and become awkward to achieve.

    If you look at the sticky FAQ thread at the top of the forum there is a thread that discusses using the display:table property that may be of interest.

  7. #7
    SitePoint Enthusiast
    Join Date
    Sep 2009
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Paul O'B View Post
    The way I look at it is when you have a definite relationship between items in a grid structure (either horizontally or vertically).

    .....looking closely at your data it seems to be "all" form oriented and generally form data is not considered to be tabular data so perhaps you were actually correct in using the display table properties instead.
    Thanks for the ideas - maybe it's even a halfway house. Perhaps the repeating groups are "truly" tabular and therefore a candidate for "true" tables, whereas the detailed content of each cell gets treated as a form. That sounds horrendous, but might actually allow a degree of backwards (ie IE) compatibility, even though I don't strictly need it.

    Quote Originally Posted by Paul O'B View Post
    I usually use floats for form alignment but it can get awkward if they are complex and if the form data can be arrange in neat rows and columns the display:table should be fine. The problem with display:table is when you want rowspan or colspan effects which aren't natively implemented and become awkward to achieve.
    It was the desire to get away from floats that led to me playing with the "new" stuff. The second of my two tabs did indeed hit the [lack of] rowspan challenge and led to nested presentation which [probably] only served to confuse me further!

    Quote Originally Posted by Paul O'B View Post
    If you look at the sticky FAQ thread at the top of the forum there is a thread that discusses using the display:table property that may be of interest.
    I'm off there, right now!

    Again, thanks for your help, support and time.

    Nick


Bookmarks

Posting Permissions

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