Categories
Browsers Microsoft Standards State of the Web type Web Design Web Design History Web Standards webkit

IE9 preview

Is it getting hot in here? Or is it just the flames?

In An Early Look At IE9 for Developers, Dean Hachamovitch, General Manager for Internet Explorer, reports on performance progress, web standards progress (border-radius, bits of CSS3, Acid 3 performance), and “bringing the power of PC hardware and Windows to web developers in the browser” (e.g. improved type rendering via Direct2D, a Windows sub-pixel rendering technology that replaces Cleartype).

The reported web standards improvements are encouraging, and better type rendering in IE is a consummation much to be desired. These positive notes notwithstanding, what is most interesting about the post is the political tightrope Microsoft team leaders are still forced to walk.

The world has moved to web standards, and Microsoft knows it must at least try to catch up. Its brilliant browser engineers have been working hard to do so. This web standards support is not optional: having just been spanked hard in Europe for anticompetitive practices, Microsoft knows it is no longer invincible, and cannot continue to use claims of innovation to stifle the overall market or drag its feet on advanced standards compliance.

At the same time, Microsoft’s marketing department wants the public to believe that IE and Windows are profoundly innovative. Thus efforts to catch up to the typographic legibility and beauty of Mac OS X and Webkit browsers are presented, in Dean Hachamovitch’s blog post, as leading-edge innovations. Don’t get me wrong: these improvements are desirable, and Direct2D may be great. I’m not challenging the quality of the hardware and software improvements; I’m pointing out the enforced bragging, which is mandated from on high, and which flies in the face of the humble stance other high-level divisions in Microsoft would like to enforce in the wake of the company’s European drubbing and the dents Apple and Google have made on its monopoly and invulnerability.

In short, the tone of these announcements has not changed, even though the times have.

Hachamovitch does an admirable job of sticking to the facts and pointing out genuine areas of interest. But he is stuck in a corporate box. A slightly more personal, down-to-earth tone would have come across as the beginnings of transparency—Web 1.1, if not Web 2.0—and a more transparent tone might have slightly reduced the percentage of flamebait in the post’s comments. (It could only have slightly reduced that percentage, because, on the internet, there is no such thing as a calm discussion of improvements to a Microsoft browser, but still.)

Although I disagree with the tone of many of the comments—rudeness to engineers is not admirable, kind, or helpful—I agree with the leading thoughts they express, which are:

  • Getting IE fully up to speed on web standards is much more important than introducing any proprietary innovations. (Naturally I agree with this, as it is, in a nutshell, what The Web Standards Project told browser companies back in 1998—and it is still true.)
  • Switching to Webkit might be a better use of engineering resources than patching IE.

On the other hand, Microsoft’s refusal to switch to Webkit gives Apple and Google a competitive advantage, and that is good because a web in which one browser has a monopoly stifles standards and innovation alike. By torturing the IE rendering engine every couple of years instead of putting it out of its misery, Microsoft contributes to the withering away of its own monopoly. That might not be good for the shareholders, but it is great for everyone else.

Categories
Accessibility Adobe Advocacy Apple Design Flash Formats HTML HTML5 ipad Web Design Web Design History Web Standards

Betting on the web

Must-read analysis at Daring Fireball anatomizes the “war” between Flash and web standards as a matter of business strategy for companies, like Apple and Google, that build best-of-breed experiences atop lowest-common-denominator platforms such as the web:

It boils down to control. I’ve written several times that I believe Apple controls the entire source code to iPhone OS. (No one has disputed that.) There’s no bug Apple can’t try to fix on their own. No performance problem they can’t try to tackle. No one they need to wait for. That’s just not true for Mac OS X, where a component like Flash Player is controlled by Adobe.

I say what Apple cares about controlling is the implementation. That’s why they started the WebKit project. That’s why Apple employees from the WebKit team are leaders and major contributors of the HTML5 standards drive. The bottom line for Apple, at the executive level, is selling devices. … If Apple controls its own implementation, then no matter how popular the web gets as a platform, Apple will prosper so long as its implementation is superior.

Likewise with Google’s interest in the open web and HTML5. … So long as the web is open, Google’s success rests within its own control. And in the same way Apple is confident in its ability to deliver devices with best-of-breed browsing experiences, Google is confident in its ability to provide best-of-breed search results and relevant ads. In short, Google and Apple have found different ways to bet with the web, rather than against the web.

