As many of you know, I’ve recently launched a new weekly newsletter called Web Tools Weekly. In addition to providing a weekly, categorized list of tools for front-end developers, most issues begin with a brief tip or tutorial that usually includes code examples that have syntax highlighting.
In addition to the unique property/value pairs that CSS offers, there are also a small handful of language-wide features that can come in handy, including a few that are brand new in the spec.
These often go unnoticed, especially by beginners, because when CSS properties and their possible values are discussed (in tutorials, books, or even in the spec), these features are usually omitted for brevity.
Here’s something interesting that you may not have realized about CSS3 transitions. Normally, you’ll see a transition declared by utilizing three different properties, either in longhand or shorthand.
In both cases, we’re explicitly declaring three of the four transition-related properties (leaving out
transition-delay). Can a transition occur with less code than that? Well, yes.
As most of us probably are aware, a significant part of the HTML5 spec is the expansion of the History API.
This post will not be a super extensive discussion of this subject, especially since it’s something that I’m only now just getting into understanding better. But I thought I would put down the main components of the API, for my own quick reference, and I hope it will prove useful to my readers and those searching via Google.
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:
Let’s say you’re viewing different pages in your browser, and in the midst of your browsing you decide to visit a Google’s home page.
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.
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.
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, 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.
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.
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: