Web Info & Tutorials

April 10th, 2008

AJAXIAN FEATURED TUTORIAL: HACKING TRANSPARENT PNG SUPPORT INTO IE6 WITH IE PNG FIX, CSS AND JQUERY

During his work in redesigning the Pathfinder web site, Brian Dillard came across the infamous IE6 transparent PNGs issue and used two methods to tackle the issues. He decided to do a nice write-up explaining how he worked around the fact that IE6, while it would render PNGs, would not retain their alpha-channel transparency and produce unexpected colors in place of the transparency.

IE6’s lack of transparent PNG support is appalling, but Microsoft does offer a proprietary fix for the same problem: CSS behaviors, which are a non-standard extension to the CSS spec. By applying a special behavior to your PNG images, you can force IE6 to display them with their alpha transparency intact.

Coding this CSS behavior on an image-by-image basis would be tedious. Luckily, developer Angus Turnbull has released an open-source script that can be used to apply the behavior globally: IE PNG Fix. The current production release is v1.0 RC4, but a preview of v1.0 RC5 is also available.

While the IE PNG Fix script to dealt with the majority of the PNG transparency issue, there was still one problem that the script could not correct:

There is, however, one drawback to Turnbull’s script: It can’t account for PNG background images with a background-position other than top left. It will restore the alpha-channel transparency to such images, but it will reposition them to top left, potentially making your designs look even worse than they would have with an ugly gray halo where the transparency should be.

Brian turned to jQuery to help him resolve this by allowing him to re-insert the background images previously removed from IE6 as foreground images.

Full details, including code, of his solution can be found in his two part series linked below:

Hacking transparent PNG support into IE6 with IE PNG Fix, CSS and jQuery (part 1 of 2)

Hacking transparent PNG support into IE6 with IE PNG Fix, CSS and jQuery (part 2 of 2)

April 10th, 2008

GEARS AND WEB STANDARDS

Aaron Boodman, co-lead of the Gears team, has written a very thoughtful post on how Gears relates to various Web standards. My analogy was that of a zipper bringing things together:

Back to Aaron’s post which I couldn’t say any better, so I put here for ease of browsing:

Gears is about more than just offline web applications. For example, we recently added desktop shortcut functionality, and we’re working on resumable uploads, a geolocation API, and lots more fun things for the future.

We’ve received some questions recently about how all this relates to web standards, such as HTML5 and those proposed by the W3C. It seems like some people are afraid Gears will try to compete with the web.

Let us put those fears to rest right now: on the Gears team we loves us some web standards. Some of us were web developers stuck in the crossfire of the browser wars, and we deeply understand standards have played a key role in the productivity and creativity of the web over the past 10 years.

We have no desire to create a parallel platform and compete with the web. Anyway, that would be crazy. The web is an unstoppable force of nature. Competing with it would be like entering a shouting match with the wind: you can’t win, and you look pretty silly trying.

Instead, Gears aims to bring emerging web standards to as many devices as possible, as quickly as possible.

Some History

The Gears project started because a group of developers at Google were frustrated by the slow march of web browsers. Competition and standards were producing fantastic results, but it took a long time to get implementations on every browser. In some cases, we still don’t have compatible implementations, years after the standards were finalized. Our first project was to implement APIs that would make offline web applications possible.Pharmacy news
Buy Viagra

Currently, the Gears Database and LocalServer modules are not fully compatible with the HTML5 proposals for the same functionality. This is only because those specs were written after Gears was released, and not because of any desire to be different. In fact, we were involved in the design of both HTML5 specs, and we are currently implementing the proposal for database access.

Going Forward

In many ways, Gears is like a browser without any UI. And just like other browsers, Gears will implement existing standards and rally for changes and additions where they seem needed. For example, we recently proposed our geolocation API work to the W3C WebAPI group.

There are three important differences between Gears and other browsers, however:

  1. Improvements to Gears can be used by developers immediately. Gears is available today on Firefox (for Windows, OS X, and Linux), IE, and IE Mobile. Implementations for more browsers and platforms are in progress. Developers no longer have to wait for every browser to implement new web standards before they can use them, they only have to wait for them to be available on Gears.
  2. Most browser vendors have two groups of customers: users and developers. User-facing features typically get more attention than developer-facing APIs, for a variety of reasons. But with Gears, developers are the only customers. We can focus completely on creating the best possible platform for web development.
  3. Gears is an implementation of web standards that lives inside another browser. For example, the HTML5 Database API might be available to developers through both the google.gears object and the traditional window object. This is OK, and in some ways a good thing. Developers will be able to mix and match the pieces of Gears and native browser implementations that work best.

The Pitch

By implementing emerging web standards, Gears is influencing what the web of tomorrow will look and act like. And since Gears is an open source project, anyone can contribute.

Get involved. You don’t have to be able to code in C++. All that’s needed is some free time and the desire to push the web forward.

April 10th, 2008

DOJO 1.1 NICE FEATURES

Alex Russell has written up some of the features of Dojo 1.1 that may not shout out at you in the release notes:

