3 ms·
> Now, in 2015, it's more of the same, following Google Chrome instead of having a vision, sticking to it, and just implementing it. I disagree. This is 100% i
by chimeracoder 11y ago
> Now, in 2015, it's more of the same, following Google Chrome instead of having a vision, sticking to it, and just implementing it.
I disagree. This is 100% in line with Mozilla's vision (except arguably the Flash exception).
> They're also a source of cutting-edge and/or specialized functionality that isn't part of the browser and may never be.
That runs directly counter to Mozilla's vision for the Web as a dominant, universal platform. They're non-standard, oftentimes non-portable, and rarely provide functionality that couldn't be replicated in the browser[0].
> I mean, there's a reason plugins exist and I don't see that anything has changed to negate that.
Anecdotally, all the plugins that I can remember ever using - as far back as Shockwave during the 90s - were really just stopgaps that attempted to bridge the holes that have since been filled by HTML5 features such as audio, video, WebGL, etc.
What are the plugins that still exist that wouldn't be better implemented as web-native, and which don't make good candidates for extending the definition of what should be considered web-native?
[0] Rarely, not never. Though in the cases where they can't, it's worth thinking whether these should be added to the HTML5 standards - necessity is how we got stuff like WebAudio, after all.