Notacja klawiszy w <kbd></kbd>

1

Jak pewnie większość z was już zauważyła, mamy na forum notację klawiszy <kbd></kbd>, która jest dekorowana w edytorze oraz w renderze jak klawisz. Aktualnie jest to też zrobione tak, że edytor potrafi wykryć czy wpisany klawisz jest poprawny, np Ctrl będzie dekorowany ale już <kbd>Ctr</kbd> nie.

Mam do was pytanie, czy uważacie że tak powinno być? Czy powinno się dać móc wpisać do <kbd> nieistniejące klawisze i powinno być git?

Noi też dochodzi kolejna sprawa, że niektórzy chcieliby w <kbd></kbd> wpisywać nie tylko klawisze, ale też inne ciągi, np wyjście z wima chcieliby wyrazić <kbd>:wq!</kbd>, ale nie jestem pewien czy to jest zgodne ze standardem i czy chcemy coś takiego. Ja bym do tego celu po prostu użył kodu inline `:wq!`.

PS: Jestem jeszcze ciekaw zdania @furious programming

1

MDN Web Docs tak opisują element <kbd>:

<kbd>: The Keyboard Input element

The <kbd> HTML element represents a span of inline text denoting textual user input from a keyboard, voice input, or any other text entry device. By convention, the user agent defaults to rendering the contents of a <kbd> element using its default monospace font, although this is not mandated by the HTML standard.

~ https://developer.mozilla.org/en-US/docs/Web/HTML/Element/kbd

Warto zwrócić uwagę, że "voice input" jest określane jako "text entry device".

Co ciekawsze, dalej w sekcji "Usage notes" jest napisane:

  • Nesting a <kbd> element within another <kbd> element represents an actual key or other unit of input as a portion of a larger input. See Representing keystrokes within an input below.
  • Nesting a <kbd> element inside a <samp> element represents input that has been echoed back to the user by the system. See Echoed input, below, for an example.
  • Nesting a <samp> element inside a <kbd> element, on the other hand, represents input which is based on text presented by the system, such as the names of menus and menu items, or the names of buttons displayed on the screen. See the example under Representing onscreen input options below.

~ https://developer.mozilla.org/en-US/docs/Web/HTML/Element/kbd

Wygląda więc na to, że według MDN Web Docs jest to element dość elastyczny semantycznie.

6

IMHO nie powinniśmy rozpoznawać klawiszy.

1
jurek1980 napisał(a):

IMHO nie powinniśmy rozpoznawać klawiszy.

Zgadzam się.

1
jurek1980 napisał(a):

IMHO nie powinniśmy rozpoznawać klawiszy.

Jakiś argument za tym?

0

@jurek1980, @Adam Boduch: dlaczego nie przyjąć tej samej definicji <kbd>, co MDN Web Docs? (Nie mam zdania, po prostu pytam).

3

Po pierwsze mamy z historycznych zaszłości X typow klawiatur. W pamięci mam np. takie z 20 klawiszami funcyinymi. Po drugie ja bym używał też kbd np. do innych celów. Jak klawiatura ma np. dedykowany klawisz do zwieszenia głośności to vol up bylby ok. W andoidzie i telefonie sugestia użycia vol up+power dla menu bootloadera też jest uzasadniona.

1
jurek1980 napisał(a):

Po pierwsze mamy z historycznych zaszłości X typow klawiatur. W pamięci mam np. takie z 20 klawiszami funcyinymi. Po drugie ja bym używał też kbd np. do innych celów. Jak klawiatura ma np. dedykowany klawisz do zwieszenia głośności to vol up bylby ok. W andoidzie i telefonie sugestia użycia vol up+power dla menu bootloadera też jest uzasadniona.

No to jeśli problemem jest to, że nie ma niektórych klawiszy, to nie ma problemu :) Po prostu dodamy brakujące.

Chociaż z drugiej strony, nie wiem czy nazwałbym "volume up" mianem "klawisz".

1

@TomRiddle: tylko ciężko przewidzieć wszytskie mutacje klawiatur. No i nawet na przykładzie Twojego posta użyliśmy vol up ze spacja i volUp bez spacji.