Related posts, on the off-chance you missed them:


Categories
Adobe Apple development Flash Google ipad Web Design Web Design History Web Standards

Ahem

The first part of my post of 1 February was not an attack on Flash. It described a way of working with Flash that also supports users who don’t have access to Flash. I’ve followed and advocated that approach for 10 years. It has nothing to do with Apple’s recent decisions and everything to do with making content available to people and search engines.

It’s how our agency and others use Flash; we’ve published articles on the subject in our magazine, notably Semantic Flash: Slippery When Wet by Daniel Mall.

We do the same thing with JavaScript—make sure the site works for users who don’t have JavaScript. It’s called web development. It’s what all of us should do.

My point was simply that if you’re an all-Flash shop that never creates a semantic HTML underpinning, it’s time to start creating HTML first—because an ever-larger number of your users are going to be accessing your site via devices that do not support Flash.

That’s not Apple “zealotry.” It’s not Flash hate. It’s a recommendation to my fellow professionals who aren’t already on the accessible, standards-based design train.


THE SECOND PART OF MY POST wasn’t Flash hate. It was a prediction based on the way computing is changing as more people at varying skill levels use computers and the internet, and as the nature of the computer changes.

There will probably always be “expert” computer systems for people like you and me who like to tinker and customize, just as there are still hundreds of thousands of people who hand-code their websites even though there are dozens of dead-simple web content publishing platforms out there these days.

But an increasing number of people will use simpler computers (just as we’ve seen millions of people blog who never wrote a line of HTML).


THE THIRD PART OF MY POST wasn’t Flash hate. It was an observation that Google and Apple, as companies, have more to gain from betting on HTML5 than from pinning their hopes to Adobe. That’s not a deep insight, it’s a statement of the obvious, and making the statement doesn’t equate to hating Adobe or swearing allegiance to Google and Apple—any more than stating that we’re having a cold winter makes me Al Gore’s best friend.

(Although I like Gore, don’t get me wrong. I also like Apple, Google, and Adobe. My admiration for these companies, however, does not impede my ability to make observations about them.)


THE THIRD PART OF MY POST ALSO WASN’T a blind assertion that HTML5, with VIDEO and CANVAS, is ready to replace Flash today, or more adept than Flash, or more accessible than Flash. Flash is currently more capable and it is far more accessible than CANVAS.

We have previously commented on HTML5’s strengths and weaknesses (Exhibit A, Exhibit B, Exhibit C) and are about to publish a book about HTML5 for web designers. HTML5 is rich with potential; Flash is rich with capability and can be made highly accessible.

That it is unstable on Mac and Linux is one reason Apple chose not to include it in its devices; that this omission will change the way some developers create web content is certain. If the first thing it does is encourage them to develop semantic HTML first, that’s a win for everyone who uses the web.

Carry on.


Categories
Acclaim Advocacy Appearances better-know-a-speaker content creativity CSS Design HTML Interviews speaking The Profession User Experience Web Design Web Design History Web Standards Zeldman

Laying Pipe

The Pipeline inaugural podcast

Dan Benjamin and yours truly discuss the secret history of blogging, transitioning from freelance to agency, the story behind the web standards movement, the launch of A Book Apart and its first title, HTML5 For Web Designers by Jeremy Keith, the trajectory of content management systems, managing the growth of a design business, and more in the inaugural episode of the Pipeline.


Categories
spec Standards State of the Web Tools Web Design Web Design History Web Standards webfonts webtype writing Zeldman

Real Fonts and Rendering: The New Elephant in the Room

My friend, the content strategist Kristina Halvorson, likes to call content “the elephant in the room” of web design. She means it’s the huge problem that no one on the web development team or client side is willing to acknowledge, face squarely, and plan for….

Without discounting the primacy of the content problem, we web design folk have now birthed ourselves a second lumbering mammoth, thanks to our interest in “real fonts on the web“ (the unfortunate name we’ve chosen for the recent practice of serving web-licensed fonts via CSS’s decade-old @font-face declaration—as if Georgia, Verdana, and Times were somehow unreal).…

Put simply, even fonts optimized for web use (which is a whole thing: ask a type designer) will not look good in every browser and OS.

Zeldman

