If you’re fairly inexperienced with JavaScript but you’ve used jQuery, then its likely you’ve used callback functions. But maybe you don’t fully understand how they work or how they’re implemented.
In this post, which is based on what I’ve learned about callback functions, I’ll try to enlighten you on this fairly common JavaScript technique. And maybe some of our JavaScript experts can chime in and let me know what I’ve omitted or oversimplified.
On a current project, I was trying to find a way to auto-resize a textarea according to some content that would be loaded in dynamically via Ajax. I didn’t know the height of the content and the textarea element doesn’t resize naturally like other HTML elements, so I needed to update the height of the element with JavaScript each time the content changed.
It seemed like a simple task. After doing a search to see what types of plugins and scripts were floating around to do this, the examples I found seemed a little overly complex. While most solutions seemed to incorporate some complex math calculations, I thought of a better way.
“Vertical-align isn’t working!” cried the web developer.
The vertical-align property is one of those features of CSS that sounds pretty self-explanatory, but can cause problems for CSS beginners. I think even many CSS veterans have had problems figuring this one out at times.
In this post, I’ll try to cover it in an understandable manner.
With all the hype surrounding the new APIs and the fancy parts of CSS3, I had almost forgotten about the new reversed attribute that allows you to write a descending list of numbered items, as opposed to the default ascending list of numbered items.
You can get full details in the specification, but here I’ll summarize what it does and I’ll offer a solution for the fact that there is (from what I can see) no browser support for this attribute.
If you’ve been using CSS3 transitions for some time, you might be accustomed to a certain type of syntax.
Here I’ll introduce the keyword value “all” and how it might save you a few lines of code and make things easier to maintain in the future.
The other day Paul Irish posted an article that collected together responses to a question that he and Yehuda Katz asked their Twitter followers.
One of the wishlist items a few people mentioned was “CSS blend modes” with a use case of tinting an image on hover (or tinting it statically, then removing the tint on hover or by some other interaction). My immediate thought was: That should be simple enough, shouldn’t it?
Maybe there’s a technical term that I’m not aware of for this type of centered, line-splitting heading. Whatever it’s called, I’ve used it in a project’s footer in the past, where I’ve divided the footer into sections with headers that overlay a horizontal line.
I wanted to try to do this as efficiently as possible, and without images. I came up with three solutions with pure CSS and one that uses JavaScript.
If you haven’t yet used CSS3 transitions extensively, here’s something you may not have picked up on.
As I’ve outlined before, transitions can be triggered in a number of ways, and even via JavaScript. The reason for this is because the actual transition is not dependent on any particular event. Although it is the event that triggers the transition, the transition itself is completely separate from the event (as it should be).
Because of this, you’ll notice a slightly quirky behaviour if you place the transition on the part of your CSS that triggers the event.
Earlier this month, Chris Coyier posted an article discussing a way to deal with the empty elements that are often needed when doing CSS3 animation.
Chris’s solution is interesting. He basically suggests (and I’m paraphrasing here) that we can give the empty elements semantic value by adding some text in each one to describe what each animated element does, or what mood it conveys. Then, the text in those empty elements can be moved off the page with CSS.
Some people got in a tizzy over the potential SEO penalties that could arise (which I kindly pointed out is probably not an issue) while others seemed to have a problem with Chris’s use of the word “semantic”.
You’ve probably used CSS’s border property often, and in almost all cases you’ve probably set the border-style value to “solid”, which looks exactly the same in every browser.
We all know there are other values for border-style, but it’s likely you’ve never used any of them. You may have used a value of “dashed” or “dotted”, but probably not too often.
I thought it would be interesting to screen capture how all the different browsers display all the different values for border-style. In addition to the screen shots, I’ve provided some observations and I’ve summarized how the different values are supposed to look (according to the specification).
