Browsers’ developer tools evolution

It’s great to see that better tools for developer start to appear.

As in many other cases, the race started IE5.01 with support for script debugging in an external Script Debugger app. And now the race takes us to the new level with awesome tools built into browsers (like Firebug in Fx or Devtools in IE8) or even better external – let’s welcome dynaTrace Ajax!

dynaTrace Ajax supports IE6, IE7 and IE8, and will soon support Firefox. It’s basically the best tool out there for profiling and debugging javascript and CSS. Here’s what John Resig, creator of JQuery library says about the tool:

I’m very impressed with dynaTrace AJAX Edition’s ability to get at the underlying “magic” that happens inside a browser: page rendering, DOM method execution, browser events, and page layout calculation. Much of this information is completely hidden from developers and I’ve never seen it so easily collected into a single tool. Huge kudos to dynaTrace for revealing this information and especially so for making it happen in Internet Explorer.

And here’s Steve Souders, web perfomance guru, says:

When it comes to analyzing your JavaScript code to find what’s causing performance issues, dynaTrace Ajax Edition has the information to pinpoint the high-level area all the way down to the actual line of code that needs to be improved. I recommend you give it a test run and add it to your performance tool kit.

Must-have for any web-developer, seriously.

It’s interesting to see that Google and Apple play a good catch-up – both Chromium 4 and Apple Safari teams invest significant resources in building devtools, Chromium 4 finally has its own CPU & heap profilers now on top of V8. So bearing in mind that Firefox profiling will be supported by dynaTrace Ajax, it’s only Opera that’s left behind the game at the moment.

Come on, Opera team!

P.S. and by the way, Opera, can we get inPrivate browsing mode please?

Share :

Useful JS tips – getBoundingClientRect()

What do you use to get element’s offset? Looping through its parents and summing offsetLeft/offsetTop numbers? I bet you had problems with it. Well, I did, especially when additional positioning context was generated by an element with position!=static.

10 years ago in IE5.0 Microsoft invented a better way – getBoundingClientRect() method. It’s been popularised by PPK, specified in cssom-view spec, copied by Firefox 3,  Opera 9, Chrome 2, Safari; used in jQuery.

element.getBoundingClientRect() basically returns the object containing this element’s coordinates according to the window element. So you don’t have to do a loop, just call this method once and get the results. The only thing it doesn’t count for is scrolling offset, which can be calculated easily.

Extremely useful, thanks Microsoft IETeam!

Share :

Efficient IE version targeting

When you’re writing a web page, you have to keep in mind that IE6 and IE7 have higher market share than all other browsers combined and IE8 has only started gaining popularity. So in most projects you have to support IE6 and IE7, even though IE6 support for CSS2.1 has a significant amount of bugs and issues. IE7 was slightly better and IE8 provides full CSS2.1 support, which is nice.

Some web-developers whose fanatic hatred to IE blows out common sense, propose really weird “solutions”, while all sane people support all their target audience browsers with significant market share.

So we have three IE versions with different level of CSS support. One of the most often mentioned issues is IE6’s lack of support for :hover pseudo class on elements other than links. IE7 and IE8 support :hover fully. Another sample is that IE8 supports :after and :before generated content elements while IE6 and IE7 don’t. These are just two samples that spring to my mind just to show that level of CSS2.1 support really differs.

The first thing that most web-developers would use to specify a CSS rule for different browsers would be CSS hacks. But this leads to problems. For example, when IE7 wasn’t yet published, and people were using IE6, many developers used star selector bug to fix CSS2.1 issues in IE. When IE7 was shipped, it fixed support for star hack, but didn’t fix all the CSS2.1 issues. So using CSS hacks is perfectly backwards compatible – you know in which already shipped browsers and their versions it works – but is not future-compatible. This is because CSS hacks do not provide an obvious mechanism for a version targeting.

Conditional comments to rescue

