Re: The Extensible Web Manifesto [via Extensible Web Community Group]

On Wednesday, June 12, 2013 at 12:12 PM, François REMY wrote:

> > better but the sentence still doesn't make sense ;)
>  
>  
>  
> Here's yet another phrasing:
>  
> The second reason an extensible web is more beautiful is that, even though
"Beautiful" is problematic, IMO. Let's try to avoid getting too flowery with the language as the message gets lost.  

Also, "The second reason *is that* an" or "The second reason *being that* an".  

> APIs are crafted by smart people in standards committees, mistakes can be  
> made from time to time. Don't get me wrong, mistakes are normal: no process  
> can be free of mistakes. However, the problem with the current standards  
> process is that mistakes are basically irreversible; it's difficult to  
> experiment.

This is only partially true. There are times when things have been reverted or pull back (e.g., when Web Sockets was found to have a security bug - Opera pulled it). Also, CSP closes down a lot of security holes on the Web, etc. in a clever way.  

So, maybe just say: "features without a long period of experimentation tend to fail more often, as is evident with things like localStorage and AppCache" or something.  

Also, the trend to put APIs behind about:flags kinda tries to address this problem. It doesn't expose that functionality on the open Web, like -vendor prefixes did - which caused a huge f'ing mess.  

What you really want to be discussing here is that experimentation using primitives can create defacto standards which can sometimes benefit from becoming core parts of the platform (e.g., Future's long legacy in JS libraries). You can also discuss, as an example, how jQuery's custom selector engine allows apps to do interesting things today (in a future and backwards compatible way), which are only now making their way into specs.  

So - this does not diminish the role of Working Groups: it puts them in a position to look at the landscape, and try to pick out the best of breed solutions that can benefit the most users (end-users/devs) in an interoperable way (again, Futures). This also makes the role of this group important, as a way of monitoring the landscape to see what should potentially be standardized. Other Working Groups, need to continue pushing the platform forward by standardizing things that are simply impossible to do today (e.g., SysApps WG).  

This group also needs to provide guidance on how to write a prollyfill that can best serve users and makes it easy for working groups to standardize.  

HTH.  
--  
Marcos Caceres

Received on Wednesday, 12 June 2013 15:01:58 UTC