Jeffrey Zeldman, Real Fonts and Rendering: The New Elephant in the Room
22 December, 2009
24 ways: The Advent Calendar for Web Developers


Short URL: zeldman.com/?p=3319

Categories
Blue Beanie Day Code Community Design Education engagement Web Design Web Design History Web Standards

Blue Beanie Day 2009

International Blue Beanie Day 2009

Bonne journée du chapeau bleu! Now you know how to say “Happy Blue Beanie Day” in French.

Monday 30 November is International Blue Beanie Day in support of web standards. Get your toque on, post a photo, and pop a beanie on your Twitter, Flickr, and Facebook avatars to help spread the word. Let’s take this viral, kids!

Short URL: zeldman.com/?p=3142

Categories
Blue Beanie Day HTML HTML5 Standards Web Design Web Design History Web Standards XHTML Zeldman

A Zing Too Far

Fred Blasdel said:

You’ll always draw ire for having stumbled into being the Chief of the cargo-cult side of Web Standards, with so-called ‘XHTML’ as the false idol. You did a lot of good, but not without ambiguating the nomenclature with a lot of feel-good bullshit.

You often find yourself as a mediator between designery folks (who you have a strong grasp over) and technical implementors (who will always hold a grudge against you for muddying the discourse). Asking people to wear blue toques does not particularly affect this balance.

“Cargo cult.” I love that phrase. But I’m not sure I agree with your assessment.

XHTML, with its clearer and stricter rules, came out just as many of us were rediscovering semantic markup and learning of its rich value in promoting content. It wasn’t a coincidence that we took this W3C specification seriously and helped promote it to our readers, colleagues, etc. The stricter, clearer rules of XHTML 1.0 helped enforce a new mindset among web designers and developers, who had previously viewed HTML as an “anything goes” medium (because browsers treated it that way, still do, and quite probably always will; indeed HTML5 codifies this, and that’s not necessarily a bad thing).

Future versions of XHTML became a dead-end not because there was no value in strict, semantic, structural markup, but because the people charged with moving XHTML forward lost touch with reality and with developers. This is why HTML5 was born.

That’s history and it’s human behavior. But those subsequent twists and turns in the story don’t mean that standardistas who supported XHTML 1.0 (or still do) and who used it as a teaching tool when explaining semantic markup to their colleagues were wrong or misguided to do so.

That some technical people in the standards community think we were wrong is known, but their belief does not make it so.

That a handful of those technical people express their belief loudly, rudely, and with belligerent and unconcealed schadenfreude does not make their point of view true or persuasive to the rest of us. It just makes them look like the close-minded, socially maladroit, too-early-toilet-trained, tiny-all-male-world-inhabiting pinheads they are.

Short URL: zeldman.com/?p=3108

Categories
Fonts Web Design History Web Standards Web Type Day webfonts webtype

FontShop Fonts on the Web

Zeldman

FontShop announces that they are ready to deliver their font library as web type:

[S]tarting today, Typekit users can pick from dozens of FontFonts, including FF Meta, FF Dax, and FF Netto. Plus, the Typekit service lets you test any of those FontFonts on your page before you publish.

And tomorrow?

Typekit is just one piece of a holistic strategy for FontFonts on the web. The library should be licensable in a more traditional way too. That’s where WOFF fits in. … Soon anyone will be able to license and download for their website the same professional quality FontFont they use in desktop applications, but crafted specifically for the new medium.

Hat tip: Jason Santa Maria

This has been a belated part of Web Type Day.


Short URL: zeldman.com/?p=3023

Categories
better-know-a-speaker creativity CSS Design Fonts industry Press Real type on the web Standards State of the Web Web Design Web Design History Web Standards Web Type Day webfonts webtype

Web Type: Lupton on Zeldman

Designing With Web Standards

Today in Print, Ellen Lupton interviews Jeffrey Zeldman (that’s me) on web typography, web standards, and more. Part one of a two-part interview.

Ellen Lupton is curator of contemporary design at Cooper-Hewitt, National Design Museum in New York City and director of the Graphic Design MFA program at Maryland Institute College of Art (MICA) in Baltimore. She is the author of numerous books and articles on design, a frequent lecturer, and an AIGA Gold Medalist.

This has been a nutritious part of Web Type Day.

Short URL: zeldman.com/?p=2932

Categories
editorial Education HTML HTML5 Web Design History Web Standards

