It’s what happens when conference organizers look beyond logistics and put love into every component. Simon & Greg’s careful consideration & ordering of speaker topics combined with their overwhelming hospitality set a great tone that seemed to be amplified by all who partook in the week’s activities. On a personal note, I loved introducing my wife and son to industry comrades and dear friends. Seeing little Henry passed around Simon’s house was pure magic. So was watching him flirt with Aymie, Denise, and Naomi. I’ll be sure to have a sit-down with him about not laying it on too thick one of these days.

Along with speaking, I had the privilege of guiding a workshop. We looked into the basics of setting type (responsively), some of my favorite CSS properties for type, and of course Lettering.js and FitText. During the last hour of the workshop, participants were let loose to build their own stuff. I provided a handful of screenshots from The Movie Title Stills Collection, curated lovingly by Christian Annyas, and challenged everyone to recreate them with HTML, CSS, and Lettering.js. I was amazed to see what people came up with. Here are some samples of their work. I’ll be updating this post as more come in. Also, I’ll post links to video & slides from my talk as they make their way online.

By @supereight

By @mickykelleher

By @richardwiggins

By @drbparsons

By @jokedewinter

By @MaraidDesign

By @martuishere

By @martuishere

By @lewisnyman

By @jameslindeman

For those planning to attend, please feel free to comment below with anything in particular you’d like to cover. There’ll be plenty of resources at your disposal as well as time for discussion and collaboration. Also, please bring your computer and be ready to do some light coding. See you in just over a week!

Fine control remains elusive – kerning, character spacing – controlling these aspects are both difficult to specify for numerous reasons. This is frustrating to designers who love typography and want to have that finer control.

Huzzah! I couldn’t agree more. As web designers, now that our type options have drastically expanded, we want the same level of control over them that print designers do. That includes kerning as well as more interesting & intricate typographic arrangements. The key here is specificity. If we can target letters and words with CSS the sky is the limit. For further reading here are some posts that my friends and I have written on the topic:

• Controlling Web Typography: An older post I wrote summing up Lettering.js and explaining why we hope CSS makes it obsolete
• A Call for ::nth-Everything: This is Chris Coyier’s take, but much more comprehensive and clearly reasoned than mine.
• Lettering.js: I like to think of the gallery as a series of case studies for how enhanced selectors would be useful.
• Dave Rupert’s original Lettering.js post: A great introduction to how Lettering.js came about and how to implement it.

One interesting potential issue with finer control could be what happens if we target specific letters or words on a multi-lingual site. Something as detailed as this might make no sense, or break visually in another language. This was a point Christian Heilmann raised last summer at ConvergeSE, and something I don’t yet have a good answer for.

Overall, I think that the fewer situations where web designers have to resort to image replacement for text the better.

To take things further, I added in a CSS transform to get that skew, then dropped in FitText to make it all scalable for use in your fluid/responsive layout. Get a copy of Issue 221 & check it out for yourself!

After a morning of team planning and intensive YouTube research, we settled on building a page for a fictitious gameshow on the Knuckleodeon Network called Triple Dare. Reagan put together some fantastic illustrations, and I designed them into a layout that I hope leaves lots of room for code-out interpretation. There are quite a few places where interesting animations, transitions, transforms, and interactions could be built in. Heck, this thing could also be built responsibly... I mean responsively... I mean both ;)

Be sure to read Reagan’s post to get the low down on his illustration process. We’re all very excited to see what people come up with. Happy front-ending!

p {
-webkit-hyphens: auto;
-moz-hyphens: auto;
hyphens: auto;
}

During a day or so of road testing I noticed some pretty funky widows, so I fine-tuned my stylesheet to only target narrow columns, like the ones on my info page, which is a scenario where CSS hyphenation really comes in handy. Overall, I’m not sure what to think about fluid columns and widows—they’re bound to show up at varying widths. I try to avoid them at my defined max-width, but have plans to test the wp-Typography plugin in a responsive setting once we perform some server upgrades for the blog (taking our old Media Temple DV from php 4 to 5). I’ll be sure to report back when we get there.

Update (9/21/11): I’m happily using the wp-Typography plugin to prevent widows now that our servers have been upgraded. Things seem to be reflowing smoothly in my responsive layout. This plugin has loads of features, hyphenation, spacing control, character replacement, etc., that I’ll be experimenting with further soon.

Note: If you’re on any responsive width other than 100% (full), the masked shadows won’t line up. That got me thinking: wouldn’t it be cool if you could scale masked images like you can background images? Maybe it’d look a little something like: mask-image-size:100%;

Thanks to The League of Movable Type and Tyler Fink for providing Ostrich, the font used in the design.

]]> http://trentwalton.com/2011/06/01/more-css-mask-image-text/feed/ 6 http://trentwalton.com/2011/05/19/mask-image-text/ http://trentwalton.com/2011/05/19/mask-image-text/#comments Thu, 19 May 2011 16:43:32 +0000 Trent http://trentwalton.com/?p=4398 Read more →]]> I recently wrote about Controlling Web Typography and focused on CSS pseudo selectors & down-to-the-letter control. As a web designer, I want the same level of control over type that print designers have, including texture. There are currently 2 webkit CSS properties that I’ve grown to love and hope gain more traction & browser support. My favorite would have to be background-clip:text, but it currently degrades poorly. A close second is mask-image, which you can apply to text.

