-
Notifications
You must be signed in to change notification settings - Fork 25
Roadmap: Framework v1.3: JS Interactivity
JS Interactivity 1.3 seeks to provide a set of semantic markup through entity classes that allow a user, without writing complex Javascript or worrying about device-to-device differences, to add rich native-like feel to their application.
To accomplish this, this API focuses on several baseline paradigms:
- Trigger/Target - Interaction with a trigger causes an action on the target.
- Touch/Gesture - Support for touch and gesture events, beyond the standard mouse events.
- Markup, not Programmatic - Use entity classes (CSS in markup) rather than Javascript programming.
In this specification, the composition of each feature will be explored, followed by proposed interfaces.
In order to accomplish markup-driven interactivity, JS Interactivity 1.3 will use a trigger/target paradigm whereby one will designate a trigger with .t-{name} and the target with .{name}. For example, .t-ele1 is a trigger for .ele1.
In order to maintain reasonable efficiency with selectors, the trigger will also require an additional class such as .touchable to invoke the trigger/target handler. When classes like .touchable do not make semantic sense, it will instead provide a .trigger class that also invokes the handler.
For libraries where touch and gesture events make sense (transitions, expandable/collapsible, etc.), JS Interactivity 1.3 will provide a markup standard for denoting entities where such interactions are valid triggers.
In order to load the maximal content onto the page, but make it minimally visible until the user interacts with it, JS Interactivity 1.3 will provide a markup standard by which one may mark a set of elements as expandable (targets), and then use the trigger/target paradigm in order to actually drive the expansion or collapsing of the elements.
In order to provide markup-driven transitions that leverage CSS 3 and Javascript, and do so in a semantic nature so that the content provider does not need to worry about device-by-device differences in support, JS Interactivity 1.3 will include a transition library that provides a clean and simple mechanism for writing markup-driven transitions and degrading gracefully where not supported, based on the trigger/target paradigm.
As a compatibility note, MWF 1.0-1.2 provided a pair of limited Webkit-reliant transition libraries. MWF 1.3 will deprecated these in favor of a library that is (1) compatible with Webkit, Mozilla and Opera, and (2) includes a more robust, flexible and intelligible scheme for gesture support.
This library will override standard links to instead perform AJAX calls to load in the body content of a page between #header and #footer. This will provide several benefits: (1) going "back" does not require a page load, (2) a user won't be staring at a blank page while content loads, and (3) it is possible to use transitions as pages move in and out.
For browsers that do not support AJAX fully, it will instead simply load the requested page.
Mobile sites often present more content than is readily consumable on the screen. Therefore, this library will interpret user input and search entities within for the provided term, hiding those that do not contain it. It will also provide the ability to register a callback when filtering occurs so that one may extend the standard on-page filter functionality.
It should be noted that the intent of this is not to provide AJAX-driven suggestions. That is a separate sort of feature, though one that could be implemented by registering a callback on user input. Instead, one will define a text box with the filter terms, an entity set that is searchable, and the granularity of the entities that should be associated with found text within a region.
Much of the functionality in JS Interactivity 1.3 relies on the trigger/target paradigm.
In terms of interface, a target is defined with a class name such as .ele and then it's trigger is denoted by a pair of class names, namely .trigger.t-ele. For convenience, it is also acceptable to have .trigger with .t-ele as a child. However, the latter has a performance cost entailed if there are other elements within .trigger that are not actually triggers.
When a trigger is selected, the trigger/target engine must then decide what do target. It will strip the t- prefix and then search for elements matching the rest. For .t-ele, it will select elements .ele. Once it has selected the elements, then it will attempt to determine what sort of effect should be applied. While the details are expressed in later interface sections, consider the example where .ele is encapsulated by .expandable. This denotes that .ele is to be expanded based on the JS Interactivity 1.3 expandable/collapsible library.
As a note, if .t-ele is defined on an element that has multiple effects such as .expandable and .transitionable, the trigger/target library will select the nearest parent. Therefore, if the element ele is of the form .expandable .transitionable .ele, then it will perform the transition effect, whereas if it is of the form .transitionable .expandable .ele, then it will perform the expandable effect.
One may avoid this sort of issue by defining a direct sibling class name prefixed with s- (for set) in both the outer effect class and the same class on the inner transitioning element. For example, when .t-ele1 is fired, if the form .expandable.s-eles .transitionable .s-eles.ele1 exists, then the expandable effect will still occur even though the transitionable element is define more closely, as it will seek out the nearest parent with the same set definition. If both parents contain a class prefixed with s-, however, then it will still select the nearer, so .expandable.s-eles .transitionable.eles .s-eles.ele1 will invoke the transition effect, not the expandable effect.
The basic prototype for expandable content:
<div class="expandable ele1">
<h2>Target for Ele1</h2>
<p>Some paragraph text for ele2</p>
</div>
<div class="expandable ele2">
<h2>Target for Ele2</h2>
<p>Some paragraph text for ele2</p>
</div>If one seeks to apply transitionable to a set of direct children, the following is valid:
<div class="expandable">
<div class="ele1">
<h2>Target for Ele1</h2>
<p>Some paragraph text for ele2</p>
</div>
<div class="ele2">
<h2>Target for Ele2</h2>
<p>Some paragraph text for ele2</p>
</div>
</div>The direct form for triggers:
<a href="#" class="trigger t-ele1">Element 1</a>
<a href="#" class="trigger t-ele2">Element 2</a>A convenience form:
<div class="trigger">
<a href="#" class="t-ele1">Previous</a>
<a href="#" class="t-ele2">Next</a>
</div>One may also define an element as not collapsible with either .expandable.not-collapsible or with .not-collapsible on the target element with .expandable as a parent class. The same is possible with .not-expandable to only allow the element to be collapsed, not expanded.
The basic prototype for transitionable content:
<div class="transitionable [slide-x|slide-y|slide-xz]">
<div class="eles">
<h2>Transitionable 1</h2>
<p>Some paragraph text</p>
</div>
<div class="eles">
<h2>Transitionable 1</h2>
<p>Some paragraph text</p>
</div>
</div>If one seeks to apply transitionable to a set of direct children, the following is valid:
<div class="transitionable children [slide-x|slide-y|slide-xz] eles">
<div>
<h2>Transitionable 1</h2>
<p>Some paragraph text</p>
</div>
<div>
<h2>Transitionable 2</h2>
<p>Some paragraph text</p>
</div>
</div>These transitions are triggered by an element denoted via a class with t- prefix and .next or .prev defining the transition direction.
The direct form for triggers:
<a href="#" class="trigger prev t-eles">Previous</a>
<a href="#" class="trigger next t-eles">Next</a>A courtesy form for triggers:
<div class="trigger t-eles">
<a href="#" class="prev">Previous</a>
<a href="#" class="next">Next</a>
</div>Such triggers are supported anywhere within the DOM, including within the transitionable set:
<div class="transitionable children [slide-x|slide-y|slide-xz] eles">
<div>
<h2>Transitionable 1</h2>
<p>Some paragraph text</p>
<a href="#" class="trigger next t-eles">Next</div>
</div>
<div>
<h2>Transitionable 2</h2>
<p>Some paragraph text</p>
<a href="#" class="trigger prev t-eles">Previous</div>
</div>
</div>A trigger is also supported for a distinct child:
<a href="#" class="trigger t-ele1">Trigger for ele1</a>WARNING: In this format, the library will leverage the trigger/target engine to select the nearest target-like parent, which may be .transitionable or may be another target like .expandable. As such, a .transitionable and .expandable should not both be leveraged using the same target element class name, or the behavior may be unanticipated: the target/trigger engine will select the nearest parent, so if this is .expandable, then the engine will use it and perform an expansion of the content area rather than .transition to transition to the element. (QUESTION: Should this instead simply throw an error?)
This is the recommended format for such targeting:
<div class="transitionable [slide-x|slide-y|slide-xz] s-eles">
<div class="expandable">
<div class="s-eles ele1">
<h2>Target for Ele1</h2>
<p>This will be transitioned to by .t-ele1</p>
</div>
<div class="s-eles ele2">
<h2>Target for Ele2</h2>
<p>This will not be transitioned to by .t-ele1</p>
</div>
</div>
</div>In most cases, however, it makes sense to extricate the two, but because of ambiguity discussed above in Interfaces > Trigger/Target > Avoiding Ambiguity in the Trigger/Target Selector, this rule of precedence does exist.
Coming soon..._
Coming soon..._