Then maybe a PR in the main repo is the wrong place for this then :)

RFC issues and PRs are perfectly valid.

Maybe it's me not understanding custom elements yet or me not don't sharing the "We should not use Bootstrap" mentality, but I don't see the point in this example. Maybe it's also just a bad example.
Imho it makes my life as a developer (both template and extension) only harder, not easier.

We are introducing a new API and also a new markup, so documentation is vital!

Since we are known to be very good at documenting our stuff, that will be the main point where this would either succeed or fail. Being realist it will be the latter.

It looks like we're going to cook our own soup here again instead of using some (very well documented!) "standard". I really don't like the NIH syndrome ?

From what I understand about custom elements, they make a lot of sense when you want to include custom functionality (eg a dropdown list that changes behavior based on content or expands the adds features to it). But for regular markup stuff it doesn't make much sense to me. For that we can use JLayouts just fine.

@Bakual Alerts are not just some random markup, there is a script that comes with it (for the close function, it has a method and 2 events)
Documentation should be easy since there are plenty of tools out there for this, e.g. https://github.com/QingWei-Li/docsify

To make this example more interesting in your browser's console type:

tmp = document.querySelector('bs4-alert');
tmp.close();

OK So I think custom elements are going to take off over the next 5 years so I'm not against this. However caveats:

1. I am slightly nerved by the fact that custom elements are still not a approved w3c standard (and how we deal with any b/c breaks in the meantime)
2. Documentation
3. How templates override this markup. This is by far my biggest issue. I think having bs4 in the element name is bad (i'm assuming this is just for demo purposes) because if you are using uikit and have to replace the element bs4-alert it's going to be very confusing. But also how does that override mechanism work?

Quick answers:

• 1. You shouldn't be, webkit already supports it and next safari will as well: webkit: https://webkit.org/blog/7027/introducing-custom-elements/ safari: https://developer.apple.com/library/prerelease/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_1.html Firefox already supports that in experimental mode:
     and microsoft will come as well: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6261298-custom-elements So if ALL major browsers are ok (mind that they already agreed for the specs, that's the reason of v0 and v1, we'll do v1!) I think we shouldn't really worry for this...
• 2. I'm playing around with different tools so the docs would be something easy and maintainable
• 3. Same way someone overrides css and js files. So template providers can customise the sass files and create a customised version of the elements. The naming probably should be joomla-jui-{element} but this is totally configurable on the build script, so no worries. About the overriding mechanism: is the same as css and js basically we need an JHtml::_('customElements', $path, $options)

I hope this makes some sense

I really like the approach and it will make the life for me as extension developer much easier, as I don't have to care about frontend framework vendor specific markup anymore. It is the best approach I'v seen so far to become frontend framework independent.

I would also recommend not to have have bs4 in the elements names. But sounds like you are going to change that.

What for me is unclear how it would work then for a Foundation based template to load the foundation alert custom element. Would it be then trough JHTML overrides or will it be simpler with some kind of auto detection?

@laoneo the call for an alert (server side/php) will be JHtml::_('customElements', $path, $options) both for bootstrap or foundation or any other css framework. For client side is just like creating a usual element:

var tempElement = document.createElement('bs4-alert');
tempElement.setAttribute('data-type', 'success');
tempElement.setAttribute('data-button', 'true');
tempElement.innerHTML = 'Wow it works!';

document.body.appendChild(tempElement);

Try to do the same (especially client side) with bootstrap...

So when I want to provide my own fundation custom elements, then I need to reigster my own customElements script in JHtml?

Maybe it's me not understanding custom elements yet or me not don't sharing the "We should not use Bootstrap" mentality, but I don't see the point in this example. Maybe it's also just a bad example.
Imho it makes my life as a developer (both template and extension) only harder, not easier.

1. Better performance (something we all look for)
2. Decouple from Bootstrap (something people have been moaning about for years)

This doesn't in any way remove support for Bootstrap alerts....you, template devs and extension devs are quite within you right to continue using BS/jQuery if you want to.

At the end of the day, this means that Joomla supports a web component that isn't couple to BS4....which IS a big factor for extension and template devs. Once template devs realise that we're utilising web components, they can support them, and thus alerts will then work on ANY frontend framework being used.

We all have our own extensions, we all know how bloody annoying it is whgen trying to cater for other frameworks. As it stands, on one of my own modules, I've had to resort to adding a backend parameter to select the framework you wish to use (BS2, BS3, UIKit).

Ignore the fact that this PR is loading something from a CDN....Dimitris he stated it's purely for demonstration purposes

Oh and what do you know? Even Google have re-built G-Earth with Web Components: https://earth.google.com/web

For those not convinced yet about custom elements, let me point you to youtube.com. Check the source code, yup, that's right, extensive usage of custom elements:

This is how you do UI in the modern times...

I will redo this one later on..