rbarbour:
IMO,
Q. Should the next version of Zen Cart use a CSS/grid framework?
A. Absolutely, but the core framework should be separate from the "enabled by default" template.
Q. Bootstrap vs Foundation vs None vs Other (which)?
A. The core should be Zen Cart Specific (Other) and the "enabled by default" template should be based on a framework (really doesn't matter) but should NOT extend to the core.
Q. WHY YOU CHOSE THAT ANSWER?
A. The core needs to be global and consistent so any framework or custom built template can be added without framework dependency. The "enabled by default" template needs to be a simple and attractive out-of-box open shop make money solution for the novice.
Q. Are you answering as a storeowner, or as a programmer?
A. Both
I have nothing NEW to offer this discussion because my thoughts mirror this entire statement. I will add this though, I think that Bootstrap or Foundation frameworks should be a CHOICE and perhaps Zen Cart could consider following the path of some other CMS's codebases whereas there are Bootstrap or Foundation plugins which add this functionality versus bundling these frameworks into the codebase.. Now if these "official" plugins were even maintained by Zen Cart this would prevent the clusterf**k of issues that came with plugin and template authors all bundling in conflicting versions of jQuery with their contributions. If the Foundation or Bootstrap plugins were official plugins, then template or plugin authors could then write their Foundation or Bootstrap dependent code based on the official supported modules to ensure they maintain compatibility.
Finally there's this article https://www.gavick.com/blog/mixing-j...isnt-good-idea. While this article is from 2014 and is specific to Bootstrap and Joomla, the reasoning in this article to not bundle in Bootstrap could apply just as easily to any CMS including Zen Cart, or WordPress, or Drupal, or Presta Cart, or (shudder) OsCommerce..
Here's the highlights:
At first glance, it seems like there aren’t any negatives; Bootstrap looks great, it’s easy to use, supports CSS preprocessors like SASS and LESS, provides cross-browser solutions and it’s free; released under the MIT license. But if you take a moment to look closer, you might notice something interesting; no popular CMS uses this kind of frontend development framework in their core, because ultimately it seems that it causes more problems that it fixes.> Bootstrap’s weight
Bootstrap’s minified CSS weighs around 130 KB, which is quite a lot for what is essentially just base elements and grid structure. If you’re actually going to start using Bootstrap in a template, then you’ll need to customize it. By customize, we mean that you’ll need to override styles since it is not possible to modify everything using on LESS variables, which justs adds even more lines to the final CSS code. Then, if you want to be fully compatible with Joomla! you should load the Bootstrap library from the media/jui directory, which means that you will use the full-fat Bootstrap styles even when you don’t need most of them. To add insult to injury, they are loaded on every single page reload, and you’re not even using them!
Bootstrap isn’t just CSS, it’s JavaScript too, which adds an** extra 29KB to the overall weight**. All in all, you’re looking at a bare minimum of 160 KB to create a template using the default Joomla! Bootstrap library. Now add in your custom styles and override rules, and your CSS may be too heavy to lift, as it were.> Conflicts
Incompatibility between Bootstrap v.2.3.2 and v.3 is not the only conflict that can cause issues. When a template provider is logical and tries to keep their code clean by avoiding the loading of unnecessary CSS, the only viable solution with Bootstrap is to include their own Bootstrap build with the template. However, this in itself can also cause its own problems. First of all, third-party extension developers don’t often check whether Bootstrap is already loaded, which that there code will load the library from the JUI too, resulting in Bootstrap being loaded twice which creates a huge amount of CSS conflicts.
This kind of confusion is prevalent; since Bootstrap isn’t a requirement of Joomla, responsible developers that wish to use it must second-guess every other template or extension developer; “Will they use Bootstrap too?”, “Can I trust them to include it?”, “If not, can I trust them to check it’s not loaded before loading it?”. It becomes a guessing game.
Since Joomla doesn’t force Bootstrap (and they shouldn’t), then the potential for these issues arising increases. But would forcing Bootstrap help at all? **A CMS needs to be flexible, and users should be able to choose from the many frameworks available to find one that works for them; taking away that choice limits Joomla and its users. **
> For the life of me, I do not understand why anyone sane would want to force Bootstrap into a CMS without the option to easily disable it. I agree with those who say Joomla should have simply had a small, tightly defined core of CSS definitions. Those core definitions would be the ones needed for the CORE extensions (i.e., com_content, modules, etc. ), both front and back, as well as for templates to hook into should developers choose to. The CSS would be unique to Joomla, giving Joomla developers true control over the system.
Bootstrap could be packed in the core as an OPTIONAL plugin that could be enabled should a developer choose to. Other CSS/frontend frameworks could similarly be added as per the needs of each project. That way, third-party packages like Bootstrap could truly be optional - meaning that disabling them does not destroy core functionality. If a third-party framework gets updated, then no problem - because it is not core. It becomes a matter of (in)convenience, rather than a monumental problem.
