materializecss / materialize

Materialize, a web framework based on Material Design

Materialize

Materialize, a CSS Framework based on Material Design.
[ Browse the docs ]

Quickstart

Read the getting started guide for more information on how to use materialize.

• Download the latest release of materialize directly from GitHub. (Beta)
• Clone the repo: git clone https://github.com/materializecss/materialize.git
• Include the files via jsDelivr.
• Install with npm: npm install @materializecss/materialize (Beta: npm install @materializecss/materialize@next)

Development

The documentation can be found at https://materializeweb.com. To run the documentation locally on your machine, you need Node.js installed on your computer.

This is the core project with all the components. To see how they are used we recommend using an example project or go to the documentation. Otherwise, if you want to develop the components itself, the dev process of this core-repo works like this:

npm install
npm run dev

Running documentation locally

See Materialize Docs Repo to see Materialize in Action.

Documentation for previous releases

Previous releases are available here.

Release

If you want to release materialize.css or materialize.js from the latest commit, you can build the files with the following command after npm install. See package.json to check the current version like 1.0.0.

npm run release -- --oldver=<current_version> --newver=<new_version>

Supported Browsers:

Materialize is compatible with:

• Chrome 35+
• Firefox 31+
• Safari 9+
• Opera
• Edge

Changelog

For changelogs, check out the Releases section of materialize or the CHANGELOG.md.

Testing

We use Jasmine as our testing framework and we're trying to write a robust test suite for our components. If you want to help, here's a starting guide on how to write tests in Jasmine.

Contributing

Check out the CONTRIBUTING document in the root of the repository to learn how you can contribute. You can also browse the help-wanted tag in our issue tracker to find things to do.

Sponsors

Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]

Backers

Thank you to all our backers! 🙏 [Become a backer]

Copyright and license

Code Copyright 2024 Materialize. Code released under the MIT license.

materialize's Issues

Add npm-asset support

Could you add npm-asset support? I see there "npm-asset/materialize-css", but it's for Dogfalo/materialize. Then there is "npm-asset/materializecss--materialize", but it's again points to Dogfalo/materialize. This repository I can't find there.

Communication channels

What does everyone recommend for communication? I saw someone recommend Slack, but it has its issues (i.e. Invites Expiring with no option to make a permanent one and the finicky UX). Gitter is used by the old project, so no luck there.

I recommend either Discord or Matrix.

What does everyone else think?

When adding previous and next arrow next to carousel indicators, previous event selects correct indicator while next event does not

First of all, thanks for taking the initiative to open up a maintained repo of materialize. I hope someone can help me out here.

Summary

When I add a previous and next arrow next to the carousel indicators and hook up previous() and next() events on them for going to next/previous slide, when clicking on the next arrow (i.e. calling next() event), every even second indicator is "skipped". Skipped meaning the indicator is not marked correctly on the second and fourth slide in my example. When using the previous arrow (i.e. calling previous() event), this is working fine.

JSFiddle: https://jsfiddle.net/BenBITDesign/8qgb4yon/1/

Expected Behavior

I would expect the next() event to work like the previous() event and mark the indicator correctly at all times.

Current Behavior

When calling the next() event while on the first slide to go to the second slide (or from the third to the fourth slide), the indicator does not mark the second (or fourth) dot correctly. It stays on the first (or third) dot while it's on the second (or fourth) slide. This keeps going every second slide if you would add more slides. You can easily see this by clicking on the next arrow and watching the indicator dots in the JSFiddle.

Important note: The previous() event works fine on all slides

Going to the second slide with the next arrow, the second indicator is not activated:

Possible Solution

I have not been able to figure out how the JavaScript selects the indicator to mark myself. I would think that the selection for the previous() event is currently not matching the selection for the next() event. The previous() event works fine on all slides.

Steps to Reproduce (for bugs)

1. Open JSFiddle linked above
2. Click the next arrow multiple times and see the indicator not being marked as active correctly every second slide
3. (note) Clicking the previous arrow will indicate the correct indicator at all times

Context

I bumped into this while I was trying to create next/previous arrows next to the indicators for moving the slides as seen in the JSFiddle.

In addition to this issue, clicking the indicators is also not working correctly now. When clicking the second indicator, the third slide is activated. Most likely because I have added child elements in the <ul> and the count is wrong. I have added <span> items in the hope that it is only counting <li> items but that does not seem to be the case.

Your Environment

• Version used:
• Browser Name and version: Microsoft Edge Version 86.0.622.69
• Operating System and version: Desktop, Windows 10
• Link to your project: https://jsfiddle.net/BenBITDesign/8qgb4yon/1/

Improvement: Update references to e.which and e.keyCode to e.key (e.which and e.keyCode are deprecated)

DEPRECATION

Per MDN on event.which and event.keyCode:

Warning: This attribute is deprecated; you should use KeyboardEvent.key instead, if available.

There are mixed uses of the event.which and event.keyCode properties throughout the source in the following locations:

autocomplete.js - references event.keyCode

• Line: 220 - https://github.com/materializecss/materialize/blob/v1-dev/js/autocomplete.js#L220
• Line: 225 - https://github.com/materializecss/materialize/blob/v1-dev/js/autocomplete.js#L225
• Line: 237 - https://github.com/materializecss/materialize/blob/v1-dev/js/autocomplete.js#L237
• Line: 240 - https://github.com/materializecss/materialize/blob/v1-dev/js/autocomplete.js#L240
• Line: 244 - https://github.com/materializecss/materialize/blob/v1-dev/js/autocomplete.js#L244

datepicker.js - references event.which

• Line: 812 - https://github.com/materializecss/materialize/blob/v1-dev/js/datepicker.js#L812

dropdown.js - references event.which

