You say

Converting old bootstrap apps to use the core UI is as easy as search replace (bootstrap/coreui)

But in administrator/components/com_categories/tmpl/category/edit.php
bootsrap.startTabSet becomes tab.startTabSet

while in administrator/components/com_content/tmpl/article/edit.php
bootsrap.startTabSet becomes coreui.startTabSet

I assume its a mistake ?

@brianteeman oh yes...

I need the docs finished at https://joomla-projects.github.io/custom-elements/#/tab before I can merge this ;)

@wilsonge this is still WIP, the reason I exposed it was to get the UX and accessibility groups involved.
Once we're happy with the features and markup, I ll do the docs and the tests

@dgt41 nice and huge work ?

I have small concern.
Tabs in Joomla 3 has some drawbacks, and I see you copies it here.

Main drawback that the navigation rendered by JavaScript. It make huge problem if you want to attach some event listener or do any other fancy stuff with JavaScript, because you do not know when the navigation available/rendered.

The root of this problem is JHtml::_('startTab/endTab') which is joomla 1.5 legacy, which used <dd><dl> style tabs (eg https://codepen.io/Inu/pen/EPaYWz).

Perhaps can we review/rework it for future?
Example: Render the navigation before the tab content. And JHtml::_('startTab/endTab') use only for a tab content.
But do not render navigation with JavaScript.

Or just drop this creepy JHtml::_('startTab/endTab') it has not much profit,
and it not that hard to add the markup <joomla-tab></joomla-tab> by hand. Really.

For navigational purposes, it's probably easier to just build the markup by hand (at least with Bootstrap). But for tabs on pages, it's not as simple; part of the problem boils down to how some of the CSS frameworks have tabs implemented. Bootstrap 3, Semantic UI, and Materialize all have done tabs in a way where you have two separate containers, one with the tabs themselves and a second container holding all of the contents. So for dynamic tab groups (for us that's mostly form views) it's a lot harder to build that markup by hand because you don't have a fixed number of elements; or if you do try it you end up with a lot of complicated logic to build it in your layout. So the JHtml helpers help deal with some of that logic. Same issue exists with other element types too (Bootstrap 3 Collapse, Semantic UI Accordion and Materialize Collapsible to a lesser extent as examples).

@Fedik at this point the only requirements I wanted to fill were:

• minimal changes from the previous used methods (JHtml::_('bootstrap.startTabSet'...)
• make sure that keyboard navigation and all attributes satisfy WCAG 2.0 level AA
• make the creation process very easy for PHP

@mbabker all Bootstrap 3, Semantic UI, and Materialize fail miserably at their keyboard implementation, it's either totally wrong or not implemented.
Also my approach to divert all the navigation creation in the client will eliminate problems where the dev will find it hard to built this markup in the server side.
As I said before this is WIP and I would be very happy if we solve all these for the benefit of all devs

I'm not even in a spot to comment on accessibility points, I can just point out implementation details that make these kinds of helpers nice to have.

@mbabker are you talking about PHP side or client side helpers?

PHP side.

Just to clarify what's the status here:
awaiting confirmation from a11y and UX teams for the accessibility (usability) of the component

So the work so far is just fulfil these requirements: https://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-1/tabs.html

@armenos @jonrz

well, okay I don't mind if they stay ?
It can stay as is, I just wanted to note the drawback of existing approach.

@dgt41 Please resolve conflict.

@dgt41 This is it! Very good job. Good idea!
I fully support the idea of our own UI component library.
I tested the tabs with the NVDA screen reader. They are impeccable.
Tabs are a problem on mobile devices, e.g. smartphones. Have you seen a solution designed by Deque? Responsive Tabs to Accordion - https://dequeuniversity.com/library/aria/tabpanels-accordions/sf-responsive-tabs-to-accordion.
Consider whether it would be possible to use such a solution.

I tested the tabs with the NVDA screen reader. They are impeccable.

@zwiastunsw I've tried to follow these two:
http://heydonworks.com/practical_aria_examples/#tab-interface
https://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-1/tabs.html

But if https://dequeuniversity.com/library/aria/tabpanels-accordions/sf-responsive-tabs-to-accordion
is a better solution then let's to that

FWIW the markup is the same ;)

It is responsive. One code, two components...
I asked the accessibility team to get acquainted with this solution and your project. At the beginning of next week, we will talk about it.

@zwiastunsw both Armen and Jonathan had a look at this as @ciar4n and me we were trying to get this at a presentable state (this is the code pen we were working on https://codepen.io/dgt41/pen/VzeaNP)

It can stay as is, I just wanted to note the drawback of existing approach.

@Fedik can you give me an example of such a possible case? (use this https://codepen.io/dgt41/pen/VzeaNP with chrome)

@dgt41 My English is not good. I do not know if you understood me well. I'm impressed with your solution. It is very good. But if you see the opportunity to develop it like Deque, it would be perfect.

Works fine for me, both on desktop and mobile.

@zwiastunsw sorry my fault, you are suggesting tabs to become accordions for smaller screens, which should be quite easy to achieve. @ciar4n can we do it this with css?

Exactly!

@dgt41 Not really possible with CSS alone. There is ways but all a bit hacky. Ideally you need to change the markup (order) using JS, After that the CSS would be simple enough.

can you give me an example of such a possible case?

@dgt41 some fake code:

// User code
document.getElementById('tab-panel1').style.color = "red"; // Not work

// ... blabla code for render the tabs

// User code
document.getElementById('tab-panel1').style.color = "red"; // Work

but I just thought,
it not that critical with webcomponents , because they should be loaded before all other scripts,
so all fine ?

@zwiastunsw We have created the following based on your suggestion. Could you have a look for us...

https://codepen.io/littlesnippets/pen/120d66fdb11da43b7dcd76181b00926f/?editors=0100

I just noticed that with this PR we no longer have tab state

The use case for the tab state is as follows
You are on the Publishing tab on an article and press save
Before this PR you remain on the Publishing tab
After this PR you return to the first tab

In addition (i think for the same reason) you can no longer link directly to a tab
eg
administrator/index.php?option=com_content&view=article&layout=edit&id=3#permissions

I watched. It works as I expected. But now we should do testing in Joomla.

@brianteeman yeah it's a know thing. Need to replace the J3 script though

@brianteeman there will be a tabs state included in the script. The lines https://github.com/joomla/joomla-cms/pull/17375/files#diff-76b51a2a4e063276df0b4b390771cfbeR81 to 100 are there for that, I just need to find some reasonable code for that instead of the thing that we have in J3 (which also has a dependency on a polypill)...

I just need to find some reasonable code for that instead of the thing that we have in J3 (which also has a dependency on a polypill)...

That code is actually quite new. If you're going to touch it make sure you have read the PR which introduced it before. So you don't bring back the issues we tried to fix with this code.
The polyfill likely isn't needed anymore in J4.

@Bakual whatever the tab state is doing in 3 is majorly useless in the custom elements implementation simply because now we have absolute control over the tabs (we govern them) it's not some random div with some class and some dat attributes.

Anyways here is a quick implementation of both the URL hash and the session storage! Should be flawless if it's not I messed up! ?

@zwiastunsw this can be tested in the joomla environment as well now.
For those not familiar with git (from the a11y team) please download joomla from here: https://github.com/dgt41/joomla-cms/archive/§4.0-dev-coreUI-tabs.zip

PS new tabs are available in category edit and article edit for the moment

Unfortunately. In Joomla the tabs do not change on a small screen in an accordion.
This is OK.

In Joomla is not OK.

I tested in Windows10 - Chrome (v. 60.0.3112.90) and Firefox (54.0.1).

@zwiastunsw where from your first example? maybe it just "photoshoped" ?

@zwiastunsw the change from tab to accordion works only for non nested tabs. Unfortunately backend uses nested tables...

@dgt41 I understand. And can you implement tabs to test, for example, in the com_contact component in the single contact view on frontend? I could then test the correctness of the action.

@Fedik First example is from: https://codepen.io/littlesnippets/pen/120d66fdb11da43b7dcd76181b00926f/?editors=0100

@dgt41 is there any requirements/limitation why Joomla use "nested" ? (except that Bootstrap use it)
Joomla 1.5 had "non nested" if I right remember.

curious ?

@Fedik well, someone thought it was a good idea to have the permission in tabular form (quite honestly I don't know how this can be presented differently)

the permission in tabular form

I guess "non nested" allow to do the same, it just a styling.

I think that it could be a good solution for a responsive tabs, which can work without extra js code. In theory.

Or, we can combine these two technique.
Render 2 navigation ("nested" and "non nested"), and switch them depend from @media.
So on big screen we show "nested" tabs, and on mobile use "non nested" (accordion).
Idea for future ?

Satus for this:

• tab to accordion and vice versa:
  
  

Needs some work:

• key behaviours are messed up
• activating nested tabs from sessionStorage is broken

Not yet implemented

• allow server side rendering

tested ok on editing an article BUT when testing on a new article

Uncaught DOMException: Failed to execute 'querySelector' on 'Element': '#[@id='myTabTabs']|#images"]' is not a valid selector.
    at HTMLElement.connectedCallback (http://127.0.0.1/cms4/media/system/webcomponents/joomla-tab.min.js?aa0f23253692a0e357b27ac9299bfc3b:1:3803)
    at http://127.0.0.1/cms4/media/system/webcomponents/joomla-tab.min.js?aa0f23253692a0e357b27ac9299bfc3b:1:9239

@brianteeman that selector '#[@id='myTabTabs']|#images"]' doesn't exist in this implementation. The myTabTabs id is a bootstrap thing, probably you need to clear the browser's (local storage) cache (and I have to figure out a way to remove the old crap data from the previous tab state script)

Can this one being closed as the tabs CE in the template repo got merged?

Already merged