Хватит это верстать, ударим автоматизацией по макетам

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


    Интересно? Добро пожаловать под кат!



    Перед началом


    Если хочется сразу "пощупать", вот проверка концепции.


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


    Термины


    В тексте я использую термин "Верстка" в 2‑х значениях:


    1. Процесс создания разметки
    2. HTML, CSS, JS и другие документы — артефакты созданные после работы верстальщика.

    Введение


    Около 8 лет тому назад, я высказал идею, что ручная вёрстка устарела и на смену ей придёт автоматизация. С того момента я пристально слежу за попытками решить этот вопрос. У нас появились такие инструменты как Workflow, Bootstrap Studio, inVision, Framer, Supernova, React Studio и многие другие прямые или косвенные решения.


    А так же мы имеем и вовсе космические исследования этой темы при помощи нейронок, а ля pix2code или sketch2code.


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


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


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


    Проблематика


    Тут нужно сразу обговорить разницу между вёрсткой и интерфейсом:


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


    Интерфейс — полноценный артефакт системы, с которым будут взаимодействовать пользователи.


    На 2020 год ручная вёрстка всё ещё является основным способом создания web интерфейсов, что довольно любопытно само по себе. Это идёт вразрез трендам параллельных стеков, таких как нативные и десктоп приложения, где визуальные инструменты дизайна интерфейсов являются стандартом их создания.


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


    Вёрстка сложна, требует применения специальных методик и инструментов для управления, минимизации ошибок и поддержки в актуальном состоянии.


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


    Верстка это дорого, в среднем это от 25% стоимости всей системы для SPA и до 75% для посадочных страниц.


    Не существует общепринятой теории вёрстки как таковой.


    Стандарт W3C очень широкий и каждый верстальщик / команда руководствуется своими собственными правилами и стандартами, которые попадают в рамки валидной разметки.


    Решение


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


    Шаблон


    Шаг 1


    Визуально разделим на высокоуровневое дерево блоков.


    Найдём строки и колонки макета




    Шаг 2


    Семантический анализ, определим основные блоки:


    1. Шапка;
    2. Тело;
    3. Боковые панели;
    4. Подвал.


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


    И пока нам этого достаточно. Тут мы можем разделить нашу задачу на две большие группы:


    1. Техническую и
    2. Семантическую.

    Отложим семантическую группу для будущих исследований и сосредоточимся на технической.


    Несмотря на то, что вёрстка по картинке нейронной сетью задача очень интересная, по моему мнению, она избыточна.


    Сложно себе представить ситуацию, когда при нормальном рабочем процессе верстальщику придёт макет в формате растрового изображения.


    Чаще всего это форматы, созданные в таких инструментах как Figma, Sketch или Adobe Photoshop, которые в себе уже содержат практически исчерпывающую информации о макете, самое главное:


    1. Положение элементов;
    2. Тип элементов;
    3. Стили элемента.

    Получение HTML документа на основе данной информации является уже решенной проблемой, так инженеры из Figma уже поделились своей реализацией конвертации и результатами исследования, а такие сервисы как Anima прямо построены на синхронизации макетов и интерфейса.


    Но почему же подобные решения не привели к эффекту разорвавшейся бомбы и спустя 2 года нет ничего лучше старой доброй ручной вёрстки?


    Тут я повторюсь, моё мнение, причина этого два фактора:


    1. Высокие требования к качеству;
    2. Необходимость в контроле.

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


    Таким образом, первостепенным является первое требование. Но что же делает код качественным? Если убрать за скобки официальные показатели качества как LTR, Accessibility и подобное, мы останемся с важными показателями качества для разработчиков:


    1. Правильное дерево;
    2. Семантика;
    3. Отсутствие избыточности;
    4. Читаемость и редактируемость;
    5. Использование вырванных из потока блоков только там, где это нужно.

    Таким образом главной задачей для автоматизации и будет соответствие этим критериям.


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


    Строки и столбцы


    Строки


    Если позиция одного элемента попадает в отрезок высоты другого, то они образуют одну строку.



    Столбцы


    Аналогично, если позиция одного элемента попадает в отрезок ширины другого, то они образуют одну колонку.



    Отношения элементов


    Независимое расположение


    Элементы позиционируются относительно друг друга, опираясь на поток.
    Дерево достраивается при необходимости.



    Расположение с перекрытием


    Перекрывающие элементы вырываются из потока, позиционируются абсолютно, не влияют на позиционирование других элементов.



    Процесс построения дерева блоков


    Шаг 1


    Определим все строки.



    Шаг 2


    Находим отступы у каждой строки.



    Шаг 3


    Выбираем строку для проработки и определяем тип разметки:


    1. Одноколоночная
    2. Многоколоночная


    Шаг 4


    Для многоколоночной, определяем тип колонок:



    1. Плавающие
    2. Сетка

    В зависимости от типа, формируем отступы между колонками.



    Шаг 5


    Определяем тип колонки по количеству элементов в ней:


    1. Единичная
    2. Множественная

    Если тип единичный, позиционируем элемент относительно колонки, переходим к следующему.



    Шаг 6


    Для типа колонки "множественная" находим все строки
    Типы строк аналогичны типам колонок:


    1. Плавающие
    2. Сетка

    Находим отступы.
    Повторяем весь алгоритм пока есть хоть один необработанный блок.



    И теперь реализуем полученные утверждения в код.
    Упрощение:


    1. Быстрая реализация, покрывающая только ~20% случаев;
    2. Ошибки позиционирования ожидаемы;
    3. Одноуровневая структура исходных блоков;
    4. Стили записаны в атрибут style;

    Увидеть и "пощупать" доказательство концепции можно по ссылке.


    Вывод


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


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


    Что дальше?


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


    Буду рад конструктивной критике и такой же дискуссии. Всем мир!

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 38

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

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

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

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

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

        Не взлетело.

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

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

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


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


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

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

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

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

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


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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

                            Only users with full accounts can post comments. Log in, please.