Ну тогда при таком подходе, по всем css-файлам cleаnCSS-ом прошлись бы. Восстановить то не проблема :)
Хорошо что JS не аглифицирован, такой точно в удобоваримый формат не переведёшь :)
Ладно холивар уже пошёл ))) Фиг с ним, не суть )

Насколько мне известно в Opencart подвергаются минимизации только встроенные в шаблоны js сценарии, да и лучше бы оно вообще не делалось ибо курам на смех. Всем иным в базовой поставке CMS не занимается. А минимизированные CSS и JS, это тех разработчиков кто действительно позаботился о загрузке только полезного.

Не стал я настраивать Gulp или Webpack для проекта. Честно говоря, не очень представляю как в таких проектах правильно организовать `src` и `dist`. В принципе можно в директории `theme` сделать две папки типа `mytheme-src` и `mytheme-dist`, первую и отслеживать, но ведь править приходится некоторые вещи за пределами папки с моей темой, хотя конечно 95% всех правок производится в ней. Хотя и тут можно что-то придумать.

Я не совсем понял. JS-ки за пределами папки кастомной темы не меняются через модификаторы? Просто там на старом синтаксисе ES5 всё написано. Я уже стал от него отвыкать. В новом с вебпаком всё так здорово - подключил файл, расширил класс. А тут... Как мне в своём кастомном js-файле например расширить с добавлением новых свойств и методов класс псевдокласс `cart`, построенный по-старинке на объекте?

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

Собственно насиловать код и не нужно для этого. Код модификатора можно взять из файла modification.php, чуточку подправить чтобы обрабатывал один файл/один модификатор, и результат выводил на экран - лог, и пропущенный через htmlspecialcahrs() результат. Вот на этом и тренируйтесь для уяснения где вы ошибаетесь в ожиданиях.

А в базовой поставке из подключаемых файлов (не считаем плагины) всего один - common.js, в котором не так и много кода, обработчик поиска да корзины. Его проще заменить через модификатор на свой. Например так поступают при добавлении новых модулей/расширений/тем, помещая его новую версию в отличный от базового каталог.

Но если вы расширяете обработчики его, опасаясь за дальнейшее, тогда через модификатор.

Да, договорённостей тут не очень. Приходится постоянно отслеживать селекторы во время внедрения другого дизайна. Я переписал их так: $('#самыйВерхнийРодительВсе гоШаблона #элемент(или .элемент) ').actionts...
а то встречаются выборки по более низкоуровневым родителям. Ну их.. всё скопом хватаю. Ошибок пока нет.

Если каждый модуль внедряет свои модификаторы, т.е. один произвёл один замены в исходниках, другой другие, то тогда как они вообще потом вместе уживаются? Если они предполагают js-код, то как этот код вообще будет обращаться к моим элементам, моей вёрстки? Вопросов больше чем ответов.

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

Представьте, что у вас машина, но где бы вы не ездили на ней, в черте ли города, или в пустыне, вы вынуждены следовать правилам - не выше 40 км/час, 15 км прямо, затем налево 20 км, ... Нафиг оно нужно такое авто. Вот так и с CMS, кому-то нравится "ездить в их рамках" постоянно, а мне нет, надоела вся эта хрень, тупеешь. Но бывает, что выполняю такую работу, сейчас как раз выполняю связанную с Opencart.

Эта CMS заточена под торговлю, все ли в ней сделано для этого на 100%, это вопрос риторический. Но она в базовом варианте предоставляет инструментарий который как минимум позволяет торговать всем. Но всю номенклатуру товаров нельзя поставить в один ряд. Например, бытовой прибор, он может иметь вид спереди, справа, слева, ..., то есть иметь множество изображений продукта.

Я думал, когда попросили сделать, что это будет езда на "автомобиле по условиям" на дистанцию не более 100 метров, ибо требовался пустяк - автоматически выбирать в карусели изображений продукта иное по умолчанию изображение. Выбор это тоже карусель, с различными способами модификации выбранного изображения. Можно было бы сделать что просят и забыть, но продукты этого магазина могут иметь только одно изображение, нет у них вида слева, справа, ... Естественно встал вопрос, зачем тогда карусель изображений, с которой нужно бороться костылями, хотя это должен был сделать разработчик расширения обеспечивающий работу с этими продуктами, заблокировав вывод ну хотя бы в шаблоне продукта, а по уму так и в контроллере нечего этим заниматься. А пользователь добавил в карусель изображения, которые к продукту вообще не имеют отношения, в админке то доступно, вот и ...

Было предложено, уж коли карусель изображений, то это изображения категории, которой принадлежит продукт, по которым можно было бы переходить и в карточку продукта. После у заказчика возник вопрос возможности добавления слайдера к этой карусели. Окончательный вариант - в слайдере подписи, не у текущего продукта, это ссылка на карточку.

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

Вообще расширение написано настолько криво, не в плане не грамотно, а в плане логики. Почему-то не подумали (или не хотели) о SVG, когда решали задачу описания и добавления вариантов выбора модификаций изображения продукта. Все описывается в виде массивов координат с вытекающими отсюда неудобствами, чтобы добавить что-то новое, придется править код в common.js ручками, ибо искать и править модификатором будет весьма затруднительно, что и не предусмотрено через админку.

Вот так, удаляя один костыль из расширения, возникает вопрос о другом. Ну сейчас вроде бы все костыли устранены, сделано по уму, теперь нужно сделать большое, но удобное - вместо массивов координат SVG.

Естественно все что правилось, все через модификаторы. А один и тот же файл могут модифицировать множество разработчиков своими файлами модификации. Модификатор собирает все это воедино. Для того чтобы избежать конфликтов, нужно выполнять модификацию в определенном порядке, для этого есть уже и модуль OCMOD Order.

Если делать, то делать, а абы как, это не дело, я так думаю. Мне не понятны на сайтах вещи лишенные смысла, я увидел такое, если бы на вопрос "что за ..." заказчик бы ответил "да и ... с ним", то бы и работа давно закончилась. Но коли и он озадачился, и решено было довести до какого либо смысла, значит нужно делать так, чтобы работа была не в тягость, а когда она не в тягость, это интересная работа. ;)

SVG вообще по умолчанию не разрешены в opencart.
Я решил эту проблему вот так.

А откуда берется вот это? -

{% for script in scripts %}
<script src="{{ script }}" type="text/javascript"></script>
{% endfor %}

А то я подключил ещё в начале свои скрипты в хэдере вот таким образом:
<script src="catalog/view/javascript/custom.js" type="text/javascript"></script>

Ну и расширяю скрипты из коробки типа так:

$(document).ready(function() {
	cart.add3 = function(mess) {
		alert(mess);
	}
	cart.add3('Yo!');
});

смысл понятен :)

Может не так делаю? )

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

Из данных переданных в шаблон в контроллере шапки страницы

$data['scripts'] = $this->document->getScripts('header');

Это метод класса Document, он же имеет и метод добавления своих скриптов, которые добавляются в том или ином контроллере (это помимо явно прописанных в шаблонах):

$this->document->addScript(путь->имя скрипта, куда помещать, по умолчанию в шапку);

Их и собирает метод getScripts, а то что вы делаете, это явно прописанные, только чтобы их кто-то не снес, это надо делать через модификатор.

Почитайте описание процесса загрузки приложения, о том как подключать свои скрипты/стили там где они нужны, и куда.

И всё таки, после того, как возьму проект на поддержку, я всё перепишу как полагается. Убью пару тройку дней, но сделаю.

А каков вообще порядок редактирования php-скриптов? Используя сразу файл модификатора, особо не натестируешься. При разработке правишь исходник, потом возвращаешь забэкапенный, сравниваешь и составляешь таким образом модификатор?

Все, тогда уж свой движок писать используя какой либо фреймворк.

Порядок по приоритету, не станете же вы первым делом править шаблон, если контроллер не отдает ему данные необходимые, и изменять контроллер если модель не обладает нужными методами. А вот способ обычный - берется исходный файл, если он изменен ранее и кеширован, значит из кеша и дополняем/изменяем и т.п. его код. А после отладки изменения/дополнения описываем в модификаторе, удалив все свои правки из исходника. После применения модификатора они будет вставлены в файл.

Блин, с другого устройства написал, а там под другим авторизованным акком оказался )) Офигеть. Я про него и забыл.

Это козе понятно. Я уже делал там правки.

Ну я про это и писал. Т.е. правим исходник, тестируем, затем возвращаем оригинал и описываем модификатор. Всё верно.

Так это один и тот же "фраер". :D А я второму отвечал.

В случае если "тренируемся" на модифицированном, то можно и не убирать правки, модификатор все равно перезапишет.

Написал админу, пусть разрулит )


Блин запутали. Оригинал то надо возвращать назад, описать изменения в модификаторе которые и будут применены, так?

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

А если вы модифицируете еще "девственный" оригинал, то работает он, а значит правки свои для отладки вам нужно вставлять в него, а перед модификаций удалять их.

Хотел добавить немного анимации к категориям каталога. Подключаю библиотеку animate.css, в шаблоне прописываю так:

{% for category in categories %}
        {% if category.children %}
        <li class="dropdown"><a href="{{ category.href }}" class="dropdown-toggle animated bounceInRight delay-{{ loop.index }}s" data-toggle="dropdown">{{ loop.index }}) {{ category.name }}</a>

etc...

Не понимаю, почему последний элемент выводится первым? При инспектировании всё чётко: 1, 2, 3, 4, 5, 6. А шестой какого-то хрена появляется первым. У всех категорий есть дети. Что за фигня?

Мне трудно судить по представленному что выводится и почему не так как хочется.

Прописал

delay-{{ loop.index - 1 }}s

и заработало в нужном порядке. Почему - не понимаю.

Для милисекунд похоже нужно писать в css отдельные валидные классы, подогнанные под модифицированный индекс цикла. Слишком много чести. Обойдутся без анимации )

Задержка в анимации должна плясать от индекса массива (delay-0s, delay-1s, delay-2s и т.д.) Но пляшет как-то странно.

Что к чему и что за такая странная библиотека (и откуда она вообще могла появиться) animate.css. :)

Библиотека, в среде программирования, а не здания с манускриптами, это сборник подпрограмм или объектов. Среди платформ можно отметить их как с расширением .so, .dylib, .library, .dll, а среды разработки как .h, .asm и т.п.

Библиотеки могут быть статическими - файлы с исходным кодом или объектные файлы вставляемые в программу на этапе компоновки, и динамические - загружаемые либо при создании процесса, либо по запросу уже работающего процесса.

А CSS - это каскадные таблицы стилей, и коли это файл, то подключаемая. Можно конечно говорить о библиотеке, которая занимается стилями оформления темы/элементов приложения, но в среде системного программирования это ни как не .css будет. А в среде html, просто файл, набор файлов. :)

CSS3 настолько мощная штука, что некоторые неправильно называют такие вещи как animate.css библиотеками, а я взял и повторил это.

Ну если таким образом трактовать, то и табурет вполне можно называть столом. :) Это как с чей-то легкой руки назвали обычный слой ранжируемый поверх всех с затенением остального и прочей хренью модальным окном, что к окну, а тем более модальному диалогу, не имеет вообще никакого отношения. И бывают и путаницы из-за такой вольности, когда "а" и "в" не понимают друг друга во время диалога. В JS есть три модальных диалога - alert, confirm и promt, плюс в IE существуют еще два - showModalDialog и showModelessDialog, все остальное чушь полнейшая, как бы их кто-то не называл, хоть супер модальные, от этого они ими не станут. Более близкое по смыслу к библиотеке, это набор js-функций и т.п. подключаемых, а css, это правила стилей, равно как, например, в подключаемом json описание опций, конфигураций и пр.

В скриптовых языках к библиотекам "прижился" термин модули, а в РНР их называют расширениями, хотя это чистой воды библотеки написанные на С, Delphi и прочих. Для Win платформы они имеют расширения .dll, для Unix .so. Те что прописаны в php.ini загружаются в процессе сборки, но можно вызвать и динамически функцией dl().

Эти штатные модальные окна настолько убогие, что приходится писать свои "ранжируемые поверх всех с затенением остального". Поэтому и стали их так называть. Я бы назвал такой слой аля-модальное окно ))

Убогие или нет, но свою задачу они выполняют на все 100, а "аля-модальное", даже и на аля не тянет. Вот вам диалоги не убогие, это практически полноценные приложения, с гораздо большими возможностями чем confirm и promt. Как видите во всех браузерах открывается, но все это симуляция кроме в IE. Откройте эту ссылку в IE и посмотрите, чувствуется разница.

