We need to remove the module width parameter in the backend module manager as well I guess with this?

If moving layout options to the template then yes, this field would be removed. Currently this PR makes it redundant.

We need to remove the module width parameter in the backend as well I guess with this?

wouldnt that mean that all templates are forced to use css grid?

wouldnt that mean that all templates are forced to use css grid?

I mean with the current system all templates are forced to use a 12 column grid which is no good for UIKit. You would need to use a plugin to override the form field like with any other XML form.

wouldnt that mean that all templates are forced to use css grid?

NO. Also removing the dropdown doesn't necessarily means that we loose the ability to control the width! We still have the class input where someone can declare (by typing it of course) the column width. What is suggested to be removed is the coupling with bootstrap!

But it would mean that every template needs to support these new classes? Or what do we do with bootstrap classes like here?

No. All the components (at least with this PR) will still use bootstrap grid. They are a bit harder to transition because of all the parameters for moving around content etc. It's definitely something to consider moving components to use Grid. But we can just do it at template level to give more flexibility on mobile devices (see the portrait vs landscape example here https://www.w3.org/TR/css-grid-1/#source-independence) to reorder components vs modules around (also with accessibility advantages because in the html source code we can move components towards the top of the page with screen reader advantages) and none of this affects component markup

@laoneo If we are to consider moving views to CSS grid, IMO such classes would be removed and replaced with a style declaration. The idea of using classes to create a layout was always a hack due to CSS's inability to handle layouts. Thankfully that has now changed.

So a template and extensions do need to use BS4 and CSS grid then? Guess now I'm confused at all.

Why even ship BS4 then if we're not going to use it at all in core?
Imho we either use BS4 or we don't. But shipping it but not using it makes no sense at all. Neither in frontend and even less in backend.

The big selling point of Bootstrap is that extensions can write layouts which work and fit nicely into the template (as long as it is a BS4 template). If you don't load the BS4 CSS, then you toss that out. However if you still load BS4, then I don't see the point here, just use BS4 classes then.

@laoneo You can still use your BS4 grid inside the template CSS grid if you wish

@Bakual

Why even ship BS4 then if we're not going to use it at all in core?

We are still using BS4 for all the UI elements

I don't see the point here, just use BS4 classes then

Why use BS4 for the grid when there is a far more versatile solution available as platform? Just because we are loading BS4 doesn't mean we have to use it in areas that it is inferior (the grid).

So a template and extensions do need to use BS4 and CSS grid then? Guess now I'm confused at all.
Extensions can make the choice. There are advantages of both. CSS Grid allows more flexibility of layouts on different screen sizes and orientations (important to the phablet market). However it makes PHP parameters harder (although not impossible) to implement. So it depends what you value more. At the template settings level the user always has the ability to recompile SASS client side and save the file to the server. No real problems, hit the button and done.

Problem is of course a user editing an article in many cases may not have the ability to compile SASS client side (which is effectively required as the PHP compiler like the LESS compiler is massively dated) and save that file to the server. In that case you end up with some potentially yucky but viable option of defining the grid (i.e. only this part: https://github.com/ciar4n/joomla-cms/blob/6a8314a0d2f9a3c013080a0fbb181f751e7b4c0f/templates/aurora/scss/blocks/_layout.scss#L81-L89) in inline styles. I see that as far more controversial and up for debate.

Conclusion: Therefore I really like the flexibility that CSS Grid gives to the template at almost no cost. However it's clear there are potential pain points for component level use of CSS Grid at the component view level hence why we're splitting it into separate PR's and we may not go for full component integration (I'm honestly undecided).

We are still using BS4 for all the UI elements

Which there are plans to move to custom elements...

As for IE11 support: Remember that IE11 is still the default browser for Windows 10. So this browser needs to be supported well, not as a stepchild.

Problem is of course a user editing an article...

Why an editor is also responsible for the design? Do we, by default, assume that the editor is also the designer?

UI elements === buttons, headings paragraphs, fields etc
UI Components === elements that also have javascript: tabs, alerts, dropdown, accordion, modal

At the moment I just can't see the offert and consequences for template and extension developers. We also need to keep in mind that the Joomla default template is basically the template we extension developers are working against.
We just need to have a proper plan for the eco system, that's all I need to have clarification for. About the implementation details, I trust you guys.

