Комментарии 38
Вообще конечно автоматизация вёрстки — задача нужная и правильная, но в современных браузерах столько нюансов и ограничений, что покрыть в любом случае удастся только самые базовые случаи. В лучшем случае будут покрыты ещё и базовые случаи «резиновой вёрстки». Всякие сложные ситуации, типа «мы хотим вставить в контейнер несколько контейнеров разной ширины, которые должны идти в ряд, и при этом основной контейнер расширяется не более какой-то ширины, а дальше внутренние контейнеры переходят на следующий ряд» автоматизировать не удастся (хотя бы потому, что одним css тут не обойтись). Я и словами-то это с трудом сформулировал.
В концепте очень мало уделил внимание перекрытию, особенно двойному, от сюда и подобный не очень качественный результат. С другой стороны я ещё и усложнил себе задачу, так как совсем не пользовался в концепте информацией о порядке элементов).
“Давным-давно, когда 16 МБ (мегабайт) оперативной памяти стоили ~600 $US...”™
Одной из первых областей, куда была приложена компютеризация стало т.н. «наcтольное издательство» (DTP – desktop publishing) и в первую очередь именно вёрстка.
Не это вот, богомерзкое в web, которое вы сейчас тоже обзываете вёрсткой, а классическая размещение текста и иллюстраций по законам типографики.
И были попытки создать программные комплексы, способные, на лету, абсолютно “резиново” переверстать исходник под требуемый формат печати, да так, чтобы не требовалось проверять результат и заниматься ручной правкой…
Не взлетело.
Хотя бы потому, что законы конкретного языка требовали различных подходов к реализации, хотя в демонстрашках всё выглядело более-менее, но в реальной эксплуатации – увы!
Не взлетело
Взлетело. Но в одном сегменте — в рекламных каталогах и газетах. Которые с размаху прибил как раз web.
Я б сказал, рассчитывать можно процентов на 30. Когда начнёте добавлять обработку пограничных случаев (в погоне хотя бы за 60%) начнётся такая нечеловеческая каша, которую ещё Dreamweaver/Word выдавали на выходе после wysiwyg редактирования.
Если говорить не о научной работе, а о продукте, то даже не то чтобы можно, но стоит рассчитывать на 30%. Типа вот продукт, он вам выплюнет на выходе валидную семантическую расширяемую вёрстку для лендинга.
Но таких продуктов вроде и так достаточно, по причине однообразности лендингов. Добавить хидер, три колонки, слайдер, картинка-текст блок, футер — лендинг готов.
А обрабатывать все возможные перекрытия… Ну так этим сейчас и браузеры занимаются уже много лет, и до сих пор баги вылазят. Но как научная работа без особой цели и конца — наверное почему бы и нет.
Если это перевести на деньги, да в мировом масштабе, то получиться очень существенная экономия.
Хотя я с Вами конечно не совсем согласен, как один из результатов этой статьи, мне удалось познакомиться с людьми, которые погружены в эту проблему довольно глубоко. Я узнал о существовании ещё большего количества решений именно по созданию разметки, которые просто поражают воображения.
Вопрос в другом, почему они не известны и не пользуются популярностью?
Потому что задачи не ставятся по принципу "наши инструмент может сделать такое", они ставятся по принципу "дизайнер нарисовал, задумал что оно будет работать именно так, надо сделать", например.
Потому что это ещё одна прослойка-чёрный-ящик. Может сработает, а может и нет. Вывод — нужен всё-равно квалифицированный верстальщик на случай если не сработает. А если нет — зачем пробовать? А если сработает — нужно перепроверять, смотреть как оно будет в разных браузерах, при разных условиях. Я, когда код пишу, уже знаю наверняка, как он будет где работать, а если готовое что-то взять — нужно разбираться в нём.
В общем, как по мне, сфера применения прослеживается слабо. Для лендингов полно генераторов. Для чего посложнее — всё-равно нужно ручками писать, проще это делать сразу. Тут нужно найти нишу, а её я не вижу.
Опять же, не со всеми Вашими утверждениями согласен, но конечно доказать что-то или переубедить Вас цели у меня нет).
web-фуллстек я. Хотя больше работал с фронтэндом, конечно. Застал dreamweaver ещё когда он был от Макромедии, и уже тогда не особо ценился за тот мусор, который выплёвывал (может с тех пор что-то изменилось, давно его не тыкал). Последние года 4 работаю над крупными веб-приложениями (это которые разрастаются настолько, что сайтами уже не назовёшь). Сейчас, навскидку, страницы целиком добавляются редко, больше задач на изменить что-то в готовом функционале. Прикрутить Вашу идею, даже покрывающую 80% кейсов мне лично не представляется ни возможным ни целесообразным.
Для небольших студийных проектов — может быть, но… Тут мне сложно сказать. Обычно это или одностраничные лендинги, или магазины. И то и то чаще генерируется, берётся какой-нибудь вордпресс/джумла/e-commerce CMS, ещё что-то такое, готовые шаблоны и, при необходимости, правятся.
А не приходилось сталкиваться с тем же Storybook или аналогами?
Я это к тому, что в любом большом приложении будут и правила на структурирование кода, та же организация дизайн системы? Отделение бизнес логики от отображения и тп.
Неужели никогда не хотелось просто взять и подвигать элемент, изменяя его положение? Например, поигравшись с маржингами/шрифтами/другим в инспекторе, чтобы они автоматом применились к коду? Что-то подобное уже когда-то было кстати. Или забросить компонент из библиотеки сразу на экран? Или чтобы изменения, сделанные дизайнером сразу применились к интерфейсу? А как вы решаете вопрос со сложной анимацией?
Отделение бизнес логики от отображения и тп.
Конечно. Но от проекта к проекту, от команды к команды всё очень сильно разное. Технологии, год, когда изначально проект был разработан (когда самый продвинутый был, например, бекбон. Переписывать на реакт? Это банально дорого).
Неужели никогда не хотелось просто взять и подвигать элемент, изменяя его положение?
Честно говоря, нет. "Подвигать" можно столькими способами (и косвенно меняя отступы у совершенно других элементов, и меняя глобальные стили для группы элементов, и добавляя новые по хитрому селектору), что делать это мышкой не представляется возможным. Перетягивать трёхпиксельный паддинг, даже с зумом? Уф. Проще всё-таки инспектором.
Например, поигравшись с маржингами/шрифтами/другим в инспекторе, чтобы они автоматом применились к коду?
Хром это умеет, но я этим практически не пользовался.
Или забросить компонент из библиотеки сразу на экран?
Ну вот глядя на тот же сторибук, они круто выглядят из коробки, но когда доходит до кастомизации, оказывается что нужно писать аддон, или править что-то готовое, писать фидбеки, потому что сходу нелегко разобраться в реализации, а потом таки разбираться, форкать и чинить, потому что на фидбеки не обращают внимания… Сейчас мы не используем готовые библиотеки. И я не особо хотел бы. Но, я скорее хотел бы иметь похожую обёртку-библиотеку для собственных разработанных компонентов. Своего рода UI список тех же реакт-компонент. Но это надо менять существующие подходы к разработке и форсить всех писать максимально изолированные компоненты (что, конечно, хорошо…)
Или чтобы изменения, сделанные дизайнером сразу применились к интерфейсу?
Обычно для чего-то супер-нового это да, отдельный дизайн, который потом имплементируется в коде. Правки потом редко поступают от дизайнера.
Касательно новых примерно однотипных страниц, достаточно сказать "сделай как на странице А, только вот тут нужно будет добавить другой список и сделать его скроллируемым". То есть чаще это дизайн-гайд (мы сейчас перешли на AntD), нет необходимости задизайнивать-утверждать всё страницу. Обычно дэвы сами видят, как оно должно выглядеть, и только в крайних случаях обращаются к дизайнеру.
В компаниях где много разноуровневых разработчиков, некоторым требуется чёткая постановка задачи — там да, нужна целиком задизайненная страница.
А как вы решаете вопрос со сложной анимацией?
Не понял вопрос. Ну как, решаем :) Сложная анимация редко только html-css-ная проблема, вступают в силу дополнительные обработки кодом, правила взаимодействия, исключения, оптимизации производительности, инициализации/сборка мусора, вынесение на более глобальный уровень и переиспользование, если большие структуры, а оно нужно внутри сотен под-компонент.
В общем, подводя итог, можно взять AntD, Storybook, и скрутить из них готовый продукт. Как и из вордпресса склепать Амазон, наверное, в теории. Но мне кажется сложность разработки после некоторого порога сильно превысит сложность разработки изначально вручную. И это точно нужно делать в начале пути, закладывая риски. Я видел проекты которые переписывались с нуля через каких-то пару лет, потому что предыдущая команда использовала какой-то хитрый подход, в котором сложнее (и дороже для компании) было разобраться (Вам может показаться "вот оно, вот она, ниша, нужен стандарт, по которому можно будет брать готовый проект и передизайнивать его с минимальными вложениями в код". Но нет. Было 11 стандартов, теперь их 12. А самый стандартный стандарт — это то, что есть сейчас).
Если так подумать, браузер со всеми этими стандартами и есть воплощение того инструмента, с помощью которого можно сделать буквально что угодно, максимально гибко. Всё остальное будет абсолютно точно гораздо менее гибче.
Но как бы там ни было, лично для себя я вижу ряд проблем в создании интерфейсов, а как следствие, и приложений. Мои исследования направлены на их формализацию и поиска решений. И если это мне поможет хоть сколько ускорить и оптимизировать мой рабочий процесс, то это уже будет победа.
Как я понимаю, Вас вполне устраивает текущее положение дел.
А пока — это авторская работа, с кучей решений для каждого конкретного случая. Причем технологии постоянно развиваются, так что пока вы «научите» ИИ верстать так, все изменится…
github.com/tonybeltramelli/pix2code или habr.com/ru/post/347120, другое дело, что на мой взгляд это избыточно и что самое важное — плохо контролируемо.
Какую конкретно проблему мы решаем? Автоматизация процесса верстки? Тогда почему вся статья о создании основного макета.
Или мы хотим автоматизировать создание основного макета? Тогда это бессмысленно, учитывая, что сейчас поддержка Flexbox — 98,5%, поддержка Grid — 95% и "руками" все делается достаточно легко.
Статья поднимает проблематику современной вёрстки. Как вариант решения, я предлагаю автоматизацию и уже проблемы связанные с ней. Выделяю основную проблему и
далее описываею подход для её решения — построения всего дерева, опуская ряд крайних случаев. Так же в рамках статья я показываю, что описанный подход является работоспособным.
Конечно, если свести всю вёрстку к flexbox и grid, то в этом нет смысла. Но на мой скромный взгляд, тема немного шире, так у нас есть ещё как минимум таблицы, ну и ещё пара другая сотен сущностей с которыми приходится работать верстальщику, как шрифты или градиенты. Также жизненный цикл разметки не заканчивается после создания.
Но конечно я не претендую на истину в финальной инстанции и каждый сам волен для себя решать, что для него является бессмысленным, а что нет.
Двумя руками за автоматизацию, но как вы автоматизируете сложные с точки зрения дизайна и человеческой логики макеты? Варианты с абсолютным позиционированием всего и вся уже существуют, и они по очевидным причинам никуда не годятся. Если же это попытка автоматизировать сверх простой для реализации макет, то это тоже не имеет смысла, простой макет делается быстро и без каких-либо трудностей
Для того чтобы автоматизировать «сложные с точки зрения дизайна и человеческой логики макеты» нужно более подробно раскрыть тему, формализовать и классифицировать задачи.
Ну и конечно, не стоит стараться достигнуть 100% не участия человека, я думаю это в корни не верный подход.
Как раз для этого и считаю следующий шаг важным — двухсторонняя связь между кодом и графическим отображением. Доказав эти два концепта далее можно уже прорабатывать полее специальные и сложные случаи.
Начиная с 8.2 там появились управляемые формы, где невозможно просто взять «кинуть кнопку на форму», надо обязательно указать ей, в каком блоке она будет, как этот блок будет себя вести при растягивании/сжимании и т.п В итоге получается вёрстка, похожая на последнюю картинку в посте: всё поделено на функциональные блоки и подстраивается под экран. Причём всё это делается (прости, Господи) мышкой, без программирования стилей.
Форма выглядит как дерево объектов с заданным поведением.
Я на карантине собрался сделать простенькую игрушку с фронтом на JS, попытался найти похожий визуальный редактор и с удивлением обнаружил, что ничего подобного просто нет. Пришлось разбираться с React и кодить каждый компонент формы. И я до сих пор не понимаю, почему не появилось никакого средства визуального проектирования, чтобы на выходе был html с дивами и css
попытался найти похожий визуальный редактор и с удивлением обнаружил, что ничего подобного просто нет
Да полно их. Вон, дедушка Dreamweaver ещё жив: https://www.adobe.com/products/dreamweaver.html
Так чтоб перетягивать все возможные блоки из списка — может быть и нет, потому что для каждого блока можно указать сотни настроек не только отображения, но и поведения и взаимодействия с другими блоками.
Для статических форм со скриншота вариантов полно.
Пришлось разбираться с React и кодить каждый компонент формы. И я до сих пор не понимаю, почему не появилось никакого средства визуального проектирования, чтобы на выходе был html с дивами и css
Как-то непонятно, таки нужен React на выходе или html+css? Если последнее — зачем разбираться в Реакте?
Собственно, изначально в голове была такая идея: сделать каким-нибудь инструментом вёрстку, а потом нагрузить ее каким-нибудь модным JS-фреймворком. Ну и когда выяснилось, что с первым пунктом не получается, перестроился на React.
По сути это будет ещё один уровень абстракции. Где для того чтобы сделать что-то более или менее не стандартное придётся курить новую технологию. Вместо верстальщика будет p2c-верстальщик. Мир фронтенда уже ждёт с распростертыми обьятиями очередную мандулу.
Для этого я описал в 2-х словах, что для меня есть идеальный варианты и постарался определить важные критерии вёрстки.
Есть ли у Вас мысли, чтобы можно ещё добаить или изменить?
Давно пора кому-то в этом мире сделать всего две программки — «Браузер 2.0» и «Сервер 2.0».
Обе на базе подходящего графического движка с продвинутым 2D и 3D.
В программе «Сервер 2.0» создаёшь сайт или интернет-сервис, всё визуально (WYSWYG, как в Дельфи например) с добавкой скриптов на привычных языках и, при необходимости, с взаимодействием с вашими программами написанными на других языках (которые уже откомпилированы и запущены параллельно).
А в программе «Браузер 2.0» (которую будут запускать пользователи) можно будет открывать эти сайты. У таких сайтов будет свой удобный формат, избавленный от костылей накопившихся в HTML за последние 30 лет.
Конечно, нужно рассмотреть это случай более подробно, понять в какой ситуации мы решаем проблему именно таким образом. Так же, похоже стоит проговорить точно, я ни в коем случае не стараюсь полностью убрать вёрстку рукам, от сюда и концепция 2-х сторонней связи кода и визуального редактора. То есть если Вам нужно написать такое условие, просто напишите его, в автоматизации оно не нуждается.
Но так же и саму проблему стоит рассмотреть с другого ракурса. Не стоит забывать, что calc это инструмент введённый для помощи верстальщикам, долгое время обходились без него. И большую часть задач, так же можно решить без него. Тут как раз автоматизации и поможет.
Хватит это верстать, ударим автоматизацией по макетам