Impressive Webs

Using tabindex with :focus

Louis Lazaris — Tue, 23 Apr 2013 22:38:52 +0000

For those who have studied web site accessibility, this is probably old hat. Admittedly, I haven’t spent enough time thinking about accessibility, so this is one of those things I didn’t even realize until recently. So shame on me. :)

Let’s say you have the following page, with various elements, starting with maybe a form field:

Check out this Pen!

If you start with keyboard focus on the search input, then use the tab key to cycle through the elements, you’ll notice that the “focus” of the cursor goes from search field, to “Dummy link 1” (skipping the heading and paragraphs), to “Dummy link 2”, etc. To make it clear what’s focused, I’ve added a background color using the :focus pseudo-class.

Okay, simple enough. But what if you want to cycle through all the elements on the page? Easy, you just add tabindex attributes in the HTML to any element you want to receive focus:

Check out this Pen!

Now when you cycle through the elements with the tab key, all the elements receive focus, including all the paragraphs, with the background color added for each.

But notice another thing that happens: Any of those elements will receive focus styles even if you click on them with the mouse.

This means you can do something like the following demo. This is as a pure CSS game called “Find the Kitten”:

Check out this Pen!

This uses the same technique as the previous demo, changing styles on focus, but with the tabindex values added to all the elements, the boxes are clickable.

With a little more creativity, and combining this with other new CSS features, this could make for some interesting effects.

Accessibility Concerns?

I should stress that the techniques I’m using here are experimental and you should do some research on tabindex and :focus before you go crazy adding all sorts of elements on your pages that change styles when clicked/focused.

Again, this concept is probably not new to most experienced developers who have studied accessibility, but I thought it was interesting enough to write about.

Fixing Backspace Back Button Functionality When Using Autofocus

Louis Lazaris — Tue, 02 Apr 2013 10:27:13 +0000

Let’s say you’re viewing different pages in your browser, and in the midst of your browsing you decide to visit Google’s home page. So you see this:

Notice the blinking cursor. This means the cursor has been automatically focused into the search field, either via JavaScript or using HTML5′s autofocus attribute.

If you happen to change your mind about typing a search, and you want to go “back”, you can do one of two things. You can (1) use the back button in the browser, or (2) you can use the backspace key on your keyboard (on a Mac it’s the “delete” key).

If you decide to use the keyboard method, your experience will be broken, because when you’re inside a text field, the “backspace” key means “delete text”. So the browser will not go back in its history, as you would expect. And naturally, shift-backspace (which is forward in history) would likewise fail.

Personally, I’ve always found this annoying, and I’m glad a person with a disability mentioned it, because I decided to try to create a simple fix for this problem using JavaScript:

var input = document.getElementById('field'),
    key;

input.onkeydown = function(e) {

  if (!input.value) {

    key = e.keyCode || e.charCode;

    if (key === 8 || key === 46) {

      if (!e.shiftKey) {
        history.back();
      } else {
        history.forward();
      }

    }

  }
 };Check out this Pen!

The script does the following:

Look for keystrokes in the text field
Make sure the field is empty after the keystroke
Check if the key pressed is the backspace (8) or delete key (46)
If it is, check if the shift key is being pushed
Go back or forward in the browser history

The script seems to work in every browser except IE8. And oddly, although I’ve added the ability to use shift-backspace (shift-delete on Mac) to go forward in browser history, IE10 doesn’t seem to recognize this shortcut like previous versions of IE seemed to do (if I remember correctly).

Flaws

Besides the IE flaws just mentioned, one of the flaws in this script is the fact that the keystroke that it looks for can be either backspace or delete (which ensures it works on PC and Mac). So the result of this is that if you push “delete” on a PC keyboard (which is a different button than “backspace”), it too will cause the history-back functionality to occur. But I don’t think that’s such a big deal, really.

Finally, the other flaw in this is that if someone deletes what they were typing in the search box and they hit backspace/delete one too many times, it will cause the history-back fuctionality to trigger. I started to try to figure out how to cancel the event once the user begins to type actual visible text, but couldn’t figure out how to do it. Maybe someone can fork the CodePen and add that to it.