You don't need to compile SCSS to use grid. Having the grid markup inline in the document's head is about 512 bytes. Compared to what we load -and how much inline stuff we have anyway- that's nothing. As for those who need to compile SCSS know how to do it; just give them the option to not produce inline styling.

Specifying width etc in module options: that's legacy and we don't have to support it forever. Kill it with fire. It doesn't even belong in the module options, it's only specific to a single CSS framework version and 3PD templates don't care to support it for the most part.

Idea for the future: visual (JS-based) designer for the grid in the template options. Pretty much what was decided in October 2015 in Athens at the joint UX and Joomla! 4 sprint (the "bento box" idea). Maybe hire JS developers, a specialty in VERY short supply in the project, to do it.

Is this what we're talking about going to ? https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout/Basic_Concepts_of_Grid_Layout

@N6REJ yes

Chrome looks fine.
IE11 and Edge look fine when wide enough. Once you make them smaller, IE11 becomes really ugly:

Edge is better, but doesn't behave the same as Chrome. Eg top-a and top-b modules don't disappear when shrunk like they do in Chrome.

So if we want to go this route, it certainly needs better IE11 support.

The modules automatically use the full width of the container and autoscale their width if there are multiple modules in the same position. This may be fine in some cases but in others not so much.
Since you remove the "Bootstrap Size" parameter from the modulechrome, there is no easy way anymore to set up modules of different width for a position. Or to have a module only span part of the place.
Obviously, the parameter was named stupid, but other than it's name, it was a very nice parameter (if supported by the template).

How would you do that now? Using classes? Are there some that will work to adjust the width of a single module? Eg make one using 50% of the space and two use 25% each?

Once you make them smaller, IE11 becomes really ugly:

Thank you. Fixed with the latest commit. Not CSS grid related. The issue with the menu toggle is present outside of this PR so I will also create a separate PR for that.

Eg top-a and top-b modules don't disappear when shrunk like they do in Chrome.

IE11, Expect a difference - IE11 will continue to display as it does currently however as CSS grid features are implemented we need to expect some layout differences between IE11 and grid supporting browsers. As long as IE11 remains usable I can’t see this as a problem. An example of this can been seen with this PR if you resize the browser. Excluding IE11, on smaller screens the component area is moved above the top module positions.

Thanks for the fix, the modules don't look ugly anymore. The menu is indeed also present without this PR. However it's still not as good as Chrome. There seems to be another media query missing. See left IE11 and right Chrome:

As long as IE11 remains usable I can’t see this as a problem.

I certainly have an issue with that. IE11 is the default browser on Windows 10. And we're going to threat it as a stepchild with limited support. Keep in mind that it works perfectly fine using BS4.

What's the big gain here we get by using CSS grid beside using the most current technology? Imho CSS grids are awesome, but as long as not supported by IE11 and Edge not ready to be used yet in a default template of our CMS.
It's fine when you want to use it in your template of course, and there should be nothing stopping you from doing it.

Wow! This is a great pull request! Leaving Bootstrap to use CSS Grid is a very good idea!
Although it's partially supported by IE11 and Edge, it's natively available for the rest. https://caniuse.com/#search=grid Except for Opera Mini, but that one is always a bit strange :-)

Decouple HTML from layout forces us to create our own CSS. And thus brings a lot of possibilities to create smaller HTML spaghetti.

An example of sites already using CSS Grid listed by Rachel Andrew -> https://cssgrid.design

@Bakual You are wrong. The default browser in Windows 10 is Microsoft Edge. IE11 is only provided as a fallback. You need to explicitly run it and it doesn't ask you to become the default browser. You'd have to know where to go to make it the default browser. However that doesn't make it the default browser.

Please keep in mind that you're talking about the Joomla! version to be supported for the better part of the 2020s (let's be realists). If you think it's too early to implement Grid do note that the New York Times has gone Grid without a fallback.

As for IE11, an end of life browser, I would personally not mind having it present a legacy experience when modern features are used. At least it's not as broken as IE6 was when Joomla! 2.5 was released or IE7 when Joomla! 3 was released :D

@Bakual

still not as good as Chrome. There seems to be another media query missing. See left IE11 and right Chrome:

To achieve the same effect without CSS grid requires multiple media queries. I am not sure they are really needed considering it is an edge case? IE11 on that screen size is unlikely.

As long as IE11 remains usable I can’t see this as a problem.
I certainly have an issue with that. IE11 is the default browser on Windows 10. And we're going to threat it as a stepchild with limited support. Keep in mind that it works perfectly fine using BS4.

IE11 should still display as it did with Bootstrap. As I see it this adds to CSS grid supporting browsers (already the majority) rather than taking away from IE11.

Edge is improving Grid support of course:
https://twitter.com/MSEdgeDev/status/877661344375296001

@nikosdion You're right, I was wrong. Edge is the default one. IE11 isn't EOL however, it will be supported for as long as Windows 10 is supported, which is quite some time (mainstream support until 2020). At that time we're talking about J5.

If you think it's too early to implement Grid do note that the New York Times has gone Grid without a fallback.

That may be the case, but www.nytimes.com doesn't look responsive to me, neither in Chrome nor IE11. So they look both exactly the same. (maybe it's because our Firewall blocks a shitload of stuff from them).

To achieve the same effect without CSS grid requires multiple media queries. I am not sure they are really needed considering it is an edge case? IE11 on that screen size is unlikely.

My point is: It is working fine currently with BS4. If we move to CSS grid, we either have to threat IE11 as stepchild with limited featuresupport or we have to rewrite all the media queries for it. But if we do write those, we could as well remove the CSS grid again because that code which works for IE11 will also work for all other browsers, plus we end up more or less with the code BS4 is using.

IE11 should still display as it did with Bootstrap. As I see it this adds to CSS grid supporting browsers (already the majority) rather than taking away from IE11.

As I wrote, for IE11 BS4 works way better than CSS grid. But then I don't see what advantage the user has if our template uses CSS grid instead of BS4. It looks exactly the same to me. Ecept that the "Bootstrap Size" parameter (which is named badly) has no effect anymore. As an admin, I actually loose flexibility with the current proposal.
What is the main gain we get here beside using the latest tools?

Ecept that the "Bootstrap Size" parameter (which is named badly) has no effect anymore. As an admin, I actually loose flexibility with the current proposal.

No, you don't, read my comment #16810 (comment)
The only thing that you loose is the tight coupling to Bootstrap! Which is a step forward

No, you don't, read my comment #16810 (comment)

I tried with puttin col-6 into the class suffix, but that only made the module half the width of a regular module:

The only thing that you loose is the tight coupling to Bootstrap! Which is a step forward

Actually, it's just a number which could be used for anything. Name it "size" and name the options 1/12, 1/4, 1/2 , ... and you don't have any BS coupling anymore.

@Bakual I attended JoomlaDay Norway where the Microsoft representative very clearly stated that development on IE has stopped, only security issues are fixed and the objective is to kill it in favor of Edge.

Why should we use Grid?

Easy for developers. You don't have to be a designer or carefully count columns and add special non-content markup to lay out a responsive template. This means that developers can create more compelling interfaces for users with less effort. As we all know users like shiny stuff.

Support is there. By the time Joomla! 4 will be released (realistically: not before the end of the year) ALL modern browsers will support Grid perfectly. Yes, legacy browsers don't support Grid. It's because, um, they are LEGACY, i.e. old and no longer updated.

Polyfills do exist and we have the technology to inject them where needed, e.g. https://github.com/FremyCompany/css-grid-polyfill and we can use JBrowser to detect IE9-11 and inject the polyfill to provide better degradation.

You don't HAVE to use a polyfill. On legacy browsers show basic layout. Before saying anything else open the dictionary on the word "legacy". That's why.

Including a specific 3PD CSS framework in the core is a Massively Bad Idea(tm) as we have proven with the inclusion of BS2 in Joomla! 3. Unless you have decided to move to a yearly major version update cycle for Joomla! with 6 months or less LTS in which case, sure, including BS4 is possible (but that release plan will increase platform fragmentation and hurt adoption).

Grid does not require a metric crap-tonne of CSS and JS to work since it's part of the web platform itself. This means that you can shave off 80% of your page load time on slower connections (3G or slower), making Joomla! competitive to WordPress. Not convinced? Install a default J 3.7 and WP 4.8 site and use Chrome's dev tools to simulate GPRS. If you think it's too extreme: more people use GPRS than IE 11. See: Africa, Asia. Also see: the keynotes from JaB17.