• Line: 224 - https://github.com/materializecss/materialize/blob/v1-dev/js/dropdown.js#L224
• Line: 258 - https://github.com/materializecss/materialize/blob/v1-dev/js/dropdown.js#L258
• Line: 263 - https://github.com/materializecss/materialize/blob/v1-dev/js/dropdown.js#L263
• Line: 265 - https://github.com/materializecss/materialize/blob/v1-dev/js/dropdown.js#L265
• Line: 286 - https://github.com/materializecss/materialize/blob/v1-dev/js/dropdown.js#L286
• Line: 301 - https://github.com/materializecss/materialize/blob/v1-dev/js/dropdown.js#L301

forms.js - references event.which

• Line: 233 - https://github.com/materializecss/materialize/blob/v1-dev/js/forms.js#L233

global.js - references event.which

• Line: 44 - https://github.com/materializecss/materialize/blob/v1-dev/js/global.js#L44
• Line: 50 - https://github.com/materializecss/materialize/blob/v1-dev/js/global.js#L50

timepicker.js - references event.which

• Line: 139 - https://github.com/materializecss/materialize/blob/v1-dev/js/timepicker.js#L139

IMPROVEMENT

An improvement to future proof these handlers for when event.which or event.keyCode is removed would be to use the suggested event.key property when attempting to identify which key was pressed.

Caveat - IE 11 implements non-standard key identifiers

event.key differs from event.which or event.keyCode in that it returns the value of the key as opposed to the key's underlying code. Prior to the spec being approved, IE 11 implemented this change with non-standard values for the ESC, Arrow Up, and Arrow Down keys. To accomodate for this, one option would be to add the non-standard identifiers to the M.keys object in global.js:

/* Lines 29 - 35 */
M.keys = {
  TAB: "Tab",
  ENTER: "Enter",
  ESC: "Escape",
  ESC_IE11: "Esc",
  ARROW_UP: "ArrowUp",
  ARROW_UP_IE11: "Up",
  ARROW_DOWN: "ArrowDown",
  ARROW_DOWN_IE11: "Down"
};

This would require a slight modification when one of these keys is pressed. For example, in autocomplete.js on line 240:

if ((key === M.keys.ARROW_UP || key === M.keys.ARROW_UP_IE11) && this.activeIndex > 0) {
  this.activeIndex--;
}

---

I'm happy to submit a PR for the changes above, but I wanted to get this in front of the @materializecss/members to determine whether the above solution is the preferred method to resolve this (I realize the IE 11 hack is not the most elegant) and where this fits in with the priority of your new build. I don't think this is critical and could wait a version or two if preferred.

Media queries not triggered at breakpoints on Firefox with display scaling enabled

Current Behavior

CSS media queries are not triggered at exactly the responsive breakpoints (601px, 993px, 1201px) on Mozilla Firefox (latest) on Windows 10 with Display Scaling other than 100% (my display is at 125%.)

This is not specifically a Materialize issue, but needs attention. Bootstrap applied a fix some years ago.

Here is a simple Codepen to understand the issue and here is a detailed blog post to further understand the issue (screenshots included.)

There are also minor inconsistencies with min-width set to 600px (instead of 601px) in some places in the following files

• ./materialize/sass/components/_global.scss
• ./materialize/sass/components/_typography.scss

Possible Solution

I have forked the project and have the following fixes ready. I can submit a PR.

1. Set the min-width to integers, but change the max-width to a fraction (600.99px, 992.99px, 1200.99px)
2. Fix the variables in the above 2 files.

dropdown.js still has the problem of misaligned taps

Dogfalo has fixed select.js to resolve the problem of the recognizing position of tap on iOS 13. Meanwhile, dropdown.js still has a such problem.

Dogfalo@c0da340#commitcomment-36941624

I know this problem causes from the strange behavior of iOS 13 (and 14). https://developer.apple.com/forums/thread/120586

My current idea is to use'ontouchend' in document.documentElement to check if the browser supports ontouchend and use this event if suppports. If not, then use the onclick event. Though it will work well, I'm not sure if I can spend time solving this, so I wrote it down in this issue anyway.

Select does not work without jQuery

First: Thank you dudes! The compiliation process worked! Awesome... I see materialize is moving forward.

When I remove the jQuery dependency and there is a small issue when i am trying to expand a Select Component / DropDown Menu. The Error in the Console says:

Uncaught ReferenceError: $ is not defined
    getClosestAncestor https://localhost/_WORK/developing/AutoKMS/js/materialize.min.js:6
    value https://localhost/_WORK/developing/AutoKMS/js/materialize.min.js:6
    value https://localhost/_WORK/developing/AutoKMS/js/materialize.min.js:6
    value https://localhost/_WORK/developing/AutoKMS/js/materialize.min.js:6
materialize.min.js:6:14917

Steps to Reproduce (for bugs)

1. Create a Select (not multi)
2. Load Elements
3. Click on Select

Your Environment

• Version used: latest v1-dev from yesterday 20.10.2020
• Browser Name and version: Firefox 81
• Operating System and version (desktop or mobile): Windows 10 desktop

Using as modular components

There's been a long-standing issue when trying to import parts of materialize individually (Dogfalo#5958) and from what others are saying it should be a fairly easy fix. Any thoughts?

bug: materialize select in modal

Long select list in modal overflow

Current Behavior

Materialize select with multiple option change the modal height. We don't know if the select option has reached the end. Maybe it's missing some bottom margin ?

Possible Solution

The list could be overlapping the modal content or have a max-height.

Steps to Reproduce (for bugs)

• create a materialize select and add multiple option in a modal

Environment

• Version used: Materialize V1
• Operating System and version (desktop or mobile): tested on Firefox and Chrome
• Codepen: https://codepen.io/roileo/pen/yLOGjXa

