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

[4.0] Move Aurora to CSS Grid #16810

Merged
merged 7 commits into from Jul 3, 2017

Conversation

Projects
@ciar4n
Member

ciar4n commented Jun 22, 2017

Summary of Changes

CSS grid decouples HTML from layout, allowing layout to be moved exclusively to CSS. This PR moves the Aurora frontend template layout from Bootstrap to CSS grid (https://www.w3.org/TR/css3-grid-layout/).

Testing Instructions

Apply patch and ensure frontend template displays correctly across all browsers.

Compatibility

Includes a flexbox fallback for browsers that do not support the new CSS grid spec, currently this means IE11 and Edge which only supports the older spec. Microsoft are currently working on adding the new spec to Edge. Considering the collapsing nature of Joomla layouts the older CSS grid spec is not really suitable to use as it relies on a predefined number of rows.

Considerations

Move layout controls to template style - CSS grid allows us to easily set the layout in a single location with a few lines of CSS with the grid-template-areas property (https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout/Grid_Template_Areas). This opens up the possibility of creating a ‘layout builder’ of sorts which would be set from within the template style settings. A basic implementation would be just a textarea field however ideally we could improve on this with some kind of GUI. The textarea field would contain something like the following which can then be edited by the user…

head head head head
banner banner banner banner
top-a top-a top-a top-a
top-b top-b top-b top-b
side-l main-t main-t side-r
side-l comp comp side-r
side-l main-b main-b side-r
bot-a bot-a bot-a bot-a
bot-b bot-b bot-b bot-b
footer footer footer footer 

Module Groups - Considering the layout flexibility that CSS grid adds, we may need to reconsider the definition of a ‘Module Position’. ‘Module Groups’ may be more accurate.

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. Polyfills do exist for IE11 however I am not sure if we want to go down that road.

Component views - With a bit of imagination CSS grid opens up layout possibilities for the default core component views. It also partly removes the Bootstrap dependency. Whatever the thoughts on using CSS grid in the views, I believe that they should at least be CSS grid ready. This means removing Bootstrap grid classes. Bootstrap relies on nested divs with a tightly coupled class structure to define a grid which does not mix at all with CSS grid.

Misc.

Nested Elements - CSS grid uses a flat markup (no nesting). As a flexbox fallback is needed for IE11, I had to nest some of the elements (component, sidebar and main positions). Although this does restrict the freedom offered by CSS grid, it’s effect is minimal considering the current Aurora layout.

No media queries - By way of demonstration I used the minmax function instead of media queries for the top and bottom module widths.

Auto module widths - Top and bottom position module widths are calculated automatically depending on the number of modules in a position so as to allow modules to remain in a row with equal widths. Modules will wrap to a second row if widths go below a set px width (180px).

Linting - Currently SCSS-Lint does not fully support CSS grid so was disabled to compile this PR.

ciar4n added some commits Jun 21, 2017

@wilsonge

This comment has been minimized.

Show comment
Hide comment
@wilsonge

wilsonge Jun 22, 2017

Contributor

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

Contributor

wilsonge commented Jun 22, 2017

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

@ciar4n

This comment has been minimized.

Show comment
Hide comment
@ciar4n

ciar4n Jun 22, 2017

Member

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

Member

ciar4n commented Jun 22, 2017

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

@brianteeman

This comment has been minimized.

Show comment
Hide comment
@brianteeman

brianteeman Jun 22, 2017

Contributor

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?

Contributor

brianteeman commented Jun 22, 2017

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?

@wilsonge

This comment has been minimized.

Show comment
Hide comment
@wilsonge

wilsonge Jun 22, 2017

Contributor

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.

Contributor

wilsonge commented Jun 22, 2017

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.

@dgrammatiko

This comment has been minimized.

Show comment
Hide comment
@dgrammatiko

dgrammatiko Jun 22, 2017

Contributor

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!

Contributor

dgrammatiko commented Jun 22, 2017

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!

@laoneo

This comment has been minimized.

Show comment
Hide comment
@laoneo

laoneo Jun 22, 2017

Member

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

Member

laoneo commented Jun 22, 2017

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

@wilsonge

This comment has been minimized.

Show comment
Hide comment
@wilsonge

wilsonge Jun 22, 2017

Contributor

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

Contributor

wilsonge commented Jun 22, 2017

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

@ciar4n

This comment has been minimized.

Show comment
Hide comment
@ciar4n

ciar4n Jun 22, 2017

Member

@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.

Member

ciar4n commented Jun 22, 2017

@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.

@laoneo

This comment has been minimized.

Show comment
Hide comment
@laoneo

laoneo Jun 22, 2017

Member

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

Member

laoneo commented Jun 22, 2017

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

@Bakual

This comment has been minimized.

Show comment
Hide comment
@Bakual

Bakual Jun 22, 2017

Contributor

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.

Contributor

Bakual commented Jun 22, 2017

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.

@ciar4n

This comment has been minimized.

Show comment
Hide comment
@ciar4n

ciar4n Jun 22, 2017

Member

@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).