Grid doesn't require JS. No JS means that the site will work every single time. Try seeing how responsive a BS2/3/4 site is if you disable JS. Not so much, right? More so when you want to change column orders on smaller screen sizes.

The content is laid out semantically with Grid. The source code order is how it makes sense to read the content (semantic), not how it makes sense to render it in a browser. The left sidebar doesn't (and shouldn't!) come before the main content any more.

WordPress is already moving there which carries the very real risk of leaving us eating their dust. You know why this is important? Because Grid is so damn easy that a half-trained chimpanzee can use it to make compelling layouts. If Joomla! doesn't support it why would the site integrator churning out site after site choose Joomla! over WordPress when Joomla! requires spending days counting columns and figuring out layout breaks and compiling SCSS when the same work in WP is a matter of filling in a field with the layout grid cell names?

In the end it comes down to "this is the future, it's already here, we just have to bloody use it". Maybe, just maybe, we can produce a compelling, forward looking, modern CMS version for a change. What do you think?

My point is: It is working fine currently with BS4. If we move to CSS grid, we either have to threat IE11 as stepchild with limited featuresupport or we have to rewrite all the media queries for it.

You're looking at it in a way where CSS grid is the default and IE11 support is a half-baked implementation, which isn't really the right way to do it. CSS grid support is progressive enhancement, where if it's available then it's used. The only problem is Microsoft is slower at implementing features generally than the other vendors so it really does seem like IE/Edge get treated as a stepchild but that's not by a deliberate decision. If you turn off the grid stuff in Chrome (or roll back to a version without support for it) Chrome and IE11 should behave essentially the same.

We can't write 4.0 for 2016/2017 standards. If 4.0 has another 8 year lifespan (what 3.x is going to be at by the time it goes end of life), we HAVE to be forward looking where practical. Yes, it's going to mean that some browsers don't have the same level of native feature support and as such behave a bit differently, but that's already the case today anyway just masked behind either JavaScript polyfills or CSS frameworks doing their best to offer CSS only solutions to problems without relying on newer conventions.

i am still confused as to the path we are taking. at the moment it looks like its a combination of bs4 and native stuff like css-grid and vanilla js

is there an overall vision/aim - it would really help

Up until recently, the main UI goals were migrating the core framework from BS2 to BS4 and reducing the dependencies to jQuery. With CSS grid going through development pretty much during the same timeframe we've been working on 4.0, that's causing us to have this discussion now on whether to adopt it and how it in general fits into a CMS environment.

I'd say if we adopt CSS grids and use custom elements for the modals, tooltips and those stuff, then we should drop BS4 completely from core and don't ship it at all.
Imho there is no point anymore having it in core if we don't use its bigger features. We would be left with some UI design things like cards and some other input element formatting.

Of course that means component output has to be rewritten to use CSS grids as well. There is no point imho using CSS grid for the template and BS4 grid things within components.

Imho there is no point anymore having it in core if we don't use its bigger features. We would be left with some UI design things like cards and some other input element formatting.

Bootstrap, or really any of the CSS frameworks, are not just a grid system with a bunch of UI elements. They're a collection of it all. IMO using Bootstrap to provide basic design elements (navbars, buttons, cards, etc.) is perfectly fine. The UI work my company does uses another framework solely for this aspect of designing our UIs, we do not use a grid system from a CSS framework. Essentially what you're proposing is to go back to ye olde days of 1.5 or 2.5 where there was a half-hearted CSS framework implemented in the core templates and everyone just did their own thing. There are still numerous benefits to designing with a common base infrastructure instead of doing the typical Joomla thing of writing all the things ourselves.

I'm not proposing to drop BS4. I love it myself and I think it was still the best decision done for J3 to adopt BS2, no matter the issues it brought.
But imho it doesn't make sense to get rid of most of its features and still include it fully in core (and maybe even advertise with that fact). Including the full BS4 in core just for the UI stylings imho is overkill.

But maybe I don't see the bigger picture here. I leave that for you designers to figure out and will work with whatever is left for extension developers to work with. Just don't forget us and the users when you make your decisions.

