Как передавать проект на back end?

Question

[Alibek Kulseitov]

В общем проблема такая.
Хочу отказаться от бутстрапа но подключить его сетку к своему написанному фреймворку.
Хочу чтобы не было бутстраповских классов кроме сетки и контейнера.
Верстаю я по БЭМ.

Теперь сам вопрос: Как быть если почти каждый раз при передаче верстки на бэк-энд, программисты жалуются, что нету бутстрапа? И даже если они подключат бутстрап, то бутстрап поломает мои стили.
Например: .btn, .pagination, .breadcrumbs и тд.
Такие классы есть в бутстрапе и именно они перебьют или же добавят сверху моих стилей свои.
Сталкивались вы с этим?

Comments

[iBird Rose]

а что тебе мешает подключить весь бутсрап (а не только сетку) раз программистам он так нужен. и не использовать классы бутсрапа в своей верстке?

[Alibek Kulseitov]

iBird Rose, Мешает именно Бэм) Называться такие элементы как .btn, .pagination, .breadcrumbsочень удобно

[iBird Rose]

Алибек Кулсеитов, ну тут 2 варианта. либо ты как баран упираешься дальше, либо перестаешь называть.

[Сергей Горячев]

Алибек Кулсеитов, удобно - это твоя личная прихоть. Конфликты будут в любом случае с бутстрапом. У меня раньше была такая проблема, пока не придумал себе личные именования, по твоему примеру button, paginate, crumbs (crumbs__list, crumbs__item, crumbs__item--first), и никаких конфликтов.

[Alibek Kulseitov]

Сергей Горячев, Хорошая идея =) Но а как быть с .navbar - navbarate? или navbor))))

[Alibek Kulseitov]

iBird Rose, не могу перестать так называть так как я перфекционист

[Alibek Kulseitov]

Сергей Горячев, вернее не "удобно" а читабельно!)

[Сергей Горячев]

Алибек Кулсеитов, (с) ну тут 2 варианта. либо ты как баран упираешься дальше, либо перестаешь называть.
Третий вариант такой, переопределить нахер все стили свои с !important, чтобы бутстрап захлебнулся в попытке переписать твои стили, но это галимый пиздец, сразу говорю)

[Алексей]

Алибек Кулсеитов,
вот вы собираетесь передавать это на бекенд, а там жалуются, что нет бутстрапа. Я сам тоже бы жаловался. Вы же когда верстаете то не создаете все возможные варианты. Например, как будет выглядеть ошибка если пользователь ввел не тот логин и пароль? И программисту зная бутстрап будет очень просто добавить див с alert danger. А если бутстрапа не будет, то ему придется самому создавать какие-то классы, или прямо в теги добавлять style. И потратит он на это время куда больше времени.
Вы не представляете сколько программисту приходится допиливать после верстальщика. И с будстрапом это сделать намного проще чем без него.

[Alibek Kulseitov]

Алексей, вот-вот ) По этому и ищу решение )

[Ankhena]

Алибек Кулсеитов, называйте свои стили с префиксами ak-

Алексей, как верстальщик, договариваюсь с заказчиками, что пусть программисты ставят что хотят, просто div'ы со span'ами, нечего им делать в CSS вообще, а в конце они меня позовут и доделаю все аккуратно.

[Алексей]

Ankhena, Поверьте, если вас будут просить аккуратно что-то доделать, то вы с утра до вечера будете доделывать такие вещи. Программисту проще самому доделать, чем дать вам, и ждать пока вы доделаете, а потом продолжить дальше свою работу. Допиливать приходится достаточно часто. Я привел только один пример, но могу привести десятки примеров только с одного проекта. При верстке всевозможные варианты сразу не создать. И чаще всего это то, что текст в верстке и текст у живого сайта сильно отличается и тут начинаются проблемы, то слово слишком длинное, то оно слишком короткое. То попап не оформлен, то модальное окно не создано при верстке. А сообщения об ошибках и успехе отправки форм вообще обычно не создаются верстальщиками.

[Ankhena]

Алексей, поверю, я лет 10 так работаю. Зачем программисту чего-то ждать, мои CSS вряд ли его касаются.

А сообщения об ошибках и успехе отправки форм вообще обычно не создаются верстальщиками.

Начните с дизайнеров, так будет правильнее. А еще правильнее с ТЗ.
Стандартный верстальщик верстает только то, что есть в макетах.

[Алексей]

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

[Ankhena]

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

Вряд ли причина в том, что верстальщик не использует бутстрап.

[eRKa]

Ankhena, Вы тз когда нибудь составляли? Так чтобы положение до пикселя каждой кнопки, размер до пикселя, так чтобы цвет и размер шрифта? И так чтоб не одна страница и так чтоб с нелинейной навигацией? Это нереал учесть все. Крупные компании на тз могут потратить пол года, пока все согласуют, а потом, после верстки макета окажется что все не так как хочется и начинаются правки и хорошо если это на стадии пилота понимается. Поэтому не стоит пинать на тз, когда можно просто договориться. Из-за бзика верстальщика "мне так нравится называть и все тут" создается проблема целой цепочке. Если бэкенду нужен бустрап, дай его, а свой перфекционизм в названиях засунуть подальше.
И вообще по большому, в компаниях, ТЗ переписывается с нуля перед сдачей проекта, когда проект готов, тесты прошел, все на все посмотрели и претензий ни к кому нет.

[Ankhena]

eRKa,

и начинаются правки

еще раз: если правками дизайна и верстки занимается программист - читай выше.

[Сергей delphinpro]

Алексей,

Программисту проще самому доделать, чем дать вам, и ждать пока вы доделаете, а потом продолжить дальше свою работу.

А потом просят впилить какую-то фичу на фронт, смотришь код и ох...шь от каши, которую прогер накидал. Не лучше ли каждому заниматься своим делом, тем, что он умеет лучше всего?

Answer 1

[Андрей Ежгуров]

Если в ТЗ прописан bootstrap, то в выполненной работе должен быть именно bootstrap - и никак иначе. Если же в ТЗ такого требования нет, то какие претензии?

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

Comments

[Евгений Кузовлев]

а чем такие названия противоречат бэм?

[Андрей Ежгуров]

Евгений Кузовлев, дополнил основной ответ.

[Евгений Кузовлев]

Андрей Ежгуров, а где вы это нашли? Просто первый же блок из методологии https://ru.bem.info/methodology/css/

Нужно стараться использовать простые селекторы классов:
.button {}
.button_active {}

Answer 2

[eRKa]

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

Answer 3

[Ксения]

ну если так уж критично, подключите свои стили после бутстраповских

Answer 4

[Максим Тимофеев]

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

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