The last tab in a tab strip causes to display a horizontal scrollbar even if there is enough space left (f.i. with only three tabs).

md-collapsible="accordion: false leads to this being executed:

$(this.element).collapsible({
  accordion: false
});

but that still initializes the collapsible as an accordion.

There is a bug somewhere that results with the click on the item D (project status)on the screenshow

Image 1

show the (nearly empty) page shown below:

Image 2

Note. I am reporting this to avoid the debugging of the code that is very temporary and written only to facilitate easy entry for @Thanood.

• 1. Introduction
• 2. Navigation guide
• 3. Components catalog
• 4. Internal structure
• 5. Installation
• 6. Project status
• 7. Color switcher

To be able to completely implement the samples section, there should be some equivalent of Bootstrap's well.

Or, maybe, put these links into the side-bar.

I think it's a good idea to combine the issues mentioned in #13 and #30 into a separate issue dedicated to gather information on loading single Materialize features and make it work using a module loader instead of loading the bundled js file.

At the moment, this issue serves for gathering information on how this can possibly be done.

The current NavBar is still using Bootstrap and it's only because Bootstrap is loaded after Materialize (at least I think that's the reason). Also everyone likes NavBars. 😄

Implementing NavBar as a custom component allows for assigning a global primary color as the background. Implementing it as a custom element I think it will be easier to implement a fixed navbar because that wraps the actual navbar in another wrapper.

Usage example:

<md-navbar fixed="true">
  <a href="#!" class="brand-logo">Logo</a>
  <ul class="right hide-on-med-and-down">
    <li><a href="sass.html">Sass</a></li>
    <li><a href="badges.html">Components</a></li>
    <li class="active"><a href="collapsible.html">JavaScript</a></li>
  </ul>
</md-navbar>

Which translates to:

  <div class="navbar-fixed">
    <nav>
      <div class="nav-wrapper">
        <a href="#!" class="brand-logo">Logo</a>
        <ul class="right hide-on-med-and-down">
          <li><a href="sass.html">Sass</a></li>
          <li><a href="badges.html">Components</a></li>
          <li class="active"><a href="collapsible.html">JavaScript</a></li>
        </ul>
      </div>
    </nav>
  </div>

Describe usage and development of md-tabs, mb-button, md-collapsible and md-navbar as an online-help article in "App developers tutorials" and "Bridge developers tutorials".

• AppDev-tutorials:-1.-Introduction
• AppDev-tutorials:-2.-Setup
• AppDev-tutorials:-3.-Select-component
• AppDev-tutorials:-4.-Button-component
• AppDev-tutorials:-5.-Slider-component
• AppDev-tutorials:-6.-Collapsible-component

• BridgeDev-tutorials:-1.-Introduction
• BridgeDev-tutorials:-2.-Setup
• BridgeDev-tutorials:-3.-Select-component
• BridgeDev-tutorials:-4.-Button-component
• BridgeDev-tutorials:-5.-Slider-component
• BridgeDev-tutorials:-6.-Collapsible-component

How should we prefix our controls? There are some options, with the example of a button (be it an element or attribute):

• md-button
• ma-button
• material-button
• materialize-button

I'm proposing the first because I think ma-button just looks funny. The other two options are in my opinion too long and not as easy to write.

md-title="..." #45

Cards are used throughout the catalog application, all of them following a similar layout. To not necessarily repeat everything we could introduce <md-card> as a custom element.

Usage example:

<md-card title="fancy title">
  <div>card content</card>
</md-card>

Which translates to:

<div class="card">
  <div class="card-content">
    <span class="card-title">fancy title</span>
    <div>card content</card>
  </div>
</div>

(this issue is part of a first milestone implement the catalog's basic user interface)

As I began working on waves I noticed that Materialize has added css classes corresponding to some colors of the material palette (waves-${color}). There are a few missing, like f.i. indigo.

Materialize uses sass for its css styles. These sass files contain a complete representation of the Material color palette.

I guess, creating the waves-${color} classes should be quite easy. But I have no experience working with sass atm (I have been using less so far).
If we could somehow extract these colors to JSON we could probably even use them to generate a theme selector.

Theming in Material basically consists of defining the primary and accent colors and some hues along with standardized shadows and opacity (descibed here).

I tried gulp-sass-json to extract the variables to no avail.

Just a note to myself as I find this not really obvious to find:
http://materializecss.com/helpers.html

Add hoverable property to cards (as it is quote: "meant for use on cards").
Anyway, check possibility to implement as a separate attribute.

Already did that in a plunker.

Usage example:

<select md-select="selected.two-way: selectedValue;">
  <option value="" selected>select</option>
  <option value="item1">item 1</option>
  <option value="item2">item 2</option>
  <option value="item3">item 3</option>
  <option value="item4">item 4</option>
</select>

Which stays the same html but has to be initialized by: $('select').material_select(); which in turn creates new elements as a proxy.

Also needs some event-handling. Materialize changes the native <select> but doesn't trigger a change event.

This element has a destroy handler.

There are several options on how to include Materialize in this bridge.

a) which part should import the library?

1. the bridge
2. the catalog (and therefore the user's application)

I'd really like the catalog itself to show a circular preloader instead of the font-awesome spinner so the catalog would still use Materialize css because this obviously has to be available before Aurelia starts. What do you think?

b) there are some variations available..

1. jspm install materialize=github:github:Dogfalo/materialize
2. jspm install materialize=npm:materialize-css
3. use a vendor solution like the kendo-ui bridge does

Where...

