sorted by: recent | see : popular

Content Tagged with Page + ie

We desperately want users to upgrade to the latest and greatest. A prominent and respected Web citizen recently said "With Ajax we are developing to 1997 technology, and are restricted by IE 6." What if you didn't have that nagging feeling, and instead could use the platform that sits below the clients of modern browsers? You could do a hell of a lot more.

Well, maybe we get a small bone in the zero day exploit for IE that is doing the rounds right now.

Some are arguing over how easy or hard it is to get safe (run some regedit really OK?) but scary it is. Other folks can't gloat though, as who know what the hackers will find next. But, for now, we may get a few switchers. Maybe the IT guys who made the call to write ActiveX components back in the day will finally get a kick up the backside and move over? The end users? Hmm, I wonder how many are paying any attention versus clicking on the big "Internet" button and doing their thing.

That is the equation that Jeremy Keith shares with us on his article for this years 24ways. He is discussing IE6, which he sets to the variable of $web_designer_nemesis (variable used to equal NN4).

He looks at the sliding scale of support for the browser:

• Block IE6 users from your site.
• Develop with web standards and don’t spend any development time testing in IE6.
• Use the Dean Edwards IE7 script to bootstrap CSS support in IE6.
• Write an IE6 stylesheet to address layout issues.
• Make your site look exactly the same in IE6 as in any other browser.

And, gives some weight behind what you may or may not want to do. We all keep running into the highs and lows of Web development. As we look to the amazing features that current gen browsers give us we think about apps we could build. Then we come back to reality as we think about getting these apps working on browsers that people use.

A smart man just told me:

The Ajax applications that we rave about now are running on 1997 technology. Take a look at what current browsers can do, and then you will get a glimpse of where we are going.

I want to see as many forces as possible trying their best to get IE 6 users to upgrade (again: to IE.latest is fine!). One way is to develop applications that have amazing functionality that they can't use unless they upgrade.

The CSS expressions of old will no longer work in IE 8. Whenever a feature goes away in IE, Ajax hackers get worried, as many hacks rely on quirks or proprietary features of the browser.

Why did Microsoft choose this course?

• To comply with standards
  • Expressions are proprietary to Internet Explorer and as such not interoperable.
  • A common use-case for expressions was to fix IE bugs or to emulate those CSS 2.1 features not yet supported by the browser, for example, min-width and max-width. We have not only worked hard to fix these bugs in IE8 but our new layout engine supports the missing features natively.
• To improve performance
  • Expressions evaluation has a high runtime cost; web performance experts like Steve Souders recommend avoiding them to improve front-end performance
• To reduce the browser attack surface
  • Because they expose a script execution context, CSS expressions constitute a possible script injection attack vector.

The feature will still exist in IE 7 and quirks modes, but consider yourself warned and that it is time to use the new CSS 2.1 support and the like to get around the issues that CSS expressions (or Dynamic Properties) came about to solve.

Do you ever use this feature? Run into any issues where the new support doesn't give you everything you need? Now is the time to let Microsoft know.

Sunava Dutta has detailed the enhancements made to IE 8 beta 2 for Ajax developers including XDR, XDM/postMessage, DOM Storage, offline detection, and more. A lot of great stuff!

XDomainRequest (XDR)

This is an object built from the ground up to make client-side cross-domain calls secure and easy. To reduce the chances of inadvertent cross domain access, this object requires an explicit acknowledgement for allowing cross domain calls from the client script and the server. Additionally, it reduces the need for sites having to resort to the dangerous practice of merge scripting from third parties directly into the mashup page. This practice is dangerous because it provides third parties full access to the DOM. All this comes with the added benefit of improved client-side performance and lower server maintenance costs thanks to the absence of a need for server farms for proxying.

During the Beta 1 timeframe there were many security based concerns raised for cross domain access of third party data using cross site XMLHttpRequest and the Access Control framework. Since Beta 1, we had the chance to work with other browsers and attendees at a W3C face-to-face meeting to improve the server-side experience and security of the W3C’s Access Control framework. As a result, we’ve updated XDR to be explicitly compliant with syntax and directives in the sections of Access Control for requesting simple public third-party data anonymously on the client! (Section 5.1.3 in the Access Control Process Model)

