KTabs links functionality

[johncowen]

hi there 👋

I saw that functionality was added to KTabs to be able to use links for the KTab buttons.

I noticed a couple of issues with this functionality, I think both issues are noticeable here:

https://kongponents.konghq.com/components/tabs.html#tabs-as-links

• When keyboard tabbing through tabs, if I hit enter the text in the docs changes (i.e. #tab-link-1, #tab-link-2 but the URL of the page doesn't.
• When "modifier key clicking" i.e. cmd-click I expect the page for the link to open in a new tab.

lmk if you need more info 👍

[adamdehaven]

• When keyboard tabbing through tabs, if I hit enter the text in the docs changes (i.e. #tab-link-1, #tab-link-2 but the URL of the page doesn't.

Updating the hash of the URL is subjective based on the implementation in the host app, meaning that I wouldn't expect the Kongponent to update the URL's hash as it may not be desired. If a host app wants to store the hash in the URL, that should be accomplished by hooking into the change event and updating the URL hash accordingly in the host application.

• When "modifier key clicking" i.e. cmd-click I expect the page for the link to open in a new tab.

For this, I believe some logic could be added. In digging in here, I also noticed the @click event is actually being bound twice to the element, but in reality, should only bind either the @click or @click.prevent event depending on whether it's rending an anchor tag or not.

@portikM I think the handleTabChange event needs to be only bound to a single @click event, and then in the handler, you can optionally call event.preventDefault() depending on the proper logic, rather than binding 2 click events to the element.

[johncowen]

Thanks @adamdehaven !

Updating the hash of the URL is subjective based on the implementation in the host app, meaning that I wouldn't expect the Kongponent to update the URL's hash as it may not be desired. If a host app wants to store the hash in the URL, that should be accomplished by hooking into the change event and updating the URL hash accordingly in the host application.

Just to make sure I understand and I've explained myself properly. Note: I'm wondering specifically about using KTabs with it's anchor support, not using KTabs with it's button support.

Are you saying that even when using KTabs with anchor links (not buttons), by default I should still manage the URLs via my own javascript events as opposed to using the native anchor functionality?

If I don't want the URL to change when clicking a tab wouldn't it be a better choice to use buttons for the KTabs?

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#onclick_events

Anchor elements are often abused as fake buttons by setting their href to # or javascript:void(0) to prevent the page from refreshing, then listening for their click events.

These bogus href values cause unexpected behavior when copying/dragging links, opening links in a new tab/window, bookmarking, or when JavaScript is loading, errors, or is disabled. They also convey incorrect semantics to assistive technologies, like screen readers.

Use a <button> instead. In general, you should only use a hyperlink for navigation to a real URL.

Note the bolding/emphasis is added in the linked article, its not my own addition. What's your take on the above MDN link?

Aside from whether the anchors should change the URL or not, shouldn't they do so consistently? i.e. If I click on a tab and it changes the URL, then I would have assumed tabbing to and hitting enter on the same tab should also follow the same behaviour? Do you follow what I'm saying?

For this, I believe some logic could be added. In digging in here, I also noticed the @click event is actually being bound twice to the element, but in reality, should only bind either the @click or @click.prevent event depending on whether it's rending an anchor tag or not.

I was wondering how possible it would be to remove the javascript events entirely when anchors are being used, and just depend on the native anchor functionality to update the URL. Then leave it to the consuming application to set the selected tab depending on what's in the URL.

If the consuming application does not want to update the URL they could just use the existing "KTabs with buttons" functionality, but I would believe a very large percentage of folks probably want the "KTabs with anchors to change the URL" functionality. @portikM would be good to hear your insights here also.