Category: Standards

Web standards for design and communication.

Categories
Accessibility Design HTML HTML5 industry spec Standards State of the Web W3C Web Design XHTML

HTML 5 is a mess. Now what?

A few days ago on this site, John Allsopp argued passionately that HTML 5 is a mess. In response to HTML 5 activity leader Ian Hickson’s comment here that, “We don’t need to predict the future. When the future comes, we can just fix HTML again,” Allsopp said “This is the only shot for a generation” to get the next version of markup right. Now Bruce Lawson explains just why HTML 5 is “several different kind of messes:”

  1. It’s a mess, Lawson says, because the process is a mess. The process is a mess, he claims, because “[s]pecifying HTML 5 is probably the most open process the W3C has ever had,” and when you throw open the windows and doors to let in the fresh air of community opinion, you also invite sub-groups with different agendas to create competing variant specs. Lawson lists and links to the various groups and their concerns.
  2. It’s a “spec mess,” Lawson continues, citing complaints by Allsopp and Matt Wilcox that many elements suffer from imprecise or ambiguous specification or from seemingly needless restrictions. (Methinks ambiguities can be resolved, and needless restrictions lifted, if the Working Group is open to honest, accurate community feedback. Lawson tells how to contact the Working Group to express your concerns.)
  3. Most importantly, Lawson explains, HTML 5 is a backward compatibility mess because it builds on HTML 4:

[I]f you were building a mark-up language from scratch you would include elements like footer, header and nav (actually, HTML 2 had a menu element for navigation that was deprecated in 4.01).

You probably wouldn’t have loads of computer science oriented elements like kbd,var, samp in preference to the structural elements that people “fake” with classes. Things like tabindex wouldn’t be there, as we all know that if you use properly structured code you don’t need to change the tab order, and accesskey wouldn’t make it because it’s undiscoverable to a user and may conflict with assistive technology. Accessibility would have been part of the design rather than bolted on.

But we know that now; we didn’t know that then. And HTML 5 aims to be compatible with legacy browsers and legacy pages. …

There was a cartoon in the ancient satirical magazine Punch showing a city slicker asking an old rural gentleman for directions to his destination. The rustic says “To get there, I wouldn’t start from here”. That’s where we are with HTML. If we were designing a spec from scratch, it would look much like XHTML 2, which I described elsewhere as “a beautiful specification of philosophical purity that had absolutely no resemblance to the real world”, and which was aborted by the W3C last week.

Damned if you do

The third point is Lawson’s key insight, for it illuminates the dilemma faced by HTML 5 or any other honest effort to move markup forward. Neither semantic purity nor fault-tolerance will do, and neither approach can hope to satisfy all of today’s developers.

A markup based on what we now know, and can now do thanks to CSS’s power to disconnect source order from viewing experience, will be semantic and accessible, but it will not be backward compatible. That was precisely the problem with XHTML 2, and it’s why most people who build websites for a living, if they knew enough to pay attention to XHTML 2, soon changed the channel.

XHTML 2 was conceived as an effort to start over and get it right. And this doomed it, because right-wing Nativists will speak Esperanto before developers adopt a markup language that breaks all existing websites. It didn’t take a Mark Pilgrim to see that XHTML 2 was a dead-end that would eventually terminate XHTML activity (although Mr Pilgrim was the first developer I know to raise this point, and he certainly looks prescient in hindsight).

It was in reaction to XHTML 2’s otherworldliness that the HTML 5 activity began, and if XHTML suffered from detachment from reality, HTML 5 is too real. It accepts sloppiness many of us have learned to do without (thereby indirectly and inadvertently encouraging those who don’t develop with standards and accessibility in mind not to learn about these things). It is a hodgepodge of semantics and tag soup, of good and bad markup practices. It embraces ideas that logically cancel each other out. It does this in the name of realism, and it is as admirable and logical for so doing as XHTML 2 was admirable and logical in its purity.

