I’m going to especially focus on ::first-line and ::first-letter pseudo-elements which, to my surprise, WebKit has some massive problems with. Specifically:

• WebKit does not accept text-transform on the ::first-line pseudo element. This embarrassing bug is almost 6 years old and means that the common typographic practice of setting the first line of a paragraph in all-caps is impossible in Safari, Chrome, and—insanely—iBooks, which uses WebKit for its ebook rendering. The closest you can get is font-variant: small-caps which would work fine if we could also use text-transform: lowercase, but we can’t.
• WebKit also doesn’t accept a font-family rule in both the ::first-letter and ::first-line pseudo-elements. The latter is usually OK, but the former really sucks. Even worse, in both cases, a font-family rule will cause them to fall back to the system font!
• WebKit has a bug where modifying the DOM of an element that has a ::first-letter CSS rule attached will result in a phantom first letter. See QuirksMode’s test case. (Opera does this too.)

Firefox isn’t all roses either, despite their terrific efforts in bringing long-awaited OpenType features into CSS. The main thing I noticed was that Firefox treats ::first-letter oddly style-wise. It doesn’t seem to behave as a full-fledged block-level element when setting float or display properties. It also compounds the font-size when the ::first-letter coincides with another DOM element that also sets the font-size.

Some other issues:

• WebKit sets its pseudo-small caps (when using font-variant: small-caps) smaller than other browsers. It also seems to add some pseudo-emboldening to better compensate for the fact that they’re not true small caps.
• Inconsistencies between browsers in conforming to the ::first-letter spec for including punctuation characters. Specifically, WebKit only seems to include punctuation that precedes the letter, not punctuation after it.

I’ve created a test page that illustrates a lot of these pain points. I also made a page that demonstrates a WebKit normalization strategy with some UA sniffing and the jQuery fancyletter plugin, which I contributed a small patch to along the way. I’d describe that strategy, but then this post would never be published. View source!

Ethan Dunham of Font Squirrel and Fontspring fame has just released the definitive @font-face syntax. I’ve been hyping it up on my Twitter account, but this is too good to restrict to my followers there. The new syntax is clean, beautiful, and simple. It looks like:

@font-face {
   font-family: 'MyFontFamily';
   src: url('myfont-webfont.eot?') format('eot'),
        url('myfont-webfont.woff') format('woff'),
        url('myfont-webfont.ttf')  format('truetype'),
        url('myfont-webfont.svg#svgFontName') format('svg');
}

Here’s the magic he found:

The hack trick that makes this work is the ‘?’ following the EOT filename. Seriously.

Just awesome. Great work Ethan!

The short answer is: keep using Paul Irish’s bulletproof smiley syntax. WOFF will be loaded by browsers that understand it, and legacy IE versions (8 and under) will load EOT.

The long answer: every src declaration within the @font-face block effectively resets the CSS parser’s attempt to find the appropriate font file. The rendering engine will use the first viable font source in the last src declaration inside each @font-face block. Paul Irish’s smiley syntax works perfectly here, since the first src declaration is only understood by IE < 9 (due to the EOT format), while the second src declaration is understood by >= IE9 and all other good browsers.

This produces a win-win situation. Good browsers that aren’t IE ignore the first src declaration because EOT is not viable to them. IE9 prefers the second src declaration because it understands EOT.

I have a few test cases to view. They’re also available on Github.

Why it took so long for custom web fonts to become an in-browser reality is a tangled tale involving browser wars, font foundry fears and a general inertia of rest. Many thorny licensing issues remain regarding the use of commercial fonts on the web, which is why there’s been a proliferation of third-party solutions such as TypeKit, Fontdeck and Kernest cropping up.

But there are also headache-free choices such as the excellent free fonts from Jos Buivenga’s exljbris Font Foundry. Since Jos explicitly allows @font-face embedding, this site uses his excellent Delicious font for menus and headings, and will run smoother and faster than ever thanks to ditching sIFR’s Flash dependency.

Not all is sunshine and roses. The iPhone version of Safari has disabled @font-face linking for some reason unknown to me. IE has its own proprietary format that involves acronyms like EOT and WEFT, alongside a high probability of animal sacrifice to appease the demons who designed WEFT. But there is a light at the end of tunnel, and we’ve stepped through it.

