It should be a coder’s goal to make sure that every character in every line of code serves some purpose.
The quality of code is not dependent on good form, prettiness, or theoretical benefits. Code should solve problems.
HTML5 lets you omit closing paragraph tags and closing tags for list items. Some cringe at the thought of this, but it’s perfectly valid code. So if omitting extra tags helps your code become leaner and faster, then you’re solving a problem and that makes it good code.
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.
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.
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:
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.