Hi is indeed great news — I’ve bene waiting for this for a long time, with an eye to updating the Building Blocks docs on MDN. I currently have some of the web components documented here:
https://developer.mozilla.org/en-US/Apps/Design/Firefox_OS_building_blocks/2.3 Although that was along time ago and updates will probably be needed, along wth adding all the others. Questions: * When would be appropriate to start documenting these? I’d imagine Q1 2016 would be good after our Shadow DOM v1 implementation comes out, so people can at least start testing them in Nightly or whatever. * Are we sticking with the “building blocks” name, or dropping it? At the moment, I have the web components listed under the building blocks section, but I’m wondering whether I need to split them out to their own section. Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN [email protected] || @chrisdavidmills > On 5 Nov 2015, at 11:05, Eric Pang <[email protected]> wrote: > > +1 this sounds amazing Wilson, been waiting for this day! > > Especially the idea of using a live guide. Would be great if we can have a > process in place that ensures it always stays update to date. > IMO The change to the workflow would be worth it to stay aligned. > > Eric > >> On 4 Nov 2015, at 14:56, Wilson Page <[email protected]> wrote: >> >> The following is an initial strategy, along with some insight behind our >> thinking. >> >> RENAMING TO FXOS-* >> >> We will be renaming the Github organisation 'gaia-components' -> >> 'fxos-components' along with namespaces for each component (eg. >> <gaia-header> -> <fxos-header>). >> >> This is to improve transparency and solidify our message. Many people have >> heard of FirefoxOS, but not 'Gaia'. Let's tear-down these confusing barriers >> to contribution/understanding and align our vocabulary. >> >> PLATFORM STABILITY >> >> We've been using web-components in production across FirefoxOS for over a >> year in various places: >> • <gaia-header> (all apps) >> • <gaia-dialog> (spark apps) >> • <gaia-switch> (spark apps) >> • <gaia-toast> (system app) >> • Vertical homescreen >> • New homescreen >> • All Music NGA UI >> • Other stuff I've forgotten :) >> This has given us confidence that what we have in the platform right now is >> fast and reliable enough for production. >> >> Shadow DOM V1 (the latest spec all vendors agree on) has shipped in Chrome >> and WebKit Nightly. We're currently working on our implementation. Word from >> DOM team is, that once complete, they too will be happy to ship. I have been >> given a *ballpark* estimate of Q1 2016. >> >> All vendors have not yet agreed on the intricacies of Custom Elements. They >> will be meeting in Dec/Jan for a face-to-face to present proposals and iron >> our the remaining kinks of a more ES6 centric design. >> >> In Gaia we're using Google's initial specification which we haven't preffed >> on by default yet. Third-parties are able to use this API (and Shadow DOM >> V0) by using the "moz-extremely-unstable-and-will-change-webcomponents" >> permission in their app manifest. >> >> Imagining optimistically by May 2016 we'll have Shadow DOM V1 preffed on, >> third-parties will be able to use our fxos-components in Gecko by either >> using the above pref, or a custom-elements polyfill (currently used by the >> Google AMP project). >> >> For the time being we have confidence that the current implementation is >> sufficient for our internal needs. New Shadow DOM and Custom Element APIs >> will land parallel alongside the old, before being deprecated, giving us >> ample time to upgrade. We have also abstracted core APIs behind our >> gaia-component wrapper, which reduces the number of code changes required to >> migrate if/when platform changes. >> >> SEPARATE REPOS >> >> Component will continue to live in their own repos on Github under the newly >> named 'fxos-components' organisation. Each repo will contain source-code, >> live demo(s), tests and documentation. >> >> PACKAGE MANAGEMENT >> >> After much discussion both on mailing lists and person to person, we have >> decided to make the following changes to how we manage external components >> in Gaia. >> >> We will move from Bower to NPM3. NPM has become the package manager of >> choice for the majority, with NPM3, comes with several nice front-end >> features (some borrowed from Bower). >> >> Due to the reasons I outlined in this thread, components will be installed >> locally to each app referenced within a `package.json` at the app root. This >> adds a small amount of learning/friction to our workflow, but brings >> stability to our process (similar to writing tests). >> >> Today external dependencies are checked-in to the Gaia tree. This avoid >> complexities with install, version mismatches, build systems and dependency >> on third-party servers. The downside is that it adds weight to the tree and >> noisy diffs. We'll be sticking to this approach unless more attractive >> options come to light. >> >> 'LIVE' STYLE GUIDE >> >> We will build a single style-guide index page that will link to each >> component's individual gh-page demo. This will act as an index of the >> components that we deem 'production ready' and will be Gaia devs' go-to >> catalogue. >> >> The style-guide will link to each demo, which is turn will link to source >> Github repo with code, documentation, tests and issues. Incorporating a >> 'readiness' checklist within README, following on from the hard work Fred >> did, would quickly highlight stability and feature gaps. >> >> I'd also love to have visual/UX specs checked in alongside source-code as a >> proof implementation matches specs, but this may require significant changes >> to visual/UX workflow. >> >> FOSTERING CONTRIBUTION >> >> Many of these changes are an attempt to lower the barrier to entry for >> contribution to FirefoxOS. Having components separated from Gaia increases >> discoverability and sends the message that these components can be used >> stand-alone. >> >> The scope of 'required understanding for first commit' is shrunk >> dramatically when contributors have less code to look at. Using common tools >> and patterns of the community, we're doing open-source in a >> familiar/approachable way to others. >> >> --- >> >> Let's stop duplicate efforts, save engineering time, give designers a >> fast/reliable upgrade channel and overall increase quality. >> >> If you're as excited by this as me, we're looking for help to make this a >> success. Ping me if you have questions, suggestions or time to lend. >> >> Peace :) >> >> W I L S O N P A G E >> >> Front-end Developer >> Firefox OS (Gaia) >> London Office >> >> Twitter: @wilsonpage >> IRC: wilsonpage >> _______________________________________________ >> dev-fxos mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-fxos > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
