Во-первых, при первом открытии документа он мог довольно длительное время рассчитывать страницы. Во-вторых, как я уже говорил, кардинальных изменений раскладки не было, поскольку в вордовских документах нет таких зависимостей между объектами, а их размеры фиксированны. В-третьих, Word мог себе позволить пересчитывать страницы в ленивом режиме по мере пролистывания (что тоже было заметно по подтормаживаниям). Отсюда и притормаживание при предпросмотре для печати, когда требуется реально рассчитать все страницы.
Объект в полиграфии подбирается не под размеры страницы, а под его читабельность. А она не зависит от размера страницы, наоборот, 14-й шрифт должен остаться 14-м шрифтом и на конверте, и на А4, и на альбомном А4.
Да, верно, но Word не делает автоматически несколько колонок для текста при переключении ориентации. А вот в браузере возможно настроить такое поведение.
Возьмите документ какой угодно сложности, перетащите в нём отступы, поля или ещё что, и он у вас на глазах мгновенно перестроится.
С точки зрения DOM даже достаточно сложные документы в Word имеют простую структуру и содержат не так много элементов. Тем не менее, даже открытие 100-страничного документа занимает значительное время для расчёта layout. В то же время на типичной веб-странице могут быть тысячи элементов.
А где-то можно увидеть, как специфицировано это «должен»? Я, например, ожидаю, что если меняю ориентацию страницы, то таблица, если она занимала всю ширину полосы (пространство между полями), то должна продолжать это делать. Если же она продолжает иметь заранее заданную ширину, то это как раз называется фиксированной вёрсткой в случае браузеров. В этом случае технически браузер мог бы не делать reflow и repaint, но он вынужден это делать для каждого элемента с респонзивно заданными размерами.
все равно пока неизвестно
Почему же неизвестно? Они не скрывают свои наработки.
Рендеринг - это же не только отрисовка, это и просчёт того, как надо рисовать.
В таком случае очевидно, что приложение, которое вынуждено делать постоянные перерасчёты при изменении размеров элементов и структуры DOM, будет работать медленнее, чем приложение, которому этого делать не нужно.
Блин. Можно, и даже несложно :) Только это будет документ, который сохраняет размеры элементов, меняя только их расположение.
Нет. Это буквально означает, что документ не респонзивный. В браузере тоже можно прибить размеры руками, и ничего разъезжаться не будет. Только это не то поведение, которое ожидается.
почему современный компьютер не в состоянии быстро отрендерить в реальном времени текст и картинки на плоской канве с наложением каких угодно мыслимых эффектов и анимаций
Так не отрисовка же тормозит. Она вполне себе шустро работает, иначе это сразу было бы заметно по дёрганиям.
разработчики браузеров их прикручивали костылями год за годом пару десятилетий
Если бы это было так, то разработчики Servo добились бы значительных улучшений в производительности, но в DOM, как я уже писал, есть особенности, которые не позволяют применять тривиальные алгоритмы.
а в базовых единицах измерения для документа. Это же не экранная вёрстка, а полиграфическая, тут свои правила
Вот в частности поэтому и нельзя сверстать в Word документ, который не разъедется при изменении размеров и ориентации страницы.
учитывая, насколько в браузере неповоротливо выполняются изменения DOM, скорее всего, нет
Так потому они и медленные, что необходимо вычислить все используемые стили, а ещё обновить «живые коллекции» элементов, что требует стандарт. Это не только про сложность вычислений, но и про потребление памяти. Чтобы сэкономить на вычислениях, можно добавить кеш, а это плюс к расходу памяти и дополнительный код для правильной инвалидации кеша.
Почему? Это делается ровным счётом так же, как и в HTML
В том и дело, что эти возможности в Word сильно ограничены: например, нельзя задать табуляцию (tab stops), ширину колонок таблицы и, если не ошибаюсь, отступы и размеры объектов в процентах от ширины экрана. Тем более, нельзя задать значения относительно размеров родительского контейнера и шрифта. Поэтому даже простую респонзивность в Word сделать не получится.
У них не было требования обеспечивать идеальную обратную совместимость любой ценой, это их софтина и их собственный формат документов.
Вот поэтому, в том числе, код Word проще, чем код браузеров.
Ну так это же просто. Правила-то сложные для запоминания человеком, со всеми их сайд-эффектами (ещё один хороший пример отстойности стандартов CSS, кстати), а для движка наоборот, они детерминированные, и применяются строго последовательно в одном и том же порядке.
Вот нет, наоборот: как раз селекторы с подобными правилами могут быть когнитивно просты для человека, но сложны в эффективной реализации для движка. Просто так их переприменять при любом изменении DOM будет невероятно затратно, поэтому, скорее всего, в браузерах реализована некоторая система реактивности для подписки селекторов на потенциально необходимые им ветви дерева и элементы.
Это зависит от того, как вы его сверстали. Сделать вёрстку HTML, которая едет при изменении размеров - тоже как два байта переслать.
Для начала, в Word практически невозможно сверстать сложный документ так, чтобы он пережил смену ориентации страницы с portrait на landscape и обратно без изменений.
Word в целом даже не гарантировал, что документ правильно откроется в следующей версии, что для веб-страниц всегда было абсолютно неприемлемо. Большое значение в веб-стандартах уделено описанию корректного поведения в разных случаях, при этом стандарты DOC и OpenXML фокусируются исключительно на описании исходных данных, а не получаемого результата.
Да, два разных стиля одновременно в Word вы к элементу не примените. Но это вот вообще ни разу не радикальное усложнение.
Даже в браузерах 25-летней давности стили применялись не по тупому списку классов, а по достаточно сложным правилам, описываемым комбинацией нетривиальных селекторов, включая, например, *, :not, :nth-child, + и так далее. Браузеру необходимо сначала вычислить, какие именно стили необходимо применить к документу, а это как раз и есть радикальное усложнение задачи.
Опять же таки, там как минимум, это работает.
Так можно прийти к тому, что Paint и Photoshop — продукты одного класса сложности :)
Я всего лишь утверждаю, что это продукты примерно одного уровня сложности
А я последовательно обосновываю, что это не так, и браузеры даже 25 лет назад были сложнее.
Вы можете как угодно менять размеры рабочей области мышкой, и Word
...перекосит к чертям всё оформление. Это известно любому, кто пытался сверстать большой сложный документ в Word.
есть каскадные стили, применяющиеся к любому элементу
Они могут только наследоваться, а это довольно тривиально. В браузере же на любой элемент можно наложить хоть сотни разных сложных правил, которые будут динамически применяться в зависимости от структуры DOM или действий пользователя (например, по hover).
или даже анимировать
Сложные анимации тормозили даже в предназначенном для этого Power Point, а в Word они будут ещё медленнее. Тем более, нужно будет вручную просчитывать координаты и свойства объектов для каждого кадра, а браузер умеет интерполировать свойства по ключевым кадрам.
Монголия вроде как так же отстоит от России, как и от США. И при этом ближе к Словакии и Чили, чем к России и Украине, хотя там латиница. И уж Чили явно не славянская страна.
Насколько я понимаю, все точки приводятся к двумерному пространству из многомерного соответствующим алгоритмом сжатия размерностей, а потому учёные не определяли оси сами, они получились автоматически. Можно только предположить, что ось X определяет шкалу от прогрессивных к традиционным ценностям, а ось Y, возможно, что-то вроде менталитета от иерархичности, порядка, подчинённости к самостоятельности и «раздолбайству».
Выглядит не очень просто. Получается, что даже задача по переводу первого примера на внешний стейт-менеджер в вашей библиотеке требует переписывания всего кода шаблона?
код становится проще в разы
С учётом того, что мой пример портируется на Реакт практически дословно, хоть и работает не так эффективно, ваш комментарий по поводу простоты вашего решения выглядит абсолютно нелепо.
В плане использования $ для пометки реактивных переменных — да, на Svelte, но в общем как-то больше ассоциируется с Solid.
Кажется, вы изобрели Solid.js, только со слотами
Вот вы приехали в Россию, вам приходит СМС со ссылкой. Где вы её открывать будете?
Так это ещё давным давно ввели
Во-первых, при первом открытии документа он мог довольно длительное время рассчитывать страницы. Во-вторых, как я уже говорил, кардинальных изменений раскладки не было, поскольку в вордовских документах нет таких зависимостей между объектами, а их размеры фиксированны. В-третьих, Word мог себе позволить пересчитывать страницы в ленивом режиме по мере пролистывания (что тоже было заметно по подтормаживаниям). Отсюда и притормаживание при предпросмотре для печати, когда требуется реально рассчитать все страницы.
Да, верно, но Word не делает автоматически несколько колонок для текста при переключении ориентации. А вот в браузере возможно настроить такое поведение.
С точки зрения DOM даже достаточно сложные документы в Word имеют простую структуру и содержат не так много элементов. Тем не менее, даже открытие 100-страничного документа занимает значительное время для расчёта layout. В то же время на типичной веб-странице могут быть тысячи элементов.
А это уже не так сложно: ширина таблицы задана фиксированно, включено обтекание текстом.
А где-то можно увидеть, как специфицировано это «должен»? Я, например, ожидаю, что если меняю ориентацию страницы, то таблица, если она занимала всю ширину полосы (пространство между полями), то должна продолжать это делать. Если же она продолжает иметь заранее заданную ширину, то это как раз называется фиксированной вёрсткой в случае браузеров. В этом случае технически браузер мог бы не делать reflow и repaint, но он вынужден это делать для каждого элемента с респонзивно заданными размерами.
Почему же неизвестно? Они не скрывают свои наработки.
В таком случае очевидно, что приложение, которое вынуждено делать постоянные перерасчёты при изменении размеров элементов и структуры DOM, будет работать медленнее, чем приложение, которому этого делать не нужно.
Нет. Это буквально означает, что документ не респонзивный. В браузере тоже можно прибить размеры руками, и ничего разъезжаться не будет. Только это не то поведение, которое ожидается.
Так не отрисовка же тормозит. Она вполне себе шустро работает, иначе это сразу было бы заметно по дёрганиям.
Если бы это было так, то разработчики Servo добились бы значительных улучшений в производительности, но в DOM, как я уже писал, есть особенности, которые не позволяют применять тривиальные алгоритмы.
Вот в частности поэтому и нельзя сверстать в Word документ, который не разъедется при изменении размеров и ориентации страницы.
Так потому они и медленные, что необходимо вычислить все используемые стили, а ещё обновить «живые коллекции» элементов, что требует стандарт. Это не только про сложность вычислений, но и про потребление памяти. Чтобы сэкономить на вычислениях, можно добавить кеш, а это плюс к расходу памяти и дополнительный код для правильной инвалидации кеша.
В том и дело, что эти возможности в Word сильно ограничены: например, нельзя задать табуляцию (tab stops), ширину колонок таблицы и, если не ошибаюсь, отступы и размеры объектов в процентах от ширины экрана. Тем более, нельзя задать значения относительно размеров родительского контейнера и шрифта. Поэтому даже простую респонзивность в Word сделать не получится.
Вот поэтому, в том числе, код Word проще, чем код браузеров.
Вот нет, наоборот: как раз селекторы с подобными правилами могут быть когнитивно просты для человека, но сложны в эффективной реализации для движка. Просто так их переприменять при любом изменении DOM будет невероятно затратно, поэтому, скорее всего, в браузерах реализована некоторая система реактивности для подписки селекторов на потенциально необходимые им ветви дерева и элементы.
Для начала, в Word практически невозможно сверстать сложный документ так, чтобы он пережил смену ориентации страницы с portrait на landscape и обратно без изменений.
Word в целом даже не гарантировал, что документ правильно откроется в следующей версии, что для веб-страниц всегда было абсолютно неприемлемо. Большое значение в веб-стандартах уделено описанию корректного поведения в разных случаях, при этом стандарты DOC и OpenXML фокусируются исключительно на описании исходных данных, а не получаемого результата.
Даже в браузерах 25-летней давности стили применялись не по тупому списку классов, а по достаточно сложным правилам, описываемым комбинацией нетривиальных селекторов, включая, например,
*,:not,:nth-child,+и так далее. Браузеру необходимо сначала вычислить, какие именно стили необходимо применить к документу, а это как раз и есть радикальное усложнение задачи.Так можно прийти к тому, что Paint и Photoshop — продукты одного класса сложности :)
А я последовательно обосновываю, что это не так, и браузеры даже 25 лет назад были сложнее.
...перекосит к чертям всё оформление. Это известно любому, кто пытался сверстать большой сложный документ в Word.
Они могут только наследоваться, а это довольно тривиально. В браузере же на любой элемент можно наложить хоть сотни разных сложных правил, которые будут динамически применяться в зависимости от структуры DOM или действий пользователя (например, по hover).
Сложные анимации тормозили даже в предназначенном для этого Power Point, а в Word они будут ещё медленнее. Тем более, нужно будет вручную просчитывать координаты и свойства объектов для каждого кадра, а браузер умеет интерполировать свойства по ключевым кадрам.
Неа, не умеет по-настоящему. У браузеров сложность неспроста такая.
Браузеру нужно быть интерактивным и в плане DOM, и CSSOM, и респонсивности. Это намного сложнее.
Только один стандарт HTML — примерно 900000 токенов. А ещё нужно добавить CSS и прочие стандарты.
Монголия вроде как так же отстоит от России, как и от США. И при этом ближе к Словакии и Чили, чем к России и Украине, хотя там латиница. И уж Чили явно не славянская страна.
А почему не рассмотрели JasperReports? У него даже мощный визуальный редактор есть.
Насколько я понимаю, все точки приводятся к двумерному пространству из многомерного соответствующим алгоритмом сжатия размерностей, а потому учёные не определяли оси сами, они получились автоматически. Можно только предположить, что ось X определяет шкалу от прогрессивных к традиционным ценностям, а ось Y, возможно, что-то вроде менталитета от иерархичности, порядка, подчинённости к самостоятельности и «раздолбайству».
Выглядит не очень просто. Получается, что даже задача по переводу первого примера на внешний стейт-менеджер в вашей библиотеке требует переписывания всего кода шаблона?
С учётом того, что мой пример портируется на Реакт практически дословно, хоть и работает не так эффективно, ваш комментарий по поводу простоты вашего решения выглядит абсолютно нелепо.