The updates to XDR from Beta 1 allow IE8 to request data from the domain's server by sending an Origin header with the serialized value of the origin of the requestor. IE8 Beta 2 will only return the response if the server responds with Access-Control-Allow-Origin: *, instead of allowing the XDomainRequestAllowed: 1 header as we did in Beta 1. Other changes include support for relative paths in the open method, and restricting access to only HTTP and HTTPS destinations.

Cross-document Messaging (XDM)

Cross-document messaging is another powerful cross-domain feature that I’ve blogged about in the past. Rather than make a backend request to a remote Web service, this allows sites hosting third-party IFrame-based "gadgets" or components to communicate directly with the parent, without unsafely violating the same site origin policy. This has advantages including improved performance and reliability, as developers don’t have to resort to workarounds that behave differently between browsers and have unwanted side-effects. This technique also removes the need for embedding third-party script in your page, lessening the chance of potential information disclosure vulnerabilities like the disclosure of your sensitive data (such as information in your social network profile) to third parties without your consent.

Beta 2 updates here include moving the onmessage handler from the document object to the window object to better align with the updated HTML 5.0 draft.

window.attachEvent("onmessage", HandleMessage);

We also replaced e.URI with e.origin, which is serialized form of “scheme” + “host” + “non-default port”. This is far safer as the URI can carry potentially sensitive information from the origin site that is not needed by the recipient for the decision to grant or not grant access.

if (e.origin == 'http://www.contoso.com') 
        { 
               // process message text     
        }

Finally, the HTML 5.0 draft also mandates that the targetOrigin parameter for the postMessage method now be made a required parameter, as opposed to an optional one. This will make it difficult for developers to make errors by requiring an explicit acknowledgement of the target destination of the message by specifying the origin <URL> or wildcard <*>.

 frameOther.postMessage("This is a message", "http://example.com");

DOM Storage

Today, web pages use the document.cookie property to store data on the local machine. Cookies are limited in capability by the fact that sites can only store 50 key/value pairs per domain. Furthermore, the cookie programming model is cumbersome and requires parsing the entire cookie string for data. While cookies are useful for marking transitions and changes on the client to the server as they are sent with the request headers in chunks of up to 4KB, IE8 brings better alternatives for scenarios involving persisting data on the client and distinctly maintaining sessions in different tabs. The W3C’s HTML 5 DOM Storage objects provide a much simpler global and session storage model for key/value pair string data. Sites can store data for the life of a tab or until the site or user clears the data.

Updates for Beta 2 include changing the name of the persistent globalStorage attribute to localStorage and the removal of the need to specify the domain when writing to the localStorage

// Store a key-value pair.
localStorage.setItem("FirstName","Sunava");

Finally, we also included improved support of the updated onstorage HTML 5.0 event returned when the storage is changed. We now return the URI when the local storage is changed, so that handlers for pages can know who carried out the latest transaction in the storage space in addition to providing the source to the window of the origin. Furthering the good news, the HTML 5.0 Working Group has incorporated the clear method, which we shipped in Beta 1, into the draft. This essentially allows for script to clear all items accessible in its storage space without having to iterate though the keys.

Connectivity Event

The navigator.onLine property and online/offline events now work on Windows XP as well as Windows Vista. The work to enable this was not trivial, as connection awareness in Windows XP is not quite as advanced as Windows Vista. That said, this will be extremely beneficial for developers, who we believe shouldn’t have to worry about OS differences. The value of connectivity events is particularly appealing when used in conjunction with the localstorage, where data can be cached in case of network loss!

XMLHttpRequest

Introducing the XDomainRequest object in IE8 hasn’t diverted our attentions from constantly tweaking and improving XMLHttpRequest, which will continue to be our flagship object for same-domain communications. Post-Beta 1 energies here have focused on a few bug fixes around reliability and working with the Web Apps Working Group to clarify and improve the draft specification, our compliance with it, and W3C public test cases. A timeout method introduced here in Beta 1 for the convenience of developers is currently being evaluated for adoption in the XMLHttpRequest spec.

