Archive for the ‘web’ Category

Responsive Web Design for Mobile

Friday, July 2nd, 2010

Respon­sive web design is unde­ni­ably the new hot­ness in CSS. If you’re not famil­iar with the tech­nique, go and read Ethan Marcotte’s amaz­ing arti­cle over on A List Apart. What Mar­cotte has cre­ated is a way to cre­ate one design that adapts to dif­fer­ent res­o­lu­tions using media queries.

There are count­less advan­tages to build­ing sites in this way, but arguably the most com­pelling rea­son is the abil­ity to share one lay­out across both desk­top and mobile browsers. How­ever, if you’re new to mobile devel­op­ment there are a cou­ple of tricks you’ll need to use in order to make this work. It wasn’t really in the scope of Marcotte’s arti­cle to cover the mobile-specific aspects of his tech­nique, so I fig­ured a quick post was in order to fill in the gaps.

The exam­ple site we’ll be look­ing at is a hypo­thet­i­cal site for food­ies called Fork’d. When you look at it in a nor­mal sized desk­top browser, It’s got a ver­ti­cal nav­i­ga­tion list and three columns of con­tent. If you resize the win­dow to be a fair bit nar­rower, you’ll see that the floats dis­ap­pear, and the nav­i­ga­tion as well as all of the con­tent is lined up in a sin­gle col­umn. This is the lay­out we want our mobile users to see. How­ever, what they’re actu­ally going to see is this:

the site renders very small

For­tu­nately, we just need a tiny sprin­kling of pixie dust to make this work the way we expect it to. We’ll just add this meta tag to our page:


<meta name="viewport" content="width=device-width, initial-scale=1.0">

(For way more info on view­ports, check out Apple’s doc­u­men­ta­tion on the sub­ject.)

Once we put that in place, the Fork’d site ren­ders like this:

the site renders at the correct resolution

Per­fect! We now have one lay­out that works across dif­fer­ent desk­top screen res­o­lu­tions as well as (high-end) mobile devices, and the only extra trick we had to employ was to add a sin­gle meta tag.

The Rounded Corners of Tomorrow… Today!

Thursday, October 2nd, 2008

Hey, you know what can be a real pain in the tail? CSS rounded cor­ners. Of course there are battle-tested, work­horse solu­tions out there, like slid­ing doors, or a hand­ful of Javascript-based alter­na­tives. But rounded cor­ners are such a com­mon ele­ment of web design and seem like a nat­ural exten­sion of the designer’s exist­ing toolkit that it only makes sense that there should be a way to imple­ment them with pure CSS. The good news is that border-radius is indeed com­ing in CSS3. The bet­ter news is that you can start using it today, as long as you’re only tar­get­ing Gecko & Webkit. Before we get to that though, let’s look at the way it’s sup­posed to work accord­ing to the spec.

As you might expect, the border-radius prop­erty is used a lot like border. That is, you can spec­ify one value for each cor­ner (border-radius: 10px;), one value per cor­ner (border-radius: 1px 2px 3px 4px;), or val­ues for oppo­site cor­ners (border-radius: 5px 10px). It actu­ally gets more com­pli­cated, since in addi­tion to describ­ing cor­ners with one radius (i.e. those with semi-circular curves), you can make ellip­ti­cally rounded cor­ners by nam­ing two radii. For more detail on this, take a look at the draft spec. Lastly, you can use a prop­erty for each cor­ner, border-top-left-radius: 2em;, etc. So, assum­ing there aren’t any major changes in the spec, expect this to be what gets imple­mented as part of CSS3, and what you’ll ulti­mately using in your code.

But what about now? Here? Today? It hap­pens that two of the standards-aware, forward-thinking ren­der­ing engines have devel­oped pro­pri­etary exten­sions to CSS that should stand in for border-radius until cer­tain ambi­gu­i­ties in the spec can be resolved, and the prop­erty is implented accord­ing to the stan­dard. So if you want to use border-radius in your code today, you’ll have to use both the Mozilla– and Webkit-specific CSS prop­er­ties. For­tu­nately, both of the pro­pri­etary exten­sions work in the cur­rent major releases of their respec­tive browsers.