@mbabker @Bakual we can import parts of the bootstrap (base elements, navs, tables etc) or go the way @ciaran showcased in the other PR for Atum. My only problem with Bootstrap is that it is really bloated, e.g.: navbar-default & navbar-inverse. We are obliged to deliver some totally useless css just because that's the bootstrap boilerplate!
If we can figure a way to streamline Bootstrap to something that will be the base for future then let's do that, otherwise let's create a base (all the default elements, a, button, h1, p, ul, table, etc) and some state classes (active, success, warning, etc) document it and move forward!

My 2c, anyways

@Bakual from a CSS perspective, this is only replacing the grid for the core frontend template.
Template developers may want to stick with the standard BS4 grid which is an easy update.

as for the JS (custom elements), this is NOT a replacement, but an addition. extension devs may NOT want to use custom elements, but instead stick with the code they're using, like JHtml::_('bootstrap.XXX'); which will work the same in J3 and J4.

Once we've got everything in place, we WONT be including the entire BS4 CSS in core. We'll only import the SCSS files that are required.

@dgt41 you're right, BS offers a load of styled alternatives that we dont use, such as navbar-inverse so I'd suggest each element, such as navbar, card has an additional file, such as navbar-theme.scss etc. But that's something that would need to be brought up on the BS repo, and who knows....they may do it for stable

We are obliged to deliver some totally useless css just because that's the bootstrap boilerplate!

All CSS frameworks suffer from that bloat because they're a set of boilerplate tooling to do a set of tasks consistently. Even the components you do use of the frameworks, you aren't using all of the options most of the time, so you're still getting bloat.

Even if we tried to write the Joomla CSS Framework (based on Bootstrap for the sake of argument since I don't want this to derail into a NIH chat), we're still going to end up with bloat because we are going to have to provide a generic set of elements. Unless we only provide styling for the elements that the core CMS uses and leave any optional styling to extensions, and that's just making things hard for the sake of it. Bootstrap 4 is just fine to base our UI around, while continuing to work toward proper abstraction and decoupling of the core PHP layer from the core UI layer (i.e. custom elements).

Even the components you do use of the frameworks, you aren't using all of the options most of the time, so you're still getting bloat.

Backend (as long as useless files are not loaded) that's not really a problem. Few more MBs are really very cheap.
Front end size matters Every extra byte is hurting the performance. Especially CSS and JS as both are blocking the rendering. So a 150kb css file is not a feature, it's a huge problem!

We are now deep in the mobile era, so size and speed have a huge impact. Defaulting to some bloated CSS or using jQuery as a dev convenience is really hurting the project, as the final product is nowhere near competitive to other products that utilise more modern technics.
Let's agree on the compromises needed and move forward

We do need to move forward, I agree there. I just don't think we can ship only CSS for the elements that are directly used in a default core installation, since as rightfully pointed out every unused CSS rule is bloat and adds load. So to me the compromise is we should still ship a full framework stack, because not every Joomla user has the skills or budget to be able to afford a design team to do things the One Right Way™ so at the low end of the spectrum shipping that bloat helps those users. At the same time though, if we build the core infrastructure the right way, folks like you or me who know how to work with the tooling and what they're using on a site can customize the build and shave off every bloaty byte of data they don't need.

We still need to provide some infrastructure and tooling to the extension ecosystem. That's the other big part of what standardizing on a framework (be it home grown or third party, but please, let's not try to home grow too many things when there are so many viable tools on the market) enables, everyone knows the baseline tools and functionality that's available to them and can adapt from there.

Maybe we could aim for less of a reliance of the framework (bootstrap) within the core components, to the point that everything doesn't completely fall apart if the framework is removed/disabled. I agree that we must account for those that may not have the skills/budget to do things the Right Way™ but I also believe we need to make the Right Way™ as feasible as possible for those that do. This would mean removing some of the framework dependent sugar from the core components (replace dropdowns with static links etc). CSS grid allows us some layout opportunities to make a simpler UI presentable within the frontend of core components.

This is exciting, +1 for grid from me.

I'm going to give this a rollout. I think this has great potential, although we need to be careful if we want to implement this at the component level.

I've asked @ciar4n to have a look at falling back to the -ms-grid as a fallback rather than flexbox, in the hope that might give a more similar result on ie than flexbox. But I think this now works in IE (even if the layout isn't exactly the same)