Feature Request: Dark Mode

Any chance we can get dark mode for the framework?

Improve css-variables support in sass files

Hi, I'd like to propose a small sass code change (which I could implement myself if you agree), please find the rationale and suggestion below.

Use case description

I'm trying to use css variables for dynamic theme switching. To make it possible, I'd like to override materialize sass variables, e.g.:

$secondary-color: var(--secondary-color);
$secondary-color-lighten-4: var(--secondary-color-lighten-4);
$button-background-focus: var(--secondary-color-lighten-1);

These are my custom variables and they are taking precedence over materializecss variables. This works perfectly fine for me.

The problem

However, I cannot use color(var(--secondary-color)), because I'd like --secondary-color to be kept as it is, without preprocessing. I.e. in the output css I'd like to have smth like:

.button {
    background-color: var(--secondary-color);
}

But without color(...), there is a problem with other variables and styles, since color functions are not working:

$primary-color-light: lighten($primary-color, 15%) !default;

.progress {
    background-color: lighten($progress-bar-color, 40%);
}

This lighten function fails, since it expects a color as input
For variables, this is not a problem, since I can easily override them

However, for css styles, I wasn't able to find a way, how to make it compilable.

Suggestion

What do you think about avoiding color functions in style files and to move all of them into variables?
For the example above, with the progress bar, it would look like:

$progress-bar-panel-color: lighten($progress-bar-color, 40%) default!;

.progress {
    background-color: $progress-bar-panel-color;
}

I quickly checked the code, and usually there 1-2 color functions in sass files, so this shouldn't be a big change.

What do you think?

Select Component does not have onChange Event

I was doing a filter using a multiple select, checking the documentation I realize that there is no onChange like callback

Expected Behavior

The component should have a built-in callback that triggers whenever the user changes the selected item.

Current Behavior

There is no way to trigger the onChange event on the component

Possible Solution

I alredy fixed this, creating the callback in the select component, works for both multiple and regular select.

Steps to Reproduce (for bugs)

Context

I needed to filter some items using the selectedItems in the select component but I found that there is no callback currently

Scroll to selected dropdown

Dogfalo#3502 added the ability to scroll through autocomplete results with the arrow keys but as soon as you get to ones that need scrolling, you're screwed.

I've bodged this into my app (https://cloverleaf.app) using onkeyup and

const selected = document.querySelector(".autocomplete-content.dropdown-content .active");
if (selected)	selected.scrollIntoView({behavior: "smooth", block: "nearest", inline: "nearest"});

The issue with this is that when holding down, it waits for you to let go before scrolling. I've tried doing this onkeydown but then it's out by one so to properly do this I think it needs to be worked into the lib. I might take a crack at this but no promises 😄

Here's a codepen as an example: https://codepen.io/ChildishGiant/full/MWyKpxZ

Is this the official MaterializeCSS repo from now on?

I was looking on the original materializecss and that had issues piling up and it looked abandoned, I was wondering if this is now the official materializecss repo from now on?

if so should we bring the issues from the other repo here?

autocomplete with materializecss + jquery tokeninput

hi, i am a web developer and i used materializecss for a couple of projects in the past.

