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?
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
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!
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.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
border-right:1px solid #000
<div class="dt" style="width:100%">
<div class="dtc"> cell content </div>
<div class="dtc">cell content </div>
<!-- end tr -->
[B] <hr />[/B]
Run the above code and it exhibits the problem you mention.
It would be the same as saying.
<table cellspacing="0" cellpadding="0">
[B] <hr />[/B]
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.
<label for="ctl00_MainContent_fvRestaurantDetail_repContacts_ctl01_txtTitle" id="ctl00_MainContent_fvRestaurantDetail_repContacts_ctl01_lblName">Name</label>
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.
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.
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".
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!
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.
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.
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!
I'm off there, right now!
Again, thanks for your help, support and time.