Ясен хрен.

The user cannot switch to the opener window until the modal dialog is closed.

Вот поэтому не тянут.

Здрастье, это как раз одна из задач модального диалога, а всякие аля этого просто не могу сделать, обойти эту "аля модальность" как два пальца ...

Вы можете в Chrome DevTools выбрать на сайте нужный элемент и увидеть всю цепочку наследовании CSS. И можете менять стили элемента «вживую»! Рабочие пространства Chrome DevTools позволяют вам сохранить изменения в файле на сайте, внесенные вами в Devtools, в локальную копию того же файла на вашем компьютере. Например, предположим:

• У вас есть исходный код вашего opencart проекта на рабочем столе.
• Вы используете локальный веб-сервер (корень сайта — каталог исходного кода), так что ваш сайт доступен, например, по адресу localhost:8080.

Так что когда вы откроете localhost:8080 в Google Chrome, и вы будете использовать DevTools для изменения CSS сайта, то при включенных рабочих пространствах, изменения CSS, которые вы вносите в DevTools, сохраняются в исходном коде вашего opencart проекта. (localhost:8080 — это как пример, на самом деле может быть любой адрес)

Самый простой способ добавить папку проекта в рабочее пространство — открыть в Chrome DevTools панель Sources и перетащить туда папку. (https://youtu.be/DJfdjdlSJho?t=56)

А исходники? Хотя вы теперь знаете, что это не проблема!

Я заметил, что иногда рекомендуете устанавливать Open Server, почему не более приближённое к реальности, например, при помощи docker? (Как начать с docker? https://www.youtube.com/watch?v=VzzwnsLX_5o Краткое описание… https://habr.com/ru/post/309556/)

А с чего вы взяли, что это класс? cart — это экземпляр класса Object. Даже если написать отдельный класс Cart, то его всевозможные экземпляры будут выполнять одно и тоже.

Если вы хотите, чтобы cart был экземпляром класса Cart, то вы можете сделать так...

function Cart() {
	throw new TypeError("Illegal constructor");
}

Object.defineProperty(Cart, Symbol.hasInstance, {
	value: instance => cart === instance
});
Cart.prototype = cart;
Cart.prototype.constructor = Cart;

/* долгожданное наследование */
class SuperCart extends Cart {
	myNewMethod() {}
}

/* теперь вместо cart используйте myCart */
const myCart = Object.create(SuperCart.prototype);

// > cart instanceof Cart
// < true
// > myCart instanceof Cart
// < true
// > myCart.add
// < ƒ (product_id, quantity)

Но действительно ли вам нужен класс в данном случае? Вы исходили из ложной предпосылки, что cart — класс, а на деле это — объект типа Object.

Дело в том, что это не класс, а объект (экземпляр класса Object). Вы можете дописать в объект нужные функции и свойства...

Object.assign(cart, {
	myNewMethod: function() {}
});

Всё верно, это библиотека CSS анимации. Что может быть странного и удивительного в том, чтобы часто используемые анимации вынести в отдельную библиотеку? Вот ещё больше полезных библиотек CSS анимации — https://css-tricks.com/css-animation-libraries/

Обычные программы тоже могут быть оформлены при помощи CSS — Skype, Discord, WhatsApp, Visual Studio Code и пр. И даже операционная система — Chrome OS.

Такой вещи вообще не существует! Никто не может точно сказать и определить, что это такое! (Я спрашивал, человек, говорит — «ну там transform есть в CSS3...» смотрим в документацию — а там — CSS Transforms Module Level 1, вообще отдельный модуль!)

На самом деле уже с 2007 года существует «CSS Snapshot» (т.е. «снимок» состояния CSS) — периодически обновляемый документ (https://w3.org/TR/css), один из разделов которого называется — «Официальное определение CSS».

Модальное окно — окно, которое блокирует работу пользователя с приложением до тех пор, пока пользователь это окно не закроет.

Стоит учитывать, что showModalDialog раньше работал и в Firefox и в Chrome (Ещё работает в Safari, но планируется к удалению), но в последствии был объявлен устаревшим и удалён, поскольку существует стандартизированное и более гибкое решение, которое предоставляет спецификация HTML.

«Модальное» и «блокирующее выполнение скриптов» — это не одно и тоже. «Модальное» означает поверх всего остального, предотвращение взаимодействия с остальным. Таким образом, например, диалоги jQuery UI являются модальными, но они не блокируют выполнение скриптов.

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

Модальное диалоговое окно, созданное при помощи showModalDialog, содержит полноценный документ HTML, а не фрагмент кода. На самом деле это просто два совершенно разных окна, взаимодействующих друг с другом. Но в основном это просто добавляет ненужную сложность, усложняет реализацию браузера и вносит ряд ошибок.

Хотя важно, чтобы модальные диалоги не позволяли пользователю взаимодействовать с исходным окном, нет никаких причин, по которым ему нельзя разрешать взаимодействовать с другими вкладками или встроенными элементами управления браузера (назад/вперёд, избранное, адресная строка и пр.)

Что использовать взамен? Спецификация HTML 5.3 представляет элемент <dialog>, который используется для отображения диалогов, включая модальные.

Элемент <dialog> представляет часть приложения, с которой пользователь может взаимодействовать, чтобы выполнить определённую задачу — диалоговое окно.

На данный момент диалоговые окна полностью поддерживаются в Chrome и Opera, в Firefox — частичная поддержка под флагом, а остальные — нет (решается при помощи полифила, но что тебе стоит потребовать у разработчиков твоего любимого браузера все доделать?)

<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<!-- polyfill -->
	<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/dialog-polyfill/0.5.0/dialog-polyfill.min.css">
	<script src="https://cdnjs.cloudflare.com/ajax/libs/dialog-polyfill/0.5.0/dialog-polyfill.min.js"></script>
	<script>
if("showModal" in document.createElement('dialog') === false)
new MutationObserver(function(mutationsList, observer) {
	mutationsList.forEach(function(mutation) {
		mutation.addedNodes.forEach(function(node) {
			if(node.tagName === "DIALOG" && "showModal" in dialog === false)
				dialogPolyfill.registerDialog(node);
		});
	});
}).observe(document.documentElement, { childList: true, subtree: true });
	</script>
	<!-- end of polyfill -->
</head>
<body>
	<button id="button">open modal dialog</button>
	<dialog id="dialog">
 		<form method="dialog">
 			<h1>Hi!</h1>
			<p>I am a modal dialog.</p>
			<button>Close me</button>
		</form>
	</dialog>
	<script>
		button.addEventListener("click", event => {
			dialog.showModal();
		});
	</script>
</body>
</html>

Malleys, скучно? :)

Долго объяснять, да и проблем передать на сервер и там развернуть нет, хоть и под умершим Денвером делать.

В opencart нет никакого класса cart на клиенте, там всего лишь несколько $.ajax запросов, реализация же ее на сервере.

За модальное окно, спасибо конечно, но оно мне ... ей богу, без обиды, мне даже прочесть это некогда, тут без них проблем своих хватает. :)

Malleys, я потом, как освобожусь, почитаю чего там вместо модального. ;)

