Let's Build the Web We Want
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.
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="<!-- scripts concatenated [\d\w\s\W]*?!-- end concatenated and minified scripts-->"
replace="<script src='${dir.js}/scripts-${build.number}.min.js\'></script>" flags="m">
<!-- grab everything html -->
<fileset dir="./${dir.publish}/" includes="**/*.html"/>
</replaceregexp>
<replaceregexp match="<!-- yui profiler[\d\w\s\W]*?end profiling code -->" 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?
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
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?
Continue reading “Using CSS zoom and CSS Transforms For a Better “Increase Text Size” Button”
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.
Continue reading “An Ant Task to Comment Out console.log Calls from JavaScript Files”
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.