klierik

По умолчанию не надо для ретины делать х2. Ползователь будет тратить в 2 раза больше трафика на графику, которая ему и не нужна. Тут надо исходить из проекта. К примеру для мобильного сайта х2 это жесткое кидалово для пользователя. Забота о весе страницы говорит о том что ресурс беспокоится о пользователеи тем самым распологает его к себе. Я уверен что юзер не будет рад открыв сайт с х2 графикой в роуминге и заплатит 10 баксов за одну страницу Но повторюсь -- все зависит от конкретного проекта. Эсли это декстоп, то там с трафиком проще.

Скажу по другому -- это мои рекомендации. Я наступил в свое время на грабли и делюсь шишками Я работал над проектом который разрабатывался несколько месяцев -- очень большой веб-магазин. И я его как раз таки написал на базе второго бутсрапа, а классы я вписывал в код. Потом я использовал другой подход, в другом проекте, о котором говорил выше. И сравнив подходы понял насколько тяжеловеснее и менее гибкий получился магазин, с точки зрения его поддержки. Если бы он был сразу описан в less, то переход на новую версию был бы прост, а так, понимая сколько шаблонов надо будет перебрать (а их огромное множество), этот этап был отложен на неопределенный срок. Если ты не допускаешь ошибок значит ты что-то делаешь не так ) Это как использовать флоты или инлайн блоки -- понимая принцип того и иного подхода, получаешь возможность смотреть на реализацию с обеих сторон, что бы выбрать лучший способ для реализации.

Я к тому что не правильно говорить человеку, который что-то пробует новое, что у него заведомо это не получится. Понравится -- попрет! Пускай каждый для себя сам решает его это или нет. Не известно в какой период жизненного пути человек себя в чем-то найдет но пробовать надо! Очень многие прийдя на этот форум в начале горели, задавали вопросы, что-то делали но потом попросту пропадали, наверно понимая что это не ихнее. И есть небольшая часть которая себя нашла и получает кайф от работы. Оно так и должно быть -- работа в удовольствие.

а потому что поддерживать и обновлять удобнее, когда все в одном месте. расскажу историю которая случилась с нами когда бутстрап перешел с версии 2 на версию 3 -- все навернулось и перестало работать. если бы я все описал в LESS, то переход занял бы существенно меньше времени. А так у меня ушло 2 недели что бы переехать но версию 3. в другой компании, на аналогичной CMS, переход занял 1,5 месяца, и они опять таки сделали тоже самое что и в первый раз -- внедрили классы в html. использование классов очень удобно для форматирование динамического контента (статей, например), но все остальное удобнее держать в одном месте. другому разработчику надо будет всего лишь открыть 1 файл и поправить значения, что бы внести изменения. в твоём случае надо будет копать шаблоны что бы внести правки.

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

Читай http://getbootstrap.com/css/#grid-less -> Example usage тут ты делаешь все правильно, особенно если ты изменяешь изменяешь дефолтные стили, соблюдая глубину как в оригинале. а при чем тут вообще реализация говно-магазина в тому что предлагает адаптив? знаешь, CSS -- очень хороший язык, но его тоже можно испоганить в реализации. что бы то ни было всегда будет отзыв За и Против. Я, кстати, тоже могу опустит вообще весь адаптив в том виде который он сейчас есть. Но дело в том, какую сторону медали брать за основу -- от туда и плесать. Так что это не более чем очередная холиварная дискуссия будет.

так в том то и дело что ен срабатывает и при ховере цвет текста черный, а не белый

нет, данные подсчеты, в данном случае, делает LESS

у тебя такое было? тебя заставляли использовать технологии которые нафиг не надо в данном конкретном проекте? я своих заказчиков "продвигаю" использовать те или иные технологии, в рамках конкретного проекта, и подтверждаю свои рекомендации списком положительных и отрицательных фактором. тем более не будем забывать что использование любой технологии поверх стандарта html/css приводить к удорожанию разработки. даже элементароное внедрение и настройка jQ плагинов стоит денего и времени, не говоря про самопис. если заказчик не компетентен в предметной области, это не значит что надо его слушать, а наоборот -- надо рассказать, как добиться лучшего результата, за меньшее время и за меньшие для него деньги. Ибо деньги в 99% случаев самый важный фактор.

мы говорим про бустрап, а значит имеем дело с: .btn {... &:hover, &:focus { color: @btn-default-color; text-decoration: none; }}так что ранее он уже был определен, и inherit для :hover, имхо, не сработает. я на это наткнулся как раз таки более полгода назад, помучался и забил. не такая проблема переопределить color для :hover

он бы наследовался, если бы ранее не был применен стиль к :hover.

1) может все таки не надо пихать классы сетки в разметку, а использовать для этого less? 2) По теме. Для того что бы текст не соскакивал вниз, в данном случае нужен ws:nw для ".list-adv li", но при этом его отменить для ".list-adv p" Далее, у тебя ломается строка и создается "лесенка" потому что у тебя высота каждого блока разная. Это вполне предсказуемо и нормально, в данной ситуации. Решить ситуацию можем добавив стили: .list-adv li {display: inline-block;float: none;vertical-align: top;white-space: nowrap;} Я не знаю зачем тебе сдался вообще Бутстрап в данном проекте? Ради прикола что ли? Подключать его в столь мелкий проект, и при этом использовать не правильно... Ох горенька-горенька...

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

так map под данную задачу подходит шикарно

а при чем тут java вообще? то что ты хочешь сделать будет иметь возможным, наверно, через пару лет и ни о каких там IE7 вообще речи быть не может. хочешь сейчас -- пиши на флеше.

для такого, и что бы гарантированно, лучше использовать Флеш

это очень просто, на расписывать долго. научись для начала делать спрайты: http://compass-style.org/help/tutorials/spriting/

Кто тебе такое сказал? У меня есть проект на базе LESS (bootstrap). В нем помипо иконок в шрифтах, используйется так же SASS+Compass генератор спрайтов. Более того, на выходе я получаю .less файл, который потом интегрируеться в общий LESS поток. Что в свою очередь позволяет использовать .icon-my_name; внутри э Никто не мешает использовать лучшее от обоих технологий )

ну например можно так: http://note.io/1hyycuu

а как должно быть? контент, кстати, никуда не , "съезжает" -- он выравнивается по-центру области.

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

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

я говорил о картинках в шапке. тема вопроса поменялась? мы теперь говорим о чем-то другом?

может этот подойдет, но там принцип обратный -- задаются падинги

то что я вижу в данный момент -- все отлично работает: http://note.io/1fTAnIv