Есть древнющий баг с Undo/Redo, все никак не доберусь до трекера чтоб правильно сформулировать и зарепортить, если еще не зарепорчено) Поэтому зарепорчу здесь.
Суть бага в том, что, если история изменений файла большая и зажать Undo, так сказать, до упора, а потом попробовать все вернуть зажав Redo тоже до упора, то в какой-то момент код ломается и превращается в рандомную кашу и вернуть его обратно в корректный вид можно только с помощью локальной истории.
Не смертельно, но иногда поднаживает :)
Товарищи, а может кто-нибудь что-то подобное рассказать про других гигантов IT-индустрии за рубежом (США, Европа), к примеру — Apple, Amazon, Microsoft и т.п?
Больше всего, конечно, интересует как там работается, а не как туда попасть, так как, если есть желание, то это лишь дело времени. Хотя, если есть на примете какие-либо хитрости и трюки по трудоустройству, то тоже будет интересно узнать :)
Согласен. Если брать всю методику разработки в целом, то, конечно, учитывать иерархию внутри элементов и делать многоуровневые вложенности папок в файловой системе абсолютно излишне и было бы полнейшим маразмом.
Если же брать только метод именования (ну и, конечно же, независимость блоков), то в отрыве от вашего инструментария и системы разбивки всего внутри блока на папки — метод именования становится нелогичным. А, как мне кажется, в большинстве случаев верстальщики с небольших проектов как раз заимствуют только именование.
Если вы говорите о том, какие классы используют в Яндексе, то это не так: схема именования элемента не зависит от его вложенности в другие элементы.
Я говорил о верстке Яндекс.Почты и, как мне думалось на тот момент, об именовании по БЭМ'у в целом. Выше я уже неоднократно признавал, что был не прав на этот счет.
Если вы говорите о БЭМ в целом, то это тоже не верно. БЭМ как методология не регламентирует именование классов, оставляя это за конкретной реализацией.
Не о БЭМ в целом, а только о вашем, так сказать, дефолтном методе именования по БЭМ'у.
Да я уже понял, что «чисто по БЭМ'овски, как Виталя прописал» все именно так, как вы говорите. Даже покаялся чуть ниже в комментах.
Теперь же просто высказываю точку зрения о том, что оригинальное БЭМ-именование, на мой взгляд, нелогичное и трудное для восприятия, и объясняю как и почему, опять же на мой взгляд, было бы логичней и понятней.
С категоричностью первого высказывания, конечно, погорячился, каюсь.
Просто мне БЭМ представлялся более логичным, универсальным и понятным, чем он есть на самом деле. Раньше удивлялся тому, что многим он непонятен и монструозен для восприятия. Теперь же понимаю отчего это происходит.
Так как, глядя на вашу почту, я был уверен, что в БЭМ именование происходит именно так, как уже описывал выше, я неоднократно давал своим друзьям начинающим верстальщикам ссылку на bem.info (хотя сам года 2-3 ничего не читал про БЭМ) и у всех без исключения после прочтения гайдов метод именования вызывал затруднения. После того же, как я объяснял все со своей колокольни, опять же все без исключения говорили «ааа, теперь все понятно, так бы сразу и сказал».
Замечу, что я говорю только о методе именования. Основополагающий же принцип БЭМ'а о независимости блоков бесспорен.
Я прекрасно понимаю что имеется ввиду в записи Beyondtheclouds. Я же пытаюсь абстрагироваться от документации и следовать логике.
И, думаю, бессмысленно доказывать, что белое — это белое, а в этой абстрактной разметке:
… news — блок, list — элемент блока, а item — элемент блока, вложенный в другой элемент блока.
К тому же если иерархия плоская, а стили независимы — …
Стили внутри блока не могут быть независимы. В большей или меньше степени, но они обязательно зависят от того, что рядом, во что обернуты и что внутри. А если элемент независим, то это уже блок.
Я, пожалуй, воздержусь от спора о фломастерах, а попробую описать чем лично меня не устраивает приведенный вами тип записи с точки зрения моей логики:
1. Вы в имени элемента так или иначе используете ту же самую иерархию именования, что я описал выше, только в качестве разделителя пишете абсолютно нелогичный с моей точки зрения символ дефиса.
«list» — это элемент? Да.
«item» — это элемент? Да.
Элементы по БЭМ отделяются так — "__элемент"? Да.
Так при чем здесь тогда дефис? И, интересно, как бы вы написали такое — «news__list__item__link__image»?
2. Именование модификаторов как "_ключ_значение", на мой взгляд, излишне. На практике для нормального понимания абсолютно всегда достаточно написать только "_значение". Или кому-то в строке "*_disabled *_hidden *_big" будет непонятно, что "_disabled" — это о состоянии, "_hidden" — о видимости, а "_big" о размерах? Зачем писать лишние "_state", "_visibility" и "_size", когда все и без них очевидно?
А вы внутри имени ставите разделитель «блок-элемент».
Я ставлю разделитель "__элемент-блока", вложенный в "__другой-элемент-блока", так как в данном случае они неотделимы. Чуть подробней описал в комменте выше.
Явного запрета на иерархию в именовании элементов блока в их доках я что-то не нашел, к тому же сами яндексоиды на почте верстают именно так.
Да и с точки зрения логики это, по-моему, правильней, так как link — это по сути элемент, вложенный в другой элемент и не имеющий смысла вне родительского item'а. Если же link такой универсальный и существует потенциальная возможность его дальнейшего использования в другом месте, то он должен быть вынесен отдельно в качестве блока.
Но в любом случае, даже если ребята из яндекса имели ввиду то, о чем вы говорите — это все малозначительные нюансы и разные команды разработчиков могут с легкостью принимать свои откорректированные условия именования, с которыми им будет удобней работать на том или ином проекте. Главное — придерживаться одного стиля. Основополагающий же тезис методологии о независимости блоков от этого никак не страдает.
К примеру, у нас на проекте мы с коллегами отказались от всяческих предлагаемых яндексом префиксов, но добавили свой — префикс «w-», который мы добавляем к элементам-оберткам (так называемые wrappers, отсюда и название префикса). Таким образом мы отделяем вспомогательные обертки от участия в иерархии при именовании, о которой я писал выше. Вот типовой пример нашего кода:
Как уже заметил pred8or, считать следует не только разрешения экранов пользователей.
Информации только по разрешениям недостаточно, чтобы делать полноценные выводы о размере области экрана, в которой отобразится ваша страница у пользователя. habrahabr.ru/company/mailru/blog/142193/ — здесь чуть подробней описан ход мыслей и результаты похожих подсчетов на нашем проекте.
Я говорю только про доктайп HTML5 в IE6, а не про то, что вы отнесли к «несколько шире».
Использование нового доктайпа никак не обязывает к использованию кастомных тегов, новых хитрых атрибутов и прочих прелестей HTML5. Поэтому, как я уже сказал, у нас от HTML5 только доктайп и пара малозначимых мелочей вроде атрибута autocomplete.
Что вы подразумеваете под HTML5?
Из HTML5 у нас только несколько малозначимых мелочей и доктайп, а его отлично поддерживают все популярные браузеры, даже IE6.
Точно не помню, но, по-моему, при установке игрового центра должны спрашивать ставить все это «добро» или нет. По крайней мере мне ничего лишнего не установилось.
Суть бага в том, что, если история изменений файла большая и зажать Undo, так сказать, до упора, а потом попробовать все вернуть зажав Redo тоже до упора, то в какой-то момент код ломается и превращается в рандомную кашу и вернуть его обратно в корректный вид можно только с помощью локальной истории.
Не смертельно, но иногда поднаживает :)
А вообще за продукт огромное спасибо, вы лучшие)
Больше всего, конечно, интересует как там работается, а не как туда попасть, так как, если есть желание, то это лишь дело времени. Хотя, если есть на примете какие-либо хитрости и трюки по трудоустройству, то тоже будет интересно узнать :)
Если же брать только метод именования (ну и, конечно же, независимость блоков), то в отрыве от вашего инструментария и системы разбивки всего внутри блока на папки — метод именования становится нелогичным. А, как мне кажется, в большинстве случаев верстальщики с небольших проектов как раз заимствуют только именование.
Я говорил о верстке Яндекс.Почты и, как мне думалось на тот момент, об именовании по БЭМ'у в целом. Выше я уже неоднократно признавал, что был не прав на этот счет.
Не о БЭМ в целом, а только о вашем, так сказать, дефолтном методе именования по БЭМ'у.
Теперь же просто высказываю точку зрения о том, что оригинальное БЭМ-именование, на мой взгляд, нелогичное и трудное для восприятия, и объясняю как и почему, опять же на мой взгляд, было бы логичней и понятней.
Просто мне БЭМ представлялся более логичным, универсальным и понятным, чем он есть на самом деле. Раньше удивлялся тому, что многим он непонятен и монструозен для восприятия. Теперь же понимаю отчего это происходит.
Так как, глядя на вашу почту, я был уверен, что в БЭМ именование происходит именно так, как уже описывал выше, я неоднократно давал своим друзьям начинающим верстальщикам ссылку на bem.info (хотя сам года 2-3 ничего не читал про БЭМ) и у всех без исключения после прочтения гайдов метод именования вызывал затруднения. После того же, как я объяснял все со своей колокольни, опять же все без исключения говорили «ааа, теперь все понятно, так бы сразу и сказал».
Замечу, что я говорю только о методе именования. Основополагающий же принцип БЭМ'а о независимости блоков бесспорен.
И, думаю, бессмысленно доказывать, что белое — это белое, а в этой абстрактной разметке:
… news — блок, list — элемент блока, а item — элемент блока, вложенный в другой элемент блока.
Стили внутри блока не могут быть независимы. В большей или меньше степени, но они обязательно зависят от того, что рядом, во что обернуты и что внутри. А если элемент независим, то это уже блок.
Мы в своей команде решили, что отказываться от каскада в описанном вами случае — излишний фанатизм.
1. Вы в имени элемента так или иначе используете ту же самую иерархию именования, что я описал выше, только в качестве разделителя пишете абсолютно нелогичный с моей точки зрения символ дефиса.
«list» — это элемент? Да.
«item» — это элемент? Да.
Элементы по БЭМ отделяются так — "__элемент"? Да.
Так при чем здесь тогда дефис? И, интересно, как бы вы написали такое — «news__list__item__link__image»?
2. Именование модификаторов как "_ключ_значение", на мой взгляд, излишне. На практике для нормального понимания абсолютно всегда достаточно написать только "_значение". Или кому-то в строке "*_disabled *_hidden *_big" будет непонятно, что "_disabled" — это о состоянии, "_hidden" — о видимости, а "_big" о размерах? Зачем писать лишние "_state", "_visibility" и "_size", когда все и без них очевидно?
Я ставлю разделитель "__элемент-блока", вложенный в "__другой-элемент-блока", так как в данном случае они неотделимы. Чуть подробней описал в комменте выше.
Да и с точки зрения логики это, по-моему, правильней, так как link — это по сути элемент, вложенный в другой элемент и не имеющий смысла вне родительского item'а. Если же link такой универсальный и существует потенциальная возможность его дальнейшего использования в другом месте, то он должен быть вынесен отдельно в качестве блока.
Но в любом случае, даже если ребята из яндекса имели ввиду то, о чем вы говорите — это все малозначительные нюансы и разные команды разработчиков могут с легкостью принимать свои откорректированные условия именования, с которыми им будет удобней работать на том или ином проекте. Главное — придерживаться одного стиля. Основополагающий же тезис методологии о независимости блоков от этого никак не страдает.
К примеру, у нас на проекте мы с коллегами отказались от всяческих предлагаемых яндексом префиксов, но добавили свой — префикс «w-», который мы добавляем к элементам-оберткам (так называемые wrappers, отсюда и название префикса). Таким образом мы отделяем вспомогательные обертки от участия в иерархии при именовании, о которой я писал выше. Вот типовой пример нашего кода:
Для нас в такой записи все прозрачно и очевидно, по стилям сразу видна вся структура блока и видно что и от чего зависит внутри него.
БЭМ выглядел бы так:
Информации только по разрешениям недостаточно, чтобы делать полноценные выводы о размере области экрана, в которой отобразится ваша страница у пользователя.
habrahabr.ru/company/mailru/blog/142193/ — здесь чуть подробней описан ход мыслей и результаты похожих подсчетов на нашем проекте.
Использование нового доктайпа никак не обязывает к использованию кастомных тегов, новых хитрых атрибутов и прочих прелестей HTML5. Поэтому, как я уже сказал, у нас от HTML5 только доктайп и пара малозначимых мелочей вроде атрибута autocomplete.
Из HTML5 у нас только несколько малозначимых мелочей и доктайп, а его отлично поддерживают все популярные браузеры, даже IE6.