HTML5 Redefines Footer

It seems like only yesterday that the HTML5 Super Friends asked the HTML5 working groups to rethink footer’s content model to avoid web developer misuse and frustration. Okay, it wasn’t yesterday, it was Monday. Close enough. Today comes word that footer is indeed being redefined as we requested. This is a wonderful usability improvement to HTML5, and we salute the working group(s) for listening and acting.

Categories
editorial Education HTML HTML5 Web Design History Web Standards

HTML5 For Smarties

The HTML5 specification runs on for over 900 pages, and much of what it covers, while vital to browser makers, is meaningless to people who create websites. If thousands of irrelevant details in the HTML5 spec have you crossing your eyes and crying for Mama, Michael™ Smith’s HTML 5: The Markup Language is just what the HTML5 doctor ordered: lean, clean, and content-author-focused. Until there’s a plain-language HTML5 Pocket Guide, Smith’s edited presentation of the spec will do. (It’s also available in a single page format.)

ShortURL: zeldman.com/?p=2561

Categories
Design HTML HTML5 spec Standards State of the Web Web Design Web Design History Web Standards

Loving HTML5

Half of standards making is minutia; the other half is politics. Rightly or wrongly, I’ve long suspected that Atom was born, not of necessity, but because of conflicts between the XML crowd and the founders of RSS. Likewise, rightly or wrongly, I reckoned HTML5 was at least partly Hixie’s revenge against XHTML served as text/html.

And then a funny thing happened. Some friends and I gathered at Happy Cog’s New York studio to hash out the pros and cons of HTML5 from the perspective of semantic-markup-oriented web designers (as opposed to the equally valid perspectives of browser engineers and web application developers—the two perspectives that have primarily driven the creation of HTML 5).

Our first task was to come to a shared understanding of the spec. During the two days and nights we spent poring over new and changed semantic elements, we discovered that many things we had previously considered serious problems were fixable issues related to language.

Easy language problems

Some of these language problems are trivial indeed. For instance, on both the WHATWG and W3C sites, the specification is sometimes called “HTML 5” (with a space) and sometimes called “HTML5” (with no space). A standard should have a standard name. (Informed of this problem, Hixie has removed the space everywhere in the WHATWG version of the spec.)

Likewise, as an end-user, I found it confusing to be told that there is an “HTML5 serialization of HTML 5,” let alone an “XHTML 5 version of HTML5.” I requested that the two serializations be referred to as “HTML” and “XHTML”—emphasizing the distinction between the two kinds of syntax rather than drawing needless attention to version numbers. (Again, Hixie promptly updated the spec.)

Names and expectations

Some language problems are tougher—but still eminently fixable, because they are language problems that mar the presentation of good ideas, not bad ideas that require rethinking.

For example, in order to choose suitable names for the new semantic elements in HTML 5, Hixie analyzed classnames on thousands of websites to see what web designers and developers were already doing. If many designers and developers use classnames like “header” and “footer” to contain certain kinds of content, then HTML 5 should use these labels, too, Hixie and his colleagues reasoned. Doing so would make the purpose of the new elements intuitively obvious to working web professionals, removing the learning curve and encouraging proper element use from the get-go.

It’s a beautiful theory that comes straight out of Bert Bos’s W3C Design Principles. There’s just one problem. Header, and especially footer, behave differently from what their names will lead web designers and developers to expect. Developers will use it for the footer of the page—not for the footer of each section. And they will be frustrated that the footer in HTML5 forbids navigation links. After all, the footer at the bottom of web pages almost always includes navigation links.

To avoid misuse and frustration, the content model of footer should change to match that of header, so that it may be used concurrently as a template level element (the expected use) and a sub-division of section (the new use). Alternately, the element’s name should be changed (to almost anything but “footer”). Expanding the content model is clearly the better choice.

For the love of markup

HTML5 is unusual in many ways. Chiefly, it is the first HTML created in the time of web applications. It is also the first to be initiated outside the W3C (although it now develops there in parallel).

Not surprisingly in a specification that goes on for 900 pages, there are at least a dozen places in HTML5 where a thoughtful standardista might request clarification, suggest a change, or both. My friends and I have taken a stab at this ourselves, and will soon publish our short list of recommendations and requests for clarification.