If you’re mak­ing a box with four cor­ners of the same radius, the syn­tax is the same in Mozilla and Webkit:

-moz-border-radius: 10px; /* 4 corners of radius = 4px*/
-webkit-border-radius: 10px; /* Same as Mozilla */

To spec­ify dif­fer­ent radii for each cor­ner, things diverge somewhat.

/* Mozilla: */
-moz-border-radius: 1px 2px 3px 4px;
/* Webkit:
    (The four declarations below amount to the
    same thing as the single rule above) */
-webkit-border-top-left-radius: 1px;
-webkit-border-top-right-radius: 2px;
-webkit-border-bottom-right-radius: 3px;
-webkit-border-bottom-left-radius: 4px;

And that’s the guts of it. So to make a tabbed nav­i­ga­tion list, you would use a dec­la­ra­tion along the lines of the fol­low­ing (and see the below code in action.):

li {
  border: 1px solid #587402;
  border-bottom: none;
  border-radius: 0 10px 0 10px;
  -moz-border-radius: 10px 10px 0 0;
  -webkit-border-top-left-radius: 10px;
  -webkit-border-top-right-radius: 10px;
  list-style-type: none;
  float: left;
  padding: .5em 1em 0 1em;
}

There you have it. But there are just a cou­ple of other things I want to point out. If the con­tainer you’re round­ing the cor­ners of has only text con­tent and a back­ground in it, the back­ground will clip to the rounded cor­ners. And indeed, accord­ing to the spec, any the con­tents of a block-level ele­ment on which a border-radius is set should clip do the same as long as you set overflow: hidden on those con­tents. How­ever, the imple­men­ta­tions just aren’t there yet. Instead, with any­thing over and above plain HTML text (for instance, an img or iframe) inside such a con­tainer, the square cor­ners will peek out­side of the rounded con­tainer. (Exam­ple)

One solu­tion would be to make the bor­der thick enough that the cor­ners of the inner ele­ment can’t poke through the outer bor­der (like so). Though inel­e­gant, this will work just fine if you don’t need every­thing to round nicely. And this method should suf­fice for what­ever kind of con­tent you’re try­ing to stuff into your nicely rounded box.

How­ever, if it’s an image you’re putting in the box and you need the inner cor­ners to be rounded as well as the outer cor­ners, then the only answer (for now) is to set the image as a back­ground. Still, if the lan­guage of the spec is any indi­ca­tion, it won’t always be this way.

For the poor soul who is try­ing to squeeze iframe con­tent into a rounded cor­ner box, you’re essen­tially out of luck at the moment. You can cer­tainly use the thick bor­der method I described above, but short of that, you’ll have to look to the bleed­ing edge. That is to say, you’ll need some­thing which isn’t yet in any production-quality browser, but that is cur­rently in the Webkit nightlies. I speak of the arcane meth­ods of -webkit-mask-image. This prop­erty can take a png or an svg as its url, and pretty much any­thing you apply it to will play nice and clip to the shape of the image. See for your­self. Still, this last bit is obvi­ously not any­thing any­body will be using in pro­duc­tion code for some time to come.

After read­ing all of this, if noth­ing else, I do hope that you’ve come away with a bet­ter idea of some of the great things that the CSS work­ing group has in store for you, the devel­oper. But even moreso, hope­fully there’s some­thing in all of this mess that you’ll be able to put to use today.

What I’m Reading: 3/28