1

Ach, teraz chyba rozumiem. Chodzi Ci, @jurek1980, że nie powinniśmy rozpoznawać poszczególnych klawiszy, w sensie: przycisków na klawiaturze (wirtualnej lub fizycznej), tylko "user input" rozumiane jako ogólna, oddzielna kategoria semantyczna?

7

Nie rozumiem tej dyskusji. Po co próbować przewidywać przyszłość, tworzyć jakieś whitelisty, komplikować kod... to ma być proste stylowanie po prostu. Cokolwiek wpadnie pomiędzy <kbd> dostaje styl i koniec pieśni.

0

</kbd>

0

No ja miałem pomysł żeby sprawdzać klawisze w <kbd>, bo uważałem to za średnie jak ktoś wpisywał "Potem wciśnij dowolny klawisz". Kiedy "dowolny klawisz" to nie jest klawisz, tylko tak się komuś wydawało.

A poza tym miałem plan dodać więcej dekoracji do edytora, tak że jak ktoś wpisze np Command to to się udekoruje jakoś tak:

screenshot-20220209144016.png

I to samo z innymi klawiszami, jak Enter, Tab, etc. A jak wszystko będzie dopuszczone w <kbd> to taka dekoracja jest niemożliwa.

2

Ty już tu nie bądź takim komunistą, by zaglądać komuś w tagi!

2
TomRiddle napisał(a):

No ja miałem pomysł żeby sprawdzać klawisze w <kbd>, bo uważałem to za średnie jak ktoś wpisywał "Potem wciśnij dowolny klawisz". Kiedy "dowolny klawisz" to nie jest klawisz, tylko tak się komuś wydawało.

OK, ale z drugiej strony, jest to manifestacja najgorszej (osobiście stawiam ją w TOP topów, ponieważ jest przyczynkiem ogromnej ilości frustracji przy używaniu czegoś takiego) cechy oprogramowania dla użytkownika - ja (tj. aplikacja) wiem lepiej do ciebie (tj. użytkownika) co chcesz zrobić. Albo - nie pozwolę ci na to, bo miałeś co innego na myśli. Nie, miałem to na myśli co zapisałem.
I o ile dla "sekretarki" takie zachowanie systemu czasem można uznać nawet za "wartość dodaną", o tyle grupą docelowa tego edytora są programiści.
Programiści podkreślam, którzy codziennie muszą wiedzieć co wpisują w te edytory...

Zatem również uważam, ze to co w tagu to jest wyświetlane.
Wszelkie dodatkowe mechaniki są zbędne i niosą ze sobą niebezpieczeństwo zmian tylko na gorsze.

1

Pomijam, że Twoja odpowiedź jest trochę nie na temat, bo wątek jest o tym "Czy powinniśmy używać <kbd> to pisania np o vimie :wq!?".

wloochacz napisał(a):
TomRiddle napisał(a):

No ja miałem pomysł żeby sprawdzać klawisze w <kbd>, bo uważałem to za średnie jak ktoś wpisywał "Potem wciśnij dowolny klawisz". Kiedy "dowolny klawisz" to nie jest klawisz, tylko tak się komuś wydawało.

OK, ale z drugiej strony, jest to manifestacja najgorszej (osobiście stawiam ją w TOP topów, ponieważ jest przyczynkiem ogromnej ilości frustracji przy używaniu czegoś takiego) cechy oprogramowania dla użytkownika - ja (tj. aplikacja) wiem lepiej do ciebie (tj. użytkownika) co chcesz zrobić. Albo - nie pozwolę ci na to, bo miałeś co innego na myśli. Nie, miałem to na myśli co zapisałem.

To jest niebezpieczne stwierdzenie, i wydaje mi się że nie do końca prawdziwe.