Neither ethereal purity nor benign tolerance seems right, so what’s a spec developer to do? They’re damned either way—which almost suggests that the web will be built with XHTML 1.0 and HTML 4.01 forever. Most importantly for our purposes, what are we to do?

Forward, compatibly

As the conversation about HTML 5 and XHTML has played out this week, I’ve felt like Regan in The Exorcist, my head snapping around in 360 degree arcs as one great comment cancels out another.

In a private Basecamp discussion a friend said,

Maybe I’m just confused by all the competing viewpoints, but the twisted knots of claim and counterclaim are getting borderline Lovecraftian in shape.

Another said,

[I] didn’t realize that WHATWG and the W3C’s HTML WG were in fact two separate bodies, working in parallel on what effectively amounts to two different specs [1, 2—the entire thread is actually worth reading]. So as far as I can tell, if Ian Hickson removes something from the WHATWG spec, the HTML WG can apparently reinsert it, and vice versa. [T]his… seems impossibly broken. (I originally used a different word here, but, well, propriety and all that.)

Such conversations are taking place in rooms and chatrooms everywhere. The man in charge of HTML 5 appears confident in its rightness. His adherents proclaim a new era of loaves and fishes before the oven has even finished preheating. His articulate critics convey a palpable feeling of crisis. All our hopes now hang on one little Hobbit. What do we do?

As confused as I have continually felt while surfing this whirlwind, I have never stopped being certain of two things:

  1. XHTML 1.0—and for that matter, HTML 4.01—will continue to work long after I and my websites are gone. For the web’s present and for any future you or I are likely to see, there is no reason to stop using these languages to craft lean, semantic markup. The combination of CSS, JavaScript, and XHTML 1.0/HTML 4.01 is here to stay, and while the web 10 years from now may offer features not supported by this combination of technologies, we need not fear that these technologies or sites built on them will go away in the decades to come.
  2. That said, the creation of a new markup language concerns us all, and an informed community will only help the framers of HTML 5 navigate the sharp rocks of tricky shoals. Whether we influence HTML 5 greatly or not at all, it behooves us to learn as much as we can, and to practice using it on real websites.

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 Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, 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. — 12 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]HTML5, HTML4, HTML, W3C, WHATWG, markup, webstandards[/tags]

Categories
HTML HTML5 Markup spec Standards State of the Web

HTML 5: nav ambiguity resolved

AN EMAIL from Chairman Hickson resolves an ambiguity in the nav element of HTML 5.

One of the new things HTML 5 sets out to do is to provide web developers with a standardized set of semantic page layout structures. For example, it gives us a nav element to replace structures like div class="navigation".

This is exciting, logical, and smart, but it is also controversial.

The controversy is best expressed in John Allsopp’s A List Apart article, Semantics in HTML 5, where he worries that the new elements may not be entirely forward-compatible, as they are constrained to today’s understanding of what makes up a page. An extensible mechanism, although less straightforward, would offer more room to grow as the web evolves, Allsopp argues.

We’re pretty sure Ian Hickson, the main force behind HTML 5, has heard that argument, but HTML 5 is proceeding along the simpler and more direct line of adding page layout elements. The WHAT Working Group Mr Hickson chairs has solicited designer and developer opinion on typical web page structures in order to come up with a short list of new elements in HTML 5.

nav is one of these elements, and its description in the spec originally read as follows:

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of primary navigation blocks are appropriate for the nav element.

The perceived ambiguity was expressed by Bruce Lawson (AKA HTML 5 Doctor) thusly:

“Primary navigation blocks” is ambiguous, imo. A page may have two nav blocks; the first is site-wide naviagtion (“primary navigation”) and within-page links, eg a table of contents which many would term “secondary nav”.

Because of the use of the phrase “primary navigation block” in the spec, a developer may think that her secondary nav should not use a

Chairman Hickson has resolved the ambiguity by changing “primary” to “major” and by adding an example of secondary navigation using nav.

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 Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, 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. — 12 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

