Open Ecksters opened 9 years ago
Well we actually implemented the design for our tables before data tables were added to material design, so that's why. Later on we will change it to match more closely
Okay, maybe it's something I can look into adding
@DaEckster that will be great to see added! Thanks
+1 I need data tables with checkbox and radio button support.
Any progress on tables?
I like the idea, but I think we would have to discuss the functionality of this component. Should it be a data-table or just a table and how it should look like on mobile? Comments are welcome!
Some sources I found: https://material.io/guidelines/components/data-tables.html https://getmdl.io/components/index.html#tables-section https://eucalyptuss.github.io/material-foundation/#tables https://v4-alpha.getbootstrap.com/content/tables/ https://codepen.io/zavoloklom/pen/IGkDz https://iamisti.github.io/mdDataTable/
From a sheer appearance perspective following the https://material.io/guidelines/components/data-tables.html and https://getmdl.io/components/index.html#tables-section guidelines feel like the best approach for the standard table use cases. I've been working with Materialize and Vuejs to build my own client-side table component and I've run into various styling conflicts that I wish were formally addressed by the library. Things like inputs, badges, or tags in table cells can cause all sorts of alignment issues that need special rules and I've had to figure those out as I go. Those become especially troublesome if you use check boxes for selection and then use the responsive-table
class.
I'd prefer having all the CSS written upfront and documented to support those basic uses like sorting and row selection. If the CSS is available, the materialize team can decide to focus on a JS implementation of tables or leave it for now. If the styles are all available to abide by, the users can determine if a plugin library is warranted in their use case, as raw html will sometimes be all that is required and a JS library is overkill. It wouldn't be a monolithic undertaking to write a JS library, jQuery Plugin, or use any of the big frameworks to take advantage of those classes once they've been introduced.
maybe could be good add in the materialize spec list those changes that should be made in order to make the components compatible. to keep an eye on that.
I've assumed since I started using Materialize that the goal of the project was to follow Google's Material guidelines as closely as possible, however, I've seen a few derivations from the guidelines, table headers would be one example. Is this a bug, or are some design decisions being made that diverge from the Material Design spec?