At the moment, we prefix most components with ak- to prevent name collisions with other plugins, but I think we should take a more opinionated approach to naming by default, while still allowing the user to reconfigure/override if necessary.

Safari is not parsing this date format 2019-08-08 00:00:00
Lines: 46,47 file: /airkit/blob/master/dynamicdata/index.js
Evidence: https://screenshot.googleplex.com/7qaEy2z5wmL4CkG

Here's the trace I get when the watchjs event is triggered:

[...]/node_modules/airkit/gulp/compilejs.js:43
rebundle(bundler);
^

ReferenceError: rebundle is not defined
at Browserify. ([...]/node_modules/airkit/gulp/compilejs.js:43:5)
at emitOne (events.js:77:13)
at Browserify.emit (events.js:169:7)
at notify as _onTimeout
at Timer.listOnTimeout (timers.js:92:15)

It doesn't look like this should ever work since it's "rebundle_" and not "rebundle"

Like our super simple video fallback utility, we should have a way to conditionally show elements baed on dates stored in their datasets. This would be useful to simplify display of promotional or time-based content (client-side).

Sample usage:

var datetoggle = require('airkit/utils/datetoggle');
datetoggle.init();

<div data-ak-date-start="6/12/2015" data-ak-date-end="6/13/2015">
  Content displayed between 6/12 and 6/13
</div>

The attribute names would be customizable, and both attributes would be optional.

• Similar functionality to the youtubemodal module.
• If #<id> is present in the URL, show the modal by default.
• Support back button/history.
• By default, the modal will add a close button (similar to youtubemodal).
• class="ak-modal" required on modal element in order to automatically hide it from the dom. Similar to the video fallback module, we can inject a style when init is run to hide ak-modal by default, requiring the user to do nothing other than style their own content.

Sample implementation:

var modal = require('airkit/modal');
modal.init();

<a href="#" data-ak-modal-id="foo">Show</a>

<div id="foo" class="ak-modal">
  <!-- Modal content here-->
</div>

There should be a standard gulp task for airkit-based projects that applies browserify / uglify / watchify.

Airkit Grid

Airkit should have a basic grid system based on flexbox, living at airkit/grid. A SASS import of the grid system would be something like:

@import 'node_modules/airkit/grid/grid';

This requires users to use SASS in their projects for now, but maybe in the future we can pre-compile a version of the grid system as part of some release process for airkit.

The naming convention shall use BEM (block-element-modifier), as with all airkit modules.

Examples

Two-column grid (equal width columns):

<div class="ak-grid ak-grid--2-cols">
  <div class="ak-grid__item">1</div>
  <div class="ak-grid__item">2</div>
</div>

For non-equal width columns, assume a 12-column grid:

<div class="ak-grid">
  <div class="ak-grid__item ak-grid__item--3-cols">1</div> <!-- 25% width -->
  <div class="ak-grid__item ak-grid__item--9-cols">2</div> <!-- 75% width -->
</div>

Grid items that extend past 12 columns will wrap below:

<div class="ak-grid ak-grid--2-cols">
  <div class="ak-grid__item">1</div>
  <div class="ak-grid__item">2</div>
  <div class="ak-grid__item">3</div>
  <div class="ak-grid__item">4</div>
</div>

<!-- or: -->

<div class="ak-grid">
  <div class="ak-grid__item ak-grid__item--6-cols">1</div>
  <div class="ak-grid__item ak-grid__item--6-cols">2</div>
  <div class="ak-grid__item ak-grid__item--6-cols">3</div>
  <div class="ak-grid__item ak-grid__item--6-cols">4</div>
</div>

To reverse the rendering order of grid items, use ak-grid--reversed:

<div class="ak-grid ak-grid--2-cols ak-grid--reversed">
  <div class="ak-grid__item">1</div>
  <div class="ak-grid__item">2</div>
</div>

Grid items that have unequal heights can be aligned to the middle or bottom using the --valign-<position> modifier on either ak-grid or ak-grid__item:

<div class="ak-grid ak-grid--2-cols ak-grid--valign-middle">
  <div class="ak-grid__item">1</div>
  <div class="ak-grid__item">2</div>
</div>

<!-- or: -->

<div class="ak-grid ak-grid--2-cols">
  <div class="ak-grid__item">1</div>
  <div class="ak-grid__item ak-grid__item--valign-middle">2</div>
</div>

A project has requested an "autosave" feature for a form. We should implement a module that autosaves forms to local storage and restores them when the page is reloaded. There should be an API to clear the saved form data.

• Thinking that the key names could be determined based on the field names.
• By default, I would say that the form should autosave on keyup, debounced.

Some ideas around sample usage:

<form id="example">
  <input type="text" name="title">
  ...
</form>

var autosave = require('airkit/forms/autosave');

var el = document.getElementById('example');
var options = {...};  // Whatever options we might have.
var autosaver = autosave.init(el, options);
autosaver.clear();  // Clears saved data.

We should have a utility to help easily initialize GA Content Experiments, display/hide elements, and provide a framework for iterating over experimented elements with callbacks to make it easier to rapidly implement experiments via GA CX.

Background videos should only be played when inview, and should pause itself if the user switches tabs or scrolls out of view. This should hopefully make sites with videos feel more performant because otherwise videos can sometimes drain a user's laptop battery if they leave the tab open by mistake.

Codebase needs to be modernized to ES6 modules. Modules should export only whatever's necessary for public use to support optimizations like tree shaking.

Clients will need to upgrade their build systems to compile the ES6 syntax into whatever output they desire, e.g. using Babel.

Docs need to provide examples on how to import modules and how to integrate with common build systems.

With a similar featureset to – https://github.com/cferdinandi/smooth-scroll/blob/master/dist/js/smooth-scroll.js

Should support:

• Dynamic-sized header elements (check size of header each time scroll is executed, since a fixed header may change based on a responsive design)
• Fixing the scroll position on page load (if there's a fixed header, this utility should correctly move the scroll to the right position)
• Using event delegation to automatically execute a smooth scroll (to bookmarked URLs) without the need to tag links with data-scroll.

When images enter the viewport based on scroll position, we should be able to transition them in in some way. For example, I'd like to be able to reimplement the functionality of this page – https://www.solveforx.com/wing/ – the images at the bottom nicely pop in when they enter the viewport.

The user agent no longer contains any string that is identifiable as iOS or iPad, so useragent.js in airkit can no longer identify an iPad.

We initially added a few gulp tasks with browserify to make it easy to get started with airkit but it's not easy to maintain that sort of dependency since the javascript build ecosystem changes so fast year over year. Instead, we should provide example docs on how to set up airkit using common systems like webpack, etc., or just let new projects figure out how to integrate airkit into their systems.

At the minimum, we just need to be able to import airkit modules using ES6 module syntax, e.g. import {Modal} from 'airkit/modal'. Build systems can transpile ES6 module syntax to AMD or CommonJS or whatever.

This utility should be able to:

• apply classes to an element (or series of elements) when the user has scrolled past a certain threshold (for example, to be able to hide the header after scrolling 5px)
• apply classes to elements based on the scroll direction (for example, to be able to show the header when the user scrolls up)

This utility should be able to:

• detect whether the current page URL has utm_* parameters
• if so, rewrite all links on the page containing utm_* parameters with the ones from the URL

Modules like inview have inefficient event listening to trigger actions. We should use newer APIs like IntersectionObserver and fall back to lightweight polyfills.

• Similar to InViewClassAdder
• Plays a video when it comes into view

• Some sample code below, where ratios is a list of breakpoint percentages (of the page height) to track.
• A similar utility could be written using airkit's inview module, to track events when specific elements enter view.

var ratios = [0.3, 0.6, 0.9];
var func = function(category, action, label) {
    trackEvent(category, action, label);
};
window.addEventListener('scroll', function() {
  var scrollRatio = window.scrollY /
      (document.body.offsetHeight - window.innerHeight);
  for (var i = 0; i < ratios.length; i++) {
    if (scrollRatio > ratios[i]) {
      var percent = ratios[i] * 100;
      func('EVENT NAME', 'EVENT ACTION', percent + '%');
      ratios[i] = 200; // Some number out of bounds.
    }
  }
});

Airkit should have a breakpoint library that standardizes the way we do @media queries. The library should use simple names for screen sizes (e.g. "sm", "md", etc.), which are configurable on a project-by-project basis.

Example:

// Optionally configure sizes using `$breakpoint-<size>`.
$breakpoint-medium: 1024px;
@import "airkit/breakpoint/mixins";

.element {
  background-color: $blue;  // on mobile
  @include breakpoint-gt(md) {
    background-color: $red;  // medium-sized screens.
  }
}

Breakpoint-style CSS selectors are also useful if you want to be able to create utility classes that you'd apply directly to HTML. For example:

<div class="red blue--gt-md">
  I'm red on small screens, blue on medium and above.
</div>

You can also generate breakpoint rules using a breakpoint-rule mixin, e.g.:

.red {
  background-color: $red;
}
.blue {
  @include breakpoint-rule-gt($sizes: (sm, md)) {
    background-color: $blue;
  }
}

Produces:

.red {
  background-color: red;
}
.blue {
  background-color: blue;
}
@media (min-width: 400px) {
  .blue--gt-sm {
    background-color: blue;
  }
}
...

To batch window resize events.

Create a component that hijacks local URL navigation, performs an AJAX request to fetch the new HTML content, and only updates relevant elements that need to change. A good example of this is essential.com - when you click on a different page, the transitions are super smooth.

Relevant similar project might be Turbolinks.

Create a component registration system that listens to changes in the DOM (most likely using MutationObserver) and decorates/destroys elements as they enter and leave the DOM.

Currently, most of our components do a one-time initialization on load and require all of the elements to already be in the DOM.