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.
Yesterday I tweeted the following: “On current client project, client says CSS only needs to work in Chrome. Let me know how jealous you are.”
The results weren’t too surprising. Below I brainstormed a list of some other things we wish clients would say. I guess this is the polar opposite of what you find here, except these quotes aren’t real. Enjoy.
A trackback on one of my previous posts (yeah, trackbacks aren’t just for spam) alerted me to an interesting point brought up by a blogger named Matt Pass. In his post entitled Walnut, Meet jQuery Sledgehammer he politely explains why he feels it’s overkill to use jQuery in a simple tutorial post.
His main point is summarized in this quote: “Do you really need a 90k JavaScript library (and thats the minified version) to toggle the size of a menu?”
In a recent post wherein I questioned the legitimacy of W3schools’ subdomains, someone pointed out that my own site was suffering from a somewhat related problem.
Basically, if anyone typed a random subdomain in place of the “www”, the subdomain would remain in place in the address bar without any redirection occurring. So for example, if you visited peanutbuttersandwich.impressivewebs.com, the site would display as normal, except with the “peanutbuttersandwich” part still intact.
What’s worse is that I have other domains on my current hosting plan, and impressivewebs.com is the primary domain. So if someone typed in a subdomain for one of the other domains, they would actually see the impressivewebs.com home page. For example, if you visited peanutbuttersandwich.animiationfillcode.com, you would see the impressivewebs.com home page with the animationfillcode.com URL still in the address bar.
As a front-end developer, I’m constantly trying to learn new skills and technologies and adding to what I already know. Front-end developer job postings, however, vary from posting to posting so the list of different languages, libraries, and technologies that could theoretically fall under the category of front-end developer skills is quite large.
Here’s a list (that I’ll continue to update) containing a wide variety of skills and technologies that I think all front-end developers should be working on learning, at least to some extent. I certainly don’t know all of these, nor do I expect anyone else to.
The list is not necessarily in any particular order, but I tried to keep the more rudimentary stuff at or near the top. Also, many of the items overlap others, so there’s a lot of cross-over within the list. And of course the list has lots of potential for improvements (more on that below).
As the weeks go by, I find tons of new developer resources, tools, and things worth looking into.
I wrote a similar roundup of JavaScript resources, so this time I’m covering stuff related to what we commonly call “HTML5″ (even though a lot of this stuff could easily fall under a “JavaScript” umbrella too).
I’m not entirely sure what to think of this situation, but it seems to be yet another strong piece of evidence that the people behind W3schools don’t have our best interests in mind.
I’m currently in the process of revamping my CSS3 Click Chart app and I was doing my usual cursory searches for simple JavaScript methods that I often forget the syntax for. Notice what I stumbled across, as shown in the re-enactment below.
Lately in some of my writing projects I’ve had to hunt down sources to demonstrate the importance of web page speed. Usually a quick Google search will pull up some pretty good ones, and I have a few others on file that I can refer to.
I thought I would put together a roundup of some of the ones I’ve been able to find. Web development bloggers, who are constantly promoting the importance of web page speed, should have these types of authoritative sources at their fingertips.
So consider this post the collective evidence for the importance of page speed. Posts are listed from oldest to newest.
Over the last couple of weeks I’ve introduced a new link in the main navigation on this site. It’s a new section called CSS Basics.
I’ve wanted to publish info on really basic CSS stuff, because I think web design should be taught at many levels and beginners should especially be informed of the right way to do things.
This is a question that has been answered in a number of different places. Unfortunately, the answers in some instances have not been good ones. In fact, they’ve either been way too optimistic and/or presumptuous — or else just downright wrong.
Also, when we use the term “HTML5″, what exactly are we referring to? HTML5 covers a number of different features and technologies, some of which have nothing to do with SEO. So, generally speaking, when people ask this question, they’re usually referring to HTML5′s new semantic elements. So, I’ll primarily focus on those here.
Most good developers by now accept the fact that pixel-perfect cross-browser CSS is not only unnecessary, but also totally impossible.
Of course, when we speak of the challenge of “cross-browser” CSS, we’re really saying “How can I make this work in Internet Explorer versions 6-8?” — because those are really the most problematic browsers.
Although I’ve written before about cross-browser CSS, and I still stand by just about every word in that article, I thought I’d reiterate my feelings on this subject by providing what I feel is the best workflow for getting your CSS to be as efficient, hack-free, and maintainable as possible while providing as similar an experience in all supported browsers.