In the example below I’ve implemented a subtle grey flecked texture effect over the white text. Hover over the box to see how it will degrade in non-supporting browsers. The texture simply won’t show up until (fingers crossed) the property is supported by all browsers.

Here’s the CSS code with all the structural bits trimmed out:
.mask-box h3, .mask-box p{
-webkit-mask-image: url(/path/to/mask.png);
-o-mask-image: url(/path/to/mask.png);
-moz-mask-image: url(/path/to/mask.png);
mask-image: url(/path/to/mask.png);
text-shadow: 0px 0px 30px rgba(30, 28, 28, 0.6);}

In most cases, I prefer subtle amounts of texture / graphic applied to text. The best example of a well used mask-image for type I’ve ever seen is this event page designed by Matthew Smith of Squared Eye and built by Michael Meyer. The “A Night for Adoption” headline is selectable and it’s got rays of sun shining through. Magical!

As you use and join the chorus to get CSS3 properties more widely accepted, don’t forget about background-clip:text and mask-image. When these properties are combined with web fonts, enhanced CSS pseudo selectors, and CSS transforms, we’ll soon be all out of reasons to resort to image replacement for beautiful type on the web.

We’d love your feedback—if there’s anything you’d like us to dig into specifically during the workshop, comment & let us know.

Just as we’ve moved beyond Helvetica and Times New Roman, we’ve begun to think about web type in finer detail than <h1> or <span> tags currently (semantically) allow. For example, when Dave Rupert and I prepared to markup the 3 sites for the Lost World’s Fairs project, we saw elements in each design that would require an excessive number of <span> tags to target words, even letters, at a time.

Ideally, CSS selector pseudo classes or elements would work, but even with options like :nth-child and ::first-letter we wouldn’t be able to target all that we needed.  As eager as we were to dive into building these beautifully designed pages, we couldn’t help but realize two things:

1. We needed more control over letters, words, and lines than CSS currently provided for.
2. The markup was going to be extremely difficult to manage because wrapping individual letters in <span> tags would get messy quick.

An hour later Dave came back with the best solution we could think of: a simple jQuery plugin that injected <span> tags around letters, words, or lines within any declared element. Lettering.js let us build out & revise the pages, saving heaps of code as well as grunt work. It was such a lifesaver that we decided to share it with the web community, launching letteringjs.com late fall 2010.

Lettering.js was well-received, though there are a few valid criticisms that I’d like to briefly address:

If you buy good fonts, they don’t need to be kerned.
That may be, but some fonts do, and the thinking behind Lettering.js goes beyond kerning into overall control. What if web designers want to use italics, font-size, or even change font-family within an element?

Lettering.js isn’t the only way.
True, and it isn’t the ultimate solution either. Let’s consider our options from most problematic to least:

1. Embed an image
2. Use CSS image replacement
3. Wrap letters or words in <span> tags
4. Use JS to inject <span> tags after the markup as we have with Lettering.js

Even though the <span> tags aren’t in the markup, there’s still bloat.
This is true. While Lettering.js keeps the source HTML clean, it doesn’t do the DOM any favors and inserts quite a bit of code.

Load times are increased. Javascript libraries are loaded just to target a few words or letters.
Again, consider the alternatives.  An image could easily outweigh javascript code.  On the other hand, yes, it’d be ideal to do this independently from JS.

Can we replace Lettering.js with CSS?

I hope so. Lettering.js is a solution, but perhaps it’s not the ultimate solution. As I mentioned earlier, CSS Selectors come close. What if the CSS spec was adapted to fill in the gaps? After scouring the internet, here’s a brief timeline recounting what’s already been discussed.

The W3C proposed Cascading Style Sheets, level 1 (CSS1) featuring the ::first-letter and ::first-line pseudo selectors.

Anne Van Kesteren explored the idea of expanding selectors to cover ::nth-line(n) and ::nth-letter(n).

Safari 1.3 was released as the first browser to fully support both the ::first-letter and ::first-line pseudo selectors. It’s worth mentioning that prior to this, IE5.5+ (July 2000 ) and Firefox 1 (November 9, 2004 )  had partial/buggy support for these selectors.

An extensive (50+ message) CSSWG thread on Proposed ::last-line and ::last-letter selectors was started by Andrés Delfino. The feasibility was discussed at length, and rejected due to narrow user base and high cost / complexity.

At the time, this thread had trouble coming up with good use cases. With the expansion of pseudo selectors & available web fonts, good use cases are now everywhere. The discussion focused heavily on ::last-line & ::last-letter which may not be particularly useful.

Dave Rupert built Lettering.js as a workaround.  Version 0.6.1 has been downloaded 1500 times, with 550 watchers on Github, indicating that alongside the growth of web fonts, the ‘narrow user base’ is widening rapidly.

From CSS1, we’ve been able to use pseudo-elements to target ::first-letter.  What if you extended that idea to targeting letters, or even words, within an element similar to the CSS3 ::nth-child(n) selector, resulting in something like this:

h1:nth-letter(4); or h1:nth-char(4);
targeting the 4th letter within an <h1> tag.

h1:nth-word(3);
targeting the third word within an <h1> tag.

I think this would be the ideal solution from a web designer’s perspective. No javascript would be required, and 100% of the styling would be handled right where it should be- in the CSS. On the other hand, I have no idea what goes into implementing these additions for a browser, which is why the idea has been proposed as a blog post with comments. Please, feel free to share your own thoughts about how we can gain more typographic control on the web.