Member

ciar4n commented Jun 22, 2017

@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).

@wilsonge

This comment has been minimized.

Show comment
Hide comment
@wilsonge

wilsonge Jun 22, 2017

Contributor

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).

Contributor

wilsonge commented Jun 22, 2017

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).

@Bakual

This comment has been minimized.

Show comment
Hide comment
@Bakual

Bakual Jun 22, 2017

Contributor

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.

Contributor

Bakual commented Jun 22, 2017

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.

@dgrammatiko

This comment has been minimized.

Show comment
Hide comment
@dgrammatiko

dgrammatiko Jun 22, 2017

Contributor

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?

Contributor

dgrammatiko commented Jun 22, 2017

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?

@dgrammatiko

This comment has been minimized.

Show comment
Hide comment
@dgrammatiko

dgrammatiko Jun 22, 2017

Contributor

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

Contributor

dgrammatiko commented Jun 22, 2017

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

@laoneo

This comment has been minimized.

Show comment
Hide comment
@laoneo

laoneo Jun 22, 2017

Member

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.

Member

laoneo commented Jun 22, 2017

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.

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion Jun 22, 2017

Contributor

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.

Contributor

nikosdion commented Jun 22, 2017

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.

@N6REJ

This comment has been minimized.

Show comment
Hide comment
@N6REJ
Contributor

N6REJ commented Jun 22, 2017

@dgrammatiko

This comment has been minimized.

Show comment
Hide comment
@dgrammatiko

dgrammatiko Jun 22, 2017

Contributor

@N6REJ yes

Contributor

dgrammatiko commented Jun 22, 2017

@N6REJ yes

Show outdated Hide outdated Gruntfile.js Outdated
@Bakual

This comment has been minimized.

Show comment
Hide comment
@Bakual

Bakual Jun 22, 2017

Contributor

Chrome looks fine.
IE11 and Edge look fine when wide enough. Once you make them smaller, IE11 becomes really ugly:
image
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.

Contributor

Bakual commented Jun 22, 2017

Chrome looks fine.
IE11 and Edge look fine when wide enough. Once you make them smaller, IE11 becomes really ugly:
image
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.

ciar4n added some commits Jun 23, 2017

@Bakual

This comment has been minimized.

Show comment
Hide comment
@Bakual

Bakual Jun 23, 2017

Contributor

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?

Contributor

Bakual commented Jun 23, 2017

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?

@ciar4n

This comment has been minimized.

Show comment
Hide comment
@ciar4n

ciar4n Jun 23, 2017

Member

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.

grid-ie11

Member

ciar4n commented Jun 23, 2017

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.

grid-ie11

@Bakual

This comment has been minimized.

Show comment
Hide comment
@Bakual

Bakual Jun 23, 2017

Contributor

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:
image

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.

Contributor

Bakual commented Jun 23, 2017

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:
image

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.

@hans2103

This comment has been minimized.

Show comment
Hide comment
@hans2103

hans2103 Jun 23, 2017

Contributor

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

Contributor

hans2103 commented Jun 23, 2017

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

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion Jun 23, 2017

Contributor

@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

Contributor

nikosdion commented Jun 23, 2017

@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

@ciar4n

This comment has been minimized.

Show comment
Hide comment
@ciar4n

ciar4n Jun 23, 2017

Member

@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.

Member

ciar4n commented Jun 23, 2017

@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.

@davdebcom

