Develop Reference

Official dygraphs.com synchronize.html demo is busted: my version too

I refer to http://dygraphs.com/tests/synchronize.html.
Right now my own implementation is also giving me fits, which isn't surprising since I developed it as an edited version of the official example.
Try this: upon page load go to any of the four graphs and in the middle at a skinny section do a zoom in (click-drag from left to right); then double-click.
What happened? You zoomed in and the traces filled the graph vertically, but for a little bit of padding--- automatic scaling. And then upon zooming out with the double-click everything appeared to be as before. Ahh... but it wasn't and still isn't unless you've reloaded the page.
Now move to any OTHER of the four graphs and repeat the first step... zoom in at a the same skinny spot (the data happen to be the same for each of these graphs). Notice that the automatic vertical scaling is missing. And that's a permanent condition in all four charts until you reload the page.
This is with the latest version of Firefox on Ubuntu 12.04 LTS. You can see the Javascript by just looking at the web page source. I have been thinking that it has to do with the causal use of the blockRedraw boolean, but my more complicated efforts with that have yet to pan out.

I do believe that it's most appropriate for me to answer my own question, though it is a bit awkward. I burned a number of hours on this simple thing since posting the question. Here's the code and the answer:
` <script type="text/javascript">
gs = [];
var blockRedraw = false;
var initialized = false;
for (var i = 1; i <= 4; i++) {
gs.push(
new Dygraph(
document.getElementById("div" + i),
NoisyData, {
rollPeriod: 7,
errorBars: true,
drawCallback: function(me, initial) {
if (blockRedraw || initial) return;
blockRedraw = true;
var range = me.xAxisRange();
//var yrange = me.yAxisRange();
for (var j = 0; j < 4; j++) {
if (gs[j] == me) continue;
gs[j].updateOptions( {
dateWindow: range/*,
valueRange: yrange*/
} );
}
blockRedraw = false;
}
}
)
);
}
</script>`
The code there is copied directly off of the dygraphs.com synchronize.html page except that I've commented out var yrange = me.yAxisRange() and also the valueRange part of the updateOptions() argument.
Apparently if you put those range values in there you are forestalling the auto scaling from happening. I don't really know what's happening under the hood but that seems to be the deal. It solves the problem for my own analogous implementation. (That is, I found that the jsfiddle version that dygraphs.com has provided doesn't actually draw the graphs, making it useless for testing. So I have only tested this on my version which is really almost the same.)

Self-written rollout animation stuttering in Firefox

some time ago I started to write some code in JavaScript to learn it a little bit. I picked a rollin/rollout animation as 'project'. (I know about JQuery's slideDown/slideUp, but I wanted to work with pure JavaScript.)
I finished my effect, and the result looks pretty good in all major browsers except Firefox (tested versions 22.x to the latest (25.0.1)). In Firefox, the rolling (in and out) stutters while it rolls smoothly in Chrome, Opera, and Internet Explorer.
The general approach is (unsurprisingly) to have an element's style.height (or width) attribute increased/decreased several times by some pixels over a given time. To avoid calculating sizes every time the effect takes place, I calculate them one time and place them in an array (first item (0 + stepSize), last item wanted height/width). The decrease of the element's height is done by this function:
var verticalRollInWorker = function(step) {
if (step > 0) {
$(btt).style.height = stepSizes[step - 1];
setTimeout(function() { verticalRollInWorker(step - 1); }, delay);
} else {
$(btt).style.display = "none";
$(btt).style.height = 0;
// Enable roll out effect:
stateChange(false);
if (afterFullRollIn != null) {
afterFullRollIn();
}
}
}
In the particular example, I'm using 20 steps over 400ms. The step sizes in the array are rounded to integers, that's why the last step just sets 0 - to handle rounding differences.
(For convenience, I wrote my own $(element) helper, there's no JQuery involved here.)
I tested Firefox without Add-Ons, no difference.
I highly appreciate any help you can provide :)

One problem that I noticed in the above code is that you used $(btt). So, every 20s when the function is iterated, the browser needs to obtain the jQuery object. You could rather store it into a variable say 'var BTT=$(btt);' and use this BTT. Fetching jQuery object is a time consuming task.
Since you are using setTimeout(), the function will be executed every 20ms regardless of the completion of the current execution, this may also cause a drag. As Dagg Nabbit said, you could use setInterval() instad of setTimeout.
Another possible reason might be browser-reflow. I made a personalised scrollbar, and found browser reflow was noticeably greater in my FF than Chrome or IE. This depends on the size of the element, DOM tree depth, overflow property, and more...
And again use this code and see if it is fixed. reduces the subtraction into 1 code.
var BTT=$(btt).get(0);
var verticalRollInWorker = function(step) {
if (step > 0) {
step--;
BTT.style.height = stepSizes[step];
setTimeout(function() { verticalRollInWorker(step); }, delay);
}
else {
BTT.style.display = "none";
BTT.style.height = 0;
// Enable roll out effect:
stateChange(false);
if (afterFullRollIn != null) {
afterFullRollIn();
}
}
}
Further Comments can be made only after seeing a live example.
Regards.

Modify FireFox extension: If (scrollbar exists) var - 30 else var -14

Hello fellow code people :)
I am a frontend web developer and as such in need of constant knowledge of the actual viewport size in order to see where in responsive designing breakpoints start and end.
I know FF's own 'test window size' function, but came across a very handy extension: FireSizer.
the extension has one itsy bitsy drawback: It gives back the window-size including FF's borders and scrollbar. I need the viewport-size though. So I need the extension hacked, but dont't know enough javaScript to do so. Maybe someone is willing to help em out here?
I would love the extension to actually look for the scrollbar, and subtract from the width
a) 14 if no scrollbar present or
b) 30 if scrollbar present
I found of what I think is the right place to alter the code:
//
// Update the status bar panel with the current window size
//
function FiresizerUpdateStatus() {
var width = window.outerWidth + ''; // <- Think code needs to be edited here
var height = window.outerHeight + '';
document.getElementById("firesizer-statuspanel").label = width + 'x' + height;
}
Thanks for any effort!
AO
#Chen Asraf:
Well thank you very much. I didn't know there was an element to call the document-width. I changed the code to the following, and that did the trick (also when compared to FF's own 'Responsive Design View mode', which is spot on, its off by 2px - which i subtract from clientWidth.)
function FiresizerUpdateStatus() {
var width = window.outerWidth + ''; // changed this line to:
var width = document.documentElement.clientWidth-2 + '';
var height = window.outerHeight + '';
document.getElementById("firesizer-statuspanel").label = width + 'M' + height;
}
Thanks
AO

