Комментарии 20
С появлением Promise в ECMAScript 6 (ES6) всё стало возможным!
разберём разметку (bootstrap и Font Awesome для шрифтовых икон) и код alert (я использую jQuery)
Так много зависимостей. А чем оно лучше стандартных диалогов браузера?
имхо автор просто про них не слышал)
ну еще диалоги ввели вроде в HTML 5.1
Если браузер не поддерживает эту версию, то можно использовать диалоги на JS
Действительно не слышал — использую только уже распространенные технологии для большинства современных браузеров. Но сейчас посмотрел — принцип тот-же, что и в других модальных окнах — для обработки нужно реагировать на элементы управления в модальном окне. А в стандартных функциях (и в моём случае) — не нужно разделять код запроса окна, реакцию на ответ пользователя и его обработку в разных фрагментах кода.
Лучше тем, что одинаковые в различных браузерах, содержат настраиваемую под проект и задачу информацию и приводятся к единому дизайну страницы.
Лучше тем, что одинаковые в различных браузерах.
У меня и стандартные 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 (очень удобные) и аспекты дизайна простым приёмом…
Повторюсь — есть масса возможностей создавать диалоги средствами и jQuery и bootstrap и др. но alert, confirm и prompt позволяют писать непрерывную логику программы. В отличие от других средств, разрывающих логику на «до запроса диалога» и коллбэк реакции на действия пользователя. Но дизайн и содержимое alert, confirm и prompt не соответствуют дизайну страницы и имеют разный дизайн и содержимое в разных браузерах (это особенно плохо для игр). Я объединяю функциональные аспекты alert, confirm и prompt (очень удобные) и аспекты дизайна простым приёмом…
Если ВЫ сделали вёрстку в Bootstrap, то модалка в jQuery UI вряд ли кому понравится (без очень трудоёмких настроек CSS). В самом Bootstrap есть модалки! О это открытие! Я их и использую. Весь вопрос в ОСТАНОВКЕ программы в месте вызова окна, а не в танцах с обратными вызовами, разрывающими логику программы.
Переопределение стандартных функций (в вашем случае alert
, confirm
и prompt
) – это за гранью добра и зла.
Конечно, НЕ ОБЯЗАТЕЛЬНО переопределять стандартные функции — можно сделать другие. Но тогда сообщения сервера и встроенных библиотек будут очень выделяться. Особенно это плохо в играх с очень специфичным дизайном(((
Это не то что не обязательно, так делать нельзя в принципе, это самая что ни на есть bad practice.
Единственная легальная причина переопределять стандартные методы/функции/классы/… это полифилы.
Но тогда сообщения сервера и встроенных библиотек будут очень выделяться
Связи между этим и переопределением функций alert, confirm и prompt я вообще не вижу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как создать кастомизируемый вид для alert(), confirm() и prompt() для использования в JavaScript