Translations

Categories
Community HTML spec Standards The Essentials Web Design Web Design History Web Standards XHTML

In defense of web developers

It has only been a few days but I am already sick of the “XHTML is bullshit, man!” crowd 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.

A coterie of well-informed codemeisters, from ppk to Ian Hickson, has always had legit beefs with XHTML, the most persuasive of which was Hickson’s:

It is suggested that HTML delivered as text/html is broken and XHTML delivered as text/xml is risky, so authors intending their work for public consumption should stick to HTML 4.01, and authors who wish to use XHTML should deliver their markup as application/xhtml+xml.

This problem always struck me as more theoretical than real, but I pointed it out in every edition of Designing With Web Standards and left it to the reader to decide. When I wrote the first edition of the book, some versions of Mozilla and IE would go into Quirksmode in the presence of HTML 4, breaking CSS layouts. To me, that was a worse problem than whatever was supposed to be scary or bad about using well-formed XHTML syntax while delivering it as HTML all browsers could support.

The opportunity to rethink markup

The social benefit of rethinking markup sealed the deal. XHTML’s introduction in 2000, and its emphasis on rules of construction, gave web standards evangelists like me a platform on which to hook a program of semantic markup replacing the bloated and unsustainable tag soup of the day. The web is better for this and always will be, and there is much still to do, as many people who create websites still have not heard the call.

A few who became disenchanted with XHTML early retreated to HTML 4, and as browsers stopped going into Quirksmode in its presence, valid, structural HTML 4 became a reasonable option again. But both HTML 4 and XHTML 1 were document languages, not transactional languages. They were all noun, and almost no verb. So Ian Hickson, XHTML’s biggest critic, fathered HTML 5, an action-oriented toddler specification that won’t reach adulthood until 2022, although some of it can be used today.

And guess what? HTML 5 is as controversial today as XHTML was in 2000, and there are just as many people who worry that a specification of which they don’t entirely approve is being shoved down their throats by an “uncaring elite.” Only this time, instead of the W3C, the “uncaring elite” is Mr Hickson, with W3C rubber stamp, and input from browser makers, including his employer.

XHTML not dead

All of this is to say that XHTML is not dead (XHTML 2 is dead, thank goodness), and HTML 5 is not here yet. Between now and 2022, we have plenty of time to learn about HTML 5 and contribute to the discussion—and browser makers have 13 years to get it right. Which is also to say all of us—not just those who long ago retreated to HTML 4, or who became fans of HTML 5 before it could even say “Mama”—are entitled to be pleased that standard markup activity will now have a single focus, rather than a dual one (with XHTML 2 the dog spec that no one was willing to mercy-kill until now).

Entitled to be pleased is not the same as entitled to gloat and name call. As DN put it in comment-44126:

What is really rather aggravating is how many people are using this news as a stick with which to beat any developer or freelancer who’s had the audacity to study up on and use XHTML in good faith–or even, much to the horror of the Smug Knowbetters, admire XHTML’s intelligible markup structure–for the brand-new-minted sin of doing the most with XHTML that’s possible. The ‘unofficial Q&A’ is ripe with that kind of condescension. …[D]on’t pin users (front-end developers are merely users of specifications) with Microsoft’s failure to support the correct MIME type.

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
  • Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, 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. — 12 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]HTML, HTML5, W3C, WTF, XHTML, XML[/tags]

Categories
Browsers Compatibility CSS Design Marketing Markup Microsoft software spec Standards State of the Web style The Profession Tools W3C Web Standards Working XHTML

Sour Outlook

It’s outrageous that the CSS standard created in 1996 is not properly supported in Outlook 2010. Let’s do something about it.

Hundreds of millions use Microsoft Internet Explorer to access the web, and Microsoft Outlook to send and receive email. As everyone reading this knows, the good news is that in IE8, Microsoft has released a browser that supports web standards at a high level. The shockingly bad news is that Microsoft is still using the Word rendering engine to display HTML email in Outlook 2010.

