Definitely for making this a custom element, how I dont not agree with the logo/heart transition. It does not signify a loading state at all. My preference would be a CS version of the current GIF we use

There are some additional things to consider here for accessibility

WCAG 2.1 introduces Success Criterion 2.2.9 Animation from Interactions (level AAA), it should be possible to disable the animation. Safari and ios have options that a user can set for this and we can support this with a media query for example.

When I checked with external accessibility experts last week they said the current css throbber was ok but I strongly suspect this heart version will not be

@brianteeman can be patched to meet those requirements

@C-Lodder I don't actually agree, I mean the page is semi transparent and there is a beating thing for me this is a sign that something is happening/loading

I prefer the spinner/throbber as there is more change happening more frequently than with this one especially if it is only on screen for a short time.

as for the accessibility issue the fix would stop it being anything other than a static logo

I prefer the spinner/throbber

I'm not a css magician so ask someone with basic svg animation knowledge to create a codepen with this and then I can change it. Or encode base64 the gif and use that again (not really a 2018 approach)

I'm mocking up some stuff on Codepen as we speak

For reference the media query is something like

+@media screen and (prefers-reduced-motion: reduce) {
+  .progress__bar {
+    -webkit-animation: none;
+    -moz-animation: none;
+    /**
+     * Some browses do to recognise transition: none, so using
+     * transition-duration instead.
+     */
+    -webkit-transition: none;
+    -o-transition: all 0 none;
+    transition: none;
+  }

https://codepen.io/dgt41/pen/eVEaWZ

Right, here's an updated loading icon based on what Dimitris did:

https://codepen.io/anon/pen/XZawzp

• Converted to SCSS
• Correct colours
• Improve animation
• Adjust spacing between elements

@dgt41 - I assume the CSS is being appended as it was quicker for testing purposes and will be moved after?

@C-Lodder read the description, RFC part -> another issue. We're doing it wrong!

@brianteeman Seeing as J4 isn't supporting AAA, is this media query even needed?

While it might not officially support it there is no harm in doing things right ;)
Drupal isnt supporting AAA but they did it - i helped test it (thats how I even knew about it)

Eg submit button or submit form is not required unless you already have a form, the spinner is used only in 2-3 pages abut we still load all this things in every page load. This needs to be more efficient, the jQuery days (eg one library has it all) has gone.

Splitting the thing has also a drawback: you need to keep in the head what the file you need to connect on every page. ?

Eg submit button or submit form is not required unless you already have a form,

In the backend we have a form on every page, that why submit form in the core.js, and it not a heavy code.

Think about the core.js as an entry point to Joomla! front-end API, not as about jQuery ?
I think, submit form, JText, scriptOptions, Events, request, extend, renderMessages, and WebComponents should stay in the core.js (if I did not missed something), all else, can be moved somewhere (if people want it).

all else, can be moved somewhere

That was the idea, make another helper and since somehow we're gonna get ES6 code in the repo this can also then combined back to core.js for the old timers...

And this is officially the first true web component in joomla! (All 3 technologies used: Custom Elements, Templates, Shadow DOM)

Also almost 1/3 of the old image size:

Of course it's working on all browsers, even if they're not supporting Shadow DOM

Can you make Hound happy please

Guess you need to clean up the pr as there are permissions and mail test files touched here.

@laoneo this PR actually does 2 things:

• replaces the spinner with the web component version
• restores encapsulation for all the custom elements/web components, by reverting #17911

The only reason that these 2 are combined is that the actual build script was needed to change to allow the css encapsulation and as a side effect all the custom elements with css were affected. I don't know if it would make any sense to try to separate those tasks, there are pretty much correlated...

for reference BS have now added support for disabling the animation in some places.

@brianteeman FYI this spinner also supports disabling animations if UA advertises it (it works in safari, I've checked it ? )

Ok, than it is a different story. I'm more the friend of isolated pr's and doing one thing in one pr. But if you say this is connected then we leave it.

Closing here please test: #21129