User tests: Successful: Unsuccessful:
Pull Request for Issue # .
This PR replaces the bootstrap alert with a custom element joomla-alert
and introduces a way to handle web components in Joomla.
Web components is a new W3C standard that enables easier, faster, encapsulated UI components (like alerts, dropdown, tabs, accordions, modals, etc)
At the moment we are deliberately using ONLY custom elements, but switching to web components is already supported and can be done very easily, if or when is needed!
Web Components consists of several separate technologies. You can think of Web Components as reusable user interface widgets that are created using open Web technology. They are part of the browser, and so they do not need external libraries like jQuery or Dojo. An existing Web Component can be used without writing code, simply by adding an import statement to an HTML page.
Ref: https://developer.mozilla.org/en-US/docs/Web/Web_Components
Let's say you're using an html5 video tag with some basic syntax:
<video width="320" height="240" controls>
<source src="movie.mp4" type="video/mp4">
</video>
This snippet will actually render a video player with buttons for play/pause a progress bar and a full screen toggle. But you didn't insert or defined any of those, the browser automatically did that for you once it parsed the video tag. The technology that browsers are using to create this video player out of a video tag IS web components.
In our case the joomla-alert
element that is being introduced with this PR uses a very simple syntax:
<joomla-alert level="info" dismiss="true">
Alert message!
</joomla-alert>
and will create automatically the close button html markup (with all the required javascript code for the interaction).
So web components will:
An introduction to what we are trying to achieve here explained by the Joomla 4 release leader George Wilson video
https://www.w3.org/standards/techs/components#w3c_all
Apply patch and try to login without inserting username and password
Try to save an article without title
Right now there are still few browsers that do not support web components, but that is not a problem because the implementation will check (client side) if there is a need for a polyfill and load them automatically (async) and them load any of the required (by the user) components (again asynchronously). This code is tested against all the supported Joomla 4 browsers:
Documentation:
https://joomla-projects.github.io/custom-elements/
Status | New | ⇒ | Pending |
Category | ⇒ | JavaScript Repository Modules Administration Templates (admin) Layout Libraries |
Labels |
Added:
?
|
Title |
|
Title |
|
Category | JavaScript Repository Modules Administration Templates (admin) Layout Libraries | ⇒ | JavaScript Repository Administration Templates (admin) Layout Libraries Front End Templates (site) |
Is it a good idea to add a feature to J! that won't be used by most people?
More reading with a compatibility chart.
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/
Is it a good idea to add a feature to J! that won't be used by most people?
That's not the case. Web components work in Firefox (we are using polyfills for all the browsers that are not supporting them yet)
I can only go by what I read and that is that the support for web components is NOT active by default in FF and apparently limited in all other browsers.
Not trying to argue, just trying to make sure we "dot our I's and cross our T's"
@N6REJ the while point of moving to web component is to decouple Joomla from Bootstrap as much as possible. This will allow template providers to integrate their own frameworks much more easily and also improve performance.
Same as we've done for the frontend template amd using css-grid.
There should not be any doubt about this. It's an up and coming enhancement and we're implementing it.
what I read and that is that the support for web components is NOT active by default in FF and apparently limited in all other browsers
Hence the use of polyfills to make functionality available in browsers where it is not natively. Same concept already applies to various PHP APIs we use.
Also, there are polyfills in place so it WILL work in FF.
Category | JavaScript Repository Administration Templates (admin) Layout Libraries Front End Templates (site) | ⇒ | JavaScript Repository Administration Templates (admin) Layout Libraries |
@brianteeman honestly, no, I wasn't trying to speak from authority, I was speaking from concern. I read what I could briefly find, and that raised the question.
I don't doubt you or @mbabker or @wilsonge or the many others, i was just concerned if that makes sense.
I think this is the way to go and will be normal in the future to have web components on web sites. The only concern I have right now, is that template developers (who are using a CSS framework) do need to take care also about the styling of the custom element. Means they have to style two alert boxes, the one from the CSS framework and the custom element one.
What would be nice is when it would be easy for template devs to override the custom elements html files. Some kind of web components overriding. For example the system should automatically load the file /templates/{template}/webcomponents/joomla-alert.js if it exists instead of the system one. Like that the template clubs can already ship their own implementation of the Joomla custom elements.
What would be nice is when it would be easy for template devs to override the custom elements html files. Some kind of web components overriding.
@laoneo that's already implemented, placing the html file or the js+css in the respected folders of the template (e.g. themplate/webcomponents/joomla-alert.html will override the core: media/system/webcomponents/joomla-alert.html), check the static::includeRelativeFiles
in the webcomponent method.
So for a template creator/integrator, etc there will be a need to use our tools (joomla-projects/custom-elements) and adapt the scss files to their template, then recompile the web components and place them in their templates related folder.
If the question that arise is that this is complicated, the answer is: no it's not try some other modern projects and you'll immediately find that there is no customisation without using some command line tools! That's the state of web programming at the moment and joomla have to adjust (the idea that the rest of the web will adjust to our outdated workflows is probably out of question)
@zero-24 there is documentation: https://joomla-projects.github.io/custom-elements/
True, missed that. That was my only concern. Now the template clubs can ship their templates with their own custom elements overrides. Like that it is the right approach to introduce web components. Thanks, nice work!
@zero-24 there is documentation: https://joomla-projects.github.io/custom-elements/
Yes but this should just be the note that this is going to be moved to docs.joomla.org ;) Else I bet this is going to be lost.
@zero-24 there are 2 parts for the documentation:
The last one needs to be also hosted in docs.joomla.org. The first one can happily live in GitHub (actually the documentation also have some live examples and Im not so sure we can do that with mediaWiki). So a link for each component will be enough in doc.joomla.org.
Sounds like a good plan
Milestone |
Added: |
Milestone |
Added: |
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-07-22 20:20:13 |
Closed_By | ⇒ | dgt41 |
Status | Closed | ⇒ | Pending |
Closed_Date | 2017-07-22 20:20:13 | ⇒ | |
Closed_By | dgt41 | ⇒ |
Category | JavaScript Repository Administration Templates (admin) Layout Libraries | ⇒ | JavaScript Repository Administration Templates (admin) Unit Tests Layout Libraries |
Labels |
Added:
?
|
Category | JavaScript Repository Administration Templates (admin) Layout Libraries Unit Tests | ⇒ | JavaScript Repository Administration Templates (admin) Unit Tests Layout Libraries Front End Templates (site) |
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-07-28 11:51:46 |
Closed_By | ⇒ | wilsonge |
Woop woop!!
Nice?