I've been working with HTML and CSS for a while now.
Every time I work in CSS, I have a feeling that I'm not "doing it right".
For instance, when positioning different divs and elements on a webpage, I use "position: absolute" and "position: relative" quite often.
This can sometimes be very tedious to find the "right" position and results in very ugly numbers, such as:
position: relative;
width: 1300px;
height: -720px;
In addition to above, it also makes it very difficult to edit said divs and elements later on if I change my mind about their appearance or position.
I've watched a lot of tutorials on YouTube where people use "margin" and "padding" tags to position the elements on their websites.
I'm very confused by this since those tags are supposed to be used for creating space around elements and not actually change their position.
The strange thing is, that it is much easier to edit the website using "margin" and "padding" tags later on, if you change your mind about the appearance/positioning of those elements since they won't move around and overlap each other.
I apologize for the long query but this has been bothering me a lot lately and I would appreciate any advice regarding the positioning of elements in CSS.
Thank you
The biggest distinction between position and margin or padding is that when you set the position to absolute, relative or fixed, the element is taken out of the "normal flow" of the document and placed in its own layer. This is what allows you to use the z-index property and stack elements on top of each other. This has dramatic advantages when the elements in question are going to be dynamically sized or animated because doing so won't cause all other elements in the document to have to "re-flow", nor will the entire document have to "re-paint". In fact, when working with dynamic sizing or animations it is strongly recommended that you take elements out of the flow this way or performance can suffer.
Beyond this, understanding how absolute, relative and fixed positioning work is essential.
Absolute Positioning positions the element relative to its nearest ancestor that, itself, has been manually positioned or the body element if no ancestor has been positioned. The element is taken out of the flow and any space the element was taking up in that flow is removed.
Relative Positioning positions the element as an offset to its original location in the normal flow, but leaves the original space that the element took up in the document even though the element is now in its own layer.
Fixed Positioning is similar to absolute, except that the position is not relative to anything. It is fixed at an exact location you specify.
While all of these will pull the element into its own layer, how the layers are stacked (via "stacking contexts") are dependent upon which type of positioning you've used and the structure of the elements being positioned.
These are the reasons to use position. If you are not in need of new layers, using CSS float, flexbox are tools that can offer alternative ways to design a layout.
margin and padding should really not be used for the layout itself. They are used for small tweaks within a layout.
In summary, the default way the a browser lays out the contents of a page is the CSS Box Model, but using CSS position is one way to have certain content use that box model in different layers from the main content. CSS floats offer another, separate layout algorithm and Flexbox offers yet another. In the near future, the CSS Grid specification will be standardized and yet another layout paradigm will be available.
But margin and padding are not layout models. They are just tools to use in whatever layout model you happen to be using.
I have a site that is ~5000 pixels in height (ie relatively large). In order to position things absolutely on it I've created the below setup:
absolute div --> relative div --> multiple absolutely positioned images
I'm wondering if it is costly for processing purposes that my absolutely positioned div and relative div are 100% height each on such a large page?
The reason I am doing this is because I am transforming the parent div with translateY (which uses the GPU). However translateY translate elements relative to their height. If I do this on the images, it becomes difficult to move multiple elements with the same speed since they will be different height. I.e. I will need to translateY(200%) for an image that is half the height as the other image.
However moving the parent absolute div is much easier.
But my concern is that it is quite costly in that it is such a large div. Can someone with more knowledge let me know if this is bad to have such a large absolutely position div and relative div? Note I have a lot of images on my site...
It usually falls down to if they're parsed from HTML or dynamically generated with JavaScript. The latter(JS) is very fast compared to the former(HTML).
I'd be more worried if those images you are using are properly compressed for use on the web, you'd be surprised how many people think changing the size is enough. This answer has many variables to consider, you have to think about the content of each div, usage of CSS, amount of images used in each div, the browser you are using, etc.
You could also call divs as they are used, not just load them because the page loads. This would require the use of JS. If you are worried about performance, I can tell you right off the bat, worry about the images and how you load those.
It depends on how do you render the layout.
Because you don't have any DEMO, so I can only guess and provide some knowledge to you.
You can use chrome developer tools to find out the performance issue.
check this (in timeline, enable Show paint rectangles to figure out the performance problem)
I think you can try css property will-change: transform, if you want to use many transform in the same layer. It will help you to accelerate render speed, just like use transform3d instead of transform2d
more about will-change
I give you the common performance issue.
You can find out the remaining by yourself
, or you can give more DEMO to us. :)
Is there a way to position an element relative to it's original position, except for x=0 - that is, the element is positioned at it's original vertical coordinate but is glued to the window's left border?
Eventually, yes.
I believe the term is going to be "sticky".
It will say: this element is positioned relatively, until it passes a specific threshold, and then it will be a fixed-position, located at... wherever
I think there was some preliminary support in mobile (for things like responsive menus/headers), and the webkit developer branch.
For real-world support, you're best off to just use JavaScript.
I decided to use:
* {
-webkit-transform: translate3d(0px, 0px, 0px);
}
when I saw that it makes my animations much smoother, probably because it forces hardware acceleration. But I also need to make some z-index tweaks in order to place a shape in front of a text, to mask that text at some point of an animation. The thing is: my (grey) shape must move synced with another shape (the green one in the example below), which is behind the text.
I built a simple example to make it more visual. It works nicely on Firefox, but I just can't get it working on Chrome and Safari. Well, it works if I remove the translate3d thing, but since my actual project requires lots of sliding and smooth animations, the user experience would suffer if I did that.
Without translate3D, it's possible to position a peer DOM node (your text) between another peer (your handler) and one of its children (your mask), but only because neither your text nor your handler have explicit z-indexes. In this case all non z-indexed blocks are rendered first and then the mask is rendered last - ending up on top (even though it's a child element). Does this make sense? Well it's how browsers work.
However, when you added translate3d to "*", you added a "stacking context" to each element, so what "happened to work" without a translate3d, now doesn't. Incidentally,adding an explicit z-index to each element in your example - also "ruins" your mask. Again, you can't position a peer DOM node between another peer and one of its children, because the children inherit the parent's z-index as far as positioning relative to an uncle/aunt node goes.
My advice is to unnest your stuff so that everything you want to position relative to each other in the z-axis is a DOM peer. This requires manually calculating every element's absolute positioning, and you lose the benefit of overflow clipping, but hey, it works. You can also duplicate this by doing 3D transforms with positive and negative z-values - but again, only among peer elements.
(Marking the z-index as !important, just undoes the cascade and places the element on top of the cascading stacking order. It's a hack.)
Got it! We can use CSS clip Property to mask the text and update the rect values based on the other object's position. Here's some info w3schools.com/cssref/pr_pos_clip.asp. This link is pretty insightful also http://webdesignerwall.com/tutorials/5-simple-but-useful-css-properties.
And finally here is my project, done http://iuqo.com. When you drag the background you see the text being (vertically and nicely) cut. Exactly as I wanted it.
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.