The demo seems to work fine on CodePen, but because because CodePen embeds the full-page view in an iframe, it seems a little unnatural, so I’ve provided a bare-bones demo to test instead, using the button below.

And obviously, if you click the demo button below, stay in the same tab, so you’ll have something to go “back” to.

View Demo

Quick Tip: Use HTML Comments to Indicate Pseudo-elements

Louis Lazaris — Tue, 26 Mar 2013 10:00:52 +0000

At the recent W3Conf Nicolas Gallagher explained that although pseudo-elements have helped us add decorative content to our pages while keeping our HTML clean, this has led to some maintainability issues.

Developer tools can help to some degree, but oftentimes dynamically added content like pseudo-elements or extra elements added via JavaScript are initially harder to track down.

As Nicolas pointed out, the far-future improvement in this area is the Web Components spec, but I think this is something we can improve on right now.

Let’s say we have the following CSS, using pseudo-elements:

.exampleModule {
  float: left;
  border: solid 2px #ccc;
  position: relative;
}

.exampleModule:before {
  content: url(icon.png);
  float: left;
}

.exampleModule:after {
  content: url(corner.png);
  position: absolute;
  bottom: 0;
  right: 0;
}

The CSS is just illustrative, and really doesn’t matter for this example; it could be anything that uses one or more pseudo-elements. The main takeaway here is what you would see in the HTML:



content...

Now you don’t have to view the CSS or inspect the element with your dev tools; as soon as you look at the HTML, you know that the decorative content (in this case the two images) is added via pseudo-elements.

The same principle can be applied to content that is injected via JavaScript, and I suppose you could also include HTML comments in modules to list the different states that the module could be in, as represented by classes in the CSS. But that’s a little more complicated, and could probably be a topic for another post.

thatsNotYoChild.js — Fixing Parent-Child Opacity

Louis Lazaris — Tue, 19 Mar 2013 23:08:51 +0000

One of the posts on this website that consistently gets a significant amount of traffic (5000+ page views this month alone) is a ridiculous article I wrote that discusses how to make a child element not inherit the opacity setting of its parent.

As we all know, CSS transparency that uses the opacity property can be annoying in this area.

Basically, if a parent element has an opacity value set at, say, 0.5, all of its children will inherit that opacity setting, and there’s no way to reverse that opacity on the child elements.

That post I wrote discussed a hacky workaround where you actually remove the element from its parent, position it absolutely, then move it so it still appears in the same place it did when it was a child.

If you know anything about CSS positioning, then you know why this is not a great solution.

Nonetheless, I still get lots of traffic coming to that article not only from Google searches, but also from various Stack Overflow threads that link to it.

So I decided to write a script that fixes this issue. But first, let’s settle a few things.

The Best Way to Resolve This Issue

I’m guessing that in more than 90% of cases, this is pretty much a non-issue. If you need transparency on a parent element, you can do it using a few different methods that avoid this parent-child opacity issue:

If it’s only a background color on the parent, use RGBA or HSLA
If it’s a background image, use a transparent PNG
If you’re just desiring a “washed out” look for a color or background image or pattern, do it in your image editor, or sample the washed-out color you want and insert it with Hex or RGB in your CSS

But hey, it’s fun to write polyfills and workarounds for these types of problems, and it does seem like this sort of thing is in demand, even if most developers are approaching the problem in the wrong way to begin with.

Introducing thatsNotYoChild.js

I realized that the workaround to get the child elements out of their parent and repositioned is not that crazy. So I wrote a script that does this exact thing automatically, but it’s much more effective than that original solution.

Here’s an embedded pen demonstrating thatsNotYoChild.js in action:

Check out this Pen!

Go ahead, change the markup to anything you want inside the #parent element; it should work for anything you put in there.

You can view the code in the embedded CodePen, and here’s a step by step description of what it does:

Grab all child elements of the element that has the opacity setting, wrap them in a
Use cloneNode to clone the newly-wrapped child group
Place the new clone outside the parent element
Change the ID of the original group
Set the opacity of the original group to 0 (you can reduce the opacity of the children but you can’t raise it)
Use getBoundingRect() (which works everywhere that’s relevant) to find the exact position and width of the original child group
Use element.style to absolutely position and size the clone group using the values obtained from getBoundingRect()
Use window.onresize to run the previous two steps every time the window is resized.

