Есть ли сервис для превращение html в краткое визуальное дерево с классами?
Ребят, подскажите пожалуйста. Есть ли плагины для текстовых редакторов, браузеров или просто сервисы/программы со следующим функционалом. Вот есть у нас верстка сайта. Её надо натянуть на cms, допустим на битрикс или вордпресс. Получается надо выделить хедер и футер. И есть ли сервис, который на основе html построит его в древовидном виде, с классами, чтобы можно было видеть саму структуру наглядно. А ещё желательно сравнивает.
Допустим, я взял верстку сайта из 10 страниц, загрузил и он для каждой построил краткое дерево и я вижу, где отличаются хедеры и другие блоки, особенно если сам сервис сравнивает и подсвечивает. Часто хедеры бывают одинаковыми, но в них различается пару классов, где-то добавляется класс page__inner--base, где-то page__inner--index. Получается сейчас надо на глаз это всё смотреть. Особенно если используют bootstrap с адаптивными классами, типа внешне два одинаковых блока, а на выходе у них такие классы: "col-md-6 col-lg-12 mb-3 mb-md-0" и "col-md-6 col-lg-12 mt-lg-3".
В результате чего приходится долго сверять верстку у каждого блока, чтобы понять есть ли разница.
Или поделитесь своим опытом, как вы натягиваете верстку в таких случаях.
Супер распространенная ошибка: Сначала сверстать как хочется, а потом "натягивать" сову на глобус верстку на CMS. Поймите, что у CMS есть своя структура html, собственные классы, определённые паттерны структуры документа. И верстать нужно именно на этой структуре. Грубо говоря, нужно сделать страницу в CMS. Наполнить её каким-то контентом, скопировать итоговый html и уже только тогда писать CSS и JS.
Alex, дело в том, что заказчики часто заказывают на фрилансе сначала просто дизайн, потом просто верстку.
- Привет, вот макет, хочу верстку
- на верстку
Потом с этой версткой в кармане ищут программиста или несут своему. Поскольку с верстальщиком они уже поссорились в этот момент или просто решили сэкономить на связи верстальщик-программер, то вот так вот и выходит.
Сама пыталась неоднократно что-то втолковывать клиентам. Не могу сказать, что безнадежны все, но многие.
sashabeep, "Настроить" то можно, но ценой большей работы на этапе интеграции, худшей совместимостью с различными плагинами и ухудшенной производительностью.
Ankhena, Оперируйте примерно такой фразой: "Натянуть случайную верстку на конкретную CMS будет стоить в 2-3 раза дороже, так как понадобится намного больше человеко-часов, в сравнении с той, что изначально создавалась для этой CMS".
sashabeep, уважаемый, есть системы, в которых вы просто не сможете часть верстки изменить, т.к. после "индусских" программистов всё связано еще и в js и залочено в бэке. Типичный пример - Sharepoint Portal года этак 2012. Отключен браузерный скролл, ужасная реализация прижатого header, везде системные id, изменение структуры просто добавляло головной боли на месяцы интеграции верстки и восстановления функционала. И таки да - вместо ul вставить nav убивало 70% функциональности навигации.
Человеческая глупость бесконечна как и вселенная. И с этим надо было как-то жить, корпоративные порталы продаваны успешно продали в топ банки, к примеру. Бизнес.
Про CMS без шаблона по умолчанию не стоит и заикаться, т.к. анархия никогда не являлась 100% доказательством отсутствия государства в иной части земного шара.
sashabeep, я не подход описываю. Это просто часть не упомянутых кейсов, в которых ваше допущение о смене тегов и производительности просто не сработает.
В остальном полностью согласен с куратором.
sashabeep, Вот вам пара частых примеров из мира WordPress.
Меню. ВП по умолчанию выводит меню в виде списка nav > ul > li > a и самостоятельно проставляет для него классы такие как current-menu-item, current-menu-parent, current-menu-ancestor, и ещё куча других, в зависимости от того что это за элемент меню и где находится пользователь.
И вот приходит верстка, где не только структура html отличается, но ещё и классы, ну скажем, по БЭМу написаны.
Тут не предусмотрен вывод под меню (потому что дизайнер не нарисовал). И если вы делаете один сайт, для одного клиента и уверены, что ему подменю никогда не понадобится — ок, у вас есть баг который никогда не всплывет. Но если вы делаете что-то чуть более гибкое — тогда вам придётся как-то изменять верстку.
И вот, мы приходим к тому, что разработчик, вместо того, чтобы вызвать одну функцию wp_nav_menu() сидит и читай заново верстает сверстанный шаблон, так, чтобы он хоть как-то был совместим с ВП. Заново пишет и заменяет встроенный в ВП модуль по генерации меню, чтобы тот возвращал верстку с правильными классами. На задачу, которая могла бы решится за 5 минут уходит от нескольких часов до целого рабочего дня.
И на выходе мы получаем меню, которое абсолютно не совместимо с потенциальными плагинами. Потому, что условный скрипт, пытаясь найти ссылку, будет искать по селектору .current-menu-item > a чего на вашем сайте нет.
Или другой пример: Виджеты.
Предположим в дизайне сайта нарисован сайтбар с одним виджетом — всё тем же меню. И оно было сверстано точно так же как в первом примере.
Тут проблем ещё больше. Начнем с того, что управлять выводом виджета вы не можете. А значит, придётся написать свой — аналогичный встроенному, но который будет выводит меню так как сделал верстальщик. Ок. Написали, сделали всё как в первом примере. Но потом, клиент захотел под виджетом меню добавить ещё один — список рубрик на сайте. Который выводится по шаблону меню ВП. Или ставит плагин и выводит виджет топ авторов на сайте. Который тоже выводится по шаблону меню ВП. Ведь все разработчики плагинов, либо предоставляют полностью свою верстку, либо опираются на встроенные в ВП классы чтобы мимикрировать под оформление темы. Но в вашем случае ни один сторонний виджет "не взлетит". Хотя они все могли нормально работать "из коробки" если бы верстка была подходящей.
И ещё пример: Комментарии. Тут всё то же самое. Вместо того, чтобы просто вызвать одну функцию и всё "просто заработало" придётся сидеть и подгонять то что выводит ВП под то, что сделал верстальщик.
Подводя итоги:
Да, изменять стандартный вывод шаблона можно, но не всегда это просто.
Для этого требуется время, и иногда не мало. А это лишние расходы для вас. Или увеличенная цена для клиента.
Это приводит к проблемам совместимости как со встроенными функциями ВП так и с функциями сторонних плагинов. И если вы не распрощались с клиентом, или думаете о своей репутации на рынке, то все эти проблемы придётся разгребать вам. См. п. 2.
sashabeep, на самом деле там битрикс, а не вордпресс. Хотя в моём понимании структура хедер, футер и тело страницы в вордпрессе и битриксе достаточно похожи.
В целом, пообсуждав с верстальщиком, мы пришли к выводу, что это дизайн такой, слишком "крутой" (замудренный), чтобы легко уложить его в понятие хедер, тело, футер. Хедер немного разный получился на некоторых страницах.
А так, либо фулстеком быть, либо описываемый инструмент выше, мне бы очень помог и ускорил)) Т.е. построил бы кликабельное дерево всех страниц красиво, без контента и урлов, чисто тег, класс, id, style и так чтобы 10+ страниц на одной и сравнивал по типу сравнителя файлов, что вы ниже кидали(пока пользуюсь подобным сравнителем, только онлайн). Тогда бы вообще всё было супер. Возможно придется самому такой сделать на будущее.
Кстати, вот на этой страничке красиво строится хтмл дерево, так что скрипт уже можно дернуть оттуда и переделать под свои нужды. https://learn.javascript.ru/dom-nodes
ни разу не встречал сервиса для кривой верстки
верстак должен знать под что он делает верстку, должен знать структуру cms, а что касается, например, битрикса, ни разу не видел отдельную верстку, которая бы легко без косяков легла бы на сайт.
ничего нет лучше фулстек разработки, когда разделяешь и делаешь все ровненько, так чтобы, в том же битриксе, при включении режима редактирования ничего не сползало. чтобы не надо было городить условий, и чтобы после изменения демо-контента не оставалось куча мусора в стилях и событиях, а сам контент отображался как и положено.
Да, согласен, хорошо быть фулстеком в данных задачах. Сам верстаешь и знаешь, что там в этой верстке, не надо её изучать и думать, как натянуть, что в хедер вынести, что в футер и т.д., чтобы не было портянки в конце работы.
sashabeep, кастомизировать можно что угодно, если знать как. А если верстаку фиолетово, куда его верстка пойдет, то далеко такой верстак не уйдет. Такому верстаку максимум на самописцы верстать, для локального использования.
Простой
Средний
Простой