Nevertheless, the more I study the direction HTML5 is taking, the better I like it. In the words of the HTML5 Super Friends, “Its introduction of a limited set of additional semantic elements, its instructions on how to handle failure, and its integration of application development tools hold the promise of richer and more consistent user experiences, faster prototyping, and increased human and machine semantics.”

Update

[4:47 PM EST] Calling all cars! The HTML5 Super Friends declaration of support is now live, as is the Super Friends Guide to HTML5 Hiccups (i.e. our technical recommendations).

ShortURL: zeldman.com/?p=2438

Categories
Design Fonts Web Design Web Design History Web Standards webfonts webtype

Web fonts and standards

AS FAR back as 1998, CSS2 provided a way to link to real fonts from your style sheet:


  @font-face {
  font-family: "Watusi";
  src: url("http://www.example.com/fonts/watusi.ttf")
  format("truetype");
	}

  h1 {
  font-family: "Watusi", sans-serif;
	}


Instead of static pictures of fonts, linked font files can be retrieved from the web and used to display HTML text. And not just for headlines, but for body copy, too. It’s brilliant! It’s magnificent! There are just two problems:

  • Unless they are specifically licensed for web use (and few fonts are), if you embed fonts you own on a web page, you may be violating your End User Licensing Agreement (EULA) with the font foundry.
  • While Safari (and other Webkit browsers, including Google Chrome), Opera, and Firefox support @font-face for TrueType (TTF) and OpenType (OTF) fonts, guess which browser does not? That’s right, Internet Explorer. That’s not because IE is technically inferior to the other browsers. Rather, it’s because Microsoft does not wish to provide technology that might infringe on the rights of type designers. Instead, Microsoft supports @font-face only for the Embedded OpenType (EOT) format—which Microsoft itself invented. EOT discourages the copying of copyrighted font files via encryption, “subsetting” (using only needed characters rather than the entire font), and other techniques. Microsoft has supported EOT—and proposed it as a W3C standard—since IE4 was young. No other browser maker supports EOT.

The Tan method and IE

It’s the perennial web standards problem, but until Microsoft joins the party, Jon Tan offers a commendable workaround, combining standard @font-face with EOT served via IE conditional comments. It’s a hack, perhaps, but a clean one—and one that even Microsoft would approve. Nice work, Jon Tan. That’s one hurdle cleared.

The licensing hurdle

Type foundries are on the verge of agreeing to standards that will protect their rights and enable designers to embed real fonts on their web pages via standard CSS. They are on the verge, but not there yet. Competing proposals include Erik van Blokland and Tal Leming’s .webfont, a compressed format containing XML and font data; Ascender’s EOT Lite, which removes the chief objections to Microsoft’s EOT while still working in IE; and David Berlow’s OpenType Permissions and Recommendations Table, a mechanism for showing that the designer has paid for the right to use a particular font on a particular domain.

Using @font-face in all browsers today

Some of these methods work already. For instance, on Font Bureau’s website, you will soon be able to buy a web- and print-licensed version of one of their fonts for 20% more than a print-only-licensed version, and embed it on a given domain via @font-face. It will be legally licensed, and it will work in Safari, Firefox, and Opera. It will even work in IE, if you use Jon Tan’s workaround.

Rise of the middlemen

Until type designers agree to a standard and all browsers support @font-face embedding of TrueType and OpenType fonts, “middleman” platforms such as Typekit and Typotheque will make real web fonts possible by handling licensing and technological hassles.

As nearly all of you reading this know, here’s how it works: First, companies like Typekit get font vendors to sign on. The companies agree to license their fonts through Typekit. Designers pay a monthly fee to Typekit for arranging the license and hosting the fonts. Typekit also provides a technology solution, ensuring that the fonts show up in browsers that support standard font formats via @font-face (Safari, Firefox, Opera) as well as the one that does not (Internet Explorer).

Worth noting is that Typekit is font foundry agnostic, welcoming all, whereas Typotheque is a foundry-specific solution. The wizards at Clearleft have their own middleman platform in the works. All these solutions are currently in beta.

As of this writing, their pricing models are unknown—and price is sure to have an impact on acceptance.

Moreover, by definition, no web font middleman (or font developer, like Typotheque) offers every font you could wish for, and ultimately, designers will only choose a service that provides fonts they wish to use. Nor is it yet known whose technical solution will be best, whose font file will load fastest, how reliable each hosting platform will be as usage scales up, and so on.

