Re: Is polyfilling future web APIs a good idea?

 Do polyfills like WebReflection's DOM4 look promising?
No. Lets choose to not spoil a text-based markup language by trying to
emulate geometry. etc. There are other tools for geometry. HTML not suited
for  geometry.

'I feel it's more sustainable to bet on spec APIs.'
No. I prefer lets Focus on specific tags. Improve the tags and their
attributes.

MAKE THINGS BETTER BY 1% / AND THE OTHER 95% WILL…

Things I think w3c.org should work out:
CONTENTEDITABLE is an standard attribute.
http://html5demos.com/contenteditable

this thing DATALIST should be part of standard.
http://www.w3schools.com/tags/tag_datalist.asp

On Mon, Aug 3, 2015 at 7:09 AM, Glen Huang <curvedmark@gmail.com> wrote:

> I'm pretty obsessed with all kinds of web specs, and invest heavily in
> tools based on future specs. I was discussing with Tab the other day about
> whether he thinks using a css preprocessor that desugars future css is a
> good idea. His answer was surprisingly (at least to me) negative, and
> recommended sass. His arguments were that
>
> 1. the gramma is in flux and can change
> 2. css might never offer some constructs used in sass, at least with very
> low priority.
>
> I think these are good points, and it reduced my enthusiasm for future
> spec based css preprocessors. But this got me thinking about polyfills for
> future web APIs. Are they equally not recommended? Likewise, the APIs might
> change, and for DOM operations we should rely on React because the native
> DOM might never offer such declarative APIs, at least with very low
> priority. Do polyfills like WebReflection's DOM4 look promising? For new
> projects, should I stick with polyfills that only offers compatibilities
> for older browser, and for future spec features, only use libraries that
> offer similar features but invent their own APIs, or should I track future
> specs and use these "unstable" polyfills?
>
> I'm torn on this subject. Would like to be enlightened.
>
> My obsession with future specs based tools doesn't come out of nowhere.
> Coffeescript used to offer sugars for es5. But then es2015 catches up, and
> it looks obsolete, since its user base is likely migrating to es over time.
> The same goes for GSAP vs Web Animations. So I have this sense of feeling
> that technologies without the blessing of specs/browser vendors are likely
> to be abandoned eventually. So instead of investing on custom designed
> APIs, I feel it's more sustainable to bet on spec APIs. What's your take on
> this topic?
>
> P.S. I called out some projects. I, by no means, slight these projects and
> their authors in any way. The projects usually offer some useful higher
> abstractions and the authors are all extremely talented and I respect them
> a lot. This is more from users point of view, and about how they should
> choose which technologies to use.
>