это да, в общем случае.
но намного проще, чем обработка "oninput", потому что в последнем, по хорошему, надо не просто корректировать value, а ещё и запоминать/восстанавливать позицию курсора. Кстати, если тут нужны шестнадцатиричные числа, то таки придется это заговнокодить. Либо сделать проверку при отправке.

Согласен. Если знаем, что есть нечто постоянное перед значением и требуемое для всех полей, то не зачем его гонять между клиентом и сервером. На мой взгляд в данном случае усложняется все неоправданно, о чем автору ранее уже говорилось (в другой теме).

И об этом говорилось ранее, но ... :)
Это еще ладно, что на клиенте придется "костылять", а что же тогда есть на сервере, если все связано с базой? К чему это весь сыр-бор не понятно. Десятичными должен оперировать и клиент, и сервер, а если надо, то представить можно хоть в восьмеричной, какие тут проблемы.

laimas,
Судя по предыдущим темам, у них персонал привык работать с шестнадцатиричным отображением чисел. Такое бывает ...

Как вещает история, к супер компьютеру Gray был утерян загрузчик и Сеймур Крэй диктовал несколько килобайт машинного кода загрузчика по памяти.

Вы представляете хранение опций в базе в виде шестнадцатеричных значений? Конечному потребителю как то ini-файлов, hex-дампов прошивок причем в любом формате intel/motorolla, и т.п., десятичные упаковать в любое иное исчисление не проблема, а вот оперировать шестнадцатеричными не удобно.

Все может быть, может так и выгоднее, но тогда для удобства свое кастомное поле с кнопками c отображением в hex.

если он его так хорошо запомнил, то это поистине выстраданный код :)

:) Не только код, но и сами машины тоже.