Microsoft was aware that this problem would occur and in IE5 (and all newer versions, of course) they included conditional comments feature. There’s a perfect PPK’s post about “conditional comments” with samples so I’m not going to dive into details of conditional comments in this post. The main thing is that you can specify a version vector (IE version) and serve different IE versions with separate content – usually, CSS files.

Conditional comments allow to configure compatibility.

I consider a best practice to set one separate CSS and JS file for Internet Explorers that are older than IE8:

<!--[if lte IE 7]>
   <link rel="stylesheet" type="text/css" href="iefix.css">
<![endif]-->

 

And inside this iefix.css I use star selector hack to fix issues in IE6 and lower:

* html #someElement { /*rules for IE6 and lower */ }

Using star selector hack here is a perfect way to target IE6 and lower:

1. we are aware that star selector CSS hack was fixed in IE7
2. we are inside a CSS file that is only served to IE7 and lower

It’s perfectly future-compatible (IE8 and newer versions won’t fetch it as it’s inside a conditional comments) and also perfectly backwards-compatible (we know that star selector hack works in IE6 and lower versions).

So there’s no real need for a separate CSS file for IE6 and lower because we can easily separate IE7 and lower versions’ rules inside our iefix.css file.

Version targeting in javascript

There are cases when adding some javascript for IE6 and lower versions is required, for example, if you want to emulate :hover support on some elements.

Microsoft thought about this and along with conditional comments provided a conditional compilation technique. The approach is very similar – you put some javascript code inside /*@cc_on @*/ comment block and IE parses it. To control which version to target, special conditional compilation variable @_jscript_version is provided. This variable shows the build number of JScript compiler. Different versions of IE had different JScript compiler versions: IE5.01 had @_jscript_version of 5.1, IE5.5 – 5.5, IE6 – 5.6, IE7 – 5.7 and IE8 – 5.8. And this approach worked fine until Windows XP Service Pack 3 was shipped which replaced IE6’s JScript compiler of version 5.6 with a newer one of version 5.7. Before SP3 you could use the following code to separate IE6 from IE7 and upper versions:

 /*@cc_on 
   if (@_jscript_version < 5.7) {
     //code for IE6 and lower
   } else {
     //code for IE7 and upper
   }
 @*/

But when SP3 was installed, IE6 JScript compiler was updated and wouldn’t enter the first if clause. This was a serious compatibility issue and many libraries had to update their code to find a workaround. The problem was that we were solving an issue of one technology (CSS) with another (javascript), and these technologies are supposed to be loosely coupled. So JScript was upgraded, new features were added, but CSS wasn’t. This leads me to a conclusion that

Using conditional compilation version targeting to solve CSS problems is wrong

Again, these technologies are loosely coupled and you cannot assume that if @_jscript_version is X, CSS parser version is Y.

So ideally, if you want to support :hover for IE6 and lower in javascript, serve a separate javascript file for them using conditional comments.

But if want to support something that’s not provided in a specific version of JScript compiler – using conditional compilation is perfectly valid.

P.S. Well, if you still want to separate all IE6 from IE7, here’s a snippet that would work:

/*@cc_on
if (@_jscript_version==5.6 ||
   (@_jscript_version==5.7 && 
      navigator.userAgent.toLowerCase().indexOf("msie 6.") != -1)) {
  //ie6 code
}
@*/

So even if Windows XP user installed Service Pack 3 which updated JScript compiler to version 5.7, IE6 own version will still be 6. And it’s perfectly safe to use userAgent sniffing inside a conditional comments block which will be run in IE only.

Share :

Exploring Windows Desktop Gadgets #4 – flyouts

This is the fourth post in "Exploring Windows Gadgets” series. In this post I’ll tell you about the flyouts.

As it’s practical to have small gadgets which don’t take much of screen space, it’s not possible to display much information on them. That’s why Gadget Platform provides a way to add a flyout object to your gadget.

Flyout theory

In theory, flyout is supposed to present additional or detailed information about anything you choose.

The great example of flyout use case is standard Windows 7 Stocks gadget – it shows basic stocks rates information in the main window and the if you click on the stock rate you’re interested, MSN Money chart for this stock rate is shown in a flyout. Here’s how it looks:

