HDP: Revised "Degrade Gracefully" Principle

I revised the "Degrade Gracefully" principle.

http://dev.w3.org/html5/html-design-principles/Overview.html#degrade-gracefully

There wasn't too much controversy over this one so I won't respond to  
comments in detail, but I made the following changes in response to  
feedback:

- I made it more clear that this principle is about content author  
conformance requirements, and making sure the conforming language  
allows new content to work in older browsers and other user agents.

- I made it more explicit what kinds of user agents might be  
considered particularly worthy of consideration for purposes of this  
principle, including not just the most popular mainstream browsers but  
also user agents serving specialized markets or communities.

- I made the wording of the principle less browser-centric.

- I listed some of the design approaches that might be used to enable  
graceful degradation.

- I added more detailed examples.


Some requested that the <canvas> example should be removed, because it  
is new relative to HTML 4.01 and we should not assume its presence in  
the editor's draft is final. It was suggested that either existing  
constructs from HTML 4.01, or completely made up constructs like  
<newelement> should be used instead.

I did not directly fulfill this request. I feel strongly that the  
examples in the design principles need to be genuine concrete examples  
of the principles in action. Made up examples don't aid understanding  
nearly as well.

In particular, fallback content isn't the only strategy used to allow  
graceful degradation, so using a hypothetical <newelement> instead of  
a real element using that strategy could create confusion. For  
example, <section> and <aside> are new elements, but they don't make  
use of fallback, instead their content is always expected to be  
displayed. The graceful degradation strategy for those is that their  
intended presentation can be emulated with a simple style rule.

So here's what I did instead. To address the concern that use in  
examples may make new elements, attributes or APIs appear to be a done  
deal, I made clear that the features in the examples are proposed, not  
final. To address the concern that the design principles document may  
become outdated if the spec changes, I commit to updating examples if  
the features they refer to are removed from the draft or changed. For  
this reason I also gave multiple examples, so that if one or two need  
to be struck, several others will remain.

I hope this is sufficient to address concerns, and that when reviewers  
look at the newly revised principle, they will see that the concrete  
examples make it easier to understand how to apply it.


Regards,
Maciej

Received on Friday, 14 September 2007 10:04:50 UTC