Re: Offline transcript

On Wednesday, December 19, 2012 at 5:21 PM, Clint Hill wrote:

> I have questions/concerns regarding this part of the dialog ….
>  
> Marcos said:
> > I think not screwing yourself and your users over on wrong assumptions is a big benefit.
>  
> I want to understand this notion you have that in any prollyfill or polyfill we would _not_ be doing things on assumptions. I think you have an understanding that I don't and I think I might be wrong.
>  
> It's all assumptions right? A prollyfill is assuming a signature/API to be standard someday.
Kinda, a prollyfill is some idea that the author *hopes* will be standard some day - but may or may not be.  

For example, my implementation of the Web MIDI API does not follow the spec because I don't agree with some of the decisions the Editors have made (and I'm trying to convince them that my approach is better). However, if I get bored and decide to move onto other projects, but people continue to use my code, then it's best that my prollyfill does not override the real implementation in the end… hence, it's best that I prefix it (IMHO).  
   
> A polyfill is assuming that a standard signature/API is to work a certain way.  

Yes, it's based 100% on a standard… or it should be! If it's not, that's bad.   
> Both could be totally wrong. As example I would point to HTML 5 input types and the polyfills that implement completely different UI than each other and different than what the UA might implement.

No, in this case is ok. The HTML5 does not specify UX stuff. It's ok for polyfills to divert there from the UA. It's impossible to replicate the UA's inputs, in some cases because it's a security feature (i.e., users need to know when it's the browser speaking and when it's the web page speaking).     
> I think the point I'm trying to make about the prefixing is … in my humble opinion … is that it's an additional flag on implementation code that in all cases is unnecessary due to better and more declarative ways of designating an prollyfill.

Yeah, I get that. And I initially thought the same thing… but I'm starting to think that the costs outweigh the benefits. However, I would like to see code that makes this safe as you suggest.

Like in the MIDI thing, I'm just doing this:  

if ('getMIDIAccess' in exports) {
return; // namespace is taken already, bail!

}  
>  
> And lastly I think I want to re-emphasize my understanding of our mission (because again I think I'm wrong). The idea about Extensible Web is that authors are in control of the experience. They would not be constricted to UA limitations. It seems to me that we would want a world where I can use "assumed" signature/API and declare which prollyfill would implement it and that the script assures that native implementations would not interfere in a detrimental way.

Again, kinda… but we are still working with browsers of today and tomorrow. And the risk is that someone will want to use a prollyfill in production today.   
> I defer to the smarter brains in the room; I'm just trying to provide an excellent authoring experience for nExt Web. Prefixing makes my skin itch.

I'll also defer to the smarter brains :) But like I said, I would like to see some code. I work better from looking at code that I can throw test cases at.  

--  
Marcos Caceres

Received on Wednesday, 19 December 2012 17:35:23 UTC