1. Pulls the bundled and minified version of Materialize into the target and no sources. We cannot alter f.i. SASS files or just import single features with this variant (although I don't believe Materialize is made for "feaure picking" at all tbh). On the other hand this solves a few issues I've come across while experimenting with Materialize. For example toasts needing both a global Materialize variable, hammerjs and velocityjs to be present. Keep in mind that Materialize is not (yet?) built around any module system.

2. Pulls Materialize source files and dist builds. We can read and process SASS files and pick features to import. The SASS files could f.i. be used to create primary and accent colors which Materialize has no notion of, but Material does. I've already been missing that with the first Waves sample. Also we could perhaps use the "original" Waves which includes disposing functionality.
   But, as stated above, there are some issues to this approach.

3. I'm really not sure if this makes any sense at all since there are no real "editions" of Materialize and the variations noted above only make a difference from a bridge developer's point of view.

Btw: I've read the Git Commit Guidelines but this issue would fit neither (chore) or (doc) while it also does not discuss a feature I think (or does it?). Which <type> would fit here?

If possible, change the doc viewer/gitter tab to not use a fixed height but fill the screen instead. Maybe use flexbox or absolute positioning.
Not sure how the gitter tab behaves then.

This task has to wait on new jspm needed by plugin builder

gulp build-es6-temp now fails with an error I've never encountered before:

aurelia-materialize-bridge/devbuild/aurelia-materialize-bridge.js: Line 126: "fireMaterializeEvent" is read-only

  124 | * @param data Addition data to attach to an event
  125 | */
> 126 | export function fireMaterializeEvent(element: Element, name: string, data? = {}) {
      |        ^
  127 |   return fireEvent(element, `${constants.eventPrefix}${name}`, data);
  128 | }
  129 |

Removing that task from the gulp chain at least permits executing it. What does build-es6-temp do anyway?

The initialization script seems to run before fixed is bound an thus initializes the sidenav "non-fixed".

remove Bootstrap styles, apply Materialize styles

done in branch remove-bootstrap

Although md-select is configured this way:

@bindable({
    defaultBindingMode: bindingMode.twoWay
  }) selected;

It seems like selected still needs to be bound .two-way explicitly to work correctly:

<select multiple md-select="selected.bind: selectedValues;">

does not update selectedValues while the following does:

<select multiple md-select="selected.two-way: selectedValues;">

Hola! @Thanood has created a ZenHub account for the aurelia-ui-toolkits organization. ZenHub is the leading team collaboration and project management solution built for GitHub.

How do I use ZenHub?

To get set up with ZenHub, all you have to do is download the browser extension and log in with your GitHub account. Once you do, you’ll get access to ZenHub’s complete feature-set immediately.

What can ZenHub do?

ZenHub adds a series of enhancements directly inside the GitHub UI:

• Real-time, customizable task boards for GitHub issues;
• Burndown charts, estimates, and velocity tracking based on GitHub Milestones;
• Personal to-do lists and task prioritization;
• “+1” button for GitHub issues and comments;
• Drag-and-drop file sharing;
• Time-saving shortcuts like a quick repo switcher.

Add ZenHub to GitHub

Still curious? See more ZenHub features or read user reviews. This issue was written by your friendly ZenHub bot, posted by request from @Thanood.

import 'showdown'; does not introduce a global "showdown" anymore (as stated in meta section of config.js).
import * as showdown from 'showdown'; imports a local showdown but then showdown-prettify cannot be found.

Compared it with kendo-ui-bridge, it works there. Until now I couldn't find any difference.
(and of course: yesterday it worked 😄 )

As can be seen on the button sample page, a flat button (md-button="flat: true;") doesn't have a hover animation. A large button has that animation.

In addition to that, a disabled flat button gets the "focus" style when clicked on. A disabled raised button does not. Also, regular and large buttons (not flat) are animated differently on hover,

This may be a Materialize issue or may be caused by mixing Bootstrap and Materialize. Will have to check again when Bootstrap can be removed.

If it's used with string interpolation, the element's native tooltip becomes: ${expression}.

Not sure whether this is in any way related to just added fix for handling dist folder problems however, I am getting this:

λ gulp -watch
C:\work\aurelia-ui-toolkits\aurelia-materialize-plugin\node_modules\gulp-sass\node_modules\node-sass\lib\extensions.js:158
    throw new Error([
    ^

Error: The `libsass` binding was not found in C:\work\aurelia-ui-toolkits\aurelia-materialize-plugin\node_modules\gulp-sass\node_modules\node-sass\vendor\win32-x64-47\binding.node
This usually happens because your node version has changed.
Run `npm rebuild node-sass` to build the binding for your current node version.
    at Object.sass.getBinaryPath (C:\work\aurelia-ui-toolkits\aurelia-materialize-plugin\node_modules\gulp-sass\node_modules\node-sass\lib\extensions.js:158:11)
    at Object.<anonymous> (C:\work\aurelia-ui-toolkits\aurelia-materialize-plugin\node_modules\gulp-sass\node_modules\node-sass\lib\index.js:16:36)
    at Module._compile (module.js:425:26)
    at Object.Module._extensions..js (module.js:432:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:313:12)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at Object.<anonymous> (C:\work\aurelia-ui-toolkits\aurelia-materialize-plugin\node_modules\gulp-sass\index.js:176:21)
    at Module._compile (module.js:425:26)

Note earlier today, I was able to run gulp watch in this project without a peep

Checkboxes in Materialize basically consist of an <input type="checkbox"> element with an associated <label>.

I'm unsure regarding its implementation (attribute vs. element). It will not only enhance an existing element but add a new one to it. With the bonus of having control over the mandatory id attribute - which can then be generated.

Could look like this:

<md-checkbox value.bind="viewModelValue">checkbox title</md-checkbox>

which translates to:

<input type="checkbox" id="md-checkbox-1" />
<label for="md-checkbox-1">checkbox title</label>

I've tried wrapping the <input> inside of <label> to avoid ids but that did not work.

In materialize a switch is implemented by wrapping an <input type="checkbox"> element. Unlike f.i. text fields, checkboxes are quite simple elements,

I'd like to implement it as a custom element because that way we have easier control over the mentioned wrapper.

Usage example:

<md-switch value.bind="viewModelValue" label-activate="On" label-deactivate="Off"></md-switch>

Which translates to:

<div class="switch">
  <label>
    Off
    <input type="checkbox">
    <span class="lever"></span>
    On
  </label>
</div>

@JeroenVinke pointed out an issue regarding disposal of jQuery elements.

As opposed to, for example, jQueryUI, not all materialize components have a "destroy" handler. For instance the datepicker component uses some event handlers which would then still be bound to a DOM element, probably even if it's already detached. The datepicker component does not have a disposal mechanism by itself - or I didn't see it.

Not sure how to handle this. Patch materialize? Tell them with an issue/PR? Ignore it for the time being?

There are no stand-alone buttons in the catalog app but many examples will use them: button (of course), dropdown, modals (to trigger the modals), toasts, waves and so on.

Usage example:

<button md-button="disabled.bind: someVariable; flat: true;">
  my button
</button>

Which translates to
(someVariable = true):

<button class="btn-flat disabled">
  my button
</button>

(someVariable = false):

<button class="btn-flat">
  my button
</button>

When loading the docs view, then navigating away and back, the collapsible is not initialized.
When refreshed manually, it works again:

document.querySelector('[md-collapsible]').au['md-collapsible'].viewModel.refresh()

I've encountered some issues with Materialize while I was trying to run unit-tests for elements. I will document them here.

1. aurelia-pal-browser was missing - easy to solve: jspm install aurelia-pal-browser 😄
2. Materialize required "jQuery" (capital Q) while jQuery is registered as jquery - easy to solve if you know jspm maps: add "jQuery": "github:components/[email protected]", to the map
3. Materialize wants picker.js which is bundled. Systemjs looks in /base/jspm_packages/npm/[email protected]/bin/picker.js - don't know how to fix that

Note: the bridge (and thus karma/jasmine) now pulls Materialize from it's "source": npm:materialize-css. The dist version of materialize doesn't have this issue (point 3) itself.

Can we add a map to "jQuery" without mentioning its version? To be able to up/downgrade jQuery and still keep the map intact. (there are some documented issues with Materialize and jquery 2.2)

What would be a good solution for 3.?

As documented in #16 we had to attach a data-collapsible attribute to md-collapsible to be able to set it in accordion/expandable mode.

Include handling for these attributes in CssClassSetter - and maybe review the name because then it not only sets classes.

Basically fill the "installation" page with content.

• 1. Integrated with Aurelia
• 2. Why choose Materialize

aurelia-ui-toolkits/aurelia-kendoui-bridge#245

This makes sense only when the help pages are added to this repo

This is not exactly part of the basic user interface but the side-bar navigation on the Materialize website behaves a lot like the side-navigation of the current help section in this materialize-bridge.

Also it's quite similar to the variations section of the SideNav component on Materialize website.

No usage example yet and I'm not sure if it really fits in this early milestone.

At the moment, the catalog application imports Materialize CSS and JS. Change it to only use CSS and let the bridge take control of Materialize's JS parts.

If I understood correctly, project status is a temporary overview.
To be able to present a component catalog using Material principles (and looking familiar to Materialize users), implement a side-bar which holds the categories and examples from project status.

As mentioned in #31, FABs have a set of classes and methods which only apply to them, for example:

• horizontal (css)
• openFAB(), closeFAB() methods
• click-to-toggle (css)
• positioning (for fixed FABs)

I think we should introduce a separate attribute for them.

No usage example yet.

I have prepared some plunks using Materialize and Aurelia, showing some basic implementations of custom controls. @JeroenVinke suggested that we use these to discuss when to use custom attributes/elements. That way we can have a look at them from a user's perspective.

I will post the current plunks first, then do some variations using attributes or elements and post them here, too.

Datepicker (attribute):
http://plnkr.co/edit/7RxUGfKOTx0i4gjl3Ay9
Datepicker (element):
I guess this doesn't make sense since it's not bringing anything to the table other then manipulating an existing <input>. (first rule of thumb here?)

Dropdown (attribute):
http://plnkr.co/edit/jaSEjYf8K1ZyRq8g4aZ8
Dropdown (element):
http://plnkr.co/edit/zhgVowIr3mPPLYHoFJyk

I like the "embedded" style of the element more. Wish we could do without the ids and use at least selectors. But we could compensate for that using a custom element which could calculate and set the id by itself (using a static variable).

Select (attribute):
http://plnkr.co/edit/BigNLhvCW2P3cS3x1lPt
Select (element):
I guess I'll pass here, too. Again, this manipulates an existing <select> and I don't see any benefit in doing a custom element. But maybe there are good reasons I don't see. 😄

Tabs (just css, no custom anything):
http://plnkr.co/edit/YaMJxve5PoLwPxTwGfUQ

Since tabs seem to be a lot of work I won't do them now in the plunk but instead do it later in the catalog app. I need them anyway for the sample pages.

Basically I'm thinking custom element here since then we have better control of its contents (imo). That control will be handy if we implement for example:

• dynamic tab add/remove
• get the (view-model of) a specific tab
• get/set the selected tab
• callbacks/events for tab selection/deletion/addition

Possible usage:

<md-tabs selected.bind="selectedTab">
  <md-tab title="html">html code</md-tab>
  <md-tab title="javascript">js code</md-tab>
  <md-tab title="css">css rules</md-tab>
</md-tabs>

Maybe it's even possible to bind the selected tab to the active route..

Come up with something which handles setting (and removing) component's classes in a more advanced way, depending on what users have set before our bridge takes control.

As at least half of Materialize is all about setting css classes we cannot be sure which classes our users set before using our controls.
As an oversimplified example they may use this:

<button md-button class="btn">my button</button>

or this:

<button md-button>my button</button>

We'd have to set and remove (on detached()) these classes and leave the html like the user intended, removing btn only in the second example.

This is also important if we start using to set color classes (as mentioned in #9). If the user already defined such a color class, we should not override them. That may require a registry of these classes.

While running the newly created aurelia-materialize bridge, I am getting this error message

[18:58:43] Starting 'tdd'...
[18:58:44] Finished 'copy-css' after 4.58 s
13 01 2016 18:58:46.564:ERROR [karma]: { [Error: EMFILE: too many open files, open 'C:\work\aurelia-ui-toolkits\aurelia-materialize-bridge\src\click-counter.js']
  errno: -4066,
  code: 'EMFILE',
  syscall: 'open',
  path: 'C:\\work\\aurelia-ui-toolkits\\aurelia-materialize-bridge\\src\\click-counter.js' } Error: EMFILE: too many open files, open 'C:\work\aurelia-ui-toolkits\aurelia-materialize-bridge\src\click-counter.js'

each time I change something in the source code of the "bridge consumer application. Note that the task gulp watch is running as I expect to see the effects of my change, without having to manually restart the gulp watch

Looking up this error message, it seems that this is a possibly still not resolve issue with karma on Windows, so I would like to be able to exclude invoking karma in my daily grind, until we have a solution for this

Note: this simple cure in default.js file

var gulp = require('gulp');
var runSequence = require('run-sequence');

gulp.task('default', function(callback) {
  return runSequence(
    'lint',
    'build',
    // 'test',
    callback
  );
});

did not result with a fix

copy to implement the sample pages

Incoming changes:
Dogfalo/materialize#2670

Aurelia Materialize Bridge tutorial article

This document, when finished will be a part of Aurelia Materialize online help documents collection

The initial step in the process of creating this repository is to create it the directly in Github, using the browser, resulting with this

Currently, there are no source-maps created for the plugin itself. It would be very convenient having source-maps in the embedded catalog and later in dist builds.

What is the intention of not having them built? Does it cause any problems (f.i. with bundling/deployment)? If there are no concerns, I can add them.

Note: this probably also affects the plugin-builder.

It's almost an integration test but I feel I should do that.
This may become very handy: aurelia/framework#230

There is a checkbox to switch between accordion/expandable use on the popout sample page. Although it seems to be bound correctly and refresh() is called with the correct parameters, the popout collapsible stays in accordion mode.

Probably because it's not set as this.element.value.