• Что учить зная базу HTML, CSS?

    @LexCode
    JavaScript конечно. Дальше практика, ещё дальше сборщики, типа webpack, а вместе с ним и css препроцессоры, вроде sass. Дальше фреймворки, типа vue, react...
    Ответ написан
  • Как исправить конфликт при подключении bootstrap стилей?

    Alexanevsky
    @Alexanevsky
    Любительская web-разработка
    А для чего конкретно бутстрап используется? Можно скачать парочку определённых компонентов, которые используются, тогда конфликтов будет меньше.

    На будущее: почему бы сразу не подключить бутстрап при вёрстке темы?

    И в третьих, моё скромное ИМХО: в топку бутстрап. Его необходимо использовать только для абсолютно шаблонных сайтов.
    Ответ написан
  • Почему сайт отображается некорректно на iPhone?

    @kikki Автор вопроса
    Всем спасибо! Большинство косяков почти исправил.
    1) Во-первых, подключил normalize.css
    2) Добавил все необходимые префиксы с помощью Autoprefixer
    3) Установил виртуальную машину MacOS на VirtualBox и попробовал поменять различные стили в веб-инспекторе Safari. В итоге, методом тыка выяснил, что текст внутри тегов <a>, а также в некоторых других местах не отображался из-за шрифта FT40. Поменял шрифт и текст появился!
    Ответ написан
  • Как ВКонтакте узнает о поисковых запросах, по которым я искал в Яндексе?

    neluzhin
    @neluzhin
    Яндекс является рекламным партнером ВКонтакте и проталкивает в таргетинговую рекламу (которая под левым меню) собственные баннеры. Что примечательно, такие баннеры имеют другие и более мягкие ограничения по количеству символов в описании и названии, нежели те, что накладывает на вас ВКонтакте при создании объявления, а также подобные баннеры могут даже нарушать сами правила ВК. Например, ВКонтакте запрещает обращаться к пользователям в таргетинговой рекламе на "ты", но баннеры Яндекса этот момент частенько игнорируют. Таким образом нельзя исключать, что Яндекс имеет какие-то внутренние алгоритмы или договоренности с ВК, которые позволяют ему на основе одних лишь поисковых запросов составлять группу ретаргетинга.

    Собственно, подробнее о группе ретаргетинга. Владельцы сайтов устанавливают в разметке страницы "пиксели" (картинка размером 1 на 1 пиксель) в теге <img>, которые хостятся на серверах ВКонтакте. Когда юзер загружает эту картинку, то ВКонтакте с помощью cookies определяет ID пользователя и добавляет его в группу ретаргетинга. Затем этой группе можно будет показывать объявления.

    Нередко владельцы сайтов продают места для пикселей другим компаниям, чтобы те могли показывать более релевантные баннеры. Допустим, вы - владелец форума о пылесосах. Какая-нибудь торговая сеть, например МВидео или Юлмарт, может арендовать у вас размещение своего пикселя, который будет собирать для них базу ретаргетинга. И затем они будут показывать вашей аудитории рекламу своих товаров (пылесосов) во ВКонтакте.
    Ответ написан
  • Поддерживают ли мобильные браузеры ES6?

    @SergeyZelensky-Rostov Автор вопроса
    Извините за беспокойство нашел таблицу по поддержке ES6 браузерами так что вопрос не актуален
    вот ссылка если кому-нибудь понадобиться
    Ответ написан
  • Как решить проблему отображение тени (css+html)?

    Serj-One
    @Serj-One
    i'm sexy and i know it
    Блок справа по оси Z находится выше левого и перекрывает его тень. Это незаметно, пока блоки прозрачны.
    Для решения проблемы нужно поднять блок с ховером над остальными.
    .goods:hover{
        position: relative;
        z-index:1;
    }

    jsfiddle.net/L0u9ry1e
    В вашем случае указывать z-index не обязательно, т.к. блок всего один, указал его для наглядности и понимания сути решения проблемы. Если же наложенных и перекрывающих друг друга блоков несколько, их расположение на оси Z регулируется значением z-index'а.
    Ответ написан
  • Php или Ajax с JS?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    То что вы называете AJAX это всего-лишь XmlHTTPRequest, API Javascript-а которое позволяет вам делать HTTP запросы непосредственно из JS кода. И все. Никакой магии.

    Когда вы переходите в браузере на какую-то страницу, например index.php, создается HTTP запрос. Далее запрос идет на сервер где его ловит апач или nginx или еще кто. Тот смотрит что мы хотим получить результат работы скрипта index.php и просит PHP запустить скрипт для такого-то запроса. PHP любезно парсит запрос, раскидывает все по масичвикам $_SERVER/$_GET/$_POST и т.д. и запускает этот самый index.php.

    Далее ваш скрипт выдает ответ, то есть это какие-то заголовки (например если вы делаете редирект вы выставляете заголовок Location) и тело (все что вы выводите через echo). Этот ответ уходит клиенту и он видит радостно страничку.

    Что нам дал XmlHttpRequest? Он дал нам возможность делать эти самые HTTP запросы по своей прихоти а не только когда пользователь снизайдет отправить форму или перейти по ссылке. Можно хоть в цикле бесконечном сервак опрашивать на предмет наличия новых данных (если очень упрощать то приемрно так работает скажем уведомления во вконтактике).

    Подытожим: Нет, вы не можете заменить серверную часть на технологию, которая реализует общение с этим самым сервером. Это просто дополнительная возможность предоставляемая вам Javascript-ом. Как ею воспользоваться решать вам.
    Ответ написан
  • Что такое Less и Sass?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Лень двигатель прогресса. Хороший пример - принцип DRY - Don't repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

    Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:
    • организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
    • Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
    • Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
    • Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.


    Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

    • У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
    • С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
    • Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
    • Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.


    Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

    Далее уже шли какие-то модификации дальнейшие, вроде того же Stylus, где синтаксис упростили просто до нельзя.

    Личное мнение. На сегодняшний день я не вижу смысла использовать чистый CSS хоть на малых хоть на больших проектах. Вот вообще никакого.
    Ответ написан
  • Как сочетаются flex-basis flex-grow и flex-shrink?

    bugo_aneo
    @bugo_aneo
    Верстальщик по жизни, йог, буддист, кофеман
    СВОЙСТВА!!! flex-basis flex-grow и flex-shrink
    flex-basis - это та ширина, будем называть так, которая неотъемлима у элемента. Не хотите ее юзать - используйте min-width.
    flex-grow - это "жадность" того или иного элемента. Т.е. сколько свободного пространства он съест, по сравнению с соседом (Спека: Определяет, сколько пространства может занимать флекс внутри контейнера. По дефолту = 0). Вспоминаем ФБоксовский способ прижатия футера к низу:
    .wrapper {
    display: flex;
    flex-direction: column;
    height: 100%;
    }
    .content {
    flex: 1 0 auto;
    }
    .footer {
    flex: 0 0 auto;
    }

    и flex-shrink - это то, как будут сжиматься элементы, если места хватать не будет. Антагонист flex-grow. По дефолту = 1, в отличие от flex-grow = 1 (Это ТОЛСТЫЙ намек)
    Спека: Устанавливает коэффициент сжатия флексов в контейнере и задаёт, насколько элемент будет уменьшаться по отношению к другим флексам, чтобы разместить все элементы в одну строку

    Базис задавать НАДО! если желаете адаптивности, при заданном flex-wrap: wrap;
    Спека: Свойство flex-basis определяет основу флекса, которая является начальным размером элемента.
    ВОПРОСЫ?!
    https://webref.ru/css/flex-basis
    https://webref.ru/css/flex-grow
    https://webref.ru/css/flex-shrink

    Нужны ответы? Берете простеньки макетик, а-ля Бутстрап и верстаете весь!!! на флексах. После 5-й верстки наступит Дзен! ИМХО!
    Ответ написан