Re: Trusted shims and polyfills

Responses inline.

On Dec 10, 2012, at 6:00 PM, Fred Andrews <fredandw@live.com> wrote:

> Could the group please consider the possibility of trusted shims and polyfills so that even extensions such as noscript might still allow trusted polyfills to be used and that browsers might implement a mode between JS-enabled and JS-disabled that allows only trusted polyfills.  There is a great need to experiment with interactive declarative extensions for users wanting to work with JS-disabled and the work of this group might be able to help.  For example, the topic of interactive menus has come up again recently on the WHATWG list and I think it would help the development of the web if content authors could experiment with designs.

I would argue that NoScript is an end-user feature and not a prolyfill authors feature. Some end-users just don't want to experience the web. 

However I do think there is something to the idea that a prollyfill could be made to do scoping or "global ignore" for a particular DOM element. This seems to follow the same concept that the "scoped" attribute in HTML would achieve (http://www.w3.org/TR/html-markup/style.html#style.attrs.scoped).

While I don't have a clear idea in my head - conceptually I do believe this could be a prollyfill.


> 
> One option might be for the UA to store a hash for the resources to identify them.
> 

I would point you to the work that the WebApp WG is doing:

	http://www.w3.org/TR/widgets-reqs/#configuration-document
	http://www.w3.org/TR/2007/WD-widgets-reqs-20070209/#requirements_manifest

Maybe there is something there that can be re-used or referenced to achieve your identification.

> It might be expected that a polyfill is common code among many webpages, and could the group consider methods to avoid redundant storage of such resources, and also how they could work well offline.  Could a polyfill be loaded and managed as a browser extension, with a meta tag declaring the need for the polyfill?

Offline capabilities is also interesting, but I believe outside the scope of the prollyfill. That is mostly a runtime feature and/or dictated by the UA. Granted, features like storage make this possible, I just don't see it as a prollyfill directive.

> 
> With a lot of experimentation going on, there is bound to be some conflict, such as extensions that want to use the same attribute or element name.  Perhaps some thought could be given to ways this group could help manage such conflict - guidelines, etc.
> 

I totally agree thought needs to be given about conflict resolution. I would echo Brian's point about Hitch and how it provides a declarative identification (including version) and also point to the work that WebApp WG is doing for Web Components (decorator and isolation):

	http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html#isolation-confinement-and-encapsulation
	http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html#decorator-section

I think there is good ideas in Hitch on protecting from conflict as well as providing a discovery mechanism declaratively: https://github.com/bkardell/Hitch/wiki/Using-Hitches


> cheers
> Fred

Thanks Fred!

Clint