What does this mean for web designers, developers, and users? In the words of the “Let’s Fix It” project created by the Email Standards Project, Campaign Monitor, and Newism, it means exactly this:

[F]or the next 5 years your email designs will need tables for layout, have no support for CSS like float and position, no background images and lots more. Want proof? Here’s the same email in Outlook 2000 & 2010.

It’s difficult to believe that in 2009, after diligently improving standards support in IE7 and now IE8, Microsoft would force email designers to use nonsemantic table layout techniques that fractured the web, squandered bandwidth, and made a joke of accessibility back in the 1990s.

Accounting for stupidity

For a company that claims to believe in innovation and standards, and has spent five years redeeming itself in the web standards community, the decision to use the non-standards-compliant, decades-old Word rendering engine in the mail program that accompanies its shiny standards-compliant browser makes no sense from any angle. It’s not good for users, not good for business, not good for designers. It’s not logical, not on-brand, and the very opposite of a PR win.

Rumor has it that Microsoft chose the Word rendering engine because its Outlook division “couldn’t afford” to pay its browser division for IE8. And by “couldn’t afford” I don’t mean Microsoft has no money; I mean someone at this fabulously wealthy corporation must have neglected to budget for an internal cost. Big companies love these fictions where one part of the company “pays” another, and accountants love this stuff as well, for reasons that make Jesus cry out anew.

But if the rumor’s right, and if the Outlook division couldn’t afford to license the IE8 rendering engine, there are two very simple solutions: use Webkit or Gecko. They’re both free, and they both kick ass.

Why it matters

You may hope that this bone-headed decision will push millions of people into the warm embrace of Opera, Safari, Chrome, and Firefox, but it probably won’t. Most people, especially most working people, don’t have a choice about their operating system or browser. Ditto their corporate email platform.

Likewise, most web designers, whether in-house, agency, or freelance, are perpetually called upon to create HTML emails for opt-in customers. As Outlook’s Word rendering engine doesn’t support the most basic CSS layout tools such as float, designers cannot use our hard-won standards-based layout tools in the creation of these mails—unless they and their employers are willing to send broken messages to tens millions of Outlook users. No employer, of course, would sanction such a strategy. And this is precisely how self-serving decisions by Microsoft profoundly retard the adoption of standards on the web. Even when one Microsoft division has embraced standards, actions by another division ensure that millions of customers will have substandard experiences and hundreds of thousands of developers still won’t get the message that our medium has standards which can be used today.

So it’s up to us, the community, to let Microsoft know how we feel.

Participate in the Outlook’s Broken project. All it takes is a tweet.

[tags]browsers, bugs, IE8, outlook, microsoft, iranelection[/tags]

Categories
Design HTML HTML5 Standards State of the Web W3C Web Design Web Standards

NSFW tag in HTML 5

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]

Categories
Interviews Press Publications Publishing reportage reprints Standards Typography Usability User Experience UX Web Design Web Standards wisdom Zeldman zeldman.com

.net interview

There was a point in the 90s when I felt like a sucker for doing HTML and CSS.”

The .net Zeldman interview is available for your downloading pleasure (4.2 MB PDF). For more of the best in web design and development, visit netmag.co.uk.

Update, 27 May 2009

An HTML version of the interview has now been posted on .net’s website.

[tags]webdesign, webdevelopment, magazine, interview, .net, netmag, interview, interviews, zeldman, jeffreyzeldman[/tags]

Categories
Accessibility Advocacy content copyright creativity CSS Design development DWWS Fonts Ideas industry links Real type on the web Standards State of the Web Tools Web Design Web Standards webfonts webtype

Web fonts now (how we’re doing with that)

