Just beautiful.
demosthenes.info/blog/961/Big-Beautiful-DropCaps-with-CSS-initial-letter
Tag: Standards
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]
When Apple chose KHTML rather than Mozilla Gecko as the basis for its Safari browser, some of us in the web standards community scratched our heads. Sure, KHTML, the rendering engine in Konqueror, was open-source and standards-compliant. But, at the time, Gecko’s standards support was more advanced, and Gecko-based Mozilla, Camino, and even Netscape 6 felt more like browsers than Konqueror. Gecko browsers had the features, the comparative maturity, and the support of the standards community. Apple’s adoption of KHTML, and creation of a forked version called Webkit, seemed puzzling and wrong.
Yet, thanks largely to the success of the iPhone, Webkit (Apple’s open source version of KHTML) in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. Had Apple chosen Gecko, they might not have been able to so powerfully influence mainstream consumer opinion, because the fully formed, distinctly mature Gecko brand and experience could easily have overshadowed and constrained Apple’s contribution. (Not to mention, tolerating external constraint is not a game Apple plays.)
Just how has mobile Safari, a relative latecomer to the world of standards-based browsing, been able to make a difference, and what difference has it made?
The platform paradox
Firefox and Opera were wonderful before any Webkit-based browser reached maturity, but Firefox and Opera were and are non-mainstream tastes. Most people use Windows without thinking much about it, and most Windows users open the browser that comes with their operating system, again without too much thought. This doesn’t make them dumb and us smart. We are interaction designers; they are not.
Thus, the paradox: even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a comparatively poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. If you knew enough to want Firefox and Opera, those browsers delivered features and experience that confirmed the wisdom of your choice. If you didn’t know to want them, you didn’t realize you were missing anything, because folks reading this page sweated like Egyptian pyramid builders to make sure you had a good experience despite your browser’s flaws.
The power to convert
Firefox and Opera are great browsers that have greatly advanced the cause of web standards, but because they are choices in a space where most people don’t make choices, their power to convert is necessarily somewhat truncated. The millions mostly don’t care what happens on their desktop. It’s mostly not in their control. They either don’t have a choice or don’t realize they have one, and their expectations have been systematically lowered by two decades of unexciting user experience.
By contrast, the iPhone functions in a hot realm where consumers do make choices, and where choices are badges. Of course many people are forced economically to choose the cheap or free phone that comes with their mobile service. But many others are in a position to select a device. And the iPhone is to today’s urban professional gym rat what cigarettes and martinis were to their 1950s predecessors. You and I may claim to choose a mobile device based on its features, but the upwardly mobile (pardon the pun), totally hot person standing next to us in the elevator may choose their phone the same way they choose their handbag. And now that the iPhone sells for $99, more people can afford to make a fashion decision about their phone—and they’ll do it.
Mobile 2.0
Although there were great phones before the iPhone, and although the iPhone has its detractors, it is fair to say that we are now in a Mobile 2.0 phase where people expect more than a Lynx-like experience when they use their phone to access the internet. Mobile Safari in iPhone, along with the device’s superior text handling thanks to Apple and Adobe technologies, is changing perceptions about and expectations of the web in the same way social networking did, and just at the historical moment when social networking has gone totally mainstream.
Oprah’s on Twitter, your mom’s on Twitter, and they’re either using an iPhone or a recently vastly upgraded Palm or Blackberry that takes nearly all of its cues from the iPhone. Devices that copy the iPhone of course mostly end up selling the iPhone, the same way Bravo’s The Fashion Show would mostly make you miss Project Runway if you even watched The Fashion Show, which you probably haven’t.
Safari isn’t perfect, and Mobile Safari has bugs not evident in desktop Safari, but Webkit + Apple = secret sauce selling web standards to a new generation of consumers and developers.
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
- HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
- In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
- XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009
[tags]webdesign, webstandards, design, standards, browsers, CSS, webkit, gecko, mozilla, firefox, opera, safari, mobile, mobilesafari, iphone[/tags]
A “Not Safe for Work” Tag has been proposed for HTML 5:
One of the most common descriptive notes people have to write using text when they post links or images to blogs, comments or anywhere in HTML is to say “this link is not safe for work” or simply “NSFW”. By adding the <NSFW> tag, this could be made much simpler and standardized. Browsers could then have an option to automatically hide all <NSFW> content. A tag is preferred to an attribute since it could then also be used around content and not just links.
Examples:
<nsfw><a href=”http://www.example.com”>Pics here!</a></nsfw>
<nsfw><img src=”badkitten.jpg”></nsfw>
(Via Bruce Lawson)
Drew McLellan of The Web Standards Project thinks it’s a nice idea that won’t work:
@brucel we looked into #nsfw in microformats. It’s an unworkable minefield. #
it’s used when linking to something that you might want to save until you get home. e.g. http://ampleboobies.info (NSFW) #
So a browser could conceivably be configured not to follow links or display content tagged nsfw. Sounds a good idea, but unworkable. #
The use of tags (rather than CSS and JavaScript) to hide or show content is an intriguing and controversial aspect of HTML 5. It’s intriguing because using a standard tag—instead of writing custom CSS and JavaScript that someone else may someday have to maintain—potentially simplifies web development and maintenance, bringing advanced techniques of content presentation to more sites for less money. It’s controversial because it sticks presentation and behavior back in markup, after we all just spent a decade separating site structure and semantics from behavior and presentation.
We’re going to be following these developments and trying to make buzzword-free sense of them for you.
[tags]standards, webstandards, HTML, HTML5, tags, NSFW, W3C[/tags]
I discuss “open source design” in an excerpt from a long interview at Big Think. The full interview, with a complete transcript, will soon be available there as well.
BigThink’s Merrell Hambleton did a great deal of research prior to conducting the hour-long interview, and was thereby able, not only to probe typical Zeldman topics in greater depth, but also to ask interesting questions outside my comfort zone.
The interview was carried out via Interrotron, a fascinating device invented by Errol Morris.
[tags]bigthink, zeldman, design, webdesign, opensource, standards, webstandards, libraries, jeffreyzeldman, interview[/tags]
A proposal for a fonts working group is under discussion at the W3C. The minutes of a small meeting held on Thursday 23 October include a condensed, corrected transcription of a discussion between Sampo Kaasila (Bitstream), Mike Champion (Microsoft), John Daggett (Mozilla), Håkon Wium Lie (Opera), Liam Quin (W3C), Bert Bos (W3C), Alex Mogilevsky (Microsoft), Josh Soref (Nokia), Vladimir Levantovsky (Monotype), Klaas Bals (Inventive Designers), and Richard Ishida (W3C).
The meeting started with a discussion of Microsoft’s EOT (Embedded OpenType) versus raw fonts. Bert Bos, style activity lead and co-creator of CSS, has beautifully summarized the relevant pros and cons discussed.
For those just catching up with the issue of real type on the web, here’s a bone-simple intro:
- CSS provides a mechanism for embedding real fonts on your website, and some browsers support it, but its use probably violates your licensing agreement with the type foundry, and may also cause security problems on an end-user’s computer.
- Microsoft’s EOT (based on the same standard CSS mechanism) works harder to avoid violating your licensing agreement, and has long worked in Internet Explorer, but is not supported in other browsers, is not foolproof vis-a-vis type foundry licensing rules, and may also cause PC security problems.
The proposed fonts working group hopes to navigate the technical and business problems of providing real fonts on the web, and in its first meeting came up with a potential compromise proposal before lunch.
Like everyone these days, the W3C is feeling a financial pinch, which means, if a real fonts working group is formed, its size and scope will necessarily be somewhat limited. That could be a good thing, since small groups work more efficiently than large groups. But a financial constraint on the number of invited experts could make for tough going where some details are concerned—and with typography, as with web technology, the details are everything.
I advise every web designer who cares about typography and web standards—that’s all of you, right?—to read the minutes of this remarkable first gathering, and to keep watching the skies.
[tags]web typography, typography, standards, webstandards, W3C, fonts, embedded, @fontface, EOT, workinggroup[/tags]
A List Apart, for people who make websites, is slowly changing course.
For most of its decade of publication, ALA has been the leading journal of standards-based web design. Initially a lonely voice in the desert, we taught CSS layout before browsers correctly supported it, and helped The WaSP persuade browser makers to do the right thing. Once browsers’ standards support was up to snuff, we educated and excited designers and developers about standards-based design, preaching accessibility, teaching semantic markup, and helping you strategize how to sell this new way of designing websites to your clients, coworkers, and boss.
Most famously, over the years, writers for ALA have presented the design community with one amazing and powerfully useful new CSS technique after another. Initially radically new techniques that are now part of the vocabulary of all web designers include Paul Sowden’s “Alternative Styles,” Mark Newhouse’s list-based navigation, Eric Meyer’s intro to print styles, Douglas Bowman’s “Sliding Doors,” Dave Shea’s “CSS Sprites,” Dan Cederholm’s “Faux Columns,” Patrick Griffiths and Dan Webb’s “Suckerfish Dropdowns,” Drew McLellan’s “Flash Satay,” and so on and so on. There are literally too many great ones to name here. (Newcomers to standards-based design, check Erin Lynch’s “The ALA Primer Part Two: Resources For Beginners“.)
Web standards are in our DNA and will always be a core part of our editorial focus. Standards fans, never fear. We will not abandon our post. But since late 2005, we have consciously begun steering ALA back to its earliest roots as a magazine for all people who make websites—writers, architects, strategists, researchers, and yes, even marketers and clients as well as designers and developers. This means that, along with issues that focus on new methods and subtleties of markup and layout, we will also publish issues that discuss practical and sometimes theoretical aspects of user experience design, from the implications of ubiquitous computing to keeping communities civil.
The trick is to bring our huge group of highly passionate readers along for the ride. My wife likens it to piloting the Queen Mary. (Q. How do you make the Queen Mary turn left? A. Very, very slowly.)
The slow, deliberate, gradual introduction of articles on business and theory has not pleased all of ALA’s readers, some of whom may unrealistically wish that every issue would present them with the equivalent of a new “Sliding Doors.” It is possible, of course, to publish one CSS (or JavaScript or Jquery) article after another, and to do so on an almost daily basis. We could do that. Certainly we get enough submissions. The trouble is that most articles of this kind are either edge cases of limited utility, or derivatives that do not break significant new ground. (Either that, or they are flawed in our estimation, e.g. relying on dozens of non-semantic divs to create a moderately pleasing, minor visual effect.)
We review hundreds of articles and publish dozens. Some web magazines seem to have those proportions reversed, and some readers don’t seem to mind, and that’s fine. But any content you see in ALA has been vetted and deeply massaged by the toughest editorial team in the business. And when you see a new “design tech” article in our pages, you can be sure it has passed muster with our hard-ass technical editors.
Moreover, the fields of meaningful new CSS tricks have mostly yielded their fuels. We’ve done that. We’ve done it together with you. While a few new lodes of value undoubtedly remain to be tapped, we as a community, and as individuals who wish to grow as designers, need to absorb new knowledge. ALA will continue to be a place where you can do that.
When we began focusing on web standards in 1998, we were told we were wasting readers’ time on impractical crap of little value to working designers and developers. But we kept on anyway, and the things we learned and taught are now mainstream and workaday. While we apologize to readers who are again being made irritable by our insistence on occasionally presenting material that does not fall directly within their comfort zone, we hope that this experiment will prove to be of value in the end.
[tags]alistapart, webdesign, magazine, editorial, content, focus, change, publishing, standards, webstandards, css, design, layout, userexperience[/tags]
Between hurricanes and hericanes, you could easily have missed the technology news. Released yesterday in public beta, Google Chrome is a standards-compliant web browser created to erode Microsoft’s browser dominance (i.e. to boost Google’s web dominance) while also rethinking what a browser is and does in the age of web apps and Google’s YouTube.
The new browser is based on Webkit, the advanced-standards-compliant, open source browser engine that powers Apple’s Safari for Mac and PC, but Chrome currently runs only in Windows. You figure that out.
Here are the new browser’s terms of service.
And here’s an important early bug report from Jeremy Jarratt: Google Chrome wrongly displays alternate styles as if active, thus “breaking” websites that use them. (Here’s more about alternate style sheets, from Paul Sowden’s groundbreaking 2001 A List Apart article.)
To compete with Microsoft, the new browser must offer what other browsers do not. The risk inherent in that proposition is a return to proprietary browser code. It is not yet clear to me whether Chrome will compete the wrong way—offering Chrome-only features based on Chrome-only code, thus prompting Microsoft to rethink its commitment to standards—or the right way.
Competing by offering features other browsers do not (easier downloads, streamlined user interface) or by consolidating other browsers’ best features (Opera’s Speed Dial, Firefox’s auto-complete) avoids this risk, as improvements—or at any rate, changes—to the browser’s user interface have no bearing on the display of existing web content.
Competing by supporting web standards ahead of the pack, although not entirely without risk, would also be a reasonable and exciting way to compete. When one browser supports a standard, it goads other browser makers into also supporting it. Because Safari, for instance, supports @font-face, Firefox is not far behind in supporting that CSS spec. @font-face raises font licensing problems, but we’ll discuss those another time. The risk that concerns us here is when a browser supports an emerging specification before it is finalized, thus, essentially, freezing the spec before it is ready. But that is the traditional dance between spec authors and browser makers.
For web standards and web content, we once again live in interesting times. Welcome, Chrome!
[tags]google, chrome, googlechrome, beta, software, browsers, standards, webbrowsers, webstandards, bugs, standards-compliant, alternatestyles, alternatecss[/tags]
In Issue No. 256 of A List Apart, for people who make websites, Wilson Miner shares techniques for incorporating data visualization into standards-based web navigation patterns, and Paul Smith shows how to replicate Google Maps’ functionality with open source software to produce high-quality mapping applications tailored to your design goals. Read and enjoy.
P.S. Just for the heck of it, we’ve started an A List Apart Facebook group. Saddle up!
Comments off. (Comment in the magazine.)
[tags]alistapart, datavisualization, maprolling, googlemaps, opensource, navigation, standards, webstandards, design, webdesign[/tags]
The DOCTYPE switch isn’t what it used to be.
For most of the past seven years, the DOCTYPE switch stood designers and developers in good stead as a toggle between standards mode and quirks mode. The switch enabled browsers to accurately support the work of responsible designers who cared about accessibility, findability, and lean, semantic markup. It also enabled those same browsers to support the old-fashioned, table-driven junk markup your grandpappy writes.
But when IE7, with its tremendously improved support for standards, “broke the web,” it revealed the flaw in our beloved toggle. The quest was on to find a more reliable ensurer of forward compatibility. Is version targeting the answer?
In Issue No. 251 of A List Apart, for people who make websites, Aaron Gustafson of The Web Standards Project and ALA describes the workings of and logic behind version targeting, a proposed replacement to the DOCTYPE switch. It’s an idea whose simplicity you may admire immediately; or you may, at least initially, want to run screaming in the opposite direction.
That’s how ALA‘s Eric Meyer felt, when he first previewed Aaron’s report. So did I. But we came around—and in “A Standardista’s Journey,” the companion piece to Aaron’s article, Eric explains how his thinking about version targeting evolved.
Microsoft is on board to support version targeting in IE8; they hope other browser makers will do likewise. The Web Standards Project worked with the Redmond company to forge this new path in forward compatible design. It’s with Microsoft’s consent that we unveil version targeting in this issue. In a future issue, we’ll discuss the implications for scripting.
- Aaron Gustafson: Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8
- Eric Meyer: From Switches to Locks: A Standardista’s Journey
[tags]standards, webstandards, DOCTYPE, DOCTYPE switch, forward compatible, forward compatibility, versionlock, IE8[/tags]