Jonathan Weiß

Golo asked me some time ago how to retrieve the actual style property value of an element. It is easy to get the value applied by the element's style attribute or the CSS class name. But the actual value is affected by many CSS rules which are applied to the element: element type, element's parents, class name(s) and style attribute (which can, of course, be modified by JavaScript through runtime).

An example of different CSS rules overwriting each other.

Luckily we do not have to worry about this — it is the browser's job to apply all rules correctly. There are two ways of retrieving the actual style information. Those on the dark side use element.currentStyle[style property] to get the actual property value. All others use the WC3 method window.getComputedStyle() to get a CSSStyleDecoration object which can be accesed via getPropertyValue(style property).

Note, that the proprietary currentStyle() method has the same syntax as in your CSS files (e.g. background-color) while W3C DOM method uses the syntax you know from JavaScript (e.g. backgroundColor).

I guess you have seen this little warning way too often, while surfing with the Internet Explorer:

In the majority of cases you are on an encrypted website when some resources (e.g. images, CSS files or iframes (mostly filled with advertisements)) are being loaded over the normal, not encrypted, HTTP protocol. Naturally, such issues are easy to find and resolve: just take the better browser Firefox, right click the page, look at the Page Info, browse through the list in the Media tab and search for an address which does not start with https.

Another possibility is that some content can not be found on the server and Internet Explorer wants to display its own 404 page. If this happens, the browser will try to display a special page from its resources. Unfortunately this page will be rated insecure, because it does not come via HTTPS protocol, but from the browser itself.
You can try to avoid this by building a 404 error page. But even this can fail if the page size is too small for Internet Explorer.

Today I spent some time until I found third reason for this box to appear. I searched for not encrypted requests and watched out for missing files with Fiddler, but I found nothing. After a while I found an hidden frame locating to about:blank. This location, as well as the "file not found" event, leads Internet Explorer to display content from its chrome.
Funnily, this browser does not trust its own content and will bring up a warning.

So, if you have users with old versions of Internet Explorer, be sure not to use about:blank, the rhomb # or empty values for objects like images, iframes or others on SSL encrypted sites.

Update:
Today (04.09.2007) I found another example of Internet Explorer's paranoia: before navigating from an unsecure location to a web page in the Trusted sites list you have to confirm a dialog. The point is, that the current location is a page from the browser's own resources! If this page is fiddled every security check is dispensable...

Yesterday, at the Worldwide Developers Conference and exactly in time for the birthday party of this project Apple introduced the new version of Safari. The interesting fact is that they have made a version for Microsoft Windows, so that I do not have to torment the old Mac mini with upgrading the operating system etc.

My first impression is: wow, this thing is fast! It runs my applications in development and all test cases or prototypes at a similar speed as Firefox. Positioning elements is done faster in Firefox, but setting other attributes seems to faster in Safari. I have run some benchmarks to get a better impression of this.
In the past I had some problems running some test cases in Safari on OS X, which stopped on JavaScript errors which were difficult to debug in Safari. So, it is amazing that everything runs in Safari now.
I have to figure out how to enable Drosera on Safari for Windows to really use this browser for testing.

On my machine I have a strange problem with fonts, which occurs from time to time. It looks as if some characters can not be displayed.

I'm curious about Ben's report on the WWDC 2007. Be shure to read his blog in the next days. ;-)

Update:
Thank you daeg for informing us how to enable the debug menu on Windows machines in your comment on the Slashdot article Safari on Windows.