THE WEB Fonts Wiki has a page listing fonts you can legally embed in your site designs using the CSS standard @font-face method. Just as importantly, the wiki maintains a page showing commercial foundries that allow @font-face embedding. Between these two wiki pages, you may find just the font you need for your next design (even if you can’t currently license classics like Adobe Garamond or ITC Franklin and Clarendon).

The advantages of using fonts other than Times, Arial, Georgia, and Verdana have long been obvious to designers; it’s why web design in the 1990s was divided between pages done in Flash, and HTML pages containing pictures of fonts—a practice that still, bizarrely, continues even in occasionally otherwise advanced recent sites.

Using real fonts instead of pictures of fonts or outlines of fonts provides speed and accessibility advantages.

Currently the Webkit-based Apple Safari browser supports @font-face. The soon-to-be-released next versions of Opera Software’s Opera browser, Google’s Webkit-based Chrome, and Mozilla Firefox will do likewise. When I say “soon-to-be-released,” I mean any day now. When this occurs, all browsers except IE will support @font-face.

IE has, however, offered font embedding since IE4 via Embedded OpenType (.EOT), a font format that enables real fonts to be temporarily embedded in web pages. That is, the reader sees the font while reading the page, but cannot download (“steal”) the font afterwards. Microsoft has “grant[ed] to the W3C a perpetual, nonexclusive, royalty-free, world-wide right and license under any Microsoft copyrights on this contribution, to copy, publish and distribute the contribution under the W3C document licenses,” in hopes that EOT would thereby become a standard. But so far, only Microsoft’s own browsers support EOT.

Thus, as we consider integrating real fonts into our designs, we must navigate between browsers that support @font-face now (Safari), those that will do so soon (Opera, Chrome, Firefox), and the one that possibly never will (IE, with a dwindling but still overwhelming market share).

The person who figures out a designer-friendly solution to all this will either be hailed as a hero/heroine or get rich. Meanwhile, near-complete solutions of varying implementation difficulty exist. Read on:

CSS @ Ten: The Next Big Thing

“Instead of making pictures of fonts, the actual font files can be linked to and retrieved from the web. This way, designers can use TrueType fonts without having to freeze the text as background images.” An introduction to @font-face by Håkon Wium Lie, father of CSS.

Real Fonts on the Web: An Interview with The Font Bureau’s David Berlow

Is there life after Georgia? To understand issues surrounding web fonts from the type designer’s perspective, I interview David Berlow, co-founder of The Font Bureau, Inc, and the ?rst TrueType type designer.

The W3C: @font-face vs. EOT

A discussion that shows why the W3C may not be able to resolve this conflict. (It’s kind of like asking the Montagues and Capulets to decide whether the Montagues or the Capulets should rule Verona.)

sIFR 2.0: Rich Accessible Typography for the Masses

Mike Davidson’s scalable and accessible remix of Shaun Inman’s pioneering use of Flash and JavaScript to replace short passages of HTML text with Flash movies of the same text set in a real font. The Flash movies are created on the fly. If JavaScript or images are turned off, the user “sees” the HTML text; text set in sIFR can also be copied and pasted. sIFR was a great initial solution to the problem of real fonts on the web, but it’s only for short passages (which means the rest of the page must still be set in Georgia or Verdana), and it fails if the user has a Flash block plug-in installed, as half of Firefox users seem to. It’s also always a pain to implement. I don’t know any designer or developer who has an easy time setting up sIFR. In short, while sIFR is an awesome stop-gap, real fonts on the web are still what’s needed. Which also leads us to…

Cufón – Fonts for the People

Simo Kinnunen’s method of embedding fonts, regardless of whether or not a browser supports @font-face.

Combining Cufón And @Font-Face

Kilian Valkhof: “Everyone wants @font-face to work everywhere, but as it stands, it only works in Safari and the upcoming versions of Firefox and Opera. In this article I’ll show you how to use Cufón only if we can’t load the font through other, faster methods.”

Adobe, Web Fonts, and EOT

Why Adobe supports Microsoft’s EOT instead of @font-face.

