Как стать автором
Обновить

Комментарии 38

Как-то у меня практически сразу «всё пропало».
Заголовок спойлера
image

Вообще конечно автоматизация вёрстки — задача нужная и правильная, но в современных браузерах столько нюансов и ограничений, что покрыть в любом случае удастся только самые базовые случаи. В лучшем случае будут покрыты ещё и базовые случаи «резиновой вёрстки». Всякие сложные ситуации, типа «мы хотим вставить в контейнер несколько контейнеров разной ширины, которые должны идти в ряд, и при этом основной контейнер расширяется не более какой-то ширины, а дальше внутренние контейнеры переходят на следующий ряд» автоматизировать не удастся (хотя бы потому, что одним css тут не обойтись). Я и словами-то это с трудом сформулировал.
Да, согласен, есть много случаев, которые не относятся к просто технической задачи построения дерева. Как раз их вот и стоит оставить для работы специалисту. В рамках исследований буду по максимуму стараться сократить рутину.

В концепте очень мало уделил внимание перекрытию, особенно двойному, от сюда и подобный не очень качественный результат. С другой стороны я ещё и усложнил себе задачу, так как совсем не пользовался в концепте информацией о порядке элементов).
Поиграйтесь с Figma — там уже недолго до автоматической выгрузки вёрстки осталось. По моим ощущениям, из критичного только брекпоинтов не хватает. Народ уже во всю пишет плагины для выгрузки шаблонов в React / Angular
Да, я вот тоже уже как 2 года жду рабочего плагина, как api открыли, но вот что-то всё не то, да не то...(
Поддержу предыдущего оратора:
Давным-давно, когда 16 МБ (мегабайт) оперативной памяти стоили ~600 $US...”™
Одной из первых областей, куда была приложена компютеризация стало т.н. «наcтольное издательство» (DTP – desktop publishing) и в первую очередь именно вёрстка.

Не это вот, богомерзкое в web, которое вы сейчас тоже обзываете вёрсткой, а классическая размещение текста и иллюстраций по законам типографики.

И были попытки создать программные комплексы, способные, на лету, абсолютно “резиново” переверстать исходник под требуемый формат печати, да так, чтобы не требовалось проверять результат и заниматься ручной правкой…

Не взлетело.

Хотя бы потому, что законы конкретного языка требовали различных подходов к реализации, хотя в демонстрашках всё выглядело более-менее, но в реальной эксплуатации – увы!
Не взлетело

Взлетело. Но в одном сегменте — в рекламных каталогах и газетах. Которые с размаху прибил как раз web.
Глаза боятся, а руки делают). Но я конечно не стараюсь сформулировать серебрённую пулю, которая всё за меня сделает. Нет, только инструмент, который позволит упростить хотя бы 80% кейсов. И думаю, нам немного больше повезло. В отличие от издательского дела, любой инженер, который занимается созданием интерфейсов, сможет на низком уровне его доработать.

Я б сказал, рассчитывать можно процентов на 30. Когда начнёте добавлять обработку пограничных случаев (в погоне хотя бы за 60%) начнётся такая нечеловеческая каша, которую ещё Dreamweaver/Word выдавали на выходе после wysiwyg редактирования.


Если говорить не о научной работе, а о продукте, то даже не то чтобы можно, но стоит рассчитывать на 30%. Типа вот продукт, он вам выплюнет на выходе валидную семантическую расширяемую вёрстку для лендинга.
Но таких продуктов вроде и так достаточно, по причине однообразности лендингов. Добавить хидер, три колонки, слайдер, картинка-текст блок, футер — лендинг готов.


А обрабатывать все возможные перекрытия… Ну так этим сейчас и браузеры занимаются уже много лет, и до сих пор баги вылазят. Но как научная работа без особой цели и конца — наверное почему бы и нет.

Да и 30% уже не плохо.
Если это перевести на деньги, да в мировом масштабе, то получиться очень существенная экономия.

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

Вопрос в другом, почему они не известны и не пользуются популярностью?

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