Flyout is a separate HTML page which you attach to your gadget similarly to settings window – by specifying the following:

System.Gadget.Flyout.file = 'flyout.html';

Another difference from settings dialog is that settings dialog is only accessible by clicking on a options button:

and flyout is shown/hidden programmatically by setting its show property to true/false:

//show flyout
System.Gadget.Flyout.show = true;

When you set show to true, flyout html will be rendered and its window will be automatically positioned depending on the content size and gadget’s position.

Flyout provides two events – System.Gadget.Flyout.onShow which is fired when the flyout is shown and System.Gadget.Flyout.onHide which is fired when the flyout is closed.

To set flyout content to something meaningful, you have to get access to flyout’s document from your gadget main window javascript. This is achieved by using System.Gadget.Flyout.document property – but the call to it will throw an exception if flyout is hidden, so make sure you either check System.Gadget.Flyout.show property for true or wrap the code which uses System.Gadget.Flyout.document in try-catch block.

Note that you can also access main gadget page from the flyout by using System.Gadget.document property which is always available.

Enough theory, let’s modify our Gadget to show only comments titles on the main page and render a flyout with comment’s content when title is clicked.

Practice

So here’s what I did:

1. created flyout.html file
2. referenced it as System.Gadget.Flyout.file = 'flyout.html'; in rss.js
3. modified displayRSS function to store current comment object in paragraph’s expando property
4. added toggleFlyout function to the rss.js file which passes the comment object from the <p>’s expando property to System.Gadget.Flyout.document and displays the flyout

The resulting files and the compressed gadget are here.

In the next posts I’ll show what styling options we’ve got in Gadgets Platform, will proceed talking about gadgets security and talk about advanced javascript techniques that can be used in gadgets.

Stay tuned! :)

Share :

Exploring Windows Desktop Gadgets #3 – settings storage

This is the third post in Exploring Windows Desktop Gadgets series and it will be devoted to improving our comments feed reader gadget by adding settings storage functionality.

Settings storage theory

Any desktop program has its own settings storage (ini files, xml files, etc.) or uses a global OS storage (registry).

But in web-applications everything’s different – part of the functionality is provided by client (browser) and another part – by the server. Although it’s dead easy to store data on the server, on the client-side you can’t get access neither to file system nor to registry. (You actually can in IE, but this will require ActiveX scripting and therefore will ask user for an explicit permission.)

Until very recent DOM Storage specification draft, in most browsers you could only use cookies for storing some data on client side. However, IE5 introduced support for true client-side only storage – DOM Storage predecessor – userData. So it took almost eight years for the whole browsers industry to define and support similar client-side storage approach. And right at the time as DOM Storage is being drafted by W3C, it gets support in IE8.

The reason I’m telling you about DOM Storage in IE8 is that I have a strong feeling that this DOM Storage is used by Gadgets Platform to allow storing settings data for each gadget.

Settings storage practice

Settings dialog is a modal window which opens on top of your gadget. As it’s modal, the only way you can close it is to press OK or CANCEL button in its UI. Similarly to the gadget itself, settings dialog is a HTML page displayed by MSHTML.

As it would be useful to have comments feed URL and refresh frequency configurable, this is what I’ll add to my gadget:

In the settings dialog only area outlined in red is actually a HTML file, title and OK/CANCEL buttons are provided by Gadgets Platform:

To add the settings dialog to our gadget we’ll have to create a HTML file, let’s call it “settings.html”. To save comments feed URL and refresh frequency, we only need two fields and couple of labels. This is what I came up with.

If  you look at the JS code, you’ll see that it does two things:

1. calls System.Gadget.Settings.read function to retrieve data from the Gadget settings storage
2. defines a handler for System.Gadget.onSettingsClosing event

