Although we’re now in this transitional stage of shedding off old browsers and web technologies that have been stumbling blocks to creating innovative new websites, there’s still confusion and fear that needs to be quelled. (Some people just can’t get excited that easily.)
Jeremy Keith’s article, Misunderstanding markup, seems like the ideal anchor at this point. First, it points out the differences between XHTML 1.0, XHTML 1.1, and XHTML 2:
- XHTML 1.0 = HTML4 with XHTML syntax
- XHTML 1.1 = XHTML 1.0 with the requirement that documents should be served with the XML MIME type
- XHTML 2 = a whole new specification that has little in common with XHTML 1.0/1.1/HTML 4
- XHTML has two types: pages that are actually served using the
application/xhtml+xml MIME type; and pages that are actually served using the text/html MIME type but follow XHTML syntax.
Confusion? Fixed.
Second and more importantly, it emphasizes what the triumph of HTML5 means for XHTML:
- You can still use XHTML syntax on HTML5 documents; it’s flexible enough and backwards-compatible (unlike XHTML2) that way. You can also go back to old coding conventions like uppercase tag names, optional quoting of attributes, and the absence of trailing slashes, and that’s okay too.
- In fact, you can serve HTML5 documents as
application/xhtml+xml and you get an XHTML document, affectionately called XHTML5. At this point, only XHTML2 is dead.
- Still scared about taking the plunge to HTML5? It’s as easy as replacing that long-winded strict, transitional, or (gasp) frameset DOCTYPE declaration to
<!DOCTYPE html>.
Once you learn items 1 and 2, the third item is all you’ll need to focus on from now on. It’s a comforting message that if you think catching up to HTML5 will be difficult, rest assured that it’s not as scary as it looks.
Fear? Fixed.
Let’s move on, shall we?
I know rattling off websites in blog posts are a dime a dozen these days and may not be your cup of tea. But you might want to read and bookmark these sites—you’ll definitely keep coming back to them.
It’s a very short list, so you won’t tire easily reading this, and the sites are more like Position is Everything than Smashing Magazine. (No offense intended; I know that SM does a wide variety of blog posts, not just lists and freebies. I just mean they’re more references than resources, okay?)
Web Design+
Web Design+ contains the solutions to common web standards problems. From choosing a DOCTYPE to implementing CSS hacks, this is a great one-stop-shop for the best practices in web design out there. There are a ton of HTML and CSS cheatsheets out there, but reading them shouldn’t stop there. Refine your markup and stylesheets with the help of this site, free!
When Can I Use…
When can I use… compares support for several web design features according to browser version, from HTML to CSS to SVG to other technologies.
For example: thinking of using CSS3′s rounded corners (border-radius)? It’s not even available on IE8 and Opera 10 yet. Of course, you don’t have to avoid using them just because the conclusion says “not ready”. It’s still a very useful page for recalling which browser version can support what.
On Having Layout
On having layout demystifies the concept of Internet Explorer’s hasLayout property. A lot of the IE-related CSS problems that web designers run into are related to hasLayout, so understanding how it works is essential.
The Ultimate Website Launch Checklist
The Ultimate Website Launch Checklist helps one go over key aspects of a website once it goes live. It’s more for the designer-webmaster hybrid, but regardless of your role in the process it’s a good view of what needs to be done.
I’ve noticed this trend to screenshot tweets instead of copy-pasting their texts in blockquotes for some time now. On web design and technology blogs, no less. You’d think these sites who constantly write articles about HTML, CSS, web standards, usability, semantics would actually listen to their own advice.
What do people get out of doing it, though? Is Twitter really that much of a game-changer that you can now break the conventions of quoting people in articles on websites? Is it really that big of a deal to debate on how you should add tweets to articles—which is so obviously linkbait?
Are tweet pages designed so much prettier than your default blockquote designs that you feel compelled to use them instead (that’s definitely an “unsuccessful designer trend” isn’t it)? Though, consider the construction: large text, a clear indication of who said the tweet, and a fuzzy timestamp. Maybe that’s what blockquotes should aspire to be?
Are tweets such special data forms that you need specialized plugins and scripts like WP Quote, Twickie, QuoteURL to display them? Or do those exist to up one’s geek cred and feed the third-party Twitter apps machine?
Still, those aren’t as bad as web apps like tweetshots. Want to share a tweet on Tumblr? Use the Quote post type. WordPress is getting custom post types in its next major release too. But publishing platform or no publishing platform, that’s what the HTML tag <blockquote> is for.
Let me channel Steve Ballmer and say: Blockquotes, blockquotes, blockquotes, blockquotes, blockquotes. They’re not that hard to use, certainly not more than taking a screenshot and uploading it.
I understand why on some occasions using images instead of text and other data formats is preferred. They’re usually more portable when passed around in email, forums, social networks, and other communication platforms. More people know how to deal with images than URLs too. But for the purpose of quoting tweeple on websites, I see no excuse for displaying text as images.
I’ll spell it out for you in <strong> and <em>: display text as text, not as images, damn it!
Sure, screencapping tweets may not be as grave a sin as using tables for layouts, but back when that was the dominant method of creating websites, it was a pragmatic choice to make do with the technology available. The choice to use images for text is illogical today. It is confusing behavior that is inexplicably linked to Twitter’s success.
Google brought back the 80s arcade game Pac Man to celebrate its 30th anniversary last May 22nd in the form of a fully-working Google Doodle on its homepage (it’s been since moved to a dedicated page where people can still play it). The “I’m feeling lucky” button gets replaced by “Insert coin” and clicking on it lets you play. Click on it a second time and Ms. Pac Man joins in the fun.
Apart from hearing collective 8-bit cheers of delight upon discovering what could be Google’s most viral web toy yet, the Pac Man doodle was another display of its massive influence, both the good and the bad. more
Aside from creating brilliantly art-directed articles that push the limits in with the latest HTML and CSS features, David DeSandro is redefining at least two classic site features at the same time with his Portfolio page:
The portfolio format.
Most portfolios consist of image thumbnails with either short or detailed descriptions about each project undertaken. DeSandro’s portfolio, on the other hand, contains full-width, full-height screenshots with guided markings explaining the how and why of his work, not just the what. Not only can you admire and drool over the designs, but you can learn from them as well.
The HTML image map.
The concept of image maps is sound but its execution isn’t so exciting: you don’t exactly know where to click and if you do, you don’t know what you’re clicking on. DeSandro created annotations that are intuitive and easy to navigate.
Does your portfolio need a refresh?
Your portfolio is your resume. Presenting your work and communicating your design view is critical to how others perceive you and shouldn’t be an afterthought. David’s portfolio isn’t so complex as it is well thought out. The designs are in full view; the details are straightforward. No distractions, no hype. Reexamine your portfolio page and see if yours is the same.
Blackbird Pie is Twitter’s very own tool for embedding tweets on webpages without the cumbersome, semantics-killing screenshot method. It still lacks the dead-simple interface Twitter is notorious for, since you have to enter the URL of the tweet to grab the embed code and it’s not even built into the system yet, but that’s because it’s a rough prototype at this point.
Since Twitter is an ecosystem of early adopters, it didn’t take long before a bookmarklet surfaced, which sports only a minor difference with the original code in the date format, and seems to display better on this site.
Note that this method inherits your websites styles, which means you may or may not have to tweak your CSS to accommodate it. Unfortunately it still looks bad in feed readers.
Has progress been achieved here?
I’m not sure this is any better than a screenshot. Putting aside the long-winded user flow of grabbing the code since that can be remedied once it’s built into the Twitter system, there’s an overflowing amount of inline CSS to copy and paste. The advantage to this static code, however, instead of a JavaScript embed is that the text is preserved even when the tweet is deleted.
The question remains: should people go through all this trouble to use tweets as quotes? Is there really that much more to be gained by preserving the tweet “format” over a simple blockquote? I still don’t think so.
As much as I wish we’d move on and get Apple off our radar, its decisions have a rippling effect in the industry and the future of various technologies. The next issue on the list? The Web versus App debate. This can be framed more specifically as a Mobile Web vs. Objective-C Web debate in the context of Apple’s mobile landscape, but as early discussions arise, it’s transforming into an interoperability vs. superior user experience debate. Cameron Moll, author of Mobile Web Design, writes:
At one point in time, J2ME (now Java ME) and WAP were the starting points for a discussion on mobile strategy and the web. Then, for a brief period of time, you talked about HTML/CSS. Now, for a growing majority of mobile strategies that don’t require a global presence on widely varying devices, the discussion begins with iPhone. Smart client is now iPhone app, and in many cases, the app is primary to the experience, not secondary to the browser. And iPad app may soon replace iPhone app as the starting point.
Frankly, as the adoption rate of iPhone increases and if iPad follows suit, it will become increasingly difficult to argue in favor of a starting point other than iPhone OS. The NPR iPad app, for one, provides a much more pleasant user experience than NPR.org.
Peter-Paul Koch steps in and plants himself firmly on the interoperability front, maintaining allegiance to the Web:
This is a total no-brainer when we’re talking about games and other entertainment apps. When it comes to complex, graphic games, vendors will opt for superior UX, and once you’ve done that, starting on iPhone OS makes excellent sense.
But if you build an integrated social media client, is superior UX still so important that you can afford to ignore non-iPhones? I don’t think so. I think creators of such apps would do better to create one in web standards so that it runs on all (well, many) devices. There’s stiff competition out there, and the wider your reach, the better chance you have of prevailing.
Meanwhile, Faruk Ates goes the complete opposite: rooting for UX, lamenting the existence of multiple browsers, and emphasizing the need to make a buck. The debate expands further and we see clashing ideologies of democracy vs. walled gardens, free vs. paid business models, and so on. All these further reinforce how Apple’s philosophies go against those of the Web.
With all its new moves, Apple has been targeting all sorts of corporate entities for its own gain: Adobe, Google, the whole porn industry…but now is it also hurting developers? consumers? the Web? itself?
Hostility towards competitors is, I suppose, all part of the game. But this action is also hugely hostile towards developers themselves. The banned development environments offer things that Apple’s Xcode doesn’t. Sometimes it’s just a different choice of language, one that a particular deveoper might feel more comfortable in. But often the advantage is simplification—the use of higher-level programming languages (like Lua, or JavaScript, or C#) and frameworks that take out a lot of the grunt-work of software development (like writing a 3D engine). In turn, developers get quicker development cycles, easier development, fewer bugs, and overall, superior applications. Banning these tools doesn’t just hurt competitors. It hurts developers on Apple’s platform, and in turn hurts the platform itself.
Apple’s done a lot of things to stir the pot, and while such stringent practices have been known to yield revolutionary results, its actions continue to seem awfully ruthless. Choosing a more favorable approach to mobile development could very well be tainted by the company’s values.
So Mark Boulton decided to release his book, A Practical Guide to Designing for the Web, online and without cost. It’s not the only web design book available for free on the web, which this list and a previous encounter with two other online books prove, but all of them make me wonder, again, about the electronic book format.
In the examples above, said “books” don’t adapt official e-book formats, but stick with plain old semantic HTML and PDFs. Joe Clark, in an A List Apart article, explains that both standard and proprietary e-book formats are just more specialized versions of HTML/XHTML, so is there anything gravely wrong with creating webpages instead of actual e-book files?
As one who knows her way around HTML, taking an extra step into e-books (e.g. ePub) feels clunky and unnecessary. However, that is hasty judgment without first considering factors like audience. For web design books, perhaps it makes more sense to not bother with anything else and keep them as webpages because web designers work on sites all day long. That’s not to say they wouldn’t enjoy reading web design books in their e-book readers, but they may mind less having a book in one tab alongside other web design resources in other tabs.
Using proper formats also seems like a natural extension of web standards philosophy. If one were to publish a book online, why not go for the suitable format? There are scripts, extensions, and converters available. And with the ePub Zen Garden following in the steps of the CSS one, it may become the next worthy cause to root for.
I started with this article about the decade that was in web design. (Note: an earlier version of this was done here.) It was not much more than a before and after look at the most popular websites out there. Of course, ten years is a long time in web design so the showcase is a satisfactory way to see how far we’ve come, but not quite enough. There was no discussion on the notable features from the different websites. We don’t redesign sites just because we want a different look, do we? We want them to improve. Answering how those sites improved over the years would be a worthy reference for all the web designers out there. This other one almost nails it, though it focuses on the business of these companies, not web design itself.
I hope the likes of Smashing Magazine or some fabulous curator of web design history would come up with an in-depth study illustrating how web design has evolved over the last ten years. Timelines like this and this could help with that, but still needs mention of developments like:
- the downfall of
<table> layouts in favor of semantic markup
- CSS sprites
- the growth of web typography, from sIFR to
@font-face
- Art Direction in web design
- mobile web design
- the HTML 5 Superfriends
- which website or company popularized which design pattern, from the glossy, candy-colored “Web 2.0 look” to the sleeker, more dramatic “Apple look” (though something tells me Apple is responsible for both)
Here‘s another approach to the timeline, and is more of a Q&A over the years, and anybody can ask and answer. It also hasn’t been updated since ’04, as it was part of the 2005 conference, A Decade of Web Design. Jakob Nielsen also did a backtrack that same year.
I’d also like to look forward. This prediction post is quite adequate (with pictures it would be perfect). I think this passage sums up what’s happened in the past decade and what will happen in the next:
While most these technological improvements tend to make the web a more and more homogenous place, at the same time, there is a tendency to create highly curated design setups that use different designs for each article.
There will always be a dichotomy between standardization and specialization on the Web but it’s only lately that we’ve been able to do so with less crap, more elegance. And I can’t wait to see how doing those two things evolve into even more exciting things in 2010 and beyond.
Need more crystal balls and time capsules? See also:
And by jQuery-esque I mean easy! The premise of Jetpack, Mozilla Labs’s latest creation, is that anybody who knows HTML, CSS and JavaScript can create Firefox add-ons.
It takes 80 lines of code to block ads on websites as shown in the demo above, and 14 lines to edit images from within Firefox. Granted, it just sends the data to Pixlr which does all the hard work, but lowering the obstacles to develop some fairly nifty scripts is a commendable effort, just as what jQuery did with JavaScript, Sass with CSS, and HAML with HTML. It’s made even more compelling with Bespin, Mozilla’s HTML5-powered web-based code editor.
Perhaps I’m still in a “standardize everything” mood, or envy this new doodad since I’m now using Chrome as my default browser, but don’t you sometimes wish all browsers could do this? Do the same set of things? We’re getting to a point where the level of HTML and CSS support is the same across every browser, so it makes me wonder what’s the next step for the idea of cross-browser compatibility.
It will probably depend on what the web browser means to its various makers. Google has unveiled the Chrome OS, which will run on a specialized version of Chrome. Opera is focused on its “web servers for everyone” feature in Opera Unite. (And Internet Explorer is playing catch-up, mostly.) Browsers are basically the gateways to the whole Internet, but they’ve become more ambitious than that and their vendors will attend to those ventures first before convening to create new cross-platform goodness.
*/