Compared to the old article I wrote that fixed this issue with a CSS-only solution, this solution has a few advantages. First, although the child elements are absolutely positioned, taking them out of the normal flow, the space the child elements occupy is still occupied by the original child group, which isn’t visible due to having its opacity set to 0. The cloned group overlays the same space, making it appear as if it never moves, and the other elements on the page don’t reposition themselves since they are subject to the positioning of the original, now invisible, child group.

The other advantage is that this solution doesn’t require any changes to the markup, whereas that other CSS-only solution required that you change the markup.

To use the script, just call the function like this, passing in the ID of the parent element that has opacity set:

thatsNotYoChild('parent');

Feedback?

I don’t know too much about the different DOM methods I used in this script. I’m guessing for example that window.onresize is not great for performance and repaints.

This was, more or less, a fun little hacky script that’s not too heavy so maybe someone will find it useful, assuming there are no major performance issues with it.

If you have any feedback on improvements to the code, or see any potential bugs or drawbacks, feel free to comment and/or fork it.

View Demo

My Talk and Slides from jQueryTO

Louis Lazaris — Thu, 14 Mar 2013 10:00:37 +0000

On March 2nd and 3rd, I attended and had the privilege of speaking at jQueryTO, Canada’s first ever jQuery conference. It was a really cool experience, and was especially cool because I finally got to meet in person certain developers that I’ve respected from afar for some time, including Darcy Clarke (who organized it), Paul Irish, Addy Osmani, Alex Sexton, and Adam J. Sontag.

If you’ve been reading this blog for awhile now, then you know that I have little, if any, business speaking at a JavaScript conference. So I tried to keep things fairly simple for myself and proposed a talk where I could focus largely on CSS.

The conference didn’t have any official recording going on, thus any footage of the talks is rare and not great quality. So for archival purposes, I’ve recorded my own talk with slides as a screencast, embedded below. I did the screencast from memory, and my actual talk probably went a lot smoother than this screencast, so forgive some of the stutter-filled moments in this one. :)

A lot of what’s in this talk is stuff I’ve blogged about here and elsewhere, meaning it’s nothing ground-breaking for most of my readers. But it was a nice way to get my feet wet in the conference speaking arena.

In addition to the screencast, I’ve also embedded the slides from Speaker Deck and included all the links referenced in the slides.

These links start after the intro where I briefly cover who I am, etc:

Links from the start of the presentation (“Who is This Guy?”):

Image credits:

If you want footage, slides, or notes from any of the other talks:

jQueryTO 2013 Speaker Notes
jQueryTO Notes Index

Here’s a photo of the t-shirt every attendee got, along with some promotional stuff:

Finally, for more links to slides and notes from the conference, Scott Vinkle has put a list together. Enjoy.

Modular CSS with Media Queries and Sass

Louis Lazaris — Tue, 12 Mar 2013 10:00:44 +0000

Most developers nowadays are recognizing that if you’re developing large applications that have different views and states, it is best to take a modular or object-oriented approach to your CSS development.

When you throw media queries into the mix, however, the you can lose some of the benefits of modularity — code that’s easy to read, update, and maintain.

Let’s look at different ways we can write our media queries, starting with what might be the most common approach — especially with those not yet using a preprocessor.

The Common Approach

To demonstrate what I think the majority of developers have done with media queries up to this point, here’s a simple example:

.box-module {
  float: left;
  background: #ccc;
  margin-bottom: 1.2em;
}

.some-other-module {
  border: solid 4px #222;
  padding: 1.2em;
  margin-bottom: 1.2em;
}

/* ... other non-media query styles would go here ... */

@media screen and (max-width: 720px) {
  .box-module {
    float: none;
    clear: both;
    margin-bottom: .5em;
  }

  .some-other-module {
    border: solid 2px #222;
    padding: .8em;
    margin-bottom: .5em;
  }
}

