Арсений Матыцин

1. Фон прозрачный. Непрозрачный = полная заливка.
2. Бери SVG, не прогадаешь.

UPD, чтобы не возиться с расчетами, ты можешь сделать закругление псевдоэлементами и использовать тогда gif\png\svg (актуально, если высота не меняется, а только ширина надписи).

Нус для начала можно вынести где-то вверх e.preventDefault();, при беглом осмотре я увидел это при всех условиях.

Дальше до каждого третьего условия я вижу логику selectionStart\selectionEnd + 2, т.е. тоже можно сократить.

Ну и в вопросе лучше изменить формулировку

более лаконичнее и читабельнее

На

более лаконичным и читабельным

Или вовсе убрать «более».

Проверь на тип данных, если контекст это словарь (а должен быть по идее он), то тебе сюда за справкой.

На лицо проблема кодировки. Это символ ascii «]» (%5D). Если я прав, то шанс повторить ошибку не так уж велик, я бы рекомендовал понять первопричину, ибо, как понимаю, вместо подобной ошибки оно должно приходить, как строковая переменная.

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

В нормальном построенном коде callback выполняется либо по факту условия выполнения функции (не обязательно асинхронной).

Иными словами, если функция не выполнена, то вторая не войдет в условие. Но колбэком может стать обработчик ошибки, тоже функция.

Не знаю даж, может быть есть проще объяснение, я старался как мог)

Использовать margin\padding и свойства flex\grid (например align-self:end\start для вложенных элементов).

Вообще данный CSS кусок выглядит в меру корректным. Поэтому проверяй что перекрывает\мешает выполнению этого кода.

Дебаггер тебе в помощь.

Из альтернатив, кстати, можешь не display:block давать submenu, а display:flex. Но, чтобы понимать, как это работает, почитай документацию\гайды по флексам.

Если тебе нужна география, то чем Яндекс плох?

Ну а если тебя беспокоит страховка от падения сервака, то чисто теоретически ты можешь разработать логику, которая будет перекидываться от одного API к другому. Конечно, тебе придется заводить много полей, так как идентификаторы 100% разные. Зато надёжно)

Ответы

Звучит очень неадекватно. Простительно новичку... наверное.

Django — фреймворк на Python. Шарп (C#) — язык (поправьте меня, если кто знает такой фрейм). Разница как между солнцем и козюлей в носу.

Если же брать необходимость только базы + авторизации, я бы рекомендовал Flask + библиотеки типа Flask-Login (тоже фреймворк на Python). Скорость расчетов особая не нужна, ты же не написал, что собираешься ИИ делать. Так что сойдет.

А вот на счет 2.5 месяца... Ну если ты достаточно гениален, то у тебя все получится. В остальном с никаким знанием у тебя за такой короткий срок врядли выйдет что-то работающее и не подпертое костылями с тостера и стака.

Да и тебе скорее всего веб-сокеты потребуются. Или писать постоянные запросы для обновления данных для доски. Это не считая разработки самой морды (доски).

Я начал вводить «window.onerror» в поисковике, и он мне сразу подкинул «window.onerror not working». Судя по всему, ответ уже давно измусолен где-нибудь на стаке.

UPD: Кстати, посмотри первый абзац документации. И попробуй симитировать другую ошибку на странице, чтобы проверить, входит ли данная ошибка в список тех, что словит window.onerror или нет.

Я так понимаю речь о рекламных баннерах. Посмотри в сторону iFrame и то, как это реализуют поисковые метрики. Если кратко, то скрипт вызывающий их генерирует DOM-элементы, включая дополнительные скрипты.

Я так понимаю проблема не в незнании того, как работает обработка пользовательского ввода в формы при работе с джангой. Посему:

1. Я бы на твоем месте обернул формой всю таблицу.
2. Создал форму на уровне бэка для вывода полями типа hidden (contenteditable к этой штуке привязан какой-то JS редактор, значит ему можно присвоить передачу в поля значения)
3. Ну и да, изначальные значения присваивать в поля тоже неплохо бы.
4. Итак, когда ты редактируешь с помощью JS редактора ячейки, значения которых попадают в input-ы, то по сабиту формы, они сами уйдут в обработчик.

Пункт первый в принципе совсем не обязательный, но так я вижу меньше кода из-за привязки к одному контейнеру всего месива. Да и глянь документацию своего JS-редактора, может быть там все это уже есть в виде готового решения и тебе придется только создать корректную прослойку между формой и бэком.

Ну или можешь оторваться от использования шаблонов Jinja и написать свое приложение на JS\JS-фреймворке, которое будет безе перезагрузок обмениваться данными с, API в лице твоей Django.

Как видишь, варианты есть.

Не умеет, при некоторых манипуляциях это может сделать grid, но для автоматического расчета все же есть смысле использовать кирпичную кладку.