Если говорить вкратце, то основная идея БЭМ — это полный отказ от каскадов и любых цепочек классов.
Однако, как отмечают в яндексе: «Не обязательно использовать БЭМ ровно в том виде, в котором он предлагается».
Соответственно, здесь вопрос относится к тому — какое соглашение принято в Вашей компании (либо лично Вами)
Если Вы в коде встречаете .heading без дополнительной информации — главное, что вы должны полагать — это шапка сайта.
Если же heading «тыкается» в каждый блок — это пример плохого сайта.
Главная проблема верстки, на мой скромный взгляд, когда разработчик говорит себе — тут сайт маленький, одна страница… сделаю-ка я его каскадом и id… А плохо это потому, что:
1) Может потребоваться изменить сайт (даже статический, да)
2) Эта болезнь может передаться новичкам
3) Разработчик может решить — «да я писал на id css, все работает, сделаю-ка я и в большом проекте так же.»
Это вопрос уже ближе к стилю кода. Те же классы могут повторяться и т.д.
Прелесть использования id для js — их уникальность, соответственно — поиск по DOM модели будет быстрее (при найденном элементе — поиск далее продолжать не нужно)
Ваш код получается очень специфичный. Такой код совершенно спокойно подходит для написания страниц, которые не нужно будет затем менять, но не для проектов, которые постоянно развиваются.
Использование стилей для id элементов не есть хорошо.
При последующей поддержке такого сайта Вы пойдете в inline стили элементов.
Необходимо принять, что стили для id — это плохо.
Для стилей лучше использовать class. id -использовать для js кода.
Главная задача хорошо сверстанной страницы — возможность перемещения блоков в любое место. Простой пример — у вас есть блок новости.
Теперь в блок новости нужно вставить не только сами новости, но и скажем, блок погоды. В данном случае, если у вас используется каскадная верстка (.class div div и иже с ними), то Вам придется переписывать верстку для погоды и новостей. В большом проекте — это большое время и затраты. (сменили в одном месте — вполне может упасть в другом. Опять придется «выплывать» за счет inline стилей. (либо !important) Проект станет менее понятным.
При верстке проектов лучше подходить с точки зрения какой-либо из методологий верстки — (Для российского сегмента интернета самой популярной методологией является БЭМ, разработанный в недрах яндекса)
Зря вы так. C# очень мощный язык. Да, он начался как пародия на Java, но посмотрите сейчас — многие моменты в C# реализованы лучше, чем в Java. (и наоборот). Эти языки были и будут сосуществовать в конкуренции. Главный недостаток C# — ограниченность платформой Windows (да, есть Mono, но это не тоже самое, что весь .NET)
Определенный интеграл от функции — есть площадь — не проще было ли найти площадь четверти круга?
Наверное именно простейшего решения от Вас и добивались?
Насчет первого не смотрел, по причине — нет нужды.
Лайки YouTube — отключаются. Также как и вообще поиск вашего канала по почте.
И все же — написать в твиттер и поставить лайк разные вещи. Лайк, зачастую может означать не только «мне понравилось», но и «я согласен», «думаю, взгляну позже» и т.д. Да, я знаю, про такую особенность, как «посмотреть позже» на YouTube, но согласитесь, поставить лайк все же сподручнее?
Побуду КЭПом:
1) «Фича» по умолчанию включена (все тихо, мирно) А значит, большинство пользователей просто не задумается и не отключит.
2) Если от друзей рекомендации интересны — не проще их прямо спросить?
3) Теперь отслеживать действия пользователей третьим лицам будет проще. (например:
Есть Вася Пупкин, которого Дима очень не любит. Пупкин подписывается на Диму и начинает отслеживать — где он лайк поставил, где он сообщение написал… и вообще становится в курсе событий, какие видео но тытубе посмотрел и так далее. Скажите, Диме это надо?)
Ну и в догонку — Вам бы хотелось, чтобы весь интернет знал, «какой фильм вы лайкнули»?
Реализация задачи, как правило, зависит от конкретной задачи.
Нельзя найти «всегда верный» рецепт. Если целевая аудитория использует устаревшие браузеры, стоит заботится о них.
Такой сервис, например как soundCloud целевой аудиторией считает пользователей IE9+.
А говоря о скорости отрисовки страниц, то долгая отрисовка скорее всего означает «плохую» верстку, работу скриптов, и в меньшей степени порядок загрузки. Это влияет, да. Но менее критично (на порядок). Или я не прав?
IE (как минимум 10), Mozilla — не могут не пользоваться параллельной загрузкой (так как заметно бы уступали Chrome)
Safari работает на WebKit, не так?
Смартфоны и планшеты — здесь доминируют все те же браузеры. И опять же те же движки — WebKit, Blink. Насколько я понял и мобильная опера работает теперь на Blink — www.youtube.com/watch?v=Y70JypQCy08
Опять же, смотрите. Про Chrome — использование приоритетов загрузки.
Параллельная загрузка используется всеми браузерами. (опять же из письма Энди Дэвиса)
Не думаю, что Opera в версии 12,5 не практикует многопоточную загрузку.
Во всяком случае, было бы интересно увидеть статью на хабре, в которой провели сравнение способов загрузки «тяжелых» страниц с помощью разных браузеров.
Он ссылается на Chrome, под капотом у которого Blink. А, насколько мне известно, только IE и Mozilla используют другой движок? Не уверен, но думаю, что аналогично параллельную загрузку поддерживают последние версии этих браузеров.
Вставка JS кода в head да, «блокирует» дальнейшую обработку файлов до полной загрузки скрипта. Это верное утверждение.
Но современные браузеры стали умнее (и коварнее). Они точно знают, что можно грузить данные в несколько потоков.
Это означает, что JS файлы будут грузиться синхронно с страницей\другими файлами. Поэтому такая критичность в размещении «вставок» является попросту лишней. А размещение js в одном месте — удобство и эстетика.
Использовать nullable, где будем проводить проверки на наличие значений и доставать их? Думаю, что это не очень изящное решение.
В этом случае лучше воспользоваться идеей C# и назвать это «нештатной» ситуацией и выдавать Exception наподобие OutOfRange. Но опять же это усложнение совершенно простой с точки зрения решаемой задачи функции.
Быстрый старт:
ru.bem.info/articles/start-with-project-stub/
Однако, как отмечают в яндексе: «Не обязательно использовать БЭМ ровно в том виде, в котором он предлагается».
Соответственно, здесь вопрос относится к тому — какое соглашение принято в Вашей компании (либо лично Вами)
А по теме, да, интересно, спасибо
Если же heading «тыкается» в каждый блок — это пример плохого сайта.
Главная проблема верстки, на мой скромный взгляд, когда разработчик говорит себе — тут сайт маленький, одна страница… сделаю-ка я его каскадом и id… А плохо это потому, что:
1) Может потребоваться изменить сайт (даже статический, да)
2) Эта болезнь может передаться новичкам
3) Разработчик может решить — «да я писал на id css, все работает, сделаю-ка я и в большом проекте так же.»
Прелесть использования id для js — их уникальность, соответственно — поиск по DOM модели будет быстрее (при найденном элементе — поиск далее продолжать не нужно)
Использование стилей для id элементов не есть хорошо.
При последующей поддержке такого сайта Вы пойдете в inline стили элементов.
Необходимо принять, что стили для id — это плохо.
Для стилей лучше использовать class. id -использовать для js кода.
Главная задача хорошо сверстанной страницы — возможность перемещения блоков в любое место. Простой пример — у вас есть блок новости.
Теперь в блок новости нужно вставить не только сами новости, но и скажем, блок погоды. В данном случае, если у вас используется каскадная верстка (.class div div и иже с ними), то Вам придется переписывать верстку для погоды и новостей. В большом проекте — это большое время и затраты. (сменили в одном месте — вполне может упасть в другом. Опять придется «выплывать» за счет inline стилей. (либо !important) Проект станет менее понятным.
При верстке проектов лучше подходить с точки зрения какой-либо из методологий верстки — (Для российского сегмента интернета самой популярной методологией является БЭМ, разработанный в недрах яндекса)
Наверное именно простейшего решения от Вас и добивались?
Лайки YouTube — отключаются. Также как и вообще поиск вашего канала по почте.
И все же — написать в твиттер и поставить лайк разные вещи. Лайк, зачастую может означать не только «мне понравилось», но и «я согласен», «думаю, взгляну позже» и т.д. Да, я знаю, про такую особенность, как «посмотреть позже» на YouTube, но согласитесь, поставить лайк все же сподручнее?
1) «Фича» по умолчанию включена (все тихо, мирно) А значит, большинство пользователей просто не задумается и не отключит.
2) Если от друзей рекомендации интересны — не проще их прямо спросить?
3) Теперь отслеживать действия пользователей третьим лицам будет проще. (например:
Есть Вася Пупкин, которого Дима очень не любит. Пупкин подписывается на Диму и начинает отслеживать — где он лайк поставил, где он сообщение написал… и вообще становится в курсе событий, какие видео но тытубе посмотрел и так далее. Скажите, Диме это надо?)
Ну и в догонку — Вам бы хотелось, чтобы весь интернет знал, «какой фильм вы лайкнули»?
Реализация задачи, как правило, зависит от конкретной задачи.
Нельзя найти «всегда верный» рецепт. Если целевая аудитория использует устаревшие браузеры, стоит заботится о них.
Такой сервис, например как soundCloud целевой аудиторией считает пользователей IE9+.
А говоря о скорости отрисовки страниц, то долгая отрисовка скорее всего означает «плохую» верстку, работу скриптов, и в меньшей степени порядок загрузки. Это влияет, да. Но менее критично (на порядок). Или я не прав?
Safari работает на WebKit, не так?
Смартфоны и планшеты — здесь доминируют все те же браузеры. И опять же те же движки — WebKit, Blink. Насколько я понял и мобильная опера работает теперь на Blink — www.youtube.com/watch?v=Y70JypQCy08
Параллельная загрузка используется всеми браузерами. (опять же из письма Энди Дэвиса)
Во всяком случае, было бы интересно увидеть статью на хабре, в которой провели сравнение способов загрузки «тяжелых» страниц с помощью разных браузеров.
Он ссылается на Chrome, под капотом у которого Blink. А, насколько мне известно, только IE и Mozilla используют другой движок? Не уверен, но думаю, что аналогично параллельную загрузку поддерживают последние версии этих браузеров.
Вставка JS кода в head да, «блокирует» дальнейшую обработку файлов до полной загрузки скрипта. Это верное утверждение.
Но современные браузеры стали умнее (и коварнее). Они точно знают, что можно грузить данные в несколько потоков.
Это означает, что JS файлы будут грузиться синхронно с страницей\другими файлами. Поэтому такая критичность в размещении «вставок» является попросту лишней. А размещение js в одном месте — удобство и эстетика.
Чтобы предотвратить споры как лучше — ссылочка на веб-стандарты
Таким образом, Да, скрипты лучше размещать сверху. Но огромной производительности в отрисовке не прибудет
В этом случае лучше воспользоваться идеей C# и назвать это «нештатной» ситуацией и выдавать Exception наподобие OutOfRange. Но опять же это усложнение совершенно простой с точки зрения решаемой задачи функции.