@media screen and (max-width: 320px) {
  .box-module {
    margin-bottom: .2em;
  }

  .some-other-module {
    padding: .2em;
    margin-bottom: .2em;
  }
}

/* ... other media query styles would go here ... */

In the first two rule sets in this example, we have two separate elements on the page styled without media queries. (As a side point, those first two rule sets could be our mobile first styles, but it really doesn’t matter for the purpose of this theoretical example.)

After we declare those primary styles on our two elements, we then declare our media queries, repeating the same selectors, but with altered styles to suit the media features defined in the media queries.

The key part to take note of here is how this would look if we had thousands of lines of code. If that were the case, the media query styles that apply to the same modules would be significantly separated from the original styles for those same elements. Not ideal, especially when you’re trying to keep related chunks of CSS together.

A More Modular Approach

The purpose of modularizing our CSS is to help it become much more flexible and scalable, but also to help make it easier to read and easier to maintain. As we can see from the previous example, that approach (where you throw all your media queries at the bottom of the stylesheet) can, to some extent, hinder maintainability.

Let’s rewrite the example from above using a more modular approach:

.box-module {
  float: left;
  background: #ccc;
  margin-bottom: 1.2em;
}

@media screen and (max-width: 720px) {
  .box-module {
    float: none;
    clear: both;
    margin-bottom: .5em;
  }
}

@media screen and (max-width: 320px) {
  .box-module {
    margin-bottom: .2em;
  }
}

.some-other-module {
  border: solid 4px #222;
  padding: 1.2em;
  margin-bottom: 1.2em;
}

@media screen and (max-width: 720px) {
  .some-other-module {
    border: solid 2px #222;
    padding: .8em;
    margin-bottom: .5em;
  }
}

@media screen and (max-width: 320px) {
  .some-other-module {
    padding: .2em;
    margin-bottom: .2em;
  }
}

This might seem a bit odd and counterproductive to those who are accustomed to putting their media queries at the bottom of their CSS file. This approach is discussed as an option in Jonathan Snook’s book on modular CSS, where he discusses changing state with media queries.

Even before I started reading Jonathan’s book, I’ve considered this approach, but pretty much immediately discarded the thought for probably the same reason that many of you are cringing at it right now: The fact that this clearly goes against the DRY (Don’t Repeat Yourself) principle.

Pros and Cons

As we’ll see in the following sections, if you’re using Sass, the repetition becomes less of a factor and, from what I can tell, many developers are adopting this method.

But first, let’s consider the pros and cons of this approach for pure CSS that’s not using Sass.

Cons:

Lots of repetition, which modular CSS discourages
More code, which could amount to hundreds of extra lines, thus larger files
Could be confusing to future maintainers, especially if not well documented
If you change a single media query state (e.g. “max-width: 720px”), you have to change it for all modules

Pros:

Easier to read/understand/maintain for the original developer(s)
Could be much easier to read/understand for future maintainers, especially if well documented
Easier to write the initial code (more on this below)

Resolving Some of the Cons

To purists, the cons may seem like big problems. But I don’t think they’re as big as they seem, even though they may appear to outweigh the pros.

First, I’m not concerned about the larger amount of code. If I’m minifying and gzip’ing, the difference in code quantity will be negligible.

Second, as suggested by the final “pro” point, if you’re writing your media query for a module right next to the initial styles for the module itself, I believe this will make it significantly easier when debugging that particular part of the code. Since you have all the different styles for a particular module together — including all the different state changes via media queries — you’ll quickly be able to make any changes and won’t have to put off debugging the same module again at smaller breakpoints.

Modular Media Queries with Sass

When you factor in a preprocessor like Sass, this sort of thing becomes exponentially easier. If you’re not familiar with some of Sass’s media query-specific capabilities, it’s worth checking out that part of their documentation, which talks about doing this exact thing.

So let’s rewrite our example from above using Sass with nesting and variables:

$media: screen;
$feature: max-width;
$value: 720px;
$value2: 320px;

