Hello

In the last days I reworked the posting form. I have changed a few things significantly. I would therefore like to present and discuss some of the changes before they are incorporated into the project.

First things first. This is the status of the current stable version. The screenshots was taken here, in the project forum.

The posting form of version 20240827.1 in a desktop browser. I was logged in.

- The labels for category, subject and tags are displayed beside their input fields, the label for message text is displayed above the textarea. This behaviour is inconsistent.
- The textarea for the posting text is styled floating on the left and the button bar is displayed on the right with a left margin, larger than the width of the textarea.
- If one resizes the textarea (with the handle at the bottom right), the button bar stays at its position (when narrowing the textarea) or jumps to below the textarea (when making the textarea wider).
- The thread-pinning selection is built as a list but the list is displayed only with the browsers own styling.

The posting form of version 20240827.1 in the mobile view of a desktop browser. I was logged in.

- The labels for category is displayed beside its input field, the labels for subject, tags and message text are displayed above the textarea. This behaviour is inconsistent in another way than in the desktop view.
- The text input fields are wider than the viewport because of the values of their size-attributes.
- The textarea for the posting text is styled like in the desktop view. This results in the need to scroll horizontally to use the buttons.
- The thread-pinning selection is the thread-pinning selection.

Now to the changes I made. The screenshots was taken in a testing forum. I will call the version 20240913.0 in this posting/thread but this is no real version. The checkbox for attaching the signature is missing because in the testing forum my account has no signature.

The posting form of version 20240913.0 in a desktop browser. I was logged in.

- The form #postingform got a maximal width of 60em like i.e. paragraphs and lists in the main element #content.
- The labels are all displayed above the input fields.
- The instructions, that are displayed without activated JavaScript and that are the source to build the button-bars with JavaScript, are now displayed above the message-label, got a heading, a skip link and the lists was slightly restructured. This made it necessary to also apply changes to the JS-file posting.js. This has to be reviewed and to be applied also to the minimised version of the code.
- The button bar moved to a position directly above the textarea and the buttons are now horizontally ordered. There is no need for a floating construct anymore, which was implemented because of no existing alternatives.
- The buttons have no fixed width and have been slightly enlarged so that they have a larger click area. This makes them easier to use. The rules for the styling of the buttons are now applied to the parent element of both button bars (BB-code, smilies) and are valid for all of the buttons at once.
- The block for the additional buttons was a collection of links until now and rebuilt as a list of buttons. This made it necessary to also apply changes to the JS-file posting.js. This has to be reviewed and to be applied also to the minimised version of the code.
- If one resizes the textarea (with the handle at the bottom right), the button bar stays at its position with no jumping at all.
- The thread-pinning selection is now displayed with own styling rules.

The posting form of version 20240913.0 in the mobile view of a desktop browser. I was logged in.

- The labels are all displayed above the input fields.
- The input fields are width-restricted with max-width and are fitting in the narrow mobile viewport. On wider viewports they are enlarged according to the value of their size-attributes.
- The textarea for the posting text and the button bar is also styled with a max-width to fit into the viewport width.
- The thread-pinning selection is the thread-pinning selection.

We have to review the changes before merging it to the base branch and to release it. Any opinions, pro or cons?

Tschö, Auge

Feedback from more the visual side: way much better. I like the button approach on the top, it's more common and works in more "situations" regarding screen/browser/window width. And it also looks much cleaner and easier to modify.

( Tiny question: One thing, that would be interesting, if it is possible to jump from the different fields to the next one with the tab key, but without going through all of the buttons then (I like to use the mouse as less as possible and jump from field to field, also most of the time with deactivated js)? But it's not a big/important thing too.)

In general: I like it! =)

Feedback from more the visual side: way much better. I like the button approach on the top, it's more common and works in more "situations" regarding screen/browser/window width. And it also looks much cleaner and easier to modify.

Thank you.

