Jon Tangerine, David DeSandro, Trent Walton have all come up with ingenious ways to create image-free logotypes by pushing the limits of CSS (Sean Martell made a mouth-watering CSS-based logo too, but doesn’t contain text) that one has to wonder: is this the next step in online branding and identity?
The simplest argument against this could be that a logo must be constant. In the absence of CSS styling, possibly even helper JavaScript, an image will not suddenly morph into a default browser style and render a brand generic. See the image above for how the CSS-based Opera logo degrades in different browsers.
Now that excludes the scenario where images are turned off, and where text—styled text—can come in. Instead of simple image replacement techniques, we now have @font-face embedding and other advanced effects to bring the text as close as possible to the original design.
Text is great because you can read it, as can search engines. Another thing text based logos have going for them is they’re easier to make bigger; that’ll win over a lot of clients.
But there’s a great deal of extra markup required to achieve the necessary look. Does this make sense for the notion of a logo, which is inherently more portable with an image than with a bunch of divs, spans, classes and IDs? Should logos always be images and nothing but, or can they be both text and images? Which should come first, designing the logo in the browser or in a graphics program? Or should all of this experimentation remain just that: experiments?
Me, I just love we could be on the brink of shattering print conventions, yet again.
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.
Check out the more colorful, animated visualization of browser support for the latest HTML5 and CSS3 features based on data from When can I use… Inspired by a General Dynamics postcard and an infographic on America’s wealthiest religions, this single-serving site is quite literally a rainbow that’s painting optimism for the future of web standards.
Each ray represents a feature, and the different bands of color represent the leading browsers, IE6 excluded (finally). More under the hood details here, praising the virtues of Sass and Photoshop-less, in-browser design. Kudos to Paul Irish (again!) and Divya Manian.
In celebration of the iPad retail launch, Apple has created a gallery of iPad-ready websites that are said to embrace “the latest web standards—including HTML5, CSS3, and JavaScript”. That is, no Flash. You can even add your site to the gallery (scroll to the bottom).
Is Apple really opening up?
Let’s get the snark out of the way: a gallery, really? How novel. Right now there’s a vertical list (no Cover Flow?) of 20 top-tier websites. Will Apple really painstakingly update this list and add every possible HTML5/CSS3/JS-ready site submitted?
It’s a rare thing for Apple to lead a user-generated campaign like this but its best intentions are a thin veil over their real agenda—eliminating the competition and expanding further in the multimedia business. Does it really care about anything other than the big fish? What are the odds that the most humble of websites will even get into the gallery? Apple markets its products by partnering with the largest corporations that fit into its plans; I can’t imagine caring for the little guy in all of this.
This isn’t even in the same league as the iTunes app store—whose contents number in the hundreds of thousands—but could easily apply the profit-based and biased policies anyway. Not what I would call open or little guy friendly.
Is Apple a true web standards crusader?
Speaking of the app store: you can also develop specifically for the iPhone/iPod/iPad family using the SDK, but those apps don’t work in other devices. The mobile web is booming because of both the “web standards way” and the “mobile app” way, but how are device-specific apps any better than Flash apps (which happen to be cross-platform outside of Apple’s products)? Flipping off Flash when HTML5 and CSS3 aren’t ready isn’t a very responsible thing to do.
If Apple really wants to promote web standards, it should be doing a lot more with its resources to convert and educate people. The gallery is one thing, this documentation is another good step, but where are the resources for developing in HTML5, CSS3, and JavaScript? Partnerships with web standards groups like WaSP? Zeldman or one of the Super Friends speaking at the keynote?
If Apple really wants to promote web standards, see how it practically equates HTML5 with Flash-free media and nothing more. No oohs and ahs over CSS3′s text shadows and rounded corners or HTML5′s geolocation and <canvas>. This is the perfect opportunity to introduce the mainstream crowd to the wonders of these new technologies, yet all it’s pushing is anti-Flash propaganda.
One more thing…
Dear Apple, you’ve done a lot of groundbreaking things, but if you’re going to use web standards as a selling point for your most adjective-ridden product ever, you can do a hell of a lot better than an an anti-Flash gallery.
Remember my complaint about all the CSS3 syntaxes differing from one browser to another? It’s now addressed with CSS3 Please, a jQuery-based, in-browser editor that replaces multiple attribute values of the more complicated CSS3 syntaxes (from border-radius to rgba to @font-face) all at the same time, so you don’t have to.
In addition to syncing and normalizing changes across the necessary properties, it also sneaks in IE support for a few features via IE filters. Right now it helps you write the rules for: border-radius, box-shadow, linear-gradients, rotation and @font-face. A few more transforms like skew and scale are on their way, stay tuned.
You can preview your code on the box at the right side by toggling it on and off. When you’re done, click on the clipboard icon to copy the code.
This is a smart solution to a growing problem. However, even though I’m thoroughly grateful for this tool, I still want to axe the real problem, which is the inconsistent browser syntax. It’s unreasonable for a programming language to have redundant code, and while CSS isn’t really one, it’s still code. We’re still supposed to pride ourselves with efficiency, conciseness, and standards with any kind of code. We like to kick IE for constantly breaking standards; should we tolerate the same thing for other browsers just because they’re implementing cutting edge features?
It’s a disappointing day when you find a single serving site that generates the comprehensive syntax for the border-radius property, aptly named border-radius.com. Because not all browsers (and browser versions) support the latest and greatest things CSS3 can do, one has to resort to browser targeting yet again. Only this time, one browser’s syntax is different from another browser’s, and becomes a chore to write CSS for each.
There’s a pretty obvious explanation for the existence of browser-specific properties from SitePoint:
Vendors—browser makers—are free to implement extensions to the CSS specifications that, in most cases, are proprietary to their browser. They may do this for a number of reasons, such as adding new features for users, or for experiments and debugging. Most often, though, the extensions are used to release and test browser features that have been developed in the preparation of W3C drafts that have not yet reached Candidate Recommendation status—the extensions allow these new properties to be widely tested before they become available as standard CSS properties.
So for starters, the browser-specific CSS has prefixes like:
-moz: Gecko-based browsers like Firefox-webkit: WebKit-based browsers like Safari and Chrome-ms: Internet Explorer-o: Opera-khtml: Konqueror
(The complete table is listed at the W3C.) That’s fine, but what I don’t get is why the syntax following the prefix isn’t always the same as the standard CSS syntax. The border-radius property is just one example, which is peanuts compared to the gradients syntax. Compare:
-webkit-gradient(
linear,
left bottom,
left top,
color-stop(0, rgb(0,10,148)),
color-stop(1, rgb(45,58,246))
)
-moz-linear-gradient(
center bottom,
rgb(0,10,148) 0%,
rgb(45,58,246) 100%
)
Sure, we can turn to generators like WestCiv’s and Damien Galarza’s—and we’ll probably be increasingly dependent on them in the future as CSS capabilities and their corresponding syntaxes grow more complex. But why must browser vendors insist on that when it only multiplies the code and maintenance necessary? Does it have to do with the way their engines parse the code, or something less significant?
The Apple stories just don’t stop coming, do they? Here’s yet another provocative issue concerning the company, but this time with web development: the iPhone is the new Internet Explorer 6, according to Peter Paul Koch.
The iPhone has become an obsession. If we don’t pay attention, we’ll have a mobile web that only works on the iPhone. And then we’ll have the real mobile web that wasn’t made by us and doesn’t give a shit about web standards and best practices.
Worse, it seems web developers are happy with this state of affairs. It seems web developers are congratulating themselves on excluding 85% of the smartphone users. They certainly never bother to check their sites in S60 WebKit, the largest smartphone browser in the world.
Fucking dimwits.
We’re doing exactly the same as ten years ago. We now say “iPhone” instead of “IE6,” but otherwise nothing’s changed.
No, wait, there’s one more change: the iPhone has far less mobile market share now than IE6 had desktop share back then.
The once most advanced browser is now the most hated, and the same fate could happen with the iPhone and its mobile web browser. However, given that they were made by two very different companies—the oft-hated Microsoft and the much-adored Apple—it’s hard to imagine the revolutionary smartphone gaining a stigma someday. An interesting achievement if that does somehow happen, but what an unfortunate future that would be.
Still, I have two points to make. First: I’m glad that a reputable voice is finally calling out this obsession with creating custom-tailored websites for the iPhone, when it’s supposed to have the most advanced browser, displaying pages as they normally would on a regular computer. Chances are you don’t have to. That’s what the multitouch zoom gesture is for, so that the screen size wouldn’t be such a hindrance.
Second: hype, here we go again. PPK draws back the curtain and tells us that there are other devices far more popular than the iPhone, yet the buzz about mobile web development is strongest with iPhone apps and iPhone app-like websites. It goes against the very idea of web standards, of making websites work in as many platforms as possible, not just what gains the most attention and is considered cool. (As an aside: what can be said about implementing CSS3 properties via browser-specific extensions? Is it the same thing?)
Finally, a minor third point: Koch isn’t addressing every mobile web developer in his article, just the ones that are so caught up in this iPhone-loving bubble that it’d be a shame when they mislead impressionable developers branching out to the mobile arena.
And a far worse shame if because of the hype we somehow get stuck in the rut that is IE6 all over again.
Eric Meyer has started poring over the WaSP community’s suggestions for CSS3 with a series of posts on his weblog—3 so far in less than a week. The original feedback compiled by Fantasai is a monstrous read in itself, but all these are worth perusing if you care remotely about the future of web design.
It’s comforting to have one of the gurus like him to really go over this. Although he didn’t promise to address every single point on the list, what I’m seeing so far is extremely comprehensive. More importantly, we have a strong figurehead that’s rolling up his sleeves and setting up these blog posts as the stage for discussion with people who are not necessarily involved with the W3C and other stakeholders like the browser vendors.
Between debating over specific CSS features (e.g., containing floats, center positioning, selector blocks) and looking at the bigger picture…
Maybe CSS isn’t the place for this. Maybe there needs to be a new layout language that can be defined and implemented without regard to the constraints of the existing CSS syntax rules, without worrying about backwards compatibility. Maybe that way we can not only get strong layout but also arbitrary shapes, thus leaving behind the rectangular prison that’s defined the web for almost two decades.
I don’t have a concrete idea to propose here, because it’s not up to us any more. A solution was worked out over the course of several years and then found wanting by the implementors. Really, it’s up to the implementors to figure it out now. I personally would like to just lock the browser teams from Microsoft, Mozilla, Opera, and Apple in a room and not let them out until they’ve defined something that works and they’ve all agreed to implement soonest. I might even supply food and water.
…we have to keep talking and stay restless but hopeful. We may not be able to give the final word on the next version of HTML and CSS and the web browsers, but we can talk about what could go into them while the W3C listens.
IE6 is declining. HTML5 is gaining traction. JavaScript libraries and CSS frameworks abstract the process of squashing browser bugs and incompatibilities. And progressive enhancement reassures us that we don’t have to serve up exactly the same features in ancient browsers.
And maybe we can stop acting like the current technologies are our handicap and take the plunge. Okay, maybe splashing water all over might not be a good idea at once. Try dipping your toes. Try your left leg. Try wading. The key is to at least try.
You can never run out of things to talk about when it comes to cascading style sheets or CSS, but lately there have been developments that are more than worth your while. CSS3 is slowly but surely becoming mainstream thanks to several browser updates, while the gurus continue to think up smart ways to code those stylesheets.
Update: Ajaxian blogs that WebKit will support CSS variables. Amazing news that has come out just in time with this blog post. I’ve listed it below as well.
Tools and Frameworks
I’m not going to mention every imaginable CSS framework and piece of software out there, but these are worth looking at.
Stylizer: Skybound Software comes out with perhaps one of the most interesting (read: intuitive) CSS editors to date. It helps that it has a free version with a 14-day trial for its Ultimate counterpart.
YAML: Smashing Magazine shows how it is possible to create a flexible layout using Dirk Jesse’s HTML/CSS framework called YAML. The YAML Builder is an excellent plus.
CSS Cacheer: Shaun Inman releases a mini-application for CSS caching.
Best Practices
Here are some great nuggets of advice that will help guide you when writing your own CSS.
Font Stacks: The Unit Interactive blog lists various scenarios in which you should order your CSS font stacks. A PDF file is available for download, too.
Fun With Floating in the Grid: Devlounge recommends several practical CSS classes and layout techniques to achieve hassle-free floats and grids.
Performance Testing: jpsykes reports how the different browsers fare using different CSS selectors and attributes.
Faux Absolute Positioning: A List Apart comes up with a new layout technique that does away with hacks.
Nesting Specifics: DZone goes into the nuances of CSS selector specificity.
CSS3 and Beyond
If you’re still hesitant to use CSS3, you might change your mind now that some of the most popular browsers are slowly incorporating support for it.
Firefox 3: Killian Valkhof and David Baron write about support for several CSS3 features in the latest version of Mozilla Firefox. These include ligatures, kerning, font-size-adjust, inline-block/inline-table, and even text-shadow—coming in Firefox 3.1. The complete list is on Mozilla’s official page.
Opera 9.5: The Opera Developer Community discusses the CSS3 features its own browser supports, namely, @media, text-shadow, opacity, HSL values, overflow-x/overflow-y, :firstof-type, :nthchild, -o-background-size. Not to mention HTML 5 elements and SVG. Don’t forget to check out Opera’s debugging tool, Dragonfly.
Safari 3 has been out for a while now, but it’s Internet Explorer that we’re really waiting for. Unfortunately, IE8 will continue to lag behind.
Qualified Selectors: Shaun Inman proposes a different breed of CSS selectors.
CSS Variables: David Hyatt announces that WebKit now supports CSS variables as documented here.
Beautiful, practical, flexible typography on the Web is practically non-existent and still remains a web designer’s dream. We’ve drawn a few steps closer through Flash- and CSS-based inline replacement techniques but at the price of accessibility and elegant code. Fortunately a member of the W3C’s CSS Work Group, Jason Teague, volunteered to be the primary advocate for the CSS3 typography modules. And he’s asking for our input.
These are the typography modules for CSS3:
CSS Fonts Level 3
…contains the properties to select fonts, as well as properties for font “adjustments”, such as emboss and outline effects, kerning, and smoothing/anti-aliasing. Font selection is identical to the similar section in CSS2. The font adjustment properties are new to CSS3.
CSS Web Fonts Level 3
…provides syntax for describing fonts: their name, their style, which characters they cover and also where to download them from. Adding such descriptions to a style sheet allows a designer to be more precise in font selection and, if the browser supports font downloading, to use fonts that people are unlikely to have installed, including fonts that the designer created himself for the purpose. Web fonts are also used by SVG and, conversely, one can use SVG to create fonts for download. Web fonts existed already in CSS2.
If you ask me, and I’m speaking as a non-expert in typography, I just want the type size renderings to be normalized across all browsers first. With all the new properties about to hit as CSS3 becomes mainstream (it’s working on Safari already), web designers will face even more problems just trying to keep websites sane-looking across different browsers.
Problem is, the W3C is not the right venue for raising this problem since it’s the browser vendors that render styles differently. And I’m not just referring to Internet Explorer here. We all want pixel perfection, do we not? But is it even possible? Not having to choose between px, em, and pt font sizing would be a good starting point.
Regardless, it’s good that there’s an open communication line between the general Web community and the working group. It doesn’t matter if you’re a type fiend or a casual web surfer. All you have to do is leave a comment (you have to register first), and your voice will be heard. So, what have you been wishing for when it comes to web typography? Sound off at Jason’s blog now!
*/
