Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce Bootstrap as a CSS/HTML framework #7390

Closed
mnapoli opened this issue Mar 9, 2015 · 10 comments
Closed

Introduce Bootstrap as a CSS/HTML framework #7390

mnapoli opened this issue Mar 9, 2015 · 10 comments
Labels
answered For when a question was asked and we referred to forum or answered it. RFC Indicates the issue is a request for comments where the author is looking for feedback.

Comments

@mnapoli
Copy link
Contributor

mnapoli commented Mar 9, 2015

I would like to start the discussion about introducing Bootstrap, or parts of Bootstrap, in Piwik.

The idea is that standard CSS classes and HTML structures like container, columns, buttons, forms, etc. make it much easier for core and plugin developers: no need to always code custom CSS or explore other plugins to find some reusable CSS.

It would also allow to get rid of some HTML/CSS/JS code for components like buttons, forms, alerts, and maybe tables, panels (for widgets), etc.

FYI Bootstrap is written in less and customizable with variables. It is also written as independent components, so to give it a try I have started integrating the base container classes and grid system. This was easier than I thought as I was able to rewrite the dashboard with it, so we could consider doing this for more parts of Bootstrap…

What do you think of this idea?

@mnapoli mnapoli added the RFC Indicates the issue is a request for comments where the author is looking for feedback. label Mar 9, 2015
@mnapoli mnapoli added this to the Short term milestone Mar 9, 2015
@tassoman
Copy link
Contributor

tassoman commented Mar 9, 2015

Well I agree using Bootstrap because It's a common front end framework more friendly to designers, at the same time I suggest keeping an eye on WAI-ARIA support because would be easier for the maintenance of accessibility issues.

If BSD license is GPL compatible, we could also rely on Paypal's Boodstrap Accessibility Plugin

@mnapoli
Copy link
Contributor Author

mnapoli commented Mar 25, 2015

Now that #7481 is done it's good to see that the main issue was the change from box-sizing: content-box to box-sizing: border-box. The rest was pretty easy to deal with.

I am now planning to introduce the entirety of Bootstrap in Piwik. The most compelling reason is because of the redesigns of the interface that are planned (e.g. #7450, #7492, etc.): I started on #7450 and having Bootstrap classes would make the whole thing easier.

I also want to refactor a bit the CSS of plugins. The current situation is plugins define CSS quite randomly and it gets applied in the plugin but also everywhere. For example CSS from the dashboard gets apply in the admin section and vice-versa.

My goal is:

  • Piwik includes Bootstrap CSS for having base CSS classes
  • Morpheus:
    • defines the base Less variables
    • defines additional base CSS classes (as few as possible, they should be documented)
    • defines the base Twig layouts, macros, Twig extensions, etc...
    • provides a default theming of all those base classes (i.e. default Piwik appearance)
  • plugins:
    • define CSS classes as namespaced/targeted as possible
    • ideally they shouldn't define or override global CSS classes (e.g. don't override the style for p, rather if it's for the admin section do something like .admin p)
  • themes:
    • can then override Less variables (colors, …)
    • but also they can theme the base CSS classes (e.g. the notification boxes, etc. etc.)

With this it should be much easier to know what CSS classes are available, it should be easier to maintain them because plugins shouldn't mess up with the base stuff, hopefully that should reduce the amount of CSS in Piwik, themes should be more powerful (i.e. able to customize more stuff), etc.

The main drawback I can imagine is that some current plugin's CSS might have to be updated (else the plugin's look might have changed because of the changes in CSS classes). We should maybe discuss how much "BC" we want to preserve (keeping in mind that the more BC we need, the harder/longer it will be).

Thoughts?

@mattab
Copy link
Member

mattab commented Mar 25, 2015

Hi @tzi not sure if you are available, but maybe we could work together on this project sometime?

@mattab
Copy link
Member

mattab commented Mar 25, 2015

I'm not sure we should include all of bootstrap for now

  • it could be a lot of work and we have many things to work on already: https://github.com/piwik/piwik/milestones/Piwik%202.13.0
    • if we keep BC then we have a messy code using both old and bootstrap styles
    • if we don't keep BC then
    • we'd have to change maybe a lot of plugins. It's hard to justify this without a clear value to users or developers or us, besides that it will improve the CSS/class naming (which is nice but not must-have yet).
    • we would possibly break marketplace plugins or other third party plugins