There’s a complete reference of Gadget platform events and properties on MSDN, but for our simple case it’s enough to say that System.Gadget.Settings.read reads object from the storage by its name, System.Gadget.Settings.write writes object to the storage with its name and System.Gadget.onSettingsClosing event fires when the settings dialog is closing. Settings store is separate for each gadget so don’t be afraid that your settings names can be accessed from other gadgets.

So in the window.onload handler of settings.html I try to get the data from the storage and set inputs values accordingly, and when the gadget is closing, I check if OK was pressed (e.closeAction == e.Action.commit) and if so, save inputs values into the storage. Dead easy.

Now we have to attach settings.html page to our gadget. This is done by adding the following javascript code to main.html file:

System.Gadget.settingsUI = "settings.html";

Now our Gadget will show this button in the control area:

And if you click on it, you’ll see your settings.html page rendered in a nice UI:

So now we have a settings dialog that reads and writes data from the Gadget settings store.  What we also need to do is to make our main.html read comments feed URL and refresh frequency from settings store as well. If you look at this javascript, you’ll see how it’s changed from the previous version. Basically, I just did the following:

1. rss.js now doens’t have blog comments feed URL and refresh frequency hardcoded, instead, it reads these values from settings store:
   

   window.onload = function(){
   
     //read data from storage
     var data = getDataFromStorage();
   
     if ("" != data.url && 
         "" != data.frequency && 
         /^(\d*)(\.?)(\d*)$/.match(data.frequency)) startLoop(data);
     else document.body.innerHTML = "<b>Please make sure you"+
                                   "configured everything properly</b>";
   
   };

2. System.Gadget.onSettingsClosed event handler is used to restart main loop with new settings:
   

   System.Gadget.onSettingsClosed = function(){
     var data = getDataFromStorage();
     startLoop(data);
   };

3. And startLoop function has been rewritten to allow only one main loop (but that’s pretty irrelevant to Gadgets platform):
   

   var startLoop = function(data){

      //clear existing interval (if present)
      if ("undefined" != typeof arguments.callee.intervalHandler)
        window.clearInterval(arguments.callee.intervalHandler);

      //retrieve feed again
      getRSS(data.url);

      //set new main loop
      arguments.callee.intervalHandler = window.setInterval(
        function(){ getRSS(data.url); }, data.frequency * 1000
      );
   };

And here we go – gadget’s ready :)

Save it as rss-comments.gadget to your computer and install it – you will be able to set comments feed URL (so you can start using it to watch comments on your own blog) and refresh frequency in seconds.

In the next posts of this series I will cover flyouts, make the gadget look really slick with UI enhancements Gadget platform provides, show how debugging gadgets can be really effective and dive into more details of the Gadgets platform. Stay tuned for more interesting stuff!

Share :

Exploring Windows Desktop Gadgets #2 – security and limitations

In this post (second in Exploring Windows Desktop Gadgets series) I’m going to dive deeper into Windows Desktop Gadgets platform and cover its security model and some limitations.

First of all, let me repeat that gadget is a client-side web-application running in chromeless mode on your desktop. It’s similar to HTA but provides a whole new set of functionality and also has some restrictions compared to HTA.

Gadgets security model

IE has always been the de-facto-standard platform for building powerful applications that require access to file system, Cryptographic Service Provider, WMI and other OS functionality. This functionality is achieved by using ActiveX controls. But ActiveX can’t run without a user permission! So by default javascript in web-applications has quite strong security limitations. This security model can only be weaken by users choice – by allowing ActiveX controls to run or by adding a website to a trusted zone.

But as gadgets are installed by user, so it’s his choice to run them, all functionality that MSHTML can provide is enabled (*). MSDN says:

The MSHTML runtime is configured with the set of permissions given to HTAs or the Local Machine Zone security configuration.

This rises a very important point – don’t install gadgets from non trusted sources. Or if you do, please inspect the code before you install the gadget. As Gadget runs under current user account, it won’t be able to delete system32 directory or do any other critical damage to the system. But it will surely succeed in deleting your documents or photos.

And of course, as any other Microsoft technology, Gadgets can be fully controlled by Group Policy.

For more information on Gadgets security please read this and this MSDN article.

