Off and on over the past few months, I’ve been planning and working on a new project that is now ready to launch: Web Tools Weekly, a (you guessed it) weekly email newsletter targeted at front-end developers, with a special focus on tools.
This is not, by any stretch of the imagination, a unique idea. As many of us know, there are lots of options in the recent web dev newsletter boom.
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.
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: