<gaia-header>

[Wilson Page]

Hi Team,

TLDR; In v2.1 we'll be submitting pull-requests into all apps to replace old headers.css building-block, with the new gaia-header web-component building-block.

I'm giving a quick heads up to let you know what's planned in v2.1 regarding the integration of the new gaia-header web-component building-block. We're aiming to incrementally roll gaia-header out across all the apps before the end of v2.1, but we'll probably need some help, especially with the larger, more complex applications.

GaiaHeader will be found in `shared/gaia-components/gaia-header/` and can be used in a similar way to other shared assets. As the source for gaia-header lives in it's own repo, app owners optionally have the choice to install it directly into their app (via Bower) if they wish to take control of their own dependencies (see Camera app as an example).

We are making these changes in an attempt to improve he lives of those who design, implement and use building blocks, which in past releases has been slow and painful. We will continue to adapt/change things, and will review progress at the end of the release.

If your team has free capacity to implement the new gaia-header web-component, give me shout. Otherwise expect a pull-request/ping from myself or others in the not too distant future.

Thanks peeps :)

Wilson

[Andrew Sutherland]

On 07/10/2014 02:52 PM, Wilson Page wrote:

TLDR; In v2.1 we'll be submitting pull-requests into all apps to replace old headers.css building-block, with the new gaia-header web-component building-block.

Thanks for the heads up!  One possible complication is that the email app uses an evil hack "cookie cache" thing to persist our HTML state for fast start-up.  Hopefully there's some way to have our (evil) cake and eat it too, but as a heads-up, we may need to opt-out for v2.1 if there's no way to avoid regressing cold start from cookie cache or if there is but it results in visual flicker when performing any fixups.  (For example, assuming we can pierce the Shadow DOM, we could potentially build a de-webcomponented HTML state for the fast startup and then do an in-place swap-out to the correct thing during our more lazy actual initialization to make things real.)

Andrew