Friday, March 28th, 2008
  1. It’s Not a League of Their Own: Boston Dirt Dogs has an excerpt from the 2008 Red Sox Annual in which the authors size up the Sox’ com­pe­ti­tion in the Amer­i­can League. On the whole, it’s pretty inter­est­ing I guess, but the best part is that the sec­tion on the Ori­oles is just one long ref­er­ence to The Wire. And if you read a lit­tle fur­ther down there’s another Wire ref­er­ence that’s mas­querad­ing as a pithy state­ment about the eco­nom­ics behind your brand new Tampa Bay Devil Rays:

    My eco­nom­ics are rusty, but when you have an infe­rior prod­uct in a sat­u­rated, inelas­tic mar­ket, one strat­egy is to re-brand the prod­uct. There­fore, exit the Devil, and their aqua uni­forms, to be replaced by the San Diego Padres kits with blue replac­ing sand brown.

    Stringer Bell is alive and well in the sports pages, folks.

  2. WebKit gets 100% on Acid3: “Yesterday’s news” you say? Nope. The news today is about Webkit/GTK. Awe­some news for us LXers. Also, def­i­nitely take a look at this account of the main Webkit team’s road to 100/100. It’s got some fun insights for spec­ta­tors of the race between Webkit and Opera for full Acid3 com­pli­ance. And for some (prob­a­bly much-needed) per­spec­tive, here’s one Mozilla-er’s take on the Acid3 arms race.
  3. JavaScript Talk at North­east­ern: It’s a video of John Resig’s recent talk at North­east­ern on Javascript and jQuery. What are you still doing here?

What I’m Reading: 3/24

Monday, March 24th, 2008
  1. Nine Tech­niques for CSS Image Replace­ment: If you spend any time at all play­ing with CSS, you know that there are a full bajil­lion tech­niques for replac­ing text with an image. It’s a lot to remem­ber, and I’ll fess up that I tend to use what­ever one I hap­pened to have read about most recently rather than tak­ing a con­sid­ered approach to which of them might be the best solu­tion for a given sit­u­a­tion. No more! The above-linked post does a great job of run­ning through the pros and cons of the 9 (9!) major tech­niques, and from now on you (mean­ing “I”) no longer have any excuse to not use the best, seman­tic, most acces­si­ble one at every opportunity.
  2. Drugs, Bugs, and IE8: A pre­dictably good read from Eric Meyer, but I link to it mainly to have an excuse to echo the fol­low­ing point: There are a lot of beta browsers out there right now (one less, now that Safari 3 has shipped). If you’re test­ing your sites in them and some­thing ren­ders in any way other than what you were expect­ing, sub­mit a bug report. Don’t change your code.
  3. Opti­miz­ing Page Load­ing in the Web Browser: For the browser builders, net­work latency is at least as big a prob­lem as con­nec­tion speed.
  4. A Japan­ese RPG Primer: The Essen­tial 20: Last week, Gama­su­tra pub­lished this list of the best of the best in Japan­ese RPGs through­out the ages. It’s a top-20, so it’s not exhaus­tive, but it’s sure as hell exhausting–i’ve been chip­ping away at this beastie since last week. Any­way, if you’re at all into JRPGs, it’s a really fun read. It’s also neat to see some old favorites put into con­text along­side some sem­i­nal games that you may never have been exposed to.

What I’m Reading: 3/20

Thursday, March 20th, 2008
  1. CSS Styled Scroll­bars With Mootools and JQuery: Cur­rently, only the IEs sup­port the styling of scroll­bars with CSS alone (although scroll­bar styles are part of CSS3). This post links to a cou­ple of Javascript-library-based tech­niques to get the job done in the meantime.
  2. Mak­ing ‘IE6-friendly’ PNG8 Images: Turns out our beloved hack to get trans­par­ent PNG32s in IE6 can some­times crash the browser. To play it safe and ensure crash-free view­ing of your site, it’s prob­a­bly best to use PNG8 until IE6 is no longer a fac­tor (some­day, «ras­safrackin…»). This post gives you some tech­niques to make your PNG8 graph­ics almost as use­ful as PNG32s.

What I’m Reading: 3/19

Wednesday, March 19th, 2008
  1. Mar­t­ian Head­sets: Spolsky’s take on IE8 & web standards.
  2. Trans­la­tion From MS-Speak to Eng­lish of Selected Por­tions of Joel Spolsky’s “Mar­t­ian Head­sets”: Mark Pilgrim’s take on the above.
  3. Site­Point Guru Lists: SitePoint’s authors have listed the best arti­cles on the Site­Point, er, site, for get­ting started in var­i­ous areas of web design & development.