// Sets timeout after open to two seconds.
xhr.timeout             = 2000;

ToStaticHTML, to JSON, and fromJSON

What do you do with the strings returned from third parties using XDomainRequest or Cross-document Messaging? In today’s world of increasing script injection and Cross-site Scripting (XSS) attacks, having the option of passing these through a safe parser comes as a welcome relief. As detailed in Eric Lawrence's post on Comprehensive Protection for IE8 Security, toStaticHTML provides a powerful way of sanitizing your strings by purging potentially executable content.

//Calling:
window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");

//will return:
This is some <b>HTML</b> with embedded script following... !

In addition, IE8 Beta 2’s toJSON and fromJSON methods provide improved performance as opposed to non-native Javascript deserializers and serializers. Our implementation is based on the ECMAScript 3.1 proposal for native JSON-handling which uses Douglas Crockford’s json2.js API. In addition to the performance benefits of going native, the JSON parser provides a safe alternative to the eval() method, which has been a common and dangerous way to revive JSON objects, and could allow arbitrary script functions to execute.

There have been some clever tricks to create new custom tags in Internet Explorer, such as the createElement trick. However, I never realized that Internet Explorer itself provides a facility to define new tags in the markup and have them styled, since Internet Explorer 5!

Some details from the MSDN documentation on this feature, titled "Using Custom Tags In Internet Explorer". The trick lies in making sure you namespace things. For example, in the MSDN docs for this feature the example of creating a new JUSTIFY tag is given:

<HTML XMLNS:MY>
<MY:JUSTIFY>
   This paragraph demonstrates sample
   usage of the custom MY:JUSTIFY tag in a document.
   By wrapping the paragraph in start and end
   MY:JUSTIFY tags, the contained
   text is justified within the specified width. Try
   resizing the window to verify that the
   content is justified within a 500-pixel width.
   And don't forget to right-click anywhere on the
   window and "View Source".
</MY:JUSTIFY>

You can even style this with CSS!

<HTML XMLNS:MY>
<STYLE>
@media all {
   MY\:JUSTIFY  { text-align:justify; width:500 }
}
</STYLE>

The docs then go on to discuss applying an Internet Explorer 'behavior' to this custom element to give it expanded abilities:

Custom tags become much more interesting when applied with a DHTML behavior. Introduction to DHTML Behaviors (or behaviors) are applied to elements on a page, the same way styles are, using cascading style sheets (CSS) attributes. More specifically, the proposed CSS behavior attribute allows a Web author to specify the location of the behavior and apply that behavior to an element on a page.

Using DHTML in Internet Explorer 4.0.0, it is possible to create simple animated effects, such as flying text, by manipulating the position of elements on a page over time. Beginning with Internet Explorer 5, this functionality can be encapsulated in a behavior, applied to a custom <InetSDK:FLY> tag, and wrapped around blocks of text on a page. This can be applied to cause text to fly from various directions.

I'm going to do more testing on this functionality today to see how deep it goes, but if true it makes it easier to create browser shims for Internet Explorer for things like SVG, MathML, etc., including HTML 5 (if we namespace the HTML 5 elements, required to get this to work).

The reason I'm looking for an alternative to the createElement trick is I've found that it doesn't work with nested custom tags, which limits its usefulness. For example, I've found the following to not enter the DOM correctly:

Internet Explorer 8 Beta 2 was released today. There are several cool UI enhancements that this beta brings to the table that I won't cover in this post, but you can learn more about them on the IEBlog. Instead, I want to talk about how beta 2 affects IE's relationship to web standards.

First, CSS Expressions are no longer supported in Standards Mode:

Also known as 'Dynamic Properties', CSS expressions are a proprietary extension to CSS with a high performance cost. As of Internet Explorer 8 Beta 2, CSS expressions are not supported in IE8 standards mode. They are still supported in IE7 Strict mode and Quirks mode for backward compatibility.

In case you don't know, CSS expressions were actual bits of JavaScript that you could run from CSS rules; this was commonly used to simulate the CSS max-width property for IE:

IE 8 beta 2 also now supports alternate style sheets:

