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.
Continuing our examination of HTML5, this time we’ll take a slightly deeper look at the state of HTML5 support in browsers. We’ll step through several major features, examine the technical hurdles in place, identify the level of browser support and finally provide some recommendations on whether or not to pull the trigger with that shiny new feature.
New Semantic Elements
HTML5 has added many new semantic elements. These both codify existing, common patterns and offer new, meaningful ways mark up your content. So, for example, going forward, instead of using <div id="header"> we will now just use <header>. Some other examples (with definitions culled from the specification) include:
section
The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading.
Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site’s home page could be split into sections for an introduction, news items, contact information.
footer
The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.
nav
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
article
The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.
That’s far from a complete list, but it should serve to give you the flavor of what’s available.
Support
This is a curious case. If, by “support” we mean “doesn’t break anything” then the support here is broad. Using the HTML5 Shiv code snippet or the full blown Modernizr library every browser that matters supports the HTML5 elements. If you’re expecting user agents to do something interesting with your new elements, then the support level is much lower. Read the rest of this entry »
HTML5 is the latest version of the language that serves as the foundation of the web. It’s the first major revision in over 10 years and as it’s gotten closer to its final form and more and more browsers begin to implement its features it’s become a source of intense interest and contention in the technology community. This article hopes to explain the realities of HTML5, dispel a couple of myths and shine some light on the future of the web.
To begin we’ll need to define what we’re talking about when we say “HTML5.” There is a specification to refer to and much of what falls under the HTML5 name lives in that spec. In addition, there are several related specifications and APIs that are lumped together and called “HTML5″ when people talk about these things informally.
So, conversationally, HTML5 consists of the following:
New Semantic Elements
HTML5 has introduced several new elements. They aim to introduce more meaning to markup and codify existing web development patterns. Some examples of these new elements are nav (for navigation), article, header and footer.
We relaunched the Cramer blog today. It’s a soft launch. We’re hoping to shake out any kinks over the quiet time around the holiday. I did the initial HTML5/CSS3 templates and then shepherded the project for a couple of weeks* until I was freed up enough this past week to get the thing out the door. Read the rest of this entry »
Things are afoot. I’m building out the redesign of Drunkenfist.com, and we’re working on an internal redesign at work. I’ve been toying with the idea of using the new HTML5 semantic elements for both and to that end I took some time to evaluate Modernizr, the small JS library that programatically exposes HTML5/CSS3 feature support (via classes on the HTML element) and “fixes” IE’s style support for some of the newer semantic elements. Read the rest of this entry »
