Very sane and rational plan. Quick question: when we move to the fxos-components organization, are we still going to have a demo page that shows all the components in one place? To me that is one of the coolest and most useful features of gaia-components, so long as we are dedicated to keeping it up to date.
On Thu, Nov 26, 2015 at 4:39 PM, Maria Oteo <[email protected]> wrote: > 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 > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