Gadgets limitations

The main limitation to me is that there’re no modal dialogs. No alerts, no window.confirm, nothing. So if you want to do a quick debug, you have to dump data to the document itself or use a script debugger.

In one of the next posts on this topic I will cover debugging gadgets.

Share :

Exploring Windows Desktop Gadgets

With this post I’m starting a series of posts about one great Microsoft technology – Windows 7 Gadgets. I’ve already created an introduction post earlier and I recommend you to read it to find out the history of desktop gadgets. But now I will describe the technology, its theory and practice in more detail.

First of all, let’s get our hands dirty and create a simple gadget.

Creating a simple gadget

One of the things that was always bothering me was checking comments to my blog entries. There’re usually two ways to check for new comments on your blog – either by subscribing to comments RSS feed or by going to admin web-interface of the blog and checking for comments there. I don’t like first option because I’m subscribed to more than a hundred feeds in my Outlook so I only read them at the weekends when I’ve got enough free time. And I don’t particularly fancy logging to my blog every three-four hours to check for new comments. So Windows 7 Desktop Gadget with my blog comments feed would perfectly suit my needs.

Although this might not sound as a killer app to you, but it does its job and also perfectly shows how simple it is to build a gadget.

First of all, as I’ve already said, Windows 7 Gadget is nothing more than just a HTML page with Javascript and CSS. So I use the same approach as if I had to parse my blog comments on a website – a simple HTML, a bit of CSS and a bit of AJAX. So gadget building comes down to building a client-side web-app and packing it.

Creating a web-app

I created a simple page with a pretty straight-forward javascript. If you take a look at window.onload js code, you’ll see the following:

window.setInterval( function(){ getRSS(url); }, 5*60*1000);

meaning that every five minutes getRSS function is called.

This is the “main loop” of our program. As our gadget is a desktop program written in javascript and since  Javascript blocks UI when being executed, setInterval/setTimeout is the only one way to set the “main loop”.

That’s how the javascript in this web-app works:

1. getRSS function creates XMLHTTPRequest object and sends HTTP GET request to http://sharovatov.wordpress.com/comments/feed/.
2. wordpress responds with XML file containing last ten comments from my blog
3. parseRSS function parses the XML and passes the resulting object to displayRSS which just dumps it to document.body

It takes 15-20 minutes to write such a tiny piece of code. So now we’ve got a small web-application which is a very basic version of RSS reader.

As you may notice, the script doesn’t work on sharovatov.ru. Cross-domain security restrictions is a reason for that – the script is located on one domain (sharovatov.ru) and it tries to request data from another domain (sharovatov.wordpress.com). However, if you save main.html page and rss.js file to your machine, run main.html from IE8 and confirm JS execution, you will see the comments feed displayed.

As we’re done with functionality, it’s time to convert our small client-side web-app to a gadget.

Converting to a gadget

All we need to do now is to add a special manifest file. It’s just an XML file with your gadget description. Here’s mine.

That’s all. Now we pack these three files into a zip archive and rename its extension to .gadget. Here’s a link to what I came up with. Save it as test.gadget and double-click on it. If you then confirm gadget installation prompt, it will appear on the screen and the feed is downloaded and displayed.

That’s the basics of creating a gadget, if you feel interested, read MSDN or follow my posts – I will keep on writing about gadgets and in the next post I’ll show what my comments reader gadget will look like eventually :)

This is the screenshot of a 20-minutes job:

Every five minutes the gadget is updated so I can clearly see whose comment is the last one and reply if needed. Very handy :)

Stay tuned and we’ll proceed.

Share :

Windows 7 Desktop Gadgets

I’ve been playing with Windows 7 Desktop Gadget technology and I must tell you – I just love it! And I’ll tell you why :)

History

