What CSS Needs: Granular Positioning (part 1)
read more at: Ben Roux's Blog
There are a series of changes CSS could really benefit from that are largely ignored in CSS3. Generally, CSS3 improvements focus on the more complex design and updated methods: box shadows, rounded corners, etc. Personally, i'd like to see a "back-to-the-basics" approach that would fix some long standing properties and save developers from unnecessary code.
Position vs Position-X and Position-Y
One case i find myself in frequently is a centered column layout. In these cases, the right column typically contains scrollable content, while the left is typically reserved for navigation. When scrolling down, the user should maintain access to the navigation. Currently, this is done by handling window events in javascript and recalculating the position on the fly:
$( window ).scroll( repositionNavigation );
$( window ).resize( repositionNavigation );
function repositionNavigation() {
// calculate the window size
// reposition the navigation accordingly
}Few problems here: this code is executed as resizing and scrolling takes place. On slower machines, this results in a choppier experience. This isn't conducive to a responsive interface. From the developer side, we now have unintuitive and disparate code for positioning these elements.
A cleaner way to solve this would be a breakdown of the css position property. With it, the javascript is replaced with
.nav {
position-x: static;
position-y: fixed;
top: 150px;
}Simple as that. We now have a pure css solution. Our styling code is with our positioning code, and the positioning is handled outside of a browser's javascript engine.
Written by Ben Roux
Related protips
7 Responses
When scrolling down, the user should maintain access to the navigation.
The problem here is that this is executed as the resize takes place
What? Why are you talking about scrolling and then doing stuff with resizing? And the css seems indicate vertical change while your js changes the horizontal... it sounds like you mixed up two different things. Care to clarify?
@passcod Sorry for the confusion. Whenever you use javascript to handle element positioning, you must handle both scrolling and window resizing events.
Scrolling events typically requiring adjusting the top property, while horizontal resizing requires, as I showed above, adjusting the left (and potentially top as well)
Excellent point though. I will go ahead and edit to try and clean up the topic hopping.
I understand better now, but:
nav {
position-x: static;
position-y: fixed;
top: 150px;
}will, in my mind's eye, behave exactly as:
nav {
position: fixed;
top: 150px;
}as long as there's no sideways scrolling (which is rare).
Re: the original problem, I thought that W3C was working on something to solution that, but I can't seem to find it.
@passcod Indeed they will behave the same. But as soon as user scroll horizontally, or worse, resizes their browser, a fixed position nav will start to lay over the page contents.
Built up a quick and dirty example of what I mean by this. Try dragging your browser left and right.
Hence my caveat above. I understand the positioning. I understand the problem. I also understand how you're proposing to solution it. I was just pointing out that if the screen/window can be kept wide enough, the problem doesn't appear (and at-media blocks can mitigate it). This can all get very complex, though.
Regarding upcoming CSS, I think two solutions to the problem are coming up: alternative layouts (flex, grid) and scoping. With scoping one could, as I understand it, work with hybrid positioning much more easily.
Try this:
nav {
position: fixed;
left: 50%;
margin-left: (distance from center you want the left side)
}
Yeah, I agree with the others. You don't really need the scrolling Javascript, simply the resize one.
Outside of that, I do agree about the other properties.
Have a fresh tip? Share with Coderwall community!