.box-module {
  float: left;
  background: #ccc;
  margin-bottom: 1.2em;

  @media #{$media} and ($feature: $value) {
    float: none;
    clear: both;
    margin-bottom: .5em;
  }

  @media #{$media} and ($feature: $value2) {
    margin-bottom: .2em;
  }

}

.some-other-module {
  border: solid 4px #222;
  padding: 1.2em;
  margin-bottom: 1.2em;

  @media #{$media} and ($feature: $value) {
    border: solid 2px #222;
    padding: .8em;
    margin-bottom: .5em;
  }

  @media #{$media} and ($feature: $value2) {
    padding: .2em;
    margin-bottom: .2em;
  }

}

Here, in addition to variables, we’re using Sass’s nesting capabilities, which don’t require repeating the selector inside the media query block. This will compile to basically what we did in the Sass-less modular example above.

But we’re not finished yet. Let’s make one final improvement to this code, using a fairly new Sass feature.

Modular Media Queries Using Sass with @content

We’re going to improve on this even more by using Sass’s ability to pass content blocks to a mixin.

And I should point out that this is nothing new; the official Sass blog discussed this shortly before Sass 3.2 was released, and a few other blogs have discussed the benefits of using Sass to keep media query styles near the styles they override.

Here’s our updated code using Sass’s @content directive:

$media: screen;
$feature: max-width;
$value: 720px;
$value2: 320px;