Introducing Typekit

Update May 28, 2009: Working with Jason Santa Maria, Jeff Veen’s company Small Batch Inc. introduces Typekit:

We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.

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, 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. — 16 July 2009

[tags]fonts, webfonts, webdesign, embed, @font-face, EOT, wiki, css, layout, safari, opera, firefox, chrome, browsers[/tags]

Categories
Accessibility Browsers business CSS Design development DWWS Layout Standards

A new answer to the IE6 question?

In “Universal Internet Explorer 6 CSS,” Andy Clarke proposes a novel approach to the problem that has vexed standards-based designers since time immemorial (or at least since we could quit worrying about Netscape 4).

The problem is IE6. Outdated but still widely used, especially in the developing world, its inaccurate and incomplete CSS support forces web designers and developers to spend expensive hours on workarounds ranging from hacks, to IE6-only styles served via conditional comments, to JavaScript. Some refuse to serve CSS to IE6 at all; others stop IE6 users at the gate. In some situations (personal site, web app used by first-world hipsters), ignoring IE6 may work; but mostly it doesn’t.

After a brief but thorough tour of current IE6 solutions and their limitations, Andy unveils his zinger. He proposes to serve IE6 users a set of universal styles completely unrelated to the design of the site in question. Not unlike Arc90’s awesome Readability plug-in, the styles Andy has designed concern themselves with typographic hierarchy and whitespace. Here’s the theory: make the page easy to read, make it obvious that somebody designed it, and the IE6 user will have a good experience.

(By contrast, block styles from IE6, as some developers suggest, and that user will have a bad experience. Most likely, in the absence of styles, the user will think the page is broken.)

No hammer fits all nails, and no solution, however elegant, will work for every situation. But if we’re open minded, Andy’s proposal may work in more situations than we at first suspect. Where it works, it’s what business folk call a “win, win:” the visitor has a good reading experience, and client and developer are spared tedium and expense.

Check it out.

[tags]IE6, workarounds, design, development, webdesign, hacks, legibility, styles, CSS, andyclarke[/tags]

Categories
An Event Apart Appearances Browsers Career client services Code Community content creativity CSS Design eric meyer events Happy Cog™ HTML HTML5 Ideas Images industry Information architecture jobs Redesigns Seattle speaking Standards State of the Web Surviving The Profession tweets twitter Working Zeldman

AEA Seattle after-report

Armed with nothing more than a keen eye, a good seat, a fine camera, and the ability to use it, An Event Apart Seattle attendee Warren Parsons captured the entire two-day show in crisp and loving detail. Presenting, for your viewing pleasure, An Event Apart Seattle 2009 – a set on Flickr.

When you’ve paged your way through those, have a gander at Think Brownstone’s extraordinary sketches of AEA Seattle.

Still can’t get enough of that AEA stuff? Check out the official AEA Seattle photo pool on Flickr.

Wonder what people said about the event? Check these Twitter streams: AEA and AEA09.

And here are Luke W’s notes on the show.

Our thanks to the photographers, sketchers, speakers, and all who attended.

[tags]aneventapart, aeaseattle09, AEA, AEA09, Seattle, webdesign, conference, Flickr, sets, Twitter, photos, illustrations, sketches, aneventapart.com[/tags]

Categories
A List Apart Advocacy art direction business CSS Design development Fonts Happy Cog™ HTML Ideas industry Interviews Layout Publications Publishing Standards State of the Web Typography Usability User Experience UX Web Design Web Standards Working XHTML

ALA 282: Life After Georgia

In Issue No. 282 of A List Apart, For People Who Make Websites:

  • Can we finally get real type on the web?
  • Does beauty in design have a benefit besides aesthetic pleasure?

Real Fonts on the Web: An Interview with The Font Bureau’s David Berlow

by DAVID BERLOW, JEFFREY ZELDMAN