For example CSS from the dashboard gets apply in the admin section and vice-versa.

+1 to fix this but it can and should be fixed without need to involve bootstrap (by fixing this

Responsive was a nice feature for example, but this does not need the whole of bootstrap and I think was already done in another PR (although maybe not everywhere in all screens).

but also they can theme the base CSS classes (e.g. the notification boxes, etc. etc.)

Theme designers can already theme the boxes, it's just "not documented" although it works... Using bootstrap would be nice as it's kind of a standard but: it's not really a standard (a new standard could be born in next 1 or 2 years), and we don't really need to improve the Theming part of the platform (considering themes are good feature but not as important as platform, speed, plugins, security, usability, etc.).

So in theory it's good idea, but considering the work involved, we can't afford it yet. note that it would good to fix the separate issues that you may have listed above, if we need to have them fixed. Already fixing those as first steps, would help us the day we decide to use a CSS standard like boostrap. Considering there are a lot of important tasks to work on, eg. in 2.13.0 already and then in preparation to upcoming Piwik 3.0.0 I think this has to wait for 3.x sometime.

@diosmosis
Copy link
Member

We should maybe discuss how much "BC" we want to preserve (keeping in mind that the more BC we need, the harder/longer it will be).

Haven't really looked at this in detail, but is it possible to maintain BC, by adding a layer of LESS that maps old CSS to new bootstrap CSS? Could keep this in for a while, and remove it later after plugins have been converted.

@tzi
Copy link
Member

tzi commented Mar 25, 2015

Hi Piwik team!

Bootstrap is a great toolkit. It's well known by the plugin developers & well documented!
It could be great to have it on Piwik, it could ease development & improve our CSS best practices.
For example, we really should use box-sizing: border-box!

But Bootstrap is not perfect and it could take a lot of migration work.
Perhaps we can create our own simple documentation and it could solve the problem!

  1. Create something simple, like the Yelp styleguide
  2. Document the isolated components, it could help us improve our code quality by showing the lacks.
  3. Made it available to core & plugin developers.
  4. Could use it, with our automatic screenshot, to prevent front-end regression.

The great part is, if we need custom component, specific to the Piwik need, it will be documented and usable. With Bootstrap, we are limited to the Bootstrap documentation.

Cheers,
Thomas.

@tsteur
Copy link
Member

tsteur commented Mar 25, 2015

Great idea @tzi

While it would be nice to have something like Bootstrap or Foundation in Piwik it is not really so important or urgent for me. More important is to have such a styleguide which we could start to create bit by bit when working on the new screens such as updates. Keeping BC etc. will be quite hard I reckon, hard to test and will lead in a mess.

Theme developers are supposed to only change colors and fonts. This is our current API for themes and I think it will be good to keep it like this. It is a good trade-off. Easy to maintain while giving the developers to change quite a lot. Often they just want to adjust the colors to their corporate identity which can be done by changing 2 or 4 less variables.

Plugin developers do ideally not have to do deal so much with CSS if at all. I'd rather provide "components" that do all the work for the devs to actually guarantee the look and behaviour will be consistent everywhere. Eg see #6951. Same for reports etc. where plugin developers don't have to deal with CSS. Only if they build custom pages they will actually need such CSS but don't think this will be often the case.

For us core developers it would be great but think a styleguide would do the job as well and we would benefit from that much more. Plugin developers if they need CSS as well.

@mattab
Copy link
Member

mattab commented Apr 9, 2015

@tzi Really like your idea!

Note that we started using bootstrap useful grid system as we had several grid issues before.

@mattab
Copy link
Member

mattab commented Apr 9, 2015

At this point we've decided not to introduce more of Bootstrap in Piwik - we will re-visit using a framework such as boostrap or another one in the future, in months or next year.

@tzi feel free to create an issue with your proposal of "style guide" - creators of plugins and themes would love such tool

@mattab mattab closed this as completed Apr 9, 2015
@tassoman
Copy link
Contributor

tassoman commented Apr 9, 2015

I fully agree with you guys 👍

Building the style guide could be also an useful workshop stage for students doing communication, design and information technology. Just in case.

@mattab mattab added the answered For when a question was asked and we referred to forum or answered it. label Oct 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
answered For when a question was asked and we referred to forum or answered it. RFC Indicates the issue is a request for comments where the author is looking for feedback.
Projects
None yet
Development

No branches or pull requests

6 participants