Comments 22
Может, я просто старый стал, но мне так хочется, чтобы наступил чудесный момент, когда разработчики браузеров соберутся, и разработают с нуля новую спецификацию (желательно не взяв в команду тех ребят, которые являются членами современного W3C), полностью несовместимую со старой, в которой не будет ни таблиц, ни блоков, ни флексов, ни гридов. А будет одна простенькая схема с точками привязки, режимом заполнения и режимом выравнивания. Как это делалось двадцать лет назад в десктопных приложениях. И в которой не нужно будет лепить костыли, чтобы получились одинаковые поля слева и справа, чтобы сделать колонки одинаковой высоты и т.д.
И да, ещё чтобы при манипуляциях с DOM в JS можно было использовать две простенькие функции: «BeginUpdate», «EndUpdate», которые соответственно блокируют визуальную перестройку страницы перед изменениями и применяют изменения после того, как скрипт закончил изменять DOM.
И да, ещё чтобы при манипуляциях с DOM в JS можно было использовать две простенькие функции: «BeginUpdate», «EndUpdate», которые соответственно блокируют визуальную перестройку страницы перед изменениями и применяют изменения после того, как скрипт закончил изменять DOM.
Увы, деградировать может только человеческое сознание… Поэтому не ждите невыполнимого события.
Разработчики браузеров никогда не договорятся, их сблизить можем лишь мы с вами: нужно перестать пользоваться бесперспективными творениями и они сами умрут. Тогда отпадет надобность добавлять адаптацию под них, а все силы можно будет потратить на прогресс.
С другой стороны мы с вами просто сфера обслуживания, как дворники, работники столовой или швея-мотористка: делаем все, чего захочет массовый пользователь. Раньше хватало и блокнота для создания сайта, а теперь, вот видите, Flexbox и Grid'ы…
Вижу, что перевод понравился, попробую продолжить работу в этом направлении.
Разработчики браузеров никогда не договорятся, их сблизить можем лишь мы с вами: нужно перестать пользоваться бесперспективными творениями и они сами умрут. Тогда отпадет надобность добавлять адаптацию под них, а все силы можно будет потратить на прогресс.
С другой стороны мы с вами просто сфера обслуживания, как дворники, работники столовой или швея-мотористка: делаем все, чего захочет массовый пользователь. Раньше хватало и блокнота для создания сайта, а теперь, вот видите, Flexbox и Grid'ы…
Вижу, что перевод понравился, попробую продолжить работу в этом направлении.
UFO just landed and posted this here
Действительно! Ведь насколько красивее, функциональнее и богаче были десктопные приложения 20 лет назд. Современному вебу до них еще расти и расти.
Вы зря иронизируете. Что касается красоты, десктопные приложения 20 лет назад не имели анимашечек не из-за недостатков архитектуры, а просто из-за слабости компьютеров тех лет и просто потому, что мода на это не вошла. Добавить всякие эффекты/трансформации и стили современного дизайна в библиотеки виджетов нет особой проблемы.
А что касается функциональности/насыщенности фичами, дык вы, сами того не зная, попали прям в точку — современному вебу до них ещё расти и расти. Разве может, например, Google Docs потягаться по функциональности с Microsoft Word 7 как раз двадцатилетней давности? А Gmail с Outlook, да или даже The Bat?
А что касается функциональности/насыщенности фичами, дык вы, сами того не зная, попали прям в точку — современному вебу до них ещё расти и расти. Разве может, например, Google Docs потягаться по функциональности с Microsoft Word 7 как раз двадцатилетней давности? А Gmail с Outlook, да или даже The Bat?
Не ради спора, но в качестве заметки на полях: не совсем корректно считать браузерное ПО и десктопное аналогами. Это примерно как в quake2 играть на прохождение и в мультиплеере: формально игра одна, а по сути — две разные.
MS Word 20-летней давности был заточен под глубокую работу с текстом силами одного пользователя. Поэтому основная функциональность связывалась именно с текстом. И положа руку на сердце, средний офисный клерк осваивал ее от силы процентов на двадцать, потому что для повседневной работы она была явно избыточной.
Google Docs — среда для сетевой офисной работы в условиях вездесущего интернета. Поэтому и основная функциональность крутится уже не вокруг создания текста, а вокруг его использования. Браузерное ПО это вообще не самостоятельная программа в десктопном смысле. Скорее, оболочка для работы с некоторой частью моря взаимно интегрированных сервисов, от файлохранилища, до соцсети. Концептуально другой смысл.
По особенностям интерфейсов есть ещё нюанс. Браузерное ПО сталкивается с целым рядом проблем, с которыми десктопное ПО вообще толком не имело дел. Даже простое разнообразие устройств сказывается: одно дело потянуть ширину контейнера с 640 до 800 px, другое — на лету перекомпоновать все внутренности под отображение на утюге :) Вся эргономика меняется. А есть ещё подтяжка чужого контента и др. У современного ПО вообще динамика изменений в интерфейсе выше намного. Утрирую, но просто для иллюстрации мысли: представьте себе задачу собрать интерфейс «Вконтакика» силами какого-нибудь Borland Delphi 7 :) С деталями, чтобы в реальном времени видеть как люди печатают сообщения, ставят лайки, уходят оффлайн и вот это вот всё. Дело не в красотах и анимациях. Динамика другая. «Физика» другая. Эргономика другая.
Словом, вряд ли дело вообще в ПО или в том, что раньше деревья были зеленее. Просто жизнь идёт и мир меняется.
P.S. Есть на этот счёт хорошая байка про учебник пилотов сверхзвуковых истребителей: «полет — это непрерывная цепочка неправильных решений». Со спецификацей примерно так же.
MS Word 20-летней давности был заточен под глубокую работу с текстом силами одного пользователя. Поэтому основная функциональность связывалась именно с текстом. И положа руку на сердце, средний офисный клерк осваивал ее от силы процентов на двадцать, потому что для повседневной работы она была явно избыточной.
Google Docs — среда для сетевой офисной работы в условиях вездесущего интернета. Поэтому и основная функциональность крутится уже не вокруг создания текста, а вокруг его использования. Браузерное ПО это вообще не самостоятельная программа в десктопном смысле. Скорее, оболочка для работы с некоторой частью моря взаимно интегрированных сервисов, от файлохранилища, до соцсети. Концептуально другой смысл.
По особенностям интерфейсов есть ещё нюанс. Браузерное ПО сталкивается с целым рядом проблем, с которыми десктопное ПО вообще толком не имело дел. Даже простое разнообразие устройств сказывается: одно дело потянуть ширину контейнера с 640 до 800 px, другое — на лету перекомпоновать все внутренности под отображение на утюге :) Вся эргономика меняется. А есть ещё подтяжка чужого контента и др. У современного ПО вообще динамика изменений в интерфейсе выше намного. Утрирую, но просто для иллюстрации мысли: представьте себе задачу собрать интерфейс «Вконтакика» силами какого-нибудь Borland Delphi 7 :) С деталями, чтобы в реальном времени видеть как люди печатают сообщения, ставят лайки, уходят оффлайн и вот это вот всё. Дело не в красотах и анимациях. Динамика другая. «Физика» другая. Эргономика другая.
Словом, вряд ли дело вообще в ПО или в том, что раньше деревья были зеленее. Просто жизнь идёт и мир меняется.
P.S. Есть на этот счёт хорошая байка про учебник пилотов сверхзвуковых истребителей: «полет — это непрерывная цепочка неправильных решений». Со спецификацей примерно так же.
современному вебу до них ещё расти и расти
Никому ни до кого расти не надо, каждый продукт, в свое время реализует то, что нужно его аудитории, или перестает развиваться и умирает. Gmail не конкурент Outlook в офисе, но практически никому и не нужна вся эта мощь дома, подтверждение тому — популярность Gmail.
Разве может, например, Google Docs потягаться по функциональности с Microsoft Word 7
А что скажете про Office 360?
Вообще, достаточно взглянуть на проекты вроде VSCode и Atom, чтобы перестать волноваться о том, насколько ограничена платформа.
1. Есть работающий стандарт, но с некоторыми хаками и неудобствами
2. Давайте сделаем новый стандарт с нуля, чтобы все было проще и понятнее!
3. В процессе всплывают граничные случаи и всякие неочевидности, кое-как решаются
4. Приходим в пункт 1
2. Давайте сделаем новый стандарт с нуля, чтобы все было проще и понятнее!
3. В процессе всплывают граничные случаи и всякие неочевидности, кое-как решаются
4. Приходим в пункт 1
И называется он QML
А будет одна простенькая схема с точками привязки, режимом заполнения и режимом выравнивания.
Флекс как раз и является простенькой схемой укладки. Даже еще более простой (но нисколько не менее полной), чем ваши идеалы 20-летней давности.
БегинАпдейт говорите? Это ж джаваскрипт, который без RAII, даже урезанного, вроде шарповского using или java-вого try-with-resource, одно исключение и страница зависла. Более того, это javascript, в котором всё асинхронно, и многие функции, которые могут отдать результат синхронно, сделаны асинхронными либо потому, что первый вызов требует получить какие-то данные или же просто потому, что где-то ниже по стеку необходимо (либо может понадобиться в будущем) вызвать асинхронную функцию. Ваш ЕндАпдейт либо будет выполнен через неизвестное время, либо не будет поддерживать асинхронность, т.е. будет
На самом деле пересчет и перерисовка объектов происходит лениво. Достаточно просто не спрашивать о размерах объекта в цикле обновлений. Вот пример:
var div = document.createElement('div');
document.body.appendChild(div);
// здесь нет обращения к размерам объекта в цикле
console.time('no read');
for(var i = 0; i < 1000; i++) {
div.style.width = i + 'px';
}
console.log(div.offsetWidth);
console.timeEnd('no read'); // ~3ms
// а здесь есть
console.time('read');
var savedWidth;
for(var i = 0; i < 1000; i++) {
div.style.width = i + 'px';
savedWidth = div.offsetWidth; // читаем размер элемента, вызывается перерисовка
}
console.log(savedWidth);
console.timeEnd('read'); // ~ 50msПервое демо отрабатывет быстрее, потому что не делает пересчет лейаута на каждый шаг цикла.
Хм, для меня это открытие. Я думал, что до завершения обработки текущего эвента браузер вообще не будет лэйаут трогать, поэтому beginUpdate/endUpdate, работающие только на синхронном участке, бессмысленны. Оказывается можно заставить пересчитать. Ну, в таком варианте можно придумать рабочий beginUpdate/endUpdate, если вызывается что-то библиотечное, которое внутри может лэйаут дёрнуть. Ну и естественно, чтоб по завершению обработки текущего эвента открытые beginUpdate закрывались. Хотя, с таким же успехом можно просто убрать возможность вызвать пересчёт, с современным JS с его async/await не проблема отложить получение информации до следующего эвента.
UFO just landed and posted this here
Аналогично. Уже предвкушал описание внутренних алгоритмов, а тут очередная вариация… Жаль.
Автор статьи — член группы редакторов спецификации CSS. Вот она и объясняет принципы работы элементов CSS. Да и теги, указанные внизу, ну никак не содержат даже ссылок на браузеры. Прошу извинить меня, что не оправдал ваших ожиданий.
Я тоже подумал, что статья будет о производительности flex, как там под капотом что происходит, быстрее ли reflow во flex, нежели у block, inline-block.
Вся суть в заголовке: «Что происходит при создании...» — читатель ожидает раскрытие этого процесса, а оказался очередной туториал, как работает flexbox.
Был бы рад, если бы вы перевели статью, касающуюся самых темных и неосвещенных моментах flexbox.
Спасибо за старания!
Вся суть в заголовке: «Что происходит при создании...» — читатель ожидает раскрытие этого процесса, а оказался очередной туториал, как работает flexbox.
Был бы рад, если бы вы перевели статью, касающуюся самых темных и неосвещенных моментах flexbox.
Спасибо за старания!
Режимы записиВозможно, в этом контексте лучше перевести wriring modes как «направления письма» или «направления текста».
Вы абсолютно правы, лучше эти свойства называть как 'направление письма'. Но программирование и прилегающие области знаний пришли к нам из англоязычных стран, поэтому нам только остается, для совместимости, оставить названия от первоисточника. Вот комментировать можно и по-русски
Я решил провести исследование на тему правильности названия и полазил по интернету, почитал статьи, а также спецификацию CSS, и пришел к следующему выводу.
Согласно CSS Writing Modes Level 4 свойство "writing-mode" определяет направление не только вывода текста в конкретном элементе, но и расположения самих элементов уровня блока во flex-контейнере.
Поэтому это свойство нельзя переводить как "направление текста" или "направление письма", т.к. такой перевод ОГРАНИЧИТ область действия свойства. Соответственно, т.к. мы в блок пишем (записываем) текст и выводим блоки в контейнер, то правильнее, наверно, будет "режим записи" или "режим вывода".
В спецификации Display Module Level 3 каждое значение просмотра описывается как комбинация двух элементов: внутренней и внешней модели отображения.
Каждое значение display, может быть?
Sign up to leave a comment.
Что происходит при создании контейнера Flexbox?