Too big when there is just one line.
Too small when there are two lines, example: Template:Deactivate Misc Proxy Settings - Whonix
Also, if fixable, the [select code] text should never cover other text if there is a lot text input.
Note: these have to look ok with and without javascript enabled.
This has a lot going on. First, you are hiding a <pre>, then selecting from a textarea, z-indexing a div and the select link, then the link is traversing the dom tree to select text in the textarea while resizing the textarea with a JS call on the classes… see where I am going? There is a lot going on for a textarea view with a select all code to make it easier to copy it.
Backing up, I added https://www.whonix.org/wiki/Whonix:Sandbox/Code_select as a demo on something a little easier to do. Hover over the text area, left click to select or right click to select and copy. Done. Check it out. I know the [select text] link is gone, but hover over the textarea box will add some styling which will clue there is something active to do. I set it so the mouse pointer will change to a “grab hand” which is another clue. Click anywhere in the box and the text is all selected. Click again and you can click to select just text you want, which is probably not the use.
Mobile, will focus, but not select and I can not see a need to select all and copy to paste somewhere. Who is using their mobile device to copy and paste code to execute or change config files?
I like (b). Its cleaner than (a). Users might not realize that is a Select Code at first i.e. not just standard text? They would figure it out after a few copy/paste though.
As it turns out the new CodeSelect was not yet implemented when I had a look around the wiki. : I had assumed you had decided on example (a) but a newer version with better usability or something along those lines. Anyways the the new Codeselect looks good. For real this time . Sorry for the confusion.
The new CodeSelect copy button - JavaScript vs non-JavaScript version:
The non-JavaScript version has leading empty space. Where the JavaScript version has the copy button there, there non-JavaScript doesn’t have the copy button there since this is impossible to implement without JavaScript.
The leading empty space in the non-JavaScript version does not result in copying actual white space characters. That issue does not exist. The non-JavaScript simply suffers from an optical design limitation.
That non-JavaScript version design-only limitation is technically unfixable without making the JavaScript version of the wiki look worse. To remove the leading space in the non-JavaScript version, it would be required for the JavaScript version to initially have a similar design as the non-JavaScript version and then once JavaScript is load, the wiki would have a noticeable “jump” of text as the copy button would be injected on the left side.
Since most users have JavaScript enabled and non-JavaScript users are used to all kinds of weirdness anyhow and since non-JavaScript version is fully functional nonetheless besides the design-only limitation, I’ve elected for that way.
Other alternatives considered:
A) On the JavaScript version the copy button could “slide-in” to avoid the “jump”. But that would look very playful, perhaps silly, such an animation could take away attention form more important things.
B) Moving the copy button which is now on the left side over to the right side. But that imo looks worse.
C) Moving the copy button further to the left but that would break the design. The normal text would be aligned (vertically evenly start from the left side) but the copy buttons would stand out on the left.
Would be lots of extra time spent for the non-JavaScript version with questionable results.
The new CodeSelect (copy box) was been further improved. The non-JavaScript version no longer has extraneous white space. Therefore the JavaScript version now has a decent animation which looks like normal page loading which “slides in” (not really) from the left side.
. Sorry for the confusion.