Dzisiaj dodałem taką funkcję, że jak masz kursor pomiędzy nawiasami, (), i wciśniesz ), to kursor przeskoczy na koniec (nie dopisze tego drugiego nawiasu). Według tego co mówisz edytor tego nie powinien zrobić, tylko po prostu wpisać ten nawias, tak jak kliknąłeś. ()), bo przecież gdybyś faktycznie chciał przenieść kursor to użyłbyś ArrowRight, prawda? :) A skoro wcisnąłeś ( to znaczy że powinniśmy wsadzić znak ( tam gdzie jest kursor. No tak czy nie? :> Czy automatyczne wstawienie znaku tam gdzie edytor się domyśla co chcesz zrobić jest inne, od tego kiedy edytor się domyśla jaki znak można wpisać. Mamy też inne tego typu funkcje związane ze składnią; i edytor robi bardzo wiele rzeczy za użytkownika, bo jednak czasem wie lepiej od usera co można a co nie można; zwłaszcza jeśli ktoś nie zna Markdownu. Tak, wiem że jak się zjawi master geniusz użytkownik, to czasem spróbuje dodać coś co faktycznie jest poprawne, a czego edytor nie przewidział, ale wtedy to jest kwestia jednego wątku na forum z prośbą o poprawki.

Po drugie, programiści czy nie programiści, czasem każdy się myli. Zdziwiłbyś się ilu ludzi tutaj uważe że zna Markdown, podczas gdy nie słyszało o 90% jego cech. Ja chciałbym, jeśli wpisze np <kbd>Ctr+A</kbd>, żeby edytor powiedział mi że to jest źle, i miałbym szansę to poprawić wtedy na Ctrl+A.

A po trzecie, nie wiem czy się zgadzam ze stwierdzeniem ja (tj. aplikacja) wiem lepiej do ciebie (tj. użytkownika) co chcesz zrobić. To wiadomo że jest nie prawda, bo aplikacja nie może wiedzieć lepiej co chcesz zrobić. To jest racja. Ale czy na prawdę z tym mamy do czynienia? Czy może jednak mamy do czynienia z niezrozumianym przez użytkownika podejściem "ja (tj. aplikacja) wie lepiej od ciebie co możesz zrobić", i jeśli próbujesz zrobić coś czego się nie da, to Ci nie pozwala. System operacyjny wie lepiej od Ciebie co chcesz, jak nie pozwala Ci usunąć otwartego pliku? Czy może to jednak użytkownik czegoś nie rozumie?

Wszelkie dodatkowe mechaniki są zbędne i niosą ze sobą niebezpieczeństwo zmian tylko na gorsze.

Np?

PS: Nie zrozumcie mnie źle, mi nie chodzi o to żeby faktycznie była jakąś whitelista dozwolnych znaków, albo że koniecznie musi zostać tak jak jest. Możemy poluźniać zasady tego co jest klawiszem a co nie. Po prostu nie wydaje mi się żeby dobrym pomysłem było żeby się dało wsadzić tam wszystko. No bądźmy szczerzy, jaki sens jest napisać <kbd>$#RVT$%TBV#$%VCT$%@TCV#F$%</kbd>? Albo żeby wstawiać encje HTML <kbd>&nbsp;</kbd>?

2

Nie rozumiem. Działa, koloruje, po kiego mejzę drążyć temat? :P

3

Jak dla mnie temat z czapy. Co następne? AI będzie sprawdzać czy treść w środku <b> jest warta pogrubienia?
Ktoś specjalnie użył taga żeby coś ostylować to niech będzie ostylowane. Jakby nie chciał żeby było ostylowane to by go nie użył. Wyobrażasz sobie żeby przy programowaniu komputer wykonywał tylko te polecenia które uzna za stosowne?
Na klawiaturze mam wiele klawiszy jak np "Mute", "Win lock", multimedialne "Forward", "Prev", "G1" i wiele innych oznaczonych ikonkami. Jest też klawisz menu który niektórzy nazywają "Menu", niektórzy "Context menu" albo jeszcze inaczej a na klawiaturze to po prostu trzy kreski. Każdy może nazwać też po swojemu skoro wiadomo o co chodzi.

Jedyne co można by było usprawnić to np dodać ikonki do niektórych klawiszy - np jak ktoś wpisze "Shift" żeby się pojawiła strzałka w górę tak jak na wikipedii https://en.wikipedia.org/wiki/Shift_key

1
obscurity napisał(a):

Jak dla mnie temat z czapy. Co następne? AI będzie sprawdzać czy treść w środku <b> jest warta pogrubienia?
Ktoś specjalnie użył taga żeby coś ostylować to niech będzie ostylowane. Jakby nie chciał żeby było ostylowane to by go nie użył. Wyobrażasz sobie żeby przy programowaniu komputer wykonywał tylko te polecenia które uzna za stosowne?

No przecież dokładnie tak jest ;|

Jak spróbujesz usunąć otwarty plik; to OS Ci powie że nie możesz. Jak spróbujesz zapisać ujemną liczbę bajtów do pliku, to system plików Ci powie że nie możesz. Jak spróbujesz otworzyć plik UTf-8 w kodowaniu Windows-1080; to większość edytorów Ci powie że nie możesz; a jak otworzysz to dostaniesz krzaczki. Masę rzeczy programy robią i mówią: "Hola, nie możesz tego zrobić".

2
TomRiddle napisał(a):

PS: Nie zrozumcie mnie źle, mi nie chodzi o to żeby faktycznie była jakąś whitelista dozwolnych znaków, albo że koniecznie musi zostać tak jak jest. Możemy poluźniać zasady tego co jest klawiszem a co nie. Po prostu nie wydaje mi się żeby dobrym pomysłem było żeby się dało wsadzić tam wszystko. No bądźmy szczerzy, jaki sens jest napisać <kbd>$#RVT$%TBV#$%VCT$%@TCV#F$%</kbd>? Albo żeby wstawiać encje HTML <kbd>&nbsp;</kbd>?

Ano sens tego jest taki, że ktoś może mieć taką potrzebę. Po prostu.
Ty jako programista nie masz prawa określać takiego sensu, za to masz obowiązek dostarczyć odpowiednie narzędzia (a przynajmniej ja tak rozumiem swoją pracę).

Ale większy sens jest tak, że można w ten sposób zwizualizować coś, czego nawet nie przewidziałeś, ale sprytny i kreatywny user wykorzysta to do własnych celów.
I to jest absolutnie lepsze rozwiązanie, niż blokowanie czegokolwiek.

Poza tym, gdyby od tego zależała jakaś biznes-logika...
A tu jest tylko (i aż) wizualizacja, zatem po co ograniczać?

somekind napisał(a):

Nie rozumiem. Działa, koloruje, po kiego mejzę drążyć temat? :P

O to, to właśnie!

1
wloochacz napisał(a):
TomRiddle napisał(a):

PS: Nie zrozumcie mnie źle, mi nie chodzi o to żeby faktycznie była jakąś whitelista dozwolnych znaków, albo że koniecznie musi zostać tak jak jest. Możemy poluźniać zasady tego co jest klawiszem a co nie. Po prostu nie wydaje mi się żeby dobrym pomysłem było żeby się dało wsadzić tam wszystko. No bądźmy szczerzy, jaki sens jest napisać <kbd>$#RVT$%TBV#$%VCT$%@TCV#F$%</kbd>? Albo żeby wstawiać encje HTML <kbd>&nbsp;</kbd>?

Ano sens tego jest taki, że ktoś może mieć taką potrzebę. Po prostu.

YAGNI.

Daj przykład, bo bez tego rozmowa schodzi na filozoficzne tematy. Chociaż dwa albo trzy.

1
TomRiddle napisał(a):
obscurity napisał(a):

Jak dla mnie temat z czapy. Co następne? AI będzie sprawdzać czy treść w środku <b> jest warta pogrubienia?
Ktoś specjalnie użył taga żeby coś ostylować to niech będzie ostylowane. Jakby nie chciał żeby było ostylowane to by go nie użył. Wyobrażasz sobie żeby przy programowaniu komputer wykonywał tylko te polecenia które uzna za stosowne?

No przecież dokładnie tak jest ;|

Chodzi Ci o to "żeby przy programowaniu komputer wykonywał tylko te polecenia które uzna za stosowne"?
Oczywiście że tak nie jest - komputer nie wykona tego czego nie rozumie, a nie to co jest "niestosowne".

0

Moim zdaniem nie ma o co się kłócić… Ja nie wiem, co najlepsze jest dla użytkownika, pewnie dla każdego coś innego.

A co najlepsze jest dla utrzymania systemu i dla jego bezpieczeństwa?

0
wloochacz napisał(a):
TomRiddle napisał(a):
obscurity napisał(a):

Jak dla mnie temat z czapy. Co następne? AI będzie sprawdzać czy treść w środku <b> jest warta pogrubienia?
Ktoś specjalnie użył taga żeby coś ostylować to niech będzie ostylowane. Jakby nie chciał żeby było ostylowane to by go nie użył. Wyobrażasz sobie żeby przy programowaniu komputer wykonywał tylko te polecenia które uzna za stosowne?

No przecież dokładnie tak jest ;|

Chodzi Ci o to "żeby przy programowaniu komputer wykonywał tylko te polecenia które uzna za stosowne"?
Oczywiście że tak nie jest - komputer nie wykona tego czego nie rozumie, a nie to co jest "niestosowne".

Daj przykład klawisza, bo to schodzi na filozoficzne tematy ta rozmowa.

0

Nadgorliwość jest gorsza od faszyzmu

Wiesz że nawet walidacja numeru PESEL nie powinna mieć miejsca bo chodzą w polsce ludzie z źle nadanym numerem i nie zgadza się im cyfra kontrolna. Jest też parę przypadków z jednakowymi numerami.
Walidacja powinna pomagać, wychwytywać błędy na wczesnym etapie które i tak trzeba by było poprawić później, a nie przeszkadzać bo ktoś kto ją pisał nie znał wszystkich przypadków

0

Oto przykład @TomRiddle:

Tu masz błąd w wyrażeniu (s.StateOptions & power(2, @ItemKind)) = 0, pokażę ci żeby było widać:
(s.StateOptions & power(2,@ProductKind )) = 0

Fajne, można coś wyróżnić :)

1
wloochacz napisał(a):

Oto przykład @TomRiddle:

Tu masz błąd w wyrażeniu (s.StateOptions & power(2, @ItemKind)) = 0, pokażę ci żeby było widać:
(s.StateOptions & power(2,@ProductKind )) = 0

Fajne, można coś wyróżnić :)

