[4.0] A Joomla UI Kit #15225
[4.0] A Joomla UI Kit #15225
Conversation
Gruntfile.js
Outdated
| @@ -34,6 +34,7 @@ module.exports = function(grunt) { | |||
| codemirror : 'media/vendor/codemirror', | |||
| adminTemplate : 'administrator/templates/atum', | |||
| siteTemplate : 'templates/aurora', | |||
| jui : 'media/jui', | |||
|
Love it! |
|
Goes that inline with custom elements? |
|
|
||
| // Colors | ||
|
|
||
| $white: #fff !default; |
There was a problem hiding this comment.
Can we align ALL the variables please. Same as Atum
media/jui/scss/juikit/juikit.scss
Outdated
| @import "buttons"; | ||
|
|
||
| // Components | ||
| @import "button-group"; |
There was a problem hiding this comment.
Separating is fine, but can you alpha order them so it's easier to find
| // Clearfix Utities | ||
| // | ||
|
|
||
| .clearfix { |
There was a problem hiding this comment.
Has this not been prefixed with j- on purpose?
|
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 much more complex 3rd party extensions and some of them make use of Bootstrap classes much more than core does. 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/polyfills |
|
@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. |
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. 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 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) |
| @@ -14,7 +14,7 @@ | |||
| $blockPosition = $displayData['params']->get('info_block_position', 0); | |||
|
|
|||
| ?> | |||
| <dl class="article-info text-muted"> | |||
| <dl class="article-info text-mutedj-dl"> | |||
There was a problem hiding this comment.
All the other jui classes are pre-fixed "j-" butt this one is different - is there a reason?
There was a problem hiding this comment.
Thank you.
Thought I would bring this PR up to a non conflicting state. However considering we have no client side linter, hound will probably churn out these errors, 10 at a time for the next 20 commits. Not sure it is worth it.
|
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 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:
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 |
|
@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. |
|
@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: |
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. |
@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? |
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? |
| .j-clearfix { | ||
| &::after { | ||
| display: block; | ||
| content: ""; |
There was a problem hiding this comment.
Properties should be ordered display, clear, content
| } | ||
| @include hover { @content } | ||
| } | ||
| @else { |
There was a problem hiding this comment.
@else should be placed on same line as previous curly brace
|
|
||
|
|
||
| // Description Lists | ||
| $dl-margin-x: 0; |
|
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..
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 🤞 |
I realise this idea is not a new idea however here is my take on it...
Joomla views are currently tightly bound to Bootstrap. As heavily discussed in the past this presents a number of difficult issues. If you examine the views however its use for the framework is minimal. This PR creates a UI kit tailored specifically for the Joomla views. The intent here is to create a UI kit small enough that it can be loaded along side any frontend framework. This decouples the Joomla views from the frontend template giving total freedom to template developers regarding if and what frontend framework they wish to use (Bootstrap, UIKit, Pure CSS, Semantic UI, Foundation… the list goes on).
How big is it
Not very (currently 18kB)…
Pros
Joomla views not bound to a specific mainstream frontend framework.
The Joomla views will function alongside any frontend framework or indeed no framework at all.
Minimal B/C break for Joomla 4
Older templates based on Bootstrap 2.3 or 3 can still load the older framework with no ill effect to the views.
Minimal Size
As we are only loading what is needed, the Joomla UI kit is relatively small (currently less than 18kB compared to the 150kB of the standard Bootstrap CSS). Basic sites can freely disable unused components/elements of their frontend framework without any ill effect to the views.
Less CSS Overrides
Somes instances exists where Bootstrap needs to be overridden in the template to suit Joomlas output. A UI kit would avoid this as it would be specific for Joomla.
Less future B/C breaks
Frontend frameworks change. At least with a Joomla UI kit we can control how it changes. Once a markup and class naming is decided I can’t imagine much reason for them to change considering the elements involved. If they do then we can coincide these changes with major releases.
Cons
Maintenance
Personally I don’t think this is a big issue as the vast majority of the kit is made up of basic form elements which will require little or no maintenance.
Edit all views
Has to be done anyways for Joomla 4
Extra resource to load
True however in the worst case scenario with a full frontend framework (current scenario) and the Joomla UI Kit, the extra size is minimal (currently 18kB). As already stated, the option will be open to freely disable parts of a user’s frontend framework. The UI kit is an extra resource however overall will more likely reduce the CSS loaded.
No grid
Not really an issue as the default views have little use for it. I have included a basic column framework as a replacement.
Documentation
The UI kit will have to be heavily documented. I am happy enough doing this myself.
What is included (currently)
-- Utility Classes
-- Flex
-- Spacing (minimal)
-- Clearfix
-- Floats
-- Sizing (minimal)
What is missing
Some elements that are currently used in the views have been left out. The intent would be to simplify some views as they are rewritten. Missing elements can be created where there is a need for them (tabs, accordions, alerts, tooltips, elements designed specifically for Joomla requirements). I’d estimate that if all was added you could expect to add another 10-15kB (CSS) to the kit along with some JS. However my hope would be to reconsider/simplify some views and avoid having multiple UI elements where one could be re-used.
For elements that have some more ‘fancy’ functionality, custom elements could be used, as those are specifically created to satisfy such needs..
Class Naming / Markup
Currently the UI Kit is largely a stripped down version of Bootstrap so the markup in generally is the same. All class names are prefixed with ‘j-’ to avoid conflicts with other frameworks.
Eg.
Considerations
The size of the kit could be reduced further with some style changes. Quite a chunk of the CSS of the current kit involves manipulating form element borders.
A slightly softer approach to this PR would be create overrides within the frontend template for the forms (article edit) rather than applying to ../layouts/joomla/form (??)
There is still a dependency on Font Awesome (previously Icomoon).
It might be wise to add some reset/normalize CSS ('[class^=j-], [class*=' j-']'). Currently not included.
Testing
For demonstration I have amended some of the views to use the UI kit classes..
com_content -> article
com_content -> category list
com_content -> category blog
com_users -> registration
com_users -> login
mod_login
mod_menu
Documentation Changes Required
Yep