I wrote an article about getting started with HTML5 Boilerplate. It’s live at IBM. Check it out:

Kick-start your web development with HTML5 Boilerplate.

I’ve got some more content coming up on IBM over the next few months on some pretty exciting topics. I’m in the middle of a deadline for one right now, actually…

That begs the question- when will I sleep?

Answer: never.

Read the rest of this entry »

This came up in a comment here, so I thought I’d bubble this little tip to the top.

To target multiple files for URL rewriting in the HTML5 Boilerplate build script (as of version 0.95) use the fileset element instead of the file argument in the “html” target:

<target name="html" depends="">
    <echo message="Clean up the html..."/>
    <!-- style.css replacement handled as a replacetoken above -->
    <replaceregexp match="&lt;!-- scripts concatenated [\d\w\s\W]*?!-- end concatenated and minified scripts--&gt;"
    	replace="&lt;script src='${dir.js}/scripts-${build.number}.min.js\'&gt;&lt;/script&gt;" flags="m">	
        <!-- grab everything html -->
       <fileset dir="./${dir.publish}/" includes="**/*.html"/>
    </replaceregexp>
    <replaceregexp match="&lt;!-- yui profiler[\d\w\s\W]*?end profiling code --&gt;" replace=" " flags="m">
        <!-- grab everything html -->
        <fileset dir="./${dir.publish}/" includes="**/*.html"/>
    </replaceregexp>
    <!--[! use comments like this one to avoid having them get minified -->
</target>

You then need to expand the fileset element in the next three targets (htmlbuildkit, htmlclean, htmlcompress) to include subfolders.

Replace

<fileset dir="./${dir.publish}/" includes="*.html"/>

with

<fileset dir="./${dir.publish}/" includes="**/*.html"/>

And that should do it.

So… the site I’m working on has one of those “increase text size” controls. On this project it’s turned out to be one of those features that shows up in comps and somehow falls through the cracks until later on in the project cycle. Situation normal, really, as it isn’t a big feature. It’s just one of those things that needs to be buttoned up before the site can go live.

Anyway, I was thinking about how to do implement it the other day. I haven’t done one of these in a long time and the only other time I did one it involved crafting separate, albeit small, style sheets for the larger text sizes. I didn’t want to go that way again. Basically, I just didn’t want to write new style sheets- even small ones.

What’s a fella to do?

zoom

So, thinking about it a little bit, I seized upon using the non-standard CSS zoom property. Supported in Internet Explorer (zoom:1 is often used for a hasLayout toggle) and Webkit browsers, it would represent a simple (1 line!) CSS solution to this problem. It’s also one that I like better aesthetically as the site looks the same, just bigger. I figure there’s a reason all browsers have moved to this behavior when hitting ctrl+.

The problem was figuring out an equivalent for FireFox and Opera which don’t support zoom

Enter CSS 2D Transform

A little searching and experimenting later I came up with the idea of using CSS Transforms and the scale value to approximate zoom in browsers that lack support.

Let’s see how I did it.

As you go through the following keep in mind this hasn’t actually gone through testing yet so something weird could yet shake out. I just wrote this code yesterday, so you guys can be my sanity check.

Also, is anyone else doing this?

Read the rest of this entry »

As someone who started out doing JavaScript in the 1990s, I’ve been through the dark ages of debugging. Alerts, logging application data into DOM elements, etc. After having been through all that doom, I’m clearly a fan of console.log. I use it all the time. I bet you do too. It’s super useful.

The one downside? Leaving calls to console.log into code that’s being tested (as in, QA) or is destined for production (as in, emergency bug fix.) With Firebug or a similar tool running, you’re fine. Without it?

"console" is not defined.

I’ve seen this more times recently than I care to admit.
Read the rest of this entry »

I read High Performance JavaScript when it came out. It took me a while to write this review.

I’ve been busy (day job x spending a lot of time outside because it’s summer = less time for writing)

Anyway, it’s really good. It’s short, but well-written and focused so it’s an easy book to dive into, digest and integrate into your day-to-day.

One of the things I liked about it is that the topics cover enough ground that even as an experienced/expert developer you can learn some things that you’ve probably never run into in a production environment. Maybe you haven’t dealt with a lot of heavy-duty string manipulation and regular expressions or possibly you haven’t done a ton with build systems. They’re covered here, by experts. You might not be an expert after reading it, but you’ll definitely have enough to go on to start working in some solid enhancements into your own code.

All in all, this is a recommended book for all intermediate to expert JavaScript developers. It will get you thinking about your own code, about convenience and about JavaScript performance in a very fundamental way. That’s good for you, for your users and for the web as a whole.

Well, I leaked it earlier this week, so I might as well get started.

Welcome to How to Make a Web Site the Modern Way, a blog series outlining, to the best of my ability. how to build an HTML page using today’s best practices. The focus won’t be on specific coding techniques, although there will be some of that, it will be on how the pieces fit together. Without experience, it’s tough to know how the pieces of a web page fit together in the best way. I’ve got some of that experience and I’d like to share it with people. So at the end of all of this, I’m hoping this series will serve as a one stop shop for people looking to understand the big picture.

First up: The Anatomy of an HTML Page .

Some basic principles:

• Fast: I want pages to be as fast as possible by default.
• Findable: This isn’t really the same as SEO, but it’s kind of like a cousin to it. I want to make pages spiderable, human scannable, computer readable and generally information rich.
• Standards compliant: I’m not a standards zealot, but I try my best to follow web standards wherever possible.
• Accessible: I try to make pages as accessible as possible.
• Usable: Usability is a deep topic, but there are things you can do, by default that will enhance the usability of your site.
• Intuitive: I want developers to look at the stuff I do and say “hey, that makes sense.” I also want it to make sense to me when I return to it in six months
• Breakable: Which is a funny way of saying “graceful degradation,” a concept that colors a lot of what I try to do. The idea being- if something’s going to break, or not work as expected, make sure that it’s not totally screwed up

The Rest of the Series

This being a technology blog, with plenty of code samples being posted on a regular basis, it’s no surprise I give soem thought as to how that code is displayed. Personally I’ve gone for the old school, green on black text (using the excellent code font Consolas, where possible.) I like the way it looks.

function heckYeah() {
    check.it.out();
}

The one problem is with really long lines. Since I use a lot of real world examples and it’s code I’m caught between a desire to have one line of code=one line on the screen (easier to scan) and the readability issues that a scrolling text box creates.
Read the rest of this entry »