Non-Flash Peeling Page Effect Using jQuery & CSS
Non-Flash Peeling Page Effect Using jQuery & CSS
|
|
The Peeling Page is an effect is normally used by advertisers to show advertisements that would otherwise occupy space that is larger than what is available on a page. It is very slick, and is normally implemented in Flash. This script on Flashden costs $4, though there is a free tutorial available. The thing about the Flash version is that it uses both JavaScript and Flash, which may not be everyone’s cup of tea.
This is where Soh Tanaka’s jQuery + CSS idea comes in. It uses simple CSS and jQuery to mimic the Flash version, which can possibly translate to faster development and maybe even faster loading pages. The tradeoff is the absence of any extensive banner animation — something that can only be done in Flash. However, I believe this solution is worthy of a look, at least for those in need of a quick peeling page component for their project.
Simple Page Peel Effect with jQuery & CSS
Similar Posts
- You want to offer a “stylish” low-contrast and an easy-to-read high-contrast version of your site.
- You have many low-vision readers and want to give them easy access to a customized stylesheet with a larger typeface.
- Your site is schizophrenic and you want to be able to change the look quickly.
- Fully accessible to screen readers and assistive technology
- Partially selectable text (cannot select surrounding elements)
- jQuery integration
- Anti-aliasing results in crisp font rendering
- Flash-based font embedding is generally an allowable practice by most font foundries
- Easy to add text effects such as shadows in Flash
- Requires Flash
- CPU and memory intensive
- Font license restrictions can be difficult to set up (e.g. Flash loading needs to be locked to your domain)
- Can be tricky to set up
- Embedded fonts cannot be printed
- Easy to set up
- Does not require Flash
- Fastest loading and processing time (according to this presentation)
- Inability to highlight and copy/paste text
- License issues prevent many fonts from being legally embedded
- Does not support justified text alignment
- Hover state for elements other than links might result to unpredictable results
- Requires extra JavaScript to prevent FOUC on IE7
- Easy to set up
- Does not require Flash
- Fast loading and processing time
- Fonts are only selectable in browsers that support <canvas>
- Hover state is not supported, but a workaround that requires extra code is available
- License issues prevent many fonts from being legally embedded
- Long loading times in IE
- Only supports TTF (does not support .otf, PFB, and postscript fonts)
- Requires extra JavaScript to prevent FOUC on IE7
- Has spacing issues, according to some people
- Does not require Flash or JavaScript
- Fonts are rendered as an image and does not violate font licensing terms
- Many text effects available thanks to Imagemagick
- Inability to highlight and copy/paste text
- Can be painful to set up
- Requires a web server with PHP and the GD library enabled
- Finer details of fonts are not rendered very well by the GD library
- Takes up additional server resources to process (bandwidth and CPU)
- You plan to bombard the user with fancy effects. It will cause the viewer to suffer from migraines.
- Your website can live without it
- Your target audience consists of elderly or disabled people.
- You are working on a login page. AJAX will essentially renders password managers useless.
- You need specific pages or content to be bookmarkable.
- Your users need to use the browser’s back button or history feature.
- You plan to use it on a web based application.
- You plan to add support for non JavaScript-enabled browsers.
- Your target audience consists of tech savvy users.
- You are creating a tool or a widget that will be used on another site.
- You need to conserve bandwidth – AJAX allows you to refresh specific content without having to load the entire page.
- Certain tasks will be finished much faster with AJAX.
jQuery.popeye Inline Lightbox Alternative
jQuery.popeye transforms an unoredered list of images into a box displaying only one preview image at a time. The box has controls to skim through the preview images and to enlarge a given image. The box expands to accomodate the enlarged version, while the controls are hidden in full image size mode. A simple click on the image returns the box to its compact state.
The compact box has fixed, automatically calculated dimensions. The widht and height are calculated so that all thumbnail images are cropped to the smallest width and height in the set and centered resulting image area (stage).
This behaviour can be overriden in the plugin options.
Also available is a demo page which best shows the behavior of jQuery.popeye.
The nice thing about jQuery.popeye is that it degrades gracefully into a scrollable list of thumbnails which link to an enlarged version.
For more details, head over to the jQuery.popeye homepage. You can also go directly to the download page.
A Simple jQuery Stylesheet Switcher
There are lots of reasons you might want to offer your users more than one CSS file for your website:
Whatever the reason, it’s amazingly easy to create a function that swaps between multiple stylesheets using jQuery.
The first step of course is to build several different CSS files, which we’ll then swap between. Once that is done, we can dive into the XHTML and jQuery that makes the magic happen.
The XHTML
First, we need to create a set of links that will allow the user to swap between CSS files. You can make this as simple or as fancy as you’d like. For the sake of brevity, my links are simple:
<ul id="nav"> <li><a href="#" rel="/path/to/style1.css">Default CSS</a></li> <li><a href="#" rel="/path/to/style2.css">Larger Text</a></li> <li><a href="#" rel="/path/to/style3.css">Something Different</a></li> </ul>
Here I have three links, each with a “rel” attribute indicating which CSS file the link will load. Technically, I could have just as easily put this information in the “href” attribute, but I didn’t want to for one specific reason: if the user has JavaScript disabled and the CSS file is listed in the href, then clicking the link will send the user to the CSS file directly (not loading it like we intended). But our way, if JS is disabled, the user gets nothing at all: which is certainly preferable to the less savory alternative.
The jQuery
Like I promised, the jQuery is really simple:
$(document).ready(function() {
$("#nav li a").click(function() {
$("link").attr("href",$(this).attr('rel'));
return false;
});
});
This function waits until the document is loaded (generally an important step when interacting with the DOM), then attaches a click function to each of our nav anchors. The function basically says, “when someone clicks on this link, replace the link (stylesheet) tag’s href attribute with the contents of this link’s rel attribute.” The “return false” at the end just stops the browser from trying to follow the link.
Of course, you might have to get more detailed if you have more than one link tag, for example, but that’s easily done by giving the link tag a class (”changeme,” for argument’s sake), and writing something like this:
$("link.changeme").attr("href",$(this).attr('rel'));
And while this stylesheet switcher is already complete, we might want to give it some memory: after all, your users might get annoyed if they have to switch their styles back to their preferences every time they visit your site. For that, we’ll need to set a cookie. And to make that easier, I’ll use the jQuery cookie plugin (which I’ve talked about previously when building a popout ad).
With the plugin loaded, we can modify our jQuery thusly:
$(document).ready(function() {
if($.cookie("css")) {
$("link").attr("href",$.cookie("css"));
}
$("#nav li a").click(function() {
$("link").attr("href",$(this).attr('rel'));
$.cookie("css",$(this).attr('rel'), {expires: 365, path: '/'});
return false;
});
});
Now we have two statements. The first one checks as soon as the page is done loading to see if a cookie called “css” has been set. If so, it sets the stylesheet to be the one indicated in that cookie. Otherwise, it does nothing.
Our click function is much the same, except after we set the stylesheet, we also set a cookie. This cookie doesn’t expire for an entire year (and each time the user changes their stylesheet preferences, it would reset this timer), giving them a good 365 of CSS bliss.
Fine Tuning
There is one minor annoyance with this stylesheet switcher: there’s generally a flash of the “default” CSS when the user loads the page. That’s because the script waits until the document is “ready” before switching the link’s href. There is a way around this: moving the first “if” statement outside of the document ready function, like so:
if($.cookie("css")) {
$("link").attr("href",$.cookie("css"));
}
$(document).ready(function() {
$("#nav li a").click(function() {
$("link").attr("href",$(this).attr('rel'));
$.cookie("css",$(this).attr('rel'), {expires: 365, path: '/'});
return false;
});
});
Generally speaking, you don’t want to run any jQuery until your document is ready. However, so long as your jQuery comes after your link tag in your document structure, like shown below, this shouldn’t be a major concern:
<link rel="stylesheet" type="text/css" href="style1.css" /> <script type="text/javascript" language="javascript" src="jquery.js"></script> <script type="text/javascript" language="javascript" src="jquery.cookie.js"></script> <script>... your jQuery goes here...</script>
This means your jQuery will run before the document is done loading, and thus your link tag’s href will be swapped before your CSS has been applied. As I said before, it’s generally a bad idea to manipulate the DOM before document ready, but because we know the exact tag we want to manipulate and can place our jQuery below it in the DOM, we should be safe in this one specific instance.
Here’s an example if you would like to see this technique in action.
Running jQuery with Other Frameworks Via noConflict
While jQuery is certainly a popular JavaScript framework, it’s by no means the only game in town. Other frameworks such as Prototype, MooTools, Dojo and many others all have their own strengths, weaknesses, and devoted groupies.
Generally speaking, these frameworks all play well together — you can mix and match framework functionality to your heart’s content, as long as you don’t mind the additional overhead of loading several libraries simultaneously. So you have a calendar widget in jQuery that you love, but you’re already using Prototype to animate your navigation bar? Don’t be shy… use both!
Of course, every once in a while you can run in to problems when combining JS frameworks — particularly (in my experience) when combining jQuery and Prototype. Luckily, jQuery was kind enough to provide us with a workaround.
The Problem: Sharing Syntax
The most common compatibility problem stems from both jQuery and Prototype using the same shortcut syntax: namely, the $().doSomething syntax. Here’s a sample line of code in jQuery:
$('#myelement').addClass('active');
And the same functionality in Prototype:
$('myelement').addClassName('active');
Note the basic similarity? Both frameworks claim the dollar sign notation for themselves, which can wreak havoc on snippets of code dropped willy-nilly into a website. If your jQuery code is grabbed up by Prototype, things will stop working fast. And similarly, if your Prototype code is snagged by jQuery, not even the awesome power of jQuery will be enough to overcome the code confusion.
The Solution: noConflict Mode
But not to worry! jQuery has provided us with a workaround called “noConflict mode.”
By default, there are two equally correct ways to call a jQuery function — the dollar sign notation, and “jQuery” notation:
$('#myelement').show();
jQuery('#myelement').show();
Both of the lines above do exactly the same thing. However, most people use and prefer the dollar sign notation. Why? Probably because it’s shorter, and if web developers didn’t care about brevity in their code, they probably wouldn’t have used a framework in the first place.
Of course, just using the longer jQuery notation isn’t enough. If jQuery has already claimed the dollar sign for itself, any Prototype functionality relying on that notation will still be grabbed by jQuery.
This is where the noConflict function comes in handy. Simply run the following line after both Prototype and jQuery have been loaded:
jQuery.noConflict();
This will cause jQuery to give up the dollar-sign notation, allowing the other library to take it over. And you can still use your jQuery snippet, provided you change all instances of $() to jQuery().
Keeping it Short
The noConflict mode does have one other bit of functionality that I’ve found useful in some of my projects: you can select a different variable to use instead of the standard “jQuery”. The usage looks like this:
var $j = jQuery.noConflict();
Now in addition to using the default jQuery() notation, I can also use the shorter $j() notation. This allows me to avoid running into problems with other frameworks, while still enjoying almost the same conciseness in my code.
Valencia Community College
CSS Page Printing. Rotate Image Scripts. Remote Control. Flash Video Component. Flash Video Skins … Rotate Image Scripts. Banner AD Rotater. Random Image on Refresh …Text Replacement Roundup: The Pros and Cons of SIFR, Cufon, Typeface.js, and FLIR
Those of you who have explored rich typography solutions for web development should be very familiar with the different techniques floating around the Internet. Until majority of the population uses browsers that support CSS3, and until commercial font licensing issues allow use of the @font-face rule to become a norm, many resort to these font embedding techniques.
The thing with non-standard font embedding techniques is that they mostly rely on JavaScript and sometimes Flash or PHP to render text in whatever custom font is specified. Thus, choosing the right solution for a web project can become tricky. This article aims to compare them by listing the pros and cons of each technique.
Scalable Inman Flash Replacement (sIFR) / sIFR 3
Probably one of the first full-blown text replacement solutions, SIFR uses a combination of JavaScript, CSS, and Flash to render custom fonts.
Pros:
Cons:
Cufon
Cufón aims to become a worthy alternative to sIFR, which despite its merits still remains painfully tricky to set up and use.
Pros:
Cons:
Typeface.js
Typeface.js is similar to Cufon, using a JavaScript engine to render fonts on a browser using canvas or VML.
Pros:
Cons:
Facelift Image Replacement (FLIR)
Facelift Image Replacement (or FLIR, pronounced fleer) is an image replacement script that uses JavaScript, PHP and the GD library to dynamically generates image representations of text that use custom fonts.
Pros:
Cons:
The good thing about these techniques is that they all take into account things like accessibility, SEO readiness, and browser support. These are all huge factors in web development today. For Internet Explorer users, IE6 is supported at least, and for non-supported browsers, thankfully every one of them degrades gracefully into your standard HTML rendered text.
In conclusion, every one of these techniques has its own set of advantages and disadvantages. sIFR is the oldest and most “proven method”, however it relies on both Flash and JavaScript thus taking a hit on performance. FLIR uses the old school technique of replacing text with images and even offers text effects. However, it is hardest to set up and requires a web server with PHP and the GD library enabled.
Typeface and Cufon are the most promising beign the easiest to setup. On the other hand they are both plagued with licensing issues and lack of ability to select text, which for many can be a deal breaker. This appears to be changing though, as Type Select builds on top of typface.js and promises text selection functionality. Still, it is a relatively new player and is also plagued by limitations such as lack of support in IE and no support for :hover and line breaks.
6 Reasons Not To Use AJAX … And 6 Reasons Why You Should
Having to go through tons of sumbmissions for the CSS Vault Gallery over the past few years, I have noticed a definite increase in the amount of sites that use AJAX or some form of JavaScript. There seems to be a trend where even simple 5-page websites use JavaScript to some extent, in an attempt to generate additional interest on the viewer. Sometimes they are entirely unnecessary, and there are cases when the presence of AJAX only serves to annoy or encumber the user.
AJAX technology must then be used only when necessary. I have come up with a list of reasons for this purpose.
DO NOT USE AJAX when …
DO USE AJAX when …