I am working on an element that becomes sticky on top of the page once you scroll past. In order to prevent content below it from shifting up, am getting the current height of the parent of the element that's about to be made sticky and adding it as inline style purely for user experience so the user isn't disorientated by things jumping around.
I am wondering if this has added benefit for performance? Does the mere fact of changing element's position cause page reflow or have I prevented page reflow by applying fixed height to the element parent before making the child element sticky?
Does the mere fact of changing element's position cause page reflow
Yes, see What is DOM reflow?. Even if you as the user might not see a difference, the website was repainted.
I am wondering if this has added benefit for performance?
Repaints/reflows are usually quick, especially if you only change a small part of the layout. But what has a much larger influence on the performance is the way you track the scrolling. Historically, this was mostly done by using addEventListener('scroll', /* ... */). However, there is a much better and more performant way of doing the same thing using the IntersectionObserver API. It has reasonable browser support and there is a polyfill.
I appreciate that I could just "try it and see", but I'd prefer to err on the side of caution here and ask if anyone has prior experience with this matter, or knowledge that would allow an answer ;)
I'm working on a feature that will include many elements (around 800) in a canvas-like container. All of these are <div> elements with a background-image. They will be aligned to a grid.
I have some ideas for neat animations that would involve transitioning elements to their new positions when some of them are added or removed - this would involve position:absolute and setting left and top appropriately.
I'd like to know how well browsers would handle this kind of thing, or if I would be better off just using display:inline-block and letting them flow as they would - no neat transitions, though.
In short I'm just wondering if the use of position:absolute, ie. removing the elements from the document flow, would be too much for the browser to handle when updating, as opposed to simply allowing the elements to exist in the flow of the document.
Does that make sense? I feel like I'm wording this horribly XD
If all of the elements will have the same height, then I'd just use display:inline-block or float:left, and they'll fit nicely together.
If the elements will have different heights, they will not perfectly "fall in line" when floated or displayed as inline-blocks.
For the latter, using a jquery plugin such as Masonry would be a sensible solution. Masonry uses the absolute positioning your question refers to, and no, it is not too much for the browser "to handle."
You can, of course, still use Masonry if your divs will have the same height.
Without a script solution like Masonry, I doubt it'd be a good idea to use absolute positioning on 800 elements to achieve your desired result.
I've always wondered about this.
Even with media queries, how would I significantly change the placement of things(since I'm not modifying element placement in HTML directly).
For example, if social Facebook/Twitter links appear somewhere in the middle of the page(with their HTML container elements nested in a bunch of other parent tags), how would I go about moving that to the bottom of the page(or, to make it look like they are nested in a different section).
You have at least two options:
Change the positioning of the container element. Instead of static position (default behavior), you can use position: absolute or position: fixed to move it to a totally different place on your page.
Repeat the elements in two different places, and set one of them visible depending on a screen size.
I must add, however, that in a good design such measures are rarely necessary. You do not want to confuse your users by moving the elements to a totally different location. A better approach is to use a responsive grid (for example, changing the layout from three columns to two, or from two to one, when a screen gets smaller), collapse tabs into a drop-down list, etc., but keep the position of different elements relatively stable.
Moving to the bottom of the page wouldn't be a big deal. Depending on the parent container, use position:absolute or position:fixed and adjust the z-index of this and the parent container.
However, if you wanted to re-order your containers for specific media queries, you'll either have to give absolute positioning to more elements, adjust your floats, or use Javascript.
If this is a client request, I would personally revisit the wireframe stage and plan your responsive behavior from scratch.
You never ever can assume height of elements for sure from a CSS perspective: user will zoom a bit or a lot, images included or not; images won't appear because of network problem or by user choice, etc. Thus position: absolute is a recipe for future or immediate failure (and fixed not what you're searching for).
You can play with:
flexbox (horizontal or vertical, natural or reverse order)
display: table-(header|footer)-group or display: table-caption along with table-cell and if possible with parent element having display: table (with or without table-layout: fixed) or table-row
floats and Block Formatting Context effects (such a powerful beast)
nope: CSS Grid Layout is IE10 and IE11 only
If you want to move an element from somewhere inside some other element far away both in HTML and visually, then go with JS/jQuery. CSS doesn't allow for complex manipulations. Just make sure that you watch for resize both from and to desktop/mobile resolutions (and allow for initial manipulation and after some AJAX event) and don't fire 100+ events per second when resizing
I have a <div>, inside of which some complicated content is rendered with a scale transform applied. My problem is that the <div> takes up the same space that it would have taken even if no transform was applied. I've made a jsFiddle snippet to illustrate what I mean.
I think I can understand why the behavior is like this, but is there any way to make it so that the container takes as much space as its content with scaling (and other transforms, if possible) applied?
I should note that explicitly setting the width and height of the <div> outside affects the contents of the scaled text (and this is not desired behavior in my case). Putting the scaled content in an <iframe> is something I'd like to avoid.
Without resorting to Javascript, there isn't any way to do this, I don't think. CSS transforms don't affect layout flow for elements near the transformed elements, they only change the coordinate system within that element; so children are affected, but not parents or siblings (MDN has some more detail on this).
There's a great answer here that might be a JS-based partial solution for you: https://stackoverflow.com/a/10913299/2524360
I don't know if this answers your question, but it doesn't seem to accept 0 as a value. The browsers scales from 1, as in 100% to e.g. 4, or 400%.
transform:scale(1,4);
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I was developing a web page, where I was laying out a board for a Chess-like game, along with a couple of piece trays. It's all done using HTML (with jQuery for dynamic updating as the game is played). Somewhere I'd got the notion that using absolute positioning of elements within a page was considered a bad practice, and that it was preferable to use relative positioning.
After struggling with relative positioning for too long, I realized that absolute positioning of the board elements would be much, much easier to get right... and it was.
Is anyone aware of a reason that relative positioning is preferable over absolute? Are there any guidelines or rules of thumb that you apply when deciding which approach to take?
For a chess like game such as you are developing, there is nothing inherently wrong with using absolute positioning. As you said, relative positioning and normal flow layout make this sort of task quite difficult.
Of course, if you were developing a more standard website, such as a site providing some public service, absolute positioning overrides the default flow layout of browsers and so will reduce accessibility for many users. In this case I would avoid it.
Having said that, a lesser known benefit of absolute positioning is that it allows localized absolute positioning within the nearest "positioned" parent element.
Note: A "positioned" element can be any of the following: relative, fixed, absolute, or sticky.
To explain:
<div id="parentDIV" style="position:relative">
<div id="childDIV" style="position:absolute;left:20px;top:20px;">
I'm absolutely positioned within parentDIV.
</div>
</div>
Here, childDIV is actually positioned 20px from the left and 20px from the top of parentDIV, NOT the overall document. This gives a nice precise control over nested elements on a page, without sacrificing the overall page flow-layout.
So to answer your question (relative positioning being preferred over absolute): I don't believe there is a correct answer, it depends on what you are needing to build. However in general positioning (absolute or relative) versus default flow layout, my approach is as described above.
Keep in mind also that absolute positioning is not only used for positioning things relative to the browser window - it's also used for positioning things accurately within a containing element. When I finally understood this - after years of using CSS - it really revolutionized my ability to use CSS effectively.
The key is that an absolutely positioned element is positioned in the context of the first ancestor element that has position:relative or position:absolute. So if you have this:
div.Container
{
position:relative
width:300px;
height:300px;
background:yellow;
}
div.PositionMe
{
position:absolute;
top:10px;
right:10px;
width:20px;
height:20px;
background:red
}
and
<div class=Container>
...
<div class=PositionMe>
...
</div>
...
</div>
...the div PositionMe will be placed relative to Container, not to the page.
This opens up all sorts of possibility for precise placement in particular situations, without sacrificing the overall flexibility and flow of the page.
It does not answer your question, but...
For a chess like game board I think you can also use a table.
After all, it is is columns and rows you are displaying.
Now I know that many people start shouting 'don't use tables' and 'tables are evil'. Tables are however still a valid tool for showing some types of data, especially columns / rows organised data.
Look at your website in different browsers under the following conditions:
Switch your OS settings to high-dpi/large fonts/high contrast (all change the size of the default browser font)
Increase/decrease the default font size in the browser
Override the page fonts in the browser (usually somewhere in the Accessibility options)
Override/turn off the page stylesheet (granted, users shouldn't expect a chess game to work properly in this scenario :-))
In general absolute position is bad when you have inline elements with non-fixed size fonts. For your scenario it might work; however, there will be a lot of edge cases where something funky will go on.
I think the problem is that absolute positioning is easy to abuse. A coordinate system is much easier for lay people to understand than the box model. Also, programs like Dreamweaver make it trivially simple to layout a page using absolute positioning (and people don't realize what they're doing).
However, for typical page layout, the default static positioning should be adequate and get the job done 90% of the time. It's very flexible, and by keeping everything in normal flow, elements are aware of the other elements around them, and will act according when things change. This is really good when dealing with dynamic content (which most pages are these days).
Using absolute positioning is far more rigid and makes it difficult to write layouts that respond well to changing content. They're simply too explicit. However, it is perfect if you're in need of freely moving elements around a page (drag/drop), need to overlay elements on top of each other, or other layout techniques that would benefit from working on a coordinate system. Frankly, a chessboard sounds like a fine reason to use it.
Relative positioning is nice if you can pull a totally fluid layout because it will look reasonable on a large range of screen resolutions.
That being said, it's quite often to find (especially when trying for cross-browser compatability with older versions), that totally fluid layouts are hard to get right. Falling back on absolute positioning shouldn't be frowned upon, most mortal web developers do it all the time.
As long as you structure your HTML so that the elements follow a logical order that makes sense when rendered without CSS, there is no reason why using absolute positioning should be considered bad practice.
There are no hard and fast rules. The different forms of positioning are all good at different things.
The majority of work is usually best done with static positioning (it is the least fragile option), but absolute positioning is very good on occasion. Relative positioning, on the other hand, is something I've never used except for animation (on elements which are statically positioned until JavaScript gets involved), establishing a containing block for absolute positioning (so the element itself isn't moved at all), and (very very rarely) a one or two pixel nudge of an element.
Some things are impossible to do without position:absolute. Other things are WAY easier to achive with absolute positioning (let say that you want a bottom-right button for "read more" in a fixed/min height box and you don't have enough text in that box).
So, my advice: just use the one that fits your needs...
It seems to me like I'm the only one here that totally disagree with the assumption that absolute posititioning is not a bad practice
Except conditions like animation or elements that should specifically sit in an "unusual" place whitin their parents, absolute positioning break the structure of your HTML (which is exactly what HTML suppose to define in my opinion) because you can achieve results that differ the visuality from the structure very easily.
Moreover, implementation of design is way harder and problematic with absolute because you need to measure every element and you have lot of place to mistake (against normal flow that is much easier and right for structure building of a website skeleton)
And finally, regarding the chess board, I believe that the hardest possible way to create it is using position absolute!
Making the board with table would be much easier and right (after all this is a table)... And personally I would do it with a cube class that would have float: left (with clear on every ninth cube)
Absolute positioning of 64 different square is insane!
IMO, not a bad thing at all. I have recently completed an assignment with AA standards compliance and support for FF2, IE7, IE6 (yes, a pain I know). There were certain layouts which were only achievable because of absolutely positioning! Even certain components like buttons where layering was needed (transparencies) were possible only because of absolute positioning. If someone has a better way, please refer me to that.
Absolute positioning breaks the flow, if we know how to restrict the flow (change parent's coords to relative/absolute) it is fun. I don't know about older browsers (IE6 itself is a dinosaur) but one painful thing I found was, writing to PDF (Cute PDF) or opening with WINWORD (sue me) gives a shabby result.
Absolute positioning is a tool, like any tool, it can be used in good and bad ways. There is nothing wrong with it: StackOverflow probably uses it to display its alerts in the orange bar at the top of the site.
Now, in your situation, this is not bad either. But I think it would be much easier for you not to use it.
A chess board is a table, table cells don't need position tweaks. For events, onblur / onfocus and cie will do the job. Why would you even need pixels calculation?
So don't be stressed by the quality of your practice, but maybe you could check if you really need absolute positioning.