Love it!

Goes that inline with custom elements?

Why do we need a Joomla! CSS Framework? By adding this faux abstraction layer, you honestly make it harder to work with our templating layer.

I appreciate the effort you have put into this but I just dont get it at all. We should be getting off the island not creating new ones

Admittedly my experience is strictly frontend and what I am proposing here is a frontend solution to as I see it a frontend problem. It is very possible I am missing something deeper in which case I will admit to this been a fool's errand.

To answer why.... my logic is that Joomlas output will have to be styled in some manner, that is one island we can't get off. To date we use a small portion of a rather large framework (BS) which effectively forces a frontend developers hand to use that same framework for everything else. Currently lesson 101 of any wannabe Joomla template developer is to build your template using a 4 year old version of Bootstrap. That will change in 4 to the latest version of BS however it is only a matter of time before history will repeat itself. This PR proposes that Joomla will take care of it's end and you (the frontend dev) is free to do what you want on yours. Remember Bootstrap has only a 15% usage across the net, using Bootstrap in Joomlas core pretty much enforces a 100% usage for template developers (yes I realise there is ways around this but none of them easy).

I guess this approach does also not solve the upgrade issue. When we want to make at some point a none bc break in this UI library, we will face the same challenge as when we use bootstrap, so on that end there is not much gain I guess.

If it were impossible to override the output I might buy in a bit more. But aside from a couple of plugins, what markup is in core right now that cannot be overridden either through layout overrides or registering custom callbacks for JHtml utilities?

Yes it is trickier to deal with the JavaScript side of things than it is with styling pages. But that requires a different approach than this.

@laoneo I understand your point if we are dealing with more complicated UI elements like the grid which are currently in constant change due to the benefits gained from new improved systems emerging (display:flex, display:grid etc). However we are dealing with mostly single form elements who's markup are unlikely to ever change. They can still be improved with CSS which will not cause any B/C break.

@mbabker IMO I feel only a few template developers have the resources/knowhow to rewrite the output with overrides simply because they wish to use a different frontend framework or would sooner not use one at all. What I am proposing here does not effect the templating system as I see it. If a developer wishes to override then they are still completely free to do so. The UI kit is only applied to its classes (j-xxxx).

Some talented designers are by their nature not the best developers. By over complicating simple tasks (choice of framework) we may be loosing out to an important pool of designers.

IMO the grid is causing us the biggest headache. So we really need a solution for that as well. When we will have the plan to introduce our own CSS framework, then we need also address the grid issue.

Another question, goes that inline with custom elements?

Based on the core extensions, this may make sense to a degree. But there are mich more complex 3rd party extensions and some of them make use of Bootstrap classes much more than core does.
The great thing about Joomla using Bootstrap is that extension devs can write markup and use JS functions without having to write their own CSS and JS implementations, which makes it easier in the end for frontend templates because those extensions will just fit in and work with most templates.
That was a completely different topic before J3 (if you remember).

If you want to build your own UI Kit, you will need to add the Javascript "widgets" (tooltip, popover, modal, tabs/accordions) as well, otherwise it is useless. We also need the grid in the views, because I know that I use it myself in my extension (both front and backend). It's a very useful feature.

So in the end, you will end up with a prefixed Bootstrap clone.

Together with the fact that you can already override everything and that nobody will maintain it once you stop (eg you leave the project or get children or whatever), I don't see the point in this.

@laoneo I question why we are loading a grid at all. Joomlas core extensions don't really use it. The grid is the concern of the template and not the core extensions. Remember that CSS Grid (display:grid) is now available in all the latest major browsers. Although it is to early to use it, by loading Bootstrap 4 we are effectively tying in to a grid system that will very quickly become obsolete. All frameworks including Bootstrap will be removing the obsolete grid and replacing them with utility classes for the new CSS Grid. You can expect this to happen very soon. Where will Joomla be then?... stuck with a bunch of classes loading an obsolete grid system and template developers having to create overrides to change it. CSS Grid is a great new advancement, it does however pose us a problem regarding Bootstrap 4 and it's potential lifespan as a viable framework.