@mixin modular-mq($breakpoint) {
  @if $breakpoint == medium {
    @media (#{$media} and $feature: $value) { @content; }
  }
  @else if $breakpoint == small {
    @media (#{$media} and $feature: $value2) { @content; }
  }
}

.box-module {
  float: left;
  background: #ccc;
  margin-bottom: 1.2em;

  @include modular-mq(medium) {
    float: none;
    clear: both;
    margin-bottom: .5em;
  }

  @include modular-mq(small) {
    margin-bottom: .2em;
  }

}

.some-other-module {
  border: solid 4px #222;
  padding: 1.2em;
  margin-bottom: 1.2em;

  @include modular-mq(medium) {
    border: solid 2px #222;
    padding: .8em;
    margin-bottom: .5em;
  }
 
  @include modular-mq(small) {
    padding: .2em;
    margin-bottom: .2em;
  }
}

The examples with the variables and whatnot are not necessarily going to be done like that. You can hardcode the values right into the mixin, or you could have some conditional logic that decides what the values will be. This is more or less a theoretical example.

Conclusion

Even with the two Sass examples, you’re still, to some extent, repeating your media query breakpoints for every selector that needs an override. So I can understand if many developers don’t like this approach.

Overall, I think the concept of keeping related styles near each other is much more in line with what we like to see in CSS and especially in modular or OOCSS. I always find it annoying when I have to sift through two different parts of a stylesheet to make a change to a single element on the page — a problem that has occurred much more often with the advent of media queries. I think this approach would resolve this type of thing.

I should also mention that there are some projects that aim to help in this area including Sassy Media, Susy, sass-mediaqueries and probably others that I haven’t yet seen. (Update: Scott Kellum tweeted to me about Breakpoint, which is worth checking out just for the Point Break movie homage.)

So how has everyone been doing this sort of thing? Do you mind having your media queries scattered throughout your code, repeating the same queries for different selectors?

When to Avoid the Descendant Selector

Louis Lazaris — Mon, 11 Feb 2013 11:00:16 +0000

Those of us who have started using modular or object-oriented CSS principles have learned to avoid, as much as possible, the use of the descendant selector (or, more accurately, the descendant combinator).

A selector that uses the descendant combinator looks like this:

.sidebar p  {
    color: hotpink;
    font-size: 3em;
}

Everything you see before the opening curly brace is the selector. The combinator in this case is the space character. There are other combinators, too. But in this case, the selector uses the descendant combinator.

Now that we have a technical understanding of the selector itself, let’s discuss what to keep in mind when deciding to use this selector.

Why is the Descendant Selector Restrictive?

To understand why the descendant selector can cause problems, look at the example I used above. Those styles are limited not only to paragraph elements, but on paragraph elements that are children of an element with a class of “sidebar”.

That’s pretty strict. This limits what you can do with those styles. You can’t reuse those styles, so they’re basically stuck in that context.

This is outlined in the OOCSS wiki, when discussing the separation of “container and content”.

Does OOCSS Discourage Use of the Descendant Selector?

This question is covered in the OOCSS FAQ. Part of the answer there reads:

No–descendant selectors are not discouraged, but putting them too high in the DOM tree is.

So the idea here is that you avoid the descendant selector where it will cause unnecessary restrictions, specifically “high in the DOM tree”. But you shouldn’t avoid it altogether (as I’m sure many of us have discovered, since it’s impractical not to use it at all).

Nicole Sullivan’s media object is a good example of an OOCSS module that uses the descendant selector abundantly, but not in a restrictive manner.

So, by all means, use the descendant combinator in your selectors. But avoid examples like the following:

.header p { }
.container div { }
.sidebar h2 { }

In these examples, which are using elements high up on the DOM tree, these styles are not reusable, so they could unnecessarily bloat your code.

No Dogma Here

These are suggestions, not dogma. I realize that not every project and circumstance is the same. So do whatever you need to do to solve your current coding problems.

If that means using some of the principles of modular CSS, then go for it. Even if you’re not too strict about these rules, I think keeping in mind the spirit behind them will make you a better CSS developer in the long run.

JavaScript ‘this’ in Different Contexts

Louis Lazaris — Tue, 29 Jan 2013 11:00:35 +0000

JavaScript has a reserved keyword called this that references something different depending on where you are in a JavaScript program.

In this post I’m going to summarize, by example, some different contexts and discuss what “this” would represent in each case. Note that all of these examples assume you’re developing client-side JavaScript in a browser.

In the Global Context

What happens if you reference this in the global context (i.e., not inside any function)?

console.log(this === window); // true

You can test this on any page in your dev tools by typing that line into the console.

As that code demonstrates, this in the global context refers to the window object. Look at the following code and the subsequent outputs:

this.message = "Check this out.";
window.message = "Check this out.";

console.log(this.message); // "Check this out."
console.log(window.message); // "Check this out."
console.log(message); // "Check this out."

You can view this code in action using this JS Bin.

So what’s going on here? The first two lines are doing the exact same thing — creating a global variable called “message” and setting its value to “Check this out.” This fact is demonstrated by the three console messages that follow, all showing the same result.

In Function Context

So what happens when you refer to this in the context of a function, or closure?

In a simple example with no futher nesting of functions, it will depend on whether you’re using strict mode:

function checkThisOut () {
  console.log(this === window); // true
  console.log(this); // object global
}

checkThisOut();

JS Bin example

As you can see, nothing’s changed from the global context (i.e. this still references the window object). Now let’s try in strict mode:

function checkThisOut () {
  "use strict";
  console.log(this === window); // false
  console.log(this); // undefined
}

checkThisOut();

JS Bin demo

If I understand correctly, as Nicholas Zakas points out, the behaviour shown in the “use strict” example is in order to prevent accidental globals. There could be more to it that I’m not fully understanding, but it seems that’s the main reason for the difference here.

In a Module Pattern

Recently I discussed the module pattern I’m currently using when writing JavaScript.

Let’s look at what this references in the context of such a pattern:

var s,
    PrimaryNameSpace = {

        settings : {
            first: true,
            second: false,
            foo: 'bar'
        },

        init: function () {
            console.log(this); // references PrimaryNameSpace
        },

        nextMethod: function () {
        },

        anotherMethod: function () {
        }

    };

PrimaryNameSpace.init();

JS Bin demo

In the module pattern context, inside any of the individual methods (that is, the functions), this will reference the entire module. In fact, if you view the console message created inside the init() method in your developer tools, you’ll see something like the following:

The console shows you an object (the namespace, or module), then you can drill down into the object to view the different methods, as well as all the values defined in the settings object.

Thus, inside the init() method, you can reference the modules and settings using this in the following manner:

/* ... other code here ...*/

        init: function () {
            s = this.settings;
            this.nextMethod();
            this.anotherMethod();
            console.log(s);            
        },

/* ... other code here ...*/

PrimaryNameSpace.init();

JS Bin demo

Using this to reference the other methods and the settings prevents us from having to write the references in long form. The following would be equivalent to what is written above:

/* ... other code here ...*/

        init: function () {
            s = PrimaryNameSpace.settings;
            PrimaryNameSpace.nextMethod();
            PrimaryNameSpace.anotherMethod();
            console.log(s);
        },

/* ... other code here ...*/

JS Bin demo

And in both cases, the console message would show:

What About a Nested Function?

If however, you have an anonymous function inside one of the methods, then the value of this changes, and the module object is no longer accessible via this. So the long form syntax would be necessary, as shown here:

/* ... other code here ...*/

        init: function () {
            s = this.settings;
            (function () {
              this.nextMethod();
              // [object Window] has no method 'nextMethod'
            })();
        },

/* ... other code here ...*/

JS Bin demo

The comment I’ve inserted in the code above displays the message from the console, which demonstrates that inside the anonymous function, this is a reference to the global “window” object, rather than being a reference to the PrimaryNameSpace object.

And, as we saw earlier, using strict mode would make this undefined, rather than a reference to the global object.

Summing Up

If nothing else, this post should demonstrate that using this can be a useful shortcut. But all the while, keep in mind how the context can change the value of this as well how it behaves in strict mode.

I’ve only scratched the surface of this topic, so here are some further posts discussing the this keyword:

And if you have any corrections to what I’ve said, please add them to the comments and I’ll update accordingly.

Browsing Twitter Favorites From Talented Developers

Louis Lazaris — Fri, 25 Jan 2013 11:00:54 +0000

If you’re like me, then you probably find that your “home” Twitter stream (that is, the tweets of people you follow) is okay, but often contains a lot of noise and not-so-useful info.

What if you were able to see only the tweets that respected web professionals found to be exceptional? Well, you can do that quite easily by viewing a user’s Twitter favorites.

For example, here are a few developers on Twitter that will likely have tons of cool stuff saved in their Twitter favorites:

Of those above, I can vouch for Estelle’s favorites stream. She’s always got cool stuff in there that I’ve been checking out lately. And although Zoran is not as high-profile as the other’s in that list, he’s got some cool stuff in his favorites stream probably to help his research for CSS Weekly.

So that’s just an example list. I’m sure others could come up with a similar bunch of names whose Twitter favorites might be worth a peek.

How Do You Follow Favorites?

Here’s a solution that, unfortunately, will only work until March 2013.

Apparently, you can subscribe to a Twitter user’s favorites via RSS using the following URL syntax:

https://api.twitter.com/1/favorites.rss?screen_name=ImpressiveWebs

That example uses my Twitter favorites. To change the stream, just change the last part of the URL to match the user whose favorites you want to subscribe to.

But, as mentioned, according to Twitter’s API docs, that API call is now deprecated and those RSS feed links will fail in March 2013.

Kind of a bummer, especially since there doesn’t seem to be an updated method for subscribing to someone’s favorites via RSS. If anyone knows of a simple way to do this, please share.

Is there an app I don’t know about that does this? Or maybe this post can serve as a motivator for someone to build such a tool. Here’s the relevant part of Twitter’s API that you’d need to look into, if you’re interested in this.

Web Development and Tech Email Newsletters I Subscribe to

Louis Lazaris — Tue, 15 Jan 2013 11:00:50 +0000

To keep up with the latest news in tech, design, and development, I have a subscription-only email address that I use to subscribe to various industry newsletters.

I obviously can’t read everything in all these sources, but I skim all of them regularly, and read many of the links they refer to.

Here’s a list, in no particular order:

I also get regular product-related emails from Packt Publishing, MightyDeals, AppSumo, JSMag, Adobe, O’Reilly, iStockphoto, A Book Apart, Dribbble, and some others not related to tech/dev/design.

A few of the above newsletters are a bit spammy, but even the spammy ones occasionally yield an interesting link.

And don’t even get me started on my ridiculously-impossible-to-keep-up-with RSS subscriptions! :)

What Are Yours?

Got any cool design/dev newsletters that you subscribe to? Share.

Photo credit: Vector Newspaper Icon from Bigstock