Off-DOM element dimension

It can be really frustrating; you want to know the height of an element, but it is not in the DOM yet. Since the element’s width and height depends on the styling, the measures can only be calculated on screen, in the DOM.

Size & Styling

Your best shot is adding the element to the body in a hidden state (visibility: hidden) or off-screen (position: absolute; left: -9999px;), get the width and height and remove it from the DOM. But sometimes the size of the element depends on the css of an ancestor element, like width: 100%;, which is not present in the body. Or better, you can also append the element to the eventual element, but only if that one exists and sometimes it doesn’t.


If it doesn’t, we could replicate it. We can make a structure that will ‘mimic’ the eventual structure that the elements dimension depends on. An example:

The size of the paragraph depends on the ancestor elements; when it is a child of a section with the class .column it will have a maximum width of 300px and, since it has a larger font-size than the default 12px, will be higher than outside of the column.

Now, lets replicate the ancestors. I use the jQuery css-parser I wrote to create the elements.

This function will replicate the family tree needed to get the proper dimensions and can be used as simple as this:

Ok, this only works if you now the chain of ancestors, but hey, even the web can’t be perfect…

Screen Orientation API

The Web Applications Working Group has published a Working Draft of The Screen Orientation API.

The Screen Orientation API provides the ability to read the screen orientation state, to be informed when this state changes, and to be able to lock the screen orientation to a specific state.

Probably the most interesting feature will be the lockOrientation() method, allowing the developer to force the page to be viewed in a specified orientation.

This Working Draft is an update on a previous version published in May 2012.

Out of bounds with box-sizing

Using box-sizing makes life easier, but it does not always work the way you think.

In this case you would expect the div to have a height of 100px, because of the max-height, but no, it will have a height of 150px. This is because of the way box-sizing works. About box-sizing on

…any padding specified on the element is laid out and drawn inside this specified width and height. The content width and height are calculated by subtracting the padding widths of the respective sides from the specified ‘width’ and ‘height’ properties. As the content width and height cannot be negative, this computation is floored at 0.

So, when the padding exceeds the height (or width) of the element, the content is floored to 0. This means there is a problem, because the padding does not fit in the element. In that case the box-sizing property is ignored and the element will overflow the max-height.

A fiddle.

CSS-string to jQuery object

CSS-selectors are clean and clear, element#id.class.another-class. But why, if we want to create an element, do we have to do this?

I build a css parser that converts a css-selector into a jQuery object. For now, only node-type, id and classes are implemented.

Creating an element is now a piece of cake.

The wins might not be as astronomical as I make it sound, but in future posts I might come up with some handy uses for this code.

innerHTML in IE

I stumbled upon an interesting issue today. Internet Explorer seems to store its references to DOM elements in another way than Chrome or Firefox. A (vanilla) javascript-object of an element is linked to the element in the DOM. In Chrome and Firefox, when that element is removed from the DOM, the HTML for it still exists in the innerHTML attribute in the js-object, but in IE the innerHTML is cleared.

The Problem

We have the next example (jsfiddle):

An elment is created, text is added and it is appended to the body. When we clear the body, by replacing its HTML with nothing, in IE, the html of the element is also emptied.

The Cause

Javascript in IE seems to hold reference to the ‘real’ HTML in the DOM and its values depend on it. So, when the html is not available in the DOM, its not in the object. This is more logical than you might think. The innerHTML attribute in the object is just holding a string of HTML-code, not any objects of the inner elements. When the content is cleared, so is the innerHTML, to keep the attribute’s value up to date.
Chrome and Firefox, however, keep their reference to the content. Which will leave the element intact when you remove it from the DOM, so it can be added later in the process.

The Fix

To fix this issue, the innerHTML shouldn’t be cleared. An alternative is to remove the elements from, in this example, the body by using removeChild.

This loop will remove all elements in the body, which has the same effect as clearing the innerHTML. The difference is, that the HTML is not really removed. It is still accessible in the javascript object.

jQuery: html vs empty

Maybe this issue doesn’t seem that common, but using jQuery you might run into it. jQuery uses both ways to clear the content of an element. The first is used in the html method and the second in the empty method. When using front-end mvc’s, like Backbone, there are situations where you want to re-render a view without re-rendering it’s sub-view. By first emptying the view’s html, the element will be left intact.