Yes this would go inline with custom elements. The UI kit will cover the basic form elements. Until shadow dom is supported in custom elements, from a CSS perspective at least, I am not sure how viable custom elements would handle basic, non js elements considering custom elements standalone nature (non modular CSS).

@Bakual Yes a very valid point. Bootstrap been a useful resource to extension developers would be a definite concern. By removing Bootstrap we are effectively passing the problem on to 3PD. Personally I feel this is not such a bad thing. At least 3PD can decide for themselves how to handle it. CSS Grid will very soon resolve the grid issue and tying in to a framework grid (BS 4) will cause a b/c issue for both Joomla and 3PD in the near future. If providing a major frontend framework is something Joomla wants to do then we are always going to be tied to whatever framework we decide. Personally I think it is better for Joomla to provide a non conflicting solution for the basic form elements and let 3PD decide how to best resolve more complicated elements in a manner that won't conflict and avoid b/c breaks.

Dont forget that Joomla and other web apps have to support multiple browsers not just the very latest release

@brianteeman we're supporting IE11 and the last 2 versions of all other modern browsers in J4.

I didnt forget which is why we cant use display:grid http://caniuse.com/#search=display%3Agrid

The joys of fallbacks

@brianteeman I am not suggesting we use display:grid. It is to early. I am concerned we get locked in to a grid system that will be replaced by display:grid in the near future.

Joomla core is not vendor locked though. So I'm not seeing the issue that is being addressed by creating our own mini-CSS framework. If you stop viewing the default layouts (the ones in an extension's directory) as an asset of the extension and consider them an asset of the default template, the fact that they use Bootstrap 4 markup becomes a non issue. And it can all be overridden. Want Semantic UI or Materialize? Drop in the overrides you need, have a nice day.

This is in essence challenging whether we want to go through another major release using a third party CSS framework or go back to the days of 1.0 thru 2.5 where core used its own undocumented standards.

By removing Bootstrap we are effectively passing the problem on to 3PD. Personally I feel this is not such a bad thing. At least 3PD can decide for themselves how to handle it.

I disagree with that. It's actually a very bad thing if you pass that problem back to third parties. And it will become the problem for template devs as well.
Because I can predict what will happen since we had it in the past (j2.5 and earlier): Each extension will include the framework of their choice (Bootstrap, whatever), load it and break your templates left and right. Or at least you get incompatible markup in your template and need to adjust the CSS for each extension. You don't want to go back to that age.

Imho it's fine that extension can use a standardised and well documented and maintained set of classes to create common solutions. That set is called Bootstrap 2.3 in J3 and likely will be Bootstrap 4 in J4. If you don't like that standard set, you can swap it out easily in Joomla. Just override the output or write CSS which match the existing output.

@mbabker I realise I am maybe (probably) looking at this from the wrong angle. All arguments are against the idea and no one is chiming in to support it so gonna close.

Although I would say this PR does not go against Joomlas template layer, it would not promote it.

However naive the idea may be considered, it does resolve template developers having to create a collection of overrides to cover all Joomla views and layouts simply because they don't want to use Bootstrap. But alas this is rightly a responsibility of the template so I guess my point is null and void.

As I see it this PR is still a workaround for #12016

@Bakual In a perfect world I would say extension developers should be agnostic towards the frontend framework and not be pushed to load one. But I see your point, loading Bootstrap means everyone is singing from the same hymn sheet.

So I guess this confirms we are using Bootstrap 4 in the layouts? Either ways it should probably be decided soon.

So I guess this confirms Joomla is using Bootstrap 4 in the layouts? Either ways it should probably be decided soon.

