Sorry, what? The browser has sorely needed extension and componentization capabilities for many years. Why should the W3C be the gate-keepers of what's allowed in HTML? That only leads to the invention of heavy-weight and balkanized UI frameworks. We can do much better than that.
> why the generic UI elements in Polymer, like Menu, Dialog Boxes, etc.., isn't part of HTML itself?
Because they shouldn't be. HTML should not be responsible for providing every possible UI element. In fact, I would argue that provides _far_ too many UI elements, and should instead provide low level user input APIs that can be used to build interactive elements.
And so web developers have to write basic UI widgets just to get basic UI elements. Or, to use a heavyweight component library that needs needs to be downloaded.
Thanks but no thanks.
HTML should provide a rich, declarative UI API by default. We shouldn't have to hunt down separate components to get that.
If you have to load Javascript, you have already lost.
A well regarded standard UI library, say jointly developed by browser vendors, could be CDN served and cached or even bundled with browsers eliminating the download cost with the massive advantage that it can be versioned independently of HTML and browsers and is optional in case a better library comes along.
> A well regarded standard UI library, say jointly developed by browser vendors,
This is commonly known as the web browser.
lol @ browser vendors deploying UI components via Javascript, when they could just as easily deploy them in the web browser itself as part of upgraded HTML specs.