Front-end Development Link Roundup

Sunday, January 20th, 2008

Here are just a few arti­cles that have come out in the last cou­ple of weeks that might be inter­est­ing and/or use­ful to some folks.

  1. What CSS Did We Learn in 2007
    SEO site Search-This lists the CSS tech­niques they cov­ered through­out last year. It’s a lot of use­ful, basic, meat-and-potatoes stuff.
  2. 101 CSS Tech­niques Of All Time– Part 1
    Noupe begins a multi-part list of what they find to be the most use­ful CSS tech­niques. Again, a lot of great basic stuff for those who may be new to CSS, but it should also be pretty handy as a ref­er­ence for the griz­zled vets out there.
  3. Acid 3 Tack­les ECMAScript
    Resig lays out exactly what Acid 3 is test­ing. Very inter­est­ing, and some nice insight into some edge cases in Javascript
  4. Thoughts on Fire­fox 3.0
    Nice overview of some of the changes in Fire­fox 3. He men­tions some improve­ments to the DOM imple­men­ta­tion (and links to Mozilla’s more exhaus­tive list).
  5. Reset­ting Again
    Eric Meyer once again pushes the state-of-the-art in CSS resets.
  6. IE6CSS Bugs and Fixes Explained
    Another nice ref­er­ence post. Dave Woods looks at a rogues gallery of cross-browser ren­der­ing issues.

That’s it for now. Hope­fully some­one will find some­thing use­ful in here.

Will IE6 Ever Die?

Friday, November 16th, 2007

The other day, my XP install prompted me to update to IE7. I’m curi­ous about whether this is hap­pen­ing to other Win­dows users out there. Does any­one else have a Win­dows box that’s forc­ing them to make the switch? What about you folks in the big shiny build­ings? Are your cor­po­rate IT over­seers deploy­ing IE7 on your work machines?

At the lum­ber­ing behe­moth of a com­pany where I’m cur­rently doing some con­tract work, all of the machines run IE6, and I can’t imag­ine that the IT group here is going to push an upgrade any time soon. Fur­ther, I don’t think it’s a stretch to say that there are scores of com­pa­nies out there, from the very big to the very small, that are sim­i­larly unlikely to upgrade any­time soon.

As you can prob­a­bly guess, the point of these queries & spec­u­la­tions is that I’m really start­ing to won­der if the web devel­op­ment com­mu­nity will ever be able to stop sup­port­ing IE6. Of course the answer has to be “yes, at some point” but when? It’s only been a year since IE7 shipped, and I’m guess­ing that there are still more folks out there using IE6 than IE7. Although I can’t find any num­bers about the IE6 vs IE7 mar­ket share, W3schools has a break­down of their site’s users that shows more peo­ple using IE6 than IE7, and if the web savvy still skew that way, it seems safe to assume that the gen­eral pop­u­la­tion does as well.

I don’t have a good answer for that ques­tion (if you do, I’m all ears), but it’s worth think­ing about. I’m all for push­ing ahead and cre­at­ing new stan­dards (CSS 3? ECMAScript 4? HTML 5? w00t!), but if there’s never going be a widely used browser that’s going to imple­ment them (to say noth­ing of imple­ment­ing them cor­rectly), then isn’t it all just navelgazing?

Of course, as I type this, I can hear one of the for­merly devout IE peo­ple near my cube explain to some­one how the Fire­fox Wed Devel­oper Tool­bar “can really make your life eas­ier.” Maybe there’s hope after all.

Post­script: The Wiki page about the his­tory of IE men­tions a rumor that a pre-alpha IE8 has been cir­cu­lat­ing on P2P net­works. That pretty much has to be false, right? I’m sure the IE team will try their darn­d­est to ship IE8 some­time before 2013, but I’m will­ing to bet they’re more focused on com­ing up with new and dif­fer­ent ways to man­gle web-standards bug-fixes than get­ting another ver­sion out the door.