This section of Impressive Webs features articles covering front-end technologies like HTML, CSS, and JavaScript. Some of these posts are opinion pieces and others are more research-based discussions of standards and best practices, with occasional roundups.
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.
A colleague today mentioned the 2013 Toronto Blue Jays — a much improved team compared to what was fielded in 2012. It’s owned and operated by Rogers Blue Jays baseball Partnership, a division of Rogers Communications
I opened up their website and scanned through it, quite excited by the upcoming season and the game schedule. It was only when I clicked through to their team roster that I saw this:
Never forget that usability lessons can be learned from virtually anything you use. This concept has been discussed extensively in Don Norman’s famous book, and I thought I’d discuss something specific in this area in this post.
Last week I sent out a tweet regarding an annoyance with USB plugs.
Before I get into the meat of this post, I’ll just provide some context. Last week, Harry Roberts posted a fantastic article discussing his view of bad CSS. In that article, as he’s done before, he disourages the use of IDs as selectors.
In response, Jeffrey Zeldman tried to defend the use of ID selectors. I posted a few comments in response to Jeffrey and another commenter, explaining why their views were wrong.
In most cases, when you place an element on the page in your markup, if you don’t specify any special styles, it will occupy exactly the same space that it appears to occupy visually.
In other words, if you place a box sized at 200px by 200px on your page, anything you place after it in the source order, with no further styles added, will occupy the space below or beside the green box, outside of those set boundaries.
But not everything on an HTML page occupies space that is honored by other elements. I thought it would be interesting to list and describe all the things in CSS that don’t occupy this kind of physical space in an HTML document.
For a while now, I’ve been using Notepad++ with a customized version of the Zenburn theme, which was originally created for Vim.
This week I finally started fiddling around with Sublime Text 2, and I like what I’ve seen. Although I like the default Monakai theme, I prefer my old customized version of Zenburn from Notepad++. So I forked the Zenburn repo and made my alterations.
The upcoming IE10 will continue to have strong support for a number of CSS3 features and HTML5 APIs.
But if you haven’t yet heard, many of these features will be supported in IE10 unprefixed. These include gradients, animations, transitions, and more.
There’s been a lot of talk about IE10, and what it supports, and the great improvements it’s made.
Taking all the latest news into consideration, I summarize my thoughts on this subject in this post.
When I look at new modules in the CSS spec, it makes me feel like singing the chorus from a popular Radiohead song from the ’90s: “But I’m a creep. I’m a weirdo. I don’t belong here.”
If web standards could talk, I think a lot of them would be humming that regularly.
When you code a button or other clickable element, you need to also define a comfortable click area. Depending on the context and the design, this can sometimes be a challenge. Let’s look at a few examples in a short case study, so we can see the various ways this can be done.
Some navigation bars that I’ve seen are quite paradoxical in the click area they define. Look at the screen shot below showing the main nav bar for WebProNews.