• Как лучше двигать сайт?

    SilenceOfWinter
    @SilenceOfWinter
    та еще зажигалка...
    В порядке важности:
    1. Контент: уникальный и регулярно обновляемый (в том числе изображения, видео)
    2. Ключевые слова (по которым планируется продвигать сайт): выявление и акцентирование (повышение частоты использования, выделение положением на странице, размером, типом), сюда же входят мета теги и заголовки
    3. Навигация: меню, перекрестные, сквозные ссылки, карта сайта (sitemap.xml)
    4. Публичность: регистрация в поисковых системах, каталогах, соц.сетяц
    5. Реклама: покупка площадей (статьи, ссылки), привлечение активных, популярных пользователей
    Ответ написан
    Комментировать
  • Веб-дизайн без фотошопа - реально ли?

    Могу посоветовать www.axure.com/. Это не графический редактор, а программа для создания макета сайта (ну и дизайна даже)
    Ответ написан
    1 комментарий
  • Как использовать flexbox на реальных проектах?

    Petroveg
    @Petroveg
    Миром правят маленькие с#@&ки
    Безусловно, ведь нет поддержки только в IE9 и ниже. А для них пишется что-то своё, благо они поддерживают conditional comments.
    В сложных случаях для этих версий IE (вертикальное расположение) можно написать полифилл (причём уверен, что реализованные варианты уже есть).

    Ну а впоследствии при решении не поддерживать IE9 отрубается условный комментарий и все живут долго и счастливо.
    Ответ написан
    2 комментария
  • На чем делают прототипы веб-страниц?

    p1xel
    @p1xel
    UX-спасатель
    Мне кажется, вы немного запутались с терминологией.

    Прототипы (вайфреймы, мокапы) могут делаться, к примеру, на бумаге. Могут в специализированном софте (типа Axure). Некоторые дизайнеры накидывают прототипы из готового UI кита прямо в Фотошопе (порочный подход, по-моему).

    Макеты же дизайна рисуются в Фотошопе т.к. это непризнанный отраслевой стандарт для дизайна сайтов. Ну и как же без отрисовки кнопочек? Естественно, можно сразу фигачить код, но, имхо, это более затратно.
    Ответ написан
    8 комментариев
  • Как можно программно нажать submit если файл выбран?

    Petroveg
    @Petroveg
    Миром правят маленькие с#@&ки
    $(document).on('change', 'input[type="file"]', function () {
    	this.form.submit();
    });
    Ответ написан
    9 комментариев
  • БЭМ для малых и средних проектов?

    k12th
    @k12th
    console.log(`You're pulling my leg, right?`);
    Если всю жизнь планируете сидеть на средних проектах — то можно, конечно, и без БЭМ, и без препроцессоров:)
    Ответ написан
    5 комментариев
  • Есть ли какие-то специальные рекомендации в методологии БЭМ при верстке HTML5?

    qfox
    @qfox
    Ответы есть у меня
    Зайки кушают морковку, волки кушают овес, и все бы замечательно было бы в лесу, если бы не контекст.
    - HTML5 не идеальная штука, верстать в четком соответствии с его стандартнами — равно смертный приговор внешнему виду проекта. Это достаточно сырой продукт, который производители браузеров решили кусочно выложить в свет. Что из этого получится — будет известно через пару лет, когда все грабли познают своего на них наступившего.
    - Количество проблем с кодом будет увеличиваться линейно или даже квадратически, в зависимости от ваших навыков. В любом случае, вы никогда не уйдете от классов и элементов. И скоро работы ваших сайтов при описанном подходе (поиск по тегам, поиск по data-атрибутам, смешанные селекторы и пр.) будет влиять как на первичную отрисовку страницы, так и на все последующие перерисовки достаточно сильно просто потому, что оптимизация, конечно, есть, но от полного перебора дом дерева при его перестройке никто не уйдет.

    Я, как и некоторые, уже давно не считаю html и css чем-то, что стоит писать руками. Если в js можно просто забыть и не использовать неудачный опыт типа with, отстуствия разделителей (;) при переносе строк, и т.п., это все-таки императивная среда, то с декларативной природой css и html — можно абстрагируясь писать языки разметки, вычленять кусочки из целого и реиспользовать много раз где нужно, и прочее.
    Вам HTML5 говорит о том, что хорошо бы вычленить все описание section в отдельное место, всякие стили, скрипты, и прочее?
    Да и ваш подход, с тэг = блок, не приживется. Подойдет только для очень мелких сайтов. Просто потому, что у вас тэги кончатся. Попробуйте заверстать страничку пользуясь своим руководством, и все поймете. Я уже не упоминаю про семантику.

    Если применять БЭМ в чистом виде к HTML5 получиться избыточное количество классов, которые добавляют "независимость блокам" так где она есть или не нужна.

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

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

    Порог входа не низок, не высок, но есть. Все кто против — либо любят наступать на грабли, либо ничего долгосрочного не делали, либо фанаты w3c (а не здравого смысла), либо ваш вариант.
    Ответ написан
    Комментировать