Как стать автором
Обновить

Комментарии 20

С появлением Promise в ECMAScript 6 (ES6) всё стало возможным!

разберём разметку (bootstrap и Font Awesome для шрифтовых икон) и код alert (я использую jQuery)

Так много зависимостей. А чем оно лучше стандартных диалогов браузера?

имхо автор просто про них не слышал)
ну еще диалоги ввели вроде в HTML 5.1
Если браузер не поддерживает эту версию, то можно использовать диалоги на JS

Да уже года 3 как поддерживается везде кроме проприетарных недобраузеров. Но и для них полифил есть на той же странице MDN. Не вижу причин не пользоваться ими…
Ну да, всего-то не поддерживают Firefox, Safari и IE (<Edge).
Действительно не слышал — использую только уже распространенные технологии для большинства современных браузеров. Но сейчас посмотрел — принцип тот-же, что и в других модальных окнах — для обработки нужно реагировать на элементы управления в модальном окне. А в стандартных функциях (и в моём случае) — не нужно разделять код запроса окна, реакцию на ответ пользователя и его обработку в разных фрагментах кода.
Лучше тем, что одинаковые в различных браузерах, содержат настраиваемую под проект и задачу информацию и приводятся к единому дизайну страницы.
Лучше тем, что одинаковые в различных браузерах.

У меня и стандартные HTML одинаковые во всех браузерах, содержат настраиваемую под проект и задачу информацию и приводятся к единому дизайну включенной темы GTK. Весьма спорный аргумент, <dialog> может содержать любую информацию и мало чем отличается от, например, <div> или <body>. И свойства CSS на них распространяются не хуже других. Модальное окно не останавливает работу JS, но при этом также может ожидать промиса ответа диалога.

Я вот одного не понимаю, зачем для alert, confirm и prompt подключать jQuery, да еще и с bootstrap и Font Awesome.

Вам не кажется это перебором, особенно для реализации в качестве достойной замены базовым возможностям HTML?
Как я вижу, темы GTK тут вообще не причём — речь о стилизации под темы внутри страниц HTML.
Повторюсь — есть масса возможностей создавать диалоги средствами и jQuery и bootstrap и др. но alert, confirm и prompt позволяют писать непрерывную логику программы. В отличие от других средств, разрывающих логику на «до запроса диалога» и коллбэк реакции на действия пользователя. Но дизайн и содержимое alert, confirm и prompt не соответствуют дизайну страницы и имеют разный дизайн и содержимое в разных браузерах (это особенно плохо для игр). Я объединяю функциональные аспекты alert, confirm и prompt (очень удобные) и аспекты дизайна простым приёмом…
НЛО прилетело и опубликовало эту надпись здесь
Так статья о них!
НЛО прилетело и опубликовало эту надпись здесь
Если ВЫ сделали вёрстку в Bootstrap, то модалка в jQuery UI вряд ли кому понравится (без очень трудоёмких настроек CSS). В самом Bootstrap есть модалки! О это открытие! Я их и использую. Весь вопрос в ОСТАНОВКЕ программы в месте вызова окна, а не в танцах с обратными вызовами, разрывающими логику программы.
НЛО прилетело и опубликовало эту надпись здесь
Всем устраивает! Это примерно то, что я и предлагаю, только немного другая реализация и без акцента на дизайн…
А где здесь ОСТАНОВКА программы?
await это ОСТАНОВКА программы до действия пользователя

Переопределение стандартных функций (в вашем случае alert, confirm и prompt) – это за гранью добра и зла.

Конечно, НЕ ОБЯЗАТЕЛЬНО переопределять стандартные функции — можно сделать другие. Но тогда сообщения сервера и встроенных библиотек будут очень выделяться. Особенно это плохо в играх с очень специфичным дизайном(((

Это не то что не обязательно, так делать нельзя в принципе, это самая что ни на есть bad practice.
Единственная легальная причина переопределять стандартные методы/функции/классы/… это полифилы.


Но тогда сообщения сервера и встроенных библиотек будут очень выделяться

Связи между этим и переопределением функций alert, confirm и prompt я вообще не вижу.

Вот как выглядит alert в моей игре:
image
В этом его преимущество!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации