Materialize: Freedom for the <nav> default style

[donacross]

Issue : <nav> is directly styled by it's tag name

Hi Materialize and thank you for your great work. :tada:

Is it intentional to directly style the <nav> tag ?

If it's not intentional, would you consider to avoid to do it ? Would you like a pull request ?

Demo

Codepen

Arguments

If it is intentional, I'm afraid it's considered bad practises.

Here is a few arguments :

• Multiple <nav> in a page is a legit use case
• <nav> may not be "navbar" or "toolbar"
• <nav> elements are important for accessibility and SEO.
• Separation of concerns applies to HTML & CSS
• Material Design Spec seems to be aware of this concern.
• The way the <nav> is styled in Materialize make it hard to override. (nesting depth of CSS selectors)

I understand this would be a breaking change but I hope you'll understand the necessity of it.

Thank you for your time

Cheers

[DanielRuf]

I guess this requires a bigger rewrite of the component and would be a breaking change.
And I think it would be good to extend this to other components where components have no context and no classes and are solely styled depending on the tags.

This would also fix other issues (https://github.com/Dogfalo/materialize/issues/4764 https://github.com/Dogfalo/materialize/issues/4661 https://github.com/Dogfalo/materialize/issues/4660) and ease the general usage with own styles.

[DanielRuf]

@tomscholz @fega could we create a board for this and collect related issues?

[tomscholz]

What do you have in mind?

[DanielRuf]

Meant project https://github.com/Dogfalo/materialize/projects

Still confusing this with Trello and other solutions.
We should collect the affected files and components and mark the lines using the commit hashes.

Probably one component after another but as separate branch for a later release so things do not break too often (eg each new release brings a new refactored component).

Maybe as bleeding edge non-stable for testers and not as normal release and as new major release (probably also refactoring and replace jQuery with vanilla JavaScript) after SemVer.

[donacross]

Thank you for your quick answers. You guys are really reactive, that's amazing.

200% agreed with you @DanielRuf.

I'd suggest you'll adopt SemVer after refactoring all components or ship every breaking change in a same release, otherwise you'll end up with a Materialize v36.0.0 pretty fast. It might be confusing for users and might damage your _"brand trust"_.

A cautious road map might be :

1. Refactor component's style one after another in an incremental release path upon 0.x.x
   _Achievable goal. Ease integration with 3rd party. Fast ROI. Everyone is happy._
2. Adopt SemVer and ship 1.0.0
   _Send a strong signal to the community about your ambitions._
3. Intent to drop jQuery dependency step by step in a separate VanillaJS branch.
   _Make a public announcement. Call for help among contributors and plugin developers._
4. Merge successively every 1.x.x releases upon VanillaJS branch as the developpement / maintenance of 1.x.x progresses.
   _Will help the final merge._
5. Perform a final merge when VanillaJS branch is ready, and start a release canditate cycle.
   _Start to gather feedbacks from the community and adjust to them._
6. Ship 2.0.0
   _Celebrate and get drunk. (IRL)_

Intending to drop jQuery will be savage as Materialize have many dependencies on jQuery plugins (datepicker, srollspy, etc). You could also loose the jQuery addicted fanbase... Moreover, I feel jQuery is not a big entry cost for most projects as it still very popular, already shipped with WordPress, _faster than before_ and easly accessible with CDNs. I tend to personally see Materialize as a _"big jQuery plugin"_ even if I'm not a big jQuery fan myself.
I'm not even sure my point _4._ would welp as it'd become be a total rewrite.

On the other hand, the idea to be ES6/ES7 compliant might be very well received by the community and could galvenize everyone to start contributing. Being able to promote yourself as a dependency free _framework_ would also be a big marketing argument.

So, a big investment cost for a low short term ROI, I guess many product managers would lough at us. But we worth better than that, don't we ? We understand the sake of a sustainable long term CI.

People used to say adopt early is important, let's say so does drop early.

Gathering the community is the key here, why not create a survey ?

Why not also adopt TypeScript ? Okay, let's not get too excited here.

[DanielRuf]

@donacross I totally agree with all your points and your thoughts about this and these are some good recommendations for a possible roadmap.

Sure, jQuery is stll part of some other dependencies.

The goal is to have more performant and native ES6/7 components as jQuery as abstraction layer adds some unneeded overhead and constraint in many cases.

This would also make the components consumable for more projects and solutions where you do or can not directly work with the real DOM.

The ideal solution in this case would be truly independent components which could be easier leveraged in projects based on React, Vue.js and other solutions.

@fega @tomscholz your thoughts on this?

[donacross]

Sounds great, I'd be happy to help.

[crtl]

I thought about this problem too and thought about fixing it by myself but I didtn have the time.
The global styling in materialize-css really prevents me from using it because I have an existing codebase which interferes with materialize-css styles and it would be huge effort to rewrite my existing components.

[Dogfalo]

See #5004