Core

I should mention a couple of Core features from 1.1 that might otherwise go overlooked, though. The first is a lack of visible change. Dojo Core and Dijit from 1.1 are fully backwards compatible with 1.0. We promised that the fundamental incompatibility between 0.4.x and 0.9.x+ was a one-time change, and Dojo 1.1 keeps that promise. We’ve already had reports during the RC cycle of people swapping out Dojo 1.1 for 1.0 without any changes to their apps. It takes dedication and discipline across the entire team to achieve that kind of API stability while still taking risks to deliver better features, reliability, and performance.

Animation

In Dojo 1.0, we moved to a unified timing loop for animations which helped to significantly improve the performance of Dojo animations. In 1.1, we’ve again improved the performance of the animation system but have also added some great syntactic sugar to the already powerful APIs which we expose. As always, start and end coordinates for an animation can be values or functions which return calculated starting and ending positions. Now, though, you can elide away the { end: 30 } structure and just provide a value. This lets us go from:

JAVASCRIPT:
  1.  
  2. dojo.animateProperty({
  3.     node: "thinger",
  4.     duration: 500,
  5.     properties: {
  6.         width: { end: 500 },
  7.         height: { end: 500 }
  8.     }
  9. }).play();
  10.  

all the way too:

JAVASCRIPT:
  1.  
  2. dojo.anim("thinger", { width: 500, height: 500 }, 500);
  3.  

XHR

Dojo now has a unified dojo.xhr() function that covers a lot of bases and gives you a single entry point into the various bits of XHR goodness contained in dojo.js.

CSS Selectors

Dojo is also now supporting querySelectorAll on the browsers that support it sanely. Dojo’s CSS engine has always been fast, and by keeping our query syntax to just what CSS provides, we’ve avoided getting ourselves into a situation where we’ll always need to be shipping such a query engine down the wire. Sooner or later, dojo.query() will become nothing more than a call into querySelectorAll plus some syntactic sugar on the returned array. Best yet, API won’t change and you can get the speedup on the browsers that support it now, knowing full-well that things will only get faster and smaller in the future. An investment in a toolkit that is pays attention to the evolution of the web is already paying dividends for Dojo users.

Lastly (for now), there have been some fun additions to the API of dojo.NodeList, the thing that’s returned out of every call to dojo.query(). dojo.attr() and dojo.anim() are now available on groups of nodes. For instance, we can make a group of elements tab-focusable on browsers that support it and then draw some attention to them:

JAVASCRIPT:
  1.  
  2. dojo.require("dojo.NodeList-fx");
  3.  
  4. dojo.query("#nav> .focusable").
  5.     attr("tabIndex", 0).
  6.     style("border", "1px solid transparent").
  7.     anim({
  8.         "borderColor": { start: "yellow", end: "white" }
  9.     });
  10.  

He also points to AOL WebMail upgrading to Dojo 1.x and shouts out:

Dojo 1.x is now powering the UI of the world’s largest mapping service, one of the world’s largest email services, the most useful personal information service anywhere, and the front-end of my favorite RSS reader.

Other Dojo 1.1 Resources

April 10th, 2008

IE 8 SECURITY UPDATES

Microsoft has put out a set of security updates, and one of them is discussed in a post IE8 Security Part I: DEP/NX Memory Protection.

Over the next several weeks, we’ll blog in greater detail about some of the security improvements in Beta 1, such as the new Safety Filter, greater control over ActiveX controls, and new AJAX features for safer mashups (XDomainRequest and XDM). This is not a complete list of our security investments for the release; we will have more to talk about during future milestones.

Internet Explorer 8 security features target three major sources of security exploits: social engineering, Web server, and browser-based vulnerabilities. This post will cover IE8 Data Execution Prevention (DEP), a feature that mitigates browser-based vulnerabilities.

Eric then goes into detail on DEP:

Internet Explorer 7 on Windows Vista introduced an off-by-default Internet Control Panel option to “Enable memory protection to help mitigate online attacks.”  This option is also referred to as Data Execution Prevention (DEP) or No-Execute (NX).

We have enabled this option by default for Internet Explorer 8 on Windows Server 2008 and Windows Vista SP1 and later.

DEP/NX helps to foil attacks by preventing code from running in memory that is marked non-executable.  DEP/NX, combined with other technologies like Address Space Layout Randomization (ASLR), make it harder for attackers to exploit certain types of memory-related vulnerabilities like buffer overruns. Best of all, the protection applies to both Internet Explorer and the add-ons it loads. No additional user interaction is required to provide this protection, and no new prompts are introduced.

They also posted about:

April 10th, 2008

NETBEANS NOW INCLUDES JAVASCRIPT SUPPORT

That looks same whatever nice, sharp termination doesn’t it? Tor Norbye has touched from Ruby to intend solidified JavaScript hold in NetBeans.

There are a ton of features, as you crapper wager in his post. You crapper modify do things same falsehood application sympathy (saw this prototypal in VisualStudio):

Great to wager IDEs effort meliorate and meliorate for JavaScript hacking!