Internet Explorer 8 now supports alternative style sheets as specified by HTML4 and CSS2.1. The alternative styles that are defined by the Web page author is available through the Style menu under the Page menu. The styles are also available through the Style menu under the View menu. The No Style option on either menu can be used to disable all authors styling.

In terms of the Known Issues with IE 8 Beta 2, the first is related to Ajax bookmarking and back button support and using window.location.hash to do cross-domain communication:

Internet Explorer 8 create entries in the travel log and back button for each instance of window.location.hash that is set. This is part of the behavior for Internet Explorer 8 AJAX Navigation. If you use this technique to communicate between documents, we recommend that you switch to the Internet Explorer 8 Cross Document Messaging feature that is based on Section 6.4 of the HTML 5.0 specification.

Finally, there are some issues with the onload event for IE's XDomainRequest object that helps with cross-domain communication:

The onload event may not fire reliably. We recommend you use the onprogress events which continues to fire as the data is received.

Unfortunately this is it for this release. You can see the full Beta 2 release notes, or download it yourself.

On a related note, IE 8 Beta 2 includes cross-site scripting attack (XSS) protection:

The XSS Filter operates as an IE8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.

Finally, PPK has also published a post on IE 8 Beta 2 and its changes.

Micah Tischler wasn't happy with the variety of approaches for allowing transparent PNG support in IE 6, so he continued his work with mtjs_iepnghandler which intelligently provides true background repeat functionality for transparent PNGs as well as full positioning.

In this script image tags are supported, both with and without a blank spacer GIF, and background image PNGs may be positioned, as well as repeated, even if they're smaller than the content element they're in. Also, the repeat functionality is implemented to provide true repeat functionality, rather than just stretching everything willy-nilly.

mtjs_iepnghandler.js traverses the DOM, making adjustments where it runs into PNGs. The methods used depend on whether a PNG is in use as an image, or as a background, and, if it's a background, whether it is repeated or positioned. The script also takes into account the dimensions of the PNG to make intelligent decisions about how to implement repeats. It should be noted that, like mtjs_csswalker_iepnghandler.js, the script just sits quietly and does nothing on browsers other than IE5-6.

Micah finishes up his post comparing his solution to the others out there.

Sharath Udupa, an IE developer at Microsoft has posted on the IE 8 page navigations feature:

In IE8 mode, we provide support for script to update the travel log components (for e.g. back/forward buttons, address bar) to reflect client-side updates to documents. This allows a better user experience where users can navigate back and forth without messing the AJAX application state.

What is interesting here is that even though Sharath said: "adopted in IE8 from HTML5" we have Richard Monson-Haefel (Curl evangelist) saying Ajax is dead RIA walking. This strong conclusion comes from the fact that IE implemented an HTML 5 feature???

The Open Web always has baggage from the fact that there are many parties involved, but the benefits have always made it win out. The browser is the virtual machine of the Web. While Richard thinks that fragmentation can kill Ajax, I see a brighter picture. We have HTML 5 to look at, and browser are innovating in interesting ways. That is a good thing. It pushes us forward.

It is interesting that the articles pushed are on Silverlight using this for its own goals, but Sorry Richard, this doesn't mean people will be learning Curl :)

The IE8 team has created a blitz on its blog with a slew of posts on security. There is a ton of great stuff here, and is well worth going into detail on each post:

IE8 and Trustworthy Browsing

At first they set the scene:

This blog post frames our approach in IE8 for delivering trustworthy browsing. The topic is complicated enough that some context and even history (before we go into any particular feature) is important, and so some readers may find this post a bit basic as it’s written for a wide audience. In previous posts here, we’ve written about IE8 for developers: the work in standards support, developer tools, script performance, and more. In future posts, we’ll write about IE8 for end-users (beyond the benefits of improved performance, activities, and Web Slices). This post starts a series about trustworthy browsing, a topic important for developers and end-users and everyone on the web. By setting the context and motivation with this post, the next posts that dive into the details of IE8 will build on this foundation.

Trustworthy refers to one of our overall goals: provide the most secure and most reliable browser that respects user choice and keeps users in control of their machine and their information. For reference, Microsoft’s framework for Trustworthy Computing in general spans four areas: security, privacy, reliability, and business