Почему showModalDialog плох как и другое от мелксофта, это известная притча во языцех, только ленивый об этом еще не сказал. :)

Вообще-то, showModalDialog как и другие модальные диалоги, окна, это дочерние приложения родительского приложения, дочерние формы MDI, которым можно задать различные стили как-то размеры управляемые или нет, только рамка или с заголовком с кнопками и меню, и т.п.

А вот <dialog>, это интересно.

Дело не в Microsoft... ...а в том, что то, что ты описываешь, подходит под ОС Windows. А кто подумает об iOS, Android и др. ОС? Вот с функцией open нет проблем, поскольку не требуется модальность, а соответственно можно открыть вкладку, или в той же вкладке, добавив вхождение в историю.

Мне глубоко наплевать на iOS, Android. О showModalDialog и showModelessDialog речь шла как о детище IE, которого на iOS и Android просто не существует. Следовательно и ОС подразумевается MS Windows, другую подразумевать было бы глупо, от этого и дело как раз в мелкософт. В контексте ее все - alert, confirm, promt, showModelessDialog и showModalDialog, как окна, это не порождение браузера, это именно системные окна MDI приложения (дочерние приложения), коим в данном случае является браузер. Браузер только определяет содержимое этих приложений. Последний, кстати, например в Delphi открывается одноименным методом - showModalDialog.

