Founding Principles

[wilsonge]

These are the agreed principles that this repository was founded on and agreed on. All commits should be made baring these principles in mind

• Bootstrap 4
• New user guiding system
• If possible remove parameters (thus making views simpler to override)
• Investigate making dashboard more customisable
• Colour theme research
• Accessibility Improvements
• Investigate any workflow optimisations (clearly documented + explained)
• Minimum IE Requirements? IE 11 minimum - to be reviewed closer to the time. (How to do frontend IE 8 support to be documented)

[dgrammatiko]

Minimum IE Requirements? IE 11 minimum - to be reviewed closer to the time. (How to do frontend IE 8 support to be documented)

If we go down this path there are a lot of scripts that could/should be rewritten as vanilla scripts. The bottle neck will be bootstrap.js that still depends on freaking jQuery...

[jeckodevelopment]

If we go down this path there are a lot of scripts that could/should be rewritten as vanilla scripts. The bottle neck will be bootstrap.js that still depends on freaking jQuery...

It could be useful to detect which (and how many) scripts should be rewritten.

[wilsonge]

No we are only doing things as necessary. We need to make IE8 support in frontend templates relatively easy to achieve. Of course the default template won't support IE8. But we want to ensure as much as possible that frontend templates can relatively easily use an IE8 compatible framework.

We aren't going to rewrite in vanilla JS for the sake of it.

[mbabker]

So is Joomla committing to IE8 support for 4.0? If it is, then there isn't much to do here beyond ensuring all markup can be overridden and keeping the JavaScript libraries as is. If it is not committing to core support of IE8, then I'd suggest that those who wish to refactor the JavaScript should be able to do so (maybe not as a requirement to release 4.0 but during the 4.x lifetime similar to how existing scripts have been rewritten during 3.x from MooTools to either jQuery or vanilla JS).

[dgrammatiko]

We need to make IE8 support in frontend templates relatively easy to achieve.

We already have polyfills for IE8, so front/back end could be IE8 compatible, very easily (just add the polyfill for the JS, and make sure the cascading of the css has some code that IE8 could render). Although I am not suggesting to go vanilla js all the way, it would be beneficial for the project to start moving into that direction, BS5 will drop Jquery and probably won't take 2-3 years...

[wilsonge]

We are not committing to making default templates IE8 compatible. But we are committed to making it a simple documented process to make a 3rd party template IE8 compatible

[mbabker]

So are we committing to Joomla! providing IE8 support in 4.0? You're saying that third party templates need to be able to go down to this IE version so that would imply that the core APIs need to support it, regardless of what the default templates are supporting.

This needs to be made very clear because it will affect all matters related to UI development.

[wilsonge]

No. As I said I wanted a documented simple process. That does not mean all the API's have to support IE8. What I am saying is let's not break IE8 compatible javascript because we can but take it on a case by case basis and documenting it clearly when we break IE8 compatibility.

I'm also not committing to it throughout the lifetime of Joomla 4.x but whilst many governments (UK included) say IE8 must be supported we have to make things relatively easy. If this stops being the case in 2 years then we'll drop this target. It is only a target and not an official documented feature.

[mbabker]

So from a core perspective all we need to care about is that everything that needs to be can be overridden (JHtml helpers, media assets, and layouts are all already covered; what's missing?).

The way I look at it either we are going to retain IE8 support by keeping the existing APIs structured as is or officially we aren't going to be concerned with it since everything we ship can be overridden so if we break support for it then oh well.

I get there are still scenarios where its use is mandated, but what I want to make clear from the beginning is if the project is going to retain support for it or if the project's "support" is going to be in the ability for someone to make it work (meaning through overrides). If it's the former, then honestly our defaults need to match that; if it's the latter, let people make logical changes as desired.

I don't think we can lean on a "we're going to make the best effort to support it" statement. Either we are officially or we aren't and folks need to get comfortable with the override system.

[wilsonge]

We're not officially supporting it. Internally as developers when reviewing pull requests we will give extra emphasis to things that break IE8 compatibility as part of the merge/reject process. Of course in some cases we will break IE8 compat in some of the API's and require people override those assets. That's fine. But I want emphasis on that being in as little places as possible and heavily documented where we do.

[dgrammatiko]

@wilsonge there won't be any break even if you replace scripts with ones that are not IE8 compatible

Let me explain, let's take media/jui/js/jquery.autocomplete.js as an example We could replace it with https://github.com/Pixabay/JavaScript-autoComplete This is vanilla script providing all the stuff our current script supports

Will it work with IE8? Out of the box NO, but with a line before including this script that will load the IE8 polyfill this will be totally compatible with IE8

On the other hand what @mbabker is saying is more important, if the html is gonna be html5 or html4

[wilsonge]

HTML5

[wilsonge]

There's no question about the core templates. They are using BS4 - that's fundamentally not IE8 compatible. What we want to TRY to avoid is ending up in a point where you have to override ALL media assets to get IE8 support

[mbabker]

Sorry for prodding but it is a major decision that needs to be clearly explained so people understand the methodology going forward, not to mention it does affect the manner in which people will approach their work (if you're aiming for IE8 support you're going to do things differently than if IE11 is your low point). To me it's as important to decide and make clear as other minimum support requirements for the overall application, that's why I'm being so pushy on the matter.

[wilsonge]

From picking 3rd party libraries IE11 (as they are easily overridden). Officially to users overall IE11. Internally when we are writing our internal javascript API's (i.e. not the javascript files in the templates directory) we are aiming to keep ie8 support where possible. If we decide to break it for good reasons that's absolutely fine. But it needs to be documented how to override it back...

[dgrammatiko]

@wilsonge @mbabker how about provide a IE8 compatible template, where we will showcase how things should be done (as an official project, not delivered with core)?

[wilsonge]

If I thought that was possible given the time limit I'd say yes. I don't think you will manage that alongside backend, frontend, installation, reworking the dashboard and onboarding system as well as any other UX improvements in 6 months....

[dgrammatiko]

@wilsonge how about a dummy component that will showcase all the fields, bootstrap relative code etc? shouldn't be more than a few days work...

[wilsonge]

The fields overrides and bootstrap code I don't think is a problem. As Michael says the biggest issue with "IE8 Compatibility is in Joomla's Javascript API's" (largely the code we have in core.js) and how IE8 compatible that is....

[ghost]

This is already documented in BS4, maybe this helps? http://v4-alpha.getbootstrap.com/getting-started/browsers-devices/#supporting-internet-explorer-8

[brianteeman]

So a founding principle is

We aren't going to rewrite in vanilla JS for the sake of it.

Interesting