Possible duplicate of Get the browser viewport dimensions with JavaScript
Seems like you can get the window's inner dimensions by using:
// My window is maximized; screen is 1366x768
alert(document.documentElement.clientWidth);
// ^ returns 1349 (17 missing pixels because of scrollbar)
alert(document.documentElement.clientHeight);
// ^ returns 643 (125 pixels missing because of start bar & Chrome toolbars)
You can then compare the following with whatever else you need (for example, compare client width with window width to find if the difference is big enough to be a scrollbar - just experiment with the sizes)

How to tell if an element has a fluid width [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Determine whether element has fixed or percentage width using JavaScript
I need to know if an element has a fluid width or not. I can go into the hairy details of why if it's really needed, but I dont think it is.
Basically, is the element N% width or Npx|pt|em|etc width? Right now I only see ways to get the current computed width. So, even if an element is 100% wide, getting the value in JS returns, like, 500px or however wide it is at that moment.
Are there any hacks or JS API's I dont know about to know this or to get the original CSS value?
Also, please no jQuery. This is for a JS library of mine.

You need to use window.getComputedStyle for those browsers that support it, and element.currentStyle for those that support that. Or you could use jQuery $(element).css('width') which should abstract the difference (although I haven't tested the latter).
It seems the following does not do what I had thought it would, at least not for width and height. After searching around I found this other SO question where it is stated to be impossible (at least not without parsing the Stylesheet?!). Seems mad to me, I shall keep looking just in case.
get CSS rule's percentage value in jQuery
if( window.getComputedStyle ) {
value = window.getComputedStyle(element,null).width;
} else if( element.currentStyle ) {
value = element.currentStyle.width;
}
update
I've found that this works...! but only for firefox :( To me it would make sense that if the element has nothing to compute it's width against (i.e. it's not part of the document flow) it should return it's original value:
function isElementFluid(elm){
var clone = elm.cloneNode(false);
if( window.getComputedStyle ) {
value = window.getComputedStyle(clone,null).width;
} else if( clone.currentStyle ) {
value = clone.currentStyle.width;
}
return (value && String(value).indexOf('%') != -1 );
}
(have not tested for IE)
Yet again another instance of where I agree with FireFox's implementation and frown at Chrome or Safari.
update 2
Ok, not a fan of being defeated by computers ;) so have come up with this function -- totally over the top, but it does seem to work. Again I have yet to test this on IE as I don't have a Windows machine to hand at the moment. It's annoying when the original FF only version is quite succinct, but the logic here is sound - it falls back to what a normal human would do in testing if something is stretchy.
function isElementFluid(elm){
var wrapper, clone = elm.cloneNode(false), ow, p1, p2;
if( window.getComputedStyle ) {
value = window.getComputedStyle(clone,null).width;
} else if( clone.currentStyle ) {
value = clone.currentStyle.width;
}
/// the browsers that fail to work as Firefox does
/// return an empty width value, so here we fall back.
if ( !value ) {
/// remove styles that can get in the way
clone.style.margin = '0';
clone.style.padding = '0';
clone.style.maxWidth = 'none';
clone.style.minWidth = 'none';
/// create a wrapper that we can control, my reason for
/// using an unknown element is that it stands less chance
/// of being affected by stylesheets - this could be improved
/// to avoid possible erroneous results by overriding more css
/// attributes with inline styles.
wrapper = document.createElement('wrapper');
wrapper.style.display = 'block';
wrapper.style.width = '500px';
wrapper.style.padding = '0';
wrapper.style.margin = '0';
wrapper.appendChild(clone);
/// insert the element in the same location as our target
elm.parentNode.insertBefore(wrapper,elm);
/// store the clone's calculated width
ow = clone.offsetWidth;
/// change the wrapper size once more
wrapper.style.width = '600px';
/// if the new width is the same as before, most likely a fixed width
if( clone.offsetWidth == ow ){
/// tidy up
elm.parentNode.removeChild(wrapper);
return false;
}
/// otherwise, calculate the percentages each time - if they
/// match then it's likely this is a fluid element
else {
p1 = Math.floor(100/500*ow);
p2 = Math.floor(100/600*clone.offsetWidth);
/// tidy up
elm.parentNode.removeChild(wrapper);
return (p1 == p2) ? Math.round(p1)+'%' : false;
}
}
else {
p1 = (value && String(value).indexOf('%') != -1);
return p1 ? value : false;
}
}

You can retrieve the CSS value with:
element.style.width
which will return:
auto - The browser sets the width. This is default
length - Defines the width in length units
% - Defines the width in % of the parent element
inherit - The value of the width property is inherited from parent element
Return values pasted from: http://www.w3schools.com/jsref/prop_style_width.asp

i think what your looking for is getComputedStyle
it isn't supported in IE8 and below, but u can emulate it IE see: http://snipplr.com/view/13523/

Is detecting scrollbar presence with jQuery still difficult?

I know that detecting scrollbar presence is supposed to be one of those elusive things that we should all have to suffer through. What I've read so far is that you can't really detect scrollbar presence, only use hints in the DOM to know if they may be present, and it can't be done in less than 30 lines of code.
This sounds a little impossible to me now that we're in 2010. Does jQuery have a cross-browser reliable solution that takes care of this and works at least most of the time? Any help please, I'm pulling my hair, half of it is already on the floor.

Probably not as elegant as you were hoping for but this is an adequate adaption from a script I recently wrote to calculate viewport height.
Logically you'd want to call this function on document ready and window resize.
It also deals with inconsistencies that you'd encounter in Opera (line 2) and IE7 (line 6).
function scrollbar() {
var viewportHeight = window.innerHeight ? window.innerHeight : $(window).height();
if (jQuery.browser.msie) {
if(parseInt(jQuery.browser.version) == 7) {
viewportHeight -= 3;
}
}
if(viewportHeight <= $('#wrapper').height()) {
return true;
} else {
return false;
}
}