Architecture
While the library may actually be productive with a little more elaboration, my original objective was to develop a proper extensible framework for CSS prollyfilling. Hence the basic architecture of the library was designed with this in mind.
One of the main drivers for writing an extensible framework is that at this point it's not easy to ensure that different prollyfills in a single page will play well together. Even if by some incredible coincidence they do, CSS shims usually include some sort of parser, some processing every time the layout changes and also require time to load individually. A unified framework would avoid duplicating all this effort and thus be more efficient, simultaneously raising the probability that extensions don't interfere with each other.
There's still a lot of work remaining until it gets there however. But what I've done so far has also helped me to get a better idea of the requirements, which I'll attempt to describe in this document.
The idea behind CSS is pretty intuitive. The implementation of a CSS engine, whether native or shim, is not a trivial undertaking. To make the task approachable however, I'll just focus on the prollyfill engine.
There are many ways, and many places where a CSS document, and a polyfill engine, affects the processing of an HTML document. Most of this takes place however when the layout has to change, usually during the resizing of the hosting window. It is at this point that the framework generates CSS code that it places at the end of the <head> element, where its declarations will take precedence over style definitions placed before in the document head. Even there, the processes involved are varied and depend on the nature of the different CSS declarations.
Without further ado, let's delve into the inner workings.
The script is best placed at the bottom of the HTML document, allowing the page to load and display and ensuring that the <style> and <link> tags are already declared. When the script starts, it will search, load, parse and tokenize all CSS resources. Though not implemented yet, the extensible framework at this point should load whatever polyfill extensions are desired by the web page designer.
Each 'plugin' extension should include a detector, to verify its services are actually not implemented by the browser. Failing detection, they will activate themselves within the framework.
How they activate themselves, and where they will hook into the framework depends on the nature of the CSS functionality they implement. For example, the vh/vw/vmin units at this point affect the processing in two spots. During initialization they select which CSS properties make use of the units, and during window resizing they build replacement properties in px units to be included in the generated CSS.
Meanwhile, media queries generate code when tests executed at window resize time indicate it should be active at those window dimensions. If they're indeed active, then all CSS code inside the media queries should be output in the generated CSS code unwrapped of any media query selectors as these were determined to not be supported by the browser at initialization. Other extensions, such as the v* units, should still be processed inside the media query's CSS. This means that an extension has to do its stuff and hand control back to the engine so that it can continue normal processing.
###Interlude
Though I believe it's a proper foundation for an extensible framework, the present incarnation of my shim is monolithic. I chose the v* units and media queries because, having them is enabling as far as responsive web design is concerned (demo), they're different enough in their behavior that it's a good exercise in architecture to make them work together in a single prolly and it partly paves the way for implementing the intended extensible framework.
At this point I have a good idea of how these two features could be implemented as extensions in such a framework.
Having said that, CSS is broad and there are probably many more extension points to consider for other characteristics provided by CSS. Selectors, for example, will probably work similarly in implementation to media queries. But I haven't analyzed the requirements of the many features of CSS currently not implemented in browsers. Some CSS properties, such as box-shadows, probably require generating HTML elements such as <canvas> and this is still not contemplated in the current design.
And of course many proposals for standardization may come up with unpredictable requirements on the framework as of right now. Though with some careful analysis we may be prepared for some of these, others will of course have to be dealt with at that point.
It is here that I think that such a framework can benefit from a communitary dedication towards its design and development. This document is intended to elucidate on the inner workings so as to promote understanding and encourage participation.
###Limitations
For performance reasons, and also simplicity of architecture and implementation, element style attributes are not processed, so v* units in these will not work with the shim.
More to come (diagrams!) ...