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.
I don’t know how many times I’ve redesigned this site over the past 4 years, but here’s another one, just launched this morning.
Layout-wise, there’s nothing really all that different. It’s more of a different skin than anything, and (out of sheer laziness) the comments and footer area have pretty much remained the same. Basically, I got tired of the dull looking header/sidebar in the previous design and wanted something cleaner and with a little more color.
Recently, a friend who used to do some web design years ago approached me with some questions about getting back into front-end coding. She doesn’t have a programming background and, from what I understand, her experience in coding is limited to old-style HTML using tables and very little CSS.
She says she finds all the stuff associated with front-end development to be quite overwhelming. Well, she’s not the only one. I think we all feel frustrated at the amount of reading and research that’s needed to keep up with things in the industry.
I don’t know who started it, but at some point in the web’s relatively short history, we decided that paragraphs displayed on web pages should be “typeset” in a manner similar to what we see by default in a Microsoft Word document: an empty line after a paragraph, and no indent for each paragraph.
Somehow it was unanimously settled upon that the traditional manner of typesetting paragraphs — with indents and no spaces between paragraphs — is not as readable on a computer screen. In fact, the default styles applied by a browser on paragraph elements encourages the no-indent method. If you throw together an HTML document that doesn’t have any author styles defined, you’ll see the following when you inspect your paragraph elements in Chrome’s developer tools:
If you keep up on print magazine reading in the industry, you probably know that .net magazine and Web Designer Magazine are basically the only two print magazines specifically targeted at web designers (at least, the only two that I know of).
So recently, Web Designer contacted me to do a feature piece covering CSS3 techniques. The focus of the piece is CSS effects that, prior to CSS3, required the use of images or scripts. The feature (called “Master CSS Effects) was planned to have 30 CSS techniques, and I was responsible for covering 20 of them. I don’t know what the final count includes, as I haven’t yet seen the issue, but the magazines’s staff were responsible for any remaining tips. They also wrote the intro and conclusion.
For a while now I’ve been wanting to set aside some time to do some sort of web development parody. I’ve done this sort of thing before and it’s fun to see people’s reactions.
I knew it had to be something centered around the ‘framework’ movement, mainly poking fun at the well-known HTML5 Boilerplate project. So on Tuesday night this week, I took the idea of HTML9 Responsive Boilerstrap JS from concept to creation. I finished it that night, including registering the domain, setting up the site, and gritclonemerging its own bogus repo.
In March I wrote about some of my least favourite parts of CSS. Admittedly, that was a pretty negative post, and I’ve even slightly changed my opinion of a few of those things, thanks to the comments.
But I like CSS a lot. So as a follow-up, I thought it would only be fair to list some of the things in CSS that I think work very well and thus are valuable to know and use often.
I think everyone should be willing to look back at their older work and laugh and realize how far they’ve come. Even the best designers, developers, and bloggers have past work that they cringe at today. Heck, I cringe at stuff I wrote six months ago!
So with the help of Archive.org and WordPress’s easy-to-navigate paging system, I thought it would be fun to cause a whole bunch of people tons of embarrassment by rounding up some of the earliest articles I could find on various popular web design blogs. Enjoy.
It’s sometimes intimidating and often ridiculous how quickly this industry moves forward. Just when you think you’ve reached “front-end developer” status, you realize there’s so much you still don’t know, or else only know superficially.
Others have expressed their views about our industry and how frustrating it feels, and still others feel that too much is asked of front-end developers.
As many of us have learned, vendor prefixes are a pain in the butt to maintain, and it’s great that CSS preprocessors and client-side scripts are available to help in this regard.
Although I’ve recommended that the standard property be listed after the vendor-specific lines, for “future-proofing” the code, I’m starting to think that might be bad advice in some circumstances.
We all know that CSS colors can be declared using hex, RGB, RGBA, HSL, and HSLA. But colors in those forms are not very memorable (unless they’re greys or something).
While I’m sure we all know that common colors like red, green, blue, etc. can be declared by name, CSS has quite a few not-so-conventional color names. Here are a bunch, with their colors represented as backrounds on each paragraph.