Year: 2008

Categories
Technology Web

Progressive Enhancement and Graceful Degradation

A List Apart has a timely article titled Understanding Progressive Enhancement discussing the perceptual differences between graceful degradation and progressive enhancement. I enjoyed seeing Steve Champeon’s idea given new light. Additionally, now is as good a time as any to have a go at these topics, with the many new enhancements being added to today’s browsers, while antiques still cutter cyberspace. I could have done without the cloyingly cute M & M analogy in the article, but that’s probably my inner Cranky Woman having a go this AM.

I’ve written about graceful degradation, previously. Graceful degradation means applying modern technology but ensuring the application doesn’t negatively effect those viewing a web site with an Antique (remaining nameless). However, contrary to the ALA author’s statement of Under this paradigm, older browsers are expected to have a poor, but passable experience, graceful degradation is just that: gracefully degrading, meaning that though the person using the Antique doesn’t get all the bells or whistles, their experience at the site is more than “poor but passable”.

Progressive enhancement, on the other hand, begins with the content, rather than the technology; ensuring that the markup used to organize the content is semantically correct and valid. Then, and only then, the web site developer progresses to the use of CSS and JavaScript, both to annotate and enhance the content. That’s been the primary difference between the two approaches: graceful degradation tends to focus on technology, first, while progressive enhancement focuses on content, first.

Of course, the two are not exclusive: one can use progressive enhancement techniques, beginning with the content outward, paying particular attention to the semantics of the markup, and then apply the technique of graceful degradation when applying CSS and JavaScript. In particular when using Content Management Systems, such as Drupal and WordPress, it’s important to not neglect the semantics by focusing overmuch on the themes, widgets, and other, frequently annoying, gewgaws.

Categories
Political

Palin is a bitch and I’ll gladly go to hell

From Huffington Post:

At a rally on Saturday in California, Sarah Palin offered up a rather jarring argument for supporting the Republican ticket. “There’s a place in Hell reserved for women who don’t support other women,” the Alaska Governor said, claiming she was quoting former Clinton Secretary of State Madeleine Albright.

The statement came after Palin had recounted a “providential” moment she experienced on Saturday: “I’m reading on my Starbucks mocha cup, okay? The quote of the day… It was Madeleine Albright, former Secretary of State [crowd boos] and UN ambassador. … Now she said it, I didn’t. She said, ‘There’s a place in Hell reserved for women who don’t support other women.'”

By the way, I categorically deny that I’m endorsing Palin.

Categories
SVG

Playing the game

Lars Gunther at WaSP just posted an article on ACID3 and what it really means. Though Webkit may be the first truly out the door, what’s really important is playing the game:

In the end the winner is neither Webkit, Opera, Mozilla nor Microsoft, but developers who get more powerful features to work with and more consistency between browsers. And that means that in the long run they are able to focus on user experience, not browser shortcomings. This means that the true winner of Acid3 is anybody who surfs the web.

He also goes on to mention that ACID3 is really only one test, and there are others that test individual components, such as support for JavaScript, SMIL, CSS, SVG, and so on that are more comprehensive.

But the real point of Lars’ writing is that the browsers are playing the game, and in the end, we all benefit when they do. However, I am forced to point out one thing missing from his assessment of what each browser supports: IE does not support SVG. IE has never committed to supporting SVG. It’s unlikely IE will ever support SVG, as it competes with its own Silverlight implementation.

I’m currently creating a suggested class plan for a class in SVG for the WaSP’s web education series. Included in it will be a bullet to cover whatever tools enable an SVG-like experience in IE. However, what works for IE8 probably won’t work for later versions of IE, as we don’t have a commitment from Microsoft as to what it will support, natively, in the future in regards to vector graphics. We can’t agree on what SVG will look like in HTML5 in the future at the moment, true, but we know it will be part of the specification. It will be part of the specification, or the specification won’t gain support, period. However, all indications are that SVG will be an optional component of HTML5, and if this is true, we can never expect to see a native implementation of SVG in IE.

Right now, we have decent implementations of SVG in the other three browsers, the Big Three of Firefox, Webkit/Safari, and Opera. More than that, we have a commitment from the Big Three to continue to support SVG in the future—yes even in whatever ends up in HTML5. We do not have the same from Microsoft. I can appreciate Lars wanting to give all browsers their due, and all due appreciations to Microsoft for finally implementing CSS 2.1, and for donating all the CSS 2.1 test cases, but no native implementation of SVG has inhibited the web developer in the past, and will continue to inhibit the web developer, and hence, the user’s experience, in the future. Microsoft’s checkered implementation of only what it wants to implement in standards makes it more spoiler than player.

Categories
Graphics/CSS

Gimp 2.6 released

GIMP 2.6 was released this week, with enhanced UI experience, as well as support for 32-bit color. The latter is particularly important as several web designers and photographers have focused on GIMP’s 8-bit support as their main reason not to use the tool. The 8-bit support is still the default, but you can turn 32-bit on, and the next few versions of GIMP should incorporate comprehensive support for both 32-bit and non-destructive editing.

The release is source code only at the GIMP site, though Lifehacker provides links and instructions for installing the tool in Ubuntu and Windows. The application has not been ported to Macports yet, and probably won’t be for some time. I am considering doing a source code build, something I normally wouldn’t touch. However, I really do want to see the new features, and in particular, the 32-bit support.

What makes the timing on GIMP 2.6 especially relevant is the fact that the days when we could spend thousands of dollars on software and equipment in order to work with our photos and web designs are over for most of us. I wasn’t joking when I said earlier that Frugal is sexy. Not buying is the new black.

When I have GIMP 2.6 installed, I’ll be back with a more detailed look. In the meantime, let’s hear it for 32-bit support. Let’s hear it for free.

Categories
XHTML/HTML

Distributed Extensibility

While I appreciate Mark Pilgrim’s This week in HTML5 land weekly reports, there’s one underlying thread that occurs every month that Mark doesn’t necessarily touch on: the issue of distributed extensibility. You know, the namespace, XHTML, SVG and MathML et al thing that doesn’t go away.

For instance, catching up on my HTML5 Working Group public archives reading, I found this gem from Chris Wilson of Microsoft:

You are correct, we cannot definitively say why XHTML has not been successful on the Web. However, I do believe that part of that lack of success is due to the less-forgiving XML syntax, and part of it is due to the degradation story (or lack thereof) in browsers and versions that don’t support it. (I don’t want to turn this into a pro/con XML debate either.) Part of its success in the future will be due to the important and focus it is lent by all of the major browsers. Perhaps I am misreading the tea leaves; I don’t see much interest in XHTML’s future from the other browsers. I do think XHTML would have a lot of positives as a basis; however, it does have a few negatives, and it would need to be a universal push if it were to be successful.

I would say that we can definitively state why XHTML has had limited success on the web: lack of implementation and support in IE, one of the web’s major browsers. In addition, none of the other browsers have said that they aren’t interested in supporting XHTML in the future. The fact that Microsoft’s main IE architect would make this statement leads me to believe he should be in politics.

And I’m only up to August in the archives. What other delights await in September and October…