I was practicing some jQuery when I found this tutorial. It does the exact same thing as I was trying with JavaScript but uses pure CSS3. I figure it is best to learn what's right then to have to relearn, so that is why I am asking if there is a benefit of one to another or is it just preference?
The CSS solution may be easier and will probably be more efficient, but it produces a much more basic solution.
For example, with the pure CSS solution, as soon as you move the mouse outside of an item, it loses focus and closes. This can be annoying for users if the menu has many levels or the items are small enough that the mouse may accidentally stray outside.
Using javascript, it is possible to keep menu items open even if the mouse moves outside. It also allows for more customization of options like animations and delays. There are plenty of jQuery plugins that make dropdown menus easy.
Always use CSS when given the opportunity except in cases where you need to use logic/arithmetic.
A similar question was asked here: Responsive design method for collapsing a div
Related
I'm trying to create a page similar to new google calendar landing page http://www.google.com/landing/calendar/
I'm using skrollr(https://github.com/Prinzhorn/skrollr) but I can't get the effect right, on google landing page if you do a small scroll it will send you to the next block and with skrollr I'm not able to get that navigation. Any ideas how I could reproduce that? is it possible to do with skrollr or you would recommend another js plugin?
Thanks!
In case you still haven't found a solution yourself, I've been tasked with doing a very similar thing. There are two ways of achieving this that I researched and choosing the right one mostly depends on the complexity of your design/expected result. Unfortunately I can't provide a link because the site won't be live for next couple of weeks.
This is what worked for me:
I used fullpage.js library to achieve 'full-page' scroll effect. You could also take a look at onepage-scroll.js and see which one fits you most - they don't differ that much in terms of functionality though.
Benefits of using fullpage.js (among other things):
integration is quick and simple
allows a lot of customisation through options hash
provides callbacks when scroll to another section is triggered (before or after it happens)
enables you to manually trigger a scroll via 'methods'
works surprisingly good on iPad/iPhones. Probably on other mobile devices as well, although I can't fully confirm that since that
wasn't a requirement for my project.
Now when you've got section-to-section scrolling in place, what's missing is the animations. Considering that fullpage.js provides you with callbacks, it's as easy as adding a class when a transition to another section/slide happens and then using that class to trigger an animation of your choice through CSS. This is what worked for me without facing major problems.
For more advanced things:
If you're looking to build something more complex, then I strongly recommend that you take a look at tween.js. This is what google used on the landing page that you've provided in your question.
It's a very powerful tool hence it requires quite some setup + it moves animations to javascript, which might be a hassle. I would rather keep them in CSS where they belong and dont use javascript until I really need to.
FYI I also started with skrollr but it won't really work with 'fullpage scroll' because what it really does is disabling scrolling and animating body/html through translate. Skrollr bases it's behaviour on scroll event which will not fire if you use libraries I proposed.
EDIT:
It appears that you can actually use skrollr in par with fullpage.js. You can see the answer on how in it's FAQ site. Thanks to Alvaro for claryfing that! Even then, I wouldn't use skrollr unless you really need it for some advanced parallax scrolling effect - as said before, depends on your needs though. :)
Let me know if you have any doubts or something is not clear in my answer.
Good luck!
I'm using jQuery Draggable in the application I create and I'm wondering if it would be possible to somehow create a line between dialog box and element on website? I want it to follow draggable box as you drag it.
I'm looking for CSS/HTML way and not jQuery/JS way. If there is no way to create it using pure CSS3/HTML5 then I'll start with JS approach - just wanted to know :)
Basically: no, there isn't a way to achieve this using CSS only.
But, if this is observed as a CSS riddle (I recommend you don't use the following solution in any real-world application whatsoever), you might be able to achieve something similar. Again, this is going to be completely abusive of both HTML and CSS.
You basically create a lot of divs, each stands for a 'pixel'. You change the divs' background-color on :hover, and maintain the background-color after :hover state is gone using a (yet another abusive) transition trick (pseudo-infinite delay).
Here's a demo: little link. Try hovering on the top parts to see the 'breadcrumbs' that get drawn as you move your mouse.
I, again, exaggerate this is completely abusive and shouldn't be used in any actual application.
This can be expanded to create a tiny painting program using CSS. I've made a little dabblet to illustrate: another little link (try drawing by clicking and moving your mouse!)
The bottom line: Use JavaScript -- it's the only resort in this case (you can't control a canvas without JavaScript).
I've just learned javascript and jquery a few weeks ago, since then I always use it to position all my divs and stuff in the screen by knowing the size of the screen and the window which I find extremely useful, but now I don't know if is this a good practice, cause it makes my web-pages fully dependant on jquery which I don't know if it may cause some troubles with different browsers.
I would really like to find answers like "Sure is a good practice, use all the scripts you want" cause I'm really loving this javascript stuff but well just tell what you think.
Use JavaScript for behaviors and CSS for styling.
Styling with JavaScript is slower and difficult for another developer/designer to figure out what you did.
Also if you use Firebug or Chrome Web Inspector you can not see where your styling is coming from.
Optionally set classes from JavaScript and not specific styling. You can transition between classes to create a nice effect. But at least your colleague can see where the styles are defined and change it.
I'm sorry, but I'm going to burst your bubble, somewhat.
It's somewhat OK to do it - as long as the page looks OK if you disable Javascript, as well. I would say it should look even better than OK. I would also say that you should only do that if the functionality of your site really demands Javascript, as well.
Keep in mind that a certain percentage of users will have Javascript disabled. I've seen sites that look horrible this way (I use NoScript on Firefox, and selectively enable Javascript as I browser), and a couple where nothing at all appears without JS enabled.
Bad.
As Darin notes, you can (and should!) use CSS for positioning and styling. That is what it was made for! Feel free to enhance the page with Javascript, but keep in mind what I say above!
You could use CSS for positioning and styling of elements. That's what it was designed for.
It's okay to use it for positioning in some cases, but using CSS is the better practice whenever applicable.
Well, In my opinion you should avoid it as often as possible. But I know sometime you don't have the choice.
And yea you can make great web apps using scripts.
It depends what you're positioning.
CSS should be your first choice for positioning standard, run-of-the-mill sections and elements of a webpage. To opt for JavaScript in these cases suggests a lack of understanding of CSS.
Likewise if you find yourself using JS to position things for different devices. Again, CSS has evolved; media queries came along for that. Rule: always exhaust CSS possibilities first.
That said, it would be oversimplification to suggest that JavaScript never be used for positioning. All of us, rightly or wrongly, have resorted (and it is just that, resorting) to JS in order to get things to look right cross-browser, particularly where support for older IEs is concerned.
But by far the biggest use case for JS positioning is for modern web aps and games. If you're building a game with random asteroids dotted around, JS is absolutely the choice for that, since the positions are based on calculation and computation.
Finally, bear in mind that when you position in JS, you are of course still using CSS. JS doesn't have its own, concurrent styling/positioning system - it simply sets CSS properties. It is simply able to do so more dynamically and conditionally than flat CSS.
It is almost certainly bad practise. Use CSS for styling - JavaScript to do this is slower, more work, and more prone to breaking.
If you're positioning everything absolutely (fixed coordinates) it won't look good on screens of different resolutions. There's no real answer to this question.. scripts have their place, and you can use all the scripts you want... Positioning all of the elements of your layout, however, is not a job for JS. Use CSS for that.
I'd start here: Starting with HTML + CSS
There is not one method for all situations. Each web application needs to employ the right tools and practices to achieve its goals. This varies so much between applications that there is not a "correct" answer to your question.
I'm a beginner WWW-developer and I'm wondering whether the dropdown menus should be written in CSS or JavaScript. What are the pros and cons between two techniques?
You'll need to use CSS for the styling. That is what it is for.
When it comes to the logic of when to show and hide them, then you need JavaScript unless you want:
The menus to be inaccessible to focused based navigation
Keyboard
Breath switch
etc
The menus to require precision mouse control
e.g. if you have a shaky hand (e.g. from arthritis) and you slip outside the edge of the menu, then a :hover based solution will cause it to vanish without giving time to get back inside
Personally, I'd avoid drop down menus for most situations.
I would like to recommend using just CSS as much as you can. As these will eliminate issues such as if someone got JS disabled and any other possible accessibility issues. Since menus are an integral part of you site navigation, it is important these are accessible to all the user segments. You can use this for pure CSS but also there are lots of tutorials online if you google "pure css menus". Also you can see here for jQuery & CSS menu example
They can be written using solely CSS. Check out this Pure CSS hover list.
JavaScript is often disabled by users, as a security measure, and the necessary code for drop-down menus can be quite involved. Also, a pure JavaScript menu is not available for browsers that don't support it, such as text-only browsers. CSS-based menus are always available, even with JavaScript disabled — browsers that don't handle it will just render a list.
With this technique, adding a menu to a page is as easy as creating an unordered list of links, with nested lists for the sub-menus, and including the appropriate style-sheet.
I'm looking for a javascript/css tooltip that can do the following:
Shows up when you hover over some page element (such as a help icon.)
Repositions itself based on the browser window (for example if it's on the far right of the page, it will show itself to the left of the page element, otherwise it'll show to the right of it. That way it won't go off of the page.)
You can hover over the tooltip and it won't disappear. This way you can select text or click on a hyperlink within the tooltip.
I'm using dojo but their dijit tooltip seems to be very inflexible, as it can only spawn off of another dijit element, most commonly a dijit button. I'd rather not having to reference a whole other javascript framework like jquery or prototype so hopefully someone has a way to do this using just one basic script.
Unfortunately for you, the tooltip style plugins available for Dojo are nowhere near the other frameworks (namely: jQuery). Because of this, you have three options:
Reinvent the wheel. Take what you learned from other tooltip scripts and build your own from scratch. This option takes the longest development time (and in the inevitable maintenance of cross-browser bugs).
Extend an existing plugin. You can take a current tooltip plugin for dojo (or perhaps a library agnostic plugin) and extend its functionality by adding your own scripts to it.
Use jQuery. This has already been said twice by others, but let me say it again. jQuery has a thriving plugin ecosystem, and if development/maintenance times are truly important to you, then jQuery should definitely be considered.
Again, assuming that you don't mind using jQuery (it's awesome!!) I played around with a few tooltips and found this one the best: http://flowplayer.org/tools/tooltip/index.html
Extensible with good documentation. Check out the 'position' config option and see if that does what you need.
Good luck!
If you do decide to use jQuery, qTip is a nice jQuery plugin that is very configurable and will probably meet your needs. http://craigsworks.com/projects/qtip/
I have been using several jQuery plugins, including jQuery TOOLS, Beauty Tips and Cluetip. I think all three meet your requirements.
If instead of a black box you want to know what's going on, I recommend this tutorial:
http://www.sohtanaka.com/web-design/simple-tooltip-w-jquery-css/
(and take a look at the comments section)
The dijit.Tooltip documentation gives two simple examples, the first attaching a tooltip to simple DOM nodes seems to meet your needs. The second happens to wire up the tooltip to another dijit-based widget (a button). Note that the property connectId takes a dom node reference or string id. Note that dijit may be used either programmatically or using a markup-based declaration.
Different tooltip implementations may have different functionality. Among other things, dijit.Tooltip provides ARIA accessibility for screen readers, keyboard access, bidi enablement, and automatic positioning around a node but within the boundaries of the screen.