B, I, U etc beter sig ointuitivt

När jag markerar en bit text och trycker Ctrl + B (eller klickar på motsvarande knapp) förväntar sig min hjärna till 100 % att texten som var markerad fortfarande ska vara det – inte minst då det är så i alla andra liknande gränssnitt jag använt. Ett sådant resultat är även till god nytta, eftersom jag då till exempel enkelt kan applicera både fet och kursiv.

Så är emellertid inte fallet.

Före:

En kamera är en apparat som kan ta fotografier.

Efter, förväntat:

En [b]kamera[/b] är en apparat som kan ta fotografier.

Efter, faktiskt:

En [b]kamera|[/b] är en apparat som kan ta fotografier.
            ^
            markören

Samma sak gäller väl i princip även knappar som Infoga länk och Länka video, men där är problemet inte lika påtagligt.

Slutligen vill jag lyfta en extra stark indikation på att det är intuitivt och bra att behålla markeringen: GitHub gör så. Få sajter har mer väldesignade GUI:n.

Kan även vara värt att nämna, kom jag på nu, att jag är ganska säker på att detta har funkat på SweClockers tidigare (minst ett år sedan, skulle jag tro).

Det låter bekant när du säger det, ja! Nytt för den här gången är att jag nu faktiskt tror att jag vet varför det är som det är, och varför beteendet ändrades för några år sedan.

När man använder ett verktyg som modifierar innehållet i textrutan (så som de är implementerade idag) dödar man dess historik, så det går inte att ångra sådana åtgärder. Det innebär att ett oavsiktligt klick på fel knapp kan få stora konsekvenser om knappen modifierar innehållet destruktivt. Det gjorde gissningsvis vissa knappar tidigare, till exempel knapparna för specialtecken.

Min gissning är att redaktionen tröttnade på att råka radera delar av sina egna texter, och att funktionaliteten därför ändrades från "ersätt oåterkalleligt markerad text och behåll markeringen" till "infoga efter markerad text och glöm markeringen". Kanske vet @Jacob, @JonasT eller någon annan mer om detta?

Antagligen används samma kod för destruktiva och ickedestruktiva operationer på textrutans innehåll, varför även de ickedestruktiva verktygen fick det nya beteendet. Där finns det ju dock ingen poäng med det.

Så i dagsläget har vi följande situation:

• Destruktiva verktyg beter sig inte som man förväntar sig, men i gengäld raderar de inget innehåll.

• Ickedestruktiva verktyg beter sig inte heller som man förväntar sig, men där får man ingenting i gengäld.

För inte så längesedan justerade jag beteendet hos de destruktiva verktygen i Better SweClockers till samma som standardverktygen, av samma skäl (att inte kunna råka radera text). De ickedestruktiva verktygen i Better SweClockers fungerar däremot fortfarande som förväntat, för de använder inte samma kod.

Nu ligger det i min backlog att bygga om koden som modifierar textrutans innehåll (både för Better SweClockers verktyg och förhoppningsvis standardverktygen) så att historiken inte försvinner. Då borde man kunna få samtliga verktyg att fungera som förväntat, samtidigt som man inte riskerar att radera innehåll av misstag. Det skulle även ge en bättre upplevelse överlag, eftersom man då skulle kunna ångra och göra om precis som i andra textredigeringsprogram.

Den lilla initiala research jag gjort tyder på att document.execCommand kan vara det bästa sättet att implementera detta på.

Har tagit fram en referensimplementation baserad på paketet text-field-edit. Ångra-stöd funkar finfint i Chrome och iOS Safari, men inte i Firefox, varför jag sett till att aldrig ersätta text destruktivt i Firefox, åtminstone inte utan bekräftelse från användaren.

I alla webbläsare behålls däremot markeringen som förväntat. Hur detta åstadkoms för de inbyggda verktygen (B/I/U/S) finns att beskåda här (med en hel del abstraktioner).

Kärnan i hur text-field-edit tillhandahåller ångra-stöd är att den använder document.execCommand. Om det inte stöds faller den tillbaka till HTMLTextAreaElement.prototype.setRangeText.

Min bedömning efter att ha använt denna nya feature i ett par dagar är att motsvarande förbättring från SweClockers sida skulle förbättra redigeringslägets UX avsevärt.

Vad säger @jreklund om detta?