The approach of putting web-application right on a desktop was invented by Microsoft in 1994-95 (in Windows Nashville which was intended to be released in 1996) and was a part of Windows Desktop Update for Windows 95 and a core of Windows 98 Active Desktop. You could set an HTML page (plus JS, of course) as your desktop background and it would be run in IE. Microsoft even had a gallery of Active Desktop widgets. So web-widgets-like functionality was around almost twelve years ago. As with many other Microsoft inventions, it was way too ahead of time.

Another technology that played a role in inventing desktop gadgets is HTA – short HTML applications that run in a standalone way. You had to put your scripts (VBScript or JScript) and styles in a single HTML file, add a special description and rename the file extension to .hta. Here’s a sample code:

<html>
<head>
<title>HTA Test</title>
<HTA:APPLICATION
ID="objTest"
APPLICATIONNAME="HTA Test"
SCROLL="yes"
SINGLEINSTANCE="yes"
>
</head>

<SCRIPT type="text/javascript">
//some javascript code
</SCRIPT>

<body>

<!-- some html -->

</body>


You could access all ActiveX objects that your system provided – Scripting.FileSystemObject, UserAccounts, WMI etc. – basically everything that was supported in WSH and Script Runtime. If you were using classic ASP on the server, you could switch to writing HTAs with zero effort – language and all the objects would be the same. While any web-development IDEs could be used, there even was a special IDE for building HTAs – HTAEDIT.

So Microsoft had two nice technologies that weren’t actively used – Active Desktop as a way to integrate web-application with desktop and HTA as a core for writing standalone client-side web applications. Both technologies combined both to create Microsoft Desktop Gadgets – small standalone client-side web applications that run as dockable widgets on your desktop – pure HTML,CSS and JS packed with manifest file in an archive.

Usage

If you double-click on this archive, gadget will get installed and can be moved to any place of your desktop. IE8 core is used to run them, so you get full support for CSS2.1, great level of javascript and other IE8 goodness.

The gadgets concept was introduced In Windows Vista – but gadgets had to be positioned inside a special sidebar area – which is not very flexible. In Windows 7 you can put your gadgets wherever you want them to be.

Here’s a screenshot how gadgets look like on my desktop:

Gadgets are especially useful when you have a widescreen monitor or two monitors configuration so that you’ve got much horizontal space, but even if you’ve got a normal monitor as gadgets can be freely positioned, you will find them useful.

I use Twitter, weather (standard), network traffic and cpu meter gadgets.

Awesome technology! I’m planning to build couple of my own gadgets and will definitely prepare a blog post on this :)

Update: It looks like Windows Mobile 6.5 will have support for similar gadgets functionality!

Share :

Raphaёl – excellent JS vector graphics library

When you need to create charts or do other graphically-reach stuff in your web application, you’re usually going to choose flash or silverlight, which is fine, but right a kerfuffle! :) I mean, you need to know one more technology while you could achieve nearly the same results just with Javascript and vml/svg.

And here comes Raphaёl – awesome javascript library for providing a cross-browser way to operate with vector graphics written by Dmitry Baranovsky. Check out its demos – really impressive and works in all major browsers – IE6+, Firefox 3.0+, Safari 3.0+ and Opera 9.5+; and Safari on iPhone! It leverages VML functionality for IE and SVG for other browsers. While John Resig is still working on his processingjs.com (and it’s not working in IE at the moment), we already have a well-supported and easy-to-use library.

I did some tests of Raphaёl, and its performance was sufficient to use it in a production environment.

Thanks, Dmitry, really nice library!

P.S. and Dmitry’s blog on javascript is really worthy to read!

P.P.S. heh, VML is another thing that’s been invented by Microsoft (and Macromedia), then proposed to W3C as a standard; but W3C has always its own weird way – they decided to create SVG spec instead. I mean, really, spend time to spec what’s already been spec’ed so that the new spec doesn’t match the old spec – isn’t it weird?

Share :

Objects and primitive types in Javascript

Yesterday Dmitry Baranovskiy published a very interesting post about objects and primitive types in javascript.

Guess what will be alerted if you execute the following code?

var a = 5;
a.t = 3;
alert(a.t);

undefined!

Please read his post for the explanation why :)

Share: