Essential, presented styling should not reside in any CSS class named "demo". I saw this often in MDL. Please rethink any CSS class in the documentation containing the word "demo". Any and all demoed styling ought to be contained in a core library - as "complete" or "full" or "default" - but not "demo".
There is a reason the demos have extra styling custom to them. Some things aren't spec aligned or are difficult to do in a generic way internally to the library. So the demo shows how to achieve it with custom rules. The goal is to provide a base set of components for general application usage. Developers are expected to add their own code to achieve the exact styling they need within their apps.
Stop fixing bugs and stop development and instead integrate examples into the documentation. Let the examples become the documentation.
So bug fixing and further library development is now frowned upon? I think this may have been scoped to the documentation only but isn't clear enough.
Stop creating examples for React, Angular, Vue, and Aurelia. Those are covered already. Riot.js deserves some Material Design attention. Lead.
Examples are just here to have something internal to test the interface system against. They aren't for actual use. If you feel Riot deserves a MCW implementation, please build it and distribute it. As much testing from people who actually use these various libraries and frameworks happens and feedback from those experiences comes in the better the system can be. The MCW team doesn't have the manpower to do it all internally.
Thank you @philmaker1 for expressing such interest in the future of MDC Web. There are a lot of requests here, so I'll do my best to reply to each one.
Stop following the black and algae green theme of the main material.io pages.
I'm afraid I cannot change this. This is consistent with the Material Design Components brand.
Stop fixing bugs and stop development
Like @Garbee said, I cannot stop fixing bugs or stop development. We're a library that requires constant development.
instead integrate examples into the documentation. Let the examples become the documentation
Could you be more specific? We do have documentation that shows HTML examples
Study the presentation of the documentation for vue-material, MDL, elm-mdl, and material-ui
Is there something about these projects' documentation that you like in particular?
Stop creating examples for React, Angular, Vue, and Aurelia. Those are covered already. Riot.js deserves some Material Design attention.
We would love to see an external contributor create a repository that wraps MDC Web for the Riot.js framework. If you have any issues with our Foundation/Adapter that blocks you from creating Riot.js wrappers, feel free to file specific issues with us.
presented styling should not reside in any CSS class named "demo"
+1 to @Garbee comment, "Some things aren't spec aligned or are difficult to do in a generic way internally to the library. So the demo shows how to achieve it with custom rules"
I'm going to close this issue because it is difficult to talk about all these requests in one thread. Feel free to open a new issue with more specifics about examples in documentation, or a new issue about other projects' documentation you think MDC Web could benefit from.
Most helpful comment
There is a reason the demos have extra styling custom to them. Some things aren't spec aligned or are difficult to do in a generic way internally to the library. So the demo shows how to achieve it with custom rules. The goal is to provide a base set of components for general application usage. Developers are expected to add their own code to achieve the exact styling they need within their apps.
So bug fixing and further library development is now frowned upon? I think this may have been scoped to the documentation only but isn't clear enough.
Examples are just here to have something internal to test the interface system against. They aren't for actual use. If you feel Riot deserves a MCW implementation, please build it and distribute it. As much testing from people who actually use these various libraries and frameworks happens and feedback from those experiences comes in the better the system can be. The MCW team doesn't have the manpower to do it all internally.