How can I position an element--such as a complex cursor unsuitable for the cursor property--relative to the mouse position using CSS 3?
I know how to do this with JavaScript, but it appears too choppy; I'd rather use CSS and fall back to jQuery when support is lacking. (Event when I work with elements directly and bypass jQuery, it's too slow.)
JavaScript can be used to make preparations and such, if necessary. While not preferable on principal, JavaScript is acceptable as long as it isn't in charge of updating the element every time the mouse moves.
I kindly request that answers not be used to reason why this cannot be achieved, as CSS is rapidly evolving, and the future potential of solving this problem may change. Feel free to speculate all you want in comments.
I am using Sass (SCSS) with Compass and jQuery, along with my own JavaScript framework.
As of today, CSS does not support positioning elements relative to mouse pointer.
So if you're not satisfied with cursor: url('pointer.cur') (thanks #ilya-streltsyn), then JavaScript is the only solution for you.
Or maybe you shouldn't do that in the first place. When an SWF uses a custom cursor, this freaks me out a lot.
Related
Recently I've dived into the topic of CSS animations and transitions.
I'm aware of the CSS property will-change which could be used to give a hint to the browser, that the element will change in the near future (which could improve the rendering performance).
There are several examples where developers are using will-change to improve the performance, e.g.:
https://www.android.com/
https://www.cube.eu/
https://www.mrsandmr.com/
But the docs clearly state, that:
Warning: will-change is intended to be used as a last resort, in order to try to deal with existing performance problems. It should not be used to anticipate performance problems.
So, what are essential considerations to make, whether to use will-change - or not?
DigitalOcean made a great post about this that I would highly recommend you check out.
https://www.digitalocean.com/community/tutorials/css-will-change
As someone else stated, will-change creates a new 'layer' in the browser, so to speak. If you have multiple animations or transitions under a specific parent element, it may be a good idea to assign will-change to that parent element while leaving the animated child elements with their standard animations/transitions.
Edit: I should point out that adding will-change in multiple places will increase your paint time as someone else mentioned, which will decrease your site load speed.
The question is pretty straight forward. Should I use CSS or JQuery when styling elements that are in the hover state (does one have any real advantage over the other)? To me, using JS seems like a hassle since the pseudo-classes are so easy to use. Thank you!
You should use CSS wherever possible; it's more efficient.
It also works better with property cascade and with elements created later.
Well it depends. If you want your website also displayed on mobile devices it is wiser to make a hover class and attach it with jquery because mobile browser handle hover very sketchy and different.
This is an effect very seen but i dont know how to do it, i want to have a DIV in an absolute position, for example in the middle of the page
but when you scroll down and your "border-top" of your navigator touches the div, then it comports like with
position:fixed; top:0px
Is there any way to do it only with css3? I think i can do it with jQuery and changing classes dinamically, but I'm sure there is an easy way
Thank you
It's not possible in plain CSS3 without Javascript/jQuery's help for at least a few reasons:
CSS is a language where you can only define rules that determine the appearance of HTML elements and cannot implement other programming concepts like conditions, variables, etc. [However SASS (Syntactically Awesome Stylesheets) does support the use of the aforementioned, but it lacks in so many things from Javascript, e.g. it cannot listen to events from DOM elements just as Javascript does.]
You need to listen to the scroll event when the page is scrolled (which isn't possible in CSS). For this listening to happen, you need to register a handler to handle the situation when that particular event is fired.
As soon as the current position from the top of the screen reaches some height (better known as offset) upon scroll, first, you may want to calculate that offset. Next thing you'd do is to add the style to the element which forces position: fixed on it. You could define the rule for this in CSS certainly, but yet again, you need Javascript's help to enforce this rule on the element.
I'm trying to implement a custom image cursor in CSS, e.g.
cursor:url(/img/custom.png), pointer;
this works great, except when the mouse moves over a flash element (e.g. embedded youtube video). Then it reverts back to the standard mouse cursor. Is there a way to override this?
The best "solution" would probably be to include the custom cursor in the flash as well.
Not really a perfect solution, but this site suggests putting an empty div that loads the movie in when you click it (also helps initial page load time).
I'm not sure if it works, but this site says it has a way to have a javascript command activate. Might be more than you want, but I know the solution listed gets rid of flash objects seemingly infinite z-index (thus I know it can override part of it).
My colleague and I are having a tough time deciding on a best practices approach for ie6, ie7 support for a site we're building. The site is for an older crowd, so not supporting these browsers is out of the question.
At the same time, we're trying to start incorporating modern coding practices into our work so we can get practice and fully understand capabilities. A specific area I want to touch on with you guys is handling fall backs for CSS3 backgrounds.
We have 2 choices here, if we're to use CSS3 backgrounds and not add extraneous wrapping tags for backgrounds:
Use :after, :before etc. pseudo elements for adding multiple backgrounds to elements. (this is the choice we've made for now)
Use CSS3 multiple background specifications
This produces more elegant markup and is certainly a step in the right direction. But what about browsers that don't support these features?
Modernizr.js tells us to check for specific support and then write fallbacks:
Modernizr.load({
test: Modernizr.geolocation,
yep : 'geo.js',
nope: 'geo-polyfill.js'
});
However, we're not given much guidance on the actual fallbacks for specific features. So, in the case of something like CSS3 backgrounds, what would be an effective fallback strategy?
Would we (for example) use jQuery to wrap those extra tags we need (ie btn-container, nav-container, etc.) around nav items, buttons and containers in order to have extra elements to add style attributes to?
About the CSS3 multiple backgounds and/or background gradients I think there is an approach better than those you proposed: CSS3 Pie.
This way you will be able to use all those nice effects also in IE6, 7 and 8 (including also border-radious) without any JavaScript intervention.
1. Fail gracefully. Certain complex elements can be hidden with CSS and revealed upon page-load with JavaScript depending on the browser as one example.
2. Conditional style-sheets or JavaScript fixes. Spend a lot of time fixing each problem in each browser and write a style-sheet just for it. Also, you could try various JavaScripts that claim to bring older browsers into compliance. I've tried this JavaScript but it seemed to conflict with jQuery. CSS Pie is another option to bring rounded corners to older browsers.
3. Ignore older browsers. Do nothing special for older browsers. People on IE6/7 already see the world differently than everyone else. Alternatively, do nothing special for older browsers but actively avoid overly complex functions & features. Optionally, you can add a nifty "upgrade notification" message with little effort.
Would we (for example) use jQuery to wrap those extra tags we need (ie btn-container, nav-container, etc.) around nav items, buttons and containers in order to have extra elements to add style attributes to?
That is certainly one valid fallback approach. Depending on the design and the elements in question, though, you might find that simply supplying the primary background is enough to yield a decent-looking and perfectly functional, though not visually identical, component.
"Supporting" older browsers shouldn't always mean "taking great pains/writing tons of extra code to insure a near visual match." It is difficult but not impossible to ramp up a QA team so that they understand the concept of Progressive Enhancement as it can be applied to aspects of pure visual presentation.