В общем, как по мне, сфера применения прослеживается слабо. Для лендингов полно генераторов. Для чего посложнее — всё-равно нужно ручками писать, проще это делать сразу. Тут нужно найти нишу, а её я не вижу.

По всей видимости мы с Вами сталкивались с различными задачами в своей проф. деятельности. Если не секрет, какая у Вас профессия? Данная информация для меня будет полезна, когда буду более тщательно продумывать область применения.

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

web-фуллстек я. Хотя больше работал с фронтэндом, конечно. Застал dreamweaver ещё когда он был от Макромедии, и уже тогда не особо ценился за тот мусор, который выплёвывал (может с тех пор что-то изменилось, давно его не тыкал). Последние года 4 работаю над крупными веб-приложениями (это которые разрастаются настолько, что сайтами уже не назовёшь). Сейчас, навскидку, страницы целиком добавляются редко, больше задач на изменить что-то в готовом функционале. Прикрутить Вашу идею, даже покрывающую 80% кейсов мне лично не представляется ни возможным ни целесообразным.
Для небольших студийных проектов — может быть, но… Тут мне сложно сказать. Обычно это или одностраничные лендинги, или магазины. И то и то чаще генерируется, берётся какой-нибудь вордпресс/джумла/e-commerce CMS, ещё что-то такое, готовые шаблоны и, при необходимости, правятся.

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

Конечно. Но от проекта к проекту, от команды к команды всё очень сильно разное. Технологии, год, когда изначально проект был разработан (когда самый продвинутый был, например, бекбон. Переписывать на реакт? Это банально дорого).


Неужели никогда не хотелось просто взять и подвигать элемент, изменяя его положение?

Честно говоря, нет. "Подвигать" можно столькими способами (и косвенно меняя отступы у совершенно других элементов, и меняя глобальные стили для группы элементов, и добавляя новые по хитрому селектору), что делать это мышкой не представляется возможным. Перетягивать трёхпиксельный паддинг, даже с зумом? Уф. Проще всё-таки инспектором.


Например, поигравшись с маржингами/шрифтами/другим в инспекторе, чтобы они автоматом применились к коду?

Хром это умеет, но я этим практически не пользовался.


Или забросить компонент из библиотеки сразу на экран?

Ну вот глядя на тот же сторибук, они круто выглядят из коробки, но когда доходит до кастомизации, оказывается что нужно писать аддон, или править что-то готовое, писать фидбеки, потому что сходу нелегко разобраться в реализации, а потом таки разбираться, форкать и чинить, потому что на фидбеки не обращают внимания… Сейчас мы не используем готовые библиотеки. И я не особо хотел бы. Но, я скорее хотел бы иметь похожую обёртку-библиотеку для собственных разработанных компонентов. Своего рода UI список тех же реакт-компонент. Но это надо менять существующие подходы к разработке и форсить всех писать максимально изолированные компоненты (что, конечно, хорошо…)


Или чтобы изменения, сделанные дизайнером сразу применились к интерфейсу?

Обычно для чего-то супер-нового это да, отдельный дизайн, который потом имплементируется в коде. Правки потом редко поступают от дизайнера.
Касательно новых примерно однотипных страниц, достаточно сказать "сделай как на странице А, только вот тут нужно будет добавить другой список и сделать его скроллируемым". То есть чаще это дизайн-гайд (мы сейчас перешли на AntD), нет необходимости задизайнивать-утверждать всё страницу. Обычно дэвы сами видят, как оно должно выглядеть, и только в крайних случаях обращаются к дизайнеру.
В компаниях где много разноуровневых разработчиков, некоторым требуется чёткая постановка задачи — там да, нужна целиком задизайненная страница.


А как вы решаете вопрос со сложной анимацией?

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


