- From: Marcos Caceres <w3c@marcosc.com>
- Date: Wed, 19 Dec 2012 17:59:41 +0000
- To: Clint Hill <clint.hill@gmail.com>
- Cc: François REMY <francois.remy.dev@outlook.com>, Brian Kardell <bkardell@gmail.com>, "public-nextweb@w3.org" <public-nextweb@w3.org>
On Wednesday, December 19, 2012 at 5:45 PM, Clint Hill wrote: > Further: My dislike of prefixing is to this point. I would prefer to write against a "standard" goal. Which would imply that I write my implementation against a "standard" API. While this means in prollyfill it wouldn't be a recognized standard by any standards body immediately it does mean that my implementation code is choosing it as "standard". This is perverting the definition of a "standard". A standard has to be agreed upon by a set of entities (or it may be a de facto standard - if it is not ratified by any authority and has a large enough market share). For example, jQuery is not a standard, but it's definitely a de facto standard: most devs know what $() is as the know what <!doctype html> is (which is standard). Anyway, lets not go too far down this rabbit hole. > If I as an author don't care about standards in any way - I'm happy with prefixing. On the other hand if it's important to me than prefixing feels wrong. Ok, so, you are making the assumption that all authors are good and will continue to maintain their code. I'm assuming authors get distracted or start working on other things … projects come and go. As such, I might not want unmaintained code overtaking native browser stuff (e.g., the prollyfill might have bugs and security issues). As a dev, I accept the risk when I choose to bind my application to some version of some prollyfill. However, as I said before, if you can come up with some code/scheme that makes using a prollyfill safe, then I'm all ears. -- Marcos Caceres
Received on Wednesday, 19 December 2012 18:00:13 UTC