JavaScript/Ajax Categories

Writings about JavaScript/Ajax

  • 10/07/2008 - 08:59
    Basics

    A List Apart has a timely article titled Understanding Progressive Enhancement discussing the perceptual differences between graceful degradation and progressive enhancement. I enjoyed seeing Steve Champeon's idea given new light. Additionally, now is as good a time as any to have a go at these topics, with the many new enhancements being added to today's browsers, while antiques still cutter cyberspace. I could have done without the cloyingly cute M & M analogy in the article, but that's probably my inner Cranky Woman having a go this AM.

    I've written about graceful degradation, previously. Graceful degradation means applying modern technology but ensuring the application doesn't negatively effect those viewing a web site with an Antique (remaining nameless). However, contrary to the ALA author's statement of Under this paradigm, older browsers are expected to have a poor, but passable experience, graceful degradation is just that: gracefully degrading, meaning that though the person using the Antique doesn't get all the bells or whistles, their experience at the site is more than "poor but passable".

    Progressive enhancement, on the other hand, begins with the content, rather than the technology; ensuring that the markup used to organize the content is semantically correct and valid. Then, and only then, the web site developer progresses to the use of CSS and JavaScript, both to annotate and enhance the content. That's been the primary difference between the two approaches: graceful degradation tends to focus on technology, first, while progressive enhancement focuses on content, first.

  • 10/01/2008 - 09:40
    General Ajax

    The Expert Panel session at the Ajax Experience conference should be an interesting experience for one and all. I wonder if there will be an automated device that senses the blood pressure of the participants, and automatically sprays safety foam between them, if need be?

    I did want to reassure one and all that though the Ajax Experience conference is almost exclusively male, we women do work with Ajax technologies and even publish libraries and tutorials for others to use. Of course, we're typically ignored when we do provide code, libraries, or tutorials, but still—no matter how many walls the guys put up, we seep through.

  • 09/12/2008 - 19:03
    The Browsers

    When IE8 beta 1 released, there was a minor uproar at the fact that Microsoft had dropped support for its proprietary version of opacity, while not providing support for the newer CSS-based opacity.

    Gone were the days when the following CSS setting would change the opacity of an element in all of the major browsers:

    #somediv 
    {
      opacity: 0.0; filter: alpha(opacity=0);
    }
    

    If you wanted to get opacity to work with IE8, either you'd have to have your users turn on the IE7 compatibility mode, or you'd have to add a meta tag to your web page:

    <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
    

    Yesterday, Microsoft released a post on the IEBlog that had both good and bad news. The good news was that opacity was back. The bad news was that setting opacity in such a way that IE8 would process it as IE8 is now more complicated than ever.

    It seems that the reason Microsoft pulled the old filter syntax is because the format was not CSS 2.1 compatible. However, according to comments in the post, Microsoft couldn't just transfer the opacity functionality over to the CSS approach, because the behavior between the two, CSS and Microsoft filter behavior, differs.

    Due to the gently incessant requests (!?) of web developers, Microsoft has added back in the opacity filter. However, the company is using the naming convention standardized for browser based CSS extensions, which means it still meets the CSS 2.1 requirements. Where the old, formalized, filter setting looked like the following:

    filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=0)
    

    Which had illegal characters, including the equal sign, Microsoft now has the following:

    -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";
    

    Notice the use of the "-ms-" prefix on the filter, and the use of quotes to enclose the setting, and hide the illegal characters.

    Of course, for the opacity setting to work with both IE7 and IE8, we have to use both. According to Microsoft, we have to list the new extension format first, and then older setting. This in addition to the CSS opacity setting:

    -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";
    filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=0);
    opacity: 0;
    

    I created a simple example to demonstrate how opacity would work, honoring both formats. It includes setting opacity with JavaScript, and works with Firefox, Safari, Opera, IE8, and as tested with IE7 compatibility mode. Click the image several times to hide one image, and expose another.

    theobj.style.filter='progid:DXImageTransform.Microsoft.Alpha(Opacity=' + opacity + ')';
    theobj.style.opacity=value;
    

    The challenge isn't over yet, though. The images in the first test are JPEGs, but I also tried the example with PNGs with alpha transparency. Unfortunately, IE8 beta 2 supports opacity, but if opacity settings are applied to an image or element containing an image, and the image is a PNG that incorporates alpha transparency, the transparent effect is lost when the opacity is changed.

    In older versions of IE, PNG alpha transparency was set with the AlphaImageLoader, like the following:

    #div1 img {
    filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src=fig0902.png,
    sizingMethod='scale');
    }
    

    In IE8, which normally would support the PNG transparency, when the opacity filter is changed, the alpha transparency is lost. To compensate, when the containing element's opacity is changed, the image's alpha transparency also has to be set in script, as demonstrated in a second example:

    document.getElementById("img1").style.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src=fig0902.png,sizingMethod='scale')";
    

    Since the alpha transparency in PNGs is supported with IE8 (and IE7), the CSS setting doesn't seem to need the new Microsoft extension naming. However, unless the image's alpha transparency setting is "reset" after changing the opacity, the transparency is lost when the application is run as IE8, as you can see from a third example. Oddly enough, the problem with the alpha transparency on the PNGs doesn't happen in IE7 compatibility mode. The only thing I can think is more than the name has changed with IE8's opacity implementation.

    Of course, if you use the EmulateIE7 meta tag, you don't have to muck around with the new opacity extension, or resetting the PNG filter, but you also don't get the other CSS 2.1 standard settings from IE8.

  • 08/31/2008 - 09:36
    The Browsers

    My first experiences with IE8 beta 2 have been mixed. On the one hand, I like the fact that compatibility mode no longer requires restarting the browser. However, I've found it virtually impossible to tell when I have compatibility mode turned on or off. I've also found that once turned on, you do have to reload a page in order to turn it off again, because the button disappears.

    Sam Ruby wrote about an improved namespace blurb that appeared about IE8 at a Microsoft site, which has since disappeared. In the post, Sam also mentioned that IE8 no longer supports CSS for elements it doesn't recognize, also detailed in a bug Anne van Kesteren linked in comments.

    I went to check out the bug at Microsoft's LiveConnect with IE8 beta 2, but received an error in the page that I don't have permission to view the page. Puzzled, I also noticed that the page asked if I wanted to sign out of LiveConnect.

    I had originally obtained a LiveConnect login in order to report bugs about Expression Media, which I was testing for my Painting the Web book. I figured that somehow my old account was interacting with the page in such a way as to make it inaccessible. I tried to delete cookies, in fact every kind of storage associated with IE8, but I still received the same page: I don't have permission to access the bug, would I like to sign out of LiveConnect.

    I looked more closely at the IE8 Delete options, and noticed that there's another option I missed, Preserve favorite website data, with the following explanation:

    Keep cookies and temporary files that enable your favorite websites to retain preferences and display faster.

    This checkbox overrides the cookie deletion option when login information is stored. *I'm not sure if this option was present with IE8 beta 1, and I'm not sure I like it—one could easily think they've cleared all personal information out of a browser by deleting cookies, only to forget to uncheck the favorite site option, and leave critical logins still active.

    Hakon Lie wrote about Microsoft's back stepping on standards mode. Microsoft had originally stated it would support standards mode by default with the first beta of IE8. Now, it supports standards mode by default on the internet, but supports the old IE7 non-standards mode by default for intranet accesses. The setting can be changed via a menu option, but the problem with this approach is that if you develop a web site internally and it works one way, it may break or work oddly once published externally, unless you remember to turn standards mode on when developing the page internally. This adds all new meaning to the term, quirks mode, as this really is quirky behavior.

    IE8 does implement the new JSON object, though be forewarned: it treats single quotes as second class citizens. In other words if your application returns strings delimited with single quotes, your application will fail. The JSON with single quotes still works with eval, though, so you could end up with breaking behavior when you switch from one to the other. To be honest, I find this to be a flaw with the JSON "standard"—either JSON is JavaScript Object Notation, or it's not, and single quotes can delimit strings in JavaScript.

    One new feature, or at least another feature I don't remember from IE8 beta 1 is that when you encounter a runtime error in JavaScript, IE8 now pops up a window with a note about a runtime error, and asks if you wish to debug it. I imagine this will only appear if you have developer tools enabled. The script debugger included with IE8 in beta 1 is still available in beta 2, and is one really nice feature in IE8.

    Less nice, though, is Microsoft's non-support for DOM Level 2 event handling. There's also no need to go into details about how the browser doesn't support XHTML and SVG and MathML—Microsoft will never support XHTML, which should be a disappointing given now. In fact, it's unlikely Microsoft will ever support SVG, even if this gets included in HTML5. Some would say this will kill SVG. I disagree and believe that this will eventually kill IE. Not just the lack of SVG support: Microsoft's refusal to deal effectively with the issue of XHTML support, DOM Level 2 event handling support, and so on. Too many gaping holes in standards support, and too little commitment on Microsoft's part to truly be a standards-based browser.

    On the other hand, IE8 does have improved support for CSS. It's now about equivalent to Firefox 2 in CSS support.

    Lastly, if you're a Netflix Watch Now fan, be warned: IE8 beta 2 does not work with the Watch Now feature, no matter what mode you set. Do not install IE8 beta 2 if you use this feature.

    All in all, beta 2 has the feel of being a rushed delivery. Not surprising when you consider beta 2 was released on the seventh anniversary of the release of IE6—a day some of us designated as IE6 EOL or Uninstall day.


    *The Preserve favorite option is new with beta 2, but is not working as described. It's preserving data for sites that are not on my favorites list. In addition, Microsoft puts its own sites on this list, automatically making data to them "saved" with this option.

  • 08/17/2008 - 09:03
    Specification

    Hank Williams responded to the recent ECMAScript Harmony announcement with a post titled, Ru Roh! Adobe Screwed By EcmaScript Standards Agreement. In it, he writes:

    Adobe provided support to the standards body in helping to define the standard, and most importantly, in creating an open source virtual machine called Tamarin that would run EcmaScript 4.0. But they did all of this before the standard was officially sanctioned. EcmaScipt 4.0 was nothing more than a draft proposal. But Adobe needed to make this bet because they needed a better language than the early ActionScript was, and the existing template, JavaScript, hadn’t moved substantively forward in years.

    And so Adobe released Tamarin, the EcmaScript 4.0/ActionScript 3.0 running virtual machine, and a raft of products based it...Unfortunately, while the technology of EcmaScript 4.0/ActionScript 3.0/Tamarin is compelling, the politics sucked.

    Adobe and Microsoft are bitter rivals, and the last thing Microsoft would be willing to accept is wide-spread adoption of a language that is strategically critical to a competitor...And so this meant EcmaScript 4.0 was stillborn.

    At the end of his writing, Hank summarizes Adobe's plight, now that it has been betrayed:

    the interesting question is what will Adobe do now. The technology they have is no less impressive today than it was a few days ago. But they are now totally on their own, which wasn’t exactly the plan.

    Poor, poor Adobe. Lost in the wilds of the web, all alone.

    Balderdash.

    Hank is correct with his assessment of the politics and rivalry, (though not all decisions were political in nature). But he's incorrect about his assumption that ECMAScript 4 is dead. Certain pieces of pre-existing ECMAScript 4 effort are not being pursued, true, but there will be an ECMAScript 4, they same as there will be a 5, 6, and on and on, as browsers and other applications that support ECMAScript evolve over time.

    That's really been the issue all along: there's a group within the ECMAScript community that has been pushing a much more aggressive course in the development of the next specification release than other players have been comfortable with. By other players, I don't mean only Microsoft— Google, Yahoo, Opera, Apple...all of the companies impacted by ECMAScript have agreed, with relief, that an interim specification release with full browser company support is the wisest course, with more cautious development in the future.

    In addition, Hank also overplayed the nobleness of Adobe's contribution of Tamarin, as well as the company being "screwed" in this decision. For one, Adobe agrees with the Harmony effort, while managing to get its digs in about the superiority of its offering, as implemented in Flex et al.

    Make no mistake: Adobe knew it was throwing the cat among the pigeons when it contributed Tamarin. In 2006, I expressed my concerns about Tamarin:

    So what do I think of all of this? I think it's exciting, I love the canvas element and I'm interested in many of these other innovations, it's good to revisit HTML, but I wouldn't be me if I also didn't note concerns: HTML element bloat; confusion as to direction of standards and where people should be heading; vastly incompatible web pages as browsers desperately try to keep up with all the changes; frustrated web page developers and designers also trying to keep up with changes; and a growing dominance of Mozilla/Adobe in regards to JavaScript and whether this could lead to a non-neutral ECMAScript 4.x, which does no one any good.

    In a way, Hank's biggest misunderstanding is his assuming that any of the other organizations involved with ECMAScript are somehow more "noble" than Microsoft in their involvement. Frankly, that's a naive assumption. The best we can interpret all of the organizations' involvement in the development of the ECMAScript specification—any specification, really— as being based on enlightened self interest. I wouldn't trust any organization that says otherwise.

    No, Adobe took a gamble, and the gamble didn't pay off. It will now shrug its shoulders, reflect on the ubiquity of Flash, and continue its merry course. Forgive me if I don't greet its noble stoicism at being stood up at the prom, with tears in my eyes and murmurs of "poor baby".


    Interesting comment in the Adobe post in answer to another comment:

    Unfortunately, standards aren't also the smartest things. Dumbing down is often a fact of standardization. We haven't let that stop us from innovation in the past; we won't in the future.

    Yes, trying to establish a standard that is implemented in all the major browsers is really a dumb thing to do. What we should be doing is picking a winner in this little contest, and then celebrate by increasing the number of torturous cross-browser hacks for the next two decades. That's the ticket: let's show everyone how really smart we all are by continuing our worst practices. As long as we call it "innovation" why, it's all right.

    Yes, it's all right.