В общем, подводя итог, можно взять AntD, Storybook, и скрутить из них готовый продукт. Как и из вордпресса склепать Амазон, наверное, в теории. Но мне кажется сложность разработки после некоторого порога сильно превысит сложность разработки изначально вручную. И это точно нужно делать в начале пути, закладывая риски. Я видел проекты которые переписывались с нуля через каких-то пару лет, потому что предыдущая команда использовала какой-то хитрый подход, в котором сложнее (и дороже для компании) было разобраться (Вам может показаться "вот оно, вот она, ниша, нужен стандарт, по которому можно будет брать готовый проект и передизайнивать его с минимальными вложениями в код". Но нет. Было 11 стандартов, теперь их 12. А самый стандартный стандарт — это то, что есть сейчас).
Если так подумать, браузер со всеми этими стандартами и есть воплощение того инструмента, с помощью которого можно сделать буквально что угодно, максимально гибко. Всё остальное будет абсолютно точно гораздо менее гибче.

Спасибо за столь развёрнутый ответ, конечно я по другому смотрю на ряд проблем, ввиду этого Ваше видение очень ценно и открывает для меня другой взгляд на поднятые вопросы. Что конечно и являлось одной из целей публикации данной статьи.

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

Как я понимаю, Вас вполне устраивает текущее положение дел.
LaTeX и производные, разве нет?
НедЬ.
Опираться на модульную сетку, насколько знаю, *TeX не умеет.

Например: автоматически переверстать текст из одноколоночного в многоколоночный при смене ориентации выходного документа с портретной на альбомную.
Вот когда ИИ начнет писать интересные статьи и различные книжки (детективы, фантастику, научную литературу) — вот тогда и верстка будет полностью автоматической…
А пока — это авторская работа, с кучей решений для каждого конкретного случая. Причем технологии постоянно развиваются, так что пока вы «научите» ИИ верстать так, все изменится…
Ох, боюсь всё уже изменилось. Проблема вёрстки с помощью ИИ уже решена, что я так же в статье озвучил. Не идеально, но закон Парето соблюдён.
github.com/tonybeltramelli/pix2code или habr.com/ru/post/347120, другое дело, что на мой взгляд это избыточно и что самое важное — плохо контролируемо.

Какую конкретно проблему мы решаем? Автоматизация процесса верстки? Тогда почему вся статья о создании основного макета.
Или мы хотим автоматизировать создание основного макета? Тогда это бессмысленно, учитывая, что сейчас поддержка Flexbox — 98,5%, поддержка Grid — 95% и "руками" все делается достаточно легко.

Спасибо за обратную связь, подскажите, что Вас натолкнуло на мысль, что статья о построении основного макета? Данная информация будет для меня очень полезна и смогу более чётко раскрыть мысль.
Статья поднимает проблематику современной вёрстки. Как вариант решения, я предлагаю автоматизацию и уже проблемы связанные с ней. Выделяю основную проблему и
далее описываею подход для её решения — построения всего дерева, опуская ряд крайних случаев. Так же в рамках статья я показываю, что описанный подход является работоспособным.

Конечно, если свести всю вёрстку к flexbox и grid, то в этом нет смысла. Но на мой скромный взгляд, тема немного шире, так у нас есть ещё как минимум таблицы, ну и ещё пара другая сотен сущностей с которыми приходится работать верстальщику, как шрифты или градиенты. Также жизненный цикл разметки не заканчивается после создания.

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

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

Конечно, вёрстка с абсолютным позиционированием это сразу не наш случай, для любого разработчика это богомерзкое решение). Собственно об этом я писал в части про «показателями качества для разработчиков».
Для того чтобы автоматизировать «сложные с точки зрения дизайна и человеческой логики макеты» нужно более подробно раскрыть тему, формализовать и классифицировать задачи.
Ну и конечно, не стоит стараться достигнуть 100% не участия человека, я думаю это в корни не верный подход.
Как раз для этого и считаю следующий шаг важным — двухсторонняя связь между кодом и графическим отображением. Доказав эти два концепта далее можно уже прорабатывать полее специальные и сложные случаи.
В меня сейчас начнут кидаться помидорами, но я напишу 2 страшных символа: 1С

Начиная с 8.2 там появились управляемые формы, где невозможно просто взять «кинуть кнопку на форму», надо обязательно указать ей, в каком блоке она будет, как этот блок будет себя вести при растягивании/сжимании и т.п В итоге получается вёрстка, похожая на последнюю картинку в посте: всё поделено на функциональные блоки и подстраивается под экран. Причём всё это делается (прости, Господи) мышкой, без программирования стилей.

