Thread: Inaccurate width onload issue

Why are you tampering with the width from JavaScript in the first place. You should be able to get this working properly with CSS as that's what CSS is for.

The CSS is set in the .css file to 100% as I said. The issue I am having is that when the JavaScript loads it detects two different widths rather than same and remains so until I resize the browser.

CSS file:
Parent width 100%
^container width 100%

JavaScript console.log window.onload:
Parent width 313 pixels (100%)
^container width 301 pixels (96.17%)

Without seeing the site in question it's impossible to say, but is this behavior consistent across all browsers, or just a particular one?

I find it increasingly queer how some folks ask for help on something but then don't show us what's actually failing...

Are you remembering to take into account that the width in CSS normally includes padding and borders to that the actual content width will almost always be smaller?

My best guess would be that setting padding to zero will fix the problem without any need for JavaScript but without seeing the code I am relying on the shards of my broken crystal ball for trying to figure it out.

Originally Posted by deathshadow

I find it increasingly queer how some folks ask for help on something but then don't show us what's actually failing...

Originally Posted by felgall

My best guess would be that setting padding to zero will fix the problem without any need for JavaScript but without seeing the code I am relying on the shards of my broken crystal ball for trying to figure it out.

: /

...
Seriously?

K, right then.


Vanilla JS

Code:

(function(){

	"use strict";
	
	//Window Triggers
	window.onload = function (){
		defaultBreak();
		placementBlock();
	};
	
	window.onresize = function(){
		placementBlock();
	};

	//Placement
	function placementBlock(){
		
		var mainWrap = document.getElementById('agility-set').clientWidth;

		console.log(window.innerWidth + " onload innerWidth");
		console.log(mainWrap + " parent container");

	};

};

CSS

Code:

body {
	margin:0;
	padding:0;
}

#agility-set {
	position:relative;
	width: 100%;
	pointer-events:none;
	margin:0;
	padding:0;
	outline: 0;
	box-sizing: border-box;
	-moz-box-sizing: border-box;
	-webkit-box-sizing: border-box;
	text-decoration:none;
	list-style:none;
	backface-visibility: hidden;
	-moz-backface-visibility: hidden;
	-webkit-backface-visibility: hidden;
	font-family:'arial', sans-serif;
	text-transform:uppercase;
}

K, guess I'm putting this on the list of things I'll have to figure out for myself.

It's the height...

Forgot to mention that the child elements are all absolute div tags so the parent container has to auto assume height. But I just gave the parent a fixed height and overflow hidden and that removed the gap issue.

Does that make sense?

If this works, then I have to use JS to adjust the parent height with the absolute blocks correct? Or is their a CSS only way of fixing this like using ::after or something?

IHMO you're still not showing enough to answer you... since scripting and CSS is gibberish without the markup it's being applied to, otherwise any of the dozens of things that could be interfering cannot be ruled out... like whitespace dom-nodes interfering in certain builds of IE (hence my asking if the problem is browser specific), if any other CSS present is interfering, if invalid markup is interfering, etc, etc...

Typically if height trickery is fixing it, there's something wrong with the markup like an unclosed tag or invalid element placement.

So based on the information so far provided the problem is most likely the absolute div tags. Most likely there is a better way to achieve the same effect without having them absolute but as you haven't said why you have them set a way that is almost never needed we don't know whether you really need them that way or whether there is a better way to achieve the same result that doesn't cause the problem.

Without complete information the only answers you are likely to get are going to be patches rather than proper solutions.

I am making a shaped gallery as a minor change to using quadrilaterals and require the child blocks to be positioned absolute for free form category filtering and moving the blocks around without negative margins. A lot of what I require done needs JavaScript as the bottom line and I am pushing some limits on what is available to HTML and browsers.

I believe "solved" the issue with the width by applying height:1px; and overflow:hidden; to the parent div tags. Which I admit I really do not like and would prefer a different solution, but for now it fixes the issue. I am actually having the opposite issue now when I refresh the page, the scrollbar obscures the right side a little.

I am happy with the result as it is right now but will come back to this at a later date along with some other clean up objectives. Right now, this plugin is 1.0 and I will build on it overtime if the market wants it.

"Shaped Gallery", "quadrilaterals", "free form category filtering"... *SIGH*

Pushing the limits? You've gone past them and are telling users to go plow themselves with that nonsense... That's the type of artsy "design" that really has no place on a website... so unless you're building a web application that will NOT be served directly in a browser from a site, well... I'd tell you to pitch the entire mess, PARTICULARLY if you can't make it work without scripting FIRST.

Though if height:1px (the holly hack) "fixed" anything, you likely have no doctype, invalid nesting, invalid markup, or aren't using relative/absolute's relationship properly... and/or are testing in a ridiculously outdated browser like IE7/earlier... actually, make that IE6 since IE7 has overflow as a haslayout trigger.

NOT that ANYONE could tell that from your complete LACK of showing anything meaningful.