Reading List
The most recent articles from a list of feeds I subscribe to.
Change URL hash without page jump
In modern complex layouts, sometimes the point where a hash will transport you to will be entirely different than the one you actually wanted. If you prevent the default event, you will save yourself from the page jump, but the hash won’t change either. You can accept the regular behavior and change scrollTop after the jump, but the user will still see a distracting flicker. Chris Coyier found a great workaround last year but it’s not meant for every case.
A different solution
Turns out we can take advantage of the History API to do that quite easily. It’s just one line of code:
history.pushState(null, null, ‘#myhash’);
and we can combine it with the old method of setting location.hash to cater for older browsers as well:
if(history.pushState) { history.pushState(null, null, ‘#myhash’); } else { location.hash = ‘#myhash’; }
Browser support?
The History API is supported by:
- Firefox 4+
- Safari 5+
- Chrome 8+
- Coming soon in Opera
Enjoy :)
StronglyTyped: A library for strongly typed properties & constants in JavaScript
I’ll start by saying I love the loosely typed nature of JavaScript. When I had to work with strongly typed languages like Java, it always seemed like an unnecessary hassle. On the contrary, my boyfriend even though very proficient with HTML, CSS and SVG, comes from a strong Java background and hates loosely typed scripting languages. So, to tempt him into JS and keep him away from heavy abstractions like Objective-J, I wrote a little library that allows you to specify strongly typed properties (and since global variables are also properties of the window object, those as well) of various types (real JS types like Boolean, Number, String etc or even made up ones like Integer) and constants (final properties in Java). It uses ES5 getters and setters to do that and falls back to regular, loosely typed properties in non-supporting browsers.
Also, as a bonus, you get cross-browser Function.prototype.bind and Array.prototype.forEach and a robust type checking function: StronglyTyped.is(type, value).
Example: Strongly typed properties
You define strongly typed properties by using the corresponding methods of the StronglyTyped object. For example, the following snippet defines a boolean property called “foo” on an object literal:
var o = {};
StronglyTyped.boolean(o, ‘foo’, true);
console.log(o.foo); // prints true
o.foo = false; console.log(o.foo); // prints false
o.foo = ‘bar’; // TypeError: foo must be of type Boolean. bar is not.
Example: Constants
You define constants by using the constant method of the StronglyTyped object. For example, the following snippet defines a global MAGIC_NUMBER constant:
var o = {};
StronglyTyped.constant(window, ‘MAGIC_NUMBER’, 3.1415926535);
console.log(MAGIC_NUMBER); // prints 3.1415926535
MAGIC_NUMBER = 4; console.log(MAGIC_NUMBER); // prints 3.1415926535
Please note that constants only become read-only after they first get a non-undefined value. For example:
StronglyTyped.constant(window, ‘MAGIC_NUMBER’);
console.log(MAGIC_NUMBER); // prints undefined
MAGIC_NUMBER = undefined;
console.log(MAGIC_NUMBER); // prints undefined
MAGIC_NUMBER = 3.1415926535; console.log(MAGIC_NUMBER); // prints 3.1415926535
MAGIC_NUMBER = 4; console.log(MAGIC_NUMBER); // prints 3.1415926535
Supported types
The property types currently supported by StronglyTyped are:
- Array
- Boolean
- Date
- Function
- Integer
- Number
- RegExp
- String
null and undefined are valid in every type. NaN and Infinity values are accepted in both the Number and the Integer types.
If you want to use a type that’s not among the above but either is native to the browser (for example Element) or a global object, you can use the generic method StronglyTyped.property(type, object, property [, initialValue]):
var o = {};
StronglyTyped.property(‘Element’, o, ‘foo’, document.body);
console.log(o.foo); // prints a representation of the <body> element
o.foo = document.head;
console.log(o.foo); // prints a representation of the <head> element
o.foo = 5; // TypeError: foo must be of type Element. 5 is not.
Browser support
It should work on every browser that supports Object.defineProperty or __defineGetter__ and __defineSetter__. As you can see from kangax’s awesome compatibility tables for Object.defineProperty and __define(G|S)etter__, those are:
- Firefox 3.5+
- IE8 (only on DOM elements)
- IE9+
- Opera 10.5+
- Chrome 5+
- Safari 4+
- Konqueror 4.4+
However, it’s only verified to work in:
- Firefox 4 (Win and OSX)
- IE9+
- Opera 11.10 for OSX, Opera 11 for Windows
- Chrome (Win and OSX)
- Safari 5 (Win and OSX)
This doesn’t mean it won’t work in the rest, just that it hasn’t been tested there (yet). You can load the unit tests (sort of…) in a browser you want to test and let me know about the results. :)
Naice! Can I haz?
As usual, you can get it from Github: Github repo
Credits
Thanks a lot to Max (@suprMax) for Windows testing!
StronglyTyped: A library for strongly typed properties & constants in JavaScript
I’ll start by saying I love the loosely typed nature of JavaScript. When I had to work with strongly typed languages like Java, it always seemed like an unnecessary hassle. On the contrary, my boyfriend even though very proficient with HTML, CSS and SVG, comes from a strong Java background and hates loosely typed scripting languages. So, to tempt him into JS and keep him away from heavy abstractions like Objective-J, I wrote a little library that allows you to specify strongly typed properties (and since global variables are also properties of the window object, those as well) of various types (real JS types like Boolean, Number, String etc or even made up ones like Integer) and constants (final properties in Java). It uses ES5 getters and setters to do that and falls back to regular, loosely typed properties in non-supporting browsers.
Also, as a bonus, you get cross-browser Function.prototype.bind and Array.prototype.forEach and a robust type checking function: StronglyTyped.is(type, value).
Example: Strongly typed properties
You define strongly typed properties by using the corresponding methods of the StronglyTyped object. For example, the following snippet defines a boolean property called “foo” on an object literal:
var o = {};
StronglyTyped.boolean(o, ‘foo’, true);
console.log(o.foo); // prints true
o.foo = false; console.log(o.foo); // prints false
o.foo = ‘bar’; // TypeError: foo must be of type Boolean. bar is not.
Example: Constants
You define constants by using the constant method of the StronglyTyped object. For example, the following snippet defines a global MAGIC_NUMBER constant:
var o = {};
StronglyTyped.constant(window, ‘MAGIC_NUMBER’, 3.1415926535);
console.log(MAGIC_NUMBER); // prints 3.1415926535
MAGIC_NUMBER = 4; console.log(MAGIC_NUMBER); // prints 3.1415926535
Please note that constants only become read-only after they first get a non-undefined value. For example:
StronglyTyped.constant(window, ‘MAGIC_NUMBER’);
console.log(MAGIC_NUMBER); // prints undefined
MAGIC_NUMBER = undefined;
console.log(MAGIC_NUMBER); // prints undefined
MAGIC_NUMBER = 3.1415926535; console.log(MAGIC_NUMBER); // prints 3.1415926535
MAGIC_NUMBER = 4; console.log(MAGIC_NUMBER); // prints 3.1415926535
Supported types
The property types currently supported by StronglyTyped are:
- Array
- Boolean
- Date
- Function
- Integer
- Number
- RegExp
- String
null and undefined are valid in every type. NaN and Infinity values are accepted in both the Number and the Integer types.
If you want to use a type that’s not among the above but either is native to the browser (for example Element) or a global object, you can use the generic method StronglyTyped.property(type, object, property [, initialValue]):
var o = {};
StronglyTyped.property(‘Element’, o, ‘foo’, document.body);
console.log(o.foo); // prints a representation of the <body> element
o.foo = document.head;
console.log(o.foo); // prints a representation of the <head> element
o.foo = 5; // TypeError: foo must be of type Element. 5 is not.
Browser support
It should work on every browser that supports Object.defineProperty or __defineGetter__ and __defineSetter__. As you can see from kangax’s awesome compatibility tables for Object.defineProperty and __define(G|S)etter__, those are:
- Firefox 3.5+
- IE8 (only on DOM elements)
- IE9+
- Opera 10.5+
- Chrome 5+
- Safari 4+
- Konqueror 4.4+
However, it’s only verified to work in:
- Firefox 4 (Win and OSX)
- IE9+
- Opera 11.10 for OSX, Opera 11 for Windows
- Chrome (Win and OSX)
- Safari 5 (Win and OSX)
This doesn’t mean it won’t work in the rest, just that it hasn’t been tested there (yet). You can load the unit tests (sort of…) in a browser you want to test and let me know about the results. :)
Naice! Can I haz?
As usual, you can get it from Github: Github repo
Credits
Thanks a lot to Max (@suprMax) for Windows testing!
Rule filtering based on specific selector(s) support
I’ve been using this trick for quite a while, but I never thought to blog about it. However, I recently realized that it might not be as common as I thought, so it might be a good idea to document it in a blog post.
If you follow the discussions on www-style, you might have noticed the proposal for a @supports rule to query property and value support. Some people suggested that it should also test for selectors, for example whether a certain pseudo-class is supported. However, you can do that today, albeit in a limited manner (no OR and NOT support).
The main principle that you need to keep in mind is that browsers are expected to drop rules with selectors they don’t understand, even partially. So, if only one selector in a group cannot be parsed, the whole rule will be dropped. This means we can construct selector “tests”, which are use cases of the selector whose support we want to test, that will not match anything, even if the selector is supported. Then, we include that selector in the beginning of our selector group. If all this is unclear, don’t worry, as there’s an example coming next :)
Example
Suppose you want to apply the following CSS (for rudimentary custom checkboxes):
input[type=“checkbox”] { position:absolute; clip: rect(0,0,0,0); clip: rect(0 0 0 0); }
input[type=“checkbox”] + label::before { content: url(‘checkbox.png’); }
input[type=“checkbox”]:checked + label::before { content: url(‘checkbox-checked.png’); }
only in browsers that support the attribute equality selector, the :checked pseudo-class and the ::before pseudo-element. We need to try to think of a selector that includes all of them but matches nothing. One such selector would be #foo[type="checkbox"]:checked::before. Even in supporting browsers, this matches nothing as there’s no element with id=“foo”. We can reduce the test for every rule to conserve bandwidth: For example, we don’t need to include tests for the attribute selector in any of them, since they are present anyway in all three rules. Also, we may eliminate ::before from the second test and we don’t need any test for the 3rd one, since it includes all features we want to test for. To sum up:
#foo:checked::before, input[type=“checkbox”] { position:absolute; clip: rect(0,0,0,0); clip: rect(0 0 0 0); }
#foo:checked, input[type=“checkbox”] + label::before { content: url(‘checkbox.png’); }
input[type=“checkbox”]:checked + label::before { content: url(‘checkbox-checked.png’); }
An important caveat of this technique is that Internet Explorer up to version 7 will split selectors before parsing them, so it will completely ignore our filters :( (Thanks to Ryan Seddon for finding that out).
Disclaimer: The original idea about custom checkboxes belongs to Ryan Seddon, although his code was quite different.
Rule filtering based on specific selector(s) support
I’ve been using this trick for quite a while, but I never thought to blog about it. However, I recently realized that it might not be as common as I thought, so it might be a good idea to document it in a blog post.
If you follow the discussions on www-style, you might have noticed the proposal for a @supports rule to query property and value support. Some people suggested that it should also test for selectors, for example whether a certain pseudo-class is supported. However, you can do that today, albeit in a limited manner (no OR and NOT support).
The main principle that you need to keep in mind is that browsers are expected to drop rules with selectors they don’t understand, even partially. So, if only one selector in a group cannot be parsed, the whole rule will be dropped. This means we can construct selector “tests”, which are use cases of the selector whose support we want to test, that will not match anything, even if the selector is supported. Then, we include that selector in the beginning of our selector group. If all this is unclear, don’t worry, as there’s an example coming next :)
Example
Suppose you want to apply the following CSS (for rudimentary custom checkboxes):
input[type=“checkbox”] { position:absolute; clip: rect(0,0,0,0); clip: rect(0 0 0 0); }
input[type=“checkbox”] + label::before { content: url(‘checkbox.png’); }
input[type=“checkbox”]:checked + label::before { content: url(‘checkbox-checked.png’); }
only in browsers that support the attribute equality selector, the :checked pseudo-class and the ::before pseudo-element. We need to try to think of a selector that includes all of them but matches nothing. One such selector would be #foo[type="checkbox"]:checked::before. Even in supporting browsers, this matches nothing as there’s no element with id=“foo”. We can reduce the test for every rule to conserve bandwidth: For example, we don’t need to include tests for the attribute selector in any of them, since they are present anyway in all three rules. Also, we may eliminate ::before from the second test and we don’t need any test for the 3rd one, since it includes all features we want to test for. To sum up:
#foo:checked::before, input[type=“checkbox”] { position:absolute; clip: rect(0,0,0,0); clip: rect(0 0 0 0); }
#foo:checked, input[type=“checkbox”] + label::before { content: url(‘checkbox.png’); }
input[type=“checkbox”]:checked + label::before { content: url(‘checkbox-checked.png’); }
An important caveat of this technique is that Internet Explorer up to version 7 will split selectors before parsing them, so it will completely ignore our filters :( (Thanks to Ryan Seddon for finding that out).
Disclaimer: The original idea about custom checkboxes belongs to Ryan Seddon, although his code was quite different.