Czyli użycie <kbd> do wyróżnienia czegoś w kodzie `inline`?

Nooooooooooo, nie mówię nie, ale ja bym się poważnie zastanowił czy to co zaprezentowałes ma sens. Ja bym powiedział że raczej mały, żeby <kbd> do tego służyło.

Już prędzej <mark>. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/mark I zgadzam się że w takim <mark> faktycznie mogłoby być wszystko, bo wszystko powinno się dać móc zaznaczyć.

0
TomRiddle napisał(a):

Czyli użycie <kbd> do wyróżnienia czegoś w kodzie `inline`?

To jest przykład zastosowania, a nie przepis na nową mechanikę!
To ja sobie tak użyłem, a ktoś inny może sobie użyć dowolnie inaczej.

Drogi @TomRiddle mnie to w ogóle lata i powiewa czy będzie to kbd czy mark i czy zastosowanie jednego czy drugiego znacznika "ma sens". Dla mnie sensu nie ma, szukanie w tym sensu i dokładnie w tym kontekście (edytor forum), ale do brzegu.

Dla mnie wystarczałby mark bez kbd.
Ale jak dodasz zarówno obsługę mark jak i kbd tak jak teraz, to wszyscy są szczęśliwi.

Ale jakby taki mark pozwalał określić jeszcze kolor (nie wiem np. <mark color="red"> czy coś takiego...) to w ogóle byłby WYPAS! :)

0

Ponawiam pytanie: co najlepsze jest dla utrzymania systemu i dla jego bezpieczeństwa?

2
Silv napisał(a):

Ponawiam pytanie: co najlepsze jest dla utrzymania systemu i dla jego bezpieczeństwa?

a nie pomyliłeś tematów? utrzymanie systemu i bezpieczeństwo w temacie o kolorowaniu napisów?

1 użytkowników online, w tym zalogowanych: 0, gości: 1