Я вас зачастую не понимаю, то-ли вы любите просто попи....., то-ли пофилософствовать, то-ли еще чего-то мне непонятного. :)

Ну и замечательно! Значит они не нужны. (Учитывая то, что они удалены из Chrome и Firefox)

Не стоит забывать, что HTML, CSS и JavaScript должны быть всё-таки кроссбраузерными и кроссплатформенными.

Какая философия? Элемент <dialog> реально работает и его можно использовать в реальных проектах уже сейчас (в Google даже написали качественный полифил), а то что вы предлагаете, легко обходится, от него давно отказались и придумали другое решение!

Кроссбраузерно и кроссплатформенно вы можете вызывать только диалог “Open File” и “Color” (в Windows они выглядят так — https://docs.microsoft.com/en-us/win...win-common-dlg)

Я нисколько не сомневаюсь, что в операционной системе, которая называется Windows, можно открыть сотни окон, вопрос в том, насколько удобно таким пользоваться. Я считаю такое совершенно ужасным UX, когда на каждое действие открывается по окну, и у тебя нет выбора. Рабочее пространство следует держать более организованным — для этого есть, например, вкладки!

Я совершенно не вижу интересных случаев, когда нужно было бы отдельное модальное окно, которое должно открываться как отдельный процесс! Это усложнение! Это раздражает пользователей, когда открываются окна, а тут ещё блокирующее! Ужасное непонимание UI и UX!

Вы можете посмотреть, какие компоненты используются для современных приложении (я думаю, ты найдешь для себя много интересного)

• https://developer.apple.com/design/h...erview/themes/
• https://developer.android.com/design

А если серьёзно, то ты можешь использовать, например, React компоненты для быстрой и легкой веб-разработки — React Material UI

Диванный теоретик?

И кто с этим спорит? Но любой язык имеет свою реализацию под конкретную платформу, учитывая ее особенности. А хреновая платформа или ОС, если она ничего не предоставляет разработчику и ему нужно все делать с нуля. В iOS такого конечно быть не может, в ней приложения так же имеют стили/управление определенное ОС. А Android, это даже не полуось, которой называли былую OS/2, а все-таки поскромнее, у нее другие задачи и фишки, но у нее тоже определения и соглашения, которыми руководствуется разработчик, иначе бы, в первую очередь, страдали бы пользователи.

Табуреточный.

Ты! Тебе как веб-разработчику вообще не нужно знать, какая это ОС!

Охренеть и не встать, как говорится. Я вообще-то в веб пришел из системного программирования, а также программирования микроконтроллеров, чем хоть и изредка, но и теперь занимаюсь, уже для своих потребностей. И совсем не намерен это забывать. А тема, с которой вы начали очередной свой сыр бор, за исключением <dialog>, о чем только и надо было заметить, как раз и касалась конкретной ОС, в противном случае она была бы ни о чем.

С вами вести диалог, это как воду через сито лить. :) Я все сказал.

Особенно сидя зимой в морозильнике!

Вообще-то человек упомянул про модальные диалоги, а ты решил, что самыми настоящими могут быть только могут быть только от Microsoft, а остальное — «а-ля модальное, и даже на модальное не тянет»!

«Модальное» означает поверх всего остального, предотвращение взаимодействия с остальным. Так что самое ужасное <div class="жукверно__и--модально"> тоже является модальным окном, если оно соответствует определению!

Я это прекрасно и без вас знаю, тем более учитывая то, что это я знаю из системного программирования, а не как вы из JS.

Это ваше больное воображение, я же их упомянул потому, как у IE их на два больше, о них и рассказывал и давал ссылку на пример. Хватить мне лапшу на уши вешать.

Вон проверь, сам написал... То, что ты показывал, я узнал в Java — JFrame. А в JS о таком не возможно узнать в силу того, что таких окон тут попросту нет! (Я не имею в виду внедрить HTML)

Что, не получается линейная интерполяция? Т. е. ты выделяешь прямоугольник, и он в SVG рисуется не там где выделение?

Не в интерполяции дело, да и к данной теме это не имеет отношения.