Комментарии 22
И да, ещё чтобы при манипуляциях с DOM в JS можно было использовать две простенькие функции: «BeginUpdate», «EndUpdate», которые соответственно блокируют визуальную перестройку страницы перед изменениями и применяют изменения после того, как скрипт закончил изменять DOM.
Разработчики браузеров никогда не договорятся, их сблизить можем лишь мы с вами: нужно перестать пользоваться бесперспективными творениями и они сами умрут. Тогда отпадет надобность добавлять адаптацию под них, а все силы можно будет потратить на прогресс.
С другой стороны мы с вами просто сфера обслуживания, как дворники, работники столовой или швея-мотористка: делаем все, чего захочет массовый пользователь. Раньше хватало и блокнота для создания сайта, а теперь, вот видите, Flexbox и Grid'ы…
Вижу, что перевод понравился, попробую продолжить работу в этом направлении.
А что касается функциональности/насыщенности фичами, дык вы, сами того не зная, попали прям в точку — современному вебу до них ещё расти и расти. Разве может, например, Google Docs потягаться по функциональности с Microsoft Word 7 как раз двадцатилетней давности? А Gmail с Outlook, да или даже The Bat?
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, чтобы перестать волноваться о том, насколько ограничена платформа.
2. Давайте сделаем новый стандарт с нуля, чтобы все было проще и понятнее!
3. В процессе всплывают граничные случаи и всякие неочевидности, кое-как решаются
4. Приходим в пункт 1
А будет одна простенькая схема с точками привязки, режимом заполнения и режимом выравнивания.
Флекс как раз и является простенькой схемой укладки. Даже еще более простой (но нисколько не менее полной), чем ваши идеалы 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
Первое демо отрабатывет быстрее, потому что не делает пересчет лейаута на каждый шаг цикла.
Вся суть в заголовке: «Что происходит при создании...» — читатель ожидает раскрытие этого процесса, а оказался очередной туториал, как работает flexbox.
Был бы рад, если бы вы перевели статью, касающуюся самых темных и неосвещенных моментах flexbox.
Спасибо за старания!
Режимы записиВозможно, в этом контексте лучше перевести wriring modes как «направления письма» или «направления текста».
Я решил провести исследование на тему правильности названия и полазил по интернету, почитал статьи, а также спецификацию CSS, и пришел к следующему выводу.
Согласно CSS Writing Modes Level 4 свойство "writing-mode" определяет направление не только вывода текста в конкретном элементе, но и расположения самих элементов уровня блока во flex-контейнере.
Поэтому это свойство нельзя переводить как "направление текста" или "направление письма", т.к. такой перевод ОГРАНИЧИТ область действия свойства. Соответственно, т.к. мы в блок пишем (записываем) текст и выводим блоки в контейнер, то правильнее, наверно, будет "режим записи" или "режим вывода".
В спецификации Display Module Level 3 каждое значение просмотра описывается как комбинация двух элементов: внутренней и внешней модели отображения.
Каждое значение display, может быть?
Что происходит при создании контейнера Flexbox?