Форма выглядит как дерево объектов с заданным поведением.

Я на карантине собрался сделать простенькую игрушку с фронтом на JS, попытался найти похожий визуальный редактор и с удивлением обнаружил, что ничего подобного просто нет. Пришлось разбираться с React и кодить каждый компонент формы. И я до сих пор не понимаю, почему не появилось никакого средства визуального проектирования, чтобы на выходе был html с дивами и css

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

Да полно их. Вон, дедушка Dreamweaver ещё жив: https://www.adobe.com/products/dreamweaver.html


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


Пришлось разбираться с React и кодить каждый компонент формы. И я до сих пор не понимаю, почему не появилось никакого средства визуального проектирования, чтобы на выходе был html с дивами и css

Как-то непонятно, таки нужен React на выходе или html+css? Если последнее — зачем разбираться в Реакте?

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

Собственно, изначально в голове была такая идея: сделать каким-нибудь инструментом вёрстку, а потом нагрузить ее каким-нибудь модным JS-фреймворком. Ну и когда выяснилось, что с первым пунктом не получается, перестроился на React.

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

Всем привет! А как протестить функционал?)
Добрый день!
Подскажите, какие возникли проблемы с тестированием?
Я перешел по ссылке, drag&drop-ом перетаскиваю файл, но ни чего не происходит. Или, возможно, я не правильно понял как использовать).

По сути это будет ещё один уровень абстракции. Где для того чтобы сделать что-то более или менее не стандартное придётся курить новую технологию. Вместо верстальщика будет p2c-верстальщик. Мир фронтенда уже ждёт с распростертыми обьятиями очередную мандулу.

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

Для этого я описал в 2-х словах, что для меня есть идеальный варианты и постарался определить важные критерии вёрстки.
Есть ли у Вас мысли, чтобы можно ещё добаить или изменить?
вы хотите создать очередной костыль к имеющимся технологиям (в которых за 30 лет скопилось слишком много костылей), об этом подробно рассказывалось в статье Кто похоронит современный веб?
Давно пора кому-то в этом мире сделать всего две программки — «Браузер 2.0» и «Сервер 2.0».
Обе на базе подходящего графического движка с продвинутым 2D и 3D.
В программе «Сервер 2.0» создаёшь сайт или интернет-сервис, всё визуально (WYSWYG, как в Дельфи например) с добавкой скриптов на привычных языках и, при необходимости, с взаимодействием с вашими программами написанными на других языках (которые уже откомпилированы и запущены параллельно).
А в программе «Браузер 2.0» (которую будут запускать пользователи) можно будет открывать эти сайты. У таких сайтов будет свой удобный формат, избавленный от костылей накопившихся в HTML за последние 30 лет.
Нет, я хочу оптимизировать свой рабочий процесс.
У меня есть абсолютно точный запросы и желание проверить гипотезу. Зачем кому-то про это сообщать? Почему бы и нет.
Пользы от этой публикации я получил уже неоценимо много.
Я так понимаю верстки вы вообще никогда не видели. Если не согласны, скину пару тройку стоней макетов. Ваша «концепция» поделка и 10% не покрывает. Бутстрап и то повеселей будет.
Вы абсолютно правы, и вообще я работаю ловцом жемчуга и никакого отношения к поднятой проблематики не имею ;).
как это автоматизировать? --width: calc((570px — 168vw) / -0.55); все значения выбраны на глаз под конкретное разрешение под конкретный блок.
Хороший и интересный вопрос.
Конечно, нужно рассмотреть это случай более подробно, понять в какой ситуации мы решаем проблему именно таким образом. Так же, похоже стоит проговорить точно, я ни в коем случае не стараюсь полностью убрать вёрстку рукам, от сюда и концепция 2-х сторонней связи кода и визуального редактора. То есть если Вам нужно написать такое условие, просто напишите его, в автоматизации оно не нуждается.

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