Thanks Wilson! I'd like to emphasize it is a proposal drafted among some of the Web Components team members and that any feedback is, as usual, more than welcome.
Thanks a lot! On Thu, Nov 26, 2015 at 3:26 PM, Wilson Page <[email protected]> wrote: > Maria has written up a formal plan [1] for moving Web Components forward > post v2.5. > > [1] > https://docs.google.com/document/d/1BmGLrm1tVsgv2S8mt-nTkNUN0kj8PqXq_7Wt-PP3lwE/edit > > *W I L S O N P A G E* > > Front-end Developer > Firefox OS (Gaia) > London Office > > Twitter: @wilsonpage > IRC: wilsonpage > > On Thu, Nov 12, 2015 at 8:59 AM, Chris Mills <[email protected]> wrote: > >> 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 > > -- Maria Oteo Program Manager, Firefox OS Office: Zaragoza (Spain) Mobile: +34 657881658 Email: [email protected] IRC: mariaoteo
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
