- From: James Graham <jg307@cam.ac.uk>
- Date: Mon, 04 Jun 2007 14:33:01 +0100
- To: Henrik Dvergsdal <henrik.dvergsdal@hibo.no>
- CC: HTML WG <public-html@w3.org>
Henrik Dvergsdal wrote: > > > On 1 Jun 2007, at 02:40, Ian Hickson wrote: > >> * Include links to relevant research on the wiki page. That could be: >> >> * Links to pages that are working around the lack of the feature >> being >> proposed. >> >> * Surveys (even of a few dozen sites) showing authoring practices, so >> that we can determine authoring patterns around the topic. (I might >> take such surveys to greater lengths if possible and useful by >> running similar types of scans at Google.) >> >> * Test cases showing what existing browsers do. >> >> Making proposals with no research is another good way to lose >> credibility fast. > > This requirement conforms very well to design principles such as > "Support Existing Content", "Don't Reinvent The Wheel", "Pave The > Cowpaths" etc. However, it effectively blocks out *novel* proposals that > may be related to principles such as "Solve Real Problems", "Media > Independence", "Universal Access" etc. I don't see that at-all. A link to a page that has to work around the lack of a feature in some sub-optimal way is a perfect example of how it would "Solve Real Problems". Indeed if you are unable to find such a link you will have to work much harder to convince people that the problem being solved is indeed real. Also, it is very important to understand how proposed features interact with legacy browsers so having test documents that use the proposed feature is very valuble. -- "Eternity's a terrible thought. I mean, where's it all going to end?" -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Received on Monday, 4 June 2007 13:33:13 UTC