Hi there,
Justin and I have been pairing on FLUID-4794 which involves improving the
current Progressive Enhancement infrastructure. We've chatted a bit with Colin
and Yura and have some ideas for a solution that we would like some feedback
on. Please see below for details.
Thanks,
Michelle
Goals for Progressive Enhancement:
1. Accommodate differences in a) browser feature support (i.e. HTML5 features)
and b) client and server environments (i.e. Node versus browser) by determining
what features are available in the current context and delivering the best
possible experience.
2. Support the ability for component creators to add new feature checks easily.
3. Check only the features required for the components being used in a
particular application or on a particular page.
Current Implementation:
Our current implementation is being used by the Uploader component. The
implementation consists of a predefined set of features that get checked and
put into the static environment on page load, and a component that takes an
ordered set of features and returns the first available feature. The Uploader
is wrapped by this component in order to deliver the best possible experience
based on the context in which it is being used.
There are some issues with the current implementation that we would like to
improve upon.
1. The use of a wrapper component complicates the API for users of the
underlying component.
2. There is currently no easy way to extend the existing set of feature checks.
3. All of the existing feature checks are run when Progressive Enhancer is
used, whether or not we care about them.
4. We require a separate instance of the Progressive Enhancer for every feature
set we care about.
Proposed solution:
The solution we have been talking about involves using demands blocks as a way
to state what features are required for a particular context. For example,
Uploader has three possibilities that we want to deliver in this priority
order: Binary XHR, Flash and Single File. In order to specify this, we would
put the Single File component in the defaults block and have demands blocks
that would deliver the other implementations when it's possible. One complexity
comes up when we try to specify the priority order of Binary XHR and Flash. We
would naturally have individual demands blocks to deliver each of those
implementations, however, we would also require a third demands block that
would deliver Binary XHR when both Binary XHR and Flash are available.
This would work today, however, there is more that we need to do to meet goals
2 and 3 above. Currently, we have several checks that we perform when
Progressive Enhancement loads and we store the results of the checks in the
static environment. This works well, because by the time we need to actually
determine which features are available (at the time of demands resolution), the
checks have been done. This issue we run into, is providing a way for people to
add new checks and only have checks they care about run. For all of this to
work, we need to have the relevant checks performed prior to component
initialization and demands resolution. The correct time is likely at the point
of demands registration. This requires us to modify the framework to recognize
when an action needs to be carried out early and actually do that action. One
possibility is to keep the demands API exactly as it is now, but have the
framework do a little extra when it encounters a context that it does not know
about yet. Instead of just progressing, it could look for a free function by
that name and execute it. This might look something like this:
fluid.demands("myComponent", ["browser.html5Track"], {
funcName: "myComponent.html5Impl"
});
browser.html5Track = function () {
// determines whether or not html5 Track is available
};
// Framework puts something in the static env to denote that we've checked for
html5Track and whether or not we have it
------------------------------------------------------------------------
Michelle D'Souza
Senior Inclusive Developer
Inclusive Design Research Centre, OCAD University
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