The effect of font services on web standards

It remains to be seen whether a font-licensing standard and universal browser support for @font-face will kill the middlemen, or whether the middlemen will prove so successful that they delay or stifle the adoption of a font-licensing standard and allow Microsoft to shrug its shoulders indefinitely at supporting @font-face for anything beyond its proprietary EOT file format.

There is also the possibility that the middlemen, by increasing acceptance of web fonts, will hasten the arrival of a licensing standard—and that this will, in turn, prompt Microsoft to support @font-face for any licensed font.

ShortURL: zeldman.com/x/54

Categories
Advocacy Applications architecture Browsers Code Compatibility creativity CSS Design DOM Markup spec Standards State of the Web W3C Web Design Web Design History Web Standards wisdom

Why Standards Fail

Back in 2000, CSS co-creator Bert Bos set out to explain the W3C’s design principles—“to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, [and] longevity….”

Eventually published in 2003, the essay, although ostensibly concerned with explaining W3C working group principles to the uninitiated, actually articulates the key principle that separates great design from the muck we normally wade through. It also serves as a warning to Bert’s fellow W3C wizards not to seek the dark magic of abstract purity at the expense of the common good. Tragically for these wizards, and for we who use their technologies, it is a warning some developers of W3C specifications continue to overlook.

Design is for people

In his introduction, Bert summarizes the humanistic value that is supposed to be at the core of every web standard:

Contrary to appearances, the W3C specifications are for the most part not designed for computers, but for people. … Most of the formats are in fact compromises between human-readability and computer efficiency….

But why do we want people to read them at all? Because all our specs are incomplete. Because people, usually other people than the original developers, have to add to them….

For the same reason we try to keep the specifications of reasonable size. They must describe a useful chunk of technology, but not one that is too large for an individual to understand.

Over the succeeding 25 web pages (the article is chunked out in pamphlet-sized pages, each devoted to a single principle such as “maintainability” and “robustness”) Bert clearly, plainly, and humbly articulates a series of rather profound ideas that are key to the web’s growth and that might apply equally admirably to realms of human endeavor beyond the web.

For instance, in the page entitled “Use What Is There,” Bert says:

The Web now runs on HTML, HTTP and URLs, none of which existed before the ’90s. But it isn’t just because of the quality of these new formats and protocols that the Web took off. In fact, the original HTTP was a worse protocol than, e.g., Gopher or FTP in its capabilities….

And that fact shows nicely what made the Web possible at all: it didn’t try to replace things that already worked, it only added new modules, that fit in the existing infrastructure. …

And nowadays (the year 2000), it may look like everything is XML and HTTP, but that impression is only because the “old” stuff is so well integrated that you forget about it: there is no replacement for e-mail or Usenet, for JPEG or MPEG, and many other essential parts of the Web.

He then warns:

There is, unfortunately, a tendency in every standards organization, W3C not excluded, to replace everything that was created by others with things developed in-house. It is the not-invented-here syndrome, a feeling that things that were not developed “for the Web” are somehow inferior. And that “we” can do better than “them.” But even if that is true, maybe the improvement still isn’t worth spending a working group’s resources on.

Shrinkage and seduction

In his gentle way, Bert seems to be speaking directly to his W3C peers, who may not always share his and Håkon‘s humanism. For, despite what designers new to CSS, struggling for the first time with concepts like “float” and the box model may think, Bert and Håkon designed the web’s layout language to be easy to learn, teach, implement, maintain, and (eventually) extend. They also designed CSS not to overwhelm the newcomer with advanced power at the cost of profound complexity. (“CSS stops short of even more powerful features that programmers use in their programming languages: macros, variables, symbolic constants, conditionals, expressions over variables, etc. That is because these things give power-users a lot of rope, but less experienced users will unwittingly hang themselves; or, more likely, be so scared that they won’t even touch CSS. It’s a balance.”)

This striving to be understood and used by the inexperienced is the underlying principle of all good design, from the iPhone to the Eames chair. It’s what Jared Spool would call usability and you and I may consider the heart of design. When anything new is created, be it a website, a service, or a web markup language, there is a gap between what the creator knows (which is everything about how it’s supposed to work), and what you and I know (which is nothing). The goal of design is to shrink this ignorance gap while seducing us into leaping across it.

What were once vices are now habits

