Here's an odd rendering difference between IE and other browsers.
Internet Explorer 8
Firefox 3.5
Chrome 5
See the difference? That vertical line suddenly stops in IE8. That's because IE8 refuses to display a certain background image. Here's a relevant snippet of CSS code:
td#leftbar {
background: url(img/leftbar.gif) repeat-y right top;
width: 100px;
}
You can get additional information by viewing the website on your own computer here: http://labs.pieterdedecker.be/vspwpg/
The problem is not leftbar: It is the leftbartop table cell stretching all the way down to the bottom. That is because leftbartop is in the same table row as the content.
In fact, I think IE is the only browser doing this correctly: All elements in the tr get forced to the same height. IE is ignoring the columns' rowspan properties for some reason. Why, I do not know.
The first thing that comes to mind in terms of a solution - unless somebody comes up with an explanation for this behviour - is having a separate table on the left-hand side with the first (leftbartop) and third rows (leftbarbottom) having a fixed height.
Oh, and using tables for layout is no longer socially acceptable. Just as a side note :)
I'll second Pekka's comment about avoiding tables for layouts, but since proposing serious structural changes would be a bit extreme, the following CSS seem to work well enough to fix the problem:
TABLE#body {
background:url(img/leftbar.gif) repeat-y 94px top;
border-collapse:collapse;
width:100%;
}
TD#leftbar {
width:100px;
}
TD#leftbarbottom {
background:#FFFFFF url(img/leftbarbottom.gif) no-repeat right top;
height:100px;
}
As far as why there is a difference between IE and Firefox/Chrome, the only potentially relevant piece of information that I could find right now was the CSS 2.1 section on table height, which states:
CSS 2.1 does not specify how cells
that span more than one row affect row
height calculations except that the
sum of the row heights involved must
be great enough to encompass the cell
spanning the rows.
So, not only is IE's behaviour bizarre, there's doesn't seem to be a clear cut explanation of what should happen. In IE's case, space required by the multi-row cells appears to be divided up using some sort of relative percentages related to the minimum height of each included row.
To illustrate this, you can cause #leftbar to take up all the space it's leaving empty now by using the following rules:
TD#leftbartop {
height:1px;
}
TD#leftbar {
height:150px;
}
Another interesting example is a 1/3, 2/3 split:
TD#leftbartop {
height:33px;
}
TD#leftbar {
height:66px;
}
Note that if you set the height to something unreasonably small (like 1px in the earlier example), it calculates a height for that cell that is not based on the relative percentage, but something else. I'm not sure where that comes from right now, but I'll play around with the numbers and see if I can take a guess at it later on.
Related
can you please let me know if there is any chance to make that the label wraps itself and do not go like in the picture ("Change Change Change..."):
I use "no more tables" here and always get that issue with longer labels - they just do not wrap. I understand that the white-space in css is "nowrap", but if I change it to "normal", everything goes wrong and displays badly. Maybe someone had an issue with this "no more tables" technique and word-wrapping?
More about this script can be fuonde here http://elvery.net/demo/responsive-tables/
That example uses absolute positioning to move the generated content to the start of the rows and is a flawed approach as that means that the content cannot wrap because it will overlap the content in the next row. That's why the nowrap rule is in place to stop this happening.
Instead of absolute positioning you could use display:inline-block instead and avoid the issue altogether.
In the code from here change these two rules as follows:
td {
border: none;
border-bottom: 1px solid #eee;
position: relative;
}
td:before {
display:inline-block;
vertical-align:top;
width: 45%;
padding:0 3% 0 1%;
}
Rough example here:
Updated code as per comments below:
td:before {
float:left;
width: 95%;
padding:0 0 0 1%;
margin-left:-100%;
}
td {
padding-left:50%;
-moz-box-sizing:border-box;
-webkit-box-sizing:border-box;
box-sizing:border-box;
}
You need to break the words if they are too long. You can make this in css as:
word-wrap:break-word;
Try it.
The main issue here has to do with sizing one HTML element based on another element. This is something that tables are optimized to do - calculating the height and width of TD elements across the entire table to a uniform size dynamically based on content.
By abandoning tables (via changing the display type of THEAD to "block", effectively making it nothing more than a DIV), you've lost this automatic resizing effect that browsers do for you, as evidenced here:
There's no getting around this. The "No More Tables" approach must make a compromise - use absolute height to mimic the way tables are laid out. You are trying to reintroduce this automatic size calculation, but you can't without restructuring your HTML.
If you want to continue to pursue this path, you'd need to "manually" handle resizing of the TD elements - iterate over the cells of the table and resize them yourself whenever the size of table might have changed. While possible, your Javascript won't be nearly as optimized as the browser and anything you implement yourself will likely be buggy and slow.
I'm afraid the only viable solution is to shorten your label names and accept the need for absolute sizing to get around the lack of dynamic sizing in non-TABLE elements.
One possible solution: show an abbreviated label and then show a longer name in a popup on hover or tap: Tooltips for mobile browsers
Problem: In one type of embedded styling "overflow:hidden" is working fine, and in another type of embedded styling it does not.
Here is the CSSDesk code (jsfiddle is not working as of this writing).
Background: In my project I have to use HUGE tables to show variables coming from a db - up to 75 variables per page. I tried my best using divs alone, but I wasted 20 hours and ultimately, I went back to tables (For you CSS purists, I apologize).
In some of my td's the data is a bit long, and needs to be "hidden" (it doesn't matter in this particular case because the data is just a "preview"). I've searched the web, and did an experiment in which the only styling element that could use "hidden" is a div (I tried tds and spans in an experiment and they don't work).
In one td, I'd like to put one variable on the left, and another on the right - most of the time, both will fit into the td, but on a very long variable it's OK to chop off part of the right variable. So, I write the CSS and html, and style the divs so that they meet my criteria - those are the upper two tds on the CSSDesk page noted above. Everything works fine.
BUT! Over the last few months I've learned that it's possible to "mix" multiple styles in the "class" part of the element identifier (e.g. <td class="redcolor blueunderline">) and I've found that on many occasions it is VERY convenient to use "little additions" on an element that is the only one on a page, and you'd have to rewrite/add a whole embedded style or change the style sheet (e.g. Name, address, phone number, zip and you only want to "bold" the name - class="identifers" vs class="identifiers bold") - I wonder if you experts ever do something like that?
So I played a bit and got most of it working EXCEPT for the "overflow:hidden".
For the upper left div in the CSSDesk example I use this CSS and html (it works great):
.leftdivclass {
float:left;
background-color:green;
color:black;
border:2px solid yellow;
overflow:hidden;
white-space:nowrap;
width:25%;}
<td><div class="leftdivclass" >Upper Left 123456789</div>
For the upper right div in the CSSDesk example I use this CSS and html (it works great):
.rightdivclass {
float:right;
background-color:red;
color:black;
border:2px solid yellow;
overflow:hidden;
white-space:nowrap;
width:25%;}
<div class="rightdivclass" >Upper Right 123456789</div></td>
For the lower left div in the CSSDesk example I use this CSS and html (everything works but the "hidden" - note the numbers sticking out)
.floatleft {
float:left;}
.bgblue {
background-color:blue;}
.bgred {
background-color:red;}
.lcwhite {
color:white;}
.lcblack {
color:black;}
.border2y {
border:2px solid yellow;}
overflowhidden {
overflow:hidden;}
.wsnowrap {
white-space:nowrap;}
.width25pc {
width:25%;}
<td><div class="floatleft bgblue lcblack border2y overflowhidden wsnowrap width25pc">Lower Left 123456789</div>
But if I use the same html and add "style="overflow:hidden" everything works fine, like in the lower right example of the CSSDesk example.
<div class="floatright bgred lcblack border2y overflowhidden wsnowrap width25pc" style="overflow:hidden;">Lower Right 123456789</div></td>
Questions:
Why would a single embedded css style containing "overflow:hidden" work, yet when it is parsed out to a single addition to a class command it doesn't work? And why would it work if I added "style="overflow:hidden" - inline?
Do you experts ever use little "class snippets" like this?
Again, I thank you in advance.
You can mix and match these classes. If it saves redundancy, great. If it confuses classes and container classes (i.e. the parents they are inside of) then it gets kind of hard to debug your problem.
Most likely it's not working because either its parent or another class is conflicted with the overflow property. Inline styles like style="overflow:hidden;" almost always get prioritized the highest, but remember that overflow has a default property of visible.
If you call 2 classes, one having overflow:hidden; and the other overflow:visible;, then there's a chance that you won't get your desired effect.
Keep in mind, too, that a selector like this
#divid .divclass
will always win over
.divclass
and will be treated with greater priority.
Also, have you tried
overflow:hidden !important;
which tends to take precedence over everything. Hope that helps.
Having seen advice seemingly change over the years regarding use of empty DIVs (ie. <DIV CLASS="somediv"></DIV>) I'm confused as to the current thinking over whether or not to use when a DIV will have no inner HTML.
I can find no definitive confirmation over whether we can rely on all modern browsers to display background color and image correctly at the specified width & height when there is no inner HTML, so I'm thinking maybe we can't rely on it - yet it's such a seemingly basic area.
I have even seen suggestions that empty DIVs should never be used - but do specs really state it is 'wrong' to have empty DIVs, or is it just unreliable? (I've tried finding reference to them, but maybe I'm using the wrong terms).
To illustrate, here are 5 areas where I would normally use an empty DIV, in the absence of any recommended alternative:
as a placeholder for content which will subsequently be fetched by XHR calls
as a way to manually create space in a layout
where an image is defined in CSS (as a background image, but will effectively be foreground)
where the text will come from the CSS using .somediv:after{content:SOMETEXT}
where CSS is used to display graph bars etc using solid background color
Maybe there are different answers for each of these, which might explain the complexity over this issue.
I have, of course, tried discovering already, but for example the SO question Is necessary to show an empty <div>? suggests to me there is a huge amount of "IMHO", "probably", "seems to work" in this area. I would expect that by now that some official consensus has been reached on best practice.
So.. should I use and if so should I set font-size to the same as the smaller of DIV width/height to ensure that space is filled in all browsers? Are there any other CSS tricks to ensure this will work in all browsers?
The browser is not going to discard or forget your container just because it does not have any contents (yet).
If you want the container to have a specific placeholder shape, then you might give it min-height, min-width, height and width and make sure it's display: block;.
If you are still unsure, you can fill it with a spacer.gif/png without padding and margin.
http://jsfiddle.net/APxNF/1/
Short answer. Yes, browsers will render the div even if there is no content.
Long answer, That might now always be the case. I have worked in the web for 8 years now and never had to use these, but here they are anyway.
jsFiddle demo
HTML
<div class="empty1"></div>
<div class="empty2"></div>
<div class="empty3"></div>
CSS
.empty1 {
background: #FBB829;
height: 100px;
width: 100px;
}
.empty2:before {
content: "\00a0";
}
.empty2 {
background: #FF0066;
height: 100px;
width: 100px;
}
.empty3 {
background: #F02311;
min-height: 1px;
height: 100px;
width: 100px;
}
Sources:
Experience
Empty div with 2px width and background color doesnt show with height as 100%
http://csscreator.com/node/36023
I have searched a lot for centering a div, both horizontally and vertically, this is the method given everywhere:
div {
position:fixed;
top:50%;
left:50%;
margin-left:(div width/2)
margin-top: (div height/2)
}
I just found a new solution to centering a div, both horizontally and vertically, by wrapping it inside a table. I've tested it in ie7 and above, plus other browsers.
Here is an example : http://jsbin.com/ocenok/2/
I was wondering that the first method is found everywhere on the internet, SO, etc. and requires beforehand knowledge of width and height, or is usually calculated via Javascript.
The table approach seems flawless, and requires neither javascript, nor fixed height/width.
Are there any drawbacks to the table approach ?
(I do not know the height/width of the div that I want to center.)
Update (To make my question clearer) :
I myself hate using tables for non-tabular/layout data.
I know that what I want can easily be achieved using Javascript.
I figured I can achieve this using display:table, killing IE7 support.
But what I'm trying to understand is, that when I can achieve this using a single <table> element, what are the drawbacks, if any.
Checking Answers here and on similar questions, no one has recommended this method, even though it uses all valid HTML elements and syntax and rules.
If everyone is recommending to use javascript to handle presentation, even though it is easily possible using CSS, it must have some drawbacks.
Code :
<table>
<tr>
<td>
<div>This is div that needs to be centered.</div>
</td>
</tr>
</table>
and then apply the following CSS
table {
width:100%;
height:100%;
position:fixed;
top:0;
left:0;
}
table td {
width : 100%;
text-align: center;
}
div {
width:100px;
height:100px;
background:pink;
margin: 0 auto;
}
see the below function and change as per your needs
function positionLightboxImage() {
var top = ($(window).height() - $('#lightbox').height()) / 2;
var left = ($(window).width() - $('#lightbox').width()) / 2;
console.log("The calculated position is:");
console.log(top,left);
$('#lightbox')
.css({
'top': top + $(document).scrollTop(),
'left': left
})
.fadeIn();
console.log('A jQuery selection:');
console.log($('#lightbox'));
}
Updated answer HTML and CSS:
HTML:
<div id="outer"><div id="inner"></div></div>
CSS:
#outer {
position: absolute;
top: 50%;
left: 0px;
width: 100%;
height: 1px;
overflow: visible;
background:red;
}
#inner {
width: 300px;
height: 200px;
margin-left: -150px; /*** width / 2 ***/
position: absolute;
top: -100px; /*** height / 2 ***/
left: 50%;
background:#ccc;
}
Even more updated using jquery and always remain center when you resize the window too : http://jsfiddle.net/3aZZW/3/
Demo: http://jsfiddle.net/3aZZW/3/embedded/result/
There are different reasons why you should not use tables. Some which have already been discussed here. I understand that you are only using one row and you will hopefully try to keep your promise to not add any rows but if you come to break that promise, some of the reasons below will show a lot more significance, like the rendering speed and the screen reader issue. That's exactly why they call somethings standard and some not. Standards take everything and every situation into account.
Rendering speed issue:
One of the biggest drawbacks of tables is the way they are rendered by browsers. The inside of the table must be loaded before the position and size of the table can be exactly determined. This may cause problems if you are going to have a lot of information in the table.
Validness and standards:
Using tables for non-tabular data means you are writing invalid X/HTML. Which may be fine for some. But I don't recommend. See here
SEO:
I didn't know this before I did a search on some other less heard issues with using tables.
Search engines love valid code, so by not using tables it helps with
Search Engine Optimization (SEO).
See here for more info on this
Problems for screen readers and Braille displays:
Tables can't be used easily in screen readers. Check this article.
If you must use a table for layout, remember that screen readers and
Braille displays read tables row-by-row across the columns. The TAB
order also goes through the table in this way. So make sure that your
table structure makes sense when reading from left to right,
row-by-row.
On the + side:
I hate to admit that if you honestly use just that one table with one row and one column and with a very small amount of data inside (which I would call a limitation) then the page would probably render faster than the time you use Javascript but the other issues remain.
Tables are only meant to be used for tabular data - not for layout purposes.
Using tables for your problem provides a quick and easy solution for you but it doesn't mean it's the best, or correct method.
Just because something takes a little bit more thought and effort doesn't mean it should be avoided.
Use tables for this at your peril - your immortal soul may pay a heavy psychic toll at some future date for your actions today :p
According to StatCounter, as of November 2012, IE7 accounts for only 0.87% of the usage share of desktop browsers. It's not clear how accurate that measure is; some countries are probably disproportionately weighted and the sample-set almost certainly doesn't exactly match your user demographics, whatever they are. But, how much would you really lose by leaving IE7 behind? Might as well go with display: table;
On the other hand, it drives me nuts that display: table; is necessary. This is the closest I can get to a workable alternative:
HTML
<div id="pg-centerer">
<div id="shifter">
<div id="item">content</div>
</div>
</div>
CSS
#pg-centerer {
position: absolute;
left: 50%;
top: 50%;
}
#shifter {
position: relative;
height: 40px; /** Must set the height here. **/
left: -50%;
}
#item {
position: relative;
top: -50%;
}
So far, I haven't figured out how to avoid setting the height of the div#shifter element. Here's a working demo. I've tested this on Mac 10.8.1 FF 18, Safari 6.0, Chrome 25.0.1362.0 canary, and iOS Safari 6.0.1.
There is not much of a problem till you have small data inside table. Tables are somewhat heavy for browsers and with more data coming in, they make your web page response slower in comparison.
The example you have shown is only for an example but in real world you will have data inside it. If its going to be large try choosing a different method. may be the flexbox model or box model that is going to be supported in all modern browsers very soon. See an example here. http://www.kirupa.com/html5/centering_vertically_horizontally.htm
If the data inside is going to be small, feel free to user your method.
Directing my words to the geek inside who care not about standards, or multi-channeling content served... there is really just one technical problem with tables that I can think of, if you have large content inside that cell, the browser will wait for all content to load to be able to calculate the width and height of the cell before rendering... so if that content is really large and has large images, it will not render gradually... and making it a fixed table, well, the trick above won't work.
I depends on what you're trying to achieve. If it's just one page with one thing centered, then its great.
But I see you have set the table position: fixed. Which means it will scroll with you and go on top of content below. The other thing is that, if that table really fills up, you wont be able to see whats at the bottom of that table, since the position is set to fixed.
It's a great solution to center a small piece of text, image or information.
But its a bad thing to use within a page with a lot of other content or a lot of content within the table.
Side note: Using javascript to achieve something simple like that, is stupid. It can be done without javascript using CSS only. What if you use javascript to center something, and a client without javascript visits? Lets not destroy the web by using javascript/jquery for all the simple things ;)
http://phrogz.net/css/WhyTablesAreBadForLayout.html
Basically, it's slightly longer load times (JavaScript is slower), bad for screen readers (test it with one like JAWS), and hard to redesign (really only hard if you happen to forget why the heck you put a table there, so make sure to leave yourself a comment :). What would be really nice (I'm talking to you, W3C!) is something like box-align: x y;. Then you could also do things like align: center center or align: center bottom;.
Here is a demonstration: http://jsbin.com/egezog/edit#html,live
Sorry if this is newby, but I can't figure this out. I have a title, and I need (in decoration purposes) a line going from its edge to the right of the page (not an actual page, but a wrapper, but I have overflow hidden anyway). The wrapper is fixed in width, but the titles vary in length. I can't use absolute position, and I prefer not to use tables. And if we get this sorted out...
Here: http://jsbin.com/ibeciv/edit#html,live. So in the end, I actually prefer this all right aligned. You may ask, why do I need advice if it's there, implemented? Well, as you may see, the title is in two rows, which is unacceptable in my situation, and also, I prefer not to use tables.
I guess I can use float:right, to right align, but well, it depends on the implementation that I hope you'll advise to me. Thanks!
PS: jsfiddle is down for me right now, so here I used jsbin.
http://jsbin.com/ujiquq/edit#html,live
Will work in IE8 and all modern browsers. The background of the parent element can be anything. The line will still be vertically centered no matter what font-size is chosen.
HTML:
<h3><span>The title</span></h3>
CSS:
h3:after {
content: '\00200B';
background: url(data:image/gif;base64,R0lGODlhAgABAIAAAP8AAAAAACH5BAAAAAAALAAAAAACAAEAAAICBAoAOw==) left center repeat-x;
display: block;
overflow: hidden;
}
h3 > span {
float: right;
padding-left: 5px;
}
Here is a solution without using tables:
http://jsbin.com/ujawej/5/edit
And here is the one with tables (from my comment):
http://jsbin.com/osovev/2
Write like this:
HTML
<div class="title"><span>Title Here</span></div>
CSS
.title {text-align:right;border-bottom:1px solid red;}
span{background:#fff;float:right;margin-top:-9px;}
Check this http://jsbin.com/ibeciv/3/edit
UPDATED
Check this http://jsbin.com/ibeciv/4/edit