Is there life after Georgia? We ask David Berlow, co-founder of The Font Bureau, Inc, and the ?rst TrueType type designer, how type designers and web designers can work together to resolve licensing and technology issues that stand between us and real fonts on the web.

In Defense of Eye Candy

by STEPHEN P. ANDERSON

Research proves attractive things work better. How we think cannot be separated from how we feel. The next time a boss, client, or co-worker scoffs at the notion that beauty is an important aspect of interface design, point their peepers here.

A List Apart explores the design, development, and meaning of web content, with a special focus on web standards and best practices.

[tags]alistapart, type, typography, realtype, truetype, CSS, beauty, design, aesthetics[/tags]

Categories
Standards State of the Web

UnDugg

With Digg relenting, the Digg bar’s assault on our content, ranking, and traffic will soon fade like every other lousy idea on the web, and we can once again retire our unframing scripts.

Categories
architecture Blogs and Blogging business Design findability HTML Ideas industry Information architecture links Publications Publishing Respect Standards State of the Web twitter Usability User Experience UX Web Design Web Standards Websites

Tiny URL, Big Trouble

Joshua Schachter explains how URL shorteners like TinyURL, bit.ly, etc., originally created to prevent long URLs from breaking in 1990s e-mail clients, and now used primarily as a means of monetizing someone else’s content, are bad:

  • They “add another layer of indirection to an already creaky system, [making what] used to be transparent … opaque,” slowing down web use by adding needless lookups, and potentially disguising spam.
  • Shorteners “steal search juice” from the original publishers. (For example, with the Digg bar and Digg short URL, your content makes Digg more valuable and your site less valuable; the more content you create, the richer you make Digg.)
  • “A new and potentially unreliable middleman now sits between the link and its destination. And the long-term archivability of the hyperlink now depends on the health of a third party.”

And more. Via Merlin Mann.

Anyone who creates web content should read Joshua’s post. I’m sold and will dial way back on my use of the zeldman.com short URL. The question remains, what to do when you need to paste a long, cumbersome link into a 140-character service like Twitter. (If you do nothing, Twitter itself will shorten the link via TinyURL.)

[tags]URL, URLshortener, JoshuaSchachter, redirect, abstraction, Digg, findability, searchjuice, SEO[/tags]

Categories
Design Ideas industry Interviews nytimes speaking Standards State of the Web tv Typography Usability User Experience Web Design Web Standards Zeldman zeldman.com

More Zeldman Fun From BigThink

Bigthink.com/jeffreyzeldman is your BigThink channel for all your BigThink Jeffrey Zeldman needs. Now playing at that URL are three Zeldman interview clips for your pleasure:

  1. “Jeff” Zeldman dissects online journalism
  2. “Jeff” Zeldman outlines the history of blogging
  3. “Jeff” Zeldman discusses the future of open source

View early and view often. Happy watching and blogging.

[tags]bigthink, zeldman, jeffreyzeldman, interviews, internet, web, design, history, journalism, online, onlinejournalism, webpublishing, opensource, webstandards[/tags]

Categories
Code Community Standards Web Standards

Micro-semantics for fun and profit

At corebasis.com, Henning von Vogelsang modestly presents his initiative to use an asterisk as a semantic reference for “source:”

Recent history taught us, if something is simple, makes sense and it is easy to use, it will most likely become a standard. … Through the increasing expansion of Twitter, the at-sign (@) has become a standard reference for a sender’s name. … Another change (introduced 2007) was the usage of hashtags (#). …

To help distinguish the source of information from a person, I propose we start using the following pattern:

  • @name
  • #tag
  • *source

[tags]semantics, micro, asterisk, proposal[/tags]

Categories
Design DWWS Standards Web Design Web Standards work writing

DWWS 3e

Sorry I haven’t written much here, lately, but I’ve been working on the third edition of a book you may know.

Questions?

[tags]dwws, designingwithwebstandards, 3rdedition, 3e, DWWS3e, newriders, peachpit, zeldman[/tags]