You can see this principle at work in CSS, whose simplicity allowed us to learn it. Although we now rail against the limitations of CSS 1 and even CSS 2.1, what we are really complaining about is the slow pace of CSS 3 and the greater slowness with which browser makers (some more than others) adopt bits of it.

Note that at one time we would have railed against browser makers who implemented parts of a specification that was still under development; now we admire them. Note, too, that it has taken well over a decade for developers to understand and browsers to support basic CSS, and it is only from the perspective of the experienced customer who craves more that advanced web designers now cry out for immediate CSS 3 adoption and chafe against the “restrictions” of current CSS as universally supported in all browsers, including IE8.

If CSS had initially offered the power, depth, and complexity that CSS 3 promises, we would still be designing with tables or Flash. Even assuming a browser had existed that could demonstrate the power of CSS 3, the complexity of the specification would have daunted everyone but Eric Meyer, had CSS 1 not come out of the gate first.

The future of the future of standards

It was the practical simplicity of CSS that enabled browser engineers to implement it and tempted designers to use (and then evangelize) it. In contrast, it was the seeming complexity and detachment from practical workaday concerns that doomed XHTML 2, while XHTML 1.0 remains a valid spec that will likely still be working when you and I have retired (assuming retirement will be possible in our lifetime—but that’s another story).

And yet, compared to some W3C specs in progress, XHTML 2 was a model of accessible, practical, down-to-earth usability.

To the extent that W3C specifications remain modular, practical, and accessible to the non-PhD in computer science, they will be adopted by browser makers and the marketplace. The farther they depart from the principles Bert articulated, the sooner they will peter out into nothingness, and the likelier we are to face a crisis in which web standards once again detach from the direction in which the web is actually moving, and the medium is given over to incompatible, proprietary technologies.

I urge everyone to read “What is a Good Standard?“, and I thank my friend Tantek for pointing it out to me.

[tags]W3C, design, principles, bertbos, maintainability, accessibility, extensibility, learnability, simplicity, specs, standards, css, markup, code, languages, web, webdesign, webstandards, webdevelopment, essays[/tags]

Categories
Browsers CSS Design Fonts Real type on the web spec Standards Typography Web Design Web Design History Web Standards webfonts webtype

Web Fonts Now, for real

David Berlow of The Font Bureau has proposed a Permissions Table for OpenType that can be implemented immediately to turn raw fonts into web fonts without any wrappers or other nonsense. If adopted, it will enable type designers to license their work for web use, and web designers to create pages that use real fonts via the CSS @font-face standard.

My April 21, 2009 A List Apart interview with Berlow explains how a permissions table would enable type designers to support @font-face without DRM or intermediary hosted licensing. A press release provides more detail:

Future web users will not want their browsers clogging the workings of their Operating Systems with fonts, or the browsers’ presenting the users with web content that the user cannot read. In addition, web users do not want imprecisely or un-aesthetically presented content where a simple type-bearing graphic would suffice. Lastly, users do not want fonts to be able to give fraudulent users the unique corporate appearance of a genuine company.

So far, the browsers allowing use of the @Font-face font linking are installing and removing fonts in an invisible way, but future browsers may need to more intelligently manage web fonts for users as more sites employ them. Here, the proposed table can help by containing the links from which the fonts came, and determining their cacheability based on the user’s browsing history. More importantly, the recommendations section of the proposed table could allow a browser to offer reconcileablilty of any font treatment in conflict with a user’s ‘preferenced’ desires in areas such as sizing of type, presentation of line length and potentially dangerous type treatments such as rapid text blinking.

The Permissions Table proposal will be announced tomorrow on newsgroups and forums frequented by type designers.

Read more

  • Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
  • Web Fonts Now (How We’re Doing With That): Everything you ever wanted to know about real fonts on the web, including commercial foundries that allow @font-face embedding; which browsers already support @font-face; what IE supports instead; Håkon Wium Lie, father of CSS, on @font-face at A List Apart; the Berlow interview at A List Apart; @font-face vs. EOT; Cufón; SIFR; Cufón combined with @font-face; Adobe, web fonts, and EOT; and Typekit, a new web service offering a web-only font linking license on a hosted platform; — 23 May 2009

[tags]@font-face, berlow, davidberlow, CSS, permissionstable, fontbureau, webfonts, webtypography, realtypeontheweb[/tags]