( Tiny question: One thing, that would be interesting, if it is possible to jump from the different fields to the next one with the tab key, but without going through all of the buttons then (I like to use the mouse as less as possible and jump from field to field, also most of the time with deactivated js)? But it's not a big/important thing too.)

There are several input fields with a value for the tab order. But, after looking into it in the testing forum, the order is very unordered. The buttonbars in itself are not part of the taborder. This needs also a rework.

At the moment I don't know, how to include the buttons into the taborder, because the buttons are optional. Without JavaScript, the buttons does not exist. With disabled BB-code-features all or specific buttons does not exist.

Tschö, Auge

Hello,

At the moment I don't know, how to include the buttons into the taborder, because the buttons are optional. Without JavaScript, the buttons does not exist. With disabled BB-code-features all or specific buttons does not exist.

In posting.js#L538, the tabIndex attribute is defined (always -1). Most of the attributes of a button are defined by the variable obj such as obj.code. I think it is quite easy add a further attribute to obj, e.g. in posting.js#L433 and posting.js#L484. We just have to figure out a reliable starting value.

/Micha

Hello

At the moment I don't know, how to include the buttons into the taborder, because the buttons are optional. Without JavaScript, the buttons does not exist. With disabled BB-code-features all or specific buttons does not exist.

In posting.js#L538, the tabIndex attribute is defined (always -1). Most of the attributes of a button are defined by the variable obj such as obj.code. I think it is quite easy add a further attribute to obj, e.g. in posting.js#L433 and posting.js#L484. We just have to figure out a reliable starting value.

I read a bit about tabindex and have found statements that say that numbering is a bad idea (for example the first reply in this Stack Overflow thread) because of its bad maintainability. One has to recheck the order with every structure change. And I encountered exactly this (the result of missing order checks) in the posting form. The order of focusable elements (links, input fields, textarea(s) and buttons) is completely mixed up.

You start tabbing in the page head, jump through the search form to the subnavigation item (in case of a reply "back to entry of Someone") and the next jump (for a logged in user) goes to the "Attach signature" checkbox and not (what I expected) to the input field for the subject. From there it goes to "E-mail notification ..." and from there to the "To top" link in the page footer. After the jumps through the footer links one lands in the browser tab bar. From there it goes through the elements of the browser UI over the browsers bookmark bar (if activated) to the input field for the subject and the textarea for the message itself ommiting the tags input (if available). From the textarea it jumps to the submit and preview buttons and then back to the main page link in the page header. That's terrible, to say the least.

Reading the MDN page for tabindex, it seems to be clear, what happens.

Two quotes from there:

Some focusable HTML elements have a default tabindex value of 0 set under the hood by the user agent.

A positive value means the element should be focusable in sequential keyboard navigation, with its order defined by the value of the number. That is, tabindex="4" is focused before tabindex="5" and tabindex="0", but after tabindex="3".

Emphasis by me

This means, that a browser follows the natural order as long as it finds no tabindex, given with a positive number, follows then the given order of positive values in ascending order when it focussed the first one and then jumps back to the elements with implicit (no tabindex attribute) or explicit set tabindex value of 0 afterwards. It possibly follows another group of tabindex with positive values if it finds another group.

My conclusion: With exclusively no tabindex (implicit value 0 for focusable elements) in links and forms the browser would simply tab through the elements in order of appearance. Elements, that shoudn't be focusable with tabbing (for whatever reason) should get a tabindex with a negative value (we use the common -1 for this). Keeping the tabbing system with positive values, an order with gaps between the values (1, 2, 3, 4, 5, 10, 11, 12, 20, 21, 28 and so on) shouldn't be a problem. But!: The order must be plausible for the users. The current state is it absolutely not.

The simpler and more maintainable system is IMHO to not set a tabindex order (with exception of a negative value for elements, that shouldn't be focusable when tabbing).

I didn't find a method to make a button group behave like a radio button group (tabbing to the group with [TAB] and stepping through the group with [Space]) (that was the initial question of Emanuel).

Tschö, Auge