Cross-Origin Resource Sharing (CORS) Header

Crossdomain access can be enabled in JavaScript with a mechanism similar to that in Flash. Instead of hosting a crossdomain.xml file though, crossdomain access is enabled per file, through an additional HTTP response header:

Access-Control-Allow-Origin: *

CORS is a more modern equivalent to JSONP for cross-domain XmlHttpRequests(AJAX) with options to limit domains, subdomains and ports.

Initial browser support:

  • Firefox 3.5
  • Chrome 4
  • Safari 3.2
  • MSIE 8

REFERENCES:

crossdomain.xml

Adobe FlashPlayer 7 added several security features. I first became aware of this one as I saw a large number of HTTP 404 errors for a file named ‘crossdomain.xml’ in my webserver logs. (see also clientaccesspolicy.xml)

If you use flash on your website, I’d suggest adding an appropriate copy of this file to limit your exposure to some potential security issues.

Restricted domains

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.example.com" />
<allow-access-from domain="example.com" />
</cross-domain-policy>

Open to all domains (not recommended, but fully backward compatible)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>

REFERENCES:

Google Web Fonts

The use of non-traditional web fonts was once a very challenging task due to various browser specific implementations. Thankfully Google WebFonts have made this easy enough for most developers to add in a cross-browser manner in a matter of minutes.

WARNING, there are a few considerations to make here…

  1. Some browsers displays a blank space in place of the text that uses the font.
  2. … and then re-render text in the web font once it has loaded

Method 1: (most compatible, but cross-browser loading behavior varies)

<link href='http://fonts.googleapis.com/css?family=Ubuntu:400,700' rel='stylesheet' type='text/css' />
<style type="text/css">
h1,p { font-family: 'Ubuntu', sans-serif; }
</style>

Method 2: (requires javascript, but is consistent cross-browser)

<script type="text/javascript">
WebFontConfig = {
google: { families: [ 'Ubuntu Mono','Ubuntu' ] }
};
(function() {
var wf = document.createElement('script');
wf.src = ('https:' == document.location.protocol ? 'https' : 'http') + '://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
wf.type = 'text/javascript';
wf.async = 'true';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(wf, s);
})();
</script>
<style type="text/css">
h1 { font-family: 'Ubuntu Mono','Courier New',monospace; }
p { font-family: 'Ubuntu','sans-serif'; }
</style>

JavaScript “use strict”

ECMAScript 5 added Strict Mode to JavaScript. Many of you may have first seen mention of this if you’ve used JSLint. It helps to remember that JavaScript still behaves much like an interpreted vs. compiled language as each browser/parser makes assumptions to execute code faster in different manners.

There are four primary features/goals of strict mode:

  • Throws errors for some common coding issues, that are sometimes obscure but previously didn’t throw an error.
  • Prevents or throws errors for potentially “unsafe” actions (such as gaining access to the global object).
  • Disables functions that are confusing or poorly thought out
  • Potentially code in strict mode could run faster by eliminating mistakes that would make it difficult for JavaScript engines to perform optimizations

Initial support added in FireFox 4 and MSIE10:

WARNING: if you chose to do this at a ‘file’ level, be sure to never concatenate several files together that are not ALL strict.

JS File Example:
"use strict";
function testFunction(){
var testvar = 1;
return testvar;
}

// This causes a syntax error.
testvar = 2;

JS Function Example:
function testFunction(){
"use strict";
// This causes a syntax error.
testvar = 1;
return testvar;
}
testvar = 2;

REFERENCES:

Free website uptime monitoring

Regardless if you host your own websites, or pay to have them hosted elsewhere, up-time, availability and network performance metrics are important to your visiting guests.

Here are two free services that I’ve found useful for monitoring, notification and reporting.

BTW, you can even use these to watch competitors or sites that you frequent.

MSIE iframe frameBorder=”0″ attribute is case sensitive?

No, you are not going crazy… MSIE 6 and 7 are case sensitive for the ‘frameBorder‘ (and a few other attributes).
It seems that the JavaScript attribute names are expected to be used in the HTML, should you expect them to behave and look properly you’ll have to make some small changes to support, this is even more important when using JavaScript to update or change attributes.

<iframe... frameBorder="0"></iframe>

Browser performance impact of charset/codepage assignment

Most developers (myself included) are often unaware of the performance impact of the Content-Type / charset of a web page. Ideally you should set this as an HTTP Header vs. using META http-equiv. It’s often though that this only helps with the transport and display of data, however, the browser also makes use of it when parsing CSS & JS assets. Tags related to those provide an optional ‘charset‘ attribute should they ever need to vary from your content.

General guidance is to set this at the very top of the <head> before <title>; and within the first 1024 bytes, though there are reports that Firefox will look at the first 2048 bytes of the page for this META information.

Not doing so may cause the browser to do a codepage restart to re-parse assets that were interpreted in the potentially incorrect codepage.

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

REFERENCES:

Conditional Comments cause CSS to block

Here’s an odd one…. I’ve found that if you use the common method of using Conditional Comments to separate MSIE specific CSS, you’ve likely added a performance problem without knowing it… that is, in addition to the network connection and time required for the different CSS files.

It turns out that the standard use of this approach blocks the other downloads until the main CSS is loaded.

The solution is both simple and painless to implement…. a quick solution to this is to add an empty conditional comment early on, that is, before the main content (CSS) is loaded.. This works for all approaches, such as those where comments surround the <body> or various <link>, <style> or <script> tags.

UPDATE:
Personally, I like to do this immediately after the DOCTYPE and before the <html> tag. Additionally, since IE10 dropped support for this technique, I’ll just target IE 9 and below for any developer that comes after me.


<!DOCTYPE html>
<!--[if lte IE 9]><![endif]-->
<html lang="en">
...

REFERENCES: