Re: HDP: Revised "Degrade Gracefully" Principle

Maciej Stachowiak wrote:
> 
> 
> I revised the "Degrade Gracefully" principle.
> 
> http://dev.w3.org/html5/html-design-principles/Overview.html#degrade-gracefully 
> 

Further to my comments on the Support existing comments principle, it seems that 
the text currently explaining this principle may fit better under don't reinvent 
the wheel or pave cowpaths.

As an author, I adopt the principleof providing html that works not multiple 
versions for different audiences. I see that as the role of the HTML standard. 
It is basic stuff that will work across environments. A browser or authoring 
tool that conforms, even though limiting, would be more attractive to me than 
one which provides bells and whistles.

Marghanita

> 
> 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
> 
> 
> 
> 


-- 
Marghanita da Cruz
http://www.ramin.com.au
Phone: (+61)0414 869202

Received on Friday, 21 September 2007 23:34:03 UTC