Yes, Joomla 4 will use Bootstrap 4. It is already merged into 4.0 (https://github.com/joomla/joomla-cms/tree/4.0-dev/media/vendor/bootstrap)

Is this inline with #20623? Any argument to re-open?

I am in two minds. Reading through my previous comments most are already resolved by the passage of time.
I do think that some of @Bakual comments are still very valid however the current approach for j4 frontend doesnt answer those issues either. Which is something I am concerned about

OK, looking at this with fresh eyes...

• Don't j- prefix all the things for the sake of prefixing all the things
• Pick a naming convention and stick with it (seems we're going BEM which helps a fair bit, when you start getting into utility things like badges or buttons or whatnot pick something and roll with it, it's not going to map out-of-the-box to every framework out there but conceivably it's "close enough")
• Like I pointed out in #20623 I'd really like to get all the styled stuff (whether it sticks closer to Bootstrap or still keeps its own abstraction from it) into Cassiopeia and make the system template lean solely on our UI kit; that template can be the core demonstration of "how do templates map the UI kit to their preferred framework of choice", and I honestly think we need to be forward looking and realize that we should be able to swap the default frontend template in a minor release without wreaking havoc on all the things like would happen if we did that in 3.x
  • I really do think for this to work the UI kit has to be the foundation of everything in our presentation layer and that "stylistic sugar" like how a framework styles elements like buttons or form fields or select lists needs to be left entirely at the template level and out of the kit
• Custom elements are going to help us a fair bit, but either way we need to take a look at "big" UI components (sliders, tabs, carousels, things like that where you also start getting JavaScript involved) and make sure at the PHP level extensions can consistently initialize said elements while templates can consistently customize them, map to preferred framework, whatever the case may be
• Grid, as long as we have grid related UI options in the backend that it is expected for templates to respect, we do have to figure out how to deal with that; at this point we can probably lean heavily on CSS Grid (maybe the UI kit doesn't even need flex based fallbacks, let any fully themed template sort that out since the template will probably also be dealing with its own grid system)
• Documentation, documentation, documentation

As for extensions being usable out of the box, similar to 3.x and building against Bootstrap 2 standards if our ecosystem does things well enough then an extension built against the UI kit (not the themed default template) should similarly be able to drop into any template and only need minor tweaks.

custom elements are a massive issue for me and not just here. I am convinced about custom elements etc but currently I am not seeing any real interest in more than one person writing any and we have bugs/issues being held up because of "dont fix it this will be a custom element"

It's a pain point in Joomla in general. We have a lot of people who can test stuff. We have a lot of people who can fix PHP stuff. We have a lot of people who can maintain existing UI stuff (CSS/JS). We don't have a lot of consistently active people who can architect in any of our major languages, and those who can are already overburdened.

There is a few things here to consider and admittedly it will probably take me a few days to wrap my head around it again to cover all points.

On the prefixing everything with j-. The original intent here was a simple UI kit that worked in conjunction with other frameworks. The prefixing was to ensure they did not conflict and remained uneffected with said frameworks. I guess the question is if this is what we want. If yes then I am not sure simply using BEM without a prefix will work. As I see it, even with BEM a button class will still be btn or button or whatever (maybe you think differently). I prefixed Bootstrap simply because it was the obvious choice considering Joomla's UI elements are already that way inclined. And the obvious benefit of existing documentation that can be easily tailored to suit.

I don't think we need to worry heavily about trying to prefix things to deconflict with frameworks or make it so that you can use the UI kit alongside any framework out there. Unprefixed, something is going to be used out there in some way we aren't expecting, and a "plug and play" UI kit that just works everywhere is either not going to work well at all or visually conflict so terribly people won't want to use it.

Bootstrap and Materialize use btn classes, Semantic and Foundation use button. I think trying to explicit prefix all the things just makes everyone's lives more complex because they're either class mapping more things to their framework or making more overrides just to remove 2 characters from a class name (or just overriding everything and ignoring the core UI kit, there are enough templates and extensions out there these days where you have to put in extra effort to get them to play nicely).

True. Prefixing is never a guarantee that this will always play nice with other frameworks.

So in summary we are looking for CSS to reset the basic elements and offer some minimal styling. No consideration for mainstream frameworks within the views with the presumption that if a framework (Bootstrap, UIKit etc) is to be used, the views will be overridden. An example of this will be showcased with the frontend template which will continue to use Bootstrap.

That's the way I see it personally. Our absolute minimums and defaults should just be the scaffolding needed to build beautiful sites. The UI kit should be THE building blocks for extensions so we don't go through this painful "move from whatever Bluestork was built with to Protostar with Boostrap 2 to Cassiopeia with Bootstrap 4 to whatever J5 ships" UI migration again. Let the templates be self contained and B/C within themselves, let us introduce new templates if it's really called for (even if it's a totally different framework), and let us do it without breaking down the entire ecosystem because you have to replace something annoying like badge badge-danger with label label-error.

Just some input from an extension developer point of view. It would be good if we can build our extensions against some Joomla standards. Therefor I do think it would be not bad to have some prefix in place to clearly mark that these are Joomla classes where there is preferably some sass file for it available. The template developer can integrate and override these then into its template for minimum styling. Like that we (ext devs) actually know against what we can code our classes and build the markup. Together with BEM it is the right direction to finally stop the frontend battlefield.

Full stack CSS frameworks don't prefix their stuff for the most part (notable exception being Semantic UI). I don't see why we need to prefix our's. What does it really matter if the button styling is based on Bootstrap btn, Foundation button, or Joomla j-button? As an extension developer, if I want a button I'll use whatever button class we decide (preferably without prefix because the prefixes don't add massive value IMO) and let whomever decide if said button class is good enough for their framework or if they need to override to change it.

Realistically a template will have to have an override for an extension for it to be displayed using the templates choice of framework. The problem is when no override exists in the template, which will be the likely case for most 3PD extensions.

Realistically a template will have to have an override for an extension for it to be displayed using the templates choice of framework.

I'm possibly wrong here. @laoneo you would have more experience in this?

I don't want to let this pr turn into a pro/con battle if prefixes do make sense or not. Can we agree here that we trust @ciar4n's expertise whatever he decides on the prefix topic.

Anyway, so there is an agreement that we can go with a minimalistic Joomla UI FW. What would be the next step now? Bring this pr into a none conflicting state and then get another round of feedback?

I would prefer to read your answer to the specific question you were asked.

The problem is when no override exists in the template, which will be the likely case for most 3PD extensions.

That's my biggest fear as well, speaking as a 3rd party extension developer. Templates do provide overrides for some of the top extensions, but certainly not for the ones I write.
I have a feeling that wriiting my extensions against a Joomla UI Kit may become useless if Casiopeia uses a different framework (eg BS4). The framework our template uses becomes de-facto standard anyway.

Personally I'd rather write my extensions so they work with Casiopeia (and all templates using that framework) without overrides than writing against a UI Kit which isn't used by the core template.

So if we adopt an own UI Kit, imho it has to be used by Casiopeia without any Overrides. Then it may work. Otherwise likely not.

I second here the statement of @Bakual. It is very likely that templates will not ship smaller 3rd party overrides. So we need to give the extension devs clear guidance what they should ship out of the box.

Then that defeats the point of this PR or #20623 which is to find a way to have a default UI decoupled from third party CSS frameworks that does not force the entire ecosystem to rewrite their layouts every time we change the default frontend template. I'm taking a hard stance these days because I do think we're overcomplicating things. Either use Bootstrap and just say our UI is built on Bootstrap and if you want to use anything else then deal with the pain that comes with it, or have our presentation layer be our own consistent thing that it is expected templates implement that doesn't drastically change because Bootstrap changed badge to label.

The current state IMO makes things way too complex. You've got contributors trying to do UI things and using Bootstrap because we have it in core and you've got people screaming "STOP USING BOOTSTRAP" because they aim for core having a Bootstrap abstraction layer.

What level of pain are we willing to accept? I finally caved a bit on having our own UI tooling for the sake of not having major presentation layer B/C breaks every release (essentially letting extension developers have a minimalistic yet common and consistent markup and styling standard and leaving the heavy lifting for full styling integrations at the template layer as it should be) but really if we're going to turn around and say "just use this framework as the standard" then we should stop creating abstraction layers for abstraction layers and just use the damn framework as is and just tell extension developers to get used to writing layouts for every template we produce (which luckily has only been 5 totally new templates in the last 10 years).

Realistically what elements pose a problem? My understanding is that most extension UI elements will be routed through Joomla and the template overrides (buttons, button groups etc). So the problem lies solely with layout CSS (grid etc.) and utility classes (#20771).

I never understood the "LET'S KILL BOOTSTRAP WITH FIRE" mentality thought. But that's me speaking from a extensions developer view.
I get that template developers have a different view and they like to abstract things so they can use their own framework of choice.

We need a way that solves both groups. Extensions devs needing a way to write an extension that works in more than one templates and template devs being able to use their own framework using overrides or class mapping.

I don't have the solution, but from a practical view I'm quite sure whatever we use in Casiopeia, will become the standard no matter what you write in the documentation. Because that template is where the extensions are tested/developed with.

Utilities because of inconsistent naming and modifiers (btn-success versus button green), and JavaScript related components (tabs, sliders, etc.).

Layout CSS (Grid) is definitely something I hadn't thought too much about, to be honest even when I was producing general use extensions it wasn't something I took into consideration because I wasn't building something like the com_content category view where its layouts had this type of capabilities.

What would be the next step now? Bring this pr into a none conflicting state and then get another round of feedback?

Considering a lot has changed since this PR was created (SASS compiling, relocation of views etc.) and also the change of approach been considered with a move to template overrides. I think best to create a new PR. A new PR will firstly create all the overrides from the current component views and then decouple the core views from Bootstrap.

@wilsonge

1. Do we move Bootstrap from the media/vendor folder to the template?

2. Do we keep current non Bootstrap classes in either/both the core views or/and the overrides? @brianteeman You previously voiced legit concerns on removing them (#20147 (comment)). Personally I am still of the opinion of a clean break and removing them as this will be the best opportunity to do so.

Keep it in vendor otherwise we end up duplicating Bootstrap resources in both templates. Not to mention as long as we have JHtmlBootstrap it should work with stuff in the media directory and not having it there means something will stop working.

I'll explain here what I said on Skype.

CSS frameworks are a great thing. They save you hours of work. Back in the day when LESS and SCSS weren't a thing, you'd have to hack the CSS to make changes.

LESS and SCSS came out and once the big CSS frameworks started utilising them and performance started becoming a bigger factor in the www, we could pick and choose which packages we wanted to use (badge, cards, list, etc...).

The only problem with this, is that those CSS framework still have 1 .scss file for each component. For example, the button styling is all in 1 SCSS file, meaning you are loading potentially unecessary CSS for different sizes, colours, and so on.

So in the end, you may very well have a slimmed down version of BS, utilising only the components you need, but you'll still have bloat, as the SCSS needs deeper nesting when it comes to segregation.

That said, I'll never slate CSS frameworks cause at the end of the day, they're not bad. They provide a great framework for devs to work with and save loads of time. The only down side is the bloat, which of course impacts performance. This does not make then s**t though. It simply means there's room for improvement, like any software.

Creating you own UiKit sounds all good and well, but:

1. Documentation - which I have a hunch may not even get done
2. Maintenance - this includes no only the CSS but the docs too. Look at Joomla 3's LESS situation and all the crap poeple add in there just to fix something. There's no structure at all and the same will no doubt happen for JUIKit.
3. What does this actually solve? - I already said before that BS is the most popular CSS framework, so it's likely that there will be more users who'd want BS on their Joomla 4 site. As @mbabker continuously says to people, you can decouple BS completely if you want to. Joomla does not prevent you from doing that.

If someone doesn't want to use BS, they have lots of work to do. If someone doesn't want to use the JUIkit, they also have lots if work to do.

So, seeing as BS was used in J3 and still is the most popular CSS framework out there, I'd strongly suggest creating an issue on their issue tracker and suggesting they start decoupling the component theme styling from the SCSS files.

I don't think it is an argument anymore about the merits/faults of Bootstrap. It is about moving the dependency from core to the template, so that we don't have this conversation every time a new Bootstrap version comes out.

For me Bootstraps main advantage to Joomla is that it gave a common standard between the template developer and the extension developer. IF we remove Bootstrap, we need to fill that gap with something. This was my reasoning for the j- prefix.

@C-Lodder I think you're missing the point here! It's not about not using bootstrap (which by the way for some true fronenders this will be a very welcome feature) but making Joomla more resilient to breaks due to bootstrap changes!

We all know that J3 stack to BS2 because BS3 introduced b/c breaks. I think it wouldn't be too hard for anyone to predict that this will happen again.
A reminder here that the great BS4 framework shipped in 2018, when over 80% of the browsers supported CSS Grid Layout and CSS Custom Properties, without utilising any of them!!!
Also not to mention that in the world on js modules, ES6 and web components, they've actually shipped jquery code (check Blaze and their neat custom elements for their components).

@dgrammatiko we know you dont like bs you dont need to keep repeating that and its offensive and insensitive to say that anyone who uses bs is not a "true frontender"

Please stick to the topic.

@brianteeman so from all the valid points I wrote you deliberately mentioned the only thing that was subjective but you didn't mention any of the actual objective parts:

A reminder here that the great BS4 framework shipped in 2018, when over 80% of the browsers supported CSS Grid Layout and CSS Custom Properties, without utilising any of them!!!
Also not to mention that in the world of js modules, ES6 and web components, they've actually shipped jquery code (check Blaze and their neat custom elements for their components).

over 80% of the browsers

That means every fifth browser doesn't. Which is actually a huge amount. Given that this statistics was at the time of the release and not the time of the decision (which may have been months or year before) I completely understand their choice. You can't really blame them.
A framework like Bootstrap doesn't have to use the latest and greates things. There are valid arguments for sticking to 100% supported features if you can achieve what you want with them.

A framework like Bootstrap doesn't have to use the latest and greatest things

@Bakual cascading means that if something is not recognised/can't be computed is ignored. So there is no such thing as browser coverage in the sense that if it's not covered you'll get a blank page (eg new arrow syntax of php 7 used in php5.6, or ES6 code throwing in IE because it cannot parse the new syntax). Still you need to write fallbacks but css is very forgiving...

That said I don't really support the idea that a popular framework DOESN'T actually support the new PLATFORM features. It's about the standards that we're talking about here not some stupid code I or some other random dev wrote.

But the point here is that even if you take as granted that BS4 is what it is the prediction of a short lifespan is not very hard to do, right?
And this is my point: how will J4 cope with that in 1/2 yrs when BS5 will be out with some hard B/C breaks?
Use the platform is the best bet joomla can make right now, the more it relies on opinionated 3rd PD code the more problems devs will face later on...

That said I don't really support the idea that a popular framework DOESN'T actually support the new PLATFORM features. It's about the standards that we're talking about here not some stupid code I or some other random dev wrote.

The same reason Joomla doesn't drop everything every time a new feature is introduced in the platform it depends on (PHP). Longer term stability, lack of majorly disruptive changes. Would you really use a CSS/JS framework if it was making majorly disruptive B/C breaks every 3-6 months?

I've pushed this on a little further. Simplified SCSS for easier maintenance. I've also removed all color variants. I can easily add some if deemed required. For now I have left the prefix (j-). Whatever we decide with the prefix, it is easier to remove it than have to add it back in. I have also updated all the com_content views with the exception of the frontend editing.

Before I continue, considering the amount of work involved, it would be nice to get some confirmation that this is moving in the right direction? @wilsonge?

Secondly, in their simplest form, what is the minimum amount of elements needed for the views? So far there is..

• Buttons
• Button Groups
• Tables
• Description Lists (dl)
• Pagination
• Forms (need refactoring)
• Input Groups (need refactoring)

Considering the extended UI elements required with frontend editing, it seems to make more sense that the backend UI would be loaded rather than the frontend. I have no idea what this would entail.

Presuming this PR reaches a point where all views are updated and tested etc, we then can add the overrides in the template from the 4.0-dev branch. This will return the template to Bootstrap and accomplish #20623 ?