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
