Can this CSS be used for data table visualizations too (at least to some level)? If not, maybe 'table' isn't necessarily the best CSS class to use, since it's so generic.

There are 2 things addressed in this PR:

• the system check needs to look good
• <table> tags that aren't style look really bad (which is kind of a pain if, as a core or plugin developer, I need to write custom CSS to show a dumb table)

Since the system check is just a table (nothing specific here), and since we might want to display some tables elsewhere in Piwik (e.g. plugins might want to), I chose to make this style generic (that's why the name is really generic, and again for reference it's inspired by bootstrap tables).

Data tables are different since they are much more specific (plenty of features for those tables for example), I didn't change anything regarding that. We could look into it, but I think those tables are really different and they don't serve the same purpose (i.e. it's fine if they have their own style).

Data tables are different since they are much more specific (plenty of features for those tables for example), I didn't change anything regarding that.

I wasn't suggesting that you make any changes in this regard. The CSS class 'table', however, sounds to me like it should apply (perhaps as a base) to the data table CSS. If this isn't the case, then maybe the name of the class isn't the best one.

@mnapoli What about 'simple-table', 'plain-table' or 'basic-table' for the CSS class?

@mattab @tsteur Do you have any opinions? If no one has an opinion and @mnapoli would rather use 'table', I'll just merge.

As it doesn't look like this is a style that would be used somewhere else I wouldn't make it generic. I would have it in the plugin that defines the system check and only there until we actually have more use cases for this table. Then it'll be also clear what name would be maybe better. I wouldn't go with table. Even table.table looks redundant. I would rather use something like .systemCheck .checklist or so.

Generic can be good, but wouldn't make it generic yet. We don't have to expose CSS classes for any possible use cases yet. I'd personally rather focus on the ones that we're kinda sure will be used multiple times such as dataTable and entityTables. I would not even see this here as a table even if it is technically a table. I'd see it rather as a checkList or so. There might be a better name.

I would be +1 for simple-table for example.

Generic can be good, but wouldn't make it generic yet. We don't have to expose CSS classes for any possible use cases yet.

I would classify "making a simple table" in the "any possible use case" category. When I see that plugin developers need to resort using the tables that are meant for reports (with the very explicit names entityTable plus dataTable (and don't forget one, else it just look completely weird)), or code their own CSS, I just feel bad for them.

Have you seen what a table look like in Piwik:

This is a joke. And what I want to do is to fix that. Maybe my mistake was to have the system check as a central example, but the title of the pull request is New design for default tables and this is exactly about that. To sum up:

• it isn't possible to create simple tables in Piwik
• yes tables are used outside of DataTable reports in plugins, there is a need for that: 1, 2, 3, 4, 5, 6, 7, 8, etc.

Now we could create a different style for that default/simple table. However I don't see why the system check should have its own custom style (we have already too much custom styles for everything…). I very much favor simplicity and consistency both visually and in the code for the benefit of users, core developers and plugin developers. Ideally we would have a table style for DataTable reports, and one for simple tables (and maybe another one for the site/user/alerts/… managers…). And if the style proposed here isn't good enough for a simple table design, we change it.

Have you seen what a table look like in Piwik:

Then I would maybe style <table> like this without having to use a CSS class. This way it would look better out of the box without having to do and look up anything. This would be our default table style.

I'm not sure re simple-table. It doesn't mean a lot and how do we know this is a simple table? Maybe there are other "simple" table styles as well etc. It's okay for me to do and can be merged but I usually don't make generic things from just "one" use case. Many of the links you provided are entity tables and the security check is kinda similar to the system check where a class like checkList or so would rather describe it.

The questions is what kind of tables will developers create and what do we want them to create etc. I do not really want them to create tables etc at all "if possible". Re entity tables we already have a solution and instead of having to use HTML I rather want them to use a component see #6951 . It is way to hard (it's impossible) to make it all look and feel the same otherwise. For plugin settings we already wrote the Settings API to avoid having them to create any HTML/Controller... Ideally developers don't have to write any HTML for most of the cases. Still, we have to use such classes internally anyway. Those components do not replace that. I guess what I'm trying to say is that not having tables styled super awesome is not a big deal but definitely would be nice to have tables look nice out of the box.

Anyway, it's okay for me as we can refactor it again later if we don't have to care about BC

Then I would maybe style <table> like this without having to use a CSS class. This way it would look better out of the box without having to do and look up anything. This would be our default table style.

This makes sense to me, and I'd be ok w/ this. However, since Piwik uses tables in many places, making sure these styles are overridden correctly everywhere could be a daunting task. Using a separate CSS class that isn't part of the @api, just exists to help organize & simplify existing CSS w/ some basic layout styles, seems like a good idea to me. And a simpler one to implement.

Many of the links you provided are entity tables and the security check is kinda similar to the system check where a class like checkList or so would rather describe it.

Seems more like a table w/ checklists in it to me.

Then I would maybe style <table> like this without having to use a CSS class.

As I explained in the PR introduction, tables are used a lot in Piwik for layout. I've tried to style default tables and it breaks many screens. Like @diosmosis said, fixing that could be a daunting task. But I definitely agree that this would be the ideal solution. The CSS class I'm suggesting is a workaround for this, just like it's done in Bootstrap and in PureCSS, but unlike MaterializeCSS and Foundation which style the default tables.

I'm not sure re simple-table. It doesn't mean a lot and how do we know this is a simple table?

I understand, but current classes are "data" table and "entity" table… What's more generic than a table that contains data. But to be more constructive I see 2-3 kind of needs today in Piwik (maybe there's more?):

1. showing a static list of things displayed in a tabular way
2. managing a collection of items with dynamic features, e.g. maybe editing in line, pagination, inline icon buttons… (that would be the "managers", e.g. user manager, site manager, …)
3. showing a DataTable report, needs to be compact, sorting, icons inline, etc etc.

Today when we have 1., we need to use 2. or 3. as a workaround or code custom style (examples I linked to).

It's okay for me to do and can be merged but I usually don't make generic things from just "one" use case.

… In the list of example I provided, there are indeed examples of "managers". However 1, 2, 6, 7, 8 are not about managing anything, these are informational tables. There is no interaction at table, it's just a list of things displayed in a table.

And for 1 and 2 I agree with @diosmosis:

Seems more like a table w/ checklists in it to me.

FYI icons in the system check are not part of the table. If you strip the icons (which are content because not part of the table itself) and change the words, it has nothing left to do with a checklist (whereas "manager table" would stile have features to manage the list, and "report table" would still have features specific for showing/browsing/sorting report data)

I do not really want them to create tables etc at all "if possible". Re entity tables we already have a solution and instead of having to use HTML I rather want them to use a component see #6951

I understand and agree with that, however I've had experiences with "we want to provide a generic component to edit a list of entities" and it's a huge task. But anyway, in the meantime, it doesn't address the problem n°1.

Anyway, it's okay for me as we can refactor it again later if we don't have to care about BC

I don't understand this part, the point is that plugins will be able to use this class (so it would become API).

I think everyone would agree to the following points:

1. It would be good to have a base style for plugin developers to use when using tables.
2. Ideally, the styles should be applied to the <table> element and not to a specific CSS class.

Points of contention appear to surround making the CSS class API (ie, so plugin developers can use them) and the amount of work needed to do it for <table>. Perhaps this would be a good solution:

1. Modify this PR (if needed) specifically to make it easier to change the code so the styles are eventually applied as a base to <table>s instead of a CSS class.
2. Include this change in 2.14 w/o documenting the CSS class and making it API.
3. For 3.0 modify the styles to apply to <table>.

What do you think?

I'm pretty much ok with anything. If it's a lot of work to make it work with <table> then I wouldn't do it as might be not as often used. It has not really a priority for me as mentioned earlier (I don't want developers to write HTML/CSS in like 98% of the cases). dataTable is kinda specific CSS class since it related to our DataTable. We'll need to rename that class in core one day.

@diosmosis sounds good will do that! #7960 should definitely help in that direction too

Created #8023

Renamed the table class to simple-table and removed it from the UI demo (so it's not documented anymore).

Ready for final review/merge!

@mnapoli Screenshot tests fail, some of them are very different (like the Installation DB setup page). Can you take a look?

Thank you I have pushed an update (made the installation forms use the simple-table style). This is not really important as #7960 should be merged in 2.14 and redesign those forms anyway, but might as well keep a clean pull request so 👍