Thanks Harly — this will be a great help for getting the material on MDN!
So yeah, I think from what you are saying it would make sense to put the web components on their own separate section completely, and then just link back to the old building blocks section for reference. Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN [email protected] || @chrisdavidmills > On 12 Nov 2015, at 03:13, Harly Hsu <[email protected]> wrote: > > Hi Chris, > Nice to know that you will be working on the documenting on MDN, and it is > such a coincident that the UX team were just talking about reaching out to > you for MDN assistance. The UX team are currently working on a document of > the current web component similar to what we did during Building Blocks for > 2.x, and will provide the document to you for review once we are completed. > Also, we will provide the necessary assets like visuals and animations to be > put on MDN. > > For the version and naming, I think building block will still exist for > current 2.x release, so probably make sense to still have the old building > block guideline page on MDN as reference, and put web component at its own > section to avoid misunderstanding. But that just my thoughts on this. Thanks > > Harly > > > > On Wed, Nov 11, 2015 at 10:05 PM, Chris Mills <[email protected]> wrote: > 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 > > > > -- > Harly Hsu > UX Manager, Firefox OS > Mozilla Taiwan > Tel:+886.2.8786.1100 ext:220 > e-mail:[email protected] _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
