I'd like to imitate my favorite site and measure it grid arrangement:
How to measure its width of each part?
If you are using Google Chrome, you can see the width of every element in pixels, by opening Inspect Element (F12), and hovering over the element.
There are some useful JS properties and methods you can use via the Developer Console. This is useful if you have a list of elements you want to get dimensions for and want to get them at different browser dimensions.
You could type/paste in the following in the browser console:
console.log("#content width: " + document.getElementById("content").offsetWidth)
console.log("#answers width: " + document.getElementById("answers").offsetWidth)
Which would provide the following results that you could copy and paste out.
#content width: 1600
#answers width: 728
There may be a way to do this with the Chrome debugging protocol as well.
Here are some JS properties and methods that may be of use:
Use HTMLElement.offsetWidth for width as an integer. You can also use HTMLElement.offsetWidth for height.
MDN: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/offsetWidth
MDN: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/offsetHeight
The HTMLElement.offsetWidth read-only property returns the layout width of an element. Typically, an element's offsetWidth is a measurement which includes the element borders, the element horizontal padding, the element vertical scrollbar (if present, if rendered) and the element CSS width. If the element is hidden (for example, by style.display on the element or one of its ancestors to "none"), then 0 is returned.
Use HTMLElement.getBoundingClientRect() for fractional values:
MDN: https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect
The Element.getBoundingClientRect() method returns the size of an element and its position relative to the viewport.
I think following illustration will help you:
Related
I have a set of nested HTML, elements that are made up of a parent (AssetContainer) and two main nested parts (MediaViewContainer & AssetDetailsContainer) that are side by side. The right side component (AssetDetailsContainer) has a couple of sub-divs, but they have no styling of their own.
My issue is that the right side component is not rendering at the size it is styled to. The AssetDetailsContainer CSS sets a width of 600px, and this appears in the inspector, but then a different, much smaller value is used to actually render the element. If I set a larger or small value it grows and shrinks but at some non-integer scale of the value that was set. Though "Scaling" is probably a bad term as the rendered value/input value ratio is not a constant.
I'm attaching some images of the inspector panel for the main elements involved in the width, showing their HTML, CSS, and actually rendered properties. I know images aren't ideal, but these seemed to best represent the pertinent data in one place.
AssetDetailsContainer (right side child element) inspector snapshot
Looking at the resulting AssetDetailsContainer shown in the inspector we see the original 600px in the CSS, but then it's rendered as 104.5px instead.
AssetContainer (parent element) inspector snapshot
MediaViewContainer (left side child element) inspector snapshot
What am I missing here with respect to layout?
Turns out the solution was to nest the AssetDetailsContainer in an unstyled <div>. I think since the AssetDetailsContainer had a relative positioning property, that was not playing well with the flex positioning of the parent that was being used to create the side-by-side layout. The extra div layer seems to give it the proper segmenting of the different positioning properties and I now get the expected behavior.
I run into this problem sometimes when a site is not contained inside the mobile viewport, and I need to determine what is causing the width to exceed.
Usually I do this by trial and error of hiding different elements until the elements resets to the desired 100% width. Then I repeat for each child element until I find the one that is causing it.
Is there a way in Firefox or Chrome devtools (or using a plugin) to see which DOM child element is deciding the current elements dimensions?
Determining what is defining an element's calculated width and height can be quite tricky. And neither the Chrome nor the Firefox DevTools provide an easy way to get that information in all cases. And to my knowledge, there are also no extensions available that make this easier. The Firefox DevTools team started a discussion on this some time ago, though.
There are two reasons why an element might be wider or higher than expected: Some CSS or some text on the element itself or on one of its descendant elements.
When there is no other solution, the one with hiding or removing the elements is probably the fastest one.
Nonetheless, here are some tips how to use the DevTools to determine what's defining an element's width and height:
Select the element and check in the Computed side panel whether the computed value is defined via a CSS rule. Expand the entries for width or height to see what CSS rules applied. Also check min-width and max-width or min-height and max-height and the other layout related properties like margin, border, and padding but also `line-height, etc.!
Check the text within the element influences its width or height. Long words with no break opportunities like spaces can be the culprit but also CSS property definitions like white-space: nowrap.
When you've checked the above for the element itself and couldn't find the reason, the width or height is influenced by one or more descendant elements. So you need to repeat those two steps for them.
a) To quickly see the dimensions of the direct child elements, first press → to expand the element if it isn't already, then ↓ to toggle through them. While stepping through them, check their CSS and text as noted in steps 1 and 2.
b) When you see one that is as wide as the element you are observing, repeat the previous step to get one more level down in the DOM structure.
The steps mentioned above can also be automated by using some JavaScript to walk through the tree and check the element widths or heights. A relatively simple snippet for that (which can be executed in the DevTools console) is
rootElement = $0;
rootWidth = rootElement.getBoundingClientRect().width;
walker = document.createTreeWalker(rootElement, NodeFilter.SHOW_ELEMENT, {
acceptNode: element =>
element.getBoundingClientRect().width === rootWidth ?
NodeFilter.FILTER_ACCEPT :
NodeFilter.FILTER_SKIP
});
currentNode = walker.currentNode;
while (currentNode) {
console.log(currentNode);
currentNode = walker.nextNode();
}
Where the $0 refers to the currently selected element.
I was writing the layout of an app using the box-flex property (in Chrome) and I have found a strange behaviour, in my opinion, that I am wondering if might be a bug or that I just ignore the reason for those workings.
The code looks like this: http://jsfiddle.net/5tuCh/
There is a weird "div" resize when resizing the "textarea" so that the dimension of the "div" minus the "textarea" is equal to the dimension of the second "div", in order to satisfy "box-flex:1.0" I guess. Now if the reason for box-flex was making it easier to arrange the layout, this behaviour makes it unusable in this case.
Might it be that I am missing something?
Thanks.
This is in fact correct behaviour. From MDN:
The containing box allocates the available extra space in proportion
to the flex value of each of the content elements.
In your example, div.text boxes actually render with a height, meaning that any space beyond that would be spread evenly (or, rather, according to the flex ratio) between the elements. Setting height:0 on these elements would force behavior that I believe you're after (fiddle: http://jsfiddle.net/5tuCh/16/); I also had to remove the height:100% declaration on your textarea to prevent it from collapsing inside an element with zero height. I'd speculate that you may accomplish the textarea to take up full height of the parent element by setting its box-flex property as well.
Update:
OP's having issues with textarea behaviour could possibly be addressed by the following style:
textarea {
position:absolute;
top:10px;right:10px;bottom:10px;left:10px;
resize:none;
}
The parent element, of course, has to have position:relative set, which would result in the textarea taking up all available space in the container (w/10px spacing between the borders). Not sure if that's what you were after though. Fiddle: http://jsfiddle.net/5tuCh/36/
I tried setting position:absolute and then left, top, right and bottom to fixed values in pixels, but unless I also set width and height I cannot get it to work properly on Firefox 11.
The rendering looks ok on safari/chrome... but is this a Firefox bug or something that isn't indeed standard? Using 100% for width and height is sometimes a solution, but not when the element is not completely covering the parent container.
See http://jsfiddle.net/EjS7v/6/
This is Chrome (and the desired result)
Firefox (width/height to 100%)
Firefox (without width/height)
Are there alternatives to using Javascript to compute width and height at runtime?
Note that in this example I've used a fixed size div as container, but the most interesting and useful case is when the container is elastic.
Actually there's a simple alternative, use presentational markup to contain that textarea and then just 100% width height for the textarea itself.
Indeed, CSS is very limited.
This is because textarea, unlike, say, a div, has a default width and height:
If the element has a cols attribute, and parsing that attribute’s value using the rules for parsing non-negative integers doesn’t generate an error, then the user agent is expected to use the attribute as a presentational hint for the width property on the element, with the value being the textarea effective width (as defined below). Otherwise, the user agent is expected to act as if it had a user-agent-level style sheet rule setting the width property on the element to the textarea effective width.
The textarea effective width of a textarea element is size×avg + sbw, where size is the element’s character width, avg is the average character width of the primary font of the element, in CSS pixels, and sbw is the width of a scroll bar, in CSS pixels. (The element’s letter-spacing property does not affect the result.)
If the element has a rows attribute, and parsing that attribute’s value using the rules for parsing non-negative integers doesn’t generate an error, then the user agent is expected to use the attribute as a presentational hint for the height property on the element, with the value being the textarea effective height (as defined below). Otherwise, the user agent is expected to act as if it had a user-agent-level style sheet rule setting the height property on the element to the textarea effective height.
The textarea effective height of a textarea element is the height in CSS pixels of the number of lines specified the element’s character height, plus the height of a scrollbar in CSS pixels.
Setting width/height in CSS only corresponds to the content area. Is there a way to set the offset width/height (i.e. dimensions including padding/margin/borders) of an element in CSS?
EDIT: Example ->
I have a number of divs tagged with css class "smallBox"
.smallBox{
width: 100px;
height: 100px;
}
Now I want to set the padding individually on each box, while having the overall outer dimensions stay the same.
Strictly speaking, sort of. You can change the box model used with the proposed box-sizing CSS3 property, such that the width specifies the total width of the object. Details can be found here (http://www.quirksmode.org/css/box.html).
However, browser compatibility is iffy (the article only mentions IE8+ and Firefox), so you will likely need to use JavaScript of some kind to achieve this.