Opera has just released (in conjunction with the Yahoo! Web Developer Network) its Opera Web Standards Curriculum, hoping to promote the spread of web standards via a free curriculum. While I am well-versed in web standards, I think that a professional resource such as this is fantastic for educating clients as to why they should redesign their web sites with web standards. Some reasons why are succinctly stated in the introduction:

1. Efficiency of code: As you’ll learn throughout the course, a lot of best practice web standards usage is all about reusing code—you can separate your HTML content from your stylistic (CSS) and behavioural (JavaScript) information, allowing your file sizes to be kept small, and code to be written only once, and then reused wherever it is needed.
2. Ease of maintenance: This follows closely on from the last point—if you can write HTML only once, and then apply styles and behaviour wherever they are needed using classes and functions, then if you need to change something at a later date, you can just make the change in one place and it have it propagate throughout the entire web site, rather than having to specify that change everywhere that it is needed!
3. Accessibility: The next two points are closely related—one of the big issues on the Web is making web sites accessible to everyone, no matter who they are, regardless of circumstance. This includes making web sites usable by people with disabilities such as blindness/visual impairment and motor impairment (ie, people who have restricted movement, and might not be able to use their hands properly, or at all). By using web standards and best practices, you’ll be able to make your web sites usable by this significant group of the web audience with no extra effort.
4. Device compatibility: by this, I mean ensuring that your web sites will work not only across different platforms—ie Windows, Mac, Linux—but also alternative browsing devices, which these days can include mobile phones, TVs and games consoles. These devices have limitations such as screen size, processing power, control mechanisms available and more, but the good news is that again, using web standards and best practices, you can pretty much guarantee that your web sites will work on most of these devices. There are more mobile phones in the world than PCs, a lot of which are Internet–capable, so can you or your clients afford to miss out on this market? For more on mobile web development, check out some of the dedicated articles on dev.opera.com.
5. Web crawlers/search engines: By this, we are talking about what is termed search engine optimization—the practice of making your web sites as visible as possible to the so–called web crawlers that trawl the web and index web sites, and therefore giving you better search rankings on sites such as Google. There is a science to this (see SEO articles such as Intelligent site structure for better SEO! and Semantic HTML and Search Engine Optimization) but yet again, just by using web standards you will make your site a lot more visible on Google, Yahoo! etc, which is good for business.

With 23 articles available and more on the way, Opera’s Web Standards Curriculum looks like a winner!

(HT: Jon Hicks)

I applaud the IE team for listening to developer feedback. Although I defended their previous proposal and tried to make the best of it, I’m much happier about this. Web standards and good development practices will receive another boost, as people will be screaming bloody murder at their broken sites. Developers will be pointed to the meta tag and essentially told, “we’re moving ahead on the web, but we had pity on your 5-year old practices and decided to let you play too.” Designers who don’t know a table from a div will either be forced to learn about (X)HTML, CSS, and JavaScript, or be forced further into irrelevance and obscurity.

IE team, I salute you. You will, undoubtedly, have a lot of ignorant and incompetent developers and designers frothing at the mouth when IE8 releases, but you made the right move.

Here’s my take on things: it’s a mixed bag. It’s an imperfect solution to a horrendous problem. Internet Explorer has the distinction of being the ubiquitous browser on the web, while having the worst web standards support of any browser. It’s a catch-22: if IE’s developers push for quality web standards support in IE 8 (which, by all accounts they are), they will break the many sites out there that were not designed with web standards in mind. Let’s face it: a lot of the web is built only for IE, and people will be confused and outraged if IE 8 breaks their poorly built–but functional–sites. On the other hand, focusing too much on keeping existing sites working will ensure that IE 8 continues to lag far behind in its support for web standards.

So, version targeting is an imperfect solution to an imperfect web. I wish that it wasn’t necessary, but I know that I’ll be using it right alongside my conditional comments and CSS hacks to design sites built on web standards that work in all the major browsers, even if I have to kick the crap out of IE to make it cooperate. Maybe I’ll only have to ask it now.