#7261 closed bug (patchwelcome)
Body Table
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | undecided | Milestone: | 1.5 |
| Component: | support | Version: | 1.4.3 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Lately, I have been using an experimental layout method in which I turn the entire <body> tag in to a table.
html{height:100%}
body{display:table; width:100%; height:100%;}
After those main parameters are set, I use a div that acts as a row via display:table-row, and then another div with display:table-cell. The model, essentially works just like a Web 1.0 tables layout and I've had a lot of fun using it with great success. (one of the lovely things about it is I don't need to know the height of the footer to make it sticky and nonblocking)
However, when jQuery is included, even the newest version, Webkit breaks. The body still reaches to 100% height of the viewport, but it appears as if the bottom of the page is about a sixth up from where it should be.
Observe this example page I've put together. Right away, in Chrome or Safari, you will see the white at the bottom of the page. However, comment out jQuery, and the page renders properly:
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<style>
*{ margin:0 }
html{height:100%; overflow-y:scroll;}
body{ display:table; width:100%; height:100%;}
.wrapper{ width:700px; margin:0 auto;}
.table{display:table;}
.row{ display:table-row; }
.column{ display:table-cell; }
.sticky{ height:1px; }
</style>
<!--<script src="http://code.jquery.com/jquery-1.4.2.min.js" type="text/javascript"></script>-->
<script src="http://code.jquery.com/jquery-1.4.3.min.js" type="text/javascript"></script>
<script src="../js/filler_text.js" type="text/javascript"></script>
</head>
<body>
<div class="sticky row"><p>All these are evidently sections, as it were,</p></div>
<div class="row">
<div class="wrapper table">
<div class="row">
<div class="column" style="width:200px;"><p>Three-Dimensional representations of his Four-Dimensioned being, which is a fixed and unalterable thing.'</p></div>
<div class="column"><p>'Scientific people,' proceeded the Time Traveller, after the pause required for the proper assimilation of this, 'know very well that Time is only a kind of Space. Here is a popular scientific diagram, a weather record.</p></div>
</div>
</div>
</div>
<div class="sticky row">
<div class="wrapper"><p>first</p><p>sticky</p><p>footer</p></div>
</div>
<div class="sticky row"><p>bottom sticky footer</p></div>
<script>
function ranHex(){return '#'+Math.floor(Math.random()*16777215).toString(16);}
var divs = document.getElementsByTagName('div');
for(var i=0; i<divs.length; i++){
divs[i].style.background = ranHex();
}
</script>
</body>
</html>
Change History (11)
comment:1 Changed 12 years ago by
| Owner: | set to [email protected]… |
|---|---|
| Status: | new → pending |
comment:2 Changed 12 years ago by
I can confirm this bug. And it is triggered by just including jQuery on the page (no other javascript executed neither normal nor jQuery based). It also seems to only happen in Webkit based browsers (Chrome, Safari).
The cause is this W3C box model test in support.js (I guess this actually is a Webkit bug to be reported)
I also tested Opera 10.62, FF 3.6.10 and FF 4.04b where it works just fine (can't test IE 6/7/8/9 at the moment).
I made a stripped down test-case (which I can't attach as there seems to be no option to attach a file) thus I provide this jsfiddle version of the testcase which resamples it.
Expected result: Two colored rectangles each claiming 50% of the browser window. One red in the upper half and one yellow in the lower half
Opera with jQuery (thumbnails are clickable)
Part[1 / 2] (as TRAC thinks my comment is spam - too many outbound links)
comment:3 Changed 12 years ago by
Part [2 / 2]
Chrome with jQuery and Chrome without jQuery
If you remove the above highlighted test from support.js it works fine.
If you just comment every line out in this support-test which accesses either div.offsetHeight or div.offsetWidth it also works fine.
Conclusion:
The support test adds a normal div (display:block) at the end of a body with display:table, does some tests and manipulations and then removes the div.
Accessing the offsetHeight / offsetWidth attribute of this div triggers the faulty behavior in Webkit.
The problem seems to be that Webkit after removing the div doesn't reclaim the space it has taken up and thus doesn't "resize" the other elements to fill the space.
The same behavior can be achieved in Opera and FF by removing this line from support.js.
So Webkit behaves as if the div wasn't removed altogether
P.S.: Sorry for this massive post. But some lines where needed to explain this strange bug. Hope it helps some
comment:4 Changed 12 years ago by
Here's my original example on jsfiddle. It occurs in JQuery 1.3.2 and up.
By the way, the filler_text.js was originally just there to fill in, you guessed it, text which i left out because it's the whole first chapter of the Time Machine. :P
Thanks for checking this out!
comment:5 follow-up: 6 Changed 12 years ago by
| Status: | pending → closed |
|---|
Automatically closed due to 14 days of inactivity.
comment:6 Changed 12 years ago by
Replying to trac-o-bot:
Automatically closed due to 14 days of inactivity.
So well-documented, reproducible bugs are automatically closed when there's been no activity for 2 weeks?
That's kind of messed up.
The user did everything that they could to help further the diagnosis and rectification of this bug; what more could they have done, aside from actually fixing it? The ball was obviously in *your* (jQuery's) court!
comment:7 Changed 12 years ago by
| Status: | closed → reopened |
|---|
The original report was marked as requiring additional clarification, and the original reporter’s account was not used to respond to the test case (the same person may have responded but as “anonymous”, which our system can’t identify), so this state was never cleared. This sort of mechanism is necessary in order to prevent the bug tracker from filling up with abandoned tickets.
In the future, if you want to request that a closed ticket be re-evaluated, please try to do so without being so confrontational. We are all volunteers, and we are trying very hard to make sure that limited resources are being used as efficiently as possible. If you feel that our current policies or practices are not as good as they could be, we would be happy to accept your time and effort to improve them.
comment:9 Changed 12 years ago by
| Component: | unfiled → support |
|---|---|
| Keywords: | needsreview added |
Wow, this is a pretty crazy corner case. As jitter observed, jQuery expects to be able to append content to the body in support.js where we do feature detection, and also effects.js where we append an element to the body to determine its default display state. If the whole body is a table this will create an invalid document.
I'll leave this open, assign it to the "support" category, and mark it needsreview for now, but it's very likely to be closed wontfix or patchwelcome.
comment:10 Changed 12 years ago by
| Resolution: | → patchwelcome |
|---|---|
| Status: | reopened → closed |
I'm going to close this ticket patchwelcome. It may be possible to work around the issue, but the effort required to do that and ensure no regressions for the other 99.9% of the time is beyond the benefit for the jQuery team to dedicate time to it.
To solve this particular error it *might* be as simple as checking that document.body.style.display=='' or 'block' in support.js and skipping the feature tests. But that also impacts the cases we are trying to feature detect and jQuery's behavior on some operations. It would all need thorough testing.
There is lots of other jQuery code in the wild, including plugins, that expect to be able to append elements to the body (e.g, dialogs and tooltips). I think that would be the downfall of any plan to turn the body into a table.
comment:11 Changed 12 years ago by
| Keywords: | needsreview removed |
|---|
You don't appear to be using jQuery on your page (other than including it) - could we see the contents of the filter_text.js file?. Merely including jQuery on your page should almost never cause this behavior unless there's something in your code that is causing an issue with it.