This comment has been minimized.

Show comment
Hide comment
@davdebcom

davdebcom Jun 23, 2017

Contributor

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

Contributor

davdebcom commented Jun 23, 2017

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

@Bakual

This comment has been minimized.

Show comment
Hide comment
@Bakual

Bakual Jun 23, 2017

Contributor

@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?

Contributor

Bakual commented Jun 23, 2017

@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?

@dgrammatiko

This comment has been minimized.

Show comment
Hide comment
@dgrammatiko

dgrammatiko Jun 23, 2017

Contributor

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

Contributor

dgrammatiko commented Jun 23, 2017

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

@Bakual

This comment has been minimized.

Show comment
Hide comment
@Bakual

Bakual Jun 23, 2017

Contributor

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:
image

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.

Contributor

Bakual commented Jun 23, 2017

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:
image

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.

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion Jun 23, 2017

Contributor

@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?

Contributor

nikosdion commented Jun 23, 2017

@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?

@mbabker

This comment has been minimized.

Show comment
Hide comment
@mbabker

mbabker Jun 23, 2017

Member

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.

Member

mbabker commented Jun 23, 2017

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.

@brianteeman

This comment has been minimized.

Show comment
Hide comment
@brianteeman

brianteeman Jun 23, 2017

Contributor

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

Contributor

brianteeman commented Jun 23, 2017

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

@mbabker

This comment has been minimized.

Show comment
Hide comment
@mbabker

mbabker Jun 23, 2017

Member

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.

Member

mbabker commented Jun 23, 2017

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.

@Bakual

This comment has been minimized.

Show comment
Hide comment
@Bakual

Bakual Jun 23, 2017

Contributor

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.

Contributor

Bakual commented Jun 23, 2017

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.

@mbabker

This comment has been minimized.

Show comment
Hide comment
@mbabker

mbabker Jun 23, 2017

Member

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.

Member

mbabker commented Jun 23, 2017

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.

@Bakual

This comment has been minimized.

Show comment
Hide comment
@Bakual

Bakual Jun 23, 2017

Contributor

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.

Contributor

Bakual commented Jun 23, 2017

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.

@dgrammatiko

This comment has been minimized.

Show comment
Hide comment
@dgrammatiko

dgrammatiko Jun 23, 2017

Contributor

@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

Contributor

dgrammatiko commented Jun 23, 2017

@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

@C-Lodder

This comment has been minimized.

Show comment
Hide comment
@C-Lodder

C-Lodder Jun 23, 2017

Member

@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

Member

C-Lodder commented Jun 23, 2017

@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

@mbabker

This comment has been minimized.

Show comment
Hide comment
@mbabker

mbabker Jun 23, 2017

Member

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).

Member

mbabker commented Jun 23, 2017

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).

@dgrammatiko

This comment has been minimized.

Show comment
Hide comment
@dgrammatiko

dgrammatiko Jun 23, 2017

Contributor

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

Contributor

dgrammatiko commented Jun 23, 2017

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

@mbabker

This comment has been minimized.

Show comment
Hide comment
@mbabker

mbabker Jun 23, 2017

Member

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.

Member

mbabker commented Jun 23, 2017

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.

@ciar4n

This comment has been minimized.

Show comment
Hide comment
@ciar4n

ciar4n Jun 23, 2017

Member

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.

Member

ciar4n commented Jun 23, 2017

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.

@uglyeoin

This comment has been minimized.

Show comment
Hide comment
@uglyeoin

uglyeoin Jun 25, 2017

Contributor

This is exciting, +1 for grid from me.

Contributor

uglyeoin commented Jun 25, 2017

This is exciting, +1 for grid from me.

ciar4n added some commits Jun 30, 2017

@wilsonge

This comment has been minimized.

Show comment
Hide comment
@wilsonge

wilsonge Jul 3, 2017

Contributor

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)

Contributor

wilsonge commented Jul 3, 2017

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)

@wilsonge wilsonge merged commit 55fc7ca into joomla:4.0-dev Jul 3, 2017

3 of 4 checks passed

hound Error parsing config for: scss. Click "details" for assistance.
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/drone/pr the build was successful
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@wilsonge wilsonge added this to the Joomla 4.0 milestone Jul 3, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment