Wednesday, June 24th, 2009
Category: JavaScript
The religion behind a simple $ has been fierce in the Web world. MooTools has decided to make the Dollar Safe Mode which is similar to cousins such as jQuery.noConflict (in MooTools case it just looks for the $ function). Now you can just use document.id if you want to play in the wild, or wrap up in a closure to be nice:
JAVASCRIPT:
-
-
(function(){
-
var $ = document.id;
-
-
this.X = new Class({
-
initialize: function(element){
-
this.element = $(element);
-
}
-
});
-
})();
-
Please note that MooTools will probably remain incompatible with other frameworks that modify native prototypes, as there will probably be more name clashes. This isn’t a cross-framework compatible MooTools version by any means, nor does it want to be. The whole point is not to “steal” the dollar function from other libraries.
In other MooTools news, MooTools Core Dev Thomas Aylott (subtleGradient) shows another example of overriding document.write():
I created a replacement for document.write that saves the arguments and then injects them into the page after the dom is ready. This is useful for embedding gists on your page since you can use the additional filter option to reject stuff from being written to your page. This would also be really handy for sites that include JavaFX or certain ads or anything that requires the use of document.write on your page. By deferring the injection of that stuff until after the dom is ready your visitors see the page content before any of the extras like Java applets or ads begin to load.
Tuesday, June 23rd, 2009
Category: Component, Prototype
ProtoFish is an advanced hover menu based on Prototype, written by Peter Slagter. You can easily add a delay to your menu (on mouseout) and choose your own hover class. All ProtoFish menu's will respond to users who use the TAB-key to navigate through your page.
It is trivial to use. Once you load up the script (requires Prototype 1.6+) you can:
JAVASCRIPT:
-
-
document.observe('dom:loaded', function() {
-
new ProtoFish('my-menu', '400', 'hover', false);
-
});
-
where the four parameters are:
- Menu id (In the example: my-menu)
- Delay before closing the menu (In the example: 400 ms)
- The classname to add when hovering over menuitems (In the example: hover)
- Whether or not the menu should remove .active classnames when your visitor hovers over the menu (In the example: false)
Category: CSS, Performance
There have been many tools to help make image spriting easier, by packaging up your images into one large image and splitting it up again via CSS.
Steve Souders just showed off a new little tool he created, Sprite Me at the Velocity conference that kicked off today. He has made it easier to work with sprites by:
- finds background images: SpriteMe generates a list of all background images in the page. Hovering over the its URL displays the image.
Each of the DOM elements that use that image are also listed. [DONE]
- groups images: It's hard to figure out which images can be sprited together, and how they should be laid out. For example, background images that repeat horizontally must fill the entire width of the sprite. Background images positioned
left bottom must be at the right top of the sprite if their container might be bigger than the image. SpriteMe determines which images should be sprited together based on these constraints.[IN PROCESS]
- creates sprites: SpriteMe generates the sprite for each grouping of images. This is done using open source tools, such as CSS Sprite Generator. [TBD]
- updates CSS: The final tricky part of using sprites is changing the CSS. Sometimes the CSS is a rule in a stylesheet. Or it might be a rule in an inline style block. Or it might be specified in an element's style attribute. Because SpriteMe runs inside your web page, it can find the CSS that needs to be updated. It makes the changes in realtime, so you can visually check to confirm the sprites look right.You can export the modified CSS to integrate back into your code. [TBD]
Great, a simple new bookmarklet to work with Sprites. It is always a good idea to sprite up right? Not exactly.
Vlad Vuki?evi?, a leader in the Mozilla community (and brought us cool stuff like Canvas 3D!) has spoken up on the internals of the browser, which shows you the trade-offs for the spriting approach:
The biggest problem with CSS sprites is memory usage. Unless the sprite image is carefully constructed, you end up with incredible amounts of wasted space. My favourite example is from WHIT TV's web site, where this image is used as a sprite. Note that this is a 1299x15,000 PNG. It compresses quite well — the actual download size is around 26K — but browsers don't render compressed image data. When this image is downloaded and decompressed, it will use almost 75MB in memory (1299 * 15000 * 4). If the image didn't have any alpha transparency, this could be maybe optimized to 1299 * 15000 * 3, though often at the expense of rendering speed. Even then, we'd be talking about 55MB. The vast majority of this image is blank; there is nothing there, no useful content whatsoever. Just loading the main WHIT page will cause your browser's memory usage to go up by at least 75+MB, just due to that one image.
That's not the right tradeoff to make for a website.
What alternatives are there? None right now.... but they are hopefully on the way. Some folks have been talking about the idea of packaging up images in zip files, and then the browser can manage more than just the download process, but also only load up what it needs:
Many browsers have support for offline manifests already; it might be possible to extend that to allow downloading one file (like a jar/zip file) that contains a manifest of resources and equivalent URLs that are contained inside it.
Rob Sayre, also of Mozilla, broached the subject:
Sprites have the advantage of working right now, but maybe there should be a way to serve up a multipart response with your sprite images as well. That would cut down on CSS rule count and maintenance, but still group the images in one HTTP request. Authors are already giving up the advantages of separate resources in return for speed, so maybe this is worth doing.
You can (in theory… haha) get some of these advantages with HTTP pipelining, but a multipart response would allow the server optimize the response order as they do with sprites today.
Monday, June 22nd, 2009
Category: Fun, HTML
Kyle Weems, the CSS Squirrel and author of the occasional and bizarre comic of the same name, targets his latest rendering at Ian Hickson:
Click-through to see the full comic. The related blog entry fleshes out the basic complaint some more:
Why is it that the person who is the center of this process is allowed to be a man who rejects consensus, actively denies issues (based on his own admitted policy) and substitutes expert advice in important areas like accessibility with analyzing data from the Google Index and parsing numbers? Numbers that we cannot have a third party confirm because every request to do just this is ignored?
There is no doubt in my mind that Ian is brilliant. However no man, no matter how brilliant, should be allowed to be so influential on a spec when he is bringing all this baggage to the table with him.
The number of grievances folks have with any standards process are legion, but wouldn't life be more fun if they all came with comics?
(As I wrote this, Dion leaned over and said, "I used to work with Ian, I find it funny to think of anyone trying to control him.")
Category: CSS, Video
How about starting the week with something fun. Zach Johnson has been having fun with 3D effects via CSS such as his isocube above, which is brought to you with simple HTML (including a video tag for a playing video on the surface!) and some CSS like this:
CSS:
-
-
.face {
-
position: absolute;
-
width: 200px;
-
height: 200px;
-
overflow: hidden;
-
font-family: monospace;
-
font-size: 24px;
-
}
-
-
.top {
-
top: 0;
-
left: 89px;
-
background: #fff;
-
color: #999;
-
-webkit-transform: rotate(-45deg) skew(15deg, 15deg);
-
-moz-transform: rotate(-45deg) skew(15deg, 15deg);
-
}
-
-
.left {
-
top: 155px;
-
left: 0;
-
background: #999;
-
color: #333;
-
-webkit-transform: rotate(15deg) skew(15deg, 15deg);
-
-moz-transform: rotate(15deg) skew(15deg, 15deg);
-
}
-
-
.right {
-
top: 155px;
-
left: 178px;
-
background: #ccc;
-
color: #666;
-
-webkit-transform: rotate(-15deg) skew(-15deg, -15deg);
-
-moz-transform: rotate(-15deg) skew(-15deg, -15deg);
-
}
-
-
.shadow {
-
top: 310px;
-
left: -89px;
-
background: black;
-
opacity: 0.5;
-
-webkit-transform: rotate(-45deg) skew(15deg, 15deg);
-
-moz-transform: rotate(-45deg) skew(15deg, 15deg);
-
}
-
Chris Blizzard posted his Open Video Conf talk on connecting HTML5 video showcasing the great demos of Paul Rouget :)
Friday, June 19th, 2009
Category: JavaScript
John Resig has posted on the DOM traversal methods now in Firefox 3.5 and then a spin out post on the merits of the NodeIterator API. He isn't impressed:
This API is, at best, bloated, and at worst incredibly misguided and impractical for day-to-day use.
Observe the method signature of createNodeIterator:
JAVASCRIPT:
-
-
var nodeIterator = document.createNodeIterator(
-
root, // root node for the traversal
-
whatToShow, // a set of constants to filter against
-
filter, // an object with a function for advanced filtering
-
entityReferenceExpansion // if entity reference children so be expanded
-
);
-
This is excessive for what should be, at most, a simple way to traverse DOM nodes.
One part of the critique involves the common pattern of bitwise operators that are common in C, C++, and a bit of Java (and elsewhere too). When space is at a premium, these are a good choice. There are also some nice side effects when you use them (building up the flags, munging them later, etc).
However, as John points out, these are more for CSci students than for the average Web developer.
But then the crazy comes in: In order to select multiple, different, types of nodes you must OR together the properties to creating a resulting number that'll be passed in.
For example if you wanted to find all elements, comments, and text nodes you would do:
JAVASCRIPT:
-
-
NodeFilter.SHOW_ELEMENT | NodeFilter.SHOW_COMMENT | NodeFilter.SHOW_TEXT
-
I'm not sure if you can get a much more counter-intuitive JavaScript API than that (you can certainly expect little, to no, common developer adoption, that's for sure).
He goes on to propose some more Webby APIs such as:
JAVASCRIPT:
-
-
document.getNodes( Element, Comment, Text );
-
Category: Browsers
As a follow on from the recent post on Microsoft marketing for the week, a few people have given great feedback on what we actually expect from browser marketing. This is a key point that was missing in the post as it gives those watching something to understand that could make things better. This is not about Microsoft, but about all vendors. If we keep seeing claims like this then no user will be able to take anything said from vendor seriously. If everyone claims to be the "fastest browser in the world" then that claim becomes meaningless for example.
We expect that when claims are made there is a detailed rubric on the methods. You can't just say "we are faster" for example. Right now the claims made on the IE 8 piece are so subjective that if you were in marketing you would think that you are being sneaky "we aren't teeechnically lying!" That isn't good enough though.
With the rubric we (developers) should be able to run the tests ourselves to make comparisons. When future browsers come out we should be able to rerun them.
Benchmarks can be gamed, but it is still hugely different that I can take something like SunSpider and run it on my SAME machine for the various browsers. The numbers won't be the same as on your computer, but it gives me ball park and more importantly comparisons. We can argue if SunSpider actually means anything in the grand scheme of things.... but that is another story.
As a wise man said: "Tests that aren't repeatable and claims that aren't testable (or explained) are just lies, no matter who's telling them."
What would you like to see in a Bill of Browser Vendor Ethics? :)
Category: Dojo, JavaScript
By default we should always favour asynchronous XHR to help the responsiveness of our Web applications. However, have you ever wanted a way to serialize your XHR calls because you needed to do things in sequence as B relied on what came back from A?
You could call a synchronous Ajax call, but that locks up the browser. Thibaud Lopez Schneider has written up his thoughts here showing the difference between synchronous Ajax:
and async calls with magic to serialize them:
He then went and created a simple example code generator at asynchronous.me. It is interesting to look at the code of the serialized version, and see that it doesn't do anything complex.... just passes in the next function to run as a callback:
JAVASCRIPT:
-
-
function run() {
-
request1(function () {
-
request2(function () {
-
request3(function () {
-
done();
-
});
-
});
-
});
-
}
-
function request1(callback1) {
-
// request 1
-
print("request1");
-
var xmlHttpRequest1 = new XMLHttpRequest();
-
xmlHttpRequest1.open("GET", "something1?hello1", true);
-
xmlHttpRequest1.onreadystatechange = function () {
-
if (this.readyState == 4 && this.status == 200) {
-
// response 1
-
print("response1=" + this.responseText);
-
// continue execution in the callback
-
if (callback1) {
-
callback1();
-
}
-
}
-
};
-
xmlHttpRequest1.send();
-
}
-
function request2(callback2) {
-
// request 2
-
print("request2");
-
var xmlHttpRequest2 = new XMLHttpRequest();
-
xmlHttpRequest2.open("GET", "something2?hello2", true);
-
xmlHttpRequest2.onreadystatechange = function () {
-
if (this.readyState == 4 && this.status == 200) {
-
// response 2
-
print("response2=" + this.responseText);
-
// continue execution in the callback
-
if (callback2) {
-
callback2();
-
}
-
}
-
};
-
xmlHttpRequest2.send();
-
}
-
function request3(callback3) {
-
// request 3
-
print("request3");
-
var xmlHttpRequest3 = new XMLHttpRequest();
-
xmlHttpRequest3.open("GET", "something3?hello3", true);
-
xmlHttpRequest3.onreadystatechange = function () {
-
if (this.readyState == 4 && this.status == 200) {
-
// response 3
-
print("response3=" + this.responseText);
-
// continue execution in the callback
-
if (callback3) {
-
callback3();
-
}
-
}
-
};
-
xmlHttpRequest3.send();
-
}
-
function done() {
-
// end
-
print("done");
-
}
-
You can compare that approach to Dojo Deferred:
JAVASCRIPT:
-
-
function run() {
-
request1().addCallback(request2).addCallback(request3).addCallback(done);
-
}
-
function request1() {
-
// request 1
-
print("request1");
-
var deferred = dojo.xhrGet({
-
url: "something1?hello1",
-
load: function (response) {
-
// response 1
-
print("response1=" + response);
-
}
-
});
-
return deferred;
-
}
-
function request2() {
-
// request 2
-
print("request2");
-
var deferred = dojo.xhrGet({
-
url: "something2?hello2",
-
load: function (response) {
-
// response 2
-
print("response2=" + response);
-
}
-
});
-
return deferred;
-
}
-
function request3() {
-
// request 3
-
print("request3");
-
var deferred = dojo.xhrGet({
-
url: "something3?hello3",
-
load: function (response) {
-
// response 3
-
print("response3=" + response);
-
}
-
});
-
return deferred;
-
}
-
function done() {
-
// end
-
print("done");
-
}
-
Thursday, June 18th, 2009
Category: Browsers, IE, Microsoft
There are some good engineers working to make IE a better browser. I don't want to belittle their work, but I couldn't let go the recent work of various marketing groups this week.
First up, we had the the chaps from down under try to buy downloads with 10 grand, ripping into other browsers along the way.... as they use all images and no type in their lovely page. I have found Aussies to be a hilarious bunch, but not so much this time? I can see how the idea would seem good in a meeting room.....
Michael Yoshitaka Erlewine quickly realised that tengrandisburiedthere.com wasn't taken so built his fun retort for the Mozilla community.
Then we had the new "get the facts" campaign that showed an angry "we don't suck like you think" angle:
Lately, there's been a lot of talk about Internet Explorer's speed, security, and adaptability. But many of the claims are comparing older versions of Internet Explorer to competitors' newest releases.
These pages somehow manage to claim that IE is more secure, is the only browser with privacy features, is the easiest browser to use, has great Web standards support, fantastic developer tools, is more reliable, and customizable, and on and on. They even use their monopoly baggage to claim that all of those annoying "built for IE" pages of the past make IE more "compatible". Oh, and obviously the performance of IE 8 is vastly superior to other browsers. Sure the "benchmarks" don't tell that story, but that isn't what matters. Of course, anyone who has USED THE DARN BROWSERS can get a decent feeling on performance.
IE 8 is a decent browser, much better than IE 7 and before it. However, it drives me nuts to see the marketing spin and bare-faced lies that come across here. It denigrates the work that the engineers are doing.
To finish up, I feel like I have to end with the third piece on IE this week:
Category: JSON, JavaScript
Robert Nyman has setup a really nice test suite for JavaScript 1.6, 1.7, and 1.8+ features such as getters/setters, Object.defineProperty, Object.getPrototypeOf, new String extras, and JSON.
It includes compatibility tables, and will try to run the tests on your browser to give you feedback. It also includes sample code to check web browser support that you can use in your own projects.
Nice job Robert!
Category: Articles, JavaScript
The intrepid JS hacker Juriy "kangax" Zaytsev has an incredibly detailed post on demystifying named function expressions:
Surprisingly, a topic of named function expressions doesn’t seem to be covered well enough on the web. This is probably why there are so many misconceptions floating around. In this article, I’ll try to summarize both - theoretical and practical aspects of these wonderful Javascript constructs; the good, bad and ugly parts of them.
In a nutshell, named function expressions are useful for one thing only - descriptive function names in debuggers and profilers. Well, there is also a possibility of using function names for recursion, but you will soon see that this is often impractical nowadays. If you don’t care about debugging experience, you have nothing to worry about. Otherwise, read on to see some of the cross-browser glitches you would have to deal with and tips on how work around them.
He then goes into a ton of examples of weirdness in different browsers, and fun code like this:
JAVASCRIPT:
-
-
var f = function g() {
-
return 1;
-
};
-
if (false) {
-
f = function g(){
-
return 2;
-
}
-
};
-
g(); // 2
-
and
JAVASCRIPT:
-
-
var f = function g(){
-
return [
-
arguments.callee == f,
-
arguments.callee == g
-
];
-
};
-
f(); // [true, false]
-
Finally, he shows a couple of techniques for using these correctly in the real world need of shimming:
JAVASCRIPT:
-
-
// 1) enclose declaration with a separate scope
-
var addEvent = (function(){
-
-
var docEl = document.documentElement;
-
-
// 2) declare a variable to assign function to
-
var fn;
-
-
if (docEl.addEventListener) {
-
-
// 3) make sure to give function a descriptive identifier
-
fn = function addEvent(element, eventName, callback) {
-
element.addEventListener(eventName, callback, false);
-
}
-
}
-
else if (docEl.attachEvent) {
-
fn = function addEvent(element, eventName, callback) {
-
element.attachEvent('on' + eventName, callback);
-
}
-
}
-
else {
-
fn = function addEvent(element, eventName, callback) {
-
element['on' + eventName] = callback;
-
}
-
}
-
-
// 4) clean up `addEvent` function created by JScript
-
// make sure to either prepend assignment with `var`,
-
// or declare `addEvent` at the top of the function
-
var addEvent = null;
-
-
// 5) finally return function referenced by `fn`
-
return fn;
-
})();
-
Wednesday, June 17th, 2009
Category: Ajax, Ajaxian.com Announcements, Conferences, The Ajax Experience
"When the heck are you guys going to open registration for The Ajax Experience this year!?"
Over the last 3 months that is, without question, the most frequently received email we've had from Ajaxian members like you. The good news is that the wait is finally over! Registration has officially opened for this year's Ajax Experience conference and best of all, we're offering you $300 off when you register by July 31st. Check out our just-launched Web site right here for all the benefits we have lined up for you this year: The Ajax Experience, September 14-16 in Boston, MA
Please Note: While we'll be adding the bulk of our sessions to our individual conference tracks over the next few weeks, we want to be sure you take advantage of the early-bird discount now. That said, we've once again confirmed today's best and brightest Ajax minds from across the globe and we're featuring a number of these keynote presenters and session experts for your review on the site right now, including:
* Ben Galbraith and Dion Almaer, Co-founders of Ajaxian.com
* Brendan Eich, Creator of JavaScript and CTO of Mozilla
* Douglas Crockford, Creator of JSON and Author of JavaScript: The Good Parts
* Bill Scott, Director of UX at Netflix
* Ross Boucher, Co-founder of 280 North and the Cappuccino & Atlas frameworks
* Joe Walker, Creator of DWR
* Nicole Sullivan, Creator of Object-Oriented CSS
* David Wei and Xiang Chaong, Research Scientists at Facebook
* And more!
More essential speakers and sessions to be announced in the coming weeks, so stay tuned and start planning. One feature we think you're going to love this year is "session previews." Each morning we're featuring 5-minute lightning rounds where presenters entice the audience to attend their session by giving them a brief synopsis of what they will learn. Now you'll have even more exposure to new, cutting-edge technologies and proven solutions - and a better idea of how to spend your days.
Don't delay, register now for The Ajax Experience to take advantage of your $300 early bird savings.
Category: Video
There has been a nice discussion H.264-in-<video> vs plugin APIs on the WhatWG list.
This lead to Greg Maxwell posting about his experience with the quality of Ogg Theora with real world examples, and Chris Blizzard linked it up with 35 days offering the following lead in:
The codecs being discussed are the same ones we’ll be including in Firefox 3.5 and are also the same codecs that Mozilla, Wikipedia and others have been investing in.
Recent developer nightlies of Google Chrome support these codecs and a future version of Opera will also support them. Theora and Vorbis also work in Safari if you install the Xiph Qt component. We’re quickly reaching the point where all modern browsers support these open codecs with full support for the video tag.
You’ll note that Greg’s post doesn’t have the tone of a marketing document - it’s not meant to. Nor is this a comparison against HD-sized, high-bitrate video. Instead it’s an attempt to give an honest comparison of how the open codecs fare against commonly-used formats and sizes used on the world’s largest video site. I think you’ll agree with Greg’s conclusions at the bottom of the document, especially with audio where Vorbis really shines.
There is also a discussion on how Quicktime doesn't seem to have a nice way to auto-download codecs these days, and the Xiph Qt folks haven't had an easy time getting someone at Apple to work with them. Hopefully that will change with Quicktime X.
Another hope, is that YouTube will push even harder and test out more and more with open codecs (they did the one HTML5 demo at Google I/O, but that is just a demo). If Google puts its muscle behind the standard, then a lot of the video out there would turn open pretty quickly. That being said, Google is a business, and there are lots of factors into making that happen....
Tuesday, June 16th, 2009
Category: Browsers, Opera
Opera has been leading us on to a bit product launch, and it came today in the form of Opera Unite a product which extends the Opera browser to contain a Web server inside allowing you to talk P2P between browsers (via a proxy at operaunite.com).
On the one hand, skeptics have argued that this has been done before. We have things like the Plain Old Web server and P2P extensions. However, it is nice to see it packaged cleanly, and we have the advantage of more standard APIs (HTML5 APIs, Widget APIs, etc). At Mozilla (disclaimer: remember I work there ;), we also have something that overlaps with this work in Weave.
If you check out the developer primer you will quickly learn that to create a service you simply whip up some JavaScript, XML, and call it good. It is definitely interesting that the "web server" is a server side JavaScript implementation too!
John Resig noticed that from looking at the examples you miss a decent storage API:
Reading the Opera Unite primer. Opera really needs client-side SQL
I believe that there is room for the browser to do more, and to truly be your "User Agent", thus I agree with some of the core tenants of what Opera is trying to do here. That being said, I worry that for all the talk of freedom, are we locked into Opera? :) It would be great to get this out to the community and work on getting multiple implementations and clear licensing of the protocols behind this.
What do you think?
Category: Canvas
Billy Lamberta got tired having to get so low-level as you do with the raw Canvas API. So, he create a small abstraction layer:
Doodle.js attempts to create a fun and easy way to interact with the Canvas that is lightweight, flexible, and functional. While it contains a few shape primitives it is not meant to be a full-fledged drawing api, rather a framework that allows you to build sprites and interact with them in an expressive way.
He gives plenty examples, but here is one that animates the spiral that you see:
JAVASCRIPT:
-
-
var r = 5;
-
var a = 0;
-
var frame = 0;
-
-
dot.loop(function(obj) {
-
obj.modify({x:circle_x(a),
-
y:circle_y(a),
-
fill:random_color() });
-
-
frame += 1; //update frame count
-
a += 10; //update angle rotation
-
r += 0.3; //update radius
-
-
if(a % 15 == 0){ dot.fill = '#000000'; }
-
else{ dot.fill = random_color(); }
-
-
//clear canvas every 800th frame, reset radius
-
if(frame % 800==0){oo.canvas().clear(); r = 5;}
-
-
}, 0, '48fps'); //loop indefinitely at 48 frames/sec
-
Best part of the framework? How he choose the "oo" convention for the main object:
The “oo” variable was picked because it’s easy to type, easy to remember (d-oo-dle), and easy for our eyes to parse when we look over the code (it only takes a very cursory knowledge of male psychology to understand that).
I was actually surprised that I hadn't already posted on this... or CAKE which I will mention next...
Monday, June 15th, 2009
Category: CSS
CSS3 properties can greatly improve your workflow, making some of the most time-consuming CSS tasks a breeze and allowing for better, cleaner and more lightweight markup. Some properties are still not widely supported, even by the most recent browsers, but that doesn’t mean we shouldn’t experiment with them or give visitors with modern browsers advanced features and CSS styling.
In this regard, keep in mind that educating our clients is both useful and necessary: websites don’t have to look exactly the same in every browser, and if a difference doesn’t negatively affect the aesthetics or usability of a website, it should be considered. If we continue to waste valuable time and money making every detail pixel-perfect (instead of adopting more flexible and future-oriented solutions), users won’t have an incentive to upgrade their browsers, in which case we would have to wait a long time before older browsers become legacy browsers and robust modern browsers become the standard.
The earlier we experiment with and adapt new CSS3 properties, the earlier they will be supported by popular browsers and the earlier we’ll be able to use them widely.
The words above are a conclusion in a piece in Smashing Magazine on taking your design to the next level with CSS3.
The post goes into details with case studies and examples for a huge set of enhancements available in modern browsers:
- Selector improvement
- RGBA and Opacity
- Multi-Column Layout
- Multiple Backgrounds
- Word Wrap
- Text Shadow
- @font-face Attribute
- Border Radius
- Border Image
- Box Shadow
- Box Sizing
- Media Queries
- Speech
Take a walk through the article and play with the ideas. I really like Tim Van Damme's site!
« Previous Page —
Next Page »