in the last project i integrated a (now archived) jquery plugin for autocomplete with ajax and tokens with the chips from materializecss (https://github.com/loopj/jquery-tokeninput)

i think that it's a better alternative to the autocomplete functionality offered by materializecss right now, it has ajax loading, prepopulate, adding tokens on the fly, and other triggers, but i dont think i have the technical level to contribute code to a open source project.

anyway, if you thinks it's usable, i created a gist with the two "hacked" files (jquery.tokeninput.js + token-input.css) and an example so you can merge it on the project or use it freely as you see fit.

GIF DEMO: https://imgur.com/gallery/CqfATAb
GIST: https://gist.github.com/scabros/36ec20611166bfe642a24c39fc84bff8

Style guidelines

Currently the project has a basic .eslintrc set up but I think it'd make contributing easier and more consistent if we opted to use js standard style. Many projects (including npm, GitHub and the UK government) use this style

Autocomplete share "onOptionClick" for multiple instances

Bug description

If you add multiple autocomplete components on a page, their "onOptionClick" handlers are somehow interdependent
Here is an example (I just select options from 3 autocomplete in a row):

Codewise: in autocomplete.js there is the following code:

      let dropdownOptions = $.extend(
        Autocomplete.defaults.dropdownOptions,
        this.options.dropdownOptions
      );

So on every init we extend default options with new dropdown options. I.e. we modify defaults every time we create a new autocomplete.

This was introduced in #60

Steps to Reproduce

Create 3 autocomplete, like this:

      <div class="input-field">
        <input id="autocomplete-input" class="autocomplete" type="text">
        <label for="autocomplete-input">Autocomplete</label>
      </div>

      <div class="input-field">
        <input id="autocomplete-input2" class="autocomplete" type="text">
        <label for="autocomplete-input2">Autocomplete 2</label>
      </div>

      <div class="input-field">
        <input id="autocomplete-input3" class="autocomplete" type="text">
        <label for="autocomplete-input3">Autocomplete 3</label>
      </div>

And then initialize them:

    const autocompletes = document.querySelectorAll('.autocomplete');
    M.Autocomplete.init(autocompletes, {
      data: {
        'Apples': null,
        'Oranges': null,
        'Bananas': null
      }, minLength: 0
    });

Then just select options in each autocomplete one by one

As a result, you will see the behavior from the GIF above

[ Navbar Dropdown Menu ] focus bug when hovering over dropdown items

Context

It seems that there is an issue which shows an ugly black/white border when hovering over and then out of a dropdown element which is defined within a navigation bar. It seems that this has something to do with focusing in and out of the dropdown trigger.

I have attached a screenshot which shows the border:

Steps to Reproduce (for bugs)

1. Using the following code (as documented on https://materializecss.com/navbar.html#navbar-dropdown) :

<!-- Dropdown Structure -->
<ul id="dropdown1" class="dropdown-content">
  <li><a href="#!">one</a></li>
  <li><a href="#!">two</a></li>
  <li class="divider"></li>
  <li><a href="#!">three</a></li>
</ul>
<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>
      <!-- Dropdown Trigger -->
      <li><a class="dropdown-trigger" href="#!" data-target="dropdown1">Dropdown<i class="material-icons right">arrow_drop_down</i></a></li>
    </ul>
  </div>
</nav>

2. Using the following options for the DropDown initialisation:

        document.addEventListener('DOMContentLoaded', function() {
            let elems = document.querySelectorAll('.dropdown-trigger');
            let options = {
                hover: true,
                coverTrigger: false,
            }
            let instances = M.Dropdown.init(elems, options);
        })

3. Hover over and out of the dropdown element.

4. Within the developer-console, adding the :focus state to the <li>, which surrounds the Dropdown Trigger, will result to the same behaviour.

Your Environment

• Version used: This issue occurred to me in both "@materializecss/materialize": "^1.0.0" and the CDN stated in the documentation (https://materializecss.com/getting-started.html).
• Browser Name and version: Google Chrome Version 88.0.4324.182 (Official Build) (64-bit)
• Operating System and version (desktop or mobile): Linux Mint 20

How to handle website, packages,...

Hi!

I'm very interested by the reboot of the project because the agency where I work use this project to build a client interface.
But I've several questions regarding the new orgagnization.

How do you will manage releases, packages, and updates of the website because you don't have the rights I think?

Thank's in advance!

Programmatically triggered Wave Effects

Dogfalo#3193

Would like to take this on, will work on it and send pull request unless anyone has any objections? Looks like at a cursory glance this may involve removing the wave library and either updating or replacing it.

Dropdown wrong item click on ios14 (only when closeOnClick is true)

When clicking on a dropdown item on ios14, the wrong one is clicked.
I set the timeouts to 200 in _handleDocumentClick for a test and this solve the problem

Time to stop worrying about ie support?

Several changes (such as passive event receivers) were recently blocked to keep compat with ie without the use of polyfills. Microsoft just announced they're dropping IE, maybe it's about time we do the same?

Where can I get compiled builds

Thanks for the great work continuing this project, I've looked through some of the latest gits and they fix some problems I have been having but I can't seem to be able to compile this version correctly, is there builds on Travis? If so I could not find them, is there anywhere I can download the current build? Thanks!

Feature Request: Alerts and Messages

I noticed that materialize currently doesn't provide alerts or messages for users like other css frameworks currently do.

https://getbootstrap.com/docs/4.0/components/alerts/
https://bulma.io/documentation/components/message/

This is something I really wish could be added to Materialize because every time a user saves something I want to be able to give them a quick and nice alert about what the effect of their action was, whether it was success, error, or just info but I currently am now able to do that

Components and shadow DOM

I open this error with the hope of being able to solve this annoying problem.

I state that I have read the documentation and I do not seem to have found anything about it (take me with a grain of salt because being new in web development I might have skipped something that did not seem relevant) and in the original repository the issues concerning this topic do not give a solution very clear (to tell the truth they don't give it at all, see here or here).

Expected Behavior

The materialize component used within a shadow-rooted custom element should show effects (i.e. waves) or perform specific actions (see cards). I have encountered problems with buttons and cards but the problem could affect all components using the waves.

Current Behavior

The component in a shadow DOM has only some of the effects it normally has in the light DOM (i.e. the button changes color on hover but does not have the wave effect when clicked).

Steps to Reproduce (for bugs)

Simply add a component inside a custom element with shadow DOM.
I link two examples on CodePen: buttons and cards.

Context

The problem arose when I was trying to create a component to represent a single game in a game manager using cards (with hidden side) and buttons. Specifically, the component in question is this.

Your Environment

The error presented with:

• Electron 10.1.6 (Chromium 85.0.4183.98)
• Electron 11.0.3 (Chromium 87.0.4280.67)
• Firefox 84.0b6

On Windows 10 20H2 (19042.630)

With the latest available release of materialize on npm (both this repository and the original)

Provide a new CDN Version Link

Hello!

I have been using this Library since many years now and I like it a lot. Thank you for continuing the Project. Ive been following from the start here. Maybe I can contribute something too.

I compiled the latest version myself, but it would be cool to have a CDN Link for a quick usage and testing. I think we should use free CDNs for the start. So this Project would get more interaction also from newcomers.

Thanks for pushing materializecss forward <3

Table border color is different when using rowspan/colspan

In Chrom and Edge, when using rowspan or colspan, the table overlaps the color of the borders when the color is set to transparent rgba. As you can see in the image, there is a difference in the sections where rowspan and colspan are defined.

Expected Behavior

The color of the border is expected to be the same both on lines with colspan and on lines without colspan. The same for rowspan.

Current Behavior

In Chrome and Edge where rowspan and colspan are applied, the border color is much darker.

Possible Solution

It would be possible to get around this by defining $table-border-color with hexadecimal code instead of the current rgba. It would be something like $table-border-color: #dedede.

Steps to Reproduce (for bugs)

1. Just add a colspan="value" or rowspan="value" where value is the amount of row or column to be covered.
2. For easy viewing, increase the border size to 5px or 10px

Context

This problem is not something that gets in the way of reading the table or manipulating data. However, visually it does not please, since it does not comply with what has been defined.

Your Environment

• Version used: 1.0.0-rc.2
• Browser Name and version: Chrome (87.0.4280.141), Firefox (84.0.2), Edge (87.0.664.75)
• Operating System and version (desktop or mobile): 6.1.7601 Service Pack 1 Build 7601

Improve and make consistent chips' data object

Let's restructure the chip data object so that it is more consistent within the module and easier to model on the server side.

Expected & Current Behavior

Currently chips have no built-in capacity for numeric ids and have two different data structures depending on what you're doing.

If chips "represent small blocks of information. They are most commonly used either for contacts or for tags." (from the docs), then let's make them easier to work with as db-savable records without having to do string-comparisons on the tag text.

If the two current data structures look like:

// when initializing a chips component with existing data
[{
    tag: 'Apple',
}, {
    tag: 'Microsoft',
}, {
    tag: 'Google',
}]

// when initializing autocomplete options
{
    'Apple': null,
    'Microsoft': null,
    'Google': null
}

Then let's update them to be both more semantic, consistent, and functional for modelling:

// init a chips component with existing data OR define a set of autocomplete options with
[{
    tag: 'Apple',
    id: 1,
    image: null
}, {
    tag: 'Microsoft',
    id: 2,
    image: null
}, {
    tag: 'Google',
    id: 3,
    image: null
}]

Possible Solution

Part of this is shown-off in a well-travelled Stack Overflow answer that patches v1.0.0 to support an id property for autocomplete.

This could be a starting point as it does provide the desired functionality. I have this hack working on a personal project currently, but it requires additional hacky workarounds for the two different data structures.

I can start this feature in a fork if there is traction, but I've never worked on a project with a build pipeline before and my JS may not be up to what's required here.

Your Environment

• Version used: 1.0.0
• Browser Name and version: all
• Operating System and version (desktop or mobile): either
• Link to your project (if appropriate): ? https://prism.evansharp.ca/

bug: build step failled

Expected Behavior

No errors in pull requests

Current Behavior

Github actions trigger error on step "Deploy to Github Pages" because {{secrets.GITHUB_TOKEN}} is not shareable.

Possible Solution

Deploy documentation on push master.
Possible solution is to create a new 'deploy' step with :
if: github.ref == 'refs/heads/master'

discussion: needed labels

What labels are you missing? Which ones do we need and which colors would you recommend?

@materializecss/members

Upgrade Testing framework

In working on Dropdown I added a bunch of tests and ran into some issues. While investigating those issues I noticed that our testing framework is currently something like this, to the best of my knowledge. I'm pretty new to Grunt and front-end testing in general, so let me know if this isn't how it works.

1. grunt-contrib-jasmine (current version 2.20, Materialize version 1.2.0) is the Grunt plugin that uses PhantomJS to run Jasmine tests.
2. PhantomJS (current version 2.1, no longer developed) is the headless webkit simulating the browser for Jasmine to run in.
3. Jasmine (current version 3.6, materialize version 2.6) is the test runner and supplies most of the matchers.
4. Jasmine-jquery (current version 2.1.1 VERY abandoned) provides additional matchers for jQuery and the fixture loaders.

The only 2 components that aren't vastly out of date are because they haven't been developed in years.

It looks like the hardest thing to upgrade will be jasmine-jquery, so maybe a good plan would be to replace one component at a time and see what happens? Maybe something like

• grunt-contrib-jasmine 1.2.0 -> 2.20 (will mean changing from PhantomJS to Chrome Headless)
• jasmine 2.6 -> 3.6 (I don't see any huge breaking changes in the v2 to v3 upgrade guide, so hopefully easy)
• jasmine-jquery -> ? I'm lost on this one. I'm not sure what options there even are. @tomwjerry mentioned using a server for the fixtures or directly making them using DOM creation in javascript.

As I added tests I started thinking maybe any upgrades should be done first. Upgrading could end up being a pretty big change, especially if we replace jasmine-jquery, and I feel like it would be better to do while we have about 60 test cases rather than hundreds. What do the rest of you think? Worth upgrading now before we write more tests, or wait until something else forces an upgrade?

Range Slider Not Working

I am trying to use the Range Slider but it is not working and nothing is showing up on the screen.

<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width>
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Materialize CSS Range Slider</title>


    <!-- Compiled and minified CSS -->
    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/css/materialize.min.css">

    <!-- Compiled and minified JavaScript -->
    <script src="https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/js/materialize.min.js"></script>

    <!-- JQuery CDN -->
    <script src="https://code.jquery.com/jquery-3.5.1.min.js"
            integrity="sha256-9/aliU8dGd2tb6OSsuzixeV4y/faTqgFtohetphbbj0=" crossorigin="anonymous"></script>
</head>

<body>


<div id="test-slider"></div>

<script>
    var slider = document.getElementById('test-slider');
    noUiSlider.create(slider, {
        start: [20, 80],
        connect: true,
        step: 1,
        orientation: 'horizontal', // 'horizontal' or 'vertical'
        range: {
            'min': 0,
            'max': 100
        },
        format: wNumb({
            decimals: 0
        })
    });
</script>
</body>

</html>

Broken links in docs

Now we're hosting our own docs there are a few broken links due to it being at https://materializecss.github.io/materialize/ instead of https://materializecss.github.io/ (The easiest examples are the "get started" button and clicking on the materialize logo). I'm happy to open a PR to fix these or we could make a few changes (I'll open a PR for this too) and move it over. Third option: we get a custom domain which also would solve this.

datepicker does not support date range neither a method to change Min/Max Date

datepicker does not support the feature to select a range between two dates.

In the previous version (pickadate plug in) it works better than this all new writen datepicker plugin.

It does not even have a Method to change the initial options, and, for examaple, to change the MinDate and MaxDate options on change the start/end date input fields.

Also the possibility of pick only months isnt possible.

Thanks

NPM Package has outdated readme.md with old repo link

Expected Behavior

The NPM page for the maintained fork should point to the correct fork
https://www.npmjs.com/package/@materializecss/materialize

Current Behavior

There are many links that still point to the old repo, and the stats on issues and PRs is from the old repo

Possible Solution

I don't know anything about the process of publishing to npm, but I'm assuming that the version there is the 1.0.0 release and doesn't include any of the changes made since the fork. I think at the very least the readme changes should be pushed to 1.0.0 of materializecss/materialize to make sure npm is pointing to the correct fork. Those stats on open PRs and issues look bad, and some users might go to the old repo and leave without realizing there is an actively maintained fork.

Steps to Reproduce (for bugs)

1. visit https://www.npmjs.com/package/@materializecss/materialize

Documentation error: Undefined options variable inside all vanilla JS inits

Materialize attracts many new developers - in many cases they are using code snippets direct from the documentation, and in every single example the code contains a breaking error. For instance, select:

https://materializecss.com/select.html#initialization

  document.addEventListener('DOMContentLoaded', function() {
    var elems = document.querySelectorAll('select');
    var instances = M.FormSelect.init(elems, options);
  });

  // Or with jQuery

  $(document).ready(function(){
    $('select').formSelect();
  });

This results in:

Uncaught ReferenceError: options is not defined

options is not only not defined, it is never mentioned, and it is not included in the jQuery init. Example here. Remove options (and the comma) and it works fine.

We can imagine a new developer, excited by the project, using it for the first time and then being tripped up not even by a typo of his own, but by the documentation! it is unacceptable really.

Two proposed fixes:

1) Remove options from every affected page:

  document.addEventListener('DOMContentLoaded', function() {
    var elems = document.querySelectorAll('select');
    var instances = M.FormSelect.init(elems);
  });

2) Make reference to options:

document.addEventListener('DOMContentLoaded', function() {
var elems = document.querySelectorAll('select');
var instances = M.FormSelect.init(elems);
});

To initialise with options (for instance, to set a classname on the select container), we first declare the options and then pass as the second argument:

var options = { 'classes': 'my-select-class' }
document.addEventListener('DOMContentLoaded', function() {
    var elems = document.querySelectorAll('select');
    var instances = M.FormSelect.init(elems, options);
});

Or even:

  document.addEventListener('DOMContentLoaded', function() {
    var elems = document.querySelectorAll('select');
    var instances = M.FormSelect.init(elems, {});
  });

  // Or with jQuery

  $(document).ready(function(){
    $('select').formSelect({});
  });

Beyond this, to expand on the documentation, we should:

1. Create a new general page - Initialisation. List all components with a checkbox to indicate if it needs initialising. A cheat sheet almost.

2. Expand on the init examples provided. It is not immediately obvious how to set options, and it should be. The framework should be as easy as possible to use.

Affected components:

https://materializecss.com/floating-action-button.html
https://materializecss.com/navbar.html (sidenav)

https://materializecss.com/carousel.html
https://materializecss.com/collapsible.html
https://materializecss.com/dropdown.html
https://materializecss.com/feature-discovery.html
https://materializecss.com/media.html
https://materializecss.com/modals.html
https://materializecss.com/parallax.html
https://materializecss.com/pushpin.html
https://materializecss.com/scrollspy.html
https://materializecss.com/sidenav.html
https://materializecss.com/tabs.html
https://materializecss.com/tooltips.html
https://materializecss.com/autocomplete.html
https://materializecss.com/chips.html
https://materializecss.com/pickers.html
https://materializecss.com/select.html

Feature Request: materialize css email templates

I think this is one of those things that will take materialize to the next level. I saw this on zurb foundation css and it just blew me out the water.

They give the developers free and good email templates for most common needs such as "forgot password", "marketing", "welcome", and "newsletter" This is the coolest thing to me and I thought if in the future we can implement something similar for materialize css that would be amazing too!

This is not essential, but just something I thought would give us a huge boost in awesomeness!

here is a link to how zurb foundation is currently doing it
https://get.foundation/emails/email-templates.html

Plan to fix all current CVEs

As of this statement in #7:

I haven't checked, but are the current CVEs resolved on the fork?

They are related to XSS flaws:

• CVE-2019-11002(tooltip component)
• CVE-2019-11003(autocomplete component)
• CVE-2019-11004(toast component)

We know the CVEs are not fixed yet on Materialize, and there are already discussions in the original repository (Dogfalo#6331 and Dogfalo#6286) about this subject.

Current situation

Since the current CVEs are related to XSS that can be triggered when Materialize is used in a bad manner, this is the developer's responsibility to sanitize their data before using the three aforementioned components.

However, since the warnings will still display, and since Materialize can be "considered harmful" because of these (even though the discussions on the original repo suggest that it's not Materialize's problem, but rather how devs are using it), we should still find solutions to fix the warnings in an easy and backwards-compatible manner.

This is important for some CI that don't accept dependencies with warnings, or for clients that are worried about warnings they might not understand, especially when it's written "XSS" in them (which is a well-known flaw on the web in general)

Proposal

I suggest that for all the three involved components we add a boolean sanitizeInput option.

When this option is true, the input data will be sanitized with an equivalent of htmlspecialchars() in PHP. There are plenty examples about this on the internet, the best one I found is this one here:

function escapeHtml(text) {
  var map = {'&': '&amp;', '<': '&lt;', '>': '&gt;', '"': '&quot;', "'": '&#039;'};
  
  return text.replace(/[&<>"']/g, function(m) { return map[m]; });
}

Suggestions on other sanitizing methods are encouraged, since this has never been a "standard" process in the web industry 😄 .

Behavior on Materialize 1.x

This option will by default be null. To keep backwards compatibility, null will be equivalent to false.

However, if we detect null, we display a warning in the console, as a reminder to the developer that the native behavior of not-sanitizing is deprecated, and default value will change in 2.x to true.
To remove the warning, we suggest the user to specify the value themselves, even if it's false.
An explicit false will not trigger the warning, since this means that the developer knows what they are doing, and in such case, Materialize cannot guarantee input data safety.

Behavior on the future Materialize 2.x branch

Here, default value is true, and any falsy value will be interpreted as false. We could add type checks to force the user to specify a boolean, but I think this might be overkill. Suggestions appreciated 😉

---

Feel free to discuss all the different points, and even provide PRs if necessary.

[RFC] The state of material colors

My thoughts on "why this issue" initially come from the question asked in #52

I think having "all" colors directly in Materialize is really too much. I feel like Materialize should use only one color shade as global, allow to manipulate it for states (hovering, clicking, disabling, etc.), and don't use any other color by default. So the end user will define a "primary" shade, and all other shades will not be taken in account in Materialize at all.

I know that the color palette comes from the material design specs, but I feel like, in the future, it would be better for it to be detached from the "core" of materialize, in a @materializecss/colors package, or something similar.

Toy projects / side projects might use it, but IMO, most projects using it beyond toy-projects will probably have web designers behind them to change the entire palette to fit the client's brand design, so material colors are less useful.

In the end, using a specific repository for colors will definitely help in using CSS variables, if necessary.

WDYT?

Tab Accessibility Missing

Materialize CSS currently has an accessibility issue that needs to be fixed for future versions to make it even better! The user cannot tab through any of the fields created with Materialize CSS. This is a major issue for User Experience, User Accessibility, and SEO.

When I go through bootstrap and start tabbing through their buttons and their whole page, I know exactly where I am but when I try to do the same thing with Materialize I have no idea where I am. I think this can be easily seen in their websites docs that they both put up.

https://getbootstrap.com/docs/5.0/components/buttons/

https://materializecss.com/buttons.html

Every website that uses materialize will need the tab accessibility portion and if we can enforce good accessibility by default that would be all the better.

One less thing that the developers using materialize would have to think about and it makes a perfect website by default from UI, UX, and accessibility perspective. The developer then has to try to mess it up for it to not go perfectly.

We can do way better!

https://imgur.com/a/fJMKS0u

doc: images not found component Carousel

Current Behavior

On Carousel documentation page, the images are no longer available.

NPM readme is still using the old readme

https://www.npmjs.com/package/@materializecss/materialize

It links to Dogfalo/materialize and has the incorrect quickstart etc

Host new page for updated docs?

Possibly something like materializecss.js.org ?

loading data on FormSelect

How can I clear all FormSelect options and add new?
If I use browser-default class it works, but if I don't put it it doesn't work

<select name="my_select" id="my_select">
<option value="" disabled></option>
</select>

<script>
....
var results = data.data;

var select = document.getElementById('my_select');
// Clear previous options
var length = select.options.length;
for (i = length-1; i >= 0; i--) {
  select.options[i] = null;
}

for (var i = 0; i < results.length; i++) {
  var item = data.data[i];
  var option = document.createElement('option');
  option.text = item.name;
  option.value = item.id;
  select.add(option, i);
}
</script>

Action: Mark sidenav touchmove event listeners as passive

Chrome throws 3 violation messages, directly connected to the touchmove event listener attached to sidenav:

materialize.min.js?ver=1.0.0:6 [Violation] Added non-passive event listener to a scroll-blocking 'touchmove' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952

You can see the issue on any materialize site - even the docs - by reducing screen size so that the sidenav is off the screen, then check console > messages:

https://materializecss.com/

The fix, it seems, is to amend lines 132, 134 & 136 of sidenav.js. I honestly don't know what the broader implications of this are but the warnings disappear.

Changed from:

this.dragTarget.addEventListener('touchmove', this._handleDragTargetDragBound);
this._overlay.addEventListener('touchmove', this._handleCloseDragBound);
this.el.addEventListener('touchmove', this._handleCloseDragBound);

to:

this.dragTarget.addEventListener('touchmove', this._handleDragTargetDragBound, { passive: true});
this._overlay.addEventListener('touchmove', this._handleCloseDragBound, { passive: true});
this.el.addEventListener('touchmove', this._handleCloseDragBound, { passive: true});

Maybe someone could confirm this, and then talk me through how to make this into a change?!!?

Materialize Moving Forward

Hey all,

I'm coming here from the discussion here.

I am happy to start providing pull requests. There are several minor issues that I would love to be fixed in the short term, as I have been using materialize in a very mature Laravel/Vue project in production for the last 4+ years. If there's a confirmation that this is in fact the place to put pull requests and that they will be accepted here instead of stagnating, I'd like to help.

Let me know if there is some sort of organization/trello/work board that i can see.

CI: move to GHA

We should move from TravisCI to GHA.

list of PRs to merge

Let's collect the open PRs that we have to merge. We already merged a few using the GitHub CLI.

For the needed steps see #2 (comment)

https://github.com/Dogfalo/materialize/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc

Already merged:

Fix some typos (found by codespell)
datepicker: add yearRangeReverse property sort year in reverse order
fix dropdown position when coverTrigger is false
Typos in upgrade guide

Planned to merge:

passive event receivers
Add input suffix
Add new i18n option 'headerFormat' to datepicker

Feature request: Search/Filter bar in the multi-select Select form component

Would love to have the option to easily add a Search/Filter bar at the top of the multi-select dropdown boxes.

The above screenshot is using Bootstrap's Multi-Select plugin. So I am looking for that same functionality from Materialize. Here is a live example of how it works: https://www.jquery-az.com/boots/demo.php?ex=63.0_9

Thanks!

Dependencies cannot be installed.

Expected Behavior

After cloning the repository, I tried to install the dependencies with:

npm ci

Current Behavior

But I got an error installing node-sass:

> [email protected] install /mnt/Daten/tmp/node/materialize/node_modules/node-sass
> node scripts/install.js

Downloading binary from https://github.com/sass/node-sass/releases/download/v4.14.1/linux-x64-88_binding.node
Cannot download "https://github.com/sass/node-sass/releases/download/v4.14.1/linux-x64-88_binding.node": 

HTTP error 404 Not Found

Hint: If github.com is not accessible in your location
      try setting a proxy via HTTP_PROXY, e.g. 

      export HTTP_PROXY=http://example.com:1234

or configure npm proxy via

      npm config set proxy http://example.com:8080

> [email protected] postinstall /mnt/Daten/tmp/node/materialize/node_modules/node-sass
> node scripts/build.js

Building: /usr/bin/node /mnt/Daten/tmp/node/materialize/node_modules/node-gyp/bin/node-gyp.js rebuild --verbose --libsass_ext= --libsass_cflags= --libsass_ldflags= --libsass_library=
gyp info it worked if it ends with ok
gyp verb cli [
gyp verb cli   '/usr/bin/node',
gyp verb cli   '/mnt/Daten/tmp/node/materialize/node_modules/node-gyp/bin/node-gyp.js',
gyp verb cli   'rebuild',
gyp verb cli   '--verbose',
gyp verb cli   '--libsass_ext=',
gyp verb cli   '--libsass_cflags=',
gyp verb cli   '--libsass_ldflags=',
gyp verb cli   '--libsass_library='
gyp verb cli ]
gyp info using [email protected]
gyp info using [email protected] | linux | x64
gyp verb command rebuild []
gyp verb command clean []
gyp verb clean removing "build" directory
gyp verb command configure []
gyp verb check python checking for Python executable "python2" in the PATH
gyp verb `which` failed Error: not found: python2
gyp verb `which` failed     at getNotFoundError (/mnt/Daten/tmp/node/materialize/node_modules/which/which.js:13:12)
gyp verb `which` failed     at F (/mnt/Daten/tmp/node/materialize/node_modules/which/which.js:68:19)
gyp verb `which` failed     at E (/mnt/Daten/tmp/node/materialize/node_modules/which/which.js:80:29)
gyp verb `which` failed     at /mnt/Daten/tmp/node/materialize/node_modules/which/which.js:89:16
gyp verb `which` failed     at /mnt/Daten/tmp/node/materialize/node_modules/isexe/index.js:42:5
gyp verb `which` failed     at /mnt/Daten/tmp/node/materialize/node_modules/isexe/mode.js:8:5
gyp verb `which` failed     at FSReqCallback.oncomplete (node:fs:196:21)
gyp verb `which` failed  python2 Error: not found: python2
gyp verb `which` failed     at getNotFoundError (/mnt/Daten/tmp/node/materialize/node_modules/which/which.js:13:12)
gyp verb `which` failed     at F (/mnt/Daten/tmp/node/materialize/node_modules/which/which.js:68:19)
gyp verb `which` failed     at E (/mnt/Daten/tmp/node/materialize/node_modules/which/which.js:80:29)
gyp verb `which` failed     at /mnt/Daten/tmp/node/materialize/node_modules/which/which.js:89:16
gyp verb `which` failed     at /mnt/Daten/tmp/node/materialize/node_modules/isexe/index.js:42:5
gyp verb `which` failed     at /mnt/Daten/tmp/node/materialize/node_modules/isexe/mode.js:8:5
gyp verb `which` failed     at FSReqCallback.oncomplete (node:fs:196:21) {
gyp verb `which` failed   code: 'ENOENT'
gyp verb `which` failed }
gyp verb check python checking for Python executable "python" in the PATH
gyp verb `which` succeeded python /usr/bin/python
gyp ERR! configure error 
gyp ERR! stack Error: Command failed: /usr/bin/python -c import sys; print "%s.%s.%s" % sys.version_info[:3];
gyp ERR! stack   File "<string>", line 1
gyp ERR! stack     import sys; print "%s.%s.%s" % sys.version_info[:3];
gyp ERR! stack                       ^
gyp ERR! stack SyntaxError: invalid syntax
gyp ERR! stack 
gyp ERR! stack     at ChildProcess.exithandler (node:child_process:327:12)
gyp ERR! stack     at ChildProcess.emit (node:events:378:20)
gyp ERR! stack     at maybeClose (node:internal/child_process:1067:16)
gyp ERR! stack     at Socket.<anonymous> (node:internal/child_process:453:11)
gyp ERR! stack     at Socket.emit (node:events:378:20)
gyp ERR! stack     at Pipe.<anonymous> (node:net:665:12)
gyp ERR! System Linux 5.10.13-hardened1-1-hardened
gyp ERR! command "/usr/bin/node" "/mnt/Daten/tmp/node/materialize/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="
gyp ERR! cwd /mnt/Daten/tmp/node/materialize/node_modules/node-sass
gyp ERR! node -v v15.8.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok 
Build failed with error code: 1
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] postinstall: `node scripts/build.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] postinstall script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

Possible Solution

It looks like some scripts are depending on the discontinued version 2 of python.
I'm not sure whether newer versions of node-sass are updated to version 3, yet. If so, one might want to update that dependency.

Your Environment

$ python --version
Python 3.9.1

$ npm --version
6.14.11

$ node --version
v15.8.0

$ git branch --show-current
v1-dev

$ git rev-parse --verify HEAD
a748515b0cd0a6ca2d018cd0458d292c40e18d9c

Regards
🂩