Archive for the ‘ie’ Category

Undocumented jQuery constructor

Wednesday, September 17th, 2008

In jQuery it is possible to create nodes in a foreign document by calling jQuery('<div>sample html</div>', foreignElement.ownerDocument);. If somebody documented this I wouldn’t have lost the last hour or so.

This is why I like wiki style documentation.

Reblog this post [with Zemanta]

Background on html

Monday, March 24th, 2008

There’s a paragraph in the CSS specification regarding the background property that states the following:

For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. User agents should observe the following precedence rules to fill in the background: if the value of the ‘background’ property for the HTML element is different from ‘transparent’ then use it, else use the value of the ‘background’ property for the BODY element. If the resulting value is ‘transparent’, the rendering is undefined.

This might lead to a surprise when trying to add a background on top of what you have on the body element – when you add a background property to the HTML element everything will shift. You can observe this in most browsers on the links below.

Before:

html {}
body {background:#fcc;}

After:

html {background:#ccf;}
body {background:#fcc;}

It seems you really have to add a semantically meaningless element…

Blogstorming X-UA-Compatible

Monday, January 28th, 2008

I’ve been trying to ignore this issue since I doubted I could have added anything to the debate.

I understand Microsoft, I first saw Chris speak in London and met him later at Mix07 at the POSH table. I can’t say I know what’s going on in his mind but from what I gathered he has a job many of us would not even want. How do you promote standards without breaking the internet – not only stuff other people made but also pages that are made by your own software (think not only FrontPage but also SharePoint) or networks you yourself need to maintain.

What Eric did to prevent a flame war between web developers was amazing. If all the discussions around the development and progress of web related technologies were this civil we’d probably already be using HTML 5 and CSS 3.

Broken by Jeremy Keith outlines the main problem with the technique – you have to use it to disable it. Pardon my language here, but that’s plain stupid.

Or is it?

Reasoning

Microsoft does not want support calls about IE8 breaking pages and they don’t want calls about their SharePoint breaking (believe me, it will). There is no way of knowing when the new IE8 engine should be used. There’s also no way of them saying “Hey guys, change your page for it to work in IE8”, since they’d ultimately be saying “We need to roll a SharePoint update for this.” If you’re making a page for IE8 you can just add this as you make the page.

The ultimate goal

What we need to achieve is that the feature is there to be used but the default for the rendering is IE8 or more generally the latest version of the browser we’re using. To put it another way I think that IE=edge should be the default.

Possible solution #1

IE is famous for it’s yellow status bar. I know people don’t usually see this bar even when it does appear but how about using a semi reliable logic to define whether to render in IE8 or IE7 (think Date header, Generator META tag, HTML features) accompanied with a bar like this:

Page rendered with a legacy display engine. Set the display engine for this domain.

If the META header would be added it would work as described. If it wasn’t it would check a Microsoft provided and internally updated list of set page-rendering pairs (per domain?). If there’s still nothing found we enter the fuzzy logic that is biased to present the page in the latest IE8 rendering. If the fuzzy logic decides that IE7 should be used it displays the infamous yellow bar.

Possible solution #2

Let’s assume that usually pages that are “broken” are broken all over the domain. If this is enough we can use a proprietary solution for this problem. When Adobe Flash wants to make cross-domain requests it first requests a proprietary file called crossdomain.xml. Let’s say that IE8 requests a ua-compatible.xml that contains the URL patterns with corresponding IE rendering engine version. This would defy the idea that there needs to be no change to current pages but I would say that a single file for the whole domain is not too much to ask.

Summary

I know the proposed solutions might not be what we’re looking for (yes, I think I, and all other web developers, have a say in this). What I think we need to do is find other possibilities that might not have the side effects that the current one has. Microsoft might want to elaborate on what they’re looking for – we won’t question their reasons, we’ll just try to find a solutions that suits all of us. So let’s have a brain storming of blog posts (blogstorming?) and we might find the ultimate solution.

Use Array.join instead of concatenating strings?!?

Thursday, September 6th, 2007

I read this article at Usable Type and said to myself – true, true, true, true, WTF?

So I did a quick test:

  1. Concatenating 3 long strings: without ~135ms (45ms) [25ms] {33ms}, with ~220ms (120ms) [40ms] {65ms}
  2. Concatenating 12 shorter strings: without ~215ms (190ms) [85ms] {90ms}, with ~470ms (180ms) [105ms] {165ms}

The tests were done on my laptop on Windows Vista in Firefox (IE7) [Safari3] {Opera 9.2}, the function was repeated 10000 times. It seems that you’re better off without using array.join(), though it might be an option for huge joins in IE.

I wonder what sparked the idea – I’ve seen the use of arrays for string operations in Flash – string.split(old).join(new) for replacing until a proper method was available. I’ve never thought about abusing JavaScript that way…

On a side note – have you noticed that Firefox was significantly slower than others?

Update: I created a test page so you can test your browsers and post a comment

Firefox and Opera statistics are underrated

Wednesday, September 5th, 2007

While testing browser behavior regarding inline JavaScript evaluation and the back and forward buttons I found a very interesting thing. When a script is included in the HTML to execute on parsing (not on load but inline) Internet Explorer (7 on Vista tested) and Safari 3 for Windows will re-execute the script when a user returns via the back button. In my mind this is the correct behavior, since you actually visited the page twice.

The thing is that Firefox (2.0.0.6 on Vista tested) and Opera (9.20 on Vista tested) don’t agree with me. Well maybe they do and don’t live by their beliefs. What they do is nothing. You come back and no scripts are executed. Not even one request is sent to the server in Firefox.

This “feature” is sometimes a great thing – all the AJAXy stuff and all the JavaScript enhancements are already there and don’t need to be rendered again in turn saving power and time. At other times it’s a pain in the a** since some stuff does return to its default state and some doesn’t. This problem is most often observed with dynamic/advance forms that lose their default values/states. Since even onload is not fired this can get annoying…

Besides all the interface problems you might encounter due to this “rogue” behavior, there are also a few issues regarding statistics. It’s harder to inspect the path of a user, the time a user spent on a page, the number of page views in a visit and other related metrics. The other significant issue is that browser usage statistics might be skewed. To answer this last issue we’d have to know how these statistics are measured.

Let’s take a user that is used to clicking the back button while navigating a site with a 2 level deep navigational tree. She comes to the page, goes in one branch and then to a second, very distant branch. Internet Explorer would register 7 page views (1 on the root, 2 to get down, 2 back up and 2 more down), while Firefox would only register 5 page views (1 on the root, 2 to get down, ignore the 2 back buttons, 2 more down) – a 1.4:1 ratio.

If the statistics are based on sessions or unique users we have 50% IE and 50% FF. If we base them on hits we have 58% IE and 42% FF – a 16 percentage point difference or as we said before a 40% difference. This is not something you could just ignore…

Exercise